<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 7:14 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 11/13/2013 07:49 AM, Thierry Carrez wrote:<br>


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

<div class="im">
>> [...] Raised Questions ================ - what about existing<br>
>> incubated projects, what would be their time frame to get with this<br>
>> new program - what about existing integrated projects that<br>
>> currently don't exist with either an upgrade or gate story? - what<br>
>> about an upgrade deprecation path (i.e. nova-network => neutron,<br>
>> nova-baremetal => ironic)<br>
><br>
> The transition for existing incubated/integrated projects is an<br>
> interesting question. I think it's fine to require that<br>
> currently-incubated projects get into the integrated gate before they<br>
> can graduate. For currently-integrated projects that are not up to<br>
> snuff, I think we should strongly suggest that they fix it before the<br>
> icehouse release, otherwise the next TC might be driven to make<br>
> unpleasant decisions.<br>
<br>
</div>Agreed. I think setting the bar where we want it to be for Integrated<br>
and strongly saying we expect getting to that bar to be a top priority<br>
for existing projects by end of cycle would be the right thing to do.<br>
<br>
For incubated projects, I would propose we give them the cycle to<br>
retroactively meet the bar we're talking about for incubation (which,<br>
again, should only be about 2 days of work if their software can<br>
actually run in an OpenStack cloud), and if they don't meet it by end of<br>
cycle, they de-incubate. For instance, Savana is almost already there,<br>
the devstack plugin mechanism was largely driven to let them hook into<br>
devstack pre-incubation, without code in the devstack tree. Special<br>
circumstances accepted, but Ironic and Savana are already well under way<br>
here.<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>Seems reasonable to me. The main need is communication about the requirements.</div><br class="">It also makes me realize I'd better get the docs team thinking about what minimum doc requirements we should have for any transition (incubated, integrated, upgrade/migrate). It seems you have a good outline for setting expectations. I want to do the same for docs (while also pointing out where such expectations could overwhelm current resources).</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">Anne<br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<span class=""><font color="#888888">
        -Sean<br>
</font></span><div class=""><div class="h5"><br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Anne Gentle<br><a href="mailto:annegentle@justwriteclick.com" target="_blank">annegentle@justwriteclick.com</a>
</div></div>