Open Stack

On Wed, Nov 13, 2013 at 7:49 AM, Thierry Carrez <thierry at openstack.org>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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.
>

This was my main concern for making this an incubation requirement, too.
It's not that I think the new project will have a lot of trouble with it,
but any questions they do have will need to be answered by a team that is
already operating pretty close to capacity. If you think the teams in
question can take on the extra potential load, then I like the idea.


>
> 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.
>
> (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.
>

Can we be more clear about documenting which projects are doing upgrade
testing, so users of projects who are not won't be surprised (and can
potentially apply pressure to the developers)?


>
> > [...] 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.
>

+1

Doug


>
> - --
> Thierry Carrez (ttx)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSg3VDAAoJEFB6+JAlsQQjuRQP/1kuDunU9mcwbAcqYbcnqG2A
> hBmiUxWHqe43/piN5iPwWu8/eLhl6AzQaQhRQVU/+Vv4E2yx+1rhhrTd2KmPXjmK
> kgJlI1rlGNVR18TQazjGq5KPR9LQ12hpLqouqDMGs7U1JRNFF6NdUVO1xY46Mvli
> z+vDH81lWdemIE/lAvF+IgPuHE6baPMbRl9OKHJbiF/2LE5aGgf1PuERHphOqYz9
> r/AMj4X9Kv3LAaCs4Gj6TFdY/Aqg8lsy64T/Ivme/xPkTN06gUG10ZaJaTE87jST
> WduVks5auzgSUOVPjVlMuW3vCm6i/lopoX8fThgiNZ0pp3sqZJgtMMYF73ab3FYI
> YU3VrrOjHpABU0rhInswSgPgkcBrTmVMH8ZQGGGVYiCpkDJwTirEf7U5/kDeKTXf
> K7MttUXl7fItWsRLgqV/7eDHApSmTWAuGiQQ2PuGRKZ8Zmvro/6CkPLwltB4rQ7S
> GjkHg6xvKjPp5wCF42mxkvyv4QJ/mxLmVjqHYXErk/WUVTlzyrGS49471ymk/zvJ
> TnRphEqFsTSggdQxXK1mQzwfSf4tIztZIgA1oV0eqOzPcjKJcFfd/NPnKnDzV0dp
> 8453mw+HsCa22lVWIvU+FhsLl+eC3quZLTmaKsdIINYRtOLcbSCm5s5Yfabjqxcx
> G/LwvW/BarVwxxrJoOFn
> =6/rB
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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/20131113/cd93a492/attachment.html>