On Wed, Nov 13, 2013 at 9:14 PM, Sean Dague <s...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev