> 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:vishvana...@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 <ma...@redhat.com> wrote:
> 
> >
> > On Aug 26, 2013, at 4:06 PM, Edgar Magana <emag...@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 <gong...@unitedstack.com>
> >> Date: Monday, August 26, 2013 2:58 PM
> >> To: "Kyle Mestery (kmestery)" <kmest...@cisco.com>, Aaron Rosen
> <aro...@nicira.com>, Armando Migliaccio <amigliac...@vmware.com>, Akihiro 
> MOTOKI
> <amot...@gmail.com>, Edgar Magana <emag...@plumgrid.com>, Maru Newby
> <ma...@redhat.com>, Nachi Ueno <na...@nttmcl.com>, Salvatore Orlando
> <sorla...@nicira.com>, Sumit Naiksatam <sumit.naiksa...@bigswitch.com>, Mark
> McClain <mark.mccl...@dreamhost.com>, Gary Kotton <gkot...@vmware.com>, Robert
> Kukura <rkuk...@redhat.com>
> >> Cc: OpenStack List <openstack-dev@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) 
> >> <kmest...@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 <gong...@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@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to