| *** elodilles_pto is now known as elodilles | 08:51 | |
| tkajinam | Can we get https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/960639 merged so that we can bump functional tests to use py313 ? | 16:13 |
|---|---|---|
| clarkb | tkajinam: I think that poinst out a bug in the 312. It doesn't need to use pyenv because ubuntu-noble ships python3.12 in the distro packages | 16:15 |
| clarkb | +2 from me. I think there may be some things around thread free python and normal python using pyenv too but we can debug that when we get there | 16:16 |
| tkajinam | ah, I think you are talking about that python_use_pyenv: True line, right ? | 16:16 |
| * tkajinam is looking at the other templates and now understand what is explained | 16:17 | |
| clarkb | tkajinam: yes that line shouldn't be used for py312 on noble. But it is needed for 313 on noble so the change you linked is correct | 16:17 |
| clarkb | I just wanted to point out the issue I saw with the other job. In theory using the distro packages when we can will get us slightly better performance | 16:18 |
| clarkb | and we can debug 313 issues when we have some real data | 16:18 |
| opendevreview | Merged openstack/project-config master: Add Kubernetes Module Manager app https://review.opendev.org/c/openstack/project-config/+/965422 | 16:19 |
| tkajinam | yeah | 16:19 |
| fungi | tkajinam: clarkb: why not just run on debian-trixie? | 16:19 |
| clarkb | that is an option too, I guess now that the mirrors are up there isn't a reason not to | 16:20 |
| *** jonher_ is now known as jonher | 16:20 | |
| tkajinam | fungi, I followed the existing py313 job. | 16:20 |
| tkajinam | we can technically use trixie but I'm a bit hesitant to do so at this timing, given the multiple issues we hit when we introduced bookworm for py311 jobs | 16:21 |
| tkajinam | we've been running that py313 job for some time and are now trying to make it mandatory | 16:22 |
| tkajinam | though it might be "the last chance" timing to try trixie | 16:22 |
| clarkb | I think getting it started on ubuntu or debian is fine as you're likely to hit issues with the new python regardless | 16:22 |
| clarkb | then can optimize from there | 16:22 |
| fungi | sure, just noting that running py313 jobs by compiling the interpreter is probably less like what people would actually be running in the wild, not to mention a lot of additional work the job has to do | 16:22 |
| clarkb | yes it will add about 3-5 minutes per job iirc | 16:23 |
| clarkb | which is not 0 but also not terrible | 16:23 |
| fungi | well, also it'll be an unoptimized interpreter, so potentially slower running the tests themselves | 16:23 |
| fungi | also https://governance.openstack.org/tc/reference/runtimes/2026.1.html says debian 13 (trixie) is a tested runtime for openstack 2026.1, and that python 3.13 is being tested because it's the default in trixie | 16:27 |
| tkajinam | ok | 16:27 |
| tkajinam | I thought they provide packages of newer pythons but I eventually noticed I was confused by centos/fedora doing so | 16:28 |
| fungi | testing 3.13 and avoiding testing it on trixie seems counter to the intent of the 2026.1 pti | 16:28 |
| tkajinam | ok | 16:32 |
| tkajinam | let me check if trixie works. if it does then we can use it for that new job | 16:33 |
| tkajinam | I'm wondering if we want to move the base py313 job as well (though we may not want to affect stable branches) but that's a different topic | 16:33 |
| opendevreview | Takashi Kajinami proposed openstack/openstack-zuul-jobs master: DNM: Testing Debian Trixie https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/967582 | 16:34 |
| *** starkis is now known as Guest31500 | 16:36 | |
| tkajinam | oh it seems we need that nodepool first | 16:37 |
| fungi | i guess other jobs have been using anonymous nodeset definitions for it up to now | 16:38 |
| fungi | tkajinam: it would go here... https://opendev.org/opendev/base-jobs/src/branch/master/zuul.d/nodesets.yaml | 16:39 |
| tkajinam | https://opendev.org/openstack/openstack-ansible/src/branch/master/zuul.d/nodesets.yaml#L34 | 16:39 |
| clarkb | fungi: that raises a qusetion of how we want to manage nodesets going forward. I suspect we want to be explicit eg nodeset with memory suffix using labels with suffix too | 16:41 |
| clarkb | tkajinam: note we don't have the generic labels anymore with new images | 16:42 |
| clarkb | trixie and centos 10 stream may be the first to only have explicit labels | 16:42 |
| tkajinam | clarkb, ah, yes. I noticed that when I was playing with c10s things | 16:42 |
| tkajinam | for puppet | 16:42 |
| clarkb | tkajinam: https://zuul.opendev.org/t/openstack/labels lists the valid values | 16:42 |
| tkajinam | maybe we should not define nodesets but should follow what was done in OSA ? | 16:43 |
| clarkb | I think we can define the nodeset but it should be -8GB nodeset maps to -8GB label | 16:43 |
| clarkb | corvus may have thoughts too if you ask in #opendev | 16:43 |
| clarkb | (since he has been thinking a lot about the zuul launcher setup) | 16:43 |
| tkajinam | ok | 16:43 |
| fungi | well, also jobs don't need to rely on predefined nodesets at all, they can just include a nodes list in the job directly which is useful in a lot of cases. setting a nodeset in a job is just a shorthand to include that named nodelist | 16:44 |
| tkajinam | fungi, I'm wondering about that same though I feel like that standard nodeset definition is still useful to avoid messing up dependencies accross repos | 16:46 |
| fungi | yes, i think it's useful for common cases just like project-template definitions to make standardized job lists | 16:48 |
| clarkb | I asked corvus in #opendev | 16:49 |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: DNM: Testing py27 https://review.opendev.org/c/openstack/pbr/+/967588 | 17:34 |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: DNM: Testing py27 https://review.opendev.org/c/openstack/pbr/+/967588 | 19:26 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!