[06:33:41] <elukey>	 good morning folks!
[08:25:12] <klausman>	 Morning! For some reason, I have no normal Internet (5G only), currently investigating hat
[08:25:17] <klausman>	 what is going on*
[08:26:15] <elukey>	 ack!
[08:51:41] <elukey>	 I was reviewing https://github.com/istio/istio/tree/master/cni and it may be not so horrible to set up
[08:52:07] <elukey>	 for Calico we create a deb package for cni plugins, and we install on k8s workers
[08:52:33] <elukey>	 in theory, IIUC, for istio we should do the same and then the istio yaml config can be pointed to the location on disk of the plugins
[08:52:54] <elukey>	 (otherwise istio provides a container that installs binaries on the node, but it is probably not a good thing :D)
[08:53:10] <elukey>	 in this way we'd get the istio proxy sidecar
[08:53:29] <elukey>	 and we could unblock a lot more features, like the circuit breaking etc..
[08:53:39] <elukey>	 and also automatic traffic flow handling
[08:53:47] <elukey>	 maybe mTLS could be added on a second step
[08:54:11] <elukey>	 but the current way of using istio is a little painful any time that we want to do anything more elaborated
[08:54:18] <klausman>	 Sounds desirable. Would this extra resources?
[08:54:26] <klausman>	 use*
[08:54:46] <elukey>	 so we'd need, IIUC
[08:55:08] <elukey>	 1) pods in the kube-system namespace (like calico's)
[08:55:14] <elukey>	 2) a sidecar for each pod
[08:55:30] <elukey>	 but it doesn't seem anything really problematic
[08:55:43] <elukey>	 (the sidecar in 2) is an envoy proxy)
[08:56:40] <klausman>	 It does sound more flexible than the current setup. Or more easily managed, at least
[08:57:21] <elukey>	 it may add some extra headaches, with the mesh setup we'll have istio messing up with iptables to route requests from kserve-containter to the (local) envoy proxy
[08:57:29] <elukey>	 but it will be a mesh 
[08:57:38] <elukey>	 at the moment, IIUC, all pods are outside the mesh
[08:58:12] <elukey>	 and all the docs that I am reading for traffic handling assume that istio users use the mesh
[08:59:53] <elukey>	 I'd also really like in the future to have all traffic pod -> pod encrypted
[09:05:21] <klausman>	 Yes, agreed.
[09:06:15] <klausman>	 btw, I gave a quick upd of our thoughts on Ipspace yesterday @ the mtg
[09:08:27] <elukey>	 ah nice!
[09:11:43] <klausman>	 I now have nominal Internet. With ~40+% packet loss -.-
[09:17:32] <elukey>	 kevinbazira: o/ when you have a moment can you review https://github.com/wikimedia/ores/pull/357 ?
[09:22:39] <kevinbazira>	 elukey: LGTM! thanks for working on it.
[09:24:53] <elukey>	 thanks, merged :)
[10:26:06] <elukey>	 folks Alex is going to merge https://gerrit.wikimedia.org/r/c/operations/puppet/+/767732
[10:26:20] <elukey>	 this will move the celery queue + the score cache of the eqiad nodes to another redis node
[10:26:30] <elukey>	 that in theory have been syncing from the current one since ages ago
[10:26:42] <elukey>	 so it should be a an easy roll restart and that's it
[11:27:51] * elukey lunch!
[15:56:48] <elukey>	 istio is vry complicated sigh
[15:56:55] <elukey>	 *very
[16:38:49] <chrisalbon>	 Morning all!
[16:39:30] <elukey>	 o/
[16:45:09] * elukey small break
[17:43:57] <elukey>	 folks with the new ores logs I see a ton of https://phabricator.wikimedia.org/T302851 constantly logged
[17:44:23] <elukey>	 it may be a trivial thing to fix, but I have no idea about itemquality
[17:44:30] <elukey>	 (never heard the model before)
[17:56:30] <elukey>	 going afk folks! have a good day
[22:57:12] <andre>	 Is ORES still the recommendation to base a "revert tool" on? Asking on behalf of someone working on a revert tool based on ORES, and as https://www.mediawiki.org/wiki/ORES sounds like it's active, but I also vaguely remember "maintenance mode" being mentioned somewhere (maybe I misunderstood) which would make me wonder what else is being recommended. TIA
[23:01:38] <andre>	 ml-team ^