Open Stack

Tim,

The unified agent we proposing is based on the following ideas:
  * 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.
  * the API is organized into modules which could be reused across
different projects.
  * there will be no single package: each project (Trove/Savanna/Others)
assembles its own agent based on API project needs.

I hope that covers your concerns.

Dmitry


2013/12/18 Tim Simpson <tim.simpson at rackspace.com>

>  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
>
> _______________________________________________
> 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/20131218/ed090929/attachment.html>