You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the DevWorkspace Operator will do a rudimentary liveness check on workspaces by making a http get request at the workspace's <mainUrl>/healthz. However, in order to not break applications that do not implement /healthz, it has to treat 4xx staus codes as successes, meaning the health check doesn't do a whole lot for most workloads.
Instead, we should define some way of specifying actual readiness/liveness probes for workspaces, allowing e.g. the Code editor running in the pod to prevent the workspace entering a running state until it is ready to serve requests.
It should be possible to implement a workaround for this by using pod-overrides and container-overrides, but perhaps a more formal attribute or similar would be useful here.
Additional context
The text was updated successfully, but these errors were encountered:
Description
Currently, the DevWorkspace Operator will do a rudimentary liveness check on workspaces by making a http get request at the workspace's
<mainUrl>/healthz
. However, in order to not break applications that do not implement/healthz
, it has to treat 4xx staus codes as successes, meaning the health check doesn't do a whole lot for most workloads.Instead, we should define some way of specifying actual readiness/liveness probes for workspaces, allowing e.g. the Code editor running in the pod to prevent the workspace entering a running state until it is ready to serve requests.
It should be possible to implement a workaround for this by using
pod-overrides
andcontainer-overrides
, but perhaps a more formal attribute or similar would be useful here.Additional context
The text was updated successfully, but these errors were encountered: