Excerpts from Sandy Walsh's message of 2013-12-06 12:12:16 -0800: > > On 12/06/2013 03:45 PM, Dmitry Mescheryakov wrote: > > Hello all, > > > > We would like to push further the discussion on unified guest agent. You > > may find the details of our proposal at [1]. > > > > Also let me clarify why we started this conversation. Savanna currently > > utilizes SSH to install/configure Hadoop on VMs. We were happy with that > > approach until recently we realized that in many OpenStack deployments > > VMs are not accessible from controller. That brought us to idea to use > > guest agent for VM configuration instead. That approach is already used > > by Trove, Murano and Heat and we can do the same. > > > > Uniting the efforts on a single guest agent brings a couple advantages: > > 1. Code reuse across several projects. > > 2. Simplified deployment of OpenStack. Guest agent requires additional > > facilities for transport like message queue or something similar. > > Sharing agent means projects can share transport/config and hence ease > > life of deployers. > > > > We see it is a library and we think that Oslo is a good place for it. > > > > Naturally, since this is going to be a _unified_ agent we seek input > > from all interested parties. > > It might be worth while to consider building from the Rackspace guest > agents for linux [2] and windows [3]. Perhaps get them moved over to > stackforge and scrubbed? > > These are geared towards Xen, but that would be a good first step in > making the HV-Guest pipe configurable. > > [2] https://github.com/rackerlabs/openstack-guest-agents-unix > [3] https://github.com/rackerlabs/openstack-guest-agents-windows-xenserver
This looks promising. The exchange plugin system would, I think, allow for new exchanges that are not Xen specific to be created fairly easily. The XenStore thing seems too low-level to use in the general case. However, the program itself seems to have the right kind of flexible/light weight structure. I think we'll end up having to add some things to Neutron to allow poking holes from VPC's into the cloud infrastructure safely. Once that is done we can use any communication protocol that we can pass through that. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
