<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 13, 2019 at 3:36 PM Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Nov 8, 2019, at 6:09 AM, Corey Bryant wrote:<br>
> <br>
> <br>
> On Thu, Nov 7, 2019 at 5:56 PM Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com" target="_blank">sean.mcginnis@gmx.com</a>> wrote:<br>
> > My non-TC take on this...<br>
> > <br>
> > <br>
> >  > 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.<br>
> > <br>
> >  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.<br>
> <br>
> Just to be clear I'm only talking about unit tests right now which are <br>
> generally light on resource requirements. However it would be great to <br>
> also have py38 function test enablement and periodic would make sense <br>
> for function tests at this point. For unit tests though it seems the <br>
> benefit of knowing whether your patch regresses unit tests for the <br>
> latest python version far outweighs the resources required, so I don't <br>
> see much benefit in adding periodic unit test jobs.<br>
> <br>
<br>
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 <a href="https://graphite.opendev.org" rel="noreferrer" target="_blank">https://graphite.opendev.org</a>. 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.<br>
<br>
It is large multinode integration jobs that run for extended periods of time that have the greatest impact on our resource utilization.<br>
<br>
Clark<br>
<br></blockquote><div> </div><div>That's great, thanks for sharing. Per job would be a super nice addition.<br></div><div><br></div><div>Corey<br></div></div></div>