Open Stack

On Wed, Apr 25, 2018, at 3:25 PM, Doug Hellmann wrote:
> Excerpts from Jeremy Stanley's message of 2018-04-25 21:40:37 +0000:
> > On 2018-04-25 16:54:46 -0400 (-0400), Doug Hellmann wrote:
> > [...]
> > > Still, we need to press on to the next phase of the migration, which
> > > I have been calling "Python 3 first". This is where we use python
> > > 3 as the default, for everything, and set up the exceptions we need
> > > for anything that still requires python 2.
> > [...]
> > 
> > It may be worth considering how this interacts with the switch of
> > our default test platform from Ubuntu 16.04 (which provides Python
> > 3.5) to 18.04 (which provides Python 3.6). If we switch from 3.5 to
> > 3.6 before we change most remaining jobs over to Python 3.x versions
> > then it gives us a chance to spot differences between 3.5 and 3.6 at
> > that point. Given that the 14.04 to 16.04 migration, where we
> > attempted to allow projects to switch at their own pace, didn't go
> > so well we're hoping to do a "big bang" migration instead for 18.04
> > and expect teams who haven't set up experimental jobs ahead of time
> > to work out remaining blockers after the flag day before they can go
> > back to business as usual. Since the 18.04 release is happening so
> > far into the Rocky cycle, we're likely to want to do that at the
> > start of Stein instead when it will be less disruptive.
> > 
> > So I guess that raises the question: switch to Python 3.5 by default
> > for most jobs in Rocky and then have a potentially more disruptive
> > default platform switch with Python 3.5->3.6 at the beginning of
> > Stein, or wait until the default platform switch to move from Python
> > 2.7 to 3.6 as the job default? I can see some value in each option.
> 
> Does 18.04 include a python 2 option?

It does, https://packages.ubuntu.com/bionic/python2.7.

> 
> What is the target for completing the changeover? The first or
> second milestone for Stein, or the end of the cycle?

Previously we've tried to do the transition in OpenStack release that is under development when the LTS releases. However we've offset things a bit now so that may not be as feasible. I would expect that if we waited for the next cycle we would do it very early in that cycle.

For the transition from python 3.5 on Xenial to 3.6 on Bionic we may want to keep the python 3.5 jobs on Xenial but add in non voting python 3.6 jobs to every project running Xenial python3.5 jobs. Then those projects can toggle them to voting 3.6 jobs if/when they start working. Then we can decide at a later time if continuing to support python 3.5 (and testing it) is worthwhile.

> 
> It would be useful to have some input from the project teams who
> have no unit or functional test jobs running for 3.5, since they
> will have the most work to do to cope with the upgrade overall.
> 
> Who is coordinating Ubuntu upgrade work and setting up the experimental
> jobs?

Paul Belanger has been doing much of the work to get the images up and running and helping some projects start to run early jobs on the beta images. I expect Paul would want to continue to carry the transition through to the end.

Clark