<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/18 Steven Dake <span dir="ltr"><<a href="mailto:sdake@redhat.com" target="_blank">sdake@redhat.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<div>On 12/18/2013 08:34 AM, Tim Simpson
wrote:<br>
</div>
<blockquote type="cite">
<div style="direction:ltr;font-size:10pt;font-family:Tahoma"><font color="black" face="Tahoma"><span style="font-size:10pt" dir="ltr">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>
</blockquote>
<br>
</div></div><font><font face="Tahoma">Tim,<br>
<br>
You raise very valid points that I'll summarize into bullet
points:<br>
* memory footprint of a python-based agent<br>
* guest-agent feature bloat with no clear path to refactoring<br>
* an agent should do one thing and do it well<br>
<br>
The competing viewpoint is from downstream:<br>
* How do you get those various agents into the various linux
distributions cloud images and maintain them<br>
<br>
A unified agent addresses the downstream viewpoint well, which
is "There is only one agent to package and maintain, and it
supports all the integrated OpenStack Program projects".<br>
<br>
Putting on my Fedora Hat for a moment, I'm not a big fan of an
agent per OpenStack project going into the Fedora 21 cloud
images.<br>
<br>
Another option that we really haven't discussed on this long
long thread is injecting the per-project agents into the vm on
bootstrapping of the vm. If we developed common code for this
sort of operation and placed it into oslo, *and* agreed to use
it as our common unifying mechanism of agent support, each
project would be free to ship whatever agents they wanted in
their packaging, use the proposed oslo.bootstrap code to
bootstrap the VM via cloudinit with the appropriate agents
installed in the proper locations, whamo, problem solved for
everyone.<br></font></font></div></blockquote><div><br></div><div>Funny thing is, the same idea was proposed and discussed among my colleagues and me recently. We saw it as a Heat extension which could be requested to inject guest agent into the VM. The list of required modules could be passed as a request parameter. That can ease life of us, Savanna devs, because we will not have to pre-install the agent on our images. </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><font><font face="Tahoma">
Regards<br>
-steve<br>
<br>
<br>
</font></font>
<blockquote type="cite">
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<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>
</pre>
</blockquote>
<br>
</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></div>