Open Stack

Excerpts from Tim Simpson's message of 2013-12-18 07:34:14 -0800:
> 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.
> 

"Them's fightin words". ;)

That is a very strong position to take. So I am going to hold your
statements of facts and assumptions to a very high standard below.

> 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.
>

"Would be larger..." - Please provide proof of that assumption or at least
a general hypothesis that we can test. Since nothing was agreed upon
anyway, I don't know how you came to that conclusion. I would suggest
that any agent framework be held to an extremely high standard for
footprint for this very reason.

> 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.
> 

Nobody has suggested writing an agent that does everything. A
framework for agents to build on is what has been suggested. In fact
I've specifically been arguing to keep it focused on facilitating
guest<->service communication and limiting its in-guest capabilities to
narrowly focused tasks.

> 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.
>

If Trove's communication method is in fact superior to all others,
then perhaps we should discuss using that in the unified agent framework.

Also I'd certainly be interested in hearing about whether or not you
think the C++ agent could made generic enough for any project to use.
That would be a nice win.