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

Jeremy Stanley fungi at yuggoth.org
Wed Dec 2 20:33:36 UTC 2015


[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.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151202/8e347ed2/attachment.pgp>


More information about the OpenStack-dev mailing list