Open Stack

On 03/30/2015 09:25 AM, Assaf Muller wrote:
> 
> 
> ----- Original Message -----
>> On 03/27/2015 11:48 AM, Assaf Muller wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> On 03/27/2015 05:22 AM, Thierry Carrez wrote:
>>>> <snip>
>>>>> Part of it is corner (or simplified) use cases not being optimally
>>>>> served by Neutron, and I think Neutron could more aggressively address
>>>>> those. But the other part is ignorance and convenience: that Neutron
>>>>> thing is a scary beast, last time I looked into it I couldn't make sense
>>>>> of it, and nova-network just works for me.
>>>>>
>>>>> That is why during the Ops Summit we discussed coming up with a
>>>>> migration guide that would explain the various ways you can use Neutron
>>>>> to cover nova-network use cases, demystify a few dark areas, and outline
>>>>> the step-by-step manual process you can go through to migrate from one
>>>>> to the other.
>>>>>
>>>>> We found a dev/ops volunteer for writing that migration guide but he was
>>>>> unfortunately not allowed to spend time on this. I heard we have new
>>>>> volunteers, but I'll let them announce what their plans are, rather than
>>>>> put words in their mouth.
>>>>>
>>>>> This migration guide can happen even if we follow the nova-net spinout
>>>>> plan (for the few who want to migrate to Neutron), so this is a
>>>>> complementary solution rather than an alternative. Personally I doubt
>>>>> there would suddenly be enough people interested in nova-net development
>>>>> to successfully spin it out and maintain it. I also agree with Russell
>>>>> that long-term fragmentation at this layer of the stack is generally not
>>>>> desirable.
>>>>
>>>> I think if you boil everything down, you end up with 3 really important
>>>> differences.
>>>>
>>>> 1) neutron is a fleet of services (it's very micro service) and every
>>>> service requires multiple and different config files. Just configuring
>>>> the fleet is a beast if it not devstack (and even if it is)
>>>>
>>>> 2) neutron assumes a primary interesting thing to you is tenant secured
>>>> self service networks. This is actually explicitly not interesting to a
>>>> lot of deploys for policy, security, political reasons/restrictions.
>>>>
>>>> 3) neutron open source backend defaults to OVS (largely because #2). OVS
>>>> is it's own complicated engine that you need to learn to debug. While
>>>> Linux bridge has challenges, it's also something that anyone who's
>>>> worked with Linux & Virtualization for the last 10 years has some
>>>> experience with.
>>>>
>>>> (also, the devstack setup code for neutron is a rats nest, as it was
>>>> mostly not paid attention to. This means it's been 0 help in explaining
>>>> anything to people trying to do neutron. For better or worse devstack is
>>>> our executable manual for a lot of these things)
>>>>
>>>> so.... that being said, I think we need to talk about "minimum viable
>>>> neutron" as a model and figure out how far away that is from n-net. This
>>>> week at the QA Sprint, Dean, Sean Collins, and I have spent some time
>>>> hashing it out, hopefully with something to show the end of the week.
>>>> This will be the new devstack code for neutron (the old lib/neutron is
>>>> moved to lib/neutron-legacy).
>>>>
>>>> Default setup will be provider networks (which means no tenant
>>>> isolation). For that you should only need neutron-api, -dhcp, and -l2.
>>>> So #1 is made a bunch better. #2 not a thing at all. And for #3 we'd
>>>> like to revert back to linux bridge for the base case (though first code
>>>> will probably be OVS because that's the happy path today).
>>>>
>>>
>>> Looking at the latest user survey, OVS looks to be 3 times as popular as
>>> Linux bridge for production deployments. Having LB as the default seems
>>> like an odd choice. You also wouldn't want to change the default before
>>> LB is tested at the gate.
>>
>> Sure, actually testing defaults is presumed here. I didn't think it
>> needed to be called out separately.
> 
> Quick update about OVS vs LB:
> Sean M. Collins pushed up a patch that runs CI on Tempest with LB:
> https://review.openstack.org/#/c/168423/
> 
> So far it's failing pretty badly.
That is the nature of development.

Let's also note that is patchset 1 of a patch marked work in progress.

If we start to make decisions about whether or not a direction is a
reasonable direction on a patch which is expected to fail this early in
the development process we serious injure our ability to foster development.

Please understand and respect the development process prior to expecting
others to make decisions prematurely.

Thank you,
Anita.
> 
>>
>> 	-Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>>
>> __________________________________________________________________________
>> 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
>