Open Stack

On Thu, Nov 07, 2019 at 08:10:05PM -0500, Nate Johnston wrote:
> On Thu, Nov 07, 2019 at 11:56:51PM +0100, 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.
> 
> Would it be possible to add it to the template, but under the
> experimental queue?  That way we leverage the template's ability to do
> the work for all projects but the job won't be executed without a
> specific experimental check.

Personally from neutron point of view I think that periodic is better than
experimental as with periodic jobs we don't need to do any additional actions to
run this job and see results. And we are checking periodic jobs' results every
week on CI meeting.
But ofcourse experimental would also work :)

> 
> Thanks,
> 
> Nate
> 
> > 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.
> > 
> 
> 

-- 
Slawek Kaplonski
Senior software engineer
Red Hat