"if linux bridge was a viable nova-network multi-host HA replacement, you'd be OK with this change?"
I'd be much more in favor of it. yes. Though I think its a long way from being there... planet openstack has a nice set of articles on how dvr works right now, and having read through, I think its going to be very difficult to implement that way with linuxbridge. It uses flow tables pretty heavily. LinuxBridge has nothing like that as far as I know. Because of that, I would expect that as DVR matures, the LinuxBridge implementation will wither further on the vine. :/ Just my 2 cents. Ops will probably need to consider the "complexity" necessary, just like the linux kernel is "complex" but in the end, the complexity is well worth it. To get a truly scalable NaaS, which I think is critical, you need advanced SDN and I'm not convinced LinuxBridge is advanced enough to work long term... Thanks, Kevin ________________________________________ From: Tom Fifield [t...@openstack.org] Sent: Wednesday, April 15, 2015 7:09 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 16/04/15 10:54, Fox, Kevin M wrote: > Yes, but.... if stuff like dvr is the only viable replacement to > nova-network in production, then learning the non representitive config > of neutron with linuxbridge might be misleading/counter productive since > ovs looks very very different. Sure, though on the other hand, doesn't current discussion seem to indicate that OVS with DVR is not a viable replacement for nova-network multi-host HA (eg due to complexity), and this is why folks were working towards linux bridge? In essence: if linux bridge was a viable nova-network multi-host HA replacement, you'd be OK with this change? > Kevin * > * > ------------------------------------------------------------------------ > *From:* Tom Fifield > *Sent:* Wednesday, April 15, 2015 5:58:43 PM > *To:* openstack-dev@lists.openstack.org > *Subject:* Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the > default in DevStack [was: Status of the nova-network to Neutron > migration work] > > > > On 14/04/15 23:36, Dean Troyer wrote: >> On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo >> <mangel...@redhat.com <mailto:mangel...@redhat.com>> wrote: >> >> Why would operators install from devstack? that’s not going to be >> the case. >> >> >> If they do they need more help than we can give... > > So, ummm, there is actually a valid use case for ops on devstack: it's > part of the learning process. > > In my rounds, I've had feedback from more than a few whose first > OpenStack experience was to run up a devstack, so they could run ps > aufx, brctl, iptables, etc just to see what was going on under the > covers before moving on to something more 'proper'. > > > While acknowledging that the primary purpose and audience of devstack is > and should remain development and developers, if there is something we > can do to improve the experience for those ops first-timers that doesn't > have a huge impact on devs, it would be kinda nice. > > After all, one of the reasons this thread exists is because of problems > with that ramp up process, no? > > >> >> I believe we should have both LB & OVS well tested, if LB is a good >> option for >> some operators willing to migrate from nova, that’s great, let’s >> make sure LB >> is perfectly tested upstream. >> >> >> +1 >> >> But by doing such change we can’t let OVS code rot and we would be >> neglecting >> a big customer base which is now making use of the openvswitch >> mechanism. >> (may be I’m miss understanding the scope of the change). >> >> >> Changing DevStack's default doesn't remove anything OVS-related, nor >> does it by itself remove any OVS jobs. It gives everyone who is happy >> with nova-net (or more correctly doesn't think about it) a new default >> that changes their experience the least for when nova-net disappears. >> >> dt >> >> -- >> >> Dean Troyer >> dtro...@gmail.com <mailto:dtro...@gmail.com> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev