On Tue, 2011-06-28 at 07:26 -0700, Steven Dake wrote:
On 06/28/2011 06:24 AM, Joseph VLcek wrote:
> On Mon, 2011-06-27 at 13:59 -0700, Steven Dake wrote:
>> 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
>>> about.
>>>
>>> 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.
>>>
>>> Regards
>>> -steve
>>>
>>
>> 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...
>> -steve
>>
>
> I think the solution of having Audrey store a launch time unique UUID in
> a file that Matahari can read will work.
>
> It may not be necessary to alter oz to insert init scripts to ensure
> Audrey runs before Matahari.
>
> Let me explain.
>
> Audrey does not replace /etc/rc.local
>
> When Image Factory builds the image it appends to the end
> of /etc/rc.local a line of code that will start Audrey.
>
> e.g.:
> [ -f /usr/bin/audrey ] && /usr/bin/audrey
>
>
> I propose having Image Factory append another line to /etc/rc.local
> below where it starts Audrey to start Matahari.
>
> e.g.:
>
> [ -f /usr/bin/audrey ] && /usr/bin/audrey
>
> [ -f <Matahari start> ] && <run Matahari start>
>
> We may need to manage timing to ensure /usr/bin/audrey does not return
> until it has stored the unique UUID in a file and have it return an
> error status if it is unable to.
>
> Thoughts?
>
This sounds fine to me, although the rc.local modification always
sounded a bit hacky (rather then using a proper init script).
One minor
issue is matahari expects to be started via service xxx start and each
agent has a separate init script. There are 5 or 6 agents.
Regards
-steve
> Joe
>
>
Yes. I agree the rc.local modification could be viewed as a bit hacky
however I don't think unacceptably so. If others disagree we could
explore Chris's suggestion of altering oz to insert init scripts.
Joe