On 06/17/2011 09:03 AM, Mark McLoughlin wrote:
Hi Greg, Joe, Michal,
I'm curious about the plans around using the config server to make
available the IP address of RHEV and VMWare instances
Apologies if this is written down somewhere already, I just couldn't
find anything on it
AFAIK the plan is roughly:
- VM images will need the audrey_startup script installed and a file
which contains the IP address of the config server
- The VM's UUID will be available to the audrey script in the guest
via the DMI
- The script will do a PUT on config servers /params/.../$uuid and
config server will record the IP address
- This request cannot be authenticated, so there's an inherent hole
we're accepting here - anyone can do this PUT
True.
The short term plan was to have conductor generate a simple password,
add this to the "user data" for the instance, encrypt the password, and
add the encrypted value to the instance config data for the config server.
When the config server receives the instance config, it adds the
instance's uuid and encrypted password to the htpasswd file used by
apache (as a proxy for ssl termination and basic authentication).
Additionally, a location directive could lock down the specific URI for
the instance's configuration information (all HTTP traffic, at least).
When the instance parses its user data, it uses the uuid as username and
generated password to auth with the config server.
The wrench in this plan is that this requires conductor to be the owner
of the instance's UUID. For RHEV, it generates the UUID for the
instance. This wouldn't really be a problem, if we could push user data
into the instance, containing our own instance UUID. Since we currently
don't have a clear way to handle user data with RHEV 2.2 (unless we
explore the COW functionality for modifying the launching instance), we
can't load the instance with our own UUID. This means even more
orchestration with getting the UUID back from the RHEV hypervisor post
launch, then building the instance config data for the config server.
This sequence isn't terrible. But, largely untested (see my comment
below about accepting PUTs for guests the config server doesn't know about).
The longer term plan is to integrate with IPA for auth.
- deltacloud will also be configured with the address of config
server and will do a GET on /ip/.../$uuid if the driver doesn't
return the instance IP address
In terms of how this will work in the upcoming release:
- How does the script get installed on the image? Will image factory
know that it needs to install aeolus-audrey_startup, or must the
user explicitly list the package in the template?
This needs to be explicitly listed in the packages of the template.
- Similarly, how does the config server address get on the image? I
see we have a aeolus-rhevm_config_server package containing the
config file. How is this RPM with the correct address? Is that the
users job? Or will image factory do it? Also, will image factory
know it needs to install this on RHEV/VMWare images?
For RHEV 2.2, since it doesn't support the ec2-style concept of "user
data", the RPM you mentioned has to be part of the template packages.
For VMWare, if the guest is running with the VMWare guest agent,
deltacloud should be able to access the IP address from the VMWare
hypervisor.
- How is config server set up? For now, will we just have
aeolus-configure set up a config server instance alongside
conductor? Since we're only using it for RHEV and VMWare, we can
assume those VMs can connect back to the machine conductor is
running on
yum install aeolus-configserver
By default, this runs the config server on localhost:4567. It's
currently an exercise for the user to setup a proxy in front of that, or
change the host to an externally facing IP and externally accessible
port. There's a configuration file (jclift has it documented, but I
haven't checked if that's landed out in the wild yet) that allows the
user to configure the config server ip and port
(/etc/sysconfig/aeolus-configserver).
I have an package that installs a aeolus-configure-esque script that
will configure apache as a proxy in front of the config server.
However, this will not play nicely with aeolus-configure (since both
want to own the *:443 virt host).
- Does conductor need to do a POST /configs/.../$uuid before starting
the instance in order for config server to record the IP address?
Will conductor gain that config server integration for the release?
If not, can we make the config server accept a PUT from VMs it
doesn't know anything about?
We have a hack in place (I need to verify that I actually committed this
back, or whether we hacked up a running version) that allows the config
server to accept PUTs from arbitrary guests and capture the IP address
and hand out no configs.
I haven't tested this hack with the timing of the POST from conductor to
seed the config server with instance config data. Without the hack, the
launching of the instance and the POST to config server can happen in
any order. Since the hack falsely registers an instance with the config
server, it's possible for an instance to falsely register with a PUT,
and later the conductor correctly attempt to register the instance with
a POST. There's potential for an error to be dumped back to the
conductor since the instance is already registered. I'll look into this.
As far as whether the config server integration will be part of this
conductor release, I'm not actually sure. I've added some UI to manage
the config server data pieces (host, port, cert, username, password) in
conductor...I'm writing some tests for it now. It's not part of the
demo today, so I /think/ (but not positive) that means it's not part of
the release. However, I don't know what's happened with the release
schedule.
- When will deltacloud get support for querying the IP address from
config server?
It appears that there needs to be a condor job variable for deltacloud
for the config server IP address included in the launch job. This is
not in place yet. I'll have to work with either Michal or clalance to
figure out how to get this value to deltacloud.
Thanks in advance,
Hope that helps.
---
Greg
Mark.
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel