Open Stack

First 'be like nova-network' is a merit for some deployments.
second, To allow admin to decide which network will be multihosted at
runtime will enable the neutron to continue using the current network node
(dhcp agent) mode at the same time.

If we force the network multihosted when the configuration enable_multihost
is true, and then administrator wants to transfer to normal neutron way,
he/she must modify the configuration item and then restart.



On Tue, Aug 27, 2013 at 9:14 AM, Maru Newby <marun at redhat.com> wrote:

>
> On Aug 26, 2013, at 4:06 PM, Edgar Magana <emagana at plumgrid.com> wrote:
>
> > Hi Developers,
> >
> > Let me explain my point of view on this topic and please share your
> thoughts in order to merge this new feature ASAP.
> >
> > My understanding is that multi-host is nova-network HA  and we are
> implementing this bp
> https://blueprints.launchpad.net/neutron/+spec/quantum-multihost for the
> same reason.
> > So, If in neutron configuration admin enables multi-host:
> > etc/dhcp_agent.ini
> >
> > # Support multi host networks
> > # enable_multihost = False
> >
> > 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.
>
> 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?
>
> 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?
>
>
> m.
>
> 1:
> http://docs.openstack.org/trunk/openstack-compute/admin/content/existing-ha-networking-options.html
>
>
> > I could be totally wrong and crazy, so please provide some feedback.
> >
> > Thanks,
> >
> > Edgar
> >
> >
> > From: Yongsheng Gong <gongysh at unitedstack.com>
> > Date: Monday, August 26, 2013 2:58 PM
> > To: "Kyle Mestery (kmestery)" <kmestery at cisco.com>, Aaron Rosen <
> arosen at nicira.com>, Armando Migliaccio <amigliaccio at vmware.com>, Akihiro
> MOTOKI <amotoki at gmail.com>, Edgar Magana <emagana at plumgrid.com>, Maru
> Newby <marun at redhat.com>, Nachi Ueno <nachi at nttmcl.com>, Salvatore
> Orlando <sorlando at nicira.com>, Sumit Naiksatam <
> sumit.naiksatam at bigswitch.com>, Mark McClain <mark.mcclain at dreamhost.com>,
> Gary Kotton <gkotton at vmware.com>, Robert Kukura <rkukura at redhat.com>
> > Cc: OpenStack List <openstack-dev at lists.openstack.org>
> > Subject: Re: About multihost patch review
> >
> > Hi,
> > Edgar Magana has commented to say:
> > '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
> >
> https://review.openstack.org/#/c/37919/11/neutron/extensions/multihostnetwork.py
> >
> > I have commented back, what is your opinion about it?
> >
> > Regards,
> > Yong Sheng Gong
> >
> >
> > On Fri, Aug 16, 2013 at 9:28 PM, Kyle Mestery (kmestery) <
> kmestery at cisco.com> wrote:
> >> Hi Yong:
> >>
> >> I'll review this and try it out today.
> >>
> >> Thanks,
> >> Kyle
> >>
> >> On Aug 15, 2013, at 10:01 PM, Yongsheng Gong <gongysh at unitedstack.com>
> wrote:
> >>
> >> > The multihost patch is there for a long long time, can someone help
> to review?
> >> > https://review.openstack.org/#/c/37919/
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130827/94db9002/attachment.html>