On Fri, Apr 24, 2015 at 9:46 PM, Salvatore Orlando <sorla...@nicira.com> wrote: > > > On 24 April 2015 at 15:13, Kyle Mestery <mest...@mestery.com> wrote: >> >> 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. > > > This discussion seems quite similar to that we had about non-reference > plugins. > Following the linux analogy you mention below Neutron should have been > deprived of its plugins and drivers. And indeed, regardless of what it > seems, it hasn't. Any user can still grab drivers as before. They just > reside in different repos. This is not different, imho, from the concept of > maintainers that linux has. > Besides you make it look at like as if the management layer (API/DB) is just > a tiny insignificant piece of software. I disagree quite strongly here, but > perhaps it's just me seeing in Neutron's mgmt layer something more than what > is actually is. > >> >> >>> >>> 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. > > > Perhaps point (b) is a bit unclear. Are you stating that having this control > plane in Neutron gives it a "better placement" compared with other > solutions? >
The words are just from the reference split spec :) > >>> >>> >>> 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. > > > I would answer with a different analogy - nova. Consider the various agents > as if it were libvirt. Like libvirt is a component which you use to control > your hypervisor, the agents control the data plane (OVS and utilities like > iptables/conntrack/dnsmasq/etc). With this analogy I believe Neutron's > "reference" control plane deserves to live on its own, just like nobody > would ever think that a libvirt implementation within nova is something > sane, > However, ML2 is a different beast. It has inside management and control > logic, we'll need a good surgeon there. Pretty sure our refactoring fans are > already drooling at the thought of cutting apart another component. > >> >> >>> >>> 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. > > > I'm not sure what you mean here. In your opinions do operator want something > that works and provides everything out of the box, and want something which > is able to driver open source and commercial backends. > And besides I do not see the complication from operators arising from this > proposal. It's not like they have to maintain another component - indeed > from an operator perspective l3 agents, dhcp agents, and so on are already > different components to maintain (and that's one of the pain points they > feel in using neutron) > At least for me and most of out customers, deployment and maintenance of openstack and ODL together with its SDN apps had taken much more effort than native Neutron ML2+agents. However existing agents need to evolve as you mentioned, e.g. modular combined agents > >>> >>> >> >> 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 > > > Thanks for your comments Loy. Every time you chime on the mailing list you > always have detailed insights. > Can I ask your IRC handle so that we can follow up on IRC? I could not find > it since you appear to not have a gerrit account, or a launchpad id, or a > foundation profile for that matter. > Sorry strictly speaking I'm not a developer, so have no gerrit account yet. I'm a consultant to help people building and running openstack more easily. However I will try with IRC if it is more convenient for communication. > Regards, > Salvatore > >>> >>> >>> 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 >> > > > __________________________________________________________________________ > 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
