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. -Sean -- Sean Dague http://dague.net
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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