close

Filter

loading table of contents...

Release Notes / Version 10.2107

Table Of Contents

Runlevel Health Indicator Signals Wrong State in Runlevel MAINTENANCE

When the Content Server is switched to runlevel MAINTENANCE either during startup or manually, the health/runlevel endpoint signals the server is UP. This makes it impossible to use the indicator for a readiness probe in Kubernetes, because the pod will be added to the services endpoint too early and UAPI clients that listen on a services availability would fail during the creation of the repository connection.

This change fixes the health state in the MAINTENANCE runlevel to down and includes the indicator in the health/readiness endpoint.

The content-server can therefore be in one of the following states:

  • runlevel=OFFLINE, Liveness State=BROKEN, Readiness State=REFUSING_TRAFFIC

  • runlevel=MAINTENANCE, Liveness State=CORRECT, Readiness State=REFUSING_TRAFFIC

  • runlevel=ADMINISTRATION, Liveness State=CORRECT, Readiness State=REFUSING_TRAFFIC

  • runlevel=ONLINE, Liveness State=CORRECT, Readiness State=ACCEPTING_TRAFFIC

If your health check logic depended on MAINTENANCE level being a 200 HTTP result, disable the runlevel endpoint by setting

management.health.runlevel.enabled=false
management.endpoint.health.group.readiness.include=readinessState

Please be reminded, that using the health actuator to automatically trigger a redeployment of a pod / container is not advised and can be dangerous due to health indicator that monitor connections to remote systems. This can cause chain reactions taking multiple services down. Instead use the host:8081/actuator/health/liveness endpoint instead.

(CMS-21355)

Search Results

Table Of Contents