Open Stack

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.


2013/12/12 Clint Byrum <clint at fewbar.com>

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