Open Stack

On 09/29/2015 12:23 PM, Emilien Macchi wrote:
> 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?

Silence probably means lazy consensus.
I submitted a patch: https://review.openstack.org/#/c/229675/ - please
review.

I also contacted Cisco and they acknowledged it, and will work on
puppet-n1kv to externalize third party software.


> 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
>>
> 
> 
> 
> __________________________________________________________________________
> 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/20150930/2ff20650/attachment.pgp>