Open Stack

>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 feature like DVR. Even
with a limited API change (the new distributed flag), it has an impact on
the the router/agent DB resource model and currently isn't compatible with
VLAN based ML2 deployments. It's not exactly a hidden optimization like an
improvement to some RPC handling code.

A huge piece of the DVR development had to happen in Neutron forks and 40+
revision chains of Gerrit patches. It was very difficult to follow without
being heavily involved with the L3 team. This would have been a
great candidate to develop in the incubator if it existed at the time. It
would have been easier to try as it was developed and to explore the entire
codebase. Also, more people could have been contributing bug fixes and
improvements since an entire section of code wouldn't be 'owned' by one
person like it is with the author of a Gerrit review.

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

As was pointed out before, common interest has nothing to do with
incubation. Incubation is to rapidly iterate on a new feature for Neutron.
It shouldn't be restricted to API changes, it should be used for any major
new features that are possible to develop outside of the Neutron core. If
we are going to have this new incubator tool, we should use it to the
fullest extent possible.


On Tue, Aug 26, 2014 at 6:19 PM, loy wolfe <loywolfe at 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. 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
>>
>>
>
> _______________________________________________
> 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/20140826/821b8d0b/attachment.html>