-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
for UI add uuids #173
Comments
This is slightly more complicated, after talking at length with @PizieDust, since the domain (arc / user) as well could be uuids. And the question is where should the aliasing be stored, is it albatross or in mollymawk? Should albatross without mollymawk be useful (I fear if the mapping is not present, it will be pretty obscure). I guess we should put a bit more thoughts on this before jumping to a conclusion. It involves not only mollymawk, but as well the Grafana/Influx reporting, and opens the question on who should create UUIDs (albatross? mollymawk?)? |
Taking a step back, what are names?
And where are names used?
So, there may be considerations about maximum file name / path name; also usability (the correlation between albatross metrics and unikernel metrics is pretty useful -- or at least was pretty useful). Given the limitations above, a UUID can of course be used as unikernel name (also as domain). What is still unclear is whether such a UUID would then be known to the unikernel itself? And whether Grafana/Influx can be made aware of a UUID to name mapping (so that users have an easier time clicking on names rather than UUIDs). I guess in order to find a conclusion we may want to go in detail through some workflows and figure out what is needed. |
The good news is that it's all rather easy:
The bad news is that we need to look deeper into grafana and how to get this going. |
There's need for having unique IDs for the web UI. It looks like both "this unikernel with this name serving this service" is a good thing to have, and also "this is the execution of Y" -- so we can identify the
hello
unikernel running asmy-hello
(let's assume UUID=5), and when it is upgraded to a later version the UUID should be kept the same -- but if at a later point in time, "my-hello" has a different purpose, there should be another UUID (yes, I know it is tricky, esp. since albatross doesn't know anything about dead unikernels). Maybe using the unikernel name as UUID seed is the way to go for now.The other UUID should be per execution -- so whenever we execute solo5-hvt until it terminates.
The text was updated successfully, but these errors were encountered: