<div dir="ltr">This approach would work but my only concern is then getting an external package added as a dependency to Neutron.<div>Or would you just forgo that entirely and mock out all of the library calls?</div><div><br>

</div><div>--<br>Kevin Benton</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 16, 2014 at 3:29 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I think there's is no suitable place at the moment in the source code tree.</div><div>"common" and "plugin specific" indeed are semantically a bit at odds too!</div>

I am considering moving all "library" code for the vmware plugins outside of the source code tree, into their own package, maintained separately and independently from neutron release cycles.<div>
<br></div><div>I'm not sure if and when that will happen, but I think it will beneficial to both the community and the vmware team.</div><div>That's something you might consider for your libraries too, if you can't sort that with packagers as Anita said.</div>


<div><br></div><div>A situation like this will however put distros which package plugins in distinct packages in a tight spot, as it would look rather weird to have the bigswitch plugin as a dependency for the ml2 plugin (I don't think drivers are packages separately)</div>

<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Salvatore</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 June 2014 00:10, Anita Kuno <span dir="ltr"><<a href="mailto:anteaya@anteaya.info" target="_blank">anteaya@anteaya.info</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 06/16/2014 06:02 PM, Kevin Benton wrote:<br>
> Hello,<br>
><br>
> In the Big Switch ML2 driver, we rely on quite a bit of code from the Big<br>
> Switch plugin. This works fine for distributions that include the entire<br>
> neutron code base. However, some break apart the neutron code base into<br>
> separate packages. For example, in CentOS I can't use the Big Switch ML2<br>
> driver with just ML2 installed because the Big Switch plugin directory is<br>
> gone.<br>
><br>
> Is there somewhere where we can put common third party code that will be<br>
> safe from removal during packaging?<br>
><br>
><br>
> Thanks<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
><br>
I think you would be best to talk to packagers.<br>
<br>
Rather than trying to move it around, perhaps asking the packagers why<br>
they are packaging it as they are might be a good place to begin.<br>
<br>
Thanks Kevin,<br>
Anita.<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><br></div>
</div></div><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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>