From: Joseph VLcek <jvlcek(a)redhat.com>
Date: Wed, 25 May 2011 08:43:43 -0400
Mark, et al.
The Big Question:
------------------
Should the COW file be what is used to pass the Config Server contact
info. to a RHEV-m instance at launch time?
Or is there a better way to inject user data into a launching
instance on RHEV-m?
Brief:
------
A solution is needed for passing the Audrey Config Server contact
information (IP address:port/UUID)
Also, in the fullness of time, the OTP, which will be used to
authenticate a booting instance against confserv.
None of these bits of data are very big (we're talking dozens or
possibly a couple hundred bytes), but we need a way of getting them
into the booting instance in a secure fashion.
into an Audrey enabled instance on
RHEV-m. This is required so the IP address of the launching
instance can
be picked up.
It seems a viable solution would be to put the Config Server contact
info into the COW file.
Extra Detail:
-------------
On EC2 the Config Server contact information is passed to the launching
instance using the EC2 user data.
On the Condor Cloud (test environment implemented with libvirt) SMBIOS
properties are used.
The plan had been to also use SMBIOS properties for RHEV-m however it
seems RHEV-m doesn't provide the option to override the SMBIOS data.
(See the rhevm-api email list for the thread started by Michal Fojtik
with the subject: "RHEV-M API SMBIOS support"). Using yet another
mechanism to pass this data to the launching instance on RHEV-m would
require small changes to Image Factory.
It seems the best solution for RHEV-m could be to put the Config Server
contact information in the COW file.
Ian Main has pointed out:
"Condor cloud uses COW images to back writes to a single image. This
way it can cache the image and just create one COW file per instance.
If we inject data, it would be into this COW file. It's very simple and
clean and easy."
Caveat: I know essentially nothing about the flow of control through
the API and RHEV control software. My hope is that we could find a
place in the api layer, where we know the COW has been created, but
the launch hasn't yet happened. We could add something to reach in
with libguestfs or something similar and drop our cookies in a known
place in the COW image.
If the flow of control just doesn't work that way, we'll need to do
something ickier. Worst case, we could copy the base image, register
the copy, and use libguestfs to inject our bits into the copy. But
that's pretty icky.
We also should be getting this feature onto the radar of the RHEV
team, so that even if we have to do something kludgey for now, we can
do it cleaner in 3.0.
Thoughts?
Thanks
Joe