[07:11:04] <jayme>	 ah, okay. So switching the service back to type NodePort should already do the trick AIUI
[07:11:21] <jayme>	 (we don't use route-reflectors rn)
[07:31:20] <elukey>	 hello folks!
[07:31:34] <elukey>	 https://phabricator.wikimedia.org/T375645#10186599 contains results of the docker distribution's GC dry-run
[07:32:13] <elukey>	 TL;DR: ~33hrs for mark/sweep (then we'd need to add the time to actually delete blobs from Swift), ~75k layers/blobs to clean up
[07:48:10] <brouberol>	 elukey: do we have a sense as to how much space we'd free up?
[09:04:31] <elukey>	 brouberol: no idea, I am not even sure how big is the swift container for the registry right now (and/or if we have specific metrics)
[09:04:46] <elukey>	 my aim is mostly to reduce the time to fetch the catalog via API
[09:04:57] <elukey>	 freeing space would also be nice :)
[09:10:24] <brouberol>	 ack, I see
[09:10:26] <brouberol>	 thanks
[10:15:35] <brouberol>	 jayme: I was thinking. Now that we have a stable `checksum/secrets` checksum injected by default by our scaffolding tool in base.meta.pod_annotations, would it make sense to add a `checksum/configuration` annotation as well, that would perform the same kind of checksum, but on configmap.yaml ?
[10:18:10] <jayme>	 brouberol: Yeah, probably... I think it's a plausible default at least (given we already have that for secrets). Services that are capable of hot reloading config are potentially sparse and we can find a way for them to not include checksums when it comes to it
[10:24:59] <brouberol>	 ack. Done in https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/1076710
[14:27:36] <cdanis>	 jayme: akosiaris: https://gerrit.wikimedia.org/r/c/operations/puppet/+/1076768
[15:19:21] <jayme>	 cdanis: +1
[15:22:14] <cdanis>	 ty <3
[16:33:51] <jayme>	 cdanis: btw. this sounds very interesting for the future/maybe next k8s version https://docs.tigera.io/calico/latest/operations/ebpf/enabling-ebpf
[16:34:12] <cdanis>	 jayme: yes I agree for sure
[16:34:28] <jayme>	 wasn't sure you already ran into it
[16:34:38] <cdanis>	 just heard it mentioned
[16:35:11] <cdanis>	 we could also try moving to Cilium ;)
[16:36:18] <jayme>	 yes...I had that thought as well because of the calico enterprise mess
[16:37:01] <cdanis>	 I haven't played with Hubble but it seems quite interesting
[16:40:07] <jayme>	 yes...unfortunately moving away from calico is - some work :)
[16:41:32] <cdanis>	 yes
[17:39:59] <inflatador>	 I'm partial to Antrea, but that's only due to Stockholm Syndrome from years of supporting OVS on XenServer ;p
[17:43:21] <katia>	 yay to cilium :)