[07:34:15] <gyan>	 I have a tool hosted on toolforge. The PHP version in CLI is 7.2. I am using 7.4 WEB version. Unable to update my package for 7.4. 
[07:34:15] <gyan>	 How to change the PHP version in CLI from 7.2 to 7.4?
[07:35:42] <RhinosF1>	 Does webservice shell work?
[07:36:35] <gyan>	 Let me check that
[07:36:48] <RhinosF1>	 webservice --backend=kubernetes php7.4 shell is the full command
[07:36:53] <RhinosF1>	 https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web/PHP
[07:39:29] <gyan>	 I have done that and the web version is already 7.4. The command line tool (terminal) version is 7.2 still.  When I do composer update I get error regarding PHP version 7.2 not supporting few package versions
[07:41:00] <RhinosF1>	 The shell command should allow you to run it though
[07:41:10] <RhinosF1>	 Type the shell command first
[07:41:20] <RhinosF1>	 Then do composer update
[07:42:40] <gyan>	 "1:11 PM <RhinosF1> Type the shell command first
[07:42:40] <gyan>	 " Please suggest shell command
[07:42:56] <RhinosF1>	 07:36:48 <RhinosF1> webservice --backend=kubernetes php7.4 shell is the full command
[07:43:28] <gyan>	 Ahh done that. Already. 
[07:43:49] <RhinosF1>	 And you still in the shell it gives you get errors about php7.2?
[07:44:01] <RhinosF1>	 Can you try php --version
[07:44:01] <gyan>	 yes
[07:44:09] <gyan>	 yes it gives 7.2
[07:44:23] <RhinosF1>	 That really shouldn't happen as you just specified 7.4
[07:44:32] <gyan>	 On tool web version with phpinfo it's 7.4
[07:44:50] <RhinosF1>	 Yes because you started a webservice with 7.4 I assume
[07:45:01] <RhinosF1>	 My confusion is why you can't get into a shell with it
[07:45:01] <gyan>	 yes
[07:45:08] <RhinosF1>	 majavah: are you around yet?
[07:45:21] <gyan>	 I get 7.4 on webpage
[07:45:50] <gyan>	 on cli it's still 7.2
[07:46:01] <RhinosF1>	 I understand that
[07:46:06] <majavah>	 gyan: works for me, https://phabricator.wikimedia.org/P17724
[07:48:04] <gyan>	 Wonderful. It works. That information should be added https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web/PHP
[07:48:48] <RhinosF1>	 It is
[07:49:10] <RhinosF1>	 It's the 2nd line
[07:49:19] <majavah>	 meh, not very clearly
[07:49:24] <majavah>	 I'll make it more clear
[07:49:54] <gyan>	 Ahh missed it. 
[07:50:10] <gyan>	 Thank you both.
[07:50:12] <RhinosF1>	 Can I ask what was wrong the first few times?
[07:51:12] <gyan>	 I have never run the "shell" options. Only start and stop from the last three years :(
[07:53:36] <gyan>	 my bad
[08:35:39] <majavah>	 !log paws disabling pod preset controller in preparation for T291913
[08:35:42] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Paws/SAL
[08:35:42] <stashbot>	 T291913: Upgrade PAWS kubernetes to 1.20 - https://phabricator.wikimedia.org/T291913
[10:47:09] <arturo>	 !log bastion add user `srv-networktests` as project user (T294955)
[10:47:12] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Bastion/SAL
[10:47:12] <stashbot>	 T294955: cloud network: improve automated testing & monitoring - https://phabricator.wikimedia.org/T294955
[10:50:28] <arturo>	 !log tools add user `srv-networktests` as project user (T294955)
[10:50:31] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL
[10:50:53] <arturo>	 !log cloudinfra add user `srv-networktests` as project user (T294955)
[10:50:55] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Cloudinfra/SAL
[13:21:13] <majavah>	 !log project-proxy failing over to proxy-03 T295235
[13:21:16] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Project-proxy/SAL
[13:21:16] <stashbot>	 T295235: Update project-proxy proxies to Debian Bullseye - https://phabricator.wikimedia.org/T295235
[20:30:51] <legoktm>	 Is there something in the Toolforge proxy that would prevent me from issuing a HTTP 302/307 to a URL that is 4627 bytes/characters long?
[20:31:29] <legoktm>	 From my webservice's logs, it properly creates the redirect, but https://ls.toolforge.org/p/19420423 gives me a 502 bad gateway, which suggests an issue at the proxy level
[20:32:58] <wm-bb>	 <lucaswerkmeister> I know uwsgi has a limited buffer size for *request* headers, not sure if that also applies to response headers but you might need something like this? https://github.com/lucaswerkmeister/tool-speedpatrolling/blob/main/uwsgi.ini
[20:33:40] <legoktm>	 hm, this is in Rust, and when I tested it locally there was no limitation on header size
[20:33:50] <wm-bb>	 <lucaswerkmeister> ah ok, then that’s probably not it
[20:34:04] <legoktm>	 I believe the proxy should be talking to my Rust webserver directly, but I'm not exactly sure
[20:35:10] <legoktm>	 on my laptop I see https://phabricator.wikimedia.org/P17727
[20:47:36] <majavah>	 legoktm: the error appears to be coming from the ingress-nginx kubernetes proxy layer, but I don't have more time to troubleshoot it right now
[20:52:07] <majavah>	 legoktm: apparently http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffer_size needs to be higher for it to work, setting a relevant annotation in your kubernetes ingress resource (nginx.ingress.kubernetes.io/proxy-buffer-size: "8k") changes the message a little which suggests it's the same issue on another proxy layer
[20:53:34] <majavah>	 "another proxy layer" being the front proxy
[20:59:01] <legoktm>	 majavah: ooh, thanks. So I guess Lucas's tool is creating headers that are larger than uwsgi but still under that limit
[20:59:37] <legoktm>	 I might just use http-equiv refresh as a workaround for now, since this is just a proof of concept