<div dir="ltr">Thanks for the explanation. Now I'm seeing how it works.<div><div>So the assumption is </div></div><div>- VMs are required to be on a tenant network connected to public network so that it can reach openstack public REST API</div>
<div><br></div><div>Is this a widely acceptable assumption? acceptable for NFV use case?</div><div>I'm not sure for now, I'd like to hear from others.</div><div>So far I've assumed that people may want VMs on a tenant network that is not connected to public network(isolated tenant network)</div>
<div><br></div><div>Thanks,</div><div>Isaku Yamahata</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 10, 2014 at 1:45 AM, Dmitry Mescheryakov <span dir="ltr"><<a href="mailto:dmescheryakov@mirantis.com" target="_blank">dmescheryakov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> I agree those arguments.<br>
> But I don't see how network-based agent approach works with Neutron<br>
> network for now. Can you please elaborate on it?<br>
<br>
</div>Here is the scheme of network-based agent:<br>
<div class=""><br>
server <-> MQ (Marconi) <-> agent<br>
<br>
</div>As Doug said, Marconi exposes REST API, just like any other OpenStack<br>
service. The services it provides are similar to the MQ ones (Rabbit<br>
MQ, Qpid, etc.). I.e. very simply there are methods:<br>
 * put_message(queue_name, message_payload)<br>
 * get_message(queue_name)<br>
