On 07/01/11 - 04:09:20PM, Andrew Beekhof wrote:
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
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?
--
Chris Lalancette