Open Stack

Russell Bryant wrote:
> On 04/26/2013 10:26 AM, Monty Taylor wrote:
>> As it pertains to incubated splits and the deprecation of the feature in
>> the original project - what do we think the cutover should be? If, for
>> instance, we moved forward with Ironic as an incubated project, and then
>> accepted into integrated for "I" - since there had already been the
>> Havana cycle with the external project and the incubated project, do we
>> pull the code from nova in I? Or do we wait until J?
> 
> If there is a sufficiently documented migration path, I think pulling
> baremetal out of Nova in the same release Ironic becomes integrated
> would be acceptable (so, theoretically I in this case).

A separate project definitely makes sense to me. But I'm not sure this
would qualify for an incubation bypass.

The goal of incubation is to get the new project to align with the
release cycle and procedures, as well as refine its architecture and
integration points with other projects. There are two types of project
splits:

On one end of the spectrum you have the pure project split, same code
being copied and "feature parity" between the two implementations being
immediate. Then it's a no-brainer to fast-track the new project in
Havana, mark the original implementation deprecated in Havana, and rip
it out at the beginning of I. That's what Cinder did. It skipped
incubation because there was nothing to incubate about -- even its
development team was the same core people that worked on Nova, and the
Nova PTL even led the splitting effort.

On the other end there is the "new projects" approach, which is what the
project-previously-known-as-Quantum did: start as a new project, think
about all the ways it can be redesigned, and fight to get feature parity
before you can mark the original implementation deprecated and rip it
out. The team of people in charge of the new project is separate from
the core people from the original project, and still need to learn the
ropes of release cycles and integration with other projects.

With all the talk about "reaching feature parity" for Ironic vs. the
current nova-baremetal driver, and with the team of developers working
on Ironic being relatively disjoint from the Nova team and PTL, I think
we are closer from the latter case than from the former, so I think the
project should go through an incubation period.

It can look like this:
* Copy the code to a new project, make it work
* File and get accepted for incubation before mid-H cycle
* Graduate at the end of H to be an Integrated project in I

The only tricky bit is, can we mark nova-baremetal deprecated in H
release, while there is no Ironic "integrated" release before the "I"
release time ? Or should nova-baremetal be marked deprecated at the
start of the I cycle and fully removed in J ?

Given that nova-baremetal is pretty new and that we should have a usable
version of Ironic around H release time, I think marking nova-baremetal
deprecated in Havana Nova is acceptable...

-- 
Thierry Carrez (ttx)
Chair, OpenStack Technical Committee