[openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change

Irena Berezovsky irenab at mellanox.com
Tue Dec 16 06:29:30 UTC 2014



-----Original Message-----
From: henry hly [mailto:] 
Sent: Tuesday, December 16, 2014 3:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change

On Tue, Dec 16, 2014 at 1:53 AM, Neil Jerram <Neil.Jerram at metaswitch.com> wrote:
> Hi all,
>
> Following the approval for Neutron vendor code decomposition 
> (https://review.openstack.org/#/c/134680/), I just wanted to comment 
> that it appears to work fine to have an ML2 mechanism driver 
> _entirely_ out of tree, so long as the vendor repository that provides 
> the ML2 mechanism driver does something like this to register their 
> driver as a neutron.ml2.mechanism_drivers entry point:
>
>   setuptools.setup(
>       ...,
>       entry_points = {
>           ...,
>           'neutron.ml2.mechanism_drivers': [
>               'calico = xyz.openstack.mech_xyz:XyzMechanismDriver',
>           ],
>       },
>   )
>
> (Please see
> https://github.com/Metaswitch/calico/commit/488dcd8a51d7c6a1a2f0378900
> 1c2139b16de85c for the complete change and detail, for the example 
> that works for me.)
>
> Then Neutron and the vendor package can be separately installed, and 
> the vendor's driver name configured in ml2_conf.ini, and everything works.
>
> Given that, I wonder:
>
> - is that what the architects of the decomposition are expecting?
>
> - other than for the reference OVS driver, are there any reasons in
>   principle for keeping _any_ ML2 mechanism driver code in tree?
>

Good questions. I'm also looking for the linux bridge MD, SRIOV MD...
Who will be responsible for these drivers?

Excellent question. In my opinion, 'technology' specific but not vendor specific MD (like SRIOV) should not be maintained by specific vendor. It should be accessible for all interested parties for contribution.

The OVS driver is maintained by Neutron community, vendor specific hardware driver by vendor, SDN controllers driver by their own community or vendor. But there are also other drivers like SRIOV, which are general for a lot of vendor agonitsc backends, and can't be maintained by a certain vendor/community.

So, it would be better to keep some "general backend" MD in tree besides SRIOV. There are also vif-type-tap, vif-type-vhostuser, hierarchy-binding-external-VTEP ... We can implement a very thin in-tree base MD that only handle "vif bind" which is backend agonitsc, then backend provider is free to implement their own service logic, either by an backend agent, or by a driver derived from the base MD for agentless scenery.

Keeping general backend MDs in tree sounds reasonable. 
Regards

> Many thanks,
>      Neil
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list