Re: [openstack-dev] [puppet] should puppet-neutron manage third party software?

2015-09-30 Thread Steven Hillman (sthillma) 
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"  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"  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

Re: [openstack-dev] [puppet] should puppet-neutron manage third party software?

2015-09-30 Thread Emilien Macchi 


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"  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

Re: [openstack-dev] [puppet] should puppet-neutron manage third party software?

2015-09-29 Thread Emilien Macchi 
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"  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



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

[openstack-dev] [puppet] should puppet-neutron manage third party software?

2015-09-25 Thread Emilien Macchi 
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



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

Re: [openstack-dev] [puppet] should puppet-neutron manage third party software?

2015-09-25 Thread Edgar Magana 
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"  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

Re: [openstack-dev] [puppet] should puppet-neutron manage third party software?

2015-09-25 Thread Anita Kuno 
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"  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