[openstack-dev] [olso][neutron] proxying oslo.messaging from management network into tenant network/VMs

Mark McLoughlin markmc at redhat.com
Wed Apr 9 15:42:43 UTC 2014


Hi,

On Wed, 2014-04-09 at 17:33 +0900, Isaku Yamahata wrote:
> Hello developers.
> 
> 
> As discussed many times so far[1], there are many projects that needs
> to propagate RPC messages into VMs running on OpenStack. Neutron in my case.
> 
> My idea is to relay RPC messages from management network into tenant
> network over file-like object. By file-like object, I mean virtio-serial,
> unix domain socket, unix pipe and so on.
> I've wrote some code based on oslo.messaging[2][3] and a documentation
> on use cases.[4][5]
> Only file-like transport and proxying messages would be in oslo.messaging
> and agent side code wouldn't be a part of oslo.messaging.
> 
> 
> use cases:([5] for more figures)
> file-like object: virtio-serial, unix domain socket, unix pipe
> 
>   server <-> AMQP <-> agent in host <-virtio serial-> guest agent in VM
>                       per VM
> 
>   server <-> AMQP <-> agent in host <-unix socket/pipe->
>              agent in tenant network <-> guest agent in VM
> 
> 
> So far there are security concerns to forward oslo.messaging from management
> network into tenant network. One approach is to allow only cast-RPC from
> server to guest agent in VM so that guest agent in VM only receives messages
> and can't send anything to servers. With unix pipe, it's write-only
> for server, read-only for guest agent.
> 
> 
> Thoughts? comments?

Nice work. This is a pretty gnarly topic, but I think you're doing a
good job thinking through a good solution here.

The advantage this has over Marconi is that it avoids relying on
something which might not be commonplace in OpenStack deployments for a
number of releases yet.

Using vmchannel/virtio-serial to talk to an oslo.messaging proxy server
(with would have a configurable security policy) over a unix socket
oslo.messaging transport in order to allow limited bridging from the
tenant network to management network ... definitely sounds like a
reasonable proposal.

Looking forward to your session at the summit! I also hope to look at
your patches before then.

Thanks,
Mark.



> 
> 
> Details of Neutron NFV use case[6]:
> Neutron services so far typically runs agents in host, the host agent
> in host receives RPCs from neutron server, then it executes necessary
> operations. Sometimes the agent in host issues RPC to neutron server
> periodically.(e.g. status report etc)
> It's desirable to make such services virtualized as Network Function
> Virtualizaton(NFV), i.e. make those features run in VMs. So it's quite
> natural approach to propagate those RPC message into agents into VMs.
> 
> 
> [1] https://wiki.openstack.org/wiki/UnifiedGuestAgent
> [2] https://review.openstack.org/#/c/77862/
> [3] https://review.openstack.org/#/c/77863/
> [4] https://blueprints.launchpad.net/oslo.messaging/+spec/message-proxy-server
> [5] https://wiki.openstack.org/wiki/Oslo/blueprints/message-proxy-server
> [6] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms





More information about the OpenStack-dev mailing list