Increase period, timeout and threshold for the frontend liveness check

Existing values lead to the frontend being killed when it becomes more sluggish than usual.

Signed-off-by: Andrej Shadura andrew.shadura@collabora.co.uk

helm/open-build-service/charts/frontend/templates/deployment.yaml

@@ -76,7 +76,9 @@ spec:
             httpGet:
               path: /
               port: http
-            failureThreshold: 1
+            failureThreshold: 3
+            timeoutSeconds: 10
+            periodSeconds: 30
           readinessProbe:
             httpGet:
               path: /

[Sjoerd Simons]

should the readyness probe get similar updates? Also these numbers are still very loose; This would mean in a timespan of 2.5 minutes the API has failed to reply within 20 seconds to a very basic http request.. So yeah pretty unusable..

Are you expecting it to be common to take over 1 second for OBS to reply? Would using e.g. the default failureThreshold of 3 not be enough to avoid accidentally restarts due to short hickups ?

If we're going for thresholds like as loose as this it would be good to have a rationale why the web frontend is "expected" to behave this badly

[Andrej Shadura]

I think readiness probe doesn’t need to be changed, since it’s only used at the startup, as I understand.

Regarding failureThreshold: 3 probably should work.

[Emanuele Aina]

For what is worth, both readiness and liveness probes run over the whole lifecycle of a container.

If liveness fails, the container is killed and restarted.

If readiness fails, the pod is dropped for the service endpoint (that is, no traffic is routed to it).

There are also startup probes that indeed only run at the start of the container and delay the other probes until startup succeeds.