[openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

Hirofumi Ichihara ichihara.hirofumi at lab.ntt.co.jp
Thu Apr 16 02:51:06 UTC 2015


> 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?
Some openstacker doesn’t believe ovs performance is higher than linuxbridge.
So they don’t want to use OVS. Surely old OVS has many performance problems.
Currently, the problems almost might be solved. But they aren’t sure about it.
If that is a point of the discussion, we should show it to them.

In any case, we need to know why do they prefer linuxbridge rather than OVS.

Hirofumi

On 2015/04/16, at 11:09, Tom Fifield <tom at openstack.org> wrote:

> 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 at 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
>>> <mangelajo at redhat.com <mailto:mangelajo at 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
>>> dtroyer at gmail.com <mailto:dtroyer at gmail.com>
>>> 
>>> 
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150416/4cdc026b/attachment.html>


More information about the OpenStack-dev mailing list