Revisit the message body of health

[Emily-Jiang]

In the current health spec, we have

{
  "outcome": "UP",
  "checks": [
    {
      "name": "first-check",
      "state": "UP",
      "data": {
        "key": "foo",
        "foo": "bar"
      }
    },
    {
        "name": "second-check",
        "state": "UP"
    }
  ]
}

In the message it says 'outcome'. I think it should be changed to 'status', which is better understood and also match with what Spring says. In this way, in service-mesh platform, it is much easier to be communicated. Thoughts?

[kenfinnigan]

Not sure I agree that status is more understood than outcome, but if there's desire to change it then I'd say change it to something like overall-status or something else that indicates it's a rollup situation.

Also, not sure how Service Mesh plays into this, can you elaborate?

[seabaylea]

I think its desirable to users to have a consistent payload across all of their microservices - regardless of the framework (or language) that each is built in.

There isn't a significant level of consistency in the way of convention today, but certainly the most common approach is to use status for the overall result.

[Emily-Jiang]

@cescoffier further to our discussion at EclipseCon, it is a cool thing that we can sync up in different tools and languages. Wait to see your PR and great to see you are back to Health spec again!

[Ladicek]

If there's a consensus to rename outcome to status (and I personally don't find the arguments about consistency very convincing), would it make sense to rename state of the individual checks to status as well?

[Emily-Jiang]

Maybe renaming state in the individual to status is even better. The top level status is the aggregation of the 2nd level of status.

[cescoffier]

+1 to have status everywhere.

I would like to discuss the backward compatibility, as it's a breaking change. Application analysing the content of the response would need to update to the new format. We can mark in the spec the outcome and state as deprecated in the spec. The implementations can decide to provide both for now or drop the old ones. WDYT?

[cescoffier]

Another point, should we add a version field defining the version of the model?

[pilhuhn]

If we add more fields, then it could also be good to optionally allow hints for operations folks, like a short description and a url to more information.

[cescoffier]

@pilhuhn for each procedure? or in the global report?

[pilhuhn]

I would do it for each procedure and the global report. In many cases we will only see the global report, but if there are many procedures then it is expected that those parts can fail independently and thus the hints would be needed for each of the individual parts that can fail.

[cescoffier]

I've opened a first PR doing the renaming: #126.

[cescoffier]

@pilhuhn the PR mentioned in my previous comment does not include extra-metadata. I would prefer having a second PR extending the model with them. Would you be ok with this?

[pilhuhn]

On 21 Jun 2018, at 14:55, Clement Escoffier wrote: extending the model with them. Would you be ok with this?

Yes of course

[cescoffier]

Updated PR: #127

[Emily-Jiang]

@cescoffier pleas also update the readme doc accordingly.

[cescoffier]

Closed by #127

[cescoffier]

@Emily-Jiang can you close this issue? (it seems I can't)

[cescoffier]

@Emily-Jiang I've updated the README, did I miss something?

[Emily-Jiang]

Thank you @cescoffier ! Looks good.

[derekm]

Can we rename this issue to "Rename outcome/state to status/status" or similar, so that it is obvious what this issue deals with?

Can we also revert this breaking change and continue this discussion until Health 2.0 is being considered?

I think service meshes should be app framework aware and should talk to each app in it's own way, whether Spring, MicroProfile, Dropwizard, Play, or home-brew stackoverflow copy/paste job.

Service meshes that aren't ping/health service style aware aren't good reasons to impose changes that break service meshes in Health 1.1!

Thanks for reconsidering this change!

[derekm]

If MP Health 2.0 is being developed in the master branch now, then instead of renaming this ticket, can we reopen this ticket to track all of the changes to the message body?

We're obviously not done revisiting the message body of MP Health.

I'd like to get #110 added in for 2.0.

I'd also like to recommend working with inadarei/rfc-healthcheck#24.