Open Stack

>
​Well, this is part of the motivation behind this patch. If the default is
Linuxbridge, that is what
is being used in all the gate testing unless it it being explictly
overridden.​


The defaults and what is tested in the gate are independent. Devstack
defaults to Nova network and we don't test that at all in Neutron. :)

If this change were to go through, we would likely just adjust all of the
Neutron jobs to explicitly use OVS since that is what the current jobs are
testing and there hasn't been any agreement in the Neutron development
community to drop that. If one of your goals is gate coverage of
Linuxbridge, then explicitly propose another job to run with Neutron
patches based on Linuxbridge.

>Since DVR is not enabled by default anyway (or is it?), I don't think that
it will be much of an issue
if enabling it will now require changing two settings instead of one. ​

​But having that as a second step
after having done a successful initial deployment, will be a much better
experience for most users than having them fail in their first contact with
neutron already.​

That's a pretty abrupt change for users to go through. It's misleading to
start out with Linuxbridge so users become comfortable with that and then
tell them they have to redeploy everything with a different vswitch to get
distributed routing.

Can you give some examples of how users are failing in their first contact
with Neutron? The Neutron API is supposed to abstract away those
implementation details and devstack is supposed to make the initial OVS
install and setup simple. It seems like there is an issue with one of those
if people are having difficulty getting Neutron test deployments to work.
If those are broken, I don't see why using Linux bridge is supposed to help.



On Fri, Apr 10, 2015 at 1:34 AM, Jens Rosenboom <j.rosenboom at x-ion.de>
wrote:

> 2015-04-10 9:31 GMT+02:00 Kevin Benton <blak111 at gmail.com>:
>
>> I mentioned this in my email in the previous thread, but I am also
>> concerned about the use of the Linux bridge plugin as the default for
>> devstack.
>>
>> It will reflect poorly on the Neutron project because we are defaulting
>> to something that gets almost no development effort and that is not even
>> gated on (other than unit tests). This is a risky move that can damage
>> first-time users' opinions of the viability of OpenStack. I wouldn't feel
>> confident about something that has defaults that could be broken at any
>> time... even  during a release.
>>
>
> ​Well, this is part of the motivation behind this patch. If the default is
> Linuxbridge, that is what
> is being used in all the gate testing unless it it being explictly
> overridden.​
>
>
>> Can someone point me to the list of complaints about OVS? I would rather
>> invest time in addressing those issues rather than ignoring everything a
>> good chunk of the neutron community has spent significant time on.
>>
>> If OVS really is a non-starter because of lack of tooling and lack of
>> deployer experience, we (the neutron community) will need to put
>> significantly more efforts into automated testing and feature parity (e.g.
>> re-implement DVR).
>>
> ​The idea is to make the entry level for using neutron networking as low
> as possible. Currently starting
> with neutron implicitly also requires starting with OVS, which is adding
> complexity that in a significant
> amount of environments is not needed. This probably includes most of the
> deployments that still cling to
> using nova-network, but also people looking at OpenStack for the first
> time.
>
> Since DVR is not enabled by default anyway (or is it?), I don't think that
> it will be much of an issue
> if enabling it will now require changing two settings instead of one. ​
>
> ​But having that as a second step
> after having done a successful initial deployment, will be a much better
> experience for most users than
> having them fail in their first contact with neutron already.​
>
> __________________________________________________________________________
> 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
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150410/f4278025/attachment.html>