I think we're speculating a lot about what would be best for OVN whereas we should probably just expose pro and cons of ML2 drivers vs standalone plugin (as I said earlier on indeed it does not necessarily imply monolithic *)
I reckon the job of the Neutron community is to provide a full picture to OVN developers - so that they could make a call on the integration strategy that best suits them. On the other hand, if we're planning to commit to a model where ML2 is not anymore a plugin but the interface with the API layer, then any choice which is not a ML2 driver does not make any sense. Personally I'm not sure we ever want to do that, at least not in the near/medium term, but I'm one and hardly representative of the developer/operator communities. Salvatore * In particular with the advanced service split out the term monolithic simply does not mean anything anymore. On 24 February 2015 at 17:48, Robert Kukura <kuk...@noironetworks.com> wrote: > Kyle, What happened to the long-term potential goal of ML2 driver APIs > becoming neutron's core APIs? Do we really want to encourage new monolithic > plugins? > > ML2 is not a control plane - its really just an integration point for > control planes. Although co-existence of multiple mechanism drivers is > possible, and sometimes very useful, the single-driver case is fully > supported. Even with hierarchical bindings, its not really ML2 that > controls what happens - its the drivers within the framework. I don't think > ML2 really limits what drivers can do, as long as a virtual network can be > described as a set of static and possibly dynamic network segments. ML2 is > intended to impose as few constraints on drivers as possible. > > My recommendation would be to implement an ML2 mechanism driver for OVN, > along with any needed new type drivers or extension drivers. I believe this > will result in a lot less new code to write and maintain. > > Also, keep in mind that even if multiple driver co-existence doesn't sound > immediately useful, there are several potential use cases to consider. One > is that it allows new technology to be introduced into an existing cloud > alongside what previously existed. Migration from one ML2 driver to another > may be a lot simpler (and/or flexible) than migration from one plugin to > another. Another is that additional drivers can support special cases, such > as bare metal, appliances, etc.. > > -Bob > > > On 2/24/15 11:11 AM, Kyle Mestery wrote: > > On Tue, Feb 24, 2015 at 3:19 AM, Salvatore Orlando <sorla...@nicira.com> > wrote: > >> On 24 February 2015 at 01:34, Kyle Mestery <mest...@mestery.com> wrote: >> >>> Russel and I have already merged the initial ML2 skeleton driver [1]. >>> >> The thinking is that we can always revert to a non-ML2 driver if >>> needed. >>> >> >> If nothing else an authoritative decision on a design direction saves >> us the hassle of going through iterations and discussions. >> The integration through ML2 is definitely viable. My opinion however is >> that since OVN implements a full control plane, the control plane bits >> provided by ML2 are not necessary, and a plugin which provides only >> management layer capabilities might be the best solution. Note: this does >> not mean it has to be monolithic. We can still do L3 with a service plugin. >> However, since the same kind of approach has been adopted for ODL I >> guess this provides some sort of validation. >> >> > To be honest, after thinking about this last night, I'm now leaning > towards doing this as a full plugin. I don't really envision OVN running > with other plugins, as OVN is implementing it's own control plane, as you > say. So the value of using ML2 is quesitonable. > > >> I'm not sure how useful having using OVN with other drivers will be, >>> and that was my initial concern with doing ML2 vs. full plugin. With the HW >>> VTEP support in OVN+OVS, you can tie in physical devices this way. Anyways, >>> this is where we're at for now. Comments welcome, of course. >>> >> >> That was also kind of my point regarding the control plane bits >> provided by ML2 which OVN does not need. Still, the fact that we do not use >> a function does not make any harm. >> Also i'm not sure if OVN needs at all a type manager. If not, we can >> always implement a no-op type manager, I guess. >> >> See above. I'd like to propose we move OVN to a full plugin instead > of an ML2 MechanismDriver. > > Kyle > > >> Salvatore >> >> >>> >>> Thanks, >>> Kyle >>> >>> [1] https://github.com/stackforge/networking-ovn >>> >>> On Mon, Feb 23, 2015 at 4:09 PM, Kevin Benton <blak...@gmail.com> wrote: >>> >>>> I want to emphasize Salvatore's last two points a bit more. If you go >>>> with a monolithic plugin, you eliminate the possibility of heterogenous >>>> deployments. >>>> >>>> One example of this that is common now is having the current OVS >>>> driver responsible for setting up the vswitch and then having a ToR driver >>>> (e.g. Big Switch, Arista, etc) responsible for setting up the fabric. >>>> Additionally, there is a separate L3 plugin (e.g. the reference one, >>>> Vyatta, etc) for providing routing. >>>> >>>> I suppose with an overlay it's easier to take the route that you >>>> don't want to be compatible with other networking stuff at the Neutron >>>> layer (e.g. integration with the 3rd parties is orchestrated somewhere >>>> else). In that case, the above scenario wouldn't make much sense to >>>> support, but it's worth keeping in mind. >>>> >>>> On Mon, Feb 23, 2015 at 10:28 AM, Salvatore Orlando < >>>> sorla...@nicira.com> wrote: >>>> >>>>> I think there are a few factors which influence the ML2 driver vs >>>>> "monolithic" plugin debate, and they mostly depend on OVN rather than >>>>> Neutron. >>>>> From a Neutron perspective both plugins and drivers (as long at they >>>>> live in their own tree) will be supported in the foreseeable future. If a >>>>> ML2 mech driver is not the best option for OVN that would be ok - I don't >>>>> think the Neutron community advices development of a ML2 driver as the >>>>> preferred way for integrating with new backends. >>>>> >>>>> The ML2 framework provides a long list of benefits that mechanism >>>>> driver developer can leverage. >>>>> Among those: >>>>> - The ability of leveraging Type drivers which relieves driver >>>>> developers from dealing with network segment allocation >>>>> - Post-commit and (for most operations) pre-commit hooks for >>>>> performing operation on the backend >>>>> - The ability to leverage some of the features offered by Neutron's >>>>> built-in control-plane such as L2-population >>>>> - A flexible mechanism for enabling driver-specific API extensions >>>>> - Promotes modular development and integration with higher-layer >>>>> services, such as L3. For instance OVN could provide the L2 support for >>>>> Neutron's built-in L3 control plane >>>>> - The (potential afaict) ability of interacting with other mechanism >>>>> driver such as those operating on physical appliances on the data center >>>>> - <add your benefit here> >>>>> >>>>> In my opinion OVN developers should look at ML2 benefits, and check >>>>> which ones apply to this specific platform. I'd say that if there are 1 or >>>>> 2 checks in the above list, maybe it would be the case to look at >>>>> developing a ML2 mechanism driver, and perhaps a L3 service plugin. >>>>> It is worth nothing that ML2, thanks to its type and mechanism driver >>>>> provides also some control plane capabilities. If those capabilities are >>>>> however on OVN's roadmap it might be instead worth looking at a >>>>> "monolithic" plugin, which can also be easily implemented by inheriting >>>>> from neutron.db.db_base_plugin_v2.NeutronDbPluginV2, and then adding all >>>>> the python mixins for the extensions the plugin needs to support. >>>>> >>>>> Salvatore >>>>> >>>>> >>>>> On 23 February 2015 at 18:32, Ben Pfaff <b...@nicira.com> wrote: >>>>> >>>>>> [branching off a discussion on ovs-dev at this point: >>>>>> http://openvswitch.org/pipermail/dev/2015-February/051609.html] >>>>>> >>>>>> On Fri, Feb 20, 2015 at 6:56 PM, Kyle Mestery <mest...@mestery.com> >>>>>> wrote: >>>>>> > One thing to keep in mind, this ties somewhat into my response to >>>>>> Russell >>>>>> > earlier on the decision around ML2 vs. core plugin. If we do ML2, >>>>>> there are >>>>>> > type drivers for VLAN, VXLAN, and GRE tunnels. There is no >>>>>> TypeDriver for >>>>>> > STT tunnels upstream now. It's just an item we need on the TODO >>>>>> list if we >>>>>> > go down the STT tunnel path. >>>>>> >>>>>> It was suggested to me off-list that this part of the discussion >>>>>> should be on >>>>>> openstack-dev, so here it is ;-) >>>>>> >>>>>> >>>>>> __________________________________________________________________________ >>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Kevin Benton >>>> >>>> >>>> __________________________________________________________________________ >>>> 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:unsubscribehttp://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
