On Aug 28, 2014, at 10:45 AM, Jay Pipes <[email protected]> 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 merged. > > Right. The special unicorns. > > > In that case it might >> not make sense to have a life cycle of their own in another repo >> indefinitely. > > The main reasons these "experimental components" don't make sense to live in > their own repo indefinitely are: > > a) Neutron's design doesn't make it easy or straightforward to build/layer > other things on top of it, or: >
Correct and this something I want the team to address in Kilo. Many of the L7 services would be easier to build if we invest some time early in the cycle to establishing a well defined interface for a few items. I’m sure the LBaaS team has good feedback to share with everyone. > b) The experimental piece of code intends to replace whole-hog a large chunk > of Neutron's existing codebase, or: > > 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 I’m glad Jim reminded us of the pain of merging histories and the availability of feature branches. I think for items where we’re replacing large chunks of code feature branches make lots of sense. > > 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. > > 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. Right hopefully the incubator will allow us to develop components that should be independent from the start without incurring too much debt. > > -jay > >> On Wed, Aug 27, 2014 at 11:52 AM, Jay Pipes <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 08/26/2014 07:09 PM, James E. Blair wrote: >> >> Hi, >> >> After reading >> https://wiki.openstack.org/__wiki/Network/Incubator >> <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 >> generally do a >> lot of importing code into projects. We've done this once, to my >> recollection, in a way that preserved history, and that was with the >> switch to keystone-lite. >> >> It wasn't easy; it's major git surgery and would require significant >> infra-team involvement any time we wanted to do it. >> >> However, reading the proposal, it occurred to me that it's >> pretty clear >> that we expect these tools to be able to operate outside of the >> Neutron >> project itself, to even be releasable on their own. Why not >> just stick >> with that? In other words, the goal of this process should be >> to create >> separate projects with their own development lifecycle that will >> continue indefinitely, rather than expecting the code itself to >> merge >> into the neutron repo. >> >> This has advantages in simplifying workflow and making it more >> consistent. Plus it builds on known integration mechanisms like >> APIs >> and python project versions. >> >> But more importantly, it helps scale the neutron project itself. I >> think that a focused neutron core upon which projects like these can >> build on in a reliable fashion would be ideal. >> >> >> Despite replies to you saying that certain branches of Neutron >> development work are special unicorns, I wanted to say I *fully* >> support your above statement. >> >> Best, >> -jay >> >> >> >> _________________________________________________ >> OpenStack-dev mailing list >> [email protected].__org >> <mailto:[email protected]> >> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >> >> >> >> >> -- >> Kevin Benton >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
