openstack team mailing list archive

[Chris Behrens <chris.behrens@xxxxxxxxxxxxx>]

[sorry if this posts twice... don't think LP liked the email address I used to send the first time]

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. :)

I'd propose something similar be done on the host (nova) side of things.  If we can stub out simple calls like 'guest_agent.send/receive_request/response' that we can make pluggable, I think this will give us what we want.  Since Rackspace is currently using XenStore for communication, this will obviously be the first 'module' that we'll need to create.

We might need some discussion around 'protocol'.  We currently encode a 'command' and 'command argument' into JSON to stuff into the XenStore.  We may want to create some encoding methods that are also pluggable, I don't know.

I'd love to hear some of the other thoughts about the agent.  There's a page up on the wiki with links to the etherpad that was used during the last design summit here:

http://wiki.openstack.org/GuestAgent

I admit I've not refreshed my mind with it, myself, recently, but I'll be reviewing it RSN. :)

- Chris

On Dec 14, 2010, at 12:36 PM, Ed Leafe wrote:

> [re-posted to the correct list]
> 
> 	I’m working on the blueprint for resetting the admin password on a XenServer instance (https://blueprints.launchpad.net/nova/+spec/xs-password-reset), but I wanted to run this by the community to get some feedback/input on the design, since it is potentially applicable to other use cases in OpenStack. I figured that email would be a better choice than IRC because of time zones, work schedules, etc.
> 
> 	Please keep in mind that the entire concept of a guest agent and communication between it and the host will be completely *optional*. At Rackspace, since we actively manage guest instances for our customers, it makes a lot of sense. For other applications there would be no need at all for this, and lots of reasons not to. Another aspect is that this is intended for communicating with running instances, not for the initial creation. What I'm looking for are other potential use cases for when someone would need the host to communicate to the guest and vice-versa.
> 
> 	The current design uses a guest agent installed on the instance that regularly checks XenStore for password reset requests. Obviously this is a XenServer-specific design, so I’m looking for suggestions on a hypervisor-agnostic solution for the request store: one that is as lightweight as possible, and which hosts and guests would be able to access.
> 
> 	When the guest agent finds a password reset request in the store, it starts the password resetting routines, and updates the record with its status, which the host can check to report back to the requester. I think that this approach is simple enough to work for any agent requests, not just password resetting, but I’d like to hear other ideas if you have any.
> 
> 
> -- Ed Leafe
> 
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace. 
> Any dissemination, distribution or copying of the enclosed material is prohibited.
> If you receive this transmission in error, please notify us immediately by e-mail
> at abuse@xxxxxxxxxxxxx, and delete the original message. 
> Your cooperation is appreciated.
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

Attachment: smime.p7s
Description: S/MIME cryptographic signature