On Tue, 2011-06-28 at 09:43 -0400, Joseph VLcek wrote:
On Tue, 2011-06-28 at 07:56 -0400, John R. Dunning wrote:
> From: Greg Blomquist <gblomqui(a)redhat.com>
> Date: Mon, 27 Jun 2011 18:32:48 -0400
>
>
> The real trick is that three parties _need_ to know the unique id:
>
> * Conductor
> * The instance
> * Config Server
>
> My apologies if I'm adding red herrings, I have been watching this go
> by (and being very glad we're kicking it around, btw) but have not
> been tracking all the details, so here goes:
>
> There are several places where a uuid for the instance need to live.
> One is inside conductor, for internal tracking of the instance state,
> yadda yadda. Another is a characteristic of the virt backend, for
> instance rhev-m or vmware or ec2. Another is the tag used by audrey
> to hand the correct blob of config to the correct instance.
>
> As far as I'm aware, there's no hard requirement that those all be
> the same value. But if they aren't, there needs to be a way to map
> from one kind to another kind. So for instance if conductor wants to
> generate a uuid of "3" when it launches the third instance, and
> somebody maintains a mapping table that says "conductor 3" ->
"rhev-m
> 0123-ff00", that's fine.
>
> >From audrey's point of view, the requirement is that a booting
> instance be able to be identified by whatever uuid it has, so that
> config can be handed to it. And secondarily, so that status can be
> reported back. So for instance, if the thing which populates confserv
> wants to use the backend's uuid as the tag to which it attaches config
> data, that's perfectly ok from the point of view of audrey.
>
> NB that if it's easy to use the same uuid throughout, that's almost
> certainly better, by virtue of being simpler. All I'm saying is that
> if for implementation reasons it becomes expedient to add mapping
> tables to get from the internal uuid to the backend one, that need not
> screw things up for audrey, as long as she's presented with a
> consistent view of the world.
I think we need a Red Hat Cloud UUID independent of any virt backend
generated one. If they can be the same all the better.
My understanding is that Audrey has only been using the virt generated
UUID because of current limitations with RHEV-m v2 for injecting user
data into the image. A solution to this is being investigated for RHEV-m
3.0.
I think we need to make it a requirement of any Cloud back end that it
have some way of injecting user data including a UUID
- or -
If the Cloud back end does not support injection of user data we could
inject that data into the image just prior to launching.
I think it needs to work this way:
1. Conductor - generates the Red Hat Cloud UUID and makes it available
to Config Server
2. Image launch code either passes user data to the image or injects the
user data into the image prior to launching.
3. Config Server - Makes the Red Hat Cloud UUID available to the
Audrey
Start code running in the instance.
Correction:
Config Server does not make the Red Hat Cloud UUID available to the
Audrey Start code.
Step 2. above did that.
Step 3. should read:
3. Config Server - Can now coordinate configuration of the VM based on
the UUID it has and the one made available to the instance in step 2.
4. The instance - The Audrey Start code saves the UUID in a file for any
other Red Hat Cloud related code to pick up, for example Matahari.
Thoughts?
Joe