<div dir="ltr">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.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/12 Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Excerpts from Dmitry Mescheryakov's message of 2013-12-12 09:24:13 -0800:<br>
<div class="im">> Clint, Kevin,<br>
><br>
> Thanks for reassuring me :-) I just wanted to make sure that having direct<br>
> access from VMs to a single facility is not a dead end in terms of security<br>
> and extensibility. And since it is not, I agree it is much simpler (and<br>
> hence better) than hypervisor-dependent design.<br>
><br>
><br>
> Then returning to two major suggestions made:<br>
>  * Salt<br>
>  * Custom solution specific to our needs<br>
><br>
> The custom solution could be made on top of oslo.messaging. That gives us<br>
> RPC working on different messaging systems. And that is what we really need<br>
> - an RPC into guest supporting various transports. What it lacks at the<br>
> moment is security - it has neither authentication nor ACL.<br>
><br>
<br>
</div>I bet salt would be super open to modularizing their RPC. Since<br>
oslo.messaging includes ZeroMQ, and is a library now, I see no reason to<br>
avoid opening that subject with our fine friends in the Salt community.<br>
Perhaps a few of them are even paying attention right here. :)<br>
<br>
The benefit there is that we get everything except the plugins we want<br>
to write already done. And we could start now with the ZeroMQ-only<br>
salt agent if we could at least get an agreement on principle that Salt<br>
wouldn't mind using an abstraction layer for RPC.<br>
<br>
That does make the "poke a hole out of private networks" conversation<br>
_slightly_ more complex. It is one thing to just let ZeroMQ out, another<br>
to let all of oslo.messaging's backends out. But I think in general<br>
they'll all share the same thing: you want an address+port to be routed<br>
intelligently out of the private network into something running under<br>
the cloud.<br>
<br>
Next steps (all can be done in parallel, as all are interdependent):<br>
<br>
* Ask Salt if oslo.messaging is a path they'll walk with us<br>
* Experiment with communicating with salt agents from an existing<br>
  OpenStack service (Savanna, Trove, Heat, etc)<br>
* Deep-dive into Salt to see if it is feasible<br>
<br>
As I have no cycles for this, I can't promise to do any, but I will<br>
try to offer assistance if I can.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>