[openstack-dev] Unified Guest Agent proposal
Sergey Lukjanov
slukjanov at mirantis.com
Fri Dec 6 20:34:04 UTC 2013
That's an interesting idea to use cloud-init, but it looks like such agent
will be unable to provide feedback like results of running commands.
On Sat, Dec 7, 2013 at 12:27 AM, Joshua Harlow <harlowja at yahoo-inc.com>wrote:
> Another idea that I'll put up for consideration (since I work with the
> cloud-init codebase also).
>
> Cloud-init[1] which currently does lots of little useful initialization
> types of activities (similar to the racker agents activities) has been
> going through some of the same questions[2] as to should it be an agent
> (or respond to some type of system signal on certain activities, like new
> network metadata available). So this could be another way to go.
>
> Including (ccing) scott who probably has more ideas around this to :-)
>
> [1] https://launchpad.net/cloud-init
> [2] https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1153626
>
> On 12/6/13 12:12 PM, "Sandy Walsh" <sandy.walsh at rackspace.com> wrote:
>
> >
> >
> >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
> >
> >-S
> >
> >
> >> [1] https://wiki.openstack.org/wiki/UnifiedGuestAgent
> >>
> >> Thanks,
> >>
> >> Dmitry
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131207/289364a4/attachment.html>
More information about the OpenStack-dev
mailing list