Open Stack

Excerpts from Clark Boylan's message of 2018-04-26 11:22:15 -0700:
> On Thu, Apr 26, 2018, at 7:27 AM, Sean McGinnis wrote:
> > On Wed, Apr 25, 2018 at 04:54:46PM -0400, Doug Hellmann wrote:
> > > It's time to talk about the next steps in our migration from python
> > > 2 to python 3.
> > > 
> > > [...]
> > > 
> > > 2. Change (or duplicate) all functional test jobs to run under
> > >    python 3.
> > 
> > As a test I ran Cinder functional and unit test jobs on bionic using 3.6. All
> > went well.
> > 
> > That made me realize something though - right now we have jobs that explicitly
> > say py35, both for unit tests and functional tests. But I realized setting up
> > these test jobs that it works to just specify "basepython = python3" or run
> > unit tests with "tox -e py3". Then with that, it just depends on whether the
> > job runs on xenial or bionic as to whether the job is run with py35 or py36.
> > 
> > It is less explicit, so I see some downside to that, but would it make sense to
> > change jobs to drop the minor version to make it more flexible and easy to make
> > these transitions?
> 
> One reason to use it would be local user simplicity. Rather than need to explicitly add new python3 releases to the default env list so that it does what we want every year or two we can just list py3,py2,linters in the default list and get most of the way there for local users. Then we can continue to be more specific in the CI jobs if that is desirable.
> 
> I do think we likely want to be explicit about the python versions we are using in CI testing. This makes it clear to developers who may need to reproduce or just understand why failures happen what platform is used. It also makes it explicit that "openstack runs on $pythonversion".
> 
> Clark
> 

Including support for local users to refer to "py3" makes sense, as long
as we don't come to rely on it in CI. Users can also always be more
explicit if they need to be when running tests locally.

Doug