On 12/18/2013 08:34 AM, Tim Simpson wrote:
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.
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.
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.
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.
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.
Thanks,
Tim
Tim,
You raise very valid points that I'll summarize into bullet points:
* memory footprint of a python-based agent
* guest-agent feature bloat with no clear path to refactoring
* an agent should do one thing and do it well
The competing viewpoint is from downstream:
* How do you get those various agents into the various linux
distributions cloud images and maintain them
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".
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.
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.
Regards
-steve
_______________________________________________
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