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. 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. 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. 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 <[email protected]> wrote: > > > On Thu, Apr 23, 2015 at 1:31 PM, Fox, Kevin M <[email protected]> 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. [[email protected]] >> 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: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
