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.
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!
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...
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 :)
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.
Regards
-steve
_______________________________________________
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
