>> It also pre-supposes that you'd never want the dbus id
if
>> /etc/machine-id is present.
>
> right, that is a bad assumption. My original ideas around exposing UID in
> matahari APIs was to have _several_ api calls depending on what you
> considered to be the proper UUID
>
> So maybe we need to have calls like:
>
> get_dbus_uuid (/var/lib/dbus/machine_id)
> get_machine_uuid (/etc/machine-id)
> get_smbios_uuid
>
> And if we _really_ need a separate vm_machine_id
> get_vm_machine_uuid (/etc/vm_machine_id)
>
Slight variation on the theme...
I think we should focus on the properties of the uuids rather than
where they live and/or who generates them.
So I'm thinking we want 5 uuids and probably one accessor, where each
uuid would have a different lifetime:
- externally configured
So as you say below, this is set by postboot, current thinking is that
postboot puts this in /etc/vm-machine-id, right?
- generated once for the lifetime of the vm
How is this different than the one above?
- generated every time the hardware changes
This is == to smbios uuid right?
- generated every time the machine boots
This is == DBus/systemd uuid right?
- generated every time an agent starts
What does this map to, and what's the value in it? Does every Agent on
a given guest get a different 'agent uuid'? If so, I think I see why
you'd want this.
With the accessor being:
get_uuid(lifetime), and lifetime ::= user|forever|hardware|boot|matahari
I'd call the last one 'agent' not 'matahari' if it's unique to
each agent.
The externally configured one would/could be set as part of our
"name
other than config or postboot" agent process.
People then pick whichever uuid has the properties they need.
I imagine matahari would provide the first two as attributes/properties also.
No objections to the general concepts above, just the nitpicky questions
I asked need to be clarified :)
Perry