| *** elodilles_pto is now known as elodilles | 07:00 | |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Move SELinux context to variable https://review.opendev.org/c/openstack/ci-log-processing/+/930680 | 07:36 |
|---|---|---|
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Move SELinux context to variable https://review.opendev.org/c/openstack/ci-log-processing/+/930680 | 09:26 |
| opendevreview | Merged openstack/ci-log-processing master: Move SELinux context to variable https://review.opendev.org/c/openstack/ci-log-processing/+/930680 | 10:17 |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Do not create download directory with recurse https://review.opendev.org/c/openstack/ci-log-processing/+/930693 | 11:19 |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Do not create download directory with recurse https://review.opendev.org/c/openstack/ci-log-processing/+/930693 | 11:33 |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Do not create download dir with recurse; check if dir already exists https://review.opendev.org/c/openstack/ci-log-processing/+/930693 | 11:34 |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Do not create download dir with recurse; check if dir already exists https://review.opendev.org/c/openstack/ci-log-processing/+/930693 | 12:05 |
| opendevreview | Merged openstack/ci-log-processing master: Do not create download dir with recurse; check if dir already exists https://review.opendev.org/c/openstack/ci-log-processing/+/930693 | 12:32 |
| opendevreview | Jeremy Stanley proposed openstack/project-config master: Temporarily remove release docs semaphores https://review.opendev.org/c/openstack/project-config/+/930709 | 14:27 |
| opendevreview | Jeremy Stanley proposed openstack/project-config master: Revert "Temporarily remove release docs semaphores" https://review.opendev.org/c/openstack/project-config/+/930710 | 14:27 |
| frickler | gmann: https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/926153 should be good to go now? | 15:37 |
| clarkb | following up on https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/930590 netifaces and yappi were identified as two problematic packages for arm since they don't have wheels for arm. | 16:01 |
| clarkb | yappi I think is solvable workin with upstream to update their github actions to use the new ubuntu arm github runners | 16:01 |
| clarkb | netifaces however is no longer maintained and hasn't been for years. Do we know what if any plans there are for dealing with unmaintained netifaces in openstack? | 16:01 |
| fungi | i thought there had been work done to remove it | 16:06 |
| fungi | my isp is trying to route all my packets through the eye of a hurricane right now though (quite literally), so my network connectivity for investigating that isn't the greatest at this point in time | 16:07 |
| fungi | mosh does surprisingly well with 50% packet loss, but the rest of the protocols i rely on are less useful right now | 16:08 |
| fungi | hound (codesearch) is surprisingly terrible in console-based browsers | 16:11 |
| fungi | gitea's search feature does work under elinks, and i'm seeing quite a few netifaces imports | 16:15 |
| fungi | though gitea's "fuzzy" searching has gotten more fuzzy than just case insensitivity now, it matched to a comment about "iscsi netspaces" | 16:18 |
| fungi | tkajinam brought the topic to the openstack-discuss ml in april of last year | 16:23 |
| fungi | unfortunately, hyperkitty's thread view also doesn't work well in console-based browsers | 16:24 |
| tkajinam | looks like swift added their own implementation to replace netifaces... probably we can borrow that and add something to oslo.utils | 16:29 |
| tkajinam | https://review.opendev.org/c/openstack/swift/+/873222 | 16:29 |
| fungi | though it did allow me to find https://bugs.launchpad.net/neutron/+bug/2015844 with a reference to https://review.opendev.org/c/openstack/neutron/+/880980 | 16:29 |
| tkajinam | yeah neutron used netifaces only in windows os which was deprecated and removed | 16:30 |
| tkajinam | but there are still a few projects, including netifaces, for other purposes | 16:30 |
| fungi | thanks tkajinam! so yes, it looks like there's some momentum to stop depending on netifaces, but it's moving slowly | 16:30 |
| tkajinam | sorry I meant "including oslo.utils" | 16:31 |
| tkajinam | yeah | 16:31 |
| tkajinam | some projects reacted to that mail but the other did not | 16:31 |
| clarkb | tkajinam: ok thats a neat idea. Then the next thing is making that work with arm well but one step at a time | 16:32 |
| fungi | oslo.utils.netutils seems to use it for netifaces.gateways() | 16:32 |
| tkajinam | yup | 16:33 |
| tkajinam | I'm not following the whole thread but is it blocking something ? (probably py 3.13 support ?) | 16:33 |
| clarkb | in the meantime that takes us back to the question of whether or not we need the arm64 wheel mirrors. I wonder if we address the others like yappi if we can accept some costs for packages like netifaces until it is removed | 16:33 |
| fungi | tkajinam: lack of aarch64 wheels | 16:34 |
| tkajinam | ok | 16:34 |
| clarkb | tkajinam: mnaser has requested we build an ubuntu noble python3.12 wheel cache. When I spun up the ubuntu noble test node stuff I intentionally avoided adding a wheel cache because many things do build arm wheels now | 16:34 |
| clarkb | and more generally have wheels published as the python package ecosystem has imrpvoed over time so I was hoping we wouldn't need that extra infrastructure | 16:34 |
| clarkb | my motivation there is that we have to clean it up later | 16:34 |
| clarkb | https://mirror.dfw.rax.opendev.org/wheel/ which isn't happening as you can see a number of old distros we don't support still hanging around | 16:35 |
| clarkb | but also that wheel cache/mirror has masked real packaging problems in the past like when upsteram pulls packages but we still have wheels for them | 16:35 |
| clarkb | then things only work in CI and not on your laptop which I really would like to avoid | 16:35 |
| clarkb | (because it is another thing that ultimately opendev is asked to debug when it occurs) | 16:35 |
| tkajinam | yeah that sounds fair | 16:36 |
| clarkb | if we think we can address netifaces quickly in the new cycle then maybe we can still avoid building the wheel cache? since python3.12 isn't really a major issue for the ucrrent release? | 16:36 |
| clarkb | mnaser: ^ thoughts on that? I don't know how big of an impact it currenlty has for you. Is it just slowness or is it too slow to the point of not being workable | 16:37 |
| clarkb | I think we are close to being able to do this without the wheel cache and the start of a cycle seems like a good time to push against the issues and address them. But at the same time I don't want to act like a barrier as we do have a known fix so trying to balance being able to incentivize improvements against just making it work | 16:38 |
| tkajinam | We anyway have to get rid of netifaces at some point because it's abandoned... I'll take a look next week to see how huge effort it may be | 16:38 |
| clarkb | tkajinam: thanks! | 16:38 |
| tkajinam | my small concern here is that it is used by multiple charm-* repositories and I'm unsure if I can cover these all | 16:38 |
| mnaser | clarkb: the thing is at the moment at 1 hour timeout I can’t build a Nova/neutron image :( | 16:39 |
| clarkb | mnaser: maybe lets do a quick test with a 3 hour timeout (the max) and see if we can do it in 1.25 hours vs in 3 or not at all? | 16:39 |
| mnaser | Alright I can try that. I was thinking of investing time to figure out how to make Zuul use buildx across two nodes | 16:40 |
| clarkb | part of my concern here is that dep has been unmaintained for 3 years and we're talking about removing it now because the wheel cache doesn't exist. If we just papered over that by buildign the wheels it could be another three years before openstack moved on addressing the dep issue | 16:40 |
| clarkb | so I think spending at least a little time identifying these problems and determining if there are reasonable solutions is good for overall health | 16:41 |
| mnaser | Boot an amd64 and arm64 together for the same job, add arm64 as a remote buildx builder and then go through our normal flow :P | 16:41 |
| gmann | frickler: yes, this is good to go, I removd -W https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/926153 | 16:41 |
| mnaser | clarkb: I mean, for me I’m a little too late to this, I could look into yanking it but I doubt I could get that backported at all :) | 16:41 |
| clarkb | that would be cool. I think one of the issues is that currently zuul will try to run all of the support stuff in a single provider which may require zuul itself to chagne not just the jobs | 16:41 |
| fungi | mainly because our providers are all single-arch, and also i think there are some inbuilt assumptions in nodepool that would make supporting a multu-architecture provider challenging too | 16:45 |
| clarkb | I think multiarchitecture provider would work if we can select arch by flavor | 16:46 |
| clarkb | if there is a different mechanism to detect arch we would need some chagnes to nodepool to select and boot them properly | 16:46 |
| fungi | just trying to think through how we'd do the image uploads, but i guess those are separate labels anyway so would "just work"? | 16:48 |
| clarkb | fungi: yes and in fact we have to configure each of the builders with all of the images too iirc. We just don't upload arm to x86 and vice versa | 16:48 |
| clarkb | otherwise the builders will try to clean up images they don't know about | 16:48 |
| fungi | good point | 16:48 |
| clarkb | we don't upload or build them on the wrong platform | 16:48 |
| fungi | so really, if we did have providers with both x86_64 and aarch64 flavors, we could probably make it work with no need to make changes in software | 16:49 |
| clarkb | yup | 16:49 |
| fungi | and then the blocker is really just the lack of any such provider | 16:50 |
| opendevreview | Merged openstack/openstack-zuul-jobs master: Prepare the job template for 2025.1 testing runtime https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/926153 | 17:04 |
| opendevreview | Jeremy Stanley proposed openstack/ptgbot master: Un-pin irc library https://review.opendev.org/c/openstack/ptgbot/+/930781 | 21:06 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!