Re: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck
On 6 Jul 2017, at 21:00, Heiko Braun <hbraun(a)redhat.com>
wrote:
Kubernetes has different semantics for live and ready, i.e how it interprets and reacts
to certain health responses, but underneath its the same protocol.
With the health api it's no different: you can model readiness or liveness checks
with it. I think the only constraint we are facing atm, is the usage of a single protocol
entrypoint. This approach disallows to have live and readiness checks for the same node
(i.e there is just /health)
Maybe we should change that to support multiple protocol entry points? These could either
be custom ones or defined in the spec. For instance rather then having /health, we could
introduce /live and /ready. The api underneath however would remain the same.
Some further food for thought (that will go in an issue in the spec later today):
Maybe the spec could provide some additional metadata to further characterize the health
check procedures.
For example a procedure annotated with @Ready would return UP when the component is
“ready” (for whatever it is doing) and DOWN otherwise.
The same component could have another procedure (without any annotation or a @Live one)
that returns UP when the component checks it is healthy.
The component would return different status depending on its state:
* during its initialization (READY = DOWN, LIVE = UP)
* after its initialization (READY = UP, LIVE = UP)
* if it is encountering some issues, (LIVE = DOWN, READY = <whatever>).
The spec could then provide a different entry point that only checks procedures annotated
with @Ready.
TL;DR:
the spec should enforce only 2 states (UP and DOWN) for each check procedures but could
characterise them to let consumers query different type of healthiness (live and ready)
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/