[Openstack-operators] [openstack-dev] [stable][all] Keeping Juno "alive" for longer.
mriedem at linux.vnet.ibm.com
Fri Nov 6 15:51:13 UTC 2015
On 11/6/2015 9:20 AM, Matt Riedemann wrote:
> On 11/6/2015 4:43 AM, Thierry Carrez wrote:
>> Tony Breeds wrote:
>>> 1) Is it even possible to keep Juno alive (is the impact on the
>>> project as
>>> a whole acceptable)?
>> It is *technically* possible, imho. The main cost to keep it is that the
>> branches get regularly broken by various other changes, and those breaks
>> are non-trivial to fix (we have taken steps to make branches more
>> resilient, but those only started to appear in stable/liberty). The
>> issues sometimes propagate (through upgrade testing) to master, at which
>> point it becomes everyone's problem to fix it. The burden ends up
>> falling on the usual gate fixers heroes, a rare resource we need to
>> So it's easy to say "we should keep the branch since so many people
>> still use it", unless we have significantly more people working on (and
>> capable of) fixing it when it's broken, the impact on the project is
>> just not acceptable.
>> It's not the first time this has been suggested, and every time our
>> answer was "push more resources in fixing existing stable branches and
>> we might reconsider it". We got promised lots of support. But I don't
>> think we have yet seen real change in that area (I still see the same
>> usual suspects fixing stable gates), and things can still barely keep
>> afloat with our current end-of-life policy...
>> Stable branches also come with security support, so keeping more
>> branches opened mechanically adds to the work of the Vulnerability
>> Management Team, another rare resource.
>> There are other hidden costs on the infrastructure side (we can't get
>> rid of a number of things that we have moved away from until the old
>> branch still needing those things is around), but I'll let someone
>> closer to the metal answer that one.
>>> Assuming a positive answer:
>>> 2) Who's going to do the work?
>>> - Me, who else?
>>> 3) What do we do if people don't actually do the work but we as a
>>> have made a commitment?
>> In the past, that generally meant people opposed to the idea of
>> extending support periods having to stand up for the community promise
>> and fix the mess in the end.
>> PS: stable gates are currently broken for horizon/juno, trove/kilo, and
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> In general I'm in favor of trying to keep the stable branches available
> as long as possible because of (1) lots of production deployments not
> upgrading as fast as we (the dev team) assume they are and (2)
> backporting security fixes upstream is much nicer as a community than
> doing it out of tree when you support 5+ years of releases.
> Having said that, the downside points above are very valid, i.e. not
> enough resources to help, we want to drop py26, things get wedged easily
> and there aren't people around to monitor or fix it, or understand how
> all of the stable branch + infra + QA stuff fits together.
> It also extends the life and number of tests that need to be run against
> things in Tempest, which already runs several dozen jobs per change
> proposed today (since Tempest is branchless).
> At this point stable/juno is pretty much a goner, IMO. The last few
> months of activity that I've been involved in have been dealing with
> requirements capping issues, which as we've seen you fix one issue to
> unwedge a project and with the g-r syncs we end up breaking 2 other
> projects, and the cycle never ends.
> This is not as problematic in stable/kilo because we've done a better
> job of isolating versions in g-r from the start, but things won't get
> really good until stable/liberty when we've got upper-constraints in
> So I'm optimistic that we can keep stable/kilo around and working longer
> than what we've normally done in the past, but I don't hold out much
> hope for stable/juno at this point given it's current state.
Didn't mean to break the cross-list chain.
More information about the OpenStack-operators