<br>
Multi-tenancy is provided by the same means as in the other OpenStack<br>
projects - user supplies Keystone token in the request and it<br>
determines the tenant used.<br>
<br>
As for the network, a networking-based agent requires tcp connection<br>
to Marconi. I.e. you need an agent running on the VM to be able to<br>
connect to Marconi, but not vice versa. That does not sound like a<br>
harsh requirement.<br>
<br>
The standard MQ solutions like Rabbit and Qpid actually could be used<br>
here instead of Marconi with one drawback - it is really hard to<br>
reliably implement tenant isolation with them.<br>
<br>
Thanks,<br>
<br>
Dmitry<br>
<br>
2014-04-09 17:38 GMT+04:00 Isaku Yamahata <<a href="mailto:isaku.yamahata@gmail.com">isaku.yamahata@gmail.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> Hello Dmitry. Thank you for reply.<br>
><br>
> On Wed, Apr 09, 2014 at 03:19:10PM +0400,<br>
> Dmitry Mescheryakov <<a href="mailto:dmescheryakov@mirantis.com">dmescheryakov@mirantis.com</a>> wrote:<br>
><br>
>> Hello Isaku,<br>
>><br>
>> Thanks for sharing this! Right now in Sahara project we think to use<br>
>> Marconi as a mean to communicate with VM. Seems like you are familiar<br>
>> with the discussions happened so far. If not, please see links at the<br>
>> bottom of UnifiedGuestAgent [1] wiki page. In short we see Marconi's<br>
>> supports for multi-tenancy as a huge advantage over other MQ<br>
>> solutions. Our agent is network-based, so tenant isolation is a real<br>
>> issue here. For clarity, here is the overview scheme of network based<br>
>> agent:<br>
>><br>
>> server <-> MQ (Marconi) <-> agent<br>
>><br>
>> All communication goes over network. I've made a PoC of the Marconi<br>
>> driver for oslo.messaging, you can find it at [2]<br>
><br>
> I'm not familiar with Marconi, so please enlighten me first.<br>
> How does MQ(Marconi) communicates both to management network and<br>
> tenant network?<br>
> Does it work with Neutron network? not nova-network.<br>
><br>
> Neutron network isolates not only tenant networks each other,<br>
> but also management network at L2. So openstack servers can't send<br>
> any packets to VMs. VMs can't to openstack servers.<br>
> This is the reason why neutron introduced HTTP proxy for instance metadata.<br>
> It is also the reason why I choose to introduce new agent on host.<br>
> If Marconi (or other porjects like sahara) already solved those issues,<br>
> that's great.<br>
><br>
><br>
>> We also considered 'hypervisor-dependent' agents (as I called them in<br>
>> the initial thread) like the one you propose. They also provide tenant<br>
>> isolation. But the drawback is _much_ bigger development cost and more<br>
>> fragile and complex deployment.<br>
>><br>
>> In case of network-based agent all the code is<br>
>>  * Marconi driver for RPC library (oslo.messaging)<br>
>>  * thin client for server to make calls<br>
>>  * a guest agent with thin server-side<br>
>> If you write your agent on python, it will work on any OS with any<br>
>> host hypervisor.<br>
>><br>
>><br>
>> For hypervisor dependent-agent it becomes much more complex. You need<br>
>> one more additional component - a proxy-agent running on Compute host,<br>
>> which makes deployment harder. You also need to support various<br>
>> transports for various hypervisors: virtio-serial for KVM, XenStore<br>
>> for Xen, something for Hyper-V, etc. Moreover guest OS must have<br>
>> driver for these transports and you will probably need to write<br>
>> different implementation for different OSes.<br>
>><br>
>> Also you mention that in some cases a second proxy-agent is needed and<br>
>> again in some cases only cast operations could be used. Using cast<br>
>> only is not an option for Sahara, as we do need feedback from the<br>
>> agent and sometimes getting the return value is the main reason to<br>
>> make an RPC call.<br>
>><br>
>> I didn't see a discussion in Neutron on which approach to use (if it<br>
>> was, I missed it). I see simplicity of network-based agent as a huge<br>
>> advantage. Could you please clarify why you've picked design depending<br>
>> on hypervisor?<br>
><br>
> I agree those arguments.<br>
> But I don't see how network-based agent approach works with Neutron<br>
> network for now. Can you please elaborate on it?<br>
><br>
><br>
> thanks,<br>
><br>
><br>
>> Thanks,<br>
>><br>
>> Dmitry<br>
>><br>
>><br>
>> [1] <a href="https://wiki.openstack.org/wiki/UnifiedGuestAgent" target="_blank">https://wiki.openstack.org/wiki/UnifiedGuestAgent</a><br>
>> [2] <a href="https://github.com/dmitrymex/oslo.messaging" target="_blank">https://github.com/dmitrymex/oslo.messaging</a><br>
>><br>
>> 2014-04-09 12:33 GMT+04:00 Isaku Yamahata <<a href="mailto:isaku.yamahata@gmail.com">isaku.yamahata@gmail.com</a>>:<br>
>> > Hello developers.<br>
>> ><br>
>> ><br>
>> > As discussed many times so far[1], there are many projects that needs<br>
>> > to propagate RPC messages into VMs running on OpenStack. Neutron in my case.<br>
>> ><br>
>> > My idea is to relay RPC messages from management network into tenant<br>
>> > network over file-like object. By file-like object, I mean virtio-serial,<br>
>> > unix domain socket, unix pipe and so on.<br>
>> > I've wrote some code based on oslo.messaging[2][3] and a documentation<br>
>> > on use cases.[4][5]<br>
>> > Only file-like transport and proxying messages would be in oslo.messaging<br>
>> > and agent side code wouldn't be a part of oslo.messaging.<br>
>> ><br>
>> ><br>
>> > use cases:([5] for more figures)<br>
>> > file-like object: virtio-serial, unix domain socket, unix pipe<br>
>> ><br>
>> >   server <-> AMQP <-> agent in host <-virtio serial-> guest agent in VM<br>
>> >                       per VM<br>
>> ><br>
>> >   server <-> AMQP <-> agent in host <-unix socket/pipe-><br>
>> >              agent in tenant network <-> guest agent in VM<br>
>> ><br>
>> ><br>
>> > So far there are security concerns to forward oslo.messaging from management<br>
>> > network into tenant network. One approach is to allow only cast-RPC from<br>
>> > server to guest agent in VM so that guest agent in VM only receives messages<br>
>> > and can't send anything to servers. With unix pipe, it's write-only<br>
>> > for server, read-only for guest agent.<br>
>> ><br>
>> ><br>
>> > Thoughts? comments?<br>
>> ><br>
>> ><br>
>> > Details of Neutron NFV use case[6]:<br>
>> > Neutron services so far typically runs agents in host, the host agent<br>
>> > in host receives RPCs from neutron server, then it executes necessary<br>
>> > operations. Sometimes the agent in host issues RPC to neutron server<br>
>> > periodically.(e.g. status report etc)<br>
>> > It's desirable to make such services virtualized as Network Function<br>
>> > Virtualizaton(NFV), i.e. make those features run in VMs. So it's quite<br>
>> > natural approach to propagate those RPC message into agents into VMs.<br>
>> ><br>
>> ><br>
>> > [1] <a href="https://wiki.openstack.org/wiki/UnifiedGuestAgent" target="_blank">https://wiki.openstack.org/wiki/UnifiedGuestAgent</a><br>
>> > [2] <a href="https://review.openstack.org/#/c/77862/" target="_blank">https://review.openstack.org/#/c/77862/</a><br>
>> > [3] <a href="https://review.openstack.org/#/c/77863/" target="_blank">https://review.openstack.org/#/c/77863/</a><br>
>> > [4] <a href="https://blueprints.launchpad.net/oslo.messaging/+spec/message-proxy-server" target="_blank">https://blueprints.launchpad.net/oslo.messaging/+spec/message-proxy-server</a><br>
>> > [5] <a href="https://wiki.openstack.org/wiki/Oslo/blueprints/message-proxy-server" target="_blank">https://wiki.openstack.org/wiki/Oslo/blueprints/message-proxy-server</a><br>
>> > [6] <a href="https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms" target="_blank">https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms</a><br>
>> > --<br>
>> > Isaku Yamahata <<a href="mailto:isaku.yamahata@gmail.com">isaku.yamahata@gmail.com</a>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> --<br>
> Isaku Yamahata <<a href="mailto:isaku.yamahata@gmail.com">isaku.yamahata@gmail.com</a>><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>