[08:20:50] <wikibugs>	 10serviceops, 10MediaWiki-General, 10MediaWiki-Stakeholders-Group, 10Release-Engineering-Team, and 3 others: Drop official PHP 7.2 support in MediaWiki 1.35 - https://phabricator.wikimedia.org/T257879 (10Jdforrester-WMF)
[08:55:23] <elukey>	 hello everybody, is the citoid /api 404 health check already being handled or should we look into it?
[08:55:50] <elukey>	 I guess that one of the test pages was removed
[09:09:17] <_joe_>	 elukey: I don't think that's the case, and it's relatively low-prio, but someone will look today
[09:09:25] <_joe_>	 when it's not just me and jayme I guess
[09:12:30] <elukey>	 _joe_ but what is the impact of that check?
[09:12:46] <_joe_>	 it says there is one behaviour that's unexpected
[09:12:56] <_joe_>	 not sure I understand what you mean with "impact"
[09:13:44] <elukey>	 well what the icinga error means, if it can be acked, if it needs a task, etc..
[09:14:20] <_joe_>	 It probably needs a task, but it needs a bit of investigation
[09:14:34] <_joe_>	 else it's meaningless to just open a task saying "this alert is firing"
[09:15:14] <elukey>	 well it is not if we ack the alert with the task, and follow up later
[09:15:54] <elukey>	 I am opening one, then I'll add the serviceops tag
[09:18:25] <wikibugs>	 10serviceops, 10Operations: citoid /api LVS check reports HTTP 404 instead of HTTP 200 - https://phabricator.wikimedia.org/T259469 (10elukey)
[09:25:09] <_joe_>	 I disagree with that approach FWIW
[09:25:22] <_joe_>	 acknowledgements should only happen if someone is working on the alert
[09:33:00] <wikibugs>	 10serviceops, 10CX-cxserver, 10Language-Team (Language-2020-July-September), 10Release-Engineering-Team (Pipeline): Migrate apertium to the deployment pipeline - https://phabricator.wikimedia.org/T255672 (10Pginer-WMF)
[09:41:59] <elukey>	 _joe_ you told me that the alert is low priority, and to avoid that multiple SREs will check the same thing and/or ask in this channel the same question it seems good to open a task and collect info in there :)
[10:19:56] <_joe_>	 jayme: should I stop creating the charts .tgz files, correct?
[10:21:59] <wikibugs>	 10serviceops, 10Operations, 10Patch-For-Review: Update deprecated extension names in envoy config - https://phabricator.wikimedia.org/T258140 (10Joe) 05Open→03Resolved I still didn't deploy the code to k8s, but the idea is it will be picked up next time the chart gets updated.
[11:09:26] <jayme>	 _joe_: you can stop, yes. But I have not announced that by now so maybe someone will be missing it from releases.w.o then
[11:09:45] <jayme>	 (was out for lunch, sorry)
[12:56:54] <cdanis>	 _joe_: https://github.com/php/php-src/pull/5918
[12:57:02] <cdanis>	 my nerdsnipe has been successful
[12:57:40] <_joe_>	 oh nice indeed
[13:40:22] <_joe_>	 jayme: so apparently helmfile can't interpolate {{ .Release.Name }} in the values list
[13:40:35] <_joe_>	 this is unfortunate, but should be manageable
[13:40:52] <_joe_>	 I mean in the template
[13:42:03] <_joe_>	 sigh, another double-template
[13:48:49] <jayme>	 yeah, I think it works in "hyperquotes" :D
[13:54:03] <_joe_>	 uhm still unsure about it, I think I'm going to have to do more tests
[13:54:24] <_joe_>	 did you already upgrade helm-diff?
[13:59:02] <_joe_>	 also apparently the --kubeconfig= trick doesn't work
[14:07:21] <jayme>	 I think I tried {{`{{ .Release.Name }}`}} for some values.yaml
[14:07:48] <jayme>	 And no. I did not try with helm-diff I guess
[14:08:12] <_joe_>	 I think I have another problem tbh
[14:08:20] <jayme>	 hmm...maybe I did but I recently deleted my ~/.helm to do some testing. Let me check snapshots
[14:09:42] <jayme>	 I had helm-diff v2.11.0+3
[15:09:16] <wikibugs>	 10serviceops, 10Citoid, 10Operations: citoid /api LVS check reports HTTP 404 instead of HTTP 200 - https://phabricator.wikimedia.org/T259469 (10akosiaris) p:05Triage→03High @Mvolz any ideas?
[15:55:25] <mutante>	 _joe_: ack. ok, i have https://gerrit.wikimedia.org/r/c/operations/puppet/+/579026  but mediawiki-config as well then (maybe not sure about the order)
[16:01:47] <jayme>	 _joe_: so you tried what currently is in CR 615498 on deploy hosts and it did not work, right?
[16:02:10] <_joe_>	 jayme: yes, hold on one sec
[16:02:35] <jayme>	 _joe_: just wanted to clarify, not starting anything right away :)
[16:09:35] <wikibugs>	 10serviceops, 10Citoid, 10Operations: citoid /api LVS check reports HTTP 404 instead of HTTP 200 - https://phabricator.wikimedia.org/T259469 (10Mvolz) >>! In T259469#6356479, @akosiaris wrote: > @Mvolz any ideas?  A problem of our own making, I think! The test looks at   https://wikimediafoundation.org/404 a...
[16:13:39] <wikibugs>	 10serviceops, 10Citoid, 10Operations: citoid /api LVS check reports HTTP 200 instead of HTTP 404 - https://phabricator.wikimedia.org/T259469 (10Mvolz)
[16:17:17] <wikibugs>	 10serviceops, 10Citoid, 10Operations, 10Patch-For-Review: citoid /api LVS check reports HTTP 200 instead of HTTP 404 - https://phabricator.wikimedia.org/T259469 (10Dzahn) >>! In T259469#6356754, @Mvolz wrote: > https://wikimediafoundation.org/404 and expects it to 404  I would recommend to use wikimedia.or...