Health Spec roadmap towards 1.0

[Heiko Braun]

I've been going through the health spec issues and assigned milestones better plan the scope of 1.0:

https://github.com/eclipse/microprofile-health/issues

It reflects by point view, but it would be good if others could go over it and check if that in line with your expectations. When doing that, please  keep in mind that we talk about a two week timeframe for 1.0.

Heiko

[Heiko Braun]

I've scheduled a conference call for next Tuesday to discuss the scope for the first release. Same time, same location as usual. The goal is to nail down 1.0 and make sure everybody is in agreement with the planned changes to make it to 1.0 in the next two weeks.  

Heiko

[Heiko Braun]

Please note that the call to discuss the remaining health items towards 1.0 has been postponed by one hour:

- CET Times 

- EST Times

[John D. Ament]

Hi Heiko

I think something's wrong with my head, or I stopped being able to process timezones.  Presently its 7:57 AM Eastern.  Is it 2 hours until Health Check meeting?  Or 3?  I believe we're currently in EDT but the calendar that launches with EDT is wrong, saying the MP conference call is at 6pm EDT.

John

[Heiko Braun]

It is in ~ 3 hours. 

[Heiko Braun]

Maybe this helps: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017&month=8&day=22&hour=15&min=0&sec=0&p1=168&p2=43&p3=224

[Mike Croft]

I find using http://everytimezone.com/ is very helpful!

[Heiko Braun]

Join us and have say:

https://hangouts.google.com/hangouts/_/6usetnw7zbdplghwovvwngvfhme

[Heiko Braun]

I did to cancel the call after 10min, because I was the only attendant. 

[Andrew Pielage]

Are we going to reschedule it at all?

[Heiko Braun]

It seems there is a n issue with the hangout URL, please try this one if you want to join:

https://hangouts.google.com/call/qjtaq5rqb5ghrmrvzuuoy2rk2ey

[Heiko Braun]

Here are the minutes for todays call:

Minutes

Most pressing: A decision Scott’s PR’s #59 in comparison to #60.

• Key areas for 1.0:

• Baseline API (PR’s #59 in comparison to #60)

• HTTP protocol binding:

• Single entry point per JVM (runtime) or per deployment (more in line with Java EE models and assumptions)?

• We could a) leave it to the implementor to decide

• … or b) scope the /health binding to the JVM (runtime) per spec decision

• a) leaves more room to evolve and has less conflicts with baseline assumptions in Java EE, but b) reflects clearly what the intention of a health check is and the assumption behind it (i.e. failed check terminates the JVM)

• Security (Authentication needs):

• We see two possible approaches for 1.0:

• a) just name the required authentication means required to be supported (i.e. Digest and JWT) and leave it the runtime how these are configured and enabled (out-of-bounds)

• b) A different approach altogether: no payload by default. Without payload, no sensitive data can be exposed. Without sensitive data, no authentication is required

• For b) speaks the fact that:

• Primary use case is machine-machine communication. Here the payload is ignored anyway

• Without payload the performance increases and health checks are time sensitive (<1 sec in many cloud platforms)

• Most cloud platform don’t support authentication means for health checks

• An approach to b) could be @Health(sensitive=true) by default, which suppresses the payload and forces developer to explicitly enabled a response payload for a health check with @Health(sensitive=false)

• With respect to the PR’s #59 in comparison to #60 a decision for #60 has been taken, based on the information available to the participants on the call (github votes, ML comments)