<div dir="ltr">><span style="font-family:arial,sans-serif;font-size:13px">Right. The special unicorns.</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div>Repeating this without defining it isn't helping anything.</div>
<div><br></div><div>><span style="font-family:arial,sans-serif;font-size:13px">b) The experimental piece of code intends to replace whole-hog a large chunk of Neutron's existing codebase, or:</span></div><br style="font-family:arial,sans-serif;font-size:13px">
<div>In the DVR example I gave this is is the only relevant reason. Regardless of how well the internal Neutron APIs are defined, this same problem would have arisen. DVR completely changed the reference L3 service plugin, which lives in the main tree. </div>
<div><br></div><div>A well-defined, versioned internal API would not have helped any of the issues I brought up. The 'experimental' part of the DVR work isn't referring to its internal API modifications, its referring to how the L3 service plugin will integrate with the data plane. </div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 7:45 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 08/27/2014 04:28 PM, Kevin Benton wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What are you talking about? The only reply was from me clarifying that<br>
one of the purposes of the incubator was for components of neutron that<br>
are experimental but are intended to be merged.<br>
</blockquote>
<br></div>
Right. The special unicorns.<div class=""><br>
<br>
> In that case it might<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
not make sense to have a life cycle of their own in another repo<br>
indefinitely.<br>
</blockquote>
<br></div>
The main reasons these "experimental components" don't make sense to live in their own repo indefinitely are:<br>
<br>
a) Neutron's design doesn't make it easy or straightforward to build/layer other things on top of it, or:<br>
<br>
b) The experimental piece of code intends to replace whole-hog a large chunk of Neutron's existing codebase, or:<br>
<br>
c) The experimental piece of code relies so heavily on inconsistent, unversioned internal interface and plugin calls that it cannot be designed externally due to the fragility of those interfaces<br>
<br>
Fixing a) is the solution to these problems. An incubator area where "experimental components" can live will just continue to mask the true problem domain, which is that Neutron's design is cumbersome to build on top of, and its cross-component interfaces need to be versioned, made consistent, and cleaned up to use versioned data structures instead of passing random nested dicts of randomly-prefixed string key/values.<br>
<br>
Frankly, we're going through a similar problem in Nova right now. There is a group of folks who believe that separating the nova-scheduler code into the Gantt project will magically make placement decision code and solver components *easier* to work on (because the pace of coding can be increased if there wasn't that pesky nova-core review process). But this is not correct, IMO. Separating out the scheduler into its own project before internal interfaces and data structures are cleaned up and versioned will just lead to greater technical debt and an increase in frustration on the part of Nova developers and scheduler developers alike.<br>
<br>
-jay<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
On Wed, Aug 27, 2014 at 11:52 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a><br></div><div class="">
<mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>> wrote:<br>
<br>
On 08/26/2014 07:09 PM, James E. Blair wrote:<br>
<br>
Hi,<br>
<br>
After reading<br></div>
<a href="https://wiki.openstack.org/__wiki/Network/Incubator" target="_blank">https://wiki.openstack.org/__<u></u>wiki/Network/Incubator</a><div><div class="h5"><br>
<<a href="https://wiki.openstack.org/wiki/Network/Incubator" target="_blank">https://wiki.openstack.org/<u></u>wiki/Network/Incubator</a>> I have<br>
some thoughts about the proposed workflow.<br>
<br>
We have quite a bit of experience and some good tools around<br>
splitting<br>
code out of projects and into new projects. But we don't<br>
generally do a<br>
lot of importing code into projects. We've done this once, to my<br>
recollection, in a way that preserved history, and that was with the<br>
switch to keystone-lite.<br>
<br>
It wasn't easy; it's major git surgery and would require significant<br>
infra-team involvement any time we wanted to do it.<br>
<br>
However, reading the proposal, it occurred to me that it's<br>
pretty clear<br>
that we expect these tools to be able to operate outside of the<br>
Neutron<br>
project itself, to even be releasable on their own. Why not<br>
just stick<br>
with that? In other words, the goal of this process should be<br>
to create<br>
separate projects with their own development lifecycle that will<br>
continue indefinitely, rather than expecting the code itself to<br>
merge<br>
into the neutron repo.<br>
<br>
This has advantages in simplifying workflow and making it more<br>
consistent. Plus it builds on known integration mechanisms like<br>
APIs<br>
and python project versions.<br>
<br>
But more importantly, it helps scale the neutron project itself. I<br>
think that a focused neutron core upon which projects like these can<br>
build on in a reliable fashion would be ideal.<br>
<br>
<br>
Despite replies to you saying that certain branches of Neutron<br>
development work are special unicorns, I wanted to say I *fully*<br>
support your above statement.<br>
<br>
Best,<br>
-jay<br>
<br>
<br>
<br></div></div>
______________________________<u></u>___________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.<u></u>__org<br>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
<a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-dev</a> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a>><div class="">
<br>
<br>
<br>
<br>
<br>
--<br>
Kevin Benton<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>