ping @yongtang

@aaronlehmann The PR has been updated. Please take a look and let me know if there are any issues.

Thanks, I like this design a lot more. The naming seems fine to me, but others can feel free to comment if they think of a flag name they prefer to --no-wait.

Design LGTM

Thanks @aaronlehmann for the review. The PR has been updated with no-wait.

I wonder if we can just have a whole separate configuration for the startup protocol.
For instance, even if the healtcheck is performed immediately on startup, what if it fails because something wasn't quite ready, and then it needs to wait the entire interval period anyway.

@yongtang can you have a look at @cpuguy83's comment?

What do you think about merging this as a good solution?
The current healthcheck is not useable. So this would be a major improvement.

#33918 (comment) could be another issue.

@rdxmb The problem is I don't believe this is a good solution. It may be a solution that works for some case that you currently have but that does not make it a good one.

I am with @cpuguy83 on this one. I also have a bunch of containers that need a second or so before they are fully running. They should be able to go into healthy state within seconds, but there is no way to make that happen without setting a short check interval. This pull request still would not fix that.

Ideal solution in my case would be if a health check would happen right after the start-period. Then, I can choose a a start period of, say, 5 seconds and a check interval of 5 minutes and still have the container go healthy in seconds.

Some sort of a --wait-for-start option that triggers this behavior would be backward compatible and cover all discussed use cases, right?

@cpuguy83 @dtakken Ok, I think I got it.
I just tried to draft the suggestions made up to now: #33410 (comment)

Discussing in the maintainers meeting: one option is to add a --health-start-interval instead, for example:

--health-start-interval=3sec
--health-interval=5min
--health-retries=3
--health-start-period=0

That configuration would:

• start the container
• start health-check every 3 seconds
• if three consecutive health-checks fail, the container fails

Combining this with start-period:

--health-start-interval=3sec
--health-interval=5min
--health-retries=3
--health-start-period=10min

This would:

• start the container
• perform health-checks every 3 seconds
• if the health-checks fail during the first 10 minutes (--health-start-period), they are not counted as a failure, and health-checks continue to run every 3 seconds
• if the health-check passes during the first 10 minutes, the container becomes healthy, and the interval is changing to run healthchecks every 5 minutes (--health-interval)

--health-start-x options by default use the same values as the regular --health-x options; In future we can add additional --health-start-xx options that would override those if we see a reason to add those.

@thaJeztah The --health-start-interval option proposed above is great! Is it still on the roadmap?

What's the current status here?
Without this fix a service will keep in "Starting" state until the first health check is performed.
This leads to a service downtime of the health intervale whenever a service is updated which makes the health checks unuseable if you don't want to have them in a high frequency.

I've created #40894 to replace this.