Open Stack

> -----Original Message-----
> From: Jeremy Stanley [mailto:fungi at yuggoth.org]
> Sent: Wednesday, December 02, 2015 8:34 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno)
> WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> 
> [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

Thanks for two detailed reply Jeremy!

I think this (and the one you replied to Rocky) gives enough background in compact package for interested parties to start focusing their efforts to the direction they seem appropriate. Let's see where we are in a year's time.

- Erno