<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> 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.<br>
 <br>
> I have a review here for the zuul project template enablement for ussuri:<br>
> <a href="https://review.opendev.org/#/c/693401" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/693401</a><br>
<br>
I do not think it should be added to the ussuri jobs template. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Otherwise as maybe a periodic job for now so it doesn't add to the run time and noise on every patch being submitted.<br>
<br></blockquote><div><br></div><div>Do you feel the same on the 2 points above for unit test enablement?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Any idea so far from manual py38 testing if there are breaking changes that are going to impact us?<br></blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 <br>
> Also should this be updated considering py38 would be non-voting?<br>
> <a href="https://governance.openstack.org/tc/reference/runtimes/ussuri.html%5Bhttps://governance.openstack.org/tc/reference/runtimes/ussuri.html%5D" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/reference/runtimes/ussuri.html[https://governance.openstack.org/tc/reference/runtimes/ussuri.html]</a><br>
<br>
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.<br></blockquote><div><br></div><div>Ok, makes sense.<br></div><div><br></div><div>Thanks,</div><div>Corey<br></div></div></div>