On 12/02/2015 04:11 PM, Matt Riedemann wrote: > > > On 12/2/2015 2:33 PM, Jeremy Stanley wrote: >> [Apologies for the delayed reply, after more than a week without >> Internet access it's taking me more than a week to catch up with >> everything on the mailing lists.] >> >> On 2015-11-20 10:21:47 +0000 (+0000), 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 >> >> Hopefully by the end of this week, once I finish making sure I'm up >> to speed on everything that's been said while I was out (anything >> less would be irresponsible of me). >> >>> 2) we do not remove the stable/juno branch >> >> As pointed out later in this thread by Alan, it's technically >> possible to use a tag instead of a branch name (after all, both are >> just Git refs in the end), and deleting the branch sends a clearer >> message that there are no new commits coming for stable/juno ever >> again. >> >>> 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 >> >> Our Grenade jobs are only using Python 2.7 anyway. >> >>> 2) We could do this with Ubuntu 1404 only >> >> That's the only place we run Grenade now that stable/icehouse is EOL >> (it was the last branch for which we supported Ubuntu 12.04). >> >>> 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? >> [...] >> >> There are no technical Infra-side blockers to changing how we've >> done this in the past and instead continuing to run stable/kilo >> Grenade jobs for some indeterminate period after stable/juno is >> dead, but it's also not (entirely) up to Infra to decide this. I >> defer to the Grenade maintainers and QA team to make this >> determination, and they seem to be pretty heavily against the idea. >> >>> 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? >> >> That's the kicker. As I explained earlier in the thread from which >> this one split, keeping Juno-era DevStack and Tempest and all the >> bits on which they rely working in our CI without being able to make >> any modifications to them is intractable (mainly because of the >> potential for behavior changes in transitive dependencies not under >> our control): >> >> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081109.html >> >> >>> 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? >> >> Yes. This is how we arrived at the EOL timeline for stable/juno in >> the first place: gauging our ability to keep running things like >> DevStack and Tempest on it. Now is not the time to discuss how we >> can keep Juno on some semblance of life support (that discussion >> concluded more than a year ago), it's time for discussing what we >> can implement in Mitaka so we have more reasonable options for >> keeping the stable/mitaka branch healthy a year from now. >> >> >> >> __________________________________________________________________________ >> >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > I agree with Jeremy. We might be able to consider something like this > for stable/liberty, since that's when we started doing > upper-constraints, which should make the dependency creep more manageable.
However, only if there are enough active QA contributors / reviewers to keep up on this. Which means anyone interested in this needs to start engaging and ramping up on Tempest / Devstack / Grenade on master *now*. People showing up the month before eol, and only focussing on the eoled elements is not productive. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev