[tc] Add non-voting py38 for ussuri
corey.bryant at canonical.com
Thu Nov 14 13:47:35 UTC 2019
On Wed, Nov 13, 2019 at 3:36 PM Clark Boylan <cboylan at sapwetik.org> wrote:
> On Fri, Nov 8, 2019, at 6:09 AM, Corey Bryant wrote:
> > On Thu, Nov 7, 2019 at 5:56 PM Sean McGinnis <sean.mcginnis at gmx.com>
> > > 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.
> Wanted to point out that we've begun to expose resource consumption in
> nodepool to graphite. You can find per project and per tenant resource
> usage under stats.zuul.nodepool.resources at https://graphite.opendev.org.
> Unfortunately, I don't think we have per job resource tracking there yet,
> but previous measurements from log files do agree that unittest consumption
> is relatively low.
> It is large multinode integration jobs that run for extended periods of
> time that have the greatest impact on our resource utilization.
That's great, thanks for sharing. Per job would be a super nice addition.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openstack-discuss