[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
