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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
