[tc] Add non-voting py38 for ussuri

Corey Bryant corey.bryant at canonical.com
Fri Nov 8 14:09:51 UTC 2019

On Thu, Nov 7, 2019 at 5:56 PM Sean McGinnis <sean.mcginnis at gmx.com> 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.

Just to be clear I'm only talking about unit tests right now which are
generally light on resource requirements. However it would be great to also
have py38 function test enablement and periodic would make sense for
function tests at this point. For unit tests though it seems the benefit of
knowing whether your patch regresses unit tests for the latest python
version far outweighs the resources required, so I don't see much benefit
in adding periodic unit test jobs.

> > 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.
Do you feel the same on the 2 points above for unit test enablement?

Any idea so far from manual py38 testing if there are breaking changes that
> are going to impact us?

I don't have enough details yet so I'll have to get back to you on that but
yes there is breakage that I haven't dug into yet.

> > 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.

Ok, makes sense.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191108/5aa24b88/attachment.html>

More information about the openstack-discuss mailing list