I don't think that a common area as being proposed is a silver bullet for
solving packaging issues, such as this one. Knowing that the right source
tree bits are dropped onto the file system is not enough to guarantee that
the end-to-end solution will work on a specific distro. Other issues may
arise after configuration and execution.

IMO, this is a bug in the packages spec, and should be taken care of during
the packaging implementation, testing and validation.

That said, I think the right approach is to provide a 'python-neutron'
package that installs the entire source tree; the specific plugin package
can then take care of the specifics, like config files.

Armando


On 17 June 2014 06:43, Shiv Haris <sha...@brocade.com> wrote:

> Right Armando.
>
> Brocade’s mech driver problem is due to NETCONF templates - would also
> prefer to see a common area for such templates – not just common code.
>
> Sort of like:
>
> common/brocade/templates
> common/bigswitch/*
>
> -Shiv
> From: "Armando M." <arma...@gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron] - Location for common third-party
> libs?
>
> I believe the Brocade's mech driver might have the same problem.
>
> That said, if the content of the rpm that installs the BigSwitch plugin is
> just the sub-tree for bigswitch (plus the config files, perhaps), you might
> get away with this issue by just installing the bigswitch-plugin package. I
> assume you tried that and didn't work?
>
> I was unable to find the rpm specs for CentOS to confirm.
>
> A.
>
>
> On 17 June 2014 00:02, Kevin Benton <blak...@gmail.com> 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
>> --
>> Kevin Benton
>>
>> _______________________________________________
>> 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
>
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to