Open Stack

On 11/7/19 11:56 PM, Sean McGinnis wrote:
> My non-TC take on this...
> 
>  
>> Python 3.8 is available in Ubuntu Bionic now and while I understand it's too late to enable voting py38 unit tests for ussuri, I'd like to at least enable non-voting py38 unit tests. This email is seeking approval and direction from the TC to move forward with enabling non-voting py38 tests.
> 
> I think it would be great to start testing 3.8 so there are no surprises once we need to officially move there. But I would actually not want to see that run on every since patch in every single repo.
> 
>> For some further background: The next release of Ubuntu, Focal (20.04) LTS, is scheduled to release in April 2020. Python 3.8 will be the default in the Focal release, so I'm hopeful that non-voting unit tests will help close some of the gap.
>  
>> I have a review here for the zuul project template enablement for ussuri:
>> https://review.opendev.org/#/c/693401
> 
> I do not think it should be added to the ussuri jobs template.
> 
> I think it would be more useful as its own job for now that can be added to a select few repos as a full tempest run so a smaller number of test runs can cover a broader cross-section of projects.
> 
> Otherwise as maybe a periodic job for now so it doesn't add to the run time and noise on every patch being submitted.
> 
> Any idea so far from manual py38 testing if there are breaking changes that are going to impact us?
>  
>> Also should this be updated considering py38 would be non-voting?
>> https://governance.openstack.org/tc/reference/runtimes/ussuri.html[https://governance.openstack.org/tc/reference/runtimes/ussuri.html]
> 
> I not think it would be appropriate to list 3.8 under the Ussuri runtimes. That should only list the officially targeted runtimes for the release.

Sean and everyone else,

Pardon me, but I have to rant here... :)
Please try see things from a downstream consumer point of view.

This isn't the Python 2.7 era anymore, where we had a stable python for
like forever. OpenStack needs to move quicker to newer Python 3
versions, especially considering that Python 2.7 isn't an option for
anyone anymore. While your proposal (ie: less jobs on Python 3.8) looks
like a nice first approach, it is my strong believe that the project
should quickly move to voting and full Python 3.8 testing, and
preferably, have it in order, with functional testing, for the whole
project, by the time Ussuri is released.

I know what's going to happen: I'll tell about a bug in Python 3.8 on
IRC, and someone will reply to me "hey, that's not supported by
OpenStack before the V release, please go away", even though as
downstream distribution package maintainer, we don't have the power to
decide what version of Python our distribution runs on (ie: both Debian
Sid, Ubuntu and Fedora are quickly moving targets).

There's absolutely no excuse for the OpenStack project to be dragging
its feet, apart maybe the fact that it may not be easy to setup the
infra to run tests on Py3.8 just yet. It isn't a normal situation that
downstream distributions get the shit (pardon my french) and get to be
the ones fixing issues and proposing patches (Corey, you've done awesome
job on this...), yet it's been the case for nearly every single Python 3
releases. I very much would appreciate this situation to be fixed, and
the project moving faster.

Cheers,

Thomas Goirand (zigo)