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" <emil...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
