On 07/22/2011 12:40 PM, Mark McLoughlin wrote:
Hi Andrew,
On Fri, 2011-07-22 at 08:19 +1000, Andrew Beekhof wrote:
> Are there any conditions under which /etc/machine-id would get
> regenerated? If so that would rule it out.
>
> These were my initial thoughts:
>
> Immutable: /etc/machine-id (systemd)
> Hardware: ? Something on top of the smbios API
> Reboot: ? /var/lib/dbus/machine-id (dbus)
> Agent: In memory using the libuuid API
> User: /etc/custom-machine-id
Okay, AIUI it (and I've take a quick look to confirm),
both /etc/machine-id and /var/lib/dbus/machine-id are basically
equivalent concepts
They are both a UUID that should be generated when the machine is
installed or booted for the first time and not change thereafter.
Looking at the code, I think dbus and systemd make an effort to have
these UUIDs be identical, but I'm not 100% sure. Hmm, I just checked an
F-16 machine and the two UUIDs are different.
The reference you've probably seen in the dbus docs to the UUID changing
on reboot only applies to stateless systems - the UUID is stored on a
part of the filesystem which may not persist across reboots. That could
equally apply to /etc/machine-id too.
In VM disk images, both of these UUIDs should be deleted so that they
are generated when a new VM is booted from the image. Similar to what is
done for host SSH keys.
On the RHEV-M side, there's a UUID in SMBIOS that has nothing to do with
dbus or systemd. This UUID corresponds to the instance ID you'd see in
the deltacloud API.
When you launch a deployable, you'll get the list of deltacloud instance
IDs back. I'm guessing you want Matahari to reliably report this UUID
back as a "system hardware UUID"?
In that case, the answer when running under RHEV-M is to read the UUID
from SMBIOS.
Under EC2, you get the ID from:
http://169.254.169.254/latest/meta-data/instance-id
and this isn't a UUID at all. I'm not sure about other clouds.
Now, config server seems to have its notion of a machine UUID. This is
passed to the instance at launch time and the audrey startup script has
logic to find it. The idea is that this is supplied to config server by
whatever is launching the instance. I'm not sure why this wouldn't also
be the deltacloud ID.
If the deltacloud ID is the UUID presented to deltacloud by the cloud
provider for the launched instance, then the only reason not to use the
deltacloud ID for the config server and audrey startup script is that it
requires the guest to launch and report this ID before the
configurations can be handed to the config server.
That's not terrible, but just makes the launch sequence more serial
instead of parallelizing the launch and seeding the configs to the
config server. If it's necessary to reduce the number of IDs floating
around, we can do this.
Summary:
- For the HA stuff, I think you need Matahari to be able to reliably
report the deltacloud instance ID a "system hardware ID" or similar
- That's unrelated to the systemd and dbus IDs, but these IDs should
be unique to each machine too.
- You should be able to determine the deltacloud instance ID from
inside each VM.
- This deltacloud instance ID should be what Audrey is using when
contacting config server.
- Audrey and Matahari should have the same logic for figuring this ID
out.
Cheers,
Mark.
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel