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

loy wolfe loywolfe at gmail.com
Wed Aug 27 01:19:37 UTC 2014

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 no influence on tenant facing API resource model, it
works as the built-in backend, and this feature has accepted wide common
interests, it's just the internal performance optimization tightly coupled
with existing code, so it should be developed in tree.

On Wed, Aug 27, 2014 at 8:08 AM, Kevin Benton <blak111 at gmail.com> wrote:

> 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 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.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140827/221cc486/attachment.html>

More information about the OpenStack-dev mailing list