Open Stack

----- 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>