Status UP even if deployment failed

[rsoika]

I have a general conceptual question about microprofile-health api.

In my application I implemented a details health status which results in a output with HTTP Code 200 as followed:

{
    "status": "UP",
    "checks": [
        {
            "name": "imixs-workflow",
            "status": "UP",
            "data": {
                "engine.version": "5.2.9-SNAPSHOT",
                "model.groups": 1,
                "model.versions": 1,
                "index.status": "ok",
                "database.status": "ok"
            }
        },
        {
            "name": "ready-deployment.imixs-office-workflow.war",
            "status": "UP"
        }
    ]
}

I am running this on Wildfly. My Kubernetes health check looks like this:

spec:
  containers:
    ...
    livenessProbe:
      httpGet:
        path: /health
        port: 9990
      initialDelaySeconds: 120
      periodSeconds: 10
      failureThreshold: 3
   ...

So I am using the default behaviour from Kubernetes here to validate the http response code 200=OK.

But I run into situations where something bad happens and my application did not start correctly and is not deployed at all. This results on the server in a health status like this:

{
    "status": "UP",
}

And so again we have http response code 200=OK.

Is there any chance in eclipse microprofile-health to force the Status=DOWN in case a specific deployment is missing?

[xstefank]

@rsoika we on purpose do not specify the behavior in containers that allow multiple deployments as MP is targeting microservices (one app per runtime). We plan to discuss app server environments in detail in a later version of the specification. I would suggest opening this issue directly with the WFLY application server. I believe there are ways to fail the probes if the deployment fails. Also please feel free to mention me in the WFLY issue too.

[rsoika]

Thanks for your response. I opened a bug wildfly report: https://issues.redhat.com/projects/WFLY/issues/WFLY-14804

I understand your point and suggested that the Wildfly MP Health impl should return a HTTP response code 204 or 206 if a deployment failed during startup. This would make it easy to integrate with Kubernetes liveness Probe

[xstefank]

@rsoika Can we close this issue or do you have any more questions/concerns?

[rsoika]

yes of course