Default live and ready health check response for deployed applications

[sdaschner]

It would be a simplification for less complex applications to declare a way where a successfully deployed applications shows up in the health resources, even without requiring some code in the project.
I.e. as soon as mp-health is supported/activated/installed on the implementation side, the /health resource could deliver a default response for the deployed application (given, no deployment error occurred).

Consider something similar to the following:

{
  "checks": [
    {
      "data": {},
      "name": "<app-name>-default",
      "status": "UP"
    }
  ],
  "status": "UP"
}

In this case, would not need the mp-health dependency, only a configured runtime (e.g. mpHealth-x.x feature in Liberty), and we save quite some boilerplate code for a lot of use cases.

Otherwise, IMO the benefit of defining a default health check with mp-health is not much bigger than defining a simple OK-resource in JAX-RS...

[xstefank]

Hi @sdaschner, thank you for the idea. There is an option for implementations to provide custom default health procedures [1]: A producer SHOULD support reasonable out-of-the-box procedures and some actually do (as discussed in #180). So it's not mandatory but it's definitely possible.

[1] https://github.com/eclipse/microprofile-health/blob/master/spec/src/main/asciidoc/protocol-wireformat.adoc#health-check-procedures

[jmesnil]

We did something related in WildFly to add a default readiness probe (which always returns UP) to a deployment if the deployment defines none: https://issues.redhat.com/browse/WFLY-12952

This allows to configure the server to returns DOWN until the (first) deployment is deployed. If the deployment defines readiness probes they will used to determine the overall readiness of the runtime. Otherwise, this default readiness probe will ensure the runtime is ready when the deployment is deployed.

We did not do the same thing for liveness probe as it does not make sense (a deployment is "live" by default and must provide its own liveness procedures to determine when it is not).

[xstefank]

To sum up: This would influence only multi deployments runtimes/app servers and wouldn't be necessary for the single deployment applications (maybe even additional and unwanted). This would mean that we need to add an optional part of the spec that would be implemented only in the app server environments. Since we are close to 3.0 release I would like to rediscuss this with the team for the next minor release since this would not be a breaking change.