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

On Tue, Dec 16, 2014 at 4:05 AM, Neil Jerram wrote: > > Stefano Maffulli 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-t

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

Stefano Maffulli 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 of >> the avai

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

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 w

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

On 12 December 2014 at 23:01, Yuriy Shovkoplias 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 mandatory) to follow the new

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

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

On 12/11/14, 12:50 PM, "Ihar Hrachyshka" 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 achieve this, ask

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

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

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

2014-12-09 18:32 GMT+01:00 Armando M. : > > 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 repository [

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

>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

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

;>> not be the first time and most definitely not the last). The thinning out >>>>>> is to have a shim in place. I understand this and this will be the entry >>>>>> point for the plugin. I do not have a concern for this. My concern is >>>>>

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

t;>>>> is to have a shim in place. I understand this and this will be the entry >>>>>> point for the plugin. I do not have a concern for this. My concern is >>>>>> that >>>>>> we are not doing this with the ML2 off the bat. That shoul

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

that’s the province of ML2 >>>>> drivers - so it is not a good target for the proposed decomposition by >>>>> itself. >>>>> >>>>> >>>>> > • Cause we will fix them quicker as it is something that >>>>>

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

nstraint. >>>> >>>> >>>> Maru >>>> >>>> >>>> > Sure, I’ll catch you on IRC tomorrow. I guess that you guys will bash >>>> out the details at the meetup. Sadly I will not be able to attend – so you >>>> wil

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

he shim in Neutron >>> > • Update devstack for the to use the two repos and the shim >>> > When #3 is up and running we switch for that to be the gate. Then we >>> start a stopwatch on all other plugins. >>> >>> As was pointed out on the spec

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

ain in the main Neutron repo >> for now. Neutron gates on ML2+OVS and landing a breaking change in the >> Neutron repo along with its corresponding fix to a separate ML2 repo would >> be all but impossible under the current integrated gating scheme. >> Plugins/drivers that do not g

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

will have to delay on the tar and feathers. > > Thanks > > Gary > > > > > > From: "mest...@mestery.com" > > Reply-To: OpenStack List > > Date: Sunday, December 7, 2014 at 7:19 PM > > To: OpenStack List > > Cc: "openst...@lists.openstack.org&

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

e meetup. Sadly I will not be able to attend – so you will have > to delay on the tar and feathers. > Thanks > Gary > > > From: "mest...@mestery.com" > Reply-To: OpenStack List > Date: Sunday, December 7, 2014 at 7:19 PM > To: OpenStack List > Cc: "op

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

you guys will bash out > the details at the meetup. Sadly I will not be able to attend – so you will > have to delay on the tar and feathers. > Thanks > Gary > > > From: "mest...@mestery.com" > Reply-To: OpenStack List > Date: Sunday, December 7, 2014 at 7:19 PM &

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

k List mailto:openstack-dev@lists.openstack.org>> Cc: "openst...@lists.openstack.org<mailto:openst...@lists.openstack.org>" mailto:openst...@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron] Core/Vendor code decomposition Gary, you are still miss the point of

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

y. > Thanks > Gary > > From: "Armando M." > Reply-To: OpenStack List > Date: Saturday, December 6, 2014 at 1:04 AM > To: OpenStack List , " > openst...@lists.openstack.org" > Subject: [openstack-dev] [Neutron] Core/Vendor code decomposition >

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

mailto:openstack-dev@lists.openstack.org>>, "openst...@lists.openstack.org<mailto:openst...@lists.openstack.org>" mailto:openst...@lists.openstack.org>> Subject: [openstack-dev] [Neutron] Core/Vendor code decomposition Hi folks, For a few weeks now the Neutron team ha

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

Hi folks, For a few weeks now the Neutron team has worked tirelessly on [1]. This initiative stems from the fact that as the project matures, evolution of processes and contribution guidelines need to evolve with it. This is to ensure that the project can keep on thriving in order to meet the nee

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

Hello, As follow-up action after the Design Summit Session on Core/Vendor split, please find the proposal outlined here: https://review.openstack.org/#/c/134680/ I know that Anita will tell me off since I asked for reviews on the ML, but I felt that it was important to raise awareness, even more