On 15 December 2014 at 09:53, Neil Jerram <neil.jer...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
