[openstack-dev] About multihost patch review

McCann, Jack jack.mccann at hp.com
Wed Aug 28 21:48:19 UTC 2013


> 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.

+1

>From my perspective, multi-host is an option that should be in the hands
of the deployer/operator, not exposed to the end user.  My users should
not have to know or care how DHCP, routing and floating IPs are implemented
under the covers.

Also, last I looked, I think this patch required admin role to create a multi-host
network.  That may be OK for a single flat network or small-scale multi-network
environment, but it is not viable in a large-scale multi-tenant environment.

- Jack

> -----Original Message-----
> From: Vishvananda Ishaya [mailto:vishvananda at gmail.com]
> Sent: Wednesday, August 28, 2013 1:29 PM
> To: OpenStack Development Mailing List
> Cc: Robert Kukura; Armando Migliaccio; Nachi Ueno; Sumit Naiksatam
> Subject: Re: [openstack-dev] About multihost patch review
> 
> 
> On Aug 26, 2013, at 6:14 PM, 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?
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Vish
> 
> >
> > 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/
> >>>
> >>
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list