On 07/22/2011 10:22 AM, Greg Blomquist wrote:
On 07/22/2011 01:16 PM, Mark McLoughlin wrote:
> Hi Greg,
>
> On Fri, 2011-07-22 at 13:05 -0400, Greg Blomquist wrote:
>> 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.
>
> Yeah, it's not ideal.
>
>> 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.
>
> Well, AFAICT, the only ID that the cloud HA stuff will know about from
> conductor or deltacloud is the deltacloud instance ID. So, that's what
> we want the guest agent to use when reporting back.
Ah, good point.
>
> If you choose to add another ID for config server purposes, that would
> mean the cloud HA stuff would need to find that out. And I think that's
> a step too far in terms of intertwining the architecture. The cloud HA
> stuff should work with standalone deltacloud, without conductor or
> config server IMHO.
Yep, I'm sold.
The first cut I'm working on will generate IDs for Audrey. But, we can
circle back on this and revamp to use the deltacloud ID. The two
changes this implies on the Audrey side are
1) the audrey startup script should use the UUID API to acquire the
Immutable UUID (assuming this is what maps to Deltacloud ID)
2) the conductor launch sequence will be modified to wait to push
configs to config server until the instance is launched and can report
back the deltacloud ID
Sound about right?
This proposal sounds good but leaves out a bit more detail further down
the bootstrap order.
We also need this ID loaded into matahari as well as matahari qpidd
authentication data. This is where the discussion around the machine-id
came from. If it is a different machine-external API coming out of
matahari but available as soon as matahari is started, this WFM.
This could likely be done by audrey with following start order:
audrey client starts
audrey sets matahari authentication information on the filesystem
audrey sets UUID information on the filesystem
audrey starts matahari
The issue with feeding the UUID into matahari via a local api call to
matahari is that once matahari is started it registers with QMF, which
leaves racey conditions where matahari may be active but without an
instance id.
Regards
-steve
>
> Cheers,
> Mark.
>
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel