On 07/01/11 - 04:09:20PM, Andrew Beekhof wrote:
On Fri, Jul 1, 2011 at 6:56 AM, Perry Myers pmyers@redhat.com wrote:
TBH, I'm not a fan.
Partly because that UUID is a property and attribute of every agent and are initialised at startup - I don't like the idea of those being volatile.
ick, I forgot about that...
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
- generated once for the lifetime of the vm
- generated every time the hardware changes
- generated every time the machine boots
- generated every time an agent starts
With the accessor being: get_uuid(lifetime), and lifetime ::= user|forever|hardware|boot|matahari
One of the things we were trying to do was to not add YAU (Yet Another UUID). That is, we were hoping to hook into one of the existing mechanisms (either dbus or systemd) so that we could re-use this infrastructure. That way existing software wouldn't have to learn about yet another place to fetch a UUID from.
If it turns out that this is impossible, then so be it. But I still think we should investigate the options for integrating with the existing mechanisms.
Or did I completely mis-understand your point?