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 Myerspmyers@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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel