Open Stack

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 <sorlando at 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 <anteaya at 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 at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140616/1d7f664f/attachment.html>