Hi loy, thanks for this dedicated thread. On Fri, Apr 24, 2015 at 3:13 PM, Kyle Mestery <[email protected]> wrote:
> On Fri, Apr 24, 2015 at 4:06 AM, loy wolfe <[email protected]> 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? > I totally agree that this part of Neutron should be considered as a SDN controller. Actually we can even say that the Neutron SDN controller is composed of ML2+ref service plugins+agents. I think this thread is also motivated by the fact that, during design summit, we keep on earing that Neutron should NOT deliver and maintain a SDN controller, and it should rely on 3rd party SDN controllers. > >> 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 >> > > > __________________________________________________________________________ > 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
