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

henry hly henry4hly at gmail.com
Tue Dec 16 01:11:52 UTC 2014

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/488dcd8a51d7c6a1a2f03789001c2139b16de85c
> 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?

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.


> Many thanks,
>      Neil
> _______________________________________________
> 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