[tc] Add non-voting py38 for ussuri
Hello TC members,
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.
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
Also should this be updated considering py38 would be non-voting? https://governance.openstack.org/tc/reference/runtimes/ussuri.html
Thanks, Corey
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.
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%5Bhttps:/...]
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.
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.
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%5Bhttps:/...]
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.
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%5Bhttps:/...]
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.
On Thu, Nov 7, 2019 at 5:56 PM Sean McGinnis sean.mcginnis@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%5Bhttps:/...]
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.
Thanks, Corey
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@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.
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.
Clark
On Wed, Nov 13, 2019 at 3:36 PM Clark Boylan cboylan@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@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.
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.
Clark
That's great, thanks for sharing. Per job would be a super nice addition.
Corey
On 11/7/19 11:56 PM, 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.
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%5Bhttps:/...]
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.
Sean and everyone else,
Pardon me, but I have to rant here... :) Please try see things from a downstream consumer point of view.
This isn't the Python 2.7 era anymore, where we had a stable python for like forever. OpenStack needs to move quicker to newer Python 3 versions, especially considering that Python 2.7 isn't an option for anyone anymore. While your proposal (ie: less jobs on Python 3.8) looks like a nice first approach, it is my strong believe that the project should quickly move to voting and full Python 3.8 testing, and preferably, have it in order, with functional testing, for the whole project, by the time Ussuri is released.
I know what's going to happen: I'll tell about a bug in Python 3.8 on IRC, and someone will reply to me "hey, that's not supported by OpenStack before the V release, please go away", even though as downstream distribution package maintainer, we don't have the power to decide what version of Python our distribution runs on (ie: both Debian Sid, Ubuntu and Fedora are quickly moving targets).
There's absolutely no excuse for the OpenStack project to be dragging its feet, apart maybe the fact that it may not be easy to setup the infra to run tests on Py3.8 just yet. It isn't a normal situation that downstream distributions get the shit (pardon my french) and get to be the ones fixing issues and proposing patches (Corey, you've done awesome job on this...), yet it's been the case for nearly every single Python 3 releases. I very much would appreciate this situation to be fixed, and the project moving faster.
Cheers,
Thomas Goirand (zigo)
Sean and everyone else,
Pardon me, but I have to rant here... :) Please try see things from a downstream consumer point of view.
This isn't the Python 2.7 era anymore, where we had a stable python for like forever. OpenStack needs to move quicker to newer Python 3 versions, especially considering that Python 2.7 isn't an option for anyone anymore. While your proposal (ie: less jobs on Python 3.8) looks like a nice first approach, it is my strong believe that the project should quickly move to voting and full Python 3.8 testing, and preferably, have it in order, with functional testing, for the whole project, by the time Ussuri is released.
We've had this debate many times now. Nothing has changed the fact that we cannot make something an official runtime until there is an official distro out there with that as the runtime. There is not for Ussuri.
I know what's going to happen: I'll tell about a bug in Python 3.8 on IRC, and someone will reply to me "hey, that's not supported by OpenStack before the V release, please go away", even though as downstream distribution package maintainer, we don't have the power to decide what version of Python our distribution runs on (ie: both Debian Sid, Ubuntu and Fedora are quickly moving targets).
I very highly doubt that, and very much disagree that someone will say to go away. From what I have seen, the majority of the community is very responsive to issues raised about future version problems.
Fixing and working with py3.8 is not what is being discussed here. Only whether those jobs to validate py3.8 should run on every patch or not.
There's absolutely no excuse for the OpenStack project to be dragging its feet, apart maybe the fact that it may not be easy to setup the infra to run tests on Py3.8 just yet. It isn't a normal situation that downstream distributions get the shit (pardon my french) and get to be the ones fixing issues and proposing patches (Corey, you've done awesome job on this...), yet it's been the case for nearly every single Python 3 releases. I very much would appreciate this situation to be fixed, and the project moving faster.
Cheers,
Thomas Goirand (zigo)
---- On Sun, 10 Nov 2019 18:44:24 +0800 Sean McGinnis sean.mcginnis@gmx.com wrote ----
Sean and everyone else,
Pardon me, but I have to rant here... :) Please try see things from a downstream consumer point of view.
This isn't the Python 2.7 era anymore, where we had a stable python for like forever. OpenStack needs to move quicker to newer Python 3 versions, especially considering that Python 2.7 isn't an option for anyone anymore. While your proposal (ie: less jobs on Python 3.8) looks like a nice first approach, it is my strong believe that the project should quickly move to voting and full Python 3.8 testing, and preferably, have it in order, with functional testing, for the whole project, by the time Ussuri is released.
We've had this debate many times now. Nothing has changed the fact that we cannot make something an official runtime until there is an official distro out there with that as the runtime. There is not for Ussuri.
++.
We cannot add for Ussuri at this stage. We can go with the below plan: - Start an experimental unit tests (functional and integration are next step) job first and projects can slowly start fixing (if any failure) those based on their bandwidth. - Once job pass then make it periodic or n-v to capture the new code checking on py3.8. - Same process for functional jobs. - Integration jobs are not required to be duplicated. they can be moved to the latest py version later.
In future release, we iterate the results of jobs and discuss to be add in testing run time mplate.
-gmann
I know what's going to happen: I'll tell about a bug in Python 3.8 on IRC, and someone will reply to me "hey, that's not supported by OpenStack before the V release, please go away", even though as downstream distribution package maintainer, we don't have the power to decide what version of Python our distribution runs on (ie: both Debian Sid, Ubuntu and Fedora are quickly moving targets).
I very highly doubt that, and very much disagree that someone will say to go away. From what I have seen, the majority of the community is very responsive to issues raised about future version problems.
Fixing and working with py3.8 is not what is being discussed here. Only whether those jobs to validate py3.8 should run on every patch or not.
There's absolutely no excuse for the OpenStack project to be dragging its feet, apart maybe the fact that it may not be easy to setup the infra to run tests on Py3.8 just yet. It isn't a normal situation that downstream distributions get the shit (pardon my french) and get to be the ones fixing issues and proposing patches (Corey, you've done awesome job on this...), yet it's been the case for nearly every single Python 3 releases. I very much would appreciate this situation to be fixed, and the project moving faster.
Cheers,
Thomas Goirand (zigo)
On Sun, 2019-11-10 at 04:44 -0600, Sean McGinnis wrote:
Sean and everyone else,
Pardon me, but I have to rant here... :) Please try see things from a downstream consumer point of view.
This isn't the Python 2.7 era anymore, where we had a stable python for like forever. OpenStack needs to move quicker to newer Python 3 versions, especially considering that Python 2.7 isn't an option for anyone anymore. While your proposal (ie: less jobs on Python 3.8) looks like a nice first approach, it is my strong believe that the project should quickly move to voting and full Python 3.8 testing, and preferably, have it in order, with functional testing, for the whole project, by the time Ussuri is released.
We've had this debate many times now. Nothing has changed the fact that we cannot make something an official runtime until there is an official distro out there with that as the runtime. There is not for Ussuri.
I know what's going to happen: I'll tell about a bug in Python 3.8 on IRC, and someone will reply to me "hey, that's not supported by OpenStack before the V release, please go away", even though as downstream distribution package maintainer, we don't have the power to decide what version of Python our distribution runs on (ie: both Debian Sid, Ubuntu and Fedora are quickly moving targets).
I very highly doubt that, and very much disagree that someone will say to go away. From what I have seen, the majority of the community is very responsive to issues raised about future version problems.
Fixing and working with py3.8 is not what is being discussed here. Only whether those jobs to validate py3.8 should run on every patch or not.
i think the only push back you would get is if fixing py38 compatibility would break py27 or py36 support. py27 is less of a concern at this point although i know some project might support it longer then required. The point being if we had to choose between a supported python and a newer python that we dont yet support we would prefer the supported version but generaly there is a way to support all the version we care about. it just means we can use the py38 only features until that becomes our minium supported version.
i think periodic jobs make more sense personally then experimental. depending on the velocity of the project there may be little different between a non voting check job and a peroidc at least for the smaller project. for larger project like nova a periodic would give more coverage then experimental and would use alot less resources but having a periodic job is only useful i someone checks it so im not sure if adding it to the default template makes sesne.
i would suggest we create a python-runtime-next template that add a py38 unit test job to that that adds the job to the periodic and experimental piplines. project that will actually check the periodic jobs in there weekly meeting like neutorn can opt in those that wont dont need to add the template.
There's absolutely no excuse for the OpenStack project to be dragging its feet, apart maybe the fact that it may not be easy to setup the infra to run tests on Py3.8 just yet. It isn't a normal situation that downstream distributions get the shit (pardon my french) and get to be the ones fixing issues and proposing patches (Corey, you've done awesome job on this...), yet it's been the case for nearly every single Python 3 releases. I very much would appreciate this situation to be fixed, and the project moving faster.
Cheers,
Thomas Goirand (zigo)
On 7/11/19 2:11 pm, Corey Bryant wrote:
Hello TC members,
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 was a bit fuzzy on this myself, so I looked it up and this is what the TC decided when we passed the resolution:
If the new Zuul template contains test jobs that were not in the previous one, the goal champion(s) may choose to update the previous template to add a non-voting check job (or jobs) to match the gating jobs in the new template. This means that all repositories that have not yet converted to the template for the upcoming release will see a non-voting preview of the new job(s) that will be added once they update. If this option is chosen, the non-voting job should be limited to the master branch so that it does not run on the preceding release’s stable branch.
(from https://governance.openstack.org/tc/resolutions/20181024-python-update-proce... )
So to follow that process we would need to define the python versions for V, then appoint a goal champion, and after that it would be at the champion's discretion to add a non-voting job on master in Ussuri. I happened to be sitting next to Sean when I saw this thread, and after discussing it with him I think he would OK with having a non-voting job on every commit, since it's what we have documented. Previous discussions established that the overhead of adding one Python unit test job to every project was pretty inconsequential (we'll offset it by dropping 2.7 jobs anyway).
I submitted a draft governance patch defining the Python versions for V (https://review.opendev.org/693743). Unfortunately we can't merge it yet because we don't have a release name for V (Sean is working on that: https://review.opendev.org/693266). It's gazing in the crystal ball a little bit, but even if for some reason Ubuntu 20.04 is not released before the V cycle starts, it's inevitable that we will be selecting Python 3.8 because it meets the first criterion ("The latest released version of Python 3 that is available in any distribution we can feasibly use for testing") - 3.8 is released and it's available in Ubuntu 18.04, which is the distro we use for testing anyway.
So, in my opinion, if you're volunteering to be the goal champion then there's no need for any further approval by the TC ;)
I guess to make that official we should commit the python3 update Goal for the V cycle now... or at least as soon as we have a release name.
This is happening a little earlier than I think we anticipated but, given that there's no question what is going to happen in V, I don't think we'd be doing anybody any favours by delaying the process unnecessarily.
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
Also should this be updated considering py38 would be non-voting? https://governance.openstack.org/tc/reference/runtimes/ussuri.html
No, I don't think this changes anything for Ussuri. It's preparation for V.
cheers, Zane.
On Mon, Nov 11, 2019 at 2:33 PM Zane Bitter zbitter@redhat.com wrote:
On 7/11/19 2:11 pm, Corey Bryant wrote:
Hello TC members,
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 was a bit fuzzy on this myself, so I looked it up and this is what the TC decided when we passed the resolution:
If the new Zuul template contains test jobs that were not in the
previous one, the goal champion(s) may choose to update the previous template to add a non-voting check job (or jobs) to match the gating jobs in the new template. This means that all repositories that have not yet converted to the template for the upcoming release will see a non-voting preview of the new job(s) that will be added once they update. If this option is chosen, the non-voting job should be limited to the master branch so that it does not run on the preceding release’s stable branch.
Thanks for digging that up and explaining. I recall that wording and it makes a lot more sense now that we have a scenario in front of us.
(from
https://governance.openstack.org/tc/resolutions/20181024-python-update-proce... )
So to follow that process we would need to define the python versions for V, then appoint a goal champion, and after that it would be at the champion's discretion to add a non-voting job on master in Ussuri. I happened to be sitting next to Sean when I saw this thread, and after discussing it with him I think he would OK with having a non-voting job on every commit, since it's what we have documented. Previous discussions established that the overhead of adding one Python unit test job to every project was pretty inconsequential (we'll offset it by dropping 2.7 jobs anyway).
I submitted a draft governance patch defining the Python versions for V (https://review.opendev.org/693743). Unfortunately we can't merge it yet because we don't have a release name for V (Sean is working on that: https://review.opendev.org/693266). It's gazing in the crystal ball a
Thanks very much for getting that going.
little bit, but even if for some reason Ubuntu 20.04 is not released
before the V cycle starts, it's inevitable that we will be selecting Python 3.8 because it meets the first criterion ("The latest released version of Python 3 that is available in any distribution we can feasibly use for testing") - 3.8 is released and it's available in Ubuntu 18.04, which is the distro we use for testing anyway.
So, in my opinion, if you're volunteering to be the goal champion then there's no need for any further approval by the TC ;)
Sure, I can champion that. Just to be clear, would that be Ussuri and V python3-updates champion, similar to the following? https://governance.openstack.org/tc/goals/selected/train/python3-updates.htm...
Granted it's easier now that we mostly just have to switch the job template to the new release.
I guess to make that official we should commit the python3 update Goal for the V cycle now... or at least as soon as we have a release name.
How far off do you think we are from having a V name? If just a few weeks then I'm fine waiting but if over a month I'm more concerned.
This is happening a little earlier than I think we anticipated but,
given that there's no question what is going to happen in V, I don't think we'd be doing anybody any favours by delaying the process unnecessarily.
I agree. And Python 3.9 doesn't release until Oct 2020 so that won't be in the picture for Ussuri or V.
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
Also should this be updated considering py38 would be non-voting? https://governance.openstack.org/tc/reference/runtimes/ussuri.html
No, I don't think this changes anything for Ussuri. It's preparation for V.
Ok. Appreciate all the input and help.
Thanks, Corey
On 12/11/19 9:12 am, Corey Bryant wrote:
On Mon, Nov 11, 2019 at 2:33 PM Zane Bitter <zbitter@redhat.com mailto:zbitter@redhat.com> wrote:
On 7/11/19 2:11 pm, Corey Bryant wrote: > Hello TC members, > > 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 was a bit fuzzy on this myself, so I looked it up and this is what the TC decided when we passed the resolution: > If the new Zuul template contains test jobs that were not in the previous one, the goal champion(s) may choose to update the previous template to add a non-voting check job (or jobs) to match the gating jobs in the new template. This means that all repositories that have not yet converted to the template for the upcoming release will see a non-voting preview of the new job(s) that will be added once they update. If this option is chosen, the non-voting job should be limited to the master branch so that it does not run on the preceding release’s stable branch.Thanks for digging that up and explaining. I recall that wording and it makes a lot more sense now that we have a scenario in front of us.
(from https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html#unit-tests ) So to follow that process we would need to define the python versions for V, then appoint a goal champion, and after that it would be at the champion's discretion to add a non-voting job on master in Ussuri. I happened to be sitting next to Sean when I saw this thread, and after discussing it with him I think he would OK with having a non-voting job on every commit, since it's what we have documented. Previous discussions established that the overhead of adding one Python unit test job to every project was pretty inconsequential (we'll offset it by dropping 2.7 jobs anyway). I submitted a draft governance patch defining the Python versions for V (https://review.opendev.org/693743). Unfortunately we can't merge it yet because we don't have a release name for V (Sean is working on that: https://review.opendev.org/693266). It's gazing in the crystal ball aThanks very much for getting that going.
little bit, but even if for some reason Ubuntu 20.04 is not released before the V cycle starts, it's inevitable that we will be selecting Python 3.8 because it meets the first criterion ("The latest released version of Python 3 that is available in any distribution we can feasibly use for testing") - 3.8 is released and it's available in Ubuntu 18.04, which is the distro we use for testing anyway. So, in my opinion, if you're volunteering to be the goal champion then there's no need for any further approval by the TC ;)Sure, I can champion that.
Thanks!
Just to be clear, would that be Ussuri and V python3-updates champion, similar to the following? https://governance.openstack.org/tc/goals/selected/train/python3-updates.htm...
Yes, for V it will be similar to that but s/train/v.../ only simpler because you already did the hard bits :) The goal champion for that is the one who gets to decide on adding the non-voting py38 job in Ussuri.
For U the proposed goal is https://review.opendev.org/691178 - so it will both update the Zuul template from train->ussuri and drop the py27 job (the former is a prerequisite for the latter because of reasons - see https://review.opendev.org/688997). That one is a little more complicated because we also should drop Python 2 functional tests before we drop the py27 unit tests, and because things have to happen in a certain order (services before libraries). OTOH we're only dropping stuff in this release and not adding new voting jobs that could break. Currently gmann has listed himself as the champion for that, but I know he's looking for help (we can have multiple champions for a goal). Somebody somewhere already has an action item to ask you about it :)
Granted it's easier now that we mostly just have to switch the job template to the new release.
I guess to make that official we should commit the python3 update Goal for the V cycle now... or at least as soon as we have a release name.How far off do you think we are from having a V name? If just a few weeks then I'm fine waiting but if over a month I'm more concerned.
Sean's patch has the naming poll closing on 2019-12-16, and we have to wait for legal approval from the OSF after that. (Ideally we'd have started sooner, but we were entertaining proposals to change the process and there was kind of an assumption that we wouldn't be using the existing one again.)
My take is that we shouldn't get too bureaucratic here. The criteria are well-defined so the outcome is not in doubt. There's no reason to delay until the patch is formally merged. We operate by lazy consensus, so if any TC members object they can reply to this thread. I'll flag it in IRC so people know about it. If there's no objections in the next week or say then the openstack-zuul-jobs team would be entitled to take that as approval.
cheers, Zane.
This is happening a little earlier than I think we anticipated but, given that there's no question what is going to happen in V, I don't think we'd be doing anybody any favours by delaying the process unnecessarily.I agree. And Python 3.9 doesn't release until Oct 2020 so that won't be in the picture for Ussuri or V.
> 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 > > Also should this be updated considering py38 would be non-voting? > https://governance.openstack.org/tc/reference/runtimes/ussuri.html No, I don't think this changes anything for Ussuri. It's preparation for V.Ok. Appreciate all the input and help.
Thanks, Corey
On Tue, Nov 12, 2019 at 11:47 AM Zane Bitter zbitter@redhat.com wrote:
On 12/11/19 9:12 am, Corey Bryant wrote:
On Mon, Nov 11, 2019 at 2:33 PM Zane Bitter <zbitter@redhat.com mailto:zbitter@redhat.com> wrote:
On 7/11/19 2:11 pm, Corey Bryant wrote: > Hello TC members, > > 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 toat
> 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 was a bit fuzzy on this myself, so I looked it up and this is what the TC decided when we passed the resolution: > If the new Zuul template contains test jobs that were not in the previous one, the goal champion(s) may choose to update the previous template to add a non-voting check job (or jobs) to match the gating jobs in the new template. This means that all repositories that have not yet converted to the template for the upcoming release will see a non-voting preview of the new job(s) that will be added once they update. If this option is chosen, the non-voting job should be limited to the master branch so that it does not run on the preceding release’s stable branch.Thanks for digging that up and explaining. I recall that wording and it makes a lot more sense now that we have a scenario in front of us.
(fromhttps://governance.openstack.org/tc/resolutions/20181024-python-update-proce...
) So to follow that process we would need to define the python versions for V, then appoint a goal champion, and after that it would be atthe
champion's discretion to add a non-voting job on master in Ussuri. I happened to be sitting next to Sean when I saw this thread, and after discussing it with him I think he would OK with having a non-votingjob
on every commit, since it's what we have documented. Previous discussions established that the overhead of adding one Python unit test job to every project was pretty inconsequential (we'll offset it by dropping 2.7 jobs anyway). I submitted a draft governance patch defining the Python versionsfor V
(https://review.opendev.org/693743). Unfortunately we can't merge it yet because we don't have a release name for V (Sean is working on that: https://review.opendev.org/693266). It's gazing in the crystal balla
Thanks very much for getting that going.
little bit, but even if for some reason Ubuntu 20.04 is not released before the V cycle starts, it's inevitable that we will be selecting Python 3.8 because it meets the first criterion ("The latest released version of Python 3 that is available in any distribution we can feasibly use for testing") - 3.8 is released and it's available in Ubuntu 18.04, which is the distro we use for testing anyway. So, in my opinion, if you're volunteering to be the goal championthen
there's no need for any further approval by the TC ;)Sure, I can champion that.
Thanks!
Just to be clear, would that be Ussuri and V python3-updates champion, similar to the following?
https://governance.openstack.org/tc/goals/selected/train/python3-updates.htm...
Yes, for V it will be similar to that but s/train/v.../ only simpler because you already did the hard bits :) The goal champion for that is the one who gets to decide on adding the non-voting py38 job in Ussuri.
Alright I'll definitely sign up to be champion for V.
For U the proposed goal is https://review.opendev.org/691178 - so it
will both update the Zuul template from train->ussuri and drop the py27 job (the former is a prerequisite for the latter because of reasons - see https://review.opendev.org/688997). That one is a little more complicated because we also should drop Python 2 functional tests before we drop the py27 unit tests, and because things have to happen in a certain order (services before libraries). OTOH we're only dropping stuff in this release and not adding new voting jobs that could break. Currently gmann has listed himself as the champion for that, but I know he's looking for help (we can have multiple champions for a goal). Somebody somewhere already has an action item to ask you about it :)
For Ussuri, I'll get in touch with gmann and see where we can help.
Granted it's easier now that we mostly just have to switch the job template to the new release.
I guess to make that official we should commit the python3 updateGoal
for the V cycle now... or at least as soon as we have a release name.How far off do you think we are from having a V name? If just a few weeks then I'm fine waiting but if over a month I'm more concerned.
Sean's patch has the naming poll closing on 2019-12-16, and we have to wait for legal approval from the OSF after that. (Ideally we'd have started sooner, but we were entertaining proposals to change the process and there was kind of an assumption that we wouldn't be using the existing one again.)
My take is that we shouldn't get too bureaucratic here. The criteria are well-defined so the outcome is not in doubt. There's no reason to delay until the patch is formally merged. We operate by lazy consensus, so if any TC members object they can reply to this thread. I'll flag it in IRC so people know about it. If there's no objections in the next week or say then the openstack-zuul-jobs team would be entitled to take that as approval.
That works for me. I'll check back in a week if nothing else comes up.
Thanks, Corey
cheers, Zane.
This is happening a little earlier than I think we anticipated but, given that there's no question what is going to happen in V, I don't think we'd be doing anybody any favours by delaying the process unnecessarily.I agree. And Python 3.9 doesn't release until Oct 2020 so that won't be in the picture for Ussuri or V.
> 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 > > Also should this be updated considering py38 would be non-voting? >https://governance.openstack.org/tc/reference/runtimes/ussuri.html
No, I don't think this changes anything for Ussuri. It's preparation for V.Ok. Appreciate all the input and help.
Thanks, Corey
---- On Tue, 12 Nov 2019 22:12:29 +0800 Corey Bryant corey.bryant@canonical.com wrote ----
On Mon, Nov 11, 2019 at 2:33 PM Zane Bitter zbitter@redhat.com wrote: On 7/11/19 2:11 pm, Corey Bryant wrote:
Hello TC members,
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 was a bit fuzzy on this myself, so I looked it up and this is what the TC decided when we passed the resolution:
If the new Zuul template contains test jobs that were not in the previous one, the goal champion(s) may choose to update the previous template to add a non-voting check job (or jobs) to match the gating jobs in the new template. This means that all repositories that have not yet converted to the template for the upcoming release will see a non-voting preview of the new job(s) that will be added once they update. If this option is chosen, the non-voting job should be limited to the master branch so that it does not run on the preceding release’s stable branch.
Thanks for digging that up and explaining. I recall that wording and it makes a lot more sense now that we have a scenario in front of us.
(from https://governance.openstack.org/tc/resolutions/20181024-python-update-proce... )
So to follow that process we would need to define the python versions for V, then appoint a goal champion, and after that it would be at the champion's discretion to add a non-voting job on master in Ussuri. I happened to be sitting next to Sean when I saw this thread, and after discussing it with him I think he would OK with having a non-voting job on every commit, since it's what we have documented. Previous discussions established that the overhead of adding one Python unit test job to every project was pretty inconsequential (we'll offset it by dropping 2.7 jobs anyway).
I submitted a draft governance patch defining the Python versions for V (https://review.opendev.org/693743). Unfortunately we can't merge it yet because we don't have a release name for V (Sean is working on that: https://review.opendev.org/693266). It's gazing in the crystal ball a
Thanks very much for getting that going. little bit, but even if for some reason Ubuntu 20.04 is not released before the V cycle starts, it's inevitable that we will be selecting Python 3.8 because it meets the first criterion ("The latest released version of Python 3 that is available in any distribution we can feasibly use for testing") - 3.8 is released and it's available in Ubuntu 18.04, which is the distro we use for testing anyway.
So, in my opinion, if you're volunteering to be the goal champion then there's no need for any further approval by the TC ;)
Sure, I can champion that. Just to be clear, would that be Ussuri and V python3-updates champion, similar to the following? https://governance.openstack.org/tc/goals/selected/train/python3-updates.htm... Granted it's easier now that we mostly just have to switch the job template to the new release. I guess to make that official we should commit the python3 update Goal for the V cycle now... or at least as soon as we have a release name.
How far off do you think we are from having a V name? If just a few weeks then I'm fine waiting but if over a month I'm more concerned.
This is happening a little earlier than I think we anticipated but, given that there's no question what is going to happen in V, I don't think we'd be doing anybody any favours by delaying the process unnecessarily.
++ on not delaying the process. That is the main point of the goal process schedule also. To be clear, are we going to add the py3.8 n-v job as part of v cycle template (openstack-python3-v*-jobs) ? I hope yes, as it will enable us to make the one-time change on the project's side. Once we are in V cycle then template can be updated to make it a voting job.
If not as part of the template (adding n-v job explicitly in Ussuri cycle and then add the V template once V cycle starts. ) then it will be two changes per project which I would like to avoid.
-gmann
I agree. And Python 3.9 doesn't release until Oct 2020 so that won't be in the picture for Ussuri or V.
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
Also should this be updated considering py38 would be non-voting? https://governance.openstack.org/tc/reference/runtimes/ussuri.html
No, I don't think this changes anything for Ussuri. It's preparation for V.
Ok. Appreciate all the input and help. Thanks,Corey
On Wed, Nov 13, 2019 at 2:01 PM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Tue, 12 Nov 2019 22:12:29 +0800 Corey Bryant < corey.bryant@canonical.com> wrote ----
On Mon, Nov 11, 2019 at 2:33 PM Zane Bitter zbitter@redhat.com wrote: On 7/11/19 2:11 pm, Corey Bryant wrote:
Hello TC members,
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 was a bit fuzzy on this myself, so I looked it up and this is what
the
TC decided when we passed the resolution:
If the new Zuul template contains test jobs that were not in the
previous one, the goal champion(s) may choose to update the previous template to add a non-voting check job (or jobs) to match the gating jobs in the new template. This means that all repositories that have not yet converted to the template for the upcoming release will see a non-voting preview of the new job(s) that will be added once they update. If this option is chosen, the non-voting job should be limited to the master branch so that it does not run on the preceding release’s stable branch.
Thanks for digging that up and explaining. I recall that wording and it
makes a lot more sense now that we have a scenario in front of us.
(from
https://governance.openstack.org/tc/resolutions/20181024-python-update-proce...
)
So to follow that process we would need to define the python versions for V, then appoint a goal champion, and after that it would be at the champion's discretion to add a non-voting job on master in Ussuri. I happened to be sitting next to Sean when I saw this thread, and after discussing it with him I think he would OK with having a non-voting job on every commit, since it's what we have documented. Previous discussions established that the overhead of adding one Python unit
test
job to every project was pretty inconsequential (we'll offset it by dropping 2.7 jobs anyway).
I submitted a draft governance patch defining the Python versions for V (https://review.opendev.org/693743). Unfortunately we can't merge it
yet
because we don't have a release name for V (Sean is working on that: https://review.opendev.org/693266). It's gazing in the crystal ball a
Thanks very much for getting that going. little bit, but even if for some reason Ubuntu 20.04 is not released before the V cycle starts, it's inevitable that we will be selecting Python 3.8 because it meets the first criterion ("The latest released version of Python 3 that is available in any distribution we can feasibly use for testing") - 3.8 is released and it's available in Ubuntu 18.04, which is the distro we use for testing anyway.
So, in my opinion, if you're volunteering to be the goal champion then there's no need for any further approval by the TC ;)
Sure, I can champion that. Just to be clear, would that be Ussuri and V
python3-updates champion, similar to the following?
https://governance.openstack.org/tc/goals/selected/train/python3-updates.htm...
Granted it's easier now that we mostly just have to switch the job
template to the new release.
I guess to make that official we should commit the python3 update Goal for the V cycle now... or at least as soon as we have a release name.
How far off do you think we are from having a V name? If just a few
weeks then I'm fine waiting but if over a month I'm more concerned.
This is happening a little earlier than I think we anticipated but, given that there's no question what is going to happen in V, I don't think we'd be doing anybody any favours by delaying the process unnecessarily.
++ on not delaying the process. That is the main point of the goal process schedule also. To be clear, are we going to add the py3.8 n-v job as part of v cycle template (openstack-python3-v*-jobs) ? I hope yes, as it will enable us to make the one-time change on the project's side. Once we are in V cycle then template can be updated to make it a voting job.
If not as part of the template (adding n-v job explicitly in Ussuri cycle and then add the V template once V cycle starts. ) then it will be two changes per project which I would like to avoid.
-gmann
My plan is to create V templates soon which will include voting py38. And ussuri templates will have non-voting py38: https://review.opendev.org/#/c/693401/
I was thinking we couldn't add V templates to projects until after their stable/ussuri branches are created, which would mean one update per project per release.
Thanks, Corey
---- On Thu, 14 Nov 2019 03:43:29 +0800 Corey Bryant corey.bryant@canonical.com wrote ----
On Wed, Nov 13, 2019 at 2:01 PM Ghanshyam Mann gmann@ghanshyammann.com wrote: ---- On Tue, 12 Nov 2019 22:12:29 +0800 Corey Bryant corey.bryant@canonical.com wrote ----
On Mon, Nov 11, 2019 at 2:33 PM Zane Bitter zbitter@redhat.com wrote: On 7/11/19 2:11 pm, Corey Bryant wrote:
Hello TC members,
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 was a bit fuzzy on this myself, so I looked it up and this is what the TC decided when we passed the resolution:
If the new Zuul template contains test jobs that were not in the previous one, the goal champion(s) may choose to update the previous template to add a non-voting check job (or jobs) to match the gating jobs in the new template. This means that all repositories that have not yet converted to the template for the upcoming release will see a non-voting preview of the new job(s) that will be added once they update. If this option is chosen, the non-voting job should be limited to the master branch so that it does not run on the preceding release’s stable branch.
Thanks for digging that up and explaining. I recall that wording and it makes a lot more sense now that we have a scenario in front of us.
(from https://governance.openstack.org/tc/resolutions/20181024-python-update-proce... )
So to follow that process we would need to define the python versions for V, then appoint a goal champion, and after that it would be at the champion's discretion to add a non-voting job on master in Ussuri. I happened to be sitting next to Sean when I saw this thread, and after discussing it with him I think he would OK with having a non-voting job on every commit, since it's what we have documented. Previous discussions established that the overhead of adding one Python unit test job to every project was pretty inconsequential (we'll offset it by dropping 2.7 jobs anyway).
I submitted a draft governance patch defining the Python versions for V (https://review.opendev.org/693743). Unfortunately we can't merge it yet because we don't have a release name for V (Sean is working on that: https://review.opendev.org/693266). It's gazing in the crystal ball a
Thanks very much for getting that going. little bit, but even if for some reason Ubuntu 20.04 is not released before the V cycle starts, it's inevitable that we will be selecting Python 3.8 because it meets the first criterion ("The latest released version of Python 3 that is available in any distribution we can feasibly use for testing") - 3.8 is released and it's available in Ubuntu 18.04, which is the distro we use for testing anyway.
So, in my opinion, if you're volunteering to be the goal champion then there's no need for any further approval by the TC ;)
Sure, I can champion that. Just to be clear, would that be Ussuri and V python3-updates champion, similar to the following? https://governance.openstack.org/tc/goals/selected/train/python3-updates.htm... Granted it's easier now that we mostly just have to switch the job template to the new release. I guess to make that official we should commit the python3 update Goal for the V cycle now... or at least as soon as we have a release name.
How far off do you think we are from having a V name? If just a few weeks then I'm fine waiting but if over a month I'm more concerned.
This is happening a little earlier than I think we anticipated but, given that there's no question what is going to happen in V, I don't think we'd be doing anybody any favours by delaying the process unnecessarily.
++ on not delaying the process. That is the main point of the goal process schedule also. To be clear, are we going to add the py3.8 n-v job as part of v cycle template (openstack-python3-v*-jobs) ? I hope yes, as it will enable us to make the one-time change on the project's side. Once we are in V cycle then template can be updated to make it a voting job.
If not as part of the template (adding n-v job explicitly in Ussuri cycle and then add the V template once V cycle starts. ) then it will be two changes per project which I would like to avoid.
I saw the review now and that too works well and matches the TC resolution. Once we have V cycle testing runtime (zane patch) reflecting the 3.8 as required version then we are good to merge that.
-gmann
-gmann
My plan is to create V templates soon which will include voting py38. And ussuri templates will have non-voting py38: https://review.opendev.org/#/c/693401/ I was thinking we couldn't add V templates to projects until after their stable/ussuri branches are created, which would mean one update per project per release.
Thanks, Corey
participants (9)
-
Clark Boylan
-
Corey Bryant
-
Ghanshyam Mann
-
Nate Johnston
-
Sean McGinnis
-
Sean Mooney
-
Slawek Kaplonski
-
Thomas Goirand
-
Zane Bitter