Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-16 Thread Neil Jerram
Stefano Maffulli stef...@openstack.org writes: On 12/09/2014 04:11 PM, by wrote: [vad] how about the documentation in this case?... bcos it needs some place to document (a short desc and a link to vendor page) or list these kind of out-of-tree plugins/drivers... just to make the user aware

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-16 Thread Anne Gentle
On Tue, Dec 16, 2014 at 4:05 AM, Neil Jerram neil.jer...@metaswitch.com wrote: Stefano Maffulli stef...@openstack.org writes: On 12/09/2014 04:11 PM, by wrote: [vad] how about the documentation in this case?... bcos it needs some place to document (a short desc and a link to vendor page)

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-15 Thread Stefano Maffulli
On 12/09/2014 04:11 PM, by wrote: [vad] how about the documentation in this case?... bcos it needs some place to document (a short desc and a link to vendor page) or list these kind of out-of-tree plugins/drivers... just to make the user aware of the availability of such plugins/driers which

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-12 Thread Yuriy Shovkoplias
Dear neutron community, Can you please clarify couple points on the vendor code decomposition? - Assuming I would like to create the new driver now (Kilo development cycle) - is it already allowed (or mandatory) to follow the new process? https://review.openstack.org/#/c/134680/ - Assuming the

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-12 Thread Armando M.
On 12 December 2014 at 23:01, Yuriy Shovkoplias yshovkopl...@mirantis.com wrote: Dear neutron community, Can you please clarify couple points on the vendor code decomposition? - Assuming I would like to create the new driver now (Kilo development cycle) - is it already allowed (or

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-11 Thread Ihar Hrachyshka
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 +100. I vote -1 there and would like to point out that we *must* keep history during the split, and split from u/s code base, not random repositories. If you don't know how to achieve this, ask oslo people, they did it plenty of times when

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-11 Thread Gary Kotton
On 12/11/14, 12:50 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 +100. I vote -1 there and would like to point out that we *must* keep history during the split, and split from u/s code base, not random repositories. If you don't know how to

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-10 Thread Kevin Benton
Remove everything out of tree, and leave only Neutron API framework as integration platform, would lower the attractions of the whole Openstack Project. Without a default good enough reference backend from community, customers have to depends on packagers to fully test all backends for them.

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-10 Thread Cedric OLLIVIER
https://review.openstack.org/#/c/140191/ 2014-12-09 18:32 GMT+01:00 Armando M. arma...@gmail.com: By the way, if Kyle can do it in his teeny tiny time that he has left after his PTL duties, then anyone can do it! :) https://review.openstack.org/#/c/140191/ Fully cloning Dave Tucker's

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-09 Thread Salvatore Orlando
@lists.openstack.org Cc: openst...@lists.openstack.org openst...@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Core/Vendor code decomposition Gary, you are still miss the point of this proposal. Please see my comments in review. We are not forcing things out of tree, we are thinning them

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-09 Thread Armando M.
, December 7, 2014 at 7:19 PM To: OpenStack List openstack-dev@lists.openstack.org Cc: openst...@lists.openstack.org openst...@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Core/Vendor code decomposition Gary, you are still miss the point of this proposal. Please see my comments

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-09 Thread Salvatore Orlando
...@mestery.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Sunday, December 7, 2014 at 7:19 PM To: OpenStack List openstack-dev@lists.openstack.org Cc: openst...@lists.openstack.org openst...@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Core/Vendor code

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-09 Thread Ivar Lazzaro
, December 7, 2014 at 7:19 PM To: OpenStack List openstack-dev@lists.openstack.org Cc: openst...@lists.openstack.org openst...@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Core/Vendor code decomposition Gary, you are still miss the point of this proposal. Please see my comments

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-09 Thread Vadivel Poonathan
-To: OpenStack List openstack-dev@lists.openstack.org Date: Sunday, December 7, 2014 at 7:19 PM To: OpenStack List openstack-dev@lists.openstack.org Cc: openst...@lists.openstack.org openst...@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Core/Vendor code decomposition Gary, you

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-09 Thread Ivar Lazzaro
-To: OpenStack List openstack-dev@lists.openstack.org Date: Sunday, December 7, 2014 at 7:19 PM To: OpenStack List openstack-dev@lists.openstack.org Cc: openst...@lists.openstack.org openst...@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Core/Vendor code decomposition Gary

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-09 Thread loy wolfe
Remove everything out of tree, and leave only Neutron API framework as integration platform, would lower the attractions of the whole Openstack Project. Without a default good enough reference backend from community, customers have to depends on packagers to fully test all backends for them. Can

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-08 Thread Maru Newby
: [openstack-dev] [Neutron] Core/Vendor code decomposition Gary, you are still miss the point of this proposal. Please see my comments in review. We are not forcing things out of tree, we are thinning them. The text you quoted in the review makes that clear. We will look at further decomposing

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-07 Thread Gary Kotton
Hi, I have raised my concerns on the proposal. I think that all plugins should be treated on an equal footing. My main concern is having the ML2 plugin in tree whilst the others will be moved out of tree will be problematic. I think that the model will be complete if the ML2 was also out of

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-07 Thread Kyle Mestery
Gary, you are still miss the point of this proposal. Please see my comments in review. We are not forcing things out of tree, we are thinning them. The text you quoted in the review makes that clear. We will look at further decomposing ML2 post Kilo, but we have to be realistic with what we can

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-07 Thread Gary Kotton
To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: openst...@lists.openstack.orgmailto:openst...@lists.openstack.org openst...@lists.openstack.orgmailto:openst...@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Core/Vendor code