----- 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. > > -Sean > > -- > Sean Dague > http://dague.net > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
