[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