[openstack-dev] Unified Guest Agent proposal

Clint Byrum clint at fewbar.com
Thu Dec 12 17:47:28 UTC 2013


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.



More information about the OpenStack-dev mailing list