Open Stack

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).

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
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150327/bfb401d3/attachment.pgp>