On Fri, Jul 1, 2011 at 6:56 AM, Perry Myers <pmyers(a)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
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.
Yes, it's silly to have so many uuids, and I'd love to
declare one of these
to be canonical so we could deprecate the rest. But until that happens, I
fear we're going to need to at least provide support for exposing all of
them...
Then Aeolus and CloudHA can pick which ID they want to set and standardize
on.
The question specific to matahari would be: which uuid should we use
consistently for each agent's core uuid? Right now we use the dbus one
right? If no one is going to muck with that and reset it, I'm happy to
continue using it for our purposes.
> We talked in the past about providing access to both a hardware _and_
> a software uuid.
> Which is /etc/machine-id supposed to be? If the former, then the
> solution is easy - add an extra API call.