On Tue, Dec 16, 2014 at 1:53 AM, 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? >
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. Regards > 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
