Health 1.1 breaks backwards compatibility with Health 1.0

[derekm]

Issue #125 & PR #127 breaks backwards compatibility with Health 1.0.

The wireformat is part of the spec's contract, so the health response message body cannot be reconsidered until Health 2.0 is being considered.

Wireformat changes should be reverted, and outcome and state should be restored.

People are already investing in autonomous control planes that respond to MP Health 1.0 /health responses, and MP Health 1.1 cannot break these systems or impose technical debt onto these systems.

I'm not saying 1.1 needs to become 2.0. I'm saying we need to collect our grievances before we cut 2.0, instead of cutting 2.0 with our 1st grievance and 3.0 with our 2nd grievance, etc.

These same versioning constraints should apply to my issue #110 and the unique check names issue #34 and all other issues.

1.1 can have a useless optional "Spring health check 'outcome/state' to 'status/status' rename compatibility mode", but 1.1 cannot wholesale change "outcome/state" to "status/status".

Pushing these changes into 1.1 while be a black eye for MicroProfile as it teaches people that they can't trust MicroProfile to maintain backwards compatibility.

CC: @Emily-Jiang @cescoffier @antoinesd

[cescoffier]

The fact this is a breaking change has been discussed on the mailing list. However, I don't mind releasing it as a 2.0.

[derekm]

Users of MicroProfile will not be happy to be bombarded with rapid succession of breaking changes.

Frankly, you guys need to rethink your eagerness and recklessness here.

[derekm]

On what whim will you release 3.0?

[derekm]

PS: I interpreted you as saying, “I’m okay releasing 1.1 as 2.0 instead.” Apologies if I misinterpreted you with my responses above.

[derekm]

PPS: if you’re still doing this nonsense in 2.0, don’t forget to change getState to getStatus (and State to Status).

I think I’ve demonstrated how un-thought-through this change is.

[Emily-Jiang]

As mentioned in twitter, bumping up to 2.0 is a good call.

…

On Thu, 18 Oct 2018, 07:48 Clement Escoffier, ***@***.***> wrote: The fact this is a breaking change has been discussed on the mailing list. However, I don't mind releasing it as a 2.0. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#146 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKfX5D5vUlutCB7dcHTNk5RdVtHEFMxjks5umBYogaJpZM4Xq7n2> .

[derekm]

I'm recommending against bumping to 2.0 and asking that we consider reverting this change.

There is this twice-renewed Internet-Draft RFC being actively written:
https://inadarei.github.io/rfc-healthcheck/
https://tools.ietf.org/id/draft-inadarei-api-health-check-02.txt

It calls for a status field, but it's values are pass, fail and warn.

Why are we switching from outcome to status if not for potential RFC compliance?

Should we be considering the draft RFC's values?

Should we be considering contributing to this RFC?

Thank you for your consideration on this issue!

[derekm]

This active Internet-Draft RFC might provide a good compromise if MP Health can commit to remaining 1.0-compliant while beginning to add Internet-Draft RFC compliance.

Adding "status" with RFC "pass/fail/warn" values alongside "outcome/state" with Health 1.0-compliance is not a bad option. (That is, add "status" instead of rename "outcome" and "state".)

[Emily-Jiang]

I would not vote to revert the changes as the changes has a lot of merits as explained in the issue. I am ok to bump the version.

…

On Thu, 18 Oct 2018, 10:19 Derek P. Moore, ***@***.***> wrote: This active Internet-Draft RFC might provide a good compromise if MP Health can commit to remaining 1.0-compliant while beginning to add Internet-Draft RFC compliance. Adding "status/status" with RFC "pass/fail/warn" values alongside "outcome/state" with Health 1.0-compliance is not a bad option. (That is, add "status" instead of rename "outcome" and "state".) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#146 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKfX5Bu5ao-sAV3KWyzojVCWH0PHzHvhks5umDmKgaJpZM4Xq7n2> .

[cescoffier]

using 3 values makes it unsuitable for Kubernetes (so cannot be used for automatically consumed liveness and readiness checks).

[derekm]

I read the issue and it lists these as merits:

• "is better understood" (not necessarily true)
• "in service-mesh platform, it is much easier to be communicated" (service-mesh already has to accommodate many health check styles)
• "match with what Spring says" (Spring supports UNKOWN, OUT_OF_SERVICE & custom values)
• "consistent payload across all of their microservices" (who are we consistent with?)
• "the most common approach is to use status" (not backed up by data or references)
• "I personally don't find the arguments about consistency very convincing" (obviously)

The following questions were left unaddressed:

• "should we add a version field defining the version of the model?"
• "mark outcome and state as deprecated? implementations can decide to provide both or drop the old ones?"

Points against:

• "Application[s] would need to update to the new format" (people will not see value in the change, they will see wasted labor hours)
• "Not sure I agree that status is more understood than outcome" (contradicting the primary merit)

[derekm]

If we're targeting Spring compatibility, should we also change "checks/data" to "details/details" and knock out my issue #110 ?

[derekm]

Spring output is:

{
   "status":"UP",
   "details":{
      "diskSpace":{
         "status":"UP",
         "details":{
            "total":250790436864,
            "free":100327518208,
            "threshold":10485760
         }
      }
   }
}

Only thing needed to comply with that is #110 and another "checks/data" -> "details/details" rename.

[tnsasse]

+1 for bumping the version. It’s crucial that MP holds up to backwards compatibility. MP should remain agile but not be seen as experimental.

[derekm]

Getting your keys wrong in 1.0 will cause you to be seen as experimental and untrustworthy.

Who are we coming into compliance with by adopting "status/status"?

I'm scouring Google and I can only find Spring. Why ignore Spring's "details/details"?

[derekm]

Dropwizard does "healthy": true/false. Now how will our service meshes handle that?

