On Wed, Feb 25, 2015 at 5:34 AM, Sukhdev Kapur <sukhdevka...@gmail.com> wrote:
> Folks, > > A great discussion. I am not expert at OVN, hence, want to ask a question. > The answer may make a case that it should probably be a ML2 driver as > oppose to monolithic plugin. > > Say a customer want to deploy an OVN based solution and use HW devices > from one vendor for L2 and L3 (e.g. Arista or Cisco), and want to use > another vendor for services (e.g. F5 or A10) - how can that be supported? > > If OVN goes in as ML2 driver, I can then run ML2 and Service plugin to > achieve above solution. For a monolithic plugin, don't I have an issue? > On the specifics of service plugins: service plugins and standalone plugins can co-exist to provide a solution with advanced services from different vendors. Some existing monolithic plugins (e.g. PLUMgrid) have blueprints deployed using this approach. > > regards.. > -Sukhdev > > > On Tue, Feb 24, 2015 at 8:58 AM, Salvatore Orlando <sorla...@nicira.com> > wrote: > >> 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 >> >> > > __________________________________________________________________________ > 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