<div dir="ltr"><div>Tim,</div><div><br></div><div>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. </div>
<div><br></div><div>Dmitry</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/19 Tim Simpson <span dir="ltr"><<a href="mailto:tim.simpson@rackspace.com" target="_blank">tim.simpson@rackspace.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">>> 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.<br>
<br>
</div>Can't they co-exist?<br>
<br>
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".<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
<br>
Tim<br>
<br>
<br>
From: Dmitry Mescheryakov [mailto:<a href="mailto:dmescheryakov@mirantis.com">dmescheryakov@mirantis.com</a>]<br>
Sent: Thursday, December 19, 2013 7:15 AM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] [Heat] [Trove] [Savanna] [Oslo] Unified Agents - what is the actual problem?<br>
<div class="HOEnZb"><div class="h5"><br>
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.<br>
<br>
Dmitry<br>
<br>
2013/12/19 Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><br>
So I've seen a lot of really great discussion of the unified agents, and<br>
it has made me think a lot about the problem that we're trying to solve.<br>
<br>
I just wanted to reiterate that we should be trying to solve real problems<br>
and not get distracted by doing things "right" or even "better".<br>
<br>
I actually think there are three problems to solve.<br>
<br>
* Private network guest to cloud service communication.<br>
* Narrow scope highly responsive lean guest agents (Trove, Savanna).<br>
* General purpose in-instance management agent (Heat).<br>
<br>
Since the private network guests problem is the only one they all share,<br>
perhaps this is where the three projects should collaborate, and the<br>
other pieces should be left to another discussion.<br>
<br>
Thoughts?<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>