jkube
jkube copied to clipboard
Enricher for MicroProfile Health implementations
Description
Provide HealthCheck enricher for MicroProfile Health implementations:
- [ ] SmallRye Health + Quarkified version
- [ ] ...
See also:
- https://github.com/eclipse/microprofile-health/blob/master/spec/src/main/asciidoc/protocol-wireformat.adoc
Internal reference: [protean-dev] Philosophy around healthchecks
- https://docs.google.com/document/d/11L8grYyPCNcHjcoXFo4tZomUG74bQ_JsWJOMmgyWxjQ/edit#
- This issue for the implementation
- IT for each specific frameworks:
- [ ] https://github.com/eclipse/jkube/issues/1473 etc...
- [ ] https://github.com/eclipse/jkube/issues/1468
I think we have health check implementations for the following Microprofile implementations:
- OpenLiberty: https://github.com/eclipse/jkube/pull/1541
- Quarkus: QuarkusHealthCheckEnricher
- Wildfly: WildflyJARHealthCheckEnricher
- ThorntailV2: ThorntailV2HealthCheckEnricher
In Microprofile Starter, I also see some other Microprofile runtimes for old versions of Microprofile (3.3
):
- ~Payara Micro~
- KumuluzEE https://github.com/eclipse/jkube/issues/1719
- Helidon https://github.com/eclipse/jkube/issues/1713
Do we need to consider these runtimes as well? If yes, I'd create issues for these. Or can we ignore it since they're using an old version of Microprofile?
Considering we haven't released 1.9.0 yet, we might want to refactor + redocument what was done in #1541 (#1473).
As suggested in https://github.com/eclipse/jkube/issues/1473#issuecomment-1109550057, #1473 looks like a duplicate of this issue, however, it's coupled to OpenLiberty, when it probably shouldn't.
In addition, there are more artifacts that provide a MicroProfile health implementation.
- SmallRye Health:
- https://smallrye.io/docs/smallrye-health/3.0.1/index.html
- https://github.com/smallrye/smallrye-health/ (
io.smallrye
) - We currently supported through Quarkus, which is OK, because Quarkus' dependency (
quarkus-smallrye-health
) has its own nuances. However, we should maybe support it too for its standalone usage or its usage with other libraries/frameworks.
Part of the scope of this issue is analyzing other implementations and see how we should add support for them.