Enable readiness and liveness probe endpoints by default

[dsyer]

Kubernetes has a core point in its philosophy: an application should not have to behave differently in a cluster. The readiness and liveness probes are generally useful outside k8s, so it doesn't really make sense (to me) that I have to set an explicit property to see them running locally.

[bclozel]

That was the plan! But unfortunately we can't do that before Spring Boot 3.x, see this comment.

[dsyer]

That was a comment about graceful shutdown. Did you link to the wrong place?

[bclozel]

I don't think so. I'm reproducing and updating the comment here still:

The LivenessProbeHealthIndicator and ReadinessProbeHealthIndicator, unlike other health indicators, are not enabled by default. Same thing goes for the "liveness" and "readiness" Health Groups. They're generally useful, but right now they're only enabled if the management.endpoint.health.probes.enabled=true or if k8s is detected.

If we did enable those by default, here's what would happen:

• the LivenessProbeHealthIndicator and ReadinessProbeHealthIndicator would show up in the default group in /actuator/health. Many platforms look at this endpoint to figure out if an application is healthy or not. During startup time (and especially with long-running ApplicationRunner tasks), the readiness probe will report OUT_OF_SERVICE which could trick platforms into restarting the app indefinitely if the configured timeout is too short. In short, we're adding new facets to application availability and this is a major change that can create issues during the upgrade...
• we could enable those health indicators but not take them into account in the default /actuator/health group. In this case, we'd have an inconsistent state (a specific group could report as broken, but the default group still reports "all fine").

We'd like to switch this default but we'll need to do that for our next major version and guide developers when it comes to configuring health/availability checks on their platforms.

[ThomasVitale]

@bclozel is this issue still considered for a 3.x version?