MicroProfile Health 3.1-RC1 released

[Martin Stefanko]

Hi,

we released MicroProfile Health 3.1-RC1. Please give it a try.

Cheers,

Martin

[Emily Jiang]

Thank you Martin!

I took a look at the spec change and noticed the release note section was missing. Can you add that to list the changes?

Also, I saw some comments regarding the new annotation Startness was confusing. I think both Prashanth and Tim had concerns with the name Startness to map to the Startup probe. Startness is a word but it is rarely used. Since the name Startup clashes with the ejb annotation Startup, we are better off avoid that. I am wondering whether we can use the name StartupStatus instead to make it better aligned. What other better names?

Thanks

Emily

[Amelia Eiras]

startupProbe

Amelia Eiras 

twitter.com/ameliaeiras

Tribe: http://tomitribe.com     https://tribestream.io  

OSS:  http://microprofile.io     https://jakarta.ee

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/cfa656f7-5c1d-4fe8-81db-871aec72ce1bn%40googlegroups.com.

[Emily Jiang]

The previous annotation @Readiness for Readiness Probe, @Liveness for Liveness Probe. Now we are defining an annotation for Startup Probe. If we call it @StartupProbe, which does not match with the previous annotations. @Startup makes people automatically think it is an EJB startup bean. We don't have an ideal choice though.

ok, so far, we have names: @Startness, @Startup, @StartupStatus, @StartupProbe. Any other names?

Thanks

Emily

You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/j0f2zRBBMPU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAJ0g8j4_5ToUVZU9Mo1BmOOozXbmqbSo2OJ0Cn8%3DEqhyfNV_Tg%40mail.gmail.com.

--

Thanks
Emily

[Ladislav Thon]

čt 13. 5. 2021 v 23:01 odesílatel 'Emily Jiang' via MicroProfile <microp...@googlegroups.com> napsal:

Also, I saw some comments regarding the new annotation Startness was confusing. I think both Prashanth and Tim had concerns with the name Startness to map to the Startup probe. Startness is a word but it is rarely used.

As someone involved in the original discussion in SmallRye Health (https://github.com/smallrye/smallrye-health/pull/192#pullrequestreview-522615196), I feel compelled to argue that indeed, the word "startness" carries a lot of rareness, weirdness and even ugliness, but I see zero confusingness. Everyone knows what "start" means, and even I, a non-native speaker with rather terrible English, have come to intuitively understand that the "-ness" suffix means "the quality of being whatever-is-before-the-suffix". In fact, the way how the "startness" word is composed, as well as its closeness to "readiness" and "liveness", IMHO significantly improves its comprehensibleness.

LT

 

Since the name Startup clashes with the ejb annotation Startup, we are better off avoid that. I am wondering whether we can use the name StartupStatus instead to make it better aligned. What other better names?

Thanks

Emily

On Thursday, May 13, 2021 at 4:34:53 PM UTC+1 Martin Stefanko wrote:

Hi,

we released MicroProfile Health 3.1-RC1. Please give it a try.

Cheers,

Martin

--

[Martin Stefanko]

Thanks, Emily, I'll add the release notes for RC2. 

About the name for @Startness, I wanted to create a separate thread as there was a lot of pushback about the name lately, however, it seems that this thread is already taken this task. Personally, I would be ok with preferably @Startness or if not then @StartupProbe. @Startup is overloaded in my opinion but it was pointed to me that this would be not the only case in EE.

I just want to remind everyone that I would like to avoid long discussions since we need to prepare the final release and with the release ballot (two weeks) we are getting dangerously close to missing the June release for MP 4.1 (Or it will go without Health update :)).

Martin

[Prashanth G]

Would @StartupLiveness work? 

According to the Kubernetes Startup Probe definition, the behaviour of this probe is similar to the Liveness probe, but is mainly used in cases where the container is slow to start up. 

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

"The kubelet uses startup probes to know when a container application has started. If such a probe is configured, it disables liveness and readiness checks until it succeeds, making sure those probes don't interfere with the application startup. This can be used to adopt liveness checks on slow starting containers, avoiding them getting killed by the kubelet before they are up and running."

If not, I like @Startness or @StartupProbe. @Startness would match our existing annotations, but I agree it's not very comprehensive. @StartupProbe does match the Kubernetes Startup probe, as that's what we are aligning this to be used for to begin with. :)

+1, on Martin's concerns on we would need to come with a conclusion fast, in order to prepare for the final release.

Prashanth

[Emily Jiang]

Thank you Martin and Prashanth for your thoughts! Sounds good to open a separate thread for the naming discussion! Do you want to create a doodle poll and run for a couple of days to finalise the name? I think @StartupProbe or @StartupCheck is my preference as @StartupLiveness might make people confused with @Liveness.

Thanks

Emily

[Tim Quinn]

It's gratifying to see openness to reconsidering this choice.

There is no perfect solution, given where we are, as Emily said.

I've read this thread and the original PR comments carefully, and I continue to prefer `@Startup` because it continues the very helpful convention established by the other two annotation related to the K8s probe names. 

I think this despite the potential confusion with the EJB annotation. Java developers know how to disambiguate such name reuse in their code.In fact, MP's own metrics spec itself reuses the name `ConcurrentGauge` for an annotation and an interface in different packages.

So the main question to me is how much confusion between the EJB semantics and the health semantics developers would truly suffer if health adopted `@Startup`. To my mind, the use of `@Startup` in the EJB context vs. the health context are enough different that developers would be able to keep things straight in their minds. 

And, I think adopting `@Startup`--by reinforcing the correspondence between health annotation names and K8s probe names--would give a net reduction in overall confusion.

- Tim

[Martin Stefanko]

Hi,

we've released MicroProfile Health 3.1-RC2 accomodating the rename of @Startness to @Startup and few other smaller fixes. Please give it a try. We will stage the final 3.1 release on Monday.

Cheers,

Martin

[Emily Jiang]

Thank you Martin for the update! I had a quick look and have a couple of comments:

1. I still don't see the release note anywhere (I checked here)

2. should the endpoint for the new startup check to be /health/startup instead of /health/start?  (see here)

Thanks

Emily

[Martin Stefanko]

Hi Emily,

Release notes were added right after the tag - https://github.com/eclipse/microprofile-health/commits/master. Honest forgetting on my side, sorry. However, this is only a spec doc change and I don't think that RC3 is necessary just for this change. So we can create CCRs with RC2. Correct me if my expectation is wrong.

/health/start is aligned with /health/live and /health/ready. With /health/startup I would expect /health/liveness and /health/readiness which is not the case.

Martin

[Emily Jiang]

On Friday, May 21, 2021 at 6:56:18 AM UTC+1 Martin Stefanko wrote:

Hi Emily,

Release notes were added right after the tag - https://github.com/eclipse/microprofile-health/commits/master. Honest forgetting on my side, sorry. However, this is only a spec doc change and I don't think that RC3 is necessary just for this change. So we can create CCRs with RC2. Correct me if my expectation is wrong.

Okay.

/health/start is aligned with /health/live and /health/ready. With /health/startup I would expect /health/liveness and /health/readiness which is not the case.

Fair enough. Personally, I think liveness represents live -ness while startup  does not read the same as start. It might be just me and it is nitty-gritty. I think your arguement also holds. I am okay with the current design.

Thanks

Emily

[Ladislav Thon]

pá 21. 5. 2021 v 7:56 odesílatel Martin Stefanko <xstef...@gmail.com> napsal:

/health/start is aligned with /health/live and /health/ready. With /health/startup I would expect /health/liveness and /health/readiness which is not the case.

It should be /health/started then :-)

LT

 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/fdb897fb-27aa-4f82-8153-f83e06d8499en%40googlegroups.com.

[Tim Quinn]

From the silence here and the fact that the proposed final release spec discusses /health/start, I gather people were not convinced about /health/started. 

The smiley-face in the previous note aside, /health/started would be more consistent with /health/live and /health/ready. All leaf elements of the paths would be adjectives describing the state of the service ("live," "ready," and "started"), not a mix of adjectives ("live", "ready") and a verb ("start"). 

[Martin Stefanko]

With all due respect, anyone is more than welcome to participate in the specification discussions and decisions. We, the spec group, must make decisions. Anyone can express their opinions and we are willing to include the best possible solutions. I admit that none of us is a native speaker and I might have taken this argument into account when the PR was open. However, I'm sorry but I am not willing to redo the releases all the time as it takes too much time. The ballot is halfway through. If it doesn't pass then we can reopen this discussion in the spec group.

[Tim Quinn]

I had interpreted Ladislav's earlier suggestion about /health/started as genuine. I try to track several MP spec efforts (as well as accomplish other things). If I were able to follow the MP conversations and issues and PRs more up-to-the-minute then I would have noticed earlier that there had been no follow-up discussion here of his proposal and no corresponding revision in the PR, and I would have voiced my support for the change earlier. But when I have comments or observations, I will make them, even if that's later than any of us would have liked.

The endpoint paths are important public-facing interfaces. A change in a future release would affect a non-zero number of, for instance, K8s probes; it would not affect just MP developers, which in some ways would be a bit easier to manage.

I do have some understanding of the hassle involved in late changes. Even so, I'd respectfully but strongly urge that this be reconsidered, even though we are well along in the process. 

- Tim

[Martin Stefanko]

I opened the PR for the rename [1]. I will respin the release if this is a general agreement but as already mentioned this will delay the MP 4.1 release from June meaning we will need to do it in July. If everybody agrees, I will respin the Health 3.1 release after the mentioned PR is merged.

Thanks,

Martin

[1] https://github.com/eclipse/microprofile-health/pull/304

[John Clingan]

I am ok with this change. It will push the MicroProfile 4..1 release into July, but it adds value to the release. Others?

[Emily Jiang]

Since it is a small change and Martin has done the changes plus renaming later will cause a bigger headache, it is ok to take in the changes and respin the release. In order to speed up the process, a wg vote should start again asap and encourage the reps to cast their vote within 7 days since this is the 2nd round.

Thanks

Emily

[Martin Stefanko]

We respun the 3.1 release (also creating 3.1-RC3 if you're interested) yesterday. Everything is updated and ready for review.

Martin