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