On Fri, Jul 1, 2011 at 11:10 PM, Perry Myers <pmyers(a)redhat.com> wrote:
>>> It also pre-supposes that you'd never want the dbus
>>> /etc/machine-id is present.
>> right, that is a bad assumption. My original ideas around exposing UID
>> 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)
>> 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?
Potentially. Where it lives should not be important for entities
accessing it via qmf.
At most the image creation tool may need to know the location.
> - generated once for the lifetime of the vm
How is this different than the one above?
One is configurable, this one is not.
In practice they may have the same lifetime (as may the hardware and
even per-boot uuids), however while this one will be populated if
missing, the previous one will not.
> - generated every time the hardware changes
This is == to smbios uuid right?
Potentially, assuming it has the required properties.
I'm not planning waste time re-inventing the wheel.
> - generated every time the machine boots
This is == DBus/systemd uuid right?
I believe not. I believe the DBus uuid persists across reboots, but
potentially not across upgrades.
I would be happy to be mistaken though.
> - 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'?
Yes. So it exists in case anyone needs to know if the agent it was
talking to previously is the same as it it talking to now.
I'd not expect many users of this one.
If so, I think I see why you'd
> With the accessor being:
> get_uuid(lifetime), and lifetime ::=
I'd call the last one 'agent' not 'matahari' if it's unique to
> 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
No objections to the general concepts above, just the nitpicky questions I
asked need to be clarified :)