Skip to content
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

Open
hannesm opened this issue May 7, 2024 · 3 comments
Open

for UI add uuids #173

hannesm opened this issue May 7, 2024 · 3 comments

Comments

@hannesm
Copy link
Collaborator

hannesm commented May 7, 2024

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 as my-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.

@hannesm
Copy link
Collaborator Author

hannesm commented Aug 13, 2024

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?)?

@hannesm
Copy link
Collaborator Author

hannesm commented Aug 13, 2024

Taking a step back, what are names?

  • a name consists of the path (or domain) and the unikernel name: robur:roburtls
  • there may be multiple domains (as far as I can tell, there's no limit to the number of domains)
  • each domain and the unikernel domain may consist of letters, digits, hyphen, period - while the first letter may not be a hyphen. the maximum length is 64 characters

And where are names used?

  • in the block device names: /var/db/albatross/block/robur:tlstunnel
  • in the images on disk /var/run/albatross/robur:roburtls
  • in the fifo for the console output /var/run/albatross/fifo/robur:roburtls
  • in the statistics send to grafana - and here it is useful to have the identical name in albatross and inside the unikernel (to match these in reported measurements); this name is as well used for displaying in grafana
  • in every command passed a Name.t is present (which is the full domain and name)

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.

@hannesm
Copy link
Collaborator Author

hannesm commented Sep 11, 2024

The good news is that it's all rather easy:

  • we have one user in mollymawk mapping to a single arc/path in albatross
  • the username/uuid isn't visible to the user itself: they say "read console of hello"
  • even in grafana we can just setup the very same user for the unikernel arc (i.e. grafana.mollymawk has a signin of user "alice", which shows the unikernels for alice -- but in the background there's only a uuid)

The bad news is that we need to look deeper into grafana and how to get this going.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant