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) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
