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:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
