On Fri, Apr 24, 2015 at 4:06 AM, loy wolfe <loywo...@gmail.com> wrote:
> It's already away from the original thread, so I start this new one, > also with some extra tag because I think it touch some corss-project > area. > > Original discuss and reference: > http://lists.openstack.org/pipermail/openstack-dev/2015-April/062384.html > https://review.openstack.org/#/c/176501/1/specs/liberty/reference-split.rst > > Background summary: > All in-tree implementation would be splitted from Openstack > networking, leaving Neutron as a naked "API/DB" platform, with a list > of out-tree implementation git repos, which are not maintained by core > team any more, but may be given a nominal "big tent" under the > Openstack umbrella. > > I'm not sure what led you to this discussion, but it's patently incorrect. We're going to split the in-tree reference implementation into a separate git repository. I have not said anything about the current core revewier team not being responsible for that. It's natural to evolve to a core reviewer team which cares deeply about that, vs. those who care deeply about the DB/API layer. This is exactly what happened when we split out the advanced services. > Motivation: a) Smaller core team only focus on the in-tree API/DB > definition, released from concrete controlling function > implementation; b) If there is official implementation inside Neutron, > 3rd external SDN controller would face the competition. > > I'm not sure whether it's exactly what cloud operators want the > Openstack to deliver. Do they want a off-the-shelf package, or just a > framework and have to take the responsibility of integrating with > other external controlling projects? A analogy with Linux that only > kernel without any device driver has no use at all. > > We're still going to deliver ML2+OVS/LB+[DHCP, L3, metadata] agents for Liberty. I'm not sure where your incorrect assumption on what we're going to deliver is coming from. > There are already many debates about nova-network to Neutron parity. > If largely used OVS and LB driver is out of tree and has to be > integrated separately by customers, how do those they migrate from > nova network? Standalone SDN controller has steep learning curve, and > a lot of users don't care which one is better of ODL vs. OpenContrail > to be integrated, they just want Openstack package easy to go by > default in tree implementation, and are ready to drive all kinds of > opensource or commercial backends. > > Do you realize that ML2 is plus the L2 agent is an SDN controller already? > BTW: +1 to henry and mathieu, that indeed Openstack is not responsible > projects of switch/router/fw, but it should be responsible for > scheduling, pooling, and driving of those backends, which is the same > case with Nova/Cinder scheduler and compute/volume manager. These > controlling functions shouldn't be classified as backends in Neutron > and be splitted out of tree. > > Regards > > > On Fri, Apr 24, 2015 at 2:37 AM, Kyle Mestery <mest...@mestery.com> wrote: > > > > > > On Thu, Apr 23, 2015 at 1:31 PM, Fox, Kevin M <kevin....@pnnl.gov> > wrote: > >> > >> Yeah. In the end, its what git repo the source for a given rpm you > install > >> comes from. Ops will not care that neutron-openvswitch-agent comes from > repo > >> foo.git instead of bar.git. > >> > > > > > > That's really the tl;dr of the proposed split. > > > > Thanks, > > Kyle > > > >> > >> Thanks, > >> Kevin > >> ________________________________ > >> From: Armando M. [arma...@gmail.com] > >> Sent: Thursday, April 23, 2015 9:10 AM > >> To: OpenStack Development Mailing List (not for usage questions) > >> Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron > backend > >> code > >> > >>>> > >>> I agree with henry here. > >>> Armando, If we use your analogy with nova that doesn't build and > deliver > >>> KVM, we can say that Neutron doesn't build or deliver OVS. It builds a > >>> driver and an agent which manage OVS, just like nova which provides a > driver > >>> to manage libvirt/KVM. > >>> Moreover, external SDN controllers are much more complex than Neutron > >>> with its reference drivers. I feel like forcing the cloud admin to > deploy > >>> and maintain an external SDN controller would be a terrible experience > for > >>> him if he just needs a simple way manage connectivity between VMs. > >>> At the end of the day, it might be detrimental for the neutron project. > >>> > >> > >> > >> I don't think that anyone is saying that cloud admins are going to be > >> forced to deploy and maintain an external SDN controller. There are > plenty > >> of deployment examples where people are just happy with network > >> virtualization the way Neutron has been providing for years and we > should > >> not regress on that. To me it's mostly a matter of responsibilities of > who > >> develops what, and what that what is :) > >> > >> The consumption model is totally a different matter. > >> > >> > >> > __________________________________________________________________________ > >> 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