On 06/24/2011 04:16 PM, Steven Dake wrote:
Currently most linux distributions that use dbus store a UUID in
/var/lib/dbus/machine_id. In our pacemaker-cloud work test tools, we
must manipulate this file via oz image creation to match a value we know
Q1. Is this file freshly created on each image creation/cloning process?
If not, it should be, because Matahari uses this information to uniquely
identify a host. If it is copied exactly to each new image, that
creates a problem (all hosts appear the same to matahari).
Q2. If/when it is created by image factory, will it be stored in a
database or other storage medium?
In pacemaker-cloud we need to have a mapping from image->internal id id
so that we know which VM maps to which deployable HA configuration.
If we wait on this point until after our 1.0 release, we could end up
with a bunch of images in the field that have either the same machine id
or are not mapped in any way that allows us to provide HA functionality.
After more investigation, Chris and I came up with a workable plan for
handling unique VM ids (see thread with subject How Audrey, Conductor,
and Audrey's config server interact and their relationship to a unique
vm instance id).
Currently the Audrey script runs as a replacement to rc.local. Matahari
runs at S99. The general idea is for Audrey script to run as S98
(before Matahari) and write a management-wide unique instance UUID to
the file /etc/vm_machine_id (audrey has access to this information).
Matahari could be changed to read /etc/vm_machine_id first. If that
file doesn't exist, /var/lib/dbus/machine_id would be read.
This creates some difficulty in running the audrey script at a specific
runlevel (it requires some changes to oz to insert init scripts).
Another option is for the current rc.local script that audrey replaces
to run the Matahari service starting giblits as its first action.
Comments welcome before I start writing code...
aeolus-devel mailing list