[openstack-dev] [python3] Enabling py37 unit tests

Zane Bitter zbitter at redhat.com
Mon Oct 15 23:39:02 UTC 2018

On 15/10/18 4:10 PM, Jeremy Stanley wrote:
> On 2018-10-15 15:00:07 -0400 (-0400), Zane Bitter wrote:
> [...]
>> That said, I don't think we should be dropping support/testing for 3.5.
>> According to:
>>    https://governance.openstack.org/tc/reference/pti/python.html
>> 3.5 is the only Python3 version that we require all projects to run tests
>> for.
> Until we update it to refer to the version provided by the test
> platforms we document at:
> https://governance.openstack.org/tc/reference/project-testing-interface.html#linux-distributions

I'm sure we will update it, but as of now we haven't. People shouldn't 
have to guess which TC-maintained documentation is serious and which 
stuff they should just ignore on an ad-hoc basis. If it says 3.5 then 
the answer is 3.5 until somebody submits a patch and the TC approves it.

>> Out goal is to get everyone running 3.6 unit tests by the end of Stein:
>> https://governance.openstack.org/tc/goals/stein/python3-first.html#python-3-6-unit-test-jobs
>> but we explicitly said there that we were not dropping support for 3.5 as
>> part of the goal, and should continue to do so until we can effect an
>> orderly transition later.
> [...]
> We're not dropping support for 3.5 as part of the python3-first
> goal, but would be dropping it as part of the switch from Ubuntu
> 16.04 LTS (which provides Python 3.5) to 18.04 LTS (which provides
> Python 3.6). In the past the OpenStack Infra team has prodded us to
> follow our documented testing platform policies as new versions
> become available, but now with a move to providing infrastructure
> services to other OSF projects as well we're on our own to police
> this.
> We _could_ decide that we're going to start running tests on
> multiple versions of Python 3 indefinitely (rather than as a
> transitional state during the switch from Ubuntu Xenial to Bionic)

This is inevitable at some point - we say that we'll support both the 
latest release of Ubuntu LTS *and* CentOS. So far that's been irrelevant 
for Python3 because CentOS has only Python2, but we know that the next 
CentOS release will have Python3 and from that point on we will for sure 
be in a situation where we are supporting multiple Python3 versions, not 
always contiguous, for the indefinite future (because the release cycles 
of Ubuntu & CentOS are not aligned in any way).

In fact, as far as we know the version we have to support in CentOS may 
actually be 3.5, which seems like a good reason to keep it working for 
long enough that we can find out for sure one way or the other.

> but that does necessarily mean running more jobs. We could also
> decide to start targeting different versions of Python than provided
> by the distros on which we run our tests (and build it from source
> ourselves or something) but I think that's only reasonable if we're
> going to also recommend that users deploy OpenStack on top of
> custom-compiled Python interpreters rather than the interpreters
> provided by server distros like RHEL and Ubuntu.

I am definitely spoiled by Fedora, where I have every version from 3.3 
to 3.7 installed from the distro packages.

> So to sum up the above, it's less a question of whether we're
> dropping Python 3.5 testing in Stein, and more a question of whether
> we're going to continue requiring OpenStack to also be able to run
> on Ubuntu 16.04 LTS (which wasn't the latest LTS even at the start
> of the cycle).

There's actually another whole level of discussion we probably need to 
have. So far we've talked about unit tests, but running functional tests 
is whole other thing, and one we really do probably want to pick a 
single version of Ubuntu to run on for the sake of the gate (and I'd 
suggest that that version should probably by Bionic, if we can get 
everything working on 3.6 early enough in the cycle).

That process would have been a lot easier if we were earlier on 3.6, so 
I'm grateful to the folks who are already working on 3.7 (which is a 
much more substantial change) to hopefully make this less painful in the 


More information about the OpenStack-dev mailing list