This approach would work but my only concern is then getting an external package added as a dependency to Neutron. Or would you just forgo that entirely and mock out all of the library calls?
-- Kevin Benton On Mon, Jun 16, 2014 at 3:29 PM, Salvatore Orlando <sorla...@nicira.com> wrote: > I think there's is no suitable place at the moment in the source code tree. > "common" and "plugin specific" indeed are semantically a bit at odds too! > 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. > > I'm not sure if and when that will happen, but I think it will beneficial > to both the community and the vmware team. > That's something you might consider for your libraries too, if you can't > sort that with packagers as Anita said. > > 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) > > Salvatore > > > On 17 June 2014 00:10, Anita Kuno <ante...@anteaya.info> wrote: > >> On 06/16/2014 06:02 PM, Kevin Benton wrote: >> > Hello, >> > >> > In the Big Switch ML2 driver, we rely on quite a bit of code from the >> Big >> > Switch plugin. This works fine for distributions that include the entire >> > neutron code base. However, some break apart the neutron code base into >> > separate packages. For example, in CentOS I can't use the Big Switch ML2 >> > driver with just ML2 installed because the Big Switch plugin directory >> is >> > gone. >> > >> > Is there somewhere where we can put common third party code that will be >> > safe from removal during packaging? >> > >> > >> > Thanks >> > >> > >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> I think you would be best to talk to packagers. >> >> Rather than trying to move it around, perhaps asking the packagers why >> they are packaging it as they are might be a good place to begin. >> >> Thanks Kevin, >> Anita. >> >> _______________________________________________ >> 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 > > -- Kevin Benton
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
