<html><body>
<p><tt><font size="2">Sean Dague <sean@dague.net> wrote on 03/27/2015 07:11:18 AM:<br>
<br>
> From: Sean Dague <sean@dague.net></font></tt><br>
<tt><font size="2">> To: openstack-dev@lists.openstack.org</font></tt><br>
<tt><font size="2">> Date: 03/27/2015 07:12 AM</font></tt><br>
<tt><font size="2">> Subject: Re: [openstack-dev] [Nova][Neutron] Status of the nova-<br>
> network to Neutron migration work</font></tt><br>
<tt><font size="2">> <br>
> On 03/27/2015 05:22 AM, Thierry Carrez wrote:<br>
> <snip><br>
> > Part of it is corner (or simplified) use cases not being optimally<br>
> > served by Neutron, and I think Neutron could more aggressively address<br>
> > those. But the other part is ignorance and convenience: that Neutron<br>
> > thing is a scary beast, last time I looked into it I couldn't make sense<br>
> > of it, and nova-network just works for me.<br>
> > <br>
> > That is why during the Ops Summit we discussed coming up with a<br>
> > migration guide that would explain the various ways you can use Neutron<br>
> > to cover nova-network use cases, demystify a few dark areas, and outline<br>
> > the step-by-step manual process you can go through to migrate from one<br>
> > to the other.<br>
> > <br>
> > We found a dev/ops volunteer for writing that migration guide but he was<br>
> > unfortunately not allowed to spend time on this. I heard we have new<br>
> > volunteers, but I'll let them announce what their plans are, rather than<br>
> > put words in their mouth.<br>
> > <br>
> > This migration guide can happen even if we follow the nova-net spinout<br>
> > plan (for the few who want to migrate to Neutron), so this is a<br>
> > complementary solution rather than an alternative. Personally I doubt<br>
> > there would suddenly be enough people interested in nova-net development<br>
> > to successfully spin it out and maintain it. I also agree with Russell<br>
> > that long-term fragmentation at this layer of the stack is generally not<br>
> > desirable.<br>
> <br>
> I think if you boil everything down, you end up with 3 really important<br>
> differences.<br>
> <br>
> 1) neutron is a fleet of services (it's very micro service) and every<br>
> service requires multiple and different config files. Just configuring<br>
> the fleet is a beast if it not devstack (and even if it is)<br>
> <br>
> 2) neutron assumes a primary interesting thing to you is tenant secured<br>
> self service networks. This is actually explicitly not interesting to a<br>
> lot of deploys for policy, security, political reasons/restrictions.<br>
> <br>
> 3) neutron open source backend defaults to OVS (largely because #2). OVS<br>
> is it's own complicated engine that you need to learn to debug. While<br>
> Linux bridge has challenges, it's also something that anyone who's<br>
> worked with Linux & Virtualization for the last 10 years has some<br>
> experience with.<br>
> <br>
> (also, the devstack setup code for neutron is a rats nest, as it was<br>
> mostly not paid attention to. This means it's been 0 help in explaining<br>
> anything to people trying to do neutron. For better or worse devstack is<br>
> our executable manual for a lot of these things)<br>
> <br>
> so.... that being said, I think we need to talk about "minimum viable<br>
> neutron" as a model and figure out how far away that is from n-net. This<br>
> week at the QA Sprint, Dean, Sean Collins, and I have spent some time<br>
> hashing it out, hopefully with something to show the end of the week.<br>
> This will be the new devstack code for neutron (the old lib/neutron is<br>
> moved to lib/neutron-legacy).<br>
> <br>
> Default setup will be provider networks (which means no tenant<br>
> isolation). For that you should only need neutron-api, -dhcp, and -l2.<br>
> So #1 is made a bunch better. #2 not a thing at all. And for #3 we'd<br>
> like to revert back to linux bridge for the base case (though first code<br>
> will probably be OVS because that's the happy path today).<br>
> </font></tt><br>
<br>
<tt><font size="2">Are you suggesting that for the common use cases that will use the default setup, the external network connectivity doesn't matter much? </font></tt><br>
<tt><font size="2"><br>
> Mixin #1: NEUTRON_BRIDGE_WITH=OVS<br>
> <br>
> First optional layer being flip from linuxbridge -> ovs. That becomes<br>
> one bite sized thing to flip over once you understand it.<br>
> <br>
> Mixin #2: self service networks<br>
> <br>
> This will be off in the default case, but can be enabled later.<br>
> <br>
> ... and turtles all the way up.<br>
> <br>
> <br>
> Provider networks w/ Linux bridge are really close to the simplicity on<br>
> the wire people expected with n-net. The only last really difference is<br>
> floating ips. And the problem here was best captured by Sean Collins on<br>
> Wed, Floating ips in nova are overloaded. They are both elastic ips, but<br>
> they are also how you get public addresses in a default environment.<br>
> Dean shared that that dual purpose is entirely due to constraints of the<br>
> first NASA cloud which only had a /26 of routable IPs. In neutron this<br>
> is just different, you don't need floating ips to have public addresses.<br>
> But the mental model has stuck.<br>
> <br>
> <br>
> Anyway, while I'm not sure this is going to solve everyone's issues, I<br>
> think it's a useful exercise anyway for devstack's neutron support to<br>
> revert to a minimum viable neutron for learning purposes, and let you<br>
> layer on complexity manually over time. And I'd be really curious if a<br>
> n-net -> provider network side step (still on linux bridge) would<br>
> actually be a more reasonable transition for most environments.<br>
> <br>
> -Sean<br>
> <br>
> -- <br>
> Sean Dague<br>
> <a href="http://dague.net">http://dague.net</a><br>
> <br>
> [attachment "signature.asc" deleted by Mohammad Banikazemi/Watson/<br>
> IBM] <br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></tt></body></html>