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