[openstack-dev] Unified Guest Agent proposal

Clint Byrum clint at fewbar.com
Sun Dec 15 08:17:54 UTC 2013


Excerpts from Steven Dake's message of 2013-12-14 09:00:53 -0800:
> On 12/13/2013 01:13 PM, Clint Byrum wrote:
> > Excerpts from Dmitry Mescheryakov's message of 2013-12-13 12:01:01 -0800:
> >> Still, what about one more server process users will have to run? I see
> >> unified agent as library which can be easily adopted by both exiting and
> >> new OpenStack projects. The need to configure and maintain Salt server
> >> process is big burden for end users. That idea will definitely scare off
> >> adoption of the agent. And at the same time what are the gains of having
> >> that server process? I don't really see to many of them.
> >>
> 
> I tend to agree, I don't see a big advantage to using something like 
> salt, when the current extremely simplistic cfn-init + friends do the job.
> 
> What specific problem does salt solve?  I guess I missed that context in 
> this long thread.
> 

Yes you missed the crux of the thread. There is a need to have agents that
are _not_ general purpose like cfn-init and friends. They specifically
need to be narrow in focus and not give the higher level service operator
backdoor access to everything via SSH-like control.

Salt works with plugins and thus the general purpose backdoor features
can be disabled definitively by not having them present, and then
plugins for Trove/Savanna/et.al can be added. Since they are
operator-controlled services these exotic agent configurations will be
built into operator-controlled images.

For Heat, the advantage is that you get unified transport in/out of
private networks to a general purpose agent which matches the agent for
those higher level services.

> > The Salt devs already mentioned that we can more or less just import
> > salt's master code and run that inside the existing server processes. So
> > Savanna would have a salt master capability, and so would Heat Engine.
> I really don't think we want to introduce a salt executive into the heat 
> engine process address space, even if it is as simple as an import 
> operation.  Sounds like a debugging nightmare!
> 

Data is not that hard to collect in this case, so before we call this
complicated or a debugging nightmare I think a bit of discovery would
go a long way. Also the engine is not likely to be where this would be,
"existing server processes" also includes heat-api, which would make a
lot more sense in this case.

> > If it isn't eventlet friendly we can just fork it off and run it as its
> > own child. Still better than inventing our own.
> fork/exec is not the answer to scalability and availability I was 
> looking for :)  So, given that we need scale+availability, we are back 
> to managing a daemon outside the address space, which essentially 
> introduces another daemon to be scaled and ha-ified (and documented, 
> etc, see long zookeeper thread for my arguments against new server 
> processes...).  import is not the answer, or atleast it won't be for heat...
> 

Fork and run things that don't work well with eventlet does not mean fork
and _exec_. Also this is not to address scalability or availability. It
is to isolate code that does not behave exactly like the rest of our code.

> Salt just seems like more trouble then it is worth, but I don't totally 
> understand the rationale for introducing it as a dependency in this 
> case, and I generally think dependencies are evil :)
>

I generally think dependencies are efficient ways of consuming existing
code. Should we not use pecan? eventlet?

> What are we inventing our own again of?  cfn-init & friends already 
> exist, are dead simple, and have no need of anything beyond a metadata 
> server.  I would like to see that level of simplicity in any unified agent.
> 

Please do read the whole thread or at least the first message. We would
invent a framework for efficient agent communication and plugin based
actions. Right now there are several agents and none of them work quite
like the others but all have the same basic goals. This is only about Heat
because by adopting the same communication protocol we gain in-instance
orchestration in private networks.



More information about the OpenStack-dev mailing list