Open Stack

Excerpts from Isaku Yamahata's message of 2014-04-09 01:33:49 -0700:
> 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.
> 

Hi Isaku. I like that you are bringing some new energy into this
discussion.

What if we swapped your local socket out for a connection managed by
something similar to the neutron metadata agent that forwards connections
to the EC2 metadata service? I could see a scheme something like this:

- guest boots, agent contacts link-local on port 80 with a REST request
  for a communication channel to service XYZ.
- metadata agent is allocated a port on the network of the agent and
  proxies that port to the intended endpoint.
- guest now communicates directly with that address, still nicely
  confined to the private network without any sort of gateway, but with
  an ability to talk to "under the cloud" services.

I prefer a scheme that uses the network because it will be generically
usable no matter the transport desired (marconi, amqp, 0mq, whatever)
and is directly modeled in Neutron's terms, rather than requiring tight
coupling with Nova and the hypervisors.