2013/12/18 Steven Dake <sd...@redhat.com> > 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. >
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. > Regards > -steve > > > > > > _______________________________________________ > OpenStack-dev mailing > listOpenStack-dev@lists.openstack.orghttp://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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
