openstack team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

Chris Behrens wrote:
> Ed and I were discussing this earlier.  Since I've become the owner of the current Rackspace linux guest agent, I've had some plans to make it easier to change the communication layer so that it can support more than just running under Xen and communicating through XenStore.
> 
> On the agent side of things, I'm planning to make the communication layer pluggable.  This means that that XenStore communication will move into some sort of module, and other modules could be created to communicate over the network (via a private host<->guest network interface) or however else we may decide to make it communicate in the future.  The pieces that do the real work like updating the linux distro configuration files for network, etc, shouldn't need to change based on the hypervisor or communication layer.  But, those should be somewhat pluggable as well, because different distros use different configuration files. :)

There is some overlap here with the discussion on initial instance
setup. How for example you inject the authorized_keys in the instance.

Soren was discussing this yesterday with pvo, and their most
cross-platform option seemed to be to emulate a CD in the instance, that
OS images can be modified to take advantage of.

The official Ubuntu cloud images use the EC2 metadata service: they
query it at boot-time to get user-data that is then used to customize
the instance behavior. If you add Xenstore, that makes already three
different means for the IaaS layer to communicate with specific guests.

Maybe we could use the same kind of pluggable communication layer in
both cases: the boot-time agent (getting info once at boot-time, usually
provided by the OS image builder), and the active agent (polling info
regularly, usually planted in by your cloud provider). I'd hate to see
the two use different mechanisms or layers. (Note that the active agent
would get installed by the boot-time agent, you don't really want to
inject files directly into filesystems.)

Some pointers on cloud-init, the boot-time agent included in Ubuntu
cloud images, that Amazon reused in their own linux cloud images:

https://help.ubuntu.com/community/CloudInit

It is currently EC2-metadata-service-specific, but there is no reason we
can't extend it to support the same "pluggable communication layer".

-- 
Thierry Carrez
Release Manager, OpenStack