| rubasov | hi! Maybe you know already, but it seems we have a pypi mirror that's out of sync. For example here, I believe we should have tooz 4.0.0, but we don't: http://mirror.bhs1.ovh.opendev.org/wheel/ubuntu-22.04-x86_64/tooz/ | 08:08 |
|---|---|---|
| frickler | rubasov: nope, working fine. you likely want to install tooz 4.0.0 on python3.8, which it no longer supports. time to update your testing | 08:11 |
| frickler | oh, wait, this is about wheels. wheel builds are broken for three weeks now, yes, but that shouldn't matter | 08:11 |
| frickler | the original upstream wheel is available at https://tarballs.opendev.org/openstack/tooz/ just fine | 08:12 |
| rubasov | frickler: thanks for the answer, actually I'm trying to understand the cause of this, maybe I misattributed it to the missing wheel files: https://zuul.opendev.org/t/openstack/build/283eb788bad441488592bde29c520cdf | 08:14 |
| frickler | rubasov: that failure matches my first comment. focal has python3.8, which is no longer a supported test platform for master / 2023.2.bobcat | 08:15 |
| rubasov | frickler: thank you, will look into that then | 08:15 |
| opendevreview | Rodolfo Alonso proposed openstack/project-config master: Remove "neutron-ovn-tempest-ovs-release-ubuntu-old" job https://review.opendev.org/c/openstack/project-config/+/881340 | 09:00 |
| frickler | that tooz issue is becoming a faq, wonder if it would help to do a status notice | 10:09 |
| frickler | maybe we can call it good luck that the u-c bump for oslo.db is still blocked by its side effects | 10:10 |
| *** iurygregory_ is now known as iurygregory | 11:55 | |
| *** dviroel__ is now known as dviroel | 12:04 | |
| kozhukalov_ | Hi folks. What if I would like to perform some organizational changes in storyboard (deprecate some projects, remove them from a project group). Should I ask someone with admin rights to do this, or maybe I can become an admin for a project group? I am a PTL of openstack-helm and I would like to cleanup the openstack-helm storyboard project group. | 12:07 |
| fungi | kozhukalov_: the public interface for updating that is to push changes for https://opendev.org/openstack/project-config/src/branch/master/gerrit/projects.yaml | 12:30 |
| fungi | kozhukalov_: removing from groups is just a matter of removing group names from those project entries | 12:30 |
| fungi | but as far as deprecating and/or retiring projects, the tc has a documented process you need to follow: https://opendev.org/openstack/project-config/src/branch/master/gerrit/projects.yaml | 12:31 |
| kozhukalov_ | Thanks for the link. This is only about cleaning up the storyboard. These projects themselves (openstack-helm related) have been already deprecated accoring to the TC procedure. | 12:39 |
| fungi | kozhukalov_: oh, in that case after we get them removed from the groups by merging a change to gerrit/projects.yaml i can use admin access to change the descriptions for them in sb if desired as well as switch them to inactive in the database | 12:47 |
| fungi | make sure to clean up the use-storyboard flag on them too if it's still set | 12:48 |
| opendevreview | Merged openstack/project-config master: Remove "neutron-ovn-tempest-ovs-release-ubuntu-old" job https://review.opendev.org/c/openstack/project-config/+/881340 | 14:00 |
| clarkb | rubasov is gone now but the wheel mirrors are also only there to provide wheels which don't exist on pypi. https://pypi.org/project/tooz/4.0.0/#files has a wheel so we don't put one in the wheel mirror | 15:32 |
| clarkb | then the failure is due to requires-python>=3.9 | 15:32 |
| clarkb | I do wonder why tooz is doing that though | 15:33 |
| clarkb | it is a library it probably shouldn' | 15:33 |
| clarkb | * it probably shouldn't aggressively drop python support like the openstack applications | 15:33 |
| fungi | worth bringing up in #openstack-oslo i suppose, but in the short term that requirements bump probably ought to be reverted | 15:42 |
| clarkb | looks like octavia, cinder, neutron, nova at least are affected. I think this illustrates why you don't aggressively remove python support from libraries | 15:42 |
| clarkb | you remove it from applications then libraries and we have the order the wrong way around here | 15:42 |
| clarkb | and that doesn't even consider there may be third party users of tooz (and other oslo libs) | 15:43 |
| *** dasm is now known as Guest12046 | 15:52 | |
| bauzas | clarkb: huge +1 | 15:55 |
| bauzas | removing a python version is pretty aggressive | 15:55 |
| bauzas | you're pulling your consumers on a stretch goal to align their requirements with yours | 15:56 |
| noonedeadpunk | well... for 2023.2 min python version is set to 3.9... | 15:58 |
| noonedeadpunk | so kind all should support py3.9 | 15:59 |
| noonedeadpunk | from other side, I'd say that stable branches should use u-c which does contain tooz | 16:00 |
| dansmith | clarkb: +100 | 16:00 |
| noonedeadpunk | it raises the concern of security patches though... | 16:00 |
| clarkb | noonedeadpunk: two things. 1) you can support 3.9 while still supporting 3.8. This is probably a very good idea for libraries 2) thats for the applications at the end of the cycle. Doesn't mean they will all drop 3.8 two weeks in. oh and 3) oslo libraries can be used outside fo openstack | 16:00 |
| dansmith | clarkb: agree | 16:00 |
| noonedeadpunk | I'm not disagreeing with that though | 16:01 |
| clarkb | noonedeadpunk: the change that was made dropped support for 3.8 and only support 3.9 or newer which is causing all of the trouble. Because the libary got ahead of its consumers | 16:02 |
| noonedeadpunk | Especially while python hasn't even reached it's EOL... | 16:02 |
| noonedeadpunk | even 3.7 hasn't | 16:03 |
| noonedeadpunk | also, there was no real reason for this drop except reducing amount of CI jobs: https://opendev.org/openstack/tooz/commit/4a18ae10b8d2dc164b4607fcd0728bb24516a723 | 16:05 |
| noonedeadpunk | I think we have quite solid gap in our releasing schedule logic | 16:06 |
| noonedeadpunk | As according to paper they didn't do anything wrong | 16:07 |
| clarkb | noonedeadpunk: I think the problem is the releasing schedule logic is based on applications (your openstack cloud) and not libraries | 16:10 |
| clarkb | It is totally fine for an application to say "I need to run on newer platforms" but it is more difficult for libraries to get away with that if they are consumed by applicated | 16:11 |
| clarkb | *consumed by applications | 16:11 |
| noonedeadpunk | at the same time it includes libraries deadlines that are before other services | 16:11 |
| clarkb | right this is why I'm saying practice needs to change. | 16:11 |
| clarkb | libraries should not drop python support as aggressively as applications. Wait until the next release at the very least | 16:12 |
| clarkb | But maybe go longer depending on who may be consuming the library (for example PBR) | 16:12 |
| noonedeadpunk | I can hardly imagine how to write this down or explain anyone taking into account SLURP | 16:13 |
| bauzas | noonedeadpunk: most of the concerns are purely related to the language description change for the lib | 16:13 |
| bauzas | tooz can claim they no longer support py3.8 since the 2023.2 runtimes are clear | 16:14 |
| bauzas | but removing the python language version of 3.8 is a huuuuge PITA for the library consumers since they need to adapt | 16:14 |
| noonedeadpunk | to be frank I'd rely here on best judgement of library maintainers, but that seemed to already failed | 16:15 |
| bauzas | well, if we only look at facts, then the gate is now blocked with no clear path forward yet | 16:15 |
| bauzas | a bit of communication in advance wouldn't have harmed | 16:16 |
| bauzas | but alas, a library doesn't know its consumers, | 16:16 |
| bauzas | so the least thing they can do is to provide some interim period for their consumers to adapt | 16:17 |
| noonedeadpunk | I think the fix would be to add to u-c tooz<4.0? | 16:18 |
| dansmith | agree.. saying it's not supported is fine.. blocking *anything* that installs it on the host from using python 3.9 is to aggressive, IMHO | 16:18 |
| dansmith | fine for an application, not cool for a library | 16:18 |
| noonedeadpunk | https://opendev.org/openstack/requirements/src/branch/master/upper-constraints.txt#L374 | 16:18 |
| noonedeadpunk | yeah, I'm not protecting the decision, I'm saying it's not violating any rules | 16:19 |
| dansmith | I think some of us are saying.. we should have a rule :) | 16:19 |
| noonedeadpunk | That's totally fair. I've already added it to TC meeting agenda | 16:20 |
| noonedeadpunk | I;ve also created a revert https://review.opendev.org/c/openstack/requirements/+/881329 | 16:22 |
| dansmith | noonedeadpunk: cool, I was going to suggest we discuss it on the tc meeting as well | 16:25 |
| bauzas | noonedeadpunk: thanks for the revert proposal | 16:47 |
| * bauzas drops for the day | 16:47 | |
| gmann | just saw the logs, I think we need to drop py3.8 things completely from current master as testing runtime define. but let's discuss it in TC meeting | 18:32 |
| fungi | gmann: if you mean "drop py3.8 things immediately" then that's basically stop running jobs for most affected projects. we're at the beginning of the cycle, they should have plenty of time still to do the necessary work to update instead of just turning off their jobs | 18:39 |
| fungi | libraries intentionally breaking themselves on earlier python versions before projects depending on them have had time to meet those new requirements only makes that harder | 18:41 |
| gmann | fungi: yes, those jobs should be removed by now but we need to stop testing it. | 18:41 |
| gmann | in start of cycle itself we should have stop testing that but I think it is time now. | 18:42 |
| gmann | many project/lib might be doing(soon) python_requires = >=3.9 in setup.cfg and that will hard break many | 18:43 |
| fungi | so basically stop testing octavia because they're having trouble getting working nested virt on a platform with 3.9, drop ceph jobs, and so on | 18:43 |
| fungi | gmann: if you mean many openstack libs are going to start doing that, we have some control over it. things outside openstack are generally more conservative given that even python 3.7 isn't eol yet | 18:44 |
| gmann | that is I hoping to get it sorted out by now as we decided to not test py38 in the start of cycle | 18:46 |
| fungi | if we wanted to not test py38 at the start of the cycle, we should have been working on dropping py38 testing last cycle | 18:51 |
| *** Guest12046 is now known as dasm | 19:40 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!