Open Stack

On 15 December 2014 at 09:53, 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?
>

The approach you outlined is reasonable, and new plugins/drivers, like
yours, may find it easier to approach Neutron integration this way.
However, to ensure a smoother migration path for existing plugins and
drivers, it was deemed more sensible to go down the path being proposed in
the spec referenced above.


>
> Many thanks,
>      Neil
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141215/021516b0/attachment.html>