[derekm]

Vert.x is "outcome/status": https://vertx.io/docs/vertx-health-check/java/

[derekm]

As Red Hat folks, @heiko-braun & @antoinesd both obviously have Vert.x exposure.

MP Health 1.0's format most closely matches Vert.x's format.

[cescoffier]

I implemented the Vert.x support, and it will be updated as soon as the new MP Health check is released.

[derekm]

@cescoffier -- k8s HTTP liveness probes only consider HTTP status codes and not message body "status" values: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-http-request

What do you mean about the Internet-Draft RFC's 3 "status" values being a problem?

Are you guys trying to form an undocumented standard across multiple projects? Which projects?

[derekm]

ASP.NET 2.2 health checks will use "status": "Healthy":
https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/implement-resilient-applications/monitor-app-health#querying-your-microservices-to-report-about-their-health-status

See also HealthReport.cs,HealthStatus.cs and HealthCheckResult.cs here: https://github.com/aspnet/Diagnostics/tree/release/2.2/src/Microsoft.Extensions.Diagnostics.HealthChecks.Abstractions

[antoinesd]

Hi @derekm. I agree with others that we probably need to bump the version to 2.0 if there are backward compatibility break in 1.1.

Regarding your various remarks, here are a few answers:

• MicroProfile was designed to release small and often to avoid tunnel effect we have with Java EE / Jakarta EE. The price for that is to accept (at certain conditions) non backward compatible modification. This said, there's a common agreement that these should be avoided and introduced if necessary in major version.
• Microprofile is a community project. It is supported by major vendors like Red Hat, IBM or others but there's not a huge team working on it. When it comes to Health Check, no one is full time on it. All this to say that we have a greater need for contributors than advisors.
• There's a Health Check public meeting every 2 weeks. It's open to everybody in the community. Next meeting will be Friday Oct 26th at 3:00pm CEST on https://zoom.us/j/460194898

[derekm]

This breaking change seems to be driven mostly by personal preference and is not a decision made through data and facts. This breaking change does not create much value at the expense of breaking large-scale orchestrations.

"Move fast and break things" is a joke, it isn't an actual thing.

If we are breaking things for the sake of breaking things, then I want to help the community open its eyes to real data- and fact-informed decision making. If we're going to break the wireformat, then there is a lot more breakage to consider before this breakage legitimizes itself.

There is nothing about the current changes that has to do with avoiding a tunnel effect or being agile, those are weasel words and non-rationale.

If MP Health is saying, "Oops, we fucked up on 1.0, here's 2.0," then I'm going to be here making sure 2.0 isn't similarly a fuck up, because it is kind of looking like it will be so far.

Funny thing is, I'm roping in the Internet-Draft RFC author, and he is excited to join us, but he has "details" which is Spring-compatible, and as his first order of business he wants to ditch his "details" for our "checks"!

People here are getting hung up on synonyms, and maybe because English isn't their first language. Even the RFC effort is caught up in "I don't like this name, but I do like that name" non-innovation.

I'm not sure why we're spinning our wheels with needlessly rotating through synonyms when, no matter what, industrial-strength service meshes will need to be application-style aware, since there is absolutely no agreement whatsoever on Health Check Response Formats (outside of maybe this nascent RFC, which in my mind provides some hope for both MP Health 2.0 & the developing RFC).

[derekm]

@antoinesd -- I'm deeply committed to MicroProfile (and Hammock) as a user and a contributor. I'm pushing MicroProfile at work, and I'm winning arguments with it, and in 2019 we're cutting over to EE8/MP2 (I've been using most of MP2 long before MP2 was defined). Our new projects are setup to rapidly evolve along with MicroProfile, but breaking changes that lack solid rationale and strong value propositions hinder my ability to rapidly evolve.

It sounds like you guys aren't actually relying on your health responses. Breaking changes that don't deliver high production value hinder my ability to quickly evolve along with MicroProfile, because I'll have to stop to retrofit my system to accommodate these low-value feelings/emotion-based changes.

Maybe we can get other projects to admit that they don't actually use their health responses either, so they can break their formats, too, and we can actually get some real consolidation around a standard Health Check Response Format.

Think of all the MicroProfile evangelism blogs you are breaking. Hundreds of developer advocates will have to meticulously update the JSON in their MP Health demo posts, unless they'll decide to pack up and move to more stable ground and that MicroProfile was fun while it lasted.

MicroProfile is the hottest name in Java right now. It better be smart to avoid accidentally making vanity changes like this, especially when false consensus can be formed on a whim over a short period of time to quickly push through personal preferences.

I'm sure we're not stopping here with the breaking changes, so hopefully we can make the best of it if 2.0 is on the horizon now instead of 1.1!

[derekm]

Will the next release of MicroProfile proper have to be 3.0 if MP Health goes 2.0?

Should the other specs open themselves to breaking changes if Health 2.0 is going to force MicroProfile to bump to 3.0?

[kenfinnigan]

No. Bumping the major version of the MP umbrella is only required when the underlying specifications are updated.

Such as the move from Java EE 7 to Java EE 8

[derekm]

@kenfinnigan -- If MP umbrella is going to make a release that includes the MP Health 2.0 spec in the list of specs, then it can't do that as MP 2.1, it has to do that as MP 3.0. Correct?

[kenfinnigan]

No it doesn't, that's what I mean.

Major versions for the umbrella spec are not semantic. If it were, MP umbrella release versioning would increase at a crazy pace.

As per https://docs.google.com/document/d/16v3jVkcDzVz9BVU5aGEzPVbK-a8BIx7S1gbqToVUaLs/edit, MP 2.2 will include new breaking change 2.x versions for Fault Tolerance and Metrics, but MP is only moving from 2.1 to 2.2

[antoinesd]

out of date