Open Stack

Someone's gotta make/maintain the trove/savanna images though. They usually are built from packages. If there is a unified agent, then it only has to be packaged once. If there is one per special type of agent, its one package per special type of agent. I don't think there is a free lunch here, just a question of who does the work.

Thanks,
Kevin
________________________________________
From: Clint Byrum [clint at fewbar.com]
Sent: Wednesday, December 18, 2013 9:38 AM
To: openstack-dev
Subject: Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

Excerpts from Steven Dake's message of 2013-12-18 08:05:09 -0800:
> 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
>

Only Heat cares about this. Trove and Savanna would be pretty silly if
they tried to run on general purpose images. IMO Heat shouldn't care
either and Heat operators should just make images that include Heat tools.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev