[wildfly-dev] A look at Eclipse MicroProfile Healthcheck

[Jeff Mesnil]

> On 6 Jul 2017, at 21:26, Rob Cernich <rcernich at redhat.com> wrote:
> 
>>> Regarding the probes, three states would be best, if you can swing it, as
>>> OpenShift defines two probe types: liveness and readiness.  Live is
>>> running, but unable to handle requests, while ready means it's running and
>>> able to handle requests.  For example, while the server is initializing,
>>> it's alive, but not ready. Something to think about.
>> 
>> Three states (red/orange/green) was discussed when the healthcheck API was
>> proposed. It was rejected as it puts the burden on the consumer to determine
>> the overall healthiness.
>> Besides, Kubernetes expects a binary response from its probes. If the HTTP
>> status code is between 200 and 400, it is successful[1]. Anything else is
>> considered as a failure.
>> 
>> Kubernetes distinguishes between readiness and liveness. As defined, the
>> healthcheck API deals mainly with liveness.
>> But it could be possible provide some annotation to specify that some health
>> check procedures can determine when an application is ready.
>> For example, WildFly could be considered ready (i.e. Kubernetes will start to
>> route request to it) when:
>> * it status health check is “up and running”
>> * its deployment health check verifies that all its deployments are enabled.
> 
> I think this is a bit over simplistic, e.g. what happens if a deployment failed to start?  The pod would be marked as alive, but would never become ready.  If the deployment failed, presumably, the pod should be marked as dead.  One use case we've seen is using JPA to initialize a DB.  If the DB isn't available, the deployment fails and the pod continues to bounce until the DB is accessible.  (Yes, this is not good practice, but it illustrates the point, and some of our layered products actually do this, so…)

You are right, these were only some (simple) ideas but not actual definitions of health checks.
The deployment healthiness is a bit complex. It needs to identify deployment that failed but to do that we need to know about deployment attempts (I don’t think we get such info at the moment).
We could check when the server is started if there is any deployment in the deployments directories and correlates that with /deployment resource after the server is started, etc.

But the idea remains the same: WildFly should be able to identify whether its deployments status is healthy or not.

jeff

-- 
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/