Tim, IMHO network-based and hypervisor-based agents definitely can co-exist. What I wanted to say is that the problem of enabling communication between guest and cloud service is not relevant for hypervisor-based agents. They simply don't need network access into a VM.
Dmitry 2013/12/19 Tim Simpson <tim.simp...@rackspace.com> > >> I agree that enabling communication between guest and cloud service is > a common problem for most agent designs. The only exception is agent based > on hypervisor provided transport. But as far as I understand many people > are interested in network-based agent, so indeed we can start a thread (or > continue discussion in this on) on the problem. > > Can't they co-exist? > > Let's say the interface to talk to an agent is simply some class loaded > from a config file, the way it is in Trove. So we have a class which has > the methods "add_user", "get_filesystem_stats". > > The first, and let's say default, implementation sends a message over > Rabbit using oslo.rpc or something like it. All the arguments turn into a > JSON object and are deserialized on the agent side using oslo.rpc or some > C++ code capable of reading JSON. > > If someone wants to add a hypervisor provided transport, they could do so > by instead changing this API class to one which contacts a service on the > hypervisor node (using oslo.rpc) with arguments that include the guest > agent ID and "args", which is just a dictionary of the original arguments. > This service would then shell out to execute some hypervisor specific > command to talk to the given guest. > > That's what I meant when I said I liked how Trove handled this now- > because it uses a simple, non-prescriptive interface, it's easy to swap out > yet still easy to use. > > That would mean the job of a unified agent framework would be to offer up > libraries to ease up the creation of the "API" class by offering Python > code to send messages in various styles / formats, as well as Python or C++ > code to read and interpret those messages. > > Of course, we'd still settle on one "default" (probably network based) > which would become the standard way of sending messages to guests so that > package maintainers, the Infra team, and newbies to OpenStack wouldn't have > to deal with dozens of different ways of doing things, but the important > thing is that other methods of communication would still be possible. > > Thanks, > > Tim > > > From: Dmitry Mescheryakov [mailto:dmescherya...@mirantis.com] > Sent: Thursday, December 19, 2013 7:15 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Heat] [Trove] [Savanna] [Oslo] Unified > Agents - what is the actual problem? > > I agree that enabling communication between guest and cloud service is a > common problem for most agent designs. The only exception is agent based on > hypervisor provided transport. But as far as I understand many people are > interested in network-based agent, so indeed we can start a thread (or > continue discussion in this on) on the problem. > > Dmitry > > 2013/12/19 Clint Byrum <cl...@fewbar.com> > So I've seen a lot of really great discussion of the unified agents, and > it has made me think a lot about the problem that we're trying to solve. > > I just wanted to reiterate that we should be trying to solve real problems > and not get distracted by doing things "right" or even "better". > > I actually think there are three problems to solve. > > * Private network guest to cloud service communication. > * Narrow scope highly responsive lean guest agents (Trove, Savanna). > * General purpose in-instance management agent (Heat). > > Since the private network guests problem is the only one they all share, > perhaps this is where the three projects should collaborate, and the > other pieces should be left to another discussion. > > Thoughts? > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev