List of steps to reproduce (step by step, including full links if applicable):
What happens?:
Error 503 Service Not Available
What should have happened instead?:
Not that
Description
Description
Event Timeline
Comment Actions
$ kubectl get all NAME READY STATUS RESTARTS AGE pod/global-search-765bdb846c-vnt55 1/1 Running 0 55d NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/global-search ClusterIP 10.101.69.158 <none> 8000/TCP 2y58d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/global-search 1/1 1 1 2y58d NAME DESIRED CURRENT READY AGE replicaset.apps/global-search-765bdb846c 1 1 1 2y58d
The active pod seems to have been running for a very long time, but the 503 would indicate that the frontend proxy for all of Toolforge has lost track of where the service is running.
Comment Actions
Mentioned in SAL (#wikimedia-cloud) [2022-07-06T17:10:56Z] <wm-bot> <root> Hard stop & start cycle to reregister with frontend proxy (T312246)
Comment Actions
Seems to be fixed. This was also apparently the first hard stop/start cycle applied to the tool in over 2 years, so actually kind of awesome that Kubernetes kept things working for so long without intervention. :)