Open Stack

On 12/11/19 9:12 am, Corey Bryant wrote:
> 
> On Mon, Nov 11, 2019 at 2:33 PM Zane Bitter <zbitter at redhat.com 
> <mailto:zbitter at 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 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.

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.html

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