<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 15 December 2014 at 09:53, Neil Jerram <span dir="ltr"><<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all,<br>
<br>
Following the approval for Neutron vendor code decomposition<br>
(<a href="https://review.openstack.org/#/c/134680/" target="_blank">https://review.openstack.org/#/c/134680/</a>), I just wanted to comment<br>
that it appears to work fine to have an ML2 mechanism driver _entirely_<br>
out of tree, so long as the vendor repository that provides the ML2<br>
mechanism driver does something like this to register their driver as a<br>
neutron.ml2.mechanism_drivers entry point:<br>
<br>
  setuptools.setup(<br>
      ...,<br>
      entry_points = {<br>
          ...,<br>
          'neutron.ml2.mechanism_drivers': [<br>
              'calico = xyz.openstack.mech_xyz:XyzMechanismDriver',<br>
          ],<br>
      },<br>
  )<br>
<br>
(Please see<br>
<a href="https://github.com/Metaswitch/calico/commit/488dcd8a51d7c6a1a2f03789001c2139b16de85c" target="_blank">https://github.com/Metaswitch/calico/commit/488dcd8a51d7c6a1a2f03789001c2139b16de85c</a><br>
for the complete change and detail, for the example that works for me.)<br>
<br>
Then Neutron and the vendor package can be separately installed, and the<br>
vendor's driver name configured in ml2_conf.ini, and everything works.<br>
<br>
Given that, I wonder:<br>
<br>
- is that what the architects of the decomposition are expecting?</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
- other than for the reference OVS driver, are there any reasons in<br>
  principle for keeping _any_ ML2 mechanism driver code in tree?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Many thanks,<br>
     Neil<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div>