----- Original Message ----- > On 03/30/2015 09:25 AM, Assaf Muller wrote: > > > > > > ----- 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. > That is the nature of development. > > Let's also note that is patchset 1 of a patch marked work in progress. > > If we start to make decisions about whether or not a direction is a > reasonable direction on a patch which is expected to fail this early in > the development process we serious injure our ability to foster development. > > Please understand and respect the development process prior to expecting > others to make decisions prematurely. >
I was providing a status report, nothing more. > Thank you, > Anita. > > > >> > >> -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 > > > > > __________________________________________________________________________ > 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