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" <[email protected]> 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: [email protected]?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: [email protected]?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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
