Open Stack

My suggestion:

* patch master to send deprecation warning if third party repositories
are managed in our current puppet-neutron module.
* do not manage third party repositories from now and do not accept any
patch containing this kind of code.
* in the next cycle, we will consider deleting legacy code that used to
manage third party software repos.

Thoughts?

On 09/25/2015 12:32 PM, Anita Kuno wrote:
> On 09/25/2015 12:14 PM, Edgar Magana wrote:
>> Hi There,
>>
>> I just added my comment on the review. I do agree with Emilien. There should be specific repos for plugins and drivers.
>>
>> BTW. I love the sdnmagic name  ;-)
>>
>> Edgar
>>
>>
>>
>>
>> On 9/25/15, 9:02 AM, "Emilien Macchi" <emilien at redhat.com> wrote:
>>
>>> In our last meeting [1], we were discussing about whether managing or
>>> not external packaging repositories for Neutron plugin dependencies.
>>>
>>> Current situation:
>>> puppet-neutron is installing (packages like neutron-plugin-*) &
>>> configure Neutron plugins (configuration files like
>>> /etc/neutron/plugins/*.ini
>>> Some plugins (Cisco) are doing more: they install third party packages
>>> (not part of OpenStack), from external repos.
>>>
>>> The question is: should we continue that way and accept that kind of
>>> patch [2]?
>>>
>>> I vote for no: managing external packages & external repositories should
>>> be up to an external more.
>>> Example: my SDN tool is called "sdnmagic":
>>> 1/ patch puppet-neutron to manage neutron-plugin-sdnmagic package and
>>> configure the .ini file(s) to make it work in Neutron
>>> 2/ create puppet-sdnmagic that will take care of everything else:
>>> install sdnmagic, manage packaging (and specific dependencies),
>>> repositories, etc.
>>> I -1 puppet-neutron should handle it. We are not managing SDN soltution:
>>> we are enabling puppet-neutron to work with them.
>>>
>>> I would like to find a consensus here, that will be consistent across
>>> *all plugins* without exception.
>>>
>>>
>>> Thanks for your feedback,
>>>
>>> [1] http://goo.gl/zehmN2
>>> [2] https://review.openstack.org/#/c/209997/
>>> -- 
>>> Emilien Macchi
>>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> I think the data point provided by the Cinder situation needs to be
> considered in this decision: https://bugs.launchpad.net/manila/+bug/1499334
> 
> The bug report outlines the issue, but the tl;dr is that one Cinder
> driver changed their licensing on a library required to run in tree code.
> 
> Thanks,
> Anita.
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Emilien Macchi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150929/13c09392/attachment.pgp>