<div dir="ltr">Tim, we definitely don't want to force projects to migrate to the unified agent. I've started making the PoC with the idea that Savanna needs the agent anyway, and we want it to be ready for Icehouse. On the other side, I believe, it will be much easier to drive the discussion further with the PoC ready, as we will have something material to talk over.<div>
<br></div><div>Dmitry</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/18 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>
<div style="direction:ltr;font-size:10pt;font-family:Tahoma">Thanks for the summary Dmitry. I'm ok with these ideas, and while I still disagree with having a single, forced standard for RPC communication, I should probably let things pan
out a bit before being too concerned.<br>
<br>
- Tim<br>
<br>
<br>
<div style="font-size:16px;font-family:Times New Roman">
<hr>
<div style="direction:ltr"><font color="#000000" face="Tahoma"><b>From:</b> Dmitry Mescheryakov [<a href="mailto:dmescheryakov@mirantis.com" target="_blank">dmescheryakov@mirantis.com</a>]<br>
<b>Sent:</b> Wednesday, December 18, 2013 11:51 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<div class="im"><br>
<b>Subject:</b> Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent<br>
</div></font><br>
</div><div><div class="h5">
<div></div>
<div>
<div dir="ltr">Tim,
<div><br>
</div>
<div>The unified agent we proposing is based on the following ideas:</div>
<div> * the core agent has _no_ functionality at all. It is a pure RPC mechanism with the ability to add whichever API needed on top of it.</div>
<div> * the API is organized into modules which could be reused across different projects.</div>
<div> * there will be no single package: each project (Trove/Savanna/Others) assembles its own agent based on API project needs.</div>
<div><br>
</div>
<div>I hope that covers your concerns.</div>
<div><br>
</div>
<div>Dmitry</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2013/12/18 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>
<div style="direction:ltr;font-size:10pt;font-family:Tahoma"><font color="black" face="Tahoma"><span dir="ltr" style="font-size:10pt">I've been following the Unified Agent mailing list thread for awhile now and, as someone who has written a fair amount of
code for both of the two existing Trove agents, thought I should give my opinion about it. I like the idea of a unified agent, but believe that forcing Trove to adopt this agent for use as its by default will stifle innovation and harm the project.<br>
<br>
There are reasons Trove has more than one agent currently. While everyone knows about the "Reference Agent" written in Python, Rackspace uses a different agent written in C++ because it takes up less memory. The concerns which led to the C++ agent would not
be addressed by a unified agent, which if anything would be larger than the Reference Agent is currently.<br>
<br>
I also believe a unified agent represents the wrong approach philosophically. An agent by design needs to be lightweight, capable of doing exactly what it needs to and no more. This is especially true for a project like Trove whose goal is to not to provide
overly general PAAS capabilities but simply installation and maintenance of different datastores. Currently, the Trove daemons handle most logic and leave the agents themselves to do relatively little. This takes some effort as many of the first iterations
of Trove features have too much logic put into the guest agents. However through perseverance the subsequent designs are usually cleaner and simpler to follow. A community approved, "do everything" agent would endorse the wrong balance and lead to developers
piling up logic on the guest side. Over time, features would become dependent on the Unified Agent, making it impossible to run or even contemplate light-weight agents.<br>
<br>
Trove's interface to agents today is fairly loose and could stand to be made stricter. However, it is flexible and works well enough. Essentially, the duck typed interface of the trove.guestagent.api.API class is used to send messages, and Trove conductor is
used to receive them at which point it updates the database. Because both of these components can be swapped out if necessary, the code could support the Unified Agent when it appears as well as future agents.
<br>
<br>
It would be a mistake however to alter Trove's standard method of communication to please the new Unified Agent. In general, we should try to keep Trove speaking to guest agents in Trove's terms alone to prevent bloat.<br>
<br>
Thanks,<br>
<br>
Tim </span></font></div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</blockquote>
</div>
<br>
</div>
</div>
</div></div></div>
</div>
</div>
<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></blockquote></div><br></div>