Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-09-22 Thread Anne Gentle
On Thu, Aug 28, 2014 at 12:22 PM, Richard Woo richardwoo2...@gmail.com wrote: I have another question about incubator proposal, for CLI and GUI. Do we imply that the incubator feature will need to branch python-neutron client, Horizon, and or Nova ( if changes are needed)? This is as good

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-28 Thread Jay Pipes
On 08/27/2014 04:28 PM, Kevin Benton wrote: What are you talking about? The only reply was from me clarifying that one of the purposes of the incubator was for components of neutron that are experimental but are intended to be merged. Right. The special unicorns. In that case it might not

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-28 Thread Kevin Benton
Right. The special unicorns. Repeating this without defining it isn't helping anything. b) The experimental piece of code intends to replace whole-hog a large chunk of Neutron's existing codebase, or: In the DVR example I gave this is is the only relevant reason. Regardless of how well the

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-28 Thread Mark McClain
On Aug 28, 2014, at 10:45 AM, Jay Pipes jaypi...@gmail.com wrote: On 08/27/2014 04:28 PM, Kevin Benton wrote: What are you talking about? The only reply was from me clarifying that one of the purposes of the incubator was for components of neutron that are experimental but are intended to be

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-28 Thread Richard Woo
I have another question about incubator proposal, for CLI and GUI. Do we imply that the incubator feature will need to branch python-neutron client, Horizon, and or Nova ( if changes are needed)? On Tue, Aug 26, 2014 at 7:09 PM, James E. Blair cor...@inaugust.com wrote: Hi, After reading

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-28 Thread Jeremy Stanley
On 2014-08-28 08:31:26 -0700 (-0700), Kevin Benton wrote: [...] DVR completely changed the reference L3 service plugin, which lives in the main tree.  A well-defined, versioned internal API would not have helped any of the issues I brought up. [...] Except, perhaps, insofar as that (in some

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-28 Thread Kevin Benton
Yes, in theory all of the plugins should be removable from the core neutron repo. So then it would only need to be responsible for the APIs, db models, etc. However, IIRC there are no plans to move any reference plugins from the tree. On Thu, Aug 28, 2014 at 11:20 AM, Jeremy Stanley

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-27 Thread loy wolfe
On Wed, Aug 27, 2014 at 2:44 PM, Kevin Benton blak...@gmail.com wrote: Incubator doesn't mean being kicked out of tree, it just mean that the API and resource model needs to be baked for fast iteration, and can't be put in tree temporarily. That was exactly my point about developing a major

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-27 Thread Kevin Benton
Flag is only for admin use, tenant can't see it, and the default policy for router is setup by config file. It's still a public API that will have to follow a deprecation cycle. If a new API was going to be introduced for admins to control the distributed nature of routers, it would have been

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-27 Thread Jay Pipes
On 08/26/2014 07:09 PM, James E. Blair wrote: Hi, After reading https://wiki.openstack.org/wiki/Network/Incubator I have some thoughts about the proposed workflow. We have quite a bit of experience and some good tools around splitting code out of projects and into new projects. But we don't

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-27 Thread Kevin Benton
What are you talking about? The only reply was from me clarifying that one of the purposes of the incubator was for components of neutron that are experimental but are intended to be merged. In that case it might not make sense to have a life cycle of their own in another repo indefinitely. On

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-27 Thread Kevin Benton
I agree that components isolated to one service or something along those lines where there is a clear plugin point in Neutron, it might make sense to separate them permanently. However, at that point why even bother with the Neutron incubator when a new project can be started? The feature branch

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-27 Thread Ivar Lazzaro
Quoting Stefano from a different thread [0]: The rationale for the separate repository is that Neutron's code needs a lot of love for the *existing* codebase, before new features can be added (and before core team can accept more responsibilities for it). But progress is unstoppable: new

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-27 Thread Jeremy Stanley
On 2014-08-27 16:05:36 -0700 (-0700), Joe Gordon wrote: We have feature branches? How do we use them? I am not even sure if feature branches were evaluated as an option when the incubator was proposed. Keystone's new API used a feature branch, the EC work in Swift did, so did the Gearman

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-27 Thread Mandeep Dhami
Also note that one of the features of the incubator is that it can be packaged/released independently (like python-neutronclient) and a feature branch is not designed for that workflow. Regards, Mandeep On Wed, Aug 27, 2014 at 4:55 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-08-27

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-27 Thread Jeremy Stanley
On 2014-08-27 16:53:39 -0700 (-0700), Clark Boylan wrote: [...] I thought there was a wiki article on how they work but I can't find it. Maybe someone else can link it here. [...] https://wiki.openstack.org/wiki/GerritJenkinsGit#Merge_Commits -- Jeremy Stanley

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-27 Thread Jeremy Stanley
On 2014-08-27 16:59:54 -0700 (-0700), Mandeep Dhami wrote: Also note that one of the features of the incubator is that it can be packaged/released independently (like python-neutronclient) and a feature branch is not designed for that workflow. Good point, and that definitely is a reason to

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-27 Thread Dean Troyer
On Wed, Aug 27, 2014 at 6:59 PM, Mandeep Dhami dh...@noironetworks.com wrote: Also note that one of the features of the incubator is that it can be packaged/released independently (like python-neutronclient) and a feature branch is not designed for that workflow. Which is a good reason to

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-27 Thread Ivar Lazzaro
On Wed, Aug 27, 2014 at 5:06 PM, Jeremy Stanley fu...@yuggoth.org wrote: Good point, and that definitely is a reason to just keep those pieces in their own separate Git repositories outside of the core Neutron repository in perpetuity (even after they graduate from incubation). One package

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-26 Thread Kevin Benton
From what I understand, the intended projects for the incubator can't operate without neutron because they are just extensions/plugins/drivers. For example, if the DVR modifications to the reference reference L3 plugin weren't already being developed in the tree, DVR could have been developed in

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-26 Thread loy wolfe
Incubator doesn't mean being kicked out of tree, it just mean that the API and resource model needs to be baked for fast iteration, and can't be put in tree temporarily. As kyle has said, incubator is not talking about moving 3rd drivers out of tree, which is in another thread. For DVR, as it has