Open Stack

Inline…


On Mar 27, 2015, at 11:48 AM, Assaf Muller <amuller at redhat.com> 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

3x as popular *with existing Neutron users* though.  Not people that are still running nova-net.  I think we have to bear in mind here that when we’re looking at user survey results we’re looking at a general audience of OpenStack users, and what we’re trying to solve on this thread is a specific subset of that audience.  The very fact that those people are still running nova-net may be a good indicator that they don’t find the Neutron choices that lots of other people have made to be a good fit for their particular use cases (else they’d have switched by now).  We got some reinforcement of this idea during discussion at the Operator’s Midcycle Meetup in Philadelphia: the feedback from nova-net users that I heard was that OVS+Neutron was too complicated and too hard to debug compared to what they have today, hence they didn’t find it a compelling option.  

Linux Bridge is, in the eyes of many folks in that room, a simpler model in terms of operating and debugging so I think it’s likely a very reasonable for this group of users.  However in the interest of ensuring that those operators have a chance to chime in here, I’ve added openstack-operators to the thread.

At Your Service,

Mark T. Voelker


> 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.
> 
>> Mixin #1: NEUTRON_BRIDGE_WITH=OVS
>> 
>> First optional layer being flip from linuxbridge -> ovs. That becomes
>> one bite sized thing to flip over once you understand it.
>> 
>> Mixin #2: self service networks
>> 
>> This will be off in the default case, but can be enabled later.
>> 
>> ... and turtles all the way up.
>> 
>> 
>> Provider networks w/ Linux bridge are really close to the simplicity on
>> the wire people expected with n-net. The only last really difference is
>> floating ips. And the problem here was best captured by Sean Collins on
>> Wed, Floating ips in nova are overloaded. They are both elastic ips, but
>> they are also how you get public addresses in a default environment.
>> Dean shared that that dual purpose is entirely due to constraints of the
>> first NASA cloud which only had a /26 of routable IPs. In neutron this
>> is just different, you don't need floating ips to have public addresses.
>> But the mental model has stuck.
>> 
>> 
>> Anyway, while I'm not sure this is going to solve everyone's issues, I
>> think it's a useful exercise anyway for devstack's neutron support to
>> revert to a minimum viable neutron for learning purposes, and let you
>> layer on complexity manually over time. And I'd be really curious if a
>> n-net -> provider network side step (still on linux bridge) would
>> actually be a more reasonable transition for most environments.
>> 
>> 	-Sean
>> 
>> --
>> Sean Dague
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__dague.net&d=AwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=sryIoYYzrwiRwGKFoWI_pMNmr5twlli1Pv-ocJbP_qs&s=-00m17xoYAO_GKkqE4YiLuUqGASjc0wREELtiReWGGA&e= 
>> 
>> 
>> __________________________________________________________________________
>> 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