[openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

Kuvaja, Erno kuvaja at hpe.com
Fri Nov 20 11:03:03 UTC 2015


> -----Original Message-----
> From: Thierry Carrez [mailto:thierry at openstack.org]
> Sent: Friday, November 20, 2015 10:45 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno)
> WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> 
> Kuvaja, Erno wrote:
> > So we were brainstorming this with Rocky the other night. Would this be
> possible to do by following:
> > 1) we still tag juno EOL in few days time
> > 2) we do not remove the stable/juno branch
> > 3) we run periodic grenade jobs for kilo
> >
> > I'm not that familiar with the grenade job itself so I'm doing couple of
> assumptions, please correct me if I'm wrong.
> > 1) We could do this with py27 only
> > 2) We could do this with Ubuntu 1404 only
> >
> > If this is doable would we need anything special for these jobs in infra point
> of view or can we just schedule these jobs from the pool running our other
> jobs as well?
> > If so is there still "quiet" slots on the infra utilization so that we would not
> be needing extra resources poured in for this?
> > Is there something else we would need to consider in QA/infra point of
> view?
> >
> > Benefits for this approach:
> > 1) The upgrade to kilo would be still tested occasionally.
> > 2) Less work for setting up the jobs as we do the installs from the
> > stable branch currently (vs. installing the last from tarball)
> >
> > What we should have as requirements for doing this:
> > 1) Someone making the changes to the jobs so that the grenade job gets
> ran periodically.
> > 2) Someone looking after these jobs.
> > 3) Criteria for stop doing this, X failed runs, some set timeperiod,
> > something else. (and removing the stable/juno branch)
> >
> > Big question ref the 2), what can we do if the grenade starts failing? In
> theory we won't be merging anything to kilo that _should_ cause this and we
> definitely will not be merging anything to Juno to fix these issues anymore.
> How much maintenance those grenade jobs themselves needs?
> >
> > So all in all, is the cost doing above too much to get indicator that tells us
> when Juno --> Kilo upgrade is not doable anymore?
> 
> Let's wait a bit for this discussion for the return of the Infra PTL from
> vacation, his input is critical to any decision we can make. Jeremy should be
> back on Monday.
> 
> --
> Thierry Carrez (ttx)

Sure, didn't know that he is on holidays, but there was a reason why I added infra and qa tags to the subject. Like you said infra being able to facilitate this is crucial for any plans.

- Erno
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list