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

Kevin Benton blak111 at gmail.com
Wed Aug 27 20:32:43 UTC 2014


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 idea sounds interesting for the one-time big
experimental changes. Are there any other projects that do this right now?


On Wed, Aug 27, 2014 at 12:30 PM, James E. Blair <corvus at inaugust.com>
wrote:

> Kevin Benton <blak111 at gmail.com> writes:
>
> > From what I understand, the intended projects for the incubator can't
> > operate without neutron because they are just extensions/plugins/drivers.
>
> I could have phrased that better.  What I meant was that they could
> operate without being actually in the Neutron repo, not that they could
> not operate without Neutron itself.
>
> The proposal for the incubator is that extensions be developed outside
> of the Neutron repo.  My proposed refinement is that they stay outside
> of the Neutron repo.  They live their entire lives as extension modules
> in separate projects.
>
> > 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 the incubator and then merged into Neutron once the bugs were ironed
> out
> > so a huge string of Gerrit patches didn't need to be tracked. If that had
> > happened, would it make sense to keep the L3 plugin as a completely
> > separate project or merge it? I understand this is the approach the load
> > balancer folks took by making Octavia a separate project, but I think it
> > can still operate on its own, where the reference L3 plugin (and many of
> > the other incubator projects) are just classes that expect to be able to
> > make core Neutron calls.
>
> The list of Juno/Kilo candidates doesn't seem to have projects that are
> quite so low-level.
>
> If a feature is going to become part of the neutron core, then it should
> be developed in the neutron repository.  If we need a place to land code
> that isn't master, it's actually far easier to just use a feature branch
> on the neutron repo.  Commits can land there as needed, master can be
> periodically merged into it, and when the feature is ready, the feature
> branch can be merged into master.
>
> I think between those two options: incubate/spin-out components that are
> high-level enough not to have deep integration in the neutron core, and
> using feature branches for large experimental changes to the core
> itself, we can handle the problems the incubator repo is intended to
> address.
>
> -Jim
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140827/77ffa5c2/attachment.html>


More information about the OpenStack-dev mailing list