On Fri, Jul 22, 2011 at 03:30:11PM -0400, Greg Blomquist wrote:
On 07/22/2011 02:34 PM, Steven Dake wrote:
> 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
>>>> 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
>>>> 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
There's still a bootstrapping issue here. Well, maybe...possibly
depending on who cares.
The problem is that the matahari authentication information would likely
come from the instance configuration delivered by the config server.
The audrey client would not get configuration data from the config
server until the config server learns about the instance from conductor.
Conductor wouldn't alert the config server about the instance until it
learns the deltacloud ID from the deltacloud driver.
So, it looks like this (I think--assuming we're talking about a cloud
1. conductor tells deltacloud to launch guest
2. guest boots in cloud provider
3. audrey client starts
4. audrey client contacts config server, but finds nothing there...yet
5. deltacloud driver tells conductor deltacloud ID for guest
6. conductor tells config server about instance configs
7. audrey client contacts config server, gets configs
8. audrey client sets matahari auth information on filesystem
9. audrey sets UUID information on the filesystem
10. audrey starts matahari (finally)
11. matahari can auth against broker
Given that we now have a working userdata mechanism for EC2 and
VMWare, and a soon-to-be-working one for RHEV-M... could we not
leverage that to compress steps 3-7? Meaning, if we dump the instance
configs into userdata, the audrey client could read them from there,
then go straight to contacting config server to get its matahari auth
Tell me if i'm out of my mind here.
Seems like a long time before matahari starts up, but I'm not
all the rest of the dependencies in the chain that may depend on matahari.
There are several steps that are not necessarily serial, like 2-4 and 5.
There's some amount of time between step 1 and step 5 that is
determined by the interaction between deltacloud and the cloud provider
and how that interaction results in a guest ID. In some cases (as David
L. pointed out in another thread), the guest ID is set by the provider,
other times it's expected to be provided. When it's provided (either by
deltacloud or by conductor) it can immediately be turned around to the
config server, and not hold up step 6 much at all. When it's generated
by the cloud provider, step 6 is at the mercy of when the cloud provider
sees fit to make this information available to deltacloud.
> 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.
>> aeolus-devel mailing list
aeolus-devel mailing list
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."