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.