Open Stack

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)