<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 29, 2013 at 1:28 AM, Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.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="im"><br>
On Aug 26, 2013, at 6:14 PM, Maru Newby <<a href="mailto:marun@redhat.com">marun@redhat.com</a>> wrote:<br>
<br>
><br>
> On Aug 26, 2013, at 4:06 PM, Edgar Magana <<a href="mailto:emagana@plumgrid.com">emagana@plumgrid.com</a>> wrote:<br>
><br>
>> Hi Developers,<br>
>><br>
>> Let me explain my point of view on this topic and please share your thoughts in order to merge this new feature ASAP.<br>
>><br>
>> My understanding is that multi-host is nova-network HA  and we are implementing this bp <a href="https://blueprints.launchpad.net/neutron/+spec/quantum-multihost" target="_blank">https://blueprints.launchpad.net/neutron/+spec/quantum-multihost</a> for the same reason.<br>

>> So, If in neutron configuration admin enables multi-host:<br>
>> etc/dhcp_agent.ini<br>
>><br>
>> # Support multi host networks<br>
>> # enable_multihost = False<br>
>><br>
>> Why do tenants needs to be aware of this? They should just create networks in the way they normally do and not by adding the "multihost" extension.<br>
><br>
> I was pretty confused until I looked at the nova-network HA doc [1].  The proposed design would seem to emulate nova-network's multi-host HA option, where it was necessary to both run nova-network on every compute node and create a network explicitly as multi-host.  I'm not sure why nova-network was implemented in this way, since it would appear that multi-host is basically all-or-nothing.  Once nova-network services are running on every compute node, what does it mean to create a network that is not multi-host?<br>

<br>
</div>Just to add a little background to the nova-network multi-host: The fact that the multi_host flag is stored per-network as opposed to a configuration was an implementation detail. While in theory this would support configurations where some networks are multi_host and other ones are not, I am not aware of any deployments where both are used together.<br>

<br>
That said, If there is potential value in offering both, it seems like it should be under the control of the deployer not the user. In other words the deployer should be able to set the default network type and enforce whether setting the type is exposed to the user at all.<br>
</blockquote><div>yes, the default is not multihost, admin (by policy) can set up multihost network </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, one final point. In my mind, multi-host is strictly better than single host, if I were to redesign nova-network today, I would get rid of the single host mode completely.<br>
<br></blockquote><div>problem is: the current design of neutron is single host already (If I get your point). To do multihost automatically, it needs much effort .</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Vish<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> So, to Edgar's question - is there a reason other than 'be like nova-network' for requiring neutron multi-host to be configured per-network?<br>
><br>
><br>
> m.<br>
><br>
> 1: <a href="http://docs.openstack.org/trunk/openstack-compute/admin/content/existing-ha-networking-options.html" target="_blank">http://docs.openstack.org/trunk/openstack-compute/admin/content/existing-ha-networking-options.html</a><br>

><br>
><br>
>> I could be totally wrong and crazy, so please provide some feedback.<br>
>><br>
>> Thanks,<br>
>><br>
>> Edgar<br>
>><br>
>><br>
>> From: Yongsheng Gong <<a href="mailto:gongysh@unitedstack.com">gongysh@unitedstack.com</a>><br>
>> Date: Monday, August 26, 2013 2:58 PM<br>
>> To: "Kyle Mestery (kmestery)" <<a href="mailto:kmestery@cisco.com">kmestery@cisco.com</a>>, Aaron Rosen <<a href="mailto:arosen@nicira.com">arosen@nicira.com</a>>, Armando Migliaccio <<a href="mailto:amigliaccio@vmware.com">amigliaccio@vmware.com</a>>, Akihiro MOTOKI <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>>, Edgar Magana <<a href="mailto:emagana@plumgrid.com">emagana@plumgrid.com</a>>, Maru Newby <<a href="mailto:marun@redhat.com">marun@redhat.com</a>>, Nachi Ueno <<a href="mailto:nachi@nttmcl.com">nachi@nttmcl.com</a>>, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>>, Sumit Naiksatam <<a href="mailto:sumit.naiksatam@bigswitch.com">sumit.naiksatam@bigswitch.com</a>>, Mark McClain <<a href="mailto:mark.mcclain@dreamhost.com">mark.mcclain@dreamhost.com</a>>, Gary Kotton <<a href="mailto:gkotton@vmware.com">gkotton@vmware.com</a>>, Robert Kukura <<a href="mailto:rkukura@redhat.com">rkukura@redhat.com</a>><br>

>> Cc: OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: About multihost patch review<br>
>><br>
>> Hi,<br>
>> Edgar Magana has commented to say:<br>
>> 'This is the part that for me is confusing and I will need some clarification from the community. Do we expect to have the multi-host feature as an extension or something that will natural work as long as the deployment include more than one Network Node. In my opinion, Neutron deployments with more than one Network Node by default should call DHCP agents in all those nodes without the need to use an extension. If the community has decided to do this by extensions, then I am fine' at<br>

>> <a href="https://review.openstack.org/#/c/37919/11/neutron/extensions/multihostnetwork.py" target="_blank">https://review.openstack.org/#/c/37919/11/neutron/extensions/multihostnetwork.py</a><br>
>><br>
>> I have commented back, what is your opinion about it?<br>
>><br>
>> Regards,<br>
>> Yong Sheng Gong<br>
>><br>
>><br>
>> On Fri, Aug 16, 2013 at 9:28 PM, Kyle Mestery (kmestery) <<a href="mailto:kmestery@cisco.com">kmestery@cisco.com</a>> wrote:<br>
>>> Hi Yong:<br>
>>><br>
>>> I'll review this and try it out today.<br>
>>><br>
>>> Thanks,<br>
>>> Kyle<br>
>>><br>
>>> On Aug 15, 2013, at 10:01 PM, Yongsheng Gong <<a href="mailto:gongysh@unitedstack.com">gongysh@unitedstack.com</a>> wrote:<br>
>>><br>
>>>> The multihost patch is there for a long long time, can someone help to review?<br>
>>>> <a href="https://review.openstack.org/#/c/37919/" target="_blank">https://review.openstack.org/#/c/37919/</a><br>
>>><br>
>><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<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>
_______________________________________________<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></div>