| opendevreview | Merged openstack/governance master: Update to hacking v6 https://review.opendev.org/c/openstack/governance/+/881266 | 13:34 |
|---|---|---|
| opendevreview | Merged openstack/governance master: Switch to 2023.2 testing runtime py version https://review.opendev.org/c/openstack/governance/+/881137 | 13:43 |
| opendevreview | Merged openstack/governance master: Correct the old deprecated policies removal timeline for SLURP release https://review.opendev.org/c/openstack/governance/+/880238 | 13:43 |
| knikolla | o/ | 14:15 |
| jamespage | o/ | 14:36 |
| *** iurygregory_ is now known as iurygregory | 15:00 | |
| JayF | good morning o/ | 15:58 |
| fungi | priming the pump for the meeting in a couple of hours... we're continuing to see more cases of projects setting python_requires>=3.9 in their setup.cfg files at the same time they drop 3.8 testing, but that breaks everyone else who has jobs that install that project for 3.8, so unless we can get everyone to do that at the exact same moment it would probably make more sense to have two | 16:01 |
| fungi | phases: 1. everyone stop testing on 3.8, 2. once everyone's done that then they can all update their python_requires safely | 16:01 |
| noonedeadpunk | while encouraged to keep support if possible for users outside of openstack | 16:05 |
| dansmith | yeah I think noonedeadpunk has it on the meeting agenda right? | 16:12 |
| noonedeadpunk | yup | 16:12 |
| dansmith | I'm very much in favor of us not hard-blocking on a python version unless we know we don't support it | 16:12 |
| dansmith | and even still, I wonder if maybe we should even put focal back into the PTI as an optional-but-not-fully-verified platform | 16:12 |
| dansmith | because this feels a bit too early at this point | 16:13 |
| noonedeadpunk | that could be tricky though | 16:13 |
| noonedeadpunk | at least libvirt/qemu versions are not that modern | 16:13 |
| noonedeadpunk | and last UCA release was for Yoga I believe | 16:13 |
| noonedeadpunk | not saying about things like ovs/ovn | 16:13 |
| dansmith | yeah and I know nova wants to bump the version | 16:14 |
| dansmith | I'm just saying, there are lots of people still on focal, 3.8 is still supported upstream, etc | 16:14 |
| dansmith | at least for basic python functionality, dropping it so hard is causing trouble | 16:14 |
| clarkb | I think the main thing is understanding libraries and applications have different constraints | 16:15 |
| clarkb | libraries should be forgiving. Applications can be more specific | 16:15 |
| dansmith | that for sure at a minimum | 16:15 |
| dansmith | but neutron forcing the issue already broke us :) | 16:15 |
| fungi | though nova's latest breakage was due to neutron adding it | 16:15 |
| fungi | jinx | 16:15 |
| dansmith | fungi: not our latest actually, but close :) | 16:16 |
| clarkb | and neutron only updated because tooz forced the issue | 16:16 |
| fungi | the tight integration between openstack services is why i suggested a two-phase approach | 16:16 |
| dansmith | for some reason everyone seemed to think that blocking it themselves would fix their own problem jobs I guess | 16:16 |
| dansmith | right | 16:16 |
| dansmith | so it just kept propagating through the system | 16:16 |
| clarkb | yes it is still possible that neutron would break nova independent of any library update but I suspect that if we did application in a coordinated manner first then libraries after the fact most of the issue would go away | 16:16 |
| dansmith | yes, for sure | 16:16 |
| dansmith | and it's much easier to revert a patch on neutron master than re-release and ban library versions | 16:17 |
| fungi | i still think projects need to, on the whole, stop running 3.8 based integration jobs before projects they integrate with update to python_requires>=3.9 | 16:17 |
| fungi | unless they can all do it at the exact same time | 16:17 |
| fungi | because they simply won't be coinstallable for integration testing otherwise | 16:18 |
| dansmith | yep | 16:18 |
| noonedeadpunk | I'm not sure though how this all can be enforced. Like what we're talking about is more up to common sense | 16:19 |
| noonedeadpunk | which seemed like failed now | 16:19 |
| clarkb | I think you enforce it through the release team | 16:19 |
| clarkb | and CI | 16:20 |
| clarkb | in the way way back we had far more stringent cross gating | 16:20 |
| JayF | and potentially through requirements project, yeah? e.g. tooz likely should not have been version bumped in requirements if it didn't support 3.8 and large swaths of projects did | 16:20 |
| clarkb | those ties have broken down over the years but it is entirely possible to add back in and stop this problem from ever happening | 16:20 |
| dansmith | clarkb: well, the release team doesn't prevent the neutron case | 16:20 |
| JayF | if we stop the bleeding there, no top level project updates their config (as neutron did) | 16:20 |
| dansmith | JayF: that's what prompted neutron this time, but they still could have done it on their own | 16:21 |
| clarkb | dansmith: ya the solution for that is to stop running a bunch of special jobs in each project without also having sufficient overlap | 16:21 |
| dansmith | not sure there's much we can do about that (nor need to since it's an "easy" revert) | 16:21 |
| clarkb | in this case having a 3.8 job that runs on every project would fix this | 16:21 |
| fungi | until it's time to remove the 3.8 job, but then yes remove it from everyone at the same time | 16:22 |
| dansmith | clarkb: yeah, we could, but I'm not even sure what that job would be that would pertain to everyone.. maybe devstack bashate but with py38? :) | 16:22 |
| clarkb | right and remove that job after every other 3.8 job is removed | 16:22 |
| dansmith | or maybe just never bump the base devstack-based template job until everything else has upgraded | 16:23 |
| dansmith | the problem was the ceph job and focal being a unique case, and the python version wasn't the problem at the time, | 16:23 |
| dansmith | so we didn't hold everything else back because it was just a ceph package requirement | 16:23 |
| dansmith | so you can see how we got here | 16:23 |
| clarkb | ya I think you have a nromal devstack + tempest + focal job you run everywhere until neutron and nova and octavia and cinder all remove their special 3.8 jobs | 16:24 |
| dansmith | yeah, we just have to remember that there can be no other justification for an exception, which is hard when the justification has nothing to do with python | 16:25 |
| dansmith | I'm sure we've done the same thing before, where one unique job configuration got kept back, but we just didn't happen to have this aggressive python version bumping so it didn't bite us then | 16:26 |
| clarkb | Also, I think we need to make more prominent that the PTI is a base requirement but more is fine too. And then explicitly consider extra support in oslo for things. I already fight hard for this with PBR because every year or so someone comes along and tries to delete python2 and old 3 support in PBR not realizing it will literally explode all of openstack until the only | 16:28 |
| clarkb | openstacks in existence use pyproject.toml files to specify their intsall deps or don't use PBR at all | 16:28 |
| dansmith | yeah | 16:30 |
| dansmith | that was my thought with the "make focal an optional but untested platform in PTI" suggestion | 16:30 |
| dansmith | even if nova-compute doesn't run there because of libvirt versions, saying it might work for other things might help soften the feeling that we should immediately ban even installing there | 16:30 |
| noonedeadpunk | Well even if core services does not support that - it becomes quite misleading for end users | 16:38 |
| noonedeadpunk | Especially when it known not to work | 16:39 |
| dansmith | if it's known not to work, then that's one thing, but in this case we're just banning py38 for no reason | 16:43 |
| gmann | but at some point we have to drop it, right | 16:44 |
| dansmith | so maybe we don't list focal as an optional platform but say py38 is optional or something | 16:44 |
| dansmith | gmann: which focal or py38? | 16:44 |
| dansmith | I mean, eventually both for sure | 16:44 |
| gmann | both | 16:44 |
| noonedeadpunk | yeah, mentioning py38 now makes sense for sure | 16:44 |
| gmann | IMO, if we stop testing it then hard break is ok. otherwise we need to bring back the testing | 16:44 |
| dansmith | sure, but blocking py38 in our config file for no _actual_ incompatibility is just too harsh, IMHO | 16:44 |
| noonedeadpunk | as till next slurp release py38 will be still supported | 16:45 |
| noonedeadpunk | but then we need to acknowledge we should keep it till 2024.1 | 16:45 |
| dansmith | gmann: well, then maybe we should keep testing on focal | 16:45 |
| gmann | ah that is fine. I think we should not do that and stop people to do that, config can say which py version are tested/supported but no hard break in require_python | 16:45 |
| gmann | dansmith: you mean as bets effort like we did in 2023.1 ? | 16:45 |
| dansmith | gmann: right, that's my primary concern.. that hard block is too harsh, especially in the libraries | 16:45 |
| dansmith | gmann: right | 16:46 |
| dansmith | I think people read right now that the PTI says they *should* hard-block py38 (even though it doesn't say that) | 16:46 |
| gmann | humm, we should clarify that | 16:46 |
| jrosser | testing some of the libs on the LTS OS releases which are not EOL would ease things maybe | 16:46 |
| noonedeadpunk | This kinda boils down to identifiying what library is and then implementing rules for such projects | 16:46 |
| gmann | dansmith: I am ok to bring back the focal as best effort testing one. it does not harm actually | 16:46 |
| dansmith | so we should definitely make it clear that doing that is bad.. we can either do that by saying so, or by making py38 optional or something | 16:46 |
| noonedeadpunk | Because library is vague | 16:47 |
| gmann | yeah, if there is code break then fine | 16:47 |
| dansmith | gmann: right | 16:47 |
| noonedeadpunk | I was told neutron is also a library one day as it's being used by other projects | 16:47 |
| dansmith | and to clarkb's point, I think maybe having a wider range of required-to-support for the library stuff is a good idea | 16:47 |
| dansmith | and ask them to keep running unit/functional on the older PTI stuff | 16:48 |
| noonedeadpunk | we should identify what library is first | 16:48 |
| noonedeadpunk | I was percieving library whatever is in U-C but constantly told this perception is wrong, for example | 16:49 |
| fungi | neutron at one point had an effort in progress to extract the bits other projects were importing into a separate neutron-lib project, but if memory serves that never got completed and some stuff is still imported directly from neutron itself | 16:49 |
| noonedeadpunk | also again, the issue was caused not even by tooz dropping py38, but by constraining this version too early | 16:50 |
| dansmith | yeah I think if anyone ever does an import from your package into theirs, then you're a library :) | 16:50 |
| fungi | it's something we said needed to be done 10 years ago, so... | 16:50 |
| noonedeadpunk | So maybe we should just not merge update of UC until some point in release schedule? | 16:51 |
| noonedeadpunk | But then it's kinda risky as issues won't be spotted early | 16:52 |
| dansmith | yeah, I don't think that's the solution | 16:52 |
| dansmith | because chasing this ceph thing late in the cycle would suck more than now :) | 16:52 |
| noonedeadpunk | but I'm not sure how to enforce neutron to keep their py39 support as they're a library... | 16:53 |
| noonedeadpunk | *py38 | 16:54 |
| clarkb | in m view neutron isn't a library that matters too much for this. Neutron isn't consumed by anything outside of openstack. Some oslo libs are. We can coordinate with neutron within openstack. But that is much harder with oslo libraries that can be used elsewhere | 16:54 |
| gmann | noonedeadpunk: but if we ask everyone to not put require_python in config that applies to lib also | 16:54 |
| dansmith | yeah that would be my preference.. no requires_python | 16:55 |
| clarkb | You do want require_python once you break compatibility though | 16:55 |
| noonedeadpunk | ++ | 16:55 |
| fungi | so it sounds like there might be some consensus around it being okay for projects to drop most of their py38 jobs but ideally run at least one to make sure they nominally function on it. at some point later in the cycle there can be a deadline where that job is removed and all other py38 jobs are expected to have already been dropped by applications, then and only then they can start | 16:55 |
| fungi | adding python_requires>=3.9 to setup.cfg if necessary | 16:55 |
| noonedeadpunk | from user prespective not having python_requires is weird | 16:55 |
| bauzas | fwiw, I still don't get why a library should forbid a version of python if that version of python already works | 16:55 |
| dansmith | we can have requires_python but not bump it according to the PTI, is what I meant | 16:56 |
| noonedeadpunk | Yes, exactly, there should be solid reason to remove python version | 16:56 |
| bauzas | but I guess it's a matter for some of them to say "I'm no longer supporting 3.x" | 16:56 |
| dansmith | having unit tests that continue to run on older python would probably be good enough to make sure people don't aggressively adopt new language features | 16:56 |
| dansmith | like perhaps we say in the PTI that unit tests should continue to run on focal as "best effort" and limit devstack to jammy, that sort of thing | 16:56 |
| bauzas | dansmith: :) | 16:56 |
| fungi | some of them don't want to test on older python versions, and want to assert that they consider it broken there because it's untested. i get that, though would think that at least libs would want to continue testing on the oldest non-eol python version | 16:56 |
| fungi | especially if they're likely to be used beyond openstack | 16:57 |
| dansmith | fungi: well, if we say you can't use language features of 3.11 even though only >=3.10 is required to be supported | 16:57 |
| bauzas | fungi: to me, broken and unsupported are two very different concepts | 16:57 |
| bauzas | I guess they want to move on not because of any breakage, but rather because they wanna turn into some new $fancy python features | 16:58 |
| dansmith | aggressively moving to newer dependent packages is one thing, IMHO, but aggressively adopting language features that makes you *incompatible* with currently supported python versions is a different thing IMHO | 16:58 |
| gmann | until it is working it is ok, seeing py38 tested recently and with py310 it is rare chance we will introduce py38 incompatible code unitl py3.10 is dropped | 16:58 |
| noonedeadpunk | But I really not sure what's the problem with keeping 1 pep job for older python version | 16:58 |
| gmann | yes, if it is hard break in code and cannot be fixed/keep-compatible then we can change config | 16:58 |
| noonedeadpunk | especially when they're not broken | 16:58 |
| dansmith | noonedeadpunk: to ensure language compatibility you mean.. I agree | 16:59 |
| noonedeadpunk | Though I'm against having focal in PTI now. | 16:59 |
| gmann | yeah, I am ok to keep bumping the py version but be less aggressive to drop old one until their are EOL or we have to | 16:59 |
| noonedeadpunk | But tox jobs can provide you with any python on jammy, including 3.8 | 17:00 |
| dansmith | gmann: so maybe we adjust PTI to call out what has to work on devstack jobs vs. unit/functional/ | 17:00 |
| bauzas | at least dropping the python support before milestone-1 is a pretty aggressive and optimistic deadline | 17:00 |
| clarkb | noonedeadpunk: they cannot do that currently. | 17:00 |
| dansmith | noonedeadpunk: I don't think so | 17:00 |
| JayF | noonedeadpunk: it'll happily run a different python, but won't install/configure one if it's missing | 17:00 |
| dansmith | noonedeadpunk: tox will lie to you and tell you it works, but it's nto really 3.8 :) | 17:00 |
| clarkb | it is theoretically possible if you update the jobs to install python3.8 on jammy, but nothing does that today | 17:00 |
| noonedeadpunk | rly? there's python_build role? | 17:00 |
| bauzas | as a lib, you're basically asserting that people did the necessary moves *before* m-1 | 17:00 |
| noonedeadpunk | And python versions are pre-built in images? | 17:00 |
| clarkb | noonedeadpunk: right you would need to update the jobs to use that role or something like it. I don't think anything does that today | 17:00 |
| clarkb | the jobs insall python using distro packages today | 17:01 |
| clarkb | this means you can run python3.10 and 3.11 on jammy | 17:01 |
| noonedeadpunk | or even if they're not pre-built they could be easily isntalled during runtime with pyenv | 17:01 |
| clarkb | 3.8 and 3.9 on focal and so on | 17:01 |
| clarkb | right you would need to do the work to do that is what I'm saying | 17:01 |
| dansmith | I see no reason not to just use focal for those jobs though | 17:01 |
| noonedeadpunk | I kinda thought it's matter of setting variable for the kob? | 17:01 |
| noonedeadpunk | dansmith: and what are we going to run for 3.9 support for example? | 17:02 |
| noonedeadpunk | debian? | 17:02 |
| dansmith | noonedeadpunk: also focal, or debian | 17:02 |
| clarkb | or rocky | 17:02 |
| clarkb | (but rocky isn't in the current specification iirc) | 17:03 |
| gmann | but we can keep py38 job on focal I think focal nodeset support will be there for long even we do not have that in testing runtime | 17:03 |
| noonedeadpunk | I'm pretty sure that ensure-python role was included everytwhere | 17:03 |
| noonedeadpunk | So it's matter of passing `python_version` to the job | 17:03 |
| dansmith | yeah and focal becomes easy to install locally to reproduce any issues if needed | 17:03 |
| dansmith | noonedeadpunk: python_version (the devstack variable) just changes what distro packages it installs, IIRC | 17:04 |
| clarkb | dansmith: correct. There are other flags you can set to do other things. I'm saying no one has used those I have no idea if they work and you can do it but you have to do the work | 17:04 |
| clarkb | it is definitel possible. It isn't how the jobs are used today in openstack | 17:04 |
| dansmith | yeah | 17:05 |
| clarkb | that means someone or something needs to do work to make that happen | 17:05 |
| noonedeadpunk | here we go https://zuul.opendev.org/t/openstack/build/4eab1784c6fc438585656ba1c398de35/log/job-output.txt#639 | 17:05 |
| dansmith | it's easier to just use focal for those versions and not overcomplicate things, IMHO | 17:05 |
| noonedeadpunk | dansmith: I;m talking about this: https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-python/tasks/pyenv.yaml | 17:05 |
| noonedeadpunk | like effort of switching job to focal is identical to setting vars for zuul job | 17:06 |
| dansmith | noonedeadpunk: okay I'm not sure what we're arguign about | 17:06 |
| noonedeadpunk | yeah, true | 17:06 |
| noonedeadpunk | what I was saying is that we have all tools to test any python on any OS | 17:07 |
| dansmith | you'd prefer to run unit tests on py38 on a non-native non-distro package than use focal for that? Focal doesn't have to become a supported platform just so we can use it for running unit tests on its python version | 17:07 |
| noonedeadpunk | but I don't want focal to raise in PTI as this is confusing | 17:07 |
| dansmith | don't have to, IMHO | 17:07 |
| noonedeadpunk | but yeah, we can/should bring back py38 support then | 17:08 |
| bauzas | honestly, I'm not asking to bring back Focal | 17:08 |
| noonedeadpunk | OR identify what we call libraries and have separate set of rules for them in PTI and/or release schedule | 17:08 |
| bauzas | what I ideally want is some TC direction telling the projects (and the libraries) to be soft and gentle about their python requirements | 17:08 |
| noonedeadpunk | As when time will come to drop py38 - we will hit same problem again | 17:09 |
| bauzas | and not preemptively bump their mins, at least so early in a cycle | 17:09 |
| gmann | yeah | 17:09 |
| fungi | and to maintain coinstallability during this transitional period while projects are working to move off 3.8 testing | 17:09 |
| noonedeadpunk | For me that falled under common sense to be frank... | 17:09 |
| bauzas | I know that most of them are independent releases | 17:09 |
| bauzas | but some kind of gentlemen's agreement about thinking about your consumers would be a feat. | 17:10 |
| gmann | testing as per what there in testing runtime is fine but bump min py version in config is something we can avoid | 17:10 |
| gmann | and also try not to drop older min py version from teting runtime until we have to | 17:10 |
| fungi | for the tooz example, i looked at the previous minversion bump. they merged a change to switch from python_requires>=3.6 to 3.8 at r21 of the zed cycle, but didn't tag a new release with it until r6. for this cycle the new release with the minversion bump happened at r23 | 17:11 |
| fungi | so about 4.5 months earlier in the cycle | 17:11 |
| bauzas | can we at least ask the libraries that are part of openstack namespace to just notify their intent to release some breaking change ? | 17:12 |
| bauzas | previously we had mailing-lists... | 17:12 |
| JayF | We still have a mailing list that would work fine for that purpose (-discuss), it's just not used for that sort of thing so much anymore. | 17:12 |
| bauzas | :) | 17:13 |
| bauzas | just sayin', | 17:13 |
| bauzas | we're asking any developer that touches the virt API to send an email to the list | 17:13 |
| bauzas | despite the virt API not being a public API | 17:13 |
| bauzas | but just because we know some people run out-of-tree virt drivers and they would be impacted by an interface change | 17:14 |
| bauzas | changing your setup.cfg is the exact same contract | 17:14 |
| fungi | well, unless it's a typo in the description or something ;) | 17:15 |
| bauzas | well, the requires at least | 17:15 |
| fungi | agreed | 17:15 |
| JayF | honestly part of me wonders if that alone is enough. Just if we encouraged projects to give a heads up on the ML for breaking setup.cfg changes. | 17:16 |
| bauzas | surely that sole process won't solve the problem | 17:16 |
| bauzas | but it's just communication I want | 17:16 |
| fungi | it seems like the expectation was that this was a known transition and everyone was expected to start dropping python 3.8 support from projects this cycle, they just didn't consider that doing it might require some coordination between projects and probably could have used a reminder or better guidance | 17:16 |
| bauzas | fungi: your assertion looks correct to me | 17:17 |
| bauzas | they were just enthusiats | 17:17 |
| bauzas | no bad intent at all. | 17:17 |
| fungi | so they probably didn't think it warranted broad notification | 17:17 |
| bauzas | probably the PTI could mention it, or the project team guide | 17:17 |
| gmann | I think if we add it back as it does not cost much it should work as there should not be any incompatible changes went by now | 17:18 |
| fungi | i chalk a lot of it up to our integration testsuites and requirements management being an inscrutable black box to many developers on our projects | 17:18 |
| bauzas | fungi: yeah and to be fair, requirements patches are hard to review | 17:19 |
| fungi | so things that seem like common sense to those of us who understand how they work may not be top of mind for everyone else | 17:19 |
| bauzas | particularly patches like https://review.opendev.org/c/openstack/requirements/+/872065 when you basically apt upgrade your world | 17:19 |
| * bauzas goes eating in order to be present for the TC meeting | 17:20 | |
| fungi | in theory, those changes are tested. but maybe the testing for requirements changes needs a fresh coat of paint and some new curtains | 17:20 |
| fungi | looks like probably the only place the tooz py38 drop would have been caught was the cross-swift-py38 job and i doubt swift uses tooz | 17:22 |
| JayF | I wonder if requirements repo needs ajob that just verifies python version on requirements | 17:23 |
| JayF | required_pythons=[3.8,3.9,3.10] then something that iterates and checks if you have installable versions for each | 17:23 |
| fungi | oh, i guess there is a requirements-tox-py38-check-uc already there | 17:24 |
| dansmith | JayF: sure, we just have to agree that 3.8 should be in there (in this case) and part of the problem is that currently it looks like only 3.9 should be the lower end | 17:24 |
| frickler | this revert is getting merged just now https://review.opendev.org/c/openstack/requirements/+/881433?usp=dashboard | 17:29 |
| dansmith | nice | 17:30 |
| frickler | and after that we can look into having version specific requirements again, like we had for py2.7 or also py3.6 for some time | 17:30 |
| spotz_ | atching up on the meeting before the meeting:) | 17:30 |
| gmann | or just add py38 back in testing runtime | 17:31 |
| dansmith | frickler: honestly, that revert is most of what I want, so that's cool we just need to mention 3.8 in the PTI and we're good :) | 17:31 |
| dansmith | gmann: we need both I think | 17:31 |
| fungi | d'oh, https://review.opendev.org/879229 dropped the requirements-tox-py38-check-uc job from requirements master branch changes 3 weeks ago | 17:32 |
| gmann | dansmith: i mean 'having version specific requirements'. revert is good | 17:32 |
| fungi | so i guess that was the point at which we effectively started letting non-3.8-supporting versions into the master constraints list | 17:32 |
| dansmith | gmann: ++ | 17:32 |
| knikolla | tc-members: reminder, meeting in ~25 minutes. | 17:34 |
| frickler | the other big batch of py38 drops has happened for most (or all) oslo projects, they've just not been released yet | 17:34 |
| frickler | so you might want to discuss with oslo team about reverting those, too | 17:34 |
| fungi | the main risk with keeping 3.8 in the pti is that at some point we do need projects to drop testing for it, so there still needs to be a coordinated effort when that eventually happens. if 3.8 goes back into the pti without a clear plan for how to eventually drop it without ending up back in this situation, then it's just kicking the can down the road | 17:35 |
| frickler | https://review.opendev.org/q/topic:oslo-drop-py38 | 17:35 |
| gmann | frickler: did they bump min version ? | 17:35 |
| frickler | yes | 17:35 |
| gmann | ohk | 17:35 |
| gmann | frickler: yeah, we need to be more clear in PTI and less aggressive to bump min version. we need plan and document updates on this | 17:36 |
| fungi | short term we need to keep releases of those from getting tagged, but mid-term there should be a plan on how to actually coordinate projects dropping 3.8 testing without creating collateral damage | 17:37 |
| frickler | oslo.db at least has already been released, it's u-c adoption is just blocked by other issues | 17:37 |
| fungi | just keeping 3.8 testing is a non-solution, since it has to go away eventually | 17:38 |
| noonedeadpunk | yes, I totally agree here, said that as well couple of mins ago ^ | 17:38 |
| fungi | so at some point we still have to figure out how to do it cleanly | 17:38 |
| noonedeadpunk | it's just postponing solution | 17:39 |
| frickler | essentially https://review.opendev.org/c/openstack/requirements/+/879743?usp=search | 17:39 |
| frickler | but from a quick check of open reqs reviews that is the only one | 17:40 |
| gmann | yeah until we have to drop due to EOL or external deps which we cannot control, i think keeping support does not harm | 17:43 |
| JayF | So with many things, we have a deadline attached. | 17:43 |
| gmann | for us it is less costly but from usage perspective it is very costly | 17:43 |
| JayF | Perhaps PTI is similar? | 17:43 |
| JayF | We need to set a date for projects to be ready for that move | 17:43 |
| fungi | basically the 2023.2 pti is a promise we're making to our users about the 2023.2 release and subsequent stable/2023.2 stable branch. if the suggestion is that 2023.2 should officially keep python 3.8 support then i guess that does buy some time to figure it out in the 2024.1 cycle so that we hopefully don't wind up right back here | 17:45 |
| fungi | but i wouldn't temporarily update the pti on the premise that it's guidance to our developers, because it's not really | 17:46 |
| JayF | I'm more saying, if the PTI is believed to currently say "no python 3.8 support" | 17:46 |
| dansmith | well, for what it's worth, it's been quoted as the justification for merging the >=3.9 pins | 17:46 |
| JayF | that means there's some period of time where projects are migrating | 17:46 |
| JayF | AFAICT we do not dictate a timeline or any expectation for that | 17:47 |
| bauzas | Well, the PTI is not exclusive | 17:47 |
| JayF | just that "2023.2 works with PTI" | 17:47 |
| dansmith | bauzas: right hence the need for clarity here | 17:47 |
| bauzas | it's inclusive by default "at a minimum" | 17:47 |
| fungi | dansmith: yeah, i'm aware, and i'm saying there's a misperception about what the purpose of the pti is | 17:47 |
| noonedeadpunk | I'd say PTI is bare minimum guaranteed | 17:47 |
| JayF | there's no requirement, for instance, that a project make their tests fit the updated PTI within a period of time | 17:47 |
| dansmith | fungi: okay I thought you were saying that "developers don't look at the PTI" | 17:47 |
| JayF | a project could comply with the policies as written by, halfway through the cycle, upgrading their jobs to comply with PTI | 17:47 |
| JayF | this is why I'm saying there might need to be a timing element added | 17:48 |
| dansmith | JayF: the PTI is sort of point-in-time because it only applies to the actual release, IMHO | 17:48 |
| gmann | we can be more explicitly in PTI about >=py-<version> | 17:48 |
| fungi | i was saying developers shouldn't consider the pti development guidance for how to coordinate changes over the course of the cycle, and temporarily changing the pti during the cycle only to change it back before the release as a signal to developers is misguided | 17:48 |
| bauzas | at least we should explain the PTI is related to the GA, not the cycle | 17:48 |
| dansmith | fungi: sure | 17:48 |
| gmann | I remember we had to do it when we moved from py27 to py3 which was good but it endup increasing the py3 minor version too | 17:48 |
| JayF | dansmith: yeah, that's what I'm saying --> but we've just seen demonstration that *getting to that point in time* can cause breakages, which is why I wonder if we need more coordination in ensuring projects flip over semi-atomically | 17:49 |
| bauzas | by GA, the supported envelope is X and Y | 17:49 |
| dansmith | bauzas: right but that also presents the potential problem fungi is mentioning, that disabling 3.8 for the entire cycle and re-enabling it at the end of the cycle would not be okay either | 17:49 |
| bauzas | honestly I think the ship has sailed for 3.8 | 17:49 |
| bauzas | Here, I see our discussion more like a postmortem | 17:50 |
| dansmith | sure but I'm just using it as the example | 17:50 |
| fungi | the goal of the pti is to paint a picture for what we're guaranteeing to end users about the upcoming release, it doesn't really make a statement about the development cycle itself and developers need different guidance rather than just going off whatever the pti says will be the eventual end state | 17:50 |
| dansmith | fungi: yep | 17:50 |
| bauzas | yeah, so what I'm saying is that devs shouldn't rush by the first weeks to change their support envelope | 17:50 |
| bauzas | fungi: +1 | 17:51 |
| bauzas | that's what I said by "GA" | 17:51 |
| JayF | bauzas: in this case, it's almost like there needs to be a cascade from the outside in. Seems like oslo would be the first things we'd want to support new python and one of the last things we'd want to drop support for old python | 17:52 |
| gmann | we plan well as a community goal while distro version bump and I think we should do for py version too so that all projects will be consistent on what we want to test as min or hard break for some version | 17:52 |
| bauzas | JayF : don't disagree | 17:52 |
| fungi | i'm also not just saying developers should figure it out for themselves, we've got some clear cases where it's easy to make judgement calls which seem reasonable at a small scale but have broader impact on the development progress for other related projects, so putting some actual guidance for similar future transitions together (as well as some quick messaging to the ml about how to stop | 17:52 |
| fungi | the bleeding) is warranted | 17:52 |
| fungi | i'm really mostly concerned with how to not repeat this when we drop support for python 3.9 | 17:53 |
| bauzas | +1 | 17:54 |
| fungi | and using these experiences from the current cycle to help inform that future process | 17:54 |
| dansmith | right | 17:54 |
| bauzas | Isn't 3.10 which removes support for deprecated features in 3.8 ? | 17:54 |
| dansmith | I'm not aware of any.. but 3.11 surely does | 17:55 |
| gmann | I think no as both were running fine together | 17:55 |
| bauzas | I can somehow see some rush happening for eager developers wanting to use fancy things | 17:55 |
| fungi | but for example, having at least one job with the to-be-dropped python version run across all projects while they remove the rest, and keeping the requirements check-uc job for the to-be-dropped version until the end of the cycle | 17:57 |
| fungi | and having a clear deadline for when in the cycle that testing will go away | 17:57 |
| dansmith | man, I'm already worn out from typing and the meeting hasn't even started | 17:57 |
| gmann | :) that is why I like video/voice call than typing | 17:58 |
| bauzas | Oh is the meeting on video? | 17:59 |
| dansmith | me too | 17:59 |
| dansmith | no | 17:59 |
| gmann | bauzas: no, this is IRC | 17:59 |
| bauzas | Ack | 17:59 |
| spotz_ | Next week is video, might miss it I've got a training class and already popping out for the Board meeting | 17:59 |
| knikolla | #startmeeting tc | 18:00 |
| opendevmeet | Meeting started Tue Apr 25 18:00:39 2023 UTC and is due to finish in 60 minutes. The chair is knikolla. Information about MeetBot at http://wiki.debian.org/MeetBot. | 18:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:00 |
| opendevmeet | The meeting name has been set to 'tc' | 18:00 |
| jamespage | o/ | 18:00 |
| knikolla | Hi all, welcome to the weekly meeting of the OpenStack Technical Committee | 18:00 |
| dansmith | o/ | 18:00 |
| gmann | o/ | 18:00 |
| knikolla | #topic Roll call | 18:00 |
| bauzas | o/ | 18:01 |
| knikolla | o/ | 18:01 |
| knikolla | A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct | 18:01 |
| spotz_ | o/ | 18:01 |
| slaweq | o/ | 18:01 |
| knikolla | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 18:01 |
| noonedeadpunk | o/ | 18:01 |
| rosmaita | o/ | 18:01 |
| knikolla | #topic Follow up on past action items | 18:02 |
| knikolla | I don't see any action items noted down from the previous meeting | 18:02 |
| JayF | o/ | 18:02 |
| knikolla | #topic Gate health check | 18:02 |
| knikolla | Any updates to report for this week on the state of the gate? | 18:03 |
| dansmith | lol | 18:03 |
| gmann | lot of updates :) | 18:03 |
| * bauzas rolls eyes | 18:03 | |
| JayF | the gate is closed and locked ;) | 18:03 |
| dansmith | the gate has been deathly ill this week, but things may be better after many reverts | 18:03 |
| slaweq | yeah, it's in bad shape recently | 18:03 |
| dansmith | still waiting for initial results | 18:03 |
| fungi | probably worth deferring discussion of the python 3.8 drops until the dedicated topic later in the agenda | 18:03 |
| dansmith | also probably worth mentioning the ceph thing here | 18:04 |
| dansmith | even though it's acutely related to 38, | 18:04 |
| knikolla | Well, my lunch overlapped with the discussion of the last hour, so hold your eye rolls for now :) | 18:04 |
| dansmith | I'm starting to become concerned about our ability to get ceph tested on jammy in short order | 18:04 |
| bauzas | and the volume detach ssh findings ? | 18:04 |
| gmann | dansmith: if we bring back py38then bringing back focal make sense and ceph jobs will get time at least for this cycle | 18:06 |
| slaweq | I also noticed a lot of failures due to issues with mirrors, especially last week but I don't know if that's somehow fixed already | 18:06 |
| spotz_ | knikolla: just read the scroll while the next person types:) | 18:06 |
| gmann | but yes, we need to sort out it for jammy at some point | 18:06 |
| dansmith | bauzas: every time I look at those I'm seeing the guest's boot seems to have been sufficiently late, so not sure really, but yeah that too | 18:06 |
| knikolla | I'm going to start an etherpad to track all these issues in a parallel manner, as (un)fortunately IRC is a linear medium. | 18:06 |
| knikolla | #link https://etherpad.opendev.org/p/gate-health-2023 | 18:06 |
| dansmith | gmann: not really, IMHO, because if the PTI doesn't include focal, then we're not testing ceph on our supported platforms | 18:06 |
| dansmith | gmann: the reverts have taken the pressure off, but we still need to figure out what we're doing here | 18:07 |
| fungi | slaweq: i'm happy to follow up on the mirror issues after the meeting, though the opendev sysadmins meeting is immediately after this one | 18:07 |
| gmann | dansmith: yes. going more closure to release make it more concern things | 18:07 |
| slaweq | fungi I will go afk just after this meeting, sorry | 18:08 |
| slaweq | I can talk about it tomorrow morning | 18:08 |
| fungi | slaweq: tomorrow is great, thanks! | 18:08 |
| jamespage | I'm not familiar with the specific issues we're seeing on jammy/with ceph but I'm happy to help if there is anything that I can do from the downstream distro side as well | 18:08 |
| dansmith | jamespage: no indication that it's distro related at least at this moment | 18:08 |
| jamespage | well feel free to pull me in if needed :) | 18:09 |
| gmann | this is change which try to mvoe it to jammy #link https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/865315 | 18:09 |
| dansmith | ack, thanks | 18:09 |
| knikolla | Please jot down things in the above linked etherpad, as we have a packed agenda I want to move on to the next item and we can focus on the gate outside of the meeting. https://etherpad.opendev.org/p/gate-health-2023 | 18:11 |
| knikolla | #topic Broken docs due to inconsistent release naming | 18:11 |
| knikolla | I proposed a patch that renames the docs directory to 2023.1 instead of 2023.1.antelope | 18:12 |
| knikolla | https://review.opendev.org/c/openstack/openstack-manuals/+/881290?usp=dashboard | 18:12 |
| spotz_ | looking | 18:12 |
| gmann | thanks, we need the redirect also there | 18:12 |
| knikolla | There's still issues with releases.openstack.org being named antelope, so the links to there don't work | 18:12 |
| spotz_ | knikolla: I'll read through and +w if good after the meeting | 18:13 |
| gmann | I think we should make it /2023.1 as other project specific release notes are with relerase version not name | 18:13 |
| knikolla | And yes, the redirects. | 18:13 |
| gmann | spotz_: there is comment there on redirect | 18:13 |
| spotz_ | That used to be a Jimmy thing but might be a Josh thing now? | 18:13 |
| dansmith | gmann: ++ | 18:13 |
| spotz_ | gmann: Will look, saving reading until we're done:) | 18:13 |
| gmann | example #link https://docs.openstack.org/releasenotes/aodh/2023.1.html | 18:13 |
| fungi | which redirects specifically? | 18:14 |
| knikolla | redirects from docs.openstack.org/2023.1.antelope to 2023.1 | 18:14 |
| clarkb | that isn't a foundation issue it is an openstack-manuals issue | 18:14 |
| gmann | basically this https://releases.openstack.org/antelope/index.html -> https://releases.openstack.org/2023.1/index.html | 18:14 |
| fungi | the foundation webdev folks have nothing to do with docs.o.o, never have | 18:14 |
| fungi | that's why i was asking | 18:14 |
| gmann | oh yes it is not foundation at all | 18:14 |
| gmann | it is in openstack-manuals we need to add redirect | 18:15 |
| fungi | it's an htaccess file in openstack-manuals, right | 18:15 |
| gmann | yes | 18:15 |
| knikolla | yep | 18:15 |
| clarkb | there is the separate issue where the index itself is built with broken links | 18:15 |
| clarkb | this is also an openstack-manuals issue and I haven't seen resolution for this issue either | 18:15 |
| *** spotz_ is now known as spotz | 18:16 | |
| fungi | if there's anything you need changed on the openstack.org site pertaining to links to documentation or something, i'm happy to loop in the right foundation webdev folks | 18:16 |
| gmann | knikolla: is your patch change this too? https://releases.openstack.org/antelope/index.html -> https://releases.openstack.org/2023.1/index.html | 18:16 |
| gmann | or this page is from other place? | 18:16 |
| knikolla | gmann, i don't believe it does. no. | 18:16 |
| knikolla | i have to hunt down where that is. | 18:16 |
| gmann | ohk | 18:16 |
| fungi | that'll be the openstack/releases repo | 18:17 |
| knikolla | I'm taking this work on and tracking the issues I find and patches here | 18:17 |
| knikolla | #link https://etherpad.opendev.org/p/docs-issues-2023 | 18:17 |
| spotz | Ok sounds like hold off on the review until we have all the pieces ready? | 18:17 |
| knikolla | I'll add the index issue and release name in the therpad as well. | 18:17 |
| gmann | knikolla: may be this? #link https://github.com/openstack/releases/blob/master/doc/source/antelope/index.rst | 18:17 |
| fungi | there will be multiple changes to fix the various problems, because some are in different repositories | 18:17 |
| gmann | spotz: and it is not foundation things, it is in openstack-manual which used to be maintained by doc sig and now TC | 18:18 |
| spotz | gmann: Yeah I got that already | 18:18 |
| knikolla | fungi: ++, there's a lot of interrelated things | 18:18 |
| gmann | we need to make sure consistency. | 18:18 |
| knikolla | anyhow, feel free to reach out to me with new issues you find and checking the etherpad. | 18:18 |
| gmann | thanks knikolla for fixing it. will add in etherpad if I find any other | 18:19 |
| knikolla | thank you gmann | 18:19 |
| knikolla | #topic Following new release naming convention by packagers (UCA/RDO) | 18:19 |
| knikolla | I'm not familiar with the topic, anyone care to elaborate? | 18:19 |
| gmann | I think it was added during last week meeting. noonedeadpunk ? | 18:19 |
| gmann | if I remember correctly | 18:19 |
| noonedeadpunk | yup. so the case here is that uca/rdo does name repos as antelope instead of 2023.1 | 18:20 |
| bauzas | well, those are distros | 18:20 |
| fungi | bearing in mind that uca and rdo are not governed by the openstack tc | 18:20 |
| bauzas | yeah that | 18:20 |
| gmann | yeah :) | 18:20 |
| bauzas | we can't really dictate their names | 18:20 |
| noonedeadpunk | When I talked to RDO folks they were reffering our docs that both names are valid | 18:21 |
| gmann | i think here proposal is to have consistency which can be more better | 18:21 |
| noonedeadpunk | but they did not mind changing that | 18:21 |
| gmann | tc does not need to force them but giving recommendation for consistency is good | 18:21 |
| noonedeadpunk | So we could give some recommendations or ask them | 18:21 |
| bauzas | noonedeadpunk: well, all the stable branches now proof themselves on how a release shall be named | 18:21 |
| gmann | noonedeadpunk: ++ | 18:21 |
| slaweq | if distros could and want change it, that would be great IMO | 18:21 |
| gmann | yeah | 18:21 |
| noonedeadpunk | so spotz and jamespage are here and I guess they might know some insides and if it's possible to be consistent here from their side | 18:22 |
| fungi | it may make sense to have some guidance on a recommended way to label our releases, and on how to combine the release number and the marketing moniker for the release in the least confusing way possible | 18:22 |
| knikolla | makes sense. it's good to be consistent ourselves moving forward so that provides clear guidelines for others as well. | 18:22 |
| jamespage | I can check with coreycb on the UCA side | 18:23 |
| spotz | noonedeadpunk: We should be able to rename directories and such for RDO | 18:23 |
| fungi | since the codename gets a lot of press and ends up in news articles about each release, i can understand downstream distributions wanting to include it for clarity | 18:23 |
| gmann | ++ thanks jamespage spotz | 18:23 |
| noonedeadpunk | Yes, so where I agree is that codenames are closer to ppl then release numbers | 18:24 |
| knikolla | ++ | 18:24 |
| noonedeadpunk | But double naming has potential of raising huge confusion | 18:24 |
| jamespage | in Ubuntu codenames and release versions are used fairly interchangeable | 18:24 |
| bauzas | noonedeadpunk: well, fwiw, even Nova will switch to release numbers in Launchpad by 2024.1 | 18:24 |
| fungi | for examples, we can look at how distros like debian and ubuntu combine their release codenames and release numbers for public-facing communications | 18:25 |
| bauzas | supporting both is creating more problems | 18:25 |
| knikolla | agree fully, noonedeadpunk | 18:25 |
| jamespage | most of the internal technical plumbing is codename based by the release uses the version | 18:25 |
| noonedeadpunk | As indeed I hardly imagine in regular talk of 2 operators see how they will use release number when codename is present | 18:25 |
| gmann | bauzas: true. | 18:25 |
| knikolla | fungi: once we have fixed docs, I want to look into building the infrastructure for that. The current docs tooling didn't support the name being different than the branch. | 18:25 |
| bauzas | I just feel that the nickname can continue to exist, provided we don't have it as a *reference* | 18:26 |
| fungi | knikolla: yeah, that makes sense | 18:26 |
| knikolla | But it makes a lot of sense to create the possibility to decouple the displayed name and the branch name. | 18:26 |
| spotz | bauzas: I think it might still show up on like the releases page and referenced on the index page as a project. Kind of how you type out a fullname then abbreviate after it | 18:27 |
| coreycb | in ubuntu we stuck with the codename antelope for the cloud archive since it aligns with use of the ubuntu codename in /etc/apt/sources.list | 18:27 |
| bauzas | at least the TC reference is clear : release numbers are prioritary and should always take precedence over codenames | 18:27 |
| fungi | using the release numbers in urls, suite names, package mirrors seems to be the tc's recommendation, but shouldn't exclude the possibility to also mention the release name in more "cosmetic" parts of documentation and the like | 18:28 |
| knikolla | ++, i think we already have a resolutions pushing for numbers. | 18:28 |
| gmann | yes | 18:28 |
| bauzas | fungi: +1 and fwiw I feel the TC reference to clearly stating this already | 18:28 |
| noonedeadpunk | coreycb: yes, but would it be possible in future releases to switch to release version? | 18:28 |
| fungi | so it's mainly a matter of turning that into clearer guidance for downstream distributions and communicating it to them | 18:28 |
| gmann | @link https://governance.openstack.org/tc/resolutions/20220524-release-identification-process.html | 18:28 |
| noonedeadpunk | As we're trying to align on using that instead of codenames across all of the docs | 18:28 |
| gmann | #link https://governance.openstack.org/tc/resolutions/20220524-release-identification-process.html | 18:28 |
| bauzas | knikolla: even a TC reference page, not only a TC resolution (which is sometimes hard to find) | 18:28 |
| knikolla | thanks gmann | 18:29 |
| gmann | #link https://governance.openstack.org/tc/reference/release-naming.html | 18:29 |
| gmann | bauzas: ^^ | 18:29 |
| noonedeadpunk | btw we don't inlcude there any guidance for downstream maintainers | 18:29 |
| coreycb | noonedeadpunk: it's certainly possible if there's a good argument for it | 18:29 |
| fungi | yes, that's what i'm saying | 18:29 |
| knikolla | anything else on the topic? | 18:29 |
| noonedeadpunk | So should we add some guidance to release-naming? | 18:30 |
| knikolla | I'd be in favor of such guidance. | 18:31 |
| fungi | it would make sense to add a section about downstream redistribution recommending use of the release number for things like mirror directories, suite identifiers, and so on | 18:31 |
| gmann | that will be good if we can mention it explicitly about what we recommend for downstream | 18:31 |
| noonedeadpunk | ++ | 18:31 |
| fungi | things that matter to distributions | 18:31 |
| fungi | right now it's focused on things that matter upstream | 18:31 |
| gmann | yeah | 18:31 |
| noonedeadpunk | coreycb: would that be a good argument? | 18:31 |
| knikolla | most importantly it reduces confusion for the users of those distributions | 18:31 |
| coreycb | noonedeadpunk: sorry, which point? | 18:32 |
| knikolla | With the current docs inability to reference both 2023.1 and antelope on the same line it's not immediately obvious to new users who might be using something downstream or from another vendor. | 18:32 |
| noonedeadpunk | If TC will add suggestions for maintainers of downstream packages on naming of OpenStack releases to https://governance.openstack.org/tc/reference/release-naming.html | 18:32 |
| fungi | coreycb: about adding a section to the release-naming document providing guidance to downstream package maintainers and other redistributors | 18:33 |
| gmann | at least that will help for future release if antelope cannot be fixed at this stage | 18:33 |
| knikolla | anyone volunteers to take the action to propose the addition to the reference? | 18:34 |
| noonedeadpunk | Yeah, for Antelope it's too late at this point | 18:34 |
| noonedeadpunk | I can | 18:34 |
| coreycb | fungi: sure but I wouldn't mind getting a chance to review the recommendations | 18:34 |
| knikolla | #action noonedeadpunk to propose a patch to reference that makes the recommendation for downstream packagers to use the version name rather than codename. | 18:34 |
| knikolla | thanks noonedeadpunk | 18:35 |
| fungi | coreycb: they'll be in gerrit! ;) | 18:35 |
| knikolla | We can continue the discussion on Gerrit and fine tune the specifics there. | 18:35 |
| noonedeadpunk | I'll add you to reviewers explicitly | 18:35 |
| gmann | coreycb: we will add/ping you | 18:35 |
| gmann | +1 | 18:35 |
| knikolla | Moving on to the next topic | 18:35 |
| knikolla | #topic Schedule of removing support for Python versions by libraries - how it should align with coordinated releases (tooz case) | 18:35 |
| noonedeadpunk | and rdo folks as well :) | 18:35 |
| noonedeadpunk | (and zigo) | 18:36 |
| gmann | noonedeadpunk: thanks for noticing it | 18:36 |
| dansmith | some of us have already discussed this to death at this point | 18:37 |
| knikolla | I know you talked extensively about this before the meeting and I haven't been able yet to catch up on the conversation. | 18:37 |
| gmann | yeah | 18:37 |
| noonedeadpunk | yes, so this is the topic that was heavily discussed even before the meeting | 18:37 |
| dansmith | I wonder if maybe it would be better to have one person put up a proposal and we can discuss from there? | 18:37 |
| knikolla | dansmith: ++ | 18:37 |
| noonedeadpunk | you wanna do that dansmith? | 18:37 |
| fungi | yeah, i started the discussion two hours early in hopes we could get to some shared consensus and not consume the whole meeting with it | 18:37 |
| bauzas | can I try ? | 18:38 |
| gmann | +1 dansmith you want ? | 18:38 |
| dansmith | noonedeadpunk: I was going to suggest you :D | 18:38 |
| noonedeadpunk | ah, ok, I can | 18:38 |
| dansmith | I'm pretty slammed with the fallout from this still | 18:38 |
| dansmith | if you're willing, that would be cool, but I can if you don't want to | 18:38 |
| bauzas | at least I'm more than happy to contribute to it | 18:38 |
| gmann | I think noonedeadpunk is typing the proposal :) | 18:39 |
| fungi | would a quick recap be useful for the meeting logs? | 18:39 |
| noonedeadpunk | I'm good but bauzas seem to be eager to :) | 18:39 |
| knikolla | I would also encourage sending a message to the mailing list with a link to the proposal on Gerrit to invite wider awareness | 18:39 |
| clarkb | I think one thing that should be done right now is get the release team tostop making releases | 18:40 |
| bauzas | fungi: seems appropriate | 18:40 |
| JayF | knikolla: ++ | 18:40 |
| clarkb | to stop the bleeding and allow the proposal(s) to be worked through | 18:40 |
| gmann | so who is putting proposal here? | 18:40 |
| rosmaita | fungi: ++ to a quick recap, i still have like 50 lines left to read in the scrollback | 18:40 |
| dansmith | clarkb: that that's probably a good idea | 18:40 |
| dansmith | I can summarize where I think we landed | 18:41 |
| slaweq | please do summarize as I didn't read previous discussion at all :) | 18:41 |
| fungi | quick recap then: we have a pti that does not mention us testing/supporting the 2023.2 release on python 3.8, and that has resulted in some projects eagerly removing their 3.8 testing and marking themselves as not installable on 3.8 | 18:41 |
| gmann | #link https://governance.openstack.org/tc/reference/runtimes/2023.2.html | 18:42 |
| dansmith | I think (a) recommend that we not aggressively bump the python version minimum to meet the PTI (b) keep some minimal like unit jobs on older python versions to ensure language compatibility even beyond supported platforms, | 18:42 |
| fungi | this makes them no longer coinstallable with other projects who are in the process of trying to remove 3.8 jobs but haven't finished doing so yet | 18:42 |
| noonedeadpunk | plus we need probably to clarify what PTI is | 18:42 |
| fungi | some projects have very legitimate reasons for still running 3.8 jobs, including issues getting ceph working on 3.9 | 18:42 |
| dansmith | (c) recommend wider support amongst "library packages" (for whatever that means) and (d) perhaps better define how the scheduling of bumps like this should be digested in a cycle where they're changing | 18:42 |
| gmann | ++, mentioning explicitly it in PTI and we also be less aggressive to drop older py from testing runtime | 18:43 |
| fungi | also nested virt issues with ubuntu jammy in one of our test node donors | 18:43 |
| bauzas | dansmith: I think you captured the 4 actions we discussed | 18:43 |
| noonedeadpunk | yes, ++ dansmith | 18:43 |
| * dansmith takes a bow | 18:43 | |
| gmann | dansmith: ++, all four | 18:43 |
| fungi | so anyway, yes, some coordination would be useful in order to stop projects from breaking each other's testing while removing python 3.8 testing of their own | 18:43 |
| fungi | in the near term, we need to stop the bleeding, longer term we would benefit from having a clear process and schedule for such things over the course of a development cycle | 18:44 |
| bauzas | the #3 is more a recommendation to say "if you think you're imported, consider to bump your minimums probably at the latest rather than at the earliest" | 18:44 |
| gmann | and do we want to bring back py38 in testing runtime as it is not very mandatory to drop at least in this cycle ? | 18:44 |
| bauzas | gmann: thought it was captured by action #2 | 18:44 |
| dansmith | gmann: yes, I do | 18:44 |
| dansmith | bauzas: right | 18:45 |
| knikolla | I hope people haven't already started taking advantage of 3.9 features | 18:45 |
| dansmith | knikolla: hahaha | 18:45 |
| gmann | ok, so we will add it in general template not just recommend to test | 18:45 |
| bauzas | by 3 weeks ? man, this is not eager, this is avid ! | 18:45 |
| bauzas | not being* eager | 18:45 |
| knikolla | :) | 18:46 |
| bauzas | gmann: I think those 4 actions have to be documented in 2023.2 PTI | 18:46 |
| gmann | bauzas: yes and update testing runtime for 2023.2 | 18:46 |
| dansmith | isn't that what 2023.2 PTI means? | 18:46 |
| gmann | and how about focal? do we want to add it as best effort testing in 2023.2 testint runtime? | 18:46 |
| dansmith | gmann: noonedeadpunk is opposed to that, | 18:47 |
| dansmith | and I'm okay with that, modulo my concerns about ceph | 18:47 |
| noonedeadpunk | Yeas, don't like that idea at all | 18:47 |
| fungi | we could also do a better job of communicating that the pti is how we describe the end result, it's not the process for getting there | 18:47 |
| gmann | dansmith: I mean few of the things you mentiond can go in general PTI documentation also to follow in future also | 18:47 |
| dansmith | gmann: ack | 18:47 |
| gmann | dansmith: noonedeadpunk: yeah because of ceph | 18:47 |
| slaweq | gmann giving the fact that we have those issues with nested virt on jammy I think we should add Focal back as best effort | 18:47 |
| gmann | slaweq: ah that too | 18:47 |
| slaweq | because still some projects are doing that actually :) | 18:47 |
| noonedeadpunk | gmann: no, because it won't work for nova and neutron at very least | 18:48 |
| dansmith | slaweq: the problem there is that nova was going to drop support for focal's libvirt like weeks ago if allowed | 18:48 |
| dansmith | slaweq: so it becomes sticky | 18:48 |
| bauzas | gmann: oh, you'd prefer to enforce those recommendations in the global PTI doc ? | 18:48 |
| bauzas | https://governance.openstack.org/tc/reference/project-testing-interface.html | 18:48 |
| noonedeadpunk | as both of them require more modern versions of qemu/libvirt/ovs/ovn/etc then is provided | 18:48 |
| gmann | bauzas yeah we should do that so that we avoid this situation in near future, especially less aggressive on drooping older python from release pti | 18:48 |
| fungi | yeah, neutron wanted to start requiring ovs built from downloaded source code last cycle, right? | 18:49 |
| dansmith | gmann: ah yes, I confuse the current and global PTI documents.. so I agree, both | 18:49 |
| gmann | noonedeadpunk: dansmith ohk. in that case I agree it is not easy to add focal then | 18:49 |
| bauzas | gmann: cool with that, this makes them generic | 18:49 |
| noonedeadpunk | gmann: also, if we add focal back, we will need to carry it till 2024.1, just in case | 18:49 |
| bauzas | yup, because B is non-SLURP | 18:49 |
| dansmith | I dunno that I agree with that, | 18:50 |
| gmann | humm, true | 18:50 |
| bauzas | I think we haven't discussing the upgrade scenarios in a skip-level release but we're consistent | 18:50 |
| dansmith | but if we're not adding it back, no need to argue about it :) | 18:50 |
| fungi | that might also ease the fips testing situation, since there's no ubuntu fips support for jammy yet? | 18:50 |
| dansmith | fungi: yeah tht's true... | 18:50 |
| dansmith | but again, nova would have to not do its min version bump on libvirt | 18:50 |
| gmann | yeah, let's not do for focal. | 18:50 |
| dansmith | it won't offend me, but sean will be quite unhappy with you people :D | 18:51 |
| slaweq | ok, makes sense | 18:51 |
| gmann | I think let's go with py38 things and dansmith proposals of those 4 points | 18:51 |
| noonedeadpunk | and I think this might hold on virtiofs support or make it tricky... anyway | 18:51 |
| dansmith | noonedeadpunk's proposal of my four points right? | 18:51 |
| noonedeadpunk | ++ | 18:51 |
| dansmith | feel free to refer to them as "The Smith Plan(tm)" | 18:52 |
| gmann | :) | 18:52 |
| dansmith | I will not charge royalties for the use of my four points until at least 2030 | 18:52 |
| slaweq | :) | 18:52 |
| bauzas | noonedeadpunk: not sure I see the implications about virtiofs support but meh, not the right chan and time to discuss this :) | 18:52 |
| knikolla | dansmith or noonedeadpunk, either of you wants to write the required changes? | 18:52 |
| dansmith | knikolla: noonedeadpunk is writing them | 18:52 |
| gmann | ++ | 18:52 |
| bauzas | ++ | 18:53 |
| gmann | i can do general job template changes once governance things are merged | 18:53 |
| dansmith | sweet | 18:53 |
| knikolla | #action noonedeadpunk write the words for "The Smith Plan(tm)" (the script of the movie about changing PTI and saving the world from the dangers of getting rid of py38) | 18:53 |
| fungi | and olso (possibly others) are going to need to revert changes in repos | 18:53 |
| dansmith | knikolla: I did not release the screenplay rights, to be clear | 18:54 |
| bauzas | I reached hberaud earlier today | 18:54 |
| fungi | and the release team needs to put a hold on release requests for things that merged changes to mark themselves uninstallable on 3.8 | 18:54 |
| gmann | yeah. and if any other projects has done that | 18:54 |
| bauzas | he knows the situation so I hope he's aware of the implications of a new release | 18:54 |
| noonedeadpunk | I think we'd need to come up with ML as well quite ASAP | 18:54 |
| fungi | bringing back the check-uc reqs job for py38 asap would be good too | 18:54 |
| bauzas | but I can loop back tomorrow and discuss with elod and hervé | 18:54 |
| dansmith | fungi: that's already merged IIUC | 18:54 |
| gmann | let's push the governance changes, merge then and ML | 18:54 |
| noonedeadpunk | But won't be able to do that until tomorrow afternoon just to have that said | 18:55 |
| dansmith | as in, like minutes ago | 18:55 |
| fungi | dansmith: just while we were discussing? awesome! | 18:55 |
| knikolla | Seems like there's a lot of moving parts, noonedeadpunk, do you want to also start an etherpad for dealing with the fallout? | 18:55 |
| dansmith | fungi: https://review.opendev.org/c/openstack/requirements/+/881433 | 18:55 |
| fungi | perfect | 18:55 |
| dansmith | we flap our gums and frickler gets sh*t done | 18:56 |
| spotz | hehe | 18:56 |
| noonedeadpunk | #link https://etherpad.opendev.org/p/the-smith-plan | 18:56 |
| knikolla | brilliant! | 18:56 |
| dansmith | haha | 18:56 |
| noonedeadpunk | we should not forget to clean the link up until 2030 | 18:56 |
| knikolla | 100% rotten tomatoes | 18:57 |
| noonedeadpunk | s/until/before | 18:57 |
| dansmith | I will consider renewal plans six months ahead of the deadline | 18:57 |
| gmann | I can push it on ML asking project/release team to hold dropping the py38 until we get the pti change merged | 18:57 |
| bauzas | noonedeadpunk: straight copy the etherpad content into a gerrit patch and then I'll happily +1 it :) | 18:57 |
| knikolla | on* | 18:57 |
| knikolla | haha | 18:57 |
| knikolla | alright, we're almost out of time. | 18:57 |
| knikolla | #action gmann send an email on ML asking project/release team to hold dropping the py38 until we get the pti change merged | 18:57 |
| dansmith | I'm glad.. I'm so sick of py38 at this point :) | 18:58 |
| knikolla | I think we have a good plan forward. | 18:58 |
| gmann | :) it seems more than py27 | 18:58 |
| dansmith | hah.. too soon. | 18:58 |
| knikolla | Thanks all for a productive meeting. We're out of time. | 18:59 |
| dansmith | move to adjourn? | 18:59 |
| knikolla | #endmeeting | 18:59 |
| opendevmeet | Meeting ended Tue Apr 25 18:59:25 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2023/tc.2023-04-25-18.00.html | 18:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2023/tc.2023-04-25-18.00.txt | 18:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2023/tc.2023-04-25-18.00.log.html | 18:59 |
| JayF | second | 18:59 |
| slaweq | o/ | 18:59 |
| gmann | thanks all | 18:59 |
| bauzas | \o and thanks | 18:59 |
| jamespage | thanks for chairing knikolla | 18:59 |
| knikolla | :) | 19:00 |
| spotz | Thanks knikolla and everyone | 19:00 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!