Open Stack

On Wed, Nov 13, 2013 at 9:14 PM, Sean Dague <sean at dague.net> wrote:

> On 11/13/2013 07:49 AM, Thierry Carrez wrote:
> > Sean Dague wrote:
> >> [...] Proposed Incubation requirements
> >> ================================ Once something becomes an
> >> integrated project, it's important that they are able to run in the
> >> gate.
> >
> >> Both devstack and devstack-gate now support hooks, so with a couple
> >> of days of work any project in stackforge could build a gate job
> >> which sets up a devstack of their configuration, including their
> >> code, running some project specific test they feel is appropriate
> >> to ensure they could run in the gate environment.
> >
> >> This would ensure an incubated project works with OpenStack global
> >> requirements, or if it requires something new, that's known very
> >> clearly before incubation.
> >
> > That makes sense, my only concern with it is, how much support from
> > QA/Infra would actually be needed *before* incubation can even be
> > requested. One of the ideas behind the incubation status is to allow
> > incubated projects to tap into common resources (QA, infra, release
> > management...) as they cover the necessary ground before being fully
> > integrated. Your proposal sounds like they would also need some
> > support even before being incubated.
> >
> > Also does it place a requirement that all projects wanting to request
> > incubation to be placed in stackforge ? That sounds like a harsh
> > requirement if we were to reject them.
>
> I'm not sure I consider that all that harsh. If they want to incubate,
> they want to be part of the OpenStack universe. Previously we could do
> this ad-hoc with projects that were fully formed like Heat, but I think
> as we grow, that's going to be really hard to do.
>
> If you are in stackforge that means you are used to the tooling and flow
> of OpenStack. Lighting a stackforge repository means you understand the
> OpenStack config repo enough to post a patch, and have talked with
> -infra enough to get it landed (realistically it's only a few days worth
> of work, and ensures some basic early connection to the culture of
> OpenStack).
>
> Stackforge already has a ton of stuff that's in no way ready to incubate
> (or that never would), so that barrier doesn't seem that high to me. And
> I'd rather see a project go through the effort up front to show they
> actually have the bw to do something like that (because if they don't,
> they won't make it very far in incubation.)
>
> > (sidenote: I'm planning to suggest we create an "emerging technology"
> > label for projects that are (1) in stackforge, (2) applied for
> > incubation but got rejected purely for community maturity reasons.
> > Projects under this label would potentially get some limited space at
> > summits to gain more visibility. Designate belongs to that category,
> > but without a clear label it seems to fall in the vast bucket of
> > openstack-related projects and not gaining more traction. Not sure we
> > can leverage it to solve the issue here though).
> >
> >> Proposed Graduation requirements ================================
> >> All integrated projects should be in the integrated gate, as this
> >> is the only way we provably know that they can all work together,
> >> at the same level of requirements, in a consistent way.
> >
> >> During incubation landing appropriate tests in Tempest is fair
> >> game. So the expectation would be that once a project is incubated
> >> they would be able to land tests in tempest. Before integrated
> >> we'd need to ensure the project had tests which could take part in
> >> the integrated gate, so as soon as a project is voted integrated,
> >> it has some working integrated gate tests. (Note: there is actually
> >> a symmetric complexity here, to be worked out later).
> >
> > +1 -- I think we already made that decision for any future graduation.
> >
> >> Proposed Stable Release requirements
> >> ==================================== We have this automatic
> >> transition that happens when a project that's integrated for a
> >> release, actually releases as part of that. I.e. Trove and
> >> Icehouse. There is no additional TC decision about whether or not
> >> Trove is part of the stable release, once integrated, it just is.
> >> Nothing that it does over that cycle will kick it out of the stable
> >> release. This is one of the reasons it needs to be in the
> >> integrated gate **before** graduation.
> >
> >> Additionally, upgrade path is critically important to our users,
> >> and the number one piece of feedback we received from the User
> >> Survey. It was also important enough to our developers that it was
> >> scattered all over the Icehouse Design Summit. All integrated
> >> projects should be included in upgrade testing the moment they are
> >> in a stable release. (ex: when Icehouse is released, Trove should
> >> be in master grenade, and upgrade testing from Icehouse -> master
> >> for the J cycle from day one).
> >
> > I agree with you, but I don't see how we can enforce this one. Like
> > you say, integrated projects get commonly released and get a stable
> > branch in all cases. We can strongly encourage them to get their
> > grenade act together before the final release, but there is nothing we
> > can do (short of kicking them out of the integrated release
> > altogether) to ensure it happens.
>
> I think we enforce it with requiring an upgrade test plan as part of
> graduation, so it's a known future thing they need to ensure happens.
> Then, realistically, it should be pretty easy to execute on in most
> cases (the cross service deprecation is a harder question, but that's
> why a plan pre-graduation is required).
>
> >> [...] Raised Questions ================ - what about existing
> >> incubated projects, what would be their time frame to get with this
> >> new program - what about existing integrated projects that
> >> currently don't exist with either an upgrade or gate story? - what
> >> about an upgrade deprecation path (i.e. nova-network => neutron,
> >> nova-baremetal => ironic)
> >
> > The transition for existing incubated/integrated projects is an
> > interesting question. I think it's fine to require that
> > currently-incubated projects get into the integrated gate before they
> > can graduate. For currently-integrated projects that are not up to
> > snuff, I think we should strongly suggest that they fix it before the
> > icehouse release, otherwise the next TC might be driven to make
> > unpleasant decisions.
>
> Agreed. I think setting the bar where we want it to be for Integrated
> and strongly saying we expect getting to that bar to be a top priority
> for existing projects by end of cycle would be the right thing to do.
>

+1, so it sounds like most projects have some work to do, to avoid any
unpleasant decisions in J.

It would be great to have a document tracking the state of
currently-integrated projects, so we have no surprises later on.  Partially
because having enough useful tests in the gate is somewhat of a judgment
call, so it would be nice to have a clear record tracking things.



>
> For incubated projects, I would propose we give them the cycle to
> retroactively meet the bar we're talking about for incubation (which,
> again, should only be about 2 days of work if their software can
> actually run in an OpenStack cloud), and if they don't meet it by end of
> cycle, they de-incubate. For instance, Savana is almost already there,
> the devstack plugin mechanism was largely driven to let them hook into
> devstack pre-incubation, without code in the devstack tree. Special
> circumstances accepted, but Ironic and Savana are already well under way
> here.
>
>         -Sean
>
>
Sean,
thanks for starting this conversation, I am really happy to see us having
it.


>  --
> Sean Dague
> http://dague.net
>
>
> _______________________________________________
> 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/20131114/619405eb/attachment.html>