Open Stack

Makes sense to me.

Opened a bug to track the migration of agents/n1kv_vem.pp out of
puppet-neutron during the M-cycle:
https://bugs.launchpad.net/puppet-neutron/+bug/1501535

Thanks.
Steven Hillman

On 9/29/15, 9:23 AM, "Emilien Macchi" <emilien at redhat.com> 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?
>
>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
>