[09:13:55] greetings [09:20:40] so, I managed to make bpf work on lima-kilo locally but I had to create a lima-kilo without rosetta, meaning that is *suuuuuuper* slow [09:20:49] now trying to get what I want out of it... :D [09:34:18] morning! [09:44:37] volans: I'm curious about the lima-kilo rabbit hole, can you give me a 2-line summary? :) [09:45:00] missing vdso [09:45:04] https://etherpad.wikimedia.org/p/volans-tmp2 [09:45:36] that was 2 words instead of 2 lines, not bad :) [09:45:53] and beyla (that I'm testing) was failing to load bpf stuff [09:46:50] the other alternative could be to do an arm64 vm, but then you need all the images that we have in the catalog also built for arm... :D [09:47:34] yeah I don't think that would be tooooo hard, I will probably try sooner or later :P [09:48:40] for the lima-kilo part no, it's not too hard, you change all the requirements download links to arm, then you hit an issue with get_harbor.sh but then you will need our images [09:56:00] dhinus: let me rephrase, what I meant is I created a VM with UTM and a debian netinst, then commented the lima stuff in start-devenv.sh and then played with the ansible stuff [10:00:03] volans: what differences you found between the lima vm and the UTM vm? [10:40:37] I'm debugging why cloudcephosd1052 still has its second NIC active, I'm tempted to ifdown it and ifup the vlan one, thoughts? [10:45:21] ok actually I got it why puppet isn't puppeting, interface names don't match between puppet and the system [10:51:54] or rather, used to match though on the system the ifupdown configuration isn't fully cleaned up [11:17:39] I'm off this afternoon and tomorrow FWIW, unless someone feels inspired the fix will have to wait post-lisbon [11:18:33] does anyone have a clue why toolsbeta has 3 nfs servers? are all of them still needed? [11:22:28] not sure about 3, though one of those I think is me forgetting to clean up after the trixie migration [11:53:10] ok I'll merge https://gerrit.wikimedia.org/r/c/operations/puppet/+/1215114 if sth doesn't work revert is easy [11:55:00] godog: re your last comment, profile::wmcs::striker::monitoring sets `ip4 => ipresolve('toolsadmin.wikimedia.org', 4),` for the probe, and toolsadmin.w.o resolves to dyna.. doesn't that mean the probe is going through the CDN? [11:58:39] taavi: a bit confusing but no, the probe hits the host which includes the class, and sends the address as part of the probe [11:59:15] uhhh [11:59:19] taavi: check out prometheus1005:/srv/prometheus/ops/targets/probes-custom_puppet-http.yaml for the http_toolsadmin_wikimedia_org_ip4 module [11:59:58] so how does that probe succeed when it sets port to 443? nothing listens on that port on the cloudweb hosts, the striker container runs on 8080 [12:02:41] not sure atm what's listening on 208.80.154.224:443 for example, though the probe seems to work [12:02:50] gotta go to lunch, will read later [12:07:10] .224 is text-lb [13:40:28] taavi: yes my bad, you are right and the probe does indeed hit the cdn [13:41:09] I'm off for the afternoon and tomorrow, talk to you / see you next week [14:43:00] reminder to fill out the etherpad before the meeting [15:32:32] taavi/dhinus do you have any concerns about me upgrading toolforge etcd nodes to Bookworm today, or does that fall under the heading of "don't mess with it before the offsite?" (Right now the cluster is mixed 2x bullseye 1x bookworm) [15:32:49] (which, btw, mixing with Trixie etcd also seems to work but I'm definitely saving that for later) [15:34:45] I would wait until after the offsite :) [15:35:16] ^ was my initial reaction, but I'm not sure if the mixed state is any better [15:36:16] yeah :/ maybe rolling back to bullseye everywhere is better [16:50:24] * dhinus off [17:24:37] do you think I could push a linux/arm image for alloy to the toolforge registry? would that cause any issue?