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" <emil...@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" <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 >> > >-- >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