[13:54:19] brouberol: do you have a list of all the operators you're already running (and maybe where to find version compatibility matrix for those)? [14:18:10] klausman: elukey: we're getting very confused again by kserve/knative-serving version numbers and requirements while trying to build the k8s components version matrix https://etherpad.wikimedia.org/p/T341984 - could you please advise? [14:22:04] inflatador: for the case of the production-images repo, very likely not -- there's a lot of interdependencies [14:26:29] It would also largely break the update flow of docker-pkg [14:35:56] jayme: I'd defer to klausman since I am not sure what plans the ml team has nowadays to upgrade [14:36:15] they are currently doing an offsite so the reply may be delayed [14:39:30] re production images: the production images are Dockerfiles and not blubber files. But we added Dockerfile support to one of the GitLab Trusted Runners so that should be possible. We are already building one Dockerfile image on GitLab. But nevertheless some yaml code is needed to make that work on gitlab for production images, also considering naming of the new images [14:43:12] elukey: ack, thanks [15:06:17] jayme: back. We're running cloudnative-pg 1.24.1 (https://cloudnative-pg.io/documentation/1.24/supported_releases/), ceph-csi-cephfs and ceph-csi-rbd 3.7.2 (https://github.com/ceph/ceph-csi/?tab=readme-ov-file#known-to-work-co-platforms), spark-operator 1.3.8-3.3.2-2 (https://github.com/kubeflow/spark-operator/?tab=readme-ov-file#version-matrix) [15:06:17] and flink-operator 1.4.0 (https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-release-1.4/docs/custom-resource/reference/, I couldn't find anything better than this) [15:07:08] cloudnative-pg claims that our kubernetes version is unsupported but it works just fine. We explicitly mentioned "let's try it because it fits our needs, and we never know, we might be lucky", and we were [15:07:13] thanks...I think that is coherent with what we figured out [15:07:21] sorry, I was afk for a couple of hours [15:07:39] np - I could have said that we're done ... apart from ml stuff https://etherpad.wikimedia.org/p/T341984 [15:10:57] ncie [15:10:59] *nice [15:24:07] but a lot of adjacent updates to do :) [15:26:15] I mean, it's just a Kubernetes upgrade Micheal. How much could it be? 10$? [15:32:31] you never actually set foot in a IT department, did you? :p [15:37:59] I'm a baker by trade and someone gave me a computer with a root access once, and here we are [15:49:29] sorry, that's all I recall from the dialog - I can't proceed :D [16:16:34] brouberol: favorite thing to bake? [16:17:48] I'm a simple person. I enjoy a 2kg sourdough boule (and to be clear, I'm *not* a baker by trade :D, I should have added the necessary /s) [16:19:01] I have a friend who is partway through the tech job --> baker pipeline [16:30:23] the beauty of this cycle is that many bakers (or equivalent "manual" workers) become tech workers to get a better situation [16:33:46] * kamila_ is looking forward to one day herding sourdough starter or goats instead of k8s pods [16:36:14] like my dad always said, one day closer to retirement ;P [17:11:15] We're adding a net-new service to the dse-k8s cluster...the gitlab trusted runners need to be able to POST to this service. Does anyone know if we need to add a service under ingress a la https://w.wiki/ByNk for this? Based on brouberol comment at https://w.wiki/ByNq , it sounds like it might not be necessary? [17:13:00] inflatador: adding a service under ingress is different from adding a new LVS service [17:13:15] you do not need to add a new LVS service if you are adding it under ingress, you re-use an existing LVS service, and you CNAME to its dns name [17:13:34] the defaults for the certificates and hostnames are probably entirely correct for you [17:14:05] cdanis Thanks, it sounds like we don't need this patch then [17:15:00] uh even for services under ingress it's usually still expected to add it to the service catalog, depending [17:15:11] that also gives you monitoring and a few other things [17:15:22] hmmm, OK. I did already CNAME it, FWiW [17:16:25] what you *aren't* doing is adding a huge entry like this one https://wikitech.wikimedia.org/wiki/LVS#Create_an_entry_in_the_service::catalog [17:18:24] ACK, so that means we do need that patch, but nothing LVS-related? I'm basically following the steps from https://wikitech.wikimedia.org/wiki/Kubernetes/Add_a_new_service [17:19:22] yes [17:21:53] excellent! Once again I am in your debt [18:31:45] Seems like I’ve been guilty of not doing this for about 12 services :/ [18:58:24] brouberol: IIRC gets you two things basically, ProbeDown alerts for the services, and also, the ability to add them to mediawiki's / other envoy service proxies