Open Stack

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.simpson at 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:dmescheryakov at 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 <clint at 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131219/bfbe45a3/attachment.html>