[06:55:55] I'm going to attempt to remove the per-host restbase checks as part of T314118, the service itself is already checked at its service url by swagger-exporter (fixed in T346893) [07:15:11] https://gerrit.wikimedia.org/r/c/operations/puppet/+/961002 and https://gerrit.wikimedia.org/r/c/operations/puppet/+/961003 [07:32:15] good morning! FYI all HTTPBB units on the cumin hosts are failing because the https://test.wikidata.org/wiki/Q77119 entity doesn't exists (anymore?) and returns 404 instead of 200 [08:15:05] volans: Yeah, a bureaucrat decided to remove the page for vandalism [08:15:52] I'm unsure of how to proceed though, should we contact said bureaucrat to reinstate it, do we just choose another page, remove that check? [08:20:25] I'll leave that up to you :) I would expect that test.wikidata could have "test" data... [08:21:07] Well so would I [08:35:18] <_joe_> claime: change the test :) [08:35:28] Yeah that's what I'm doing [08:35:43] Create a new item with description "SRE testing page DO NOT REMOVE" [09:08:31] 10serviceops, 10MW-on-K8s, 10MediaWiki-Platform-Team (Radar): mcrouter daemonset on mw-on-k8s - https://phabricator.wikimedia.org/T346690 (10jijiki) >>! In T346690#9187515, @Joe wrote: > I pressed submit before finishing my comment: > > that amounts to setting `clear_env = no` in php-fpm I think. Do you re... [09:15:03] 10serviceops, 10Prod-Kubernetes, 10Kubernetes: Reserve resources for system daemons on kubernetes nodes - https://phabricator.wikimedia.org/T277876 (10JMeybohm) 05Stalled→03Resolved a:03JMeybohm This is active since yesterday [09:15:06] 10serviceops, 10Prod-Kubernetes, 10Shared-Data-Infrastructure, 10Kubernetes: Update Kubernetes clusters to >1.25 - https://phabricator.wikimedia.org/T341984 (10JMeybohm) [09:15:14] 10serviceops, 10Foundational Technology Requests, 10Prod-Kubernetes, 10Shared-Data-Infrastructure, and 2 others: Update Kubernetes clusters to v1.23 - https://phabricator.wikimedia.org/T307943 (10JMeybohm) [09:15:22] 10serviceops, 10MW-on-K8s, 10SRE, 10Traffic, 10Release-Engineering-Team (Seen): Serve production traffic via Kubernetes - https://phabricator.wikimedia.org/T290536 (10JMeybohm) [09:38:03] volans: Fixed, HTTPBB tests will fix themselves as the timers run [09:39:07] claime: <3 thanks! [09:44:45] 10serviceops, 10Cloud-VPS, 10Infrastructure-Foundations, 10Packaging, and 2 others: Package mcrouter for Debian Bookworm - https://phabricator.wikimedia.org/T346762 (10fnegri) 05In progress→03Resolved [09:50:34] 10serviceops, 10Prod-Kubernetes, 10Kubernetes, 10Patch-For-Review: Use cert-manager for service-proxy certificate creation - https://phabricator.wikimedia.org/T300033 (10jijiki) [10:03:03] who should I add as a reviewer for maps alerts? https://gerrit.wikimedia.org/r/c/operations/puppet/+/961062 [10:35:18] 10serviceops, 10MW-on-K8s, 10SRE, 10Traffic, and 2 others: Migrate internal traffic to k8s - https://phabricator.wikimedia.org/T333120 (10Joe) [10:36:37] 10serviceops, 10MW-on-K8s, 10SRE, 10Traffic, and 2 others: Migrate all eventgate installations to mw-api-int - https://phabricator.wikimedia.org/T346448 (10Joe) 05Open→03Resolved a:03Joe [10:36:48] 10serviceops, 10MW-on-K8s, 10SRE, 10Traffic, and 2 others: Migrate internal traffic to k8s - https://phabricator.wikimedia.org/T333120 (10Joe) [11:10:10] eoghan: you can merge the zuul-gearman.py -> gearman-tools change at https://gerrit.wikimedia.org/r/c/operations/puppet/+/930673 . It is not used by the CI stack (it is an admin command) [11:10:10] :) [11:18:40] 10serviceops, 10Prod-Kubernetes, 10Kubernetes, 10Patch-For-Review: Use cert-manager for service-proxy certificate creation - https://phabricator.wikimedia.org/T300033 (10jijiki) [11:59:48] hashar: Certainly. [12:45:26] 10serviceops, 10Abstract Wikipedia team, 10MW-on-K8s, 10SRE, and 4 others: Migrate functions-orchestrator service to mw-api-int - https://phabricator.wikimedia.org/T347397 (10Jdforrester-WMF) [13:14:24] 10serviceops, 10MW-on-K8s, 10SRE, 10Traffic, and 2 others: Migrate wikifeeds to mw-api-int - https://phabricator.wikimedia.org/T346447 (10Joe) 05Open→03Resolved a:03Joe [13:14:42] 10serviceops, 10MW-on-K8s, 10SRE, 10Traffic, and 2 others: Migrate internal traffic to k8s - https://phabricator.wikimedia.org/T333120 (10Joe) [13:15:08] 10serviceops, 10MW-on-K8s, 10SRE, 10Traffic, and 2 others: Migrate internal traffic to k8s - https://phabricator.wikimedia.org/T333120 (10Joe) [13:32:32] hello folks [13:32:40] I have a istio/modules question [13:32:58] I'd need to add https://istio.io/latest/docs/reference/config/networking/virtual-service/#CorsPolicy to the virtual service that we generate via ingress [13:33:08] (already tested for ores-legacy, it works etc..) [13:33:39] my understanding from the ingress module is that we only set route:, and not other stuff [13:34:17] if so, should I add a specific option for the cors Policy? Or do we prefer something more generic like extra_http_config ? [13:43:31] jayme: --^ :) [13:44:47] that question requires a bit of a context switch I cant do rn, sorry. You mind proposing something (CR or phab) so I can read when there is capacity= [13:46:58] so diplomatic [13:47:05] "Luca go awayyyyyyy!" [13:47:15] sure I'll do it :) [13:48:40] <_joe_> elukey: I can give you my opinion: I hate when code requires the user to inject the configuration verbatim [13:48:59] <_joe_> so a specific option for the cors policy is the right solution imho [13:49:42] _joe_ ack, but would it be ok to allow folks to add the config snippet under it? It has several options, so listing all of them may be tedious [13:50:12] I mean everything under corsPolicy [13:50:44] <_joe_> elukey: as I said, I'd prefer us to have a switch for each feature, and for it to be opinionated. We can extend the options we want to offer later [13:51:05] <_joe_> so ideally [13:51:29] <_joe_> I guess you want to set allowOrigins [13:51:50] yeah [13:52:10] but we may want other things, if we need every time to release a module version it may be a long process [13:52:52] <_joe_> elukey: well then add options for each thing [13:52:54] <_joe_> something like [13:52:58] <_joe_> cors: [13:53:04] <_joe_> allowed_origins: [13:53:11] <_joe_> allowed_methods: [13:53:16] <_joe_> even without allowed [13:53:47] <_joe_> if you want to add the complete feature, don't be shy to make it complete :) [13:53:50] I am not getting the point of reinventing the syntax, do we want to add a specific layer to avoid folks to write istio configs directly? [13:53:58] <_joe_> yes [13:54:07] <_joe_> or having to read istio/envoy's docs [13:54:22] <_joe_> even better, we should probably have preset values for Cors :) [13:54:30] <_joe_> but I am not asking you to do that [13:55:07] In this case I think that we are complicating things [13:55:22] for example, allowOrigins wants a list of stuff like [13:55:26] <_joe_> elukey: I am definitely against having pieces of envoy config in values.yaml [13:55:33] - exact: domain1 [13:55:39] - regex: some regex [13:55:39] etc.. [13:55:59] <_joe_> yeah and I was asking... how many different CORS policies do we expect to need? [13:56:00] _joe_ it is not envoy config, but istio, and we are configuring a module called the same [13:56:39] <_joe_> elukey: my argument doesn't change [13:57:03] _joe_ sure but I have mine too, and I am explaining my points [13:57:05] <_joe_> but do as you like, you asked for an opinion [13:57:43] I hoped for a brainbounce, that's it :) [13:57:43] <_joe_> please go on then :) [13:58:05] <_joe_> elukey: let me ask a few additional quesitons though, to better understand [13:58:20] <_joe_> do you expect cors policies to change service by service or to mostly be very similar? [13:59:26] hopefully we have one, but I have no idea if this holds true for all services [14:00:22] anyway, I can start with a basic standard config [14:00:54] IIUC we set everywhere allow origins *, so maybe only that one suffices [14:05:14] <_joe_> elukey: yeah my argument is, it's easier for people to just flip on/off a CORS policy or one of a few [14:05:28] <_joe_> than to understand how to configure one explicitly [14:05:39] okok I'll go for that [14:06:04] <_joe_> and to be clear: nothing prevents us from adding an alternative free-form [14:06:09] sometimes I just feel that a shortcut to add complex snippets would be very handy, besides standard policies [14:06:20] <_joe_> but this will save you a lot of typing if you have to repeat the same config in different places [14:06:20] okok we are on the same page [14:06:29] <_joe_> elukey: uhm [14:06:49] <_joe_> what do you mean by "shortcut"? [14:07:14] in the sense of not having to map a complex config to another layer (in this case, our modules) [14:07:40] so free-form for special cases would be really nice [14:08:09] <_joe_> elukey: another option is to allow defining what template to load as cors config