On 07/21/2011 04:55 PM, Perry Myers wrote:
On 07/21/2011 02:24 AM, Andrew Beekhof wrote:
> On Tue, Jul 5, 2011 at 11:58 PM, Perry Myers<pmyers(a)redhat.com> wrote:
>>>>> - 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.
>>
>> Is that by design? If not, then it seems like we could improve that
>> particular uuid by submitting a bug to have dbus/systemd uuids persist
>> across upgrades.
>>
>> ack to your other comments on this thread, can you write up an API proposal
>> then with the new functions and properties that we'll be exposing for review
>> on list?
>>
>
> Sorry for the delay... here are my proposed changes to the host api wrt. uuids.
>
>
> <!--
> Valid UUID lifetimes:
> Immutable - Automatically configured by the system once if not
> found and never reset. May be pre-populated.
> Hardware - Automatically (re)configured by the system whenever
> the underlying hardware changes
> Reboot - Automatically (re)configured by the system whenever
> it boots
> Agent - Automatically (re)configured by the system whenever
> the agent starts
> User - Manually configured by the admin/user.
> May be pre-configured.
> -->
>
> <method name="get_uuid" desc="Obtain a UUID with the specified
> lifetime from the machine">
> <arg name="lifetime" dir="I" type="sstr"
/>
> </method>
>
> <!--
> The only valid lifetime is 'User'
> Later implementations may support re-generating the 'Hardware' uuid
> -->
> <method name="set_uuid" desc="Set a UUID with the specified
lifetime">
> <arg name="lifetime" dir="I" type="sstr"
/>
> <arg name="uuid" dir="I" type="sstr"
/>
> </method>
Thanks for writing this up. My only question now is... what existing
uuid implementations map here?
i.e. for the implementation of hardware UUID we plan on using X, for the
implementation of immutable UUID we will use /etc/machine-id
Stuff along those lines would complete the matrix needed here.
My understanding is that the UUID API being discussed here is largely
for identifying guests and guest services. To that end, it seems like
the objects in the warehouse (images and target images; and later,
templates, assemblies, deployables, deployments, and services, more?)
fall outside the scope of this discussion. Lemme know if I'm wrong there...
As for the Audrey Startup script (the only thing I immediately see as
falling in scope here), it would likely rely on a Agent or User scoped
UUID. I balk at saying it relies on the Immutable scoped UUID, because
there needs to be a reliable way to set the UUID used by the Audrey
Startup script in the guest before it launches, so the same value can be
shared with the config server.
We could force the Audrey Startup script to rely on the Immutable UUID
(if the idea is to reduce the number of UUIDs floating around). That
will turn the launching strategy around in Conductor, insofar as
Conductor would have to wait until the guest launched and could report
back the Immutable UUID (somehow) via deltacloud before it could publish
configuration data to the config server for the guest. In the current
planned implementation, Conductor generates the Audrey UUID and tells
both the Config Server and the guest the value at roughly the same time.
Perry
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel