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

2014-04-09 Thread Isaku Yamahata
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

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

2014-04-09 Thread Dmitry Mescheryakov
Hello Isaku, Thanks for sharing this! Right now in Sahara project we think to use Marconi as a mean to communicate with VM. Seems like you are familiar with the discussions happened so far. If not, please see links at the bottom of UnifiedGuestAgent [1] wiki page. In short we see Marconi's

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

2014-04-09 Thread Isaku Yamahata
Hello Dmitry. Thank you for reply. On Wed, Apr 09, 2014 at 03:19:10PM +0400, Dmitry Mescheryakov dmescherya...@mirantis.com wrote: Hello Isaku, Thanks for sharing this! Right now in Sahara project we think to use Marconi as a mean to communicate with VM. Seems like you are familiar with

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

2014-04-09 Thread Doug Hellmann
On Wed, Apr 9, 2014 at 9:38 AM, Isaku Yamahata isaku.yamah...@gmail.com wrote: Hello Dmitry. Thank you for reply. On Wed, Apr 09, 2014 at 03:19:10PM +0400, Dmitry Mescheryakov dmescherya...@mirantis.com wrote: Hello Isaku, Thanks for sharing this! Right now in Sahara project we think to

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

2014-04-09 Thread Mark McLoughlin
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

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

2014-04-09 Thread Dmitry Mescheryakov
I agree those arguments. But I don't see how network-based agent approach works with Neutron network for now. Can you please elaborate on it? Here is the scheme of network-based agent: server - MQ (Marconi) - agent As Doug said, Marconi exposes REST API, just like any other OpenStack

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

2014-04-09 Thread Daniel P. Berrange
On Wed, Apr 09, 2014 at 05:33:49PM +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

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

2014-04-09 Thread Clint Byrum
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

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

2014-04-09 Thread i y
Thanks for the explanation. Now I'm seeing how it works. So the assumption is - VMs are required to be on a tenant network connected to public network so that it can reach openstack public REST API Is this a widely acceptable assumption? acceptable for NFV use case? I'm not sure for now, I'd like

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

2014-04-09 Thread isaku yamahata
Also, how are you proposing to deal with live migration of VMs ? The virtio serial channel can get closed due to QEMU migrating while the proxy is in the middle of sending data to the guest VM, potentially causing a lost or mangled message in the guest and the sender won't know this if this