Populate docker compose healthcheck status #6414
Conversation
Signed-off-by: Remigiusz Orlowski <[email protected]>
remi00
force-pushed
the
dc-healthcheck-into-runtime-status
branch
from
9d5f7bc to
99ff5bc
Compare
| return state.Status | ||
| } | ||
| if state.Health.Status == types.Starting { | ||
| return ContainerStatusRestarting |
There was a problem hiding this comment.
i wonder if this should be created?
There was a problem hiding this comment.
This, combined with a change in RuntimeStatus() method, improves the user experience on container rebuild in case of docker containers with healthcheck. It reflects that there is an additional "pending" state of healthcheck status.
Without it, in case when the healthcheck started failing after the rebuild, the runtime status would be first green and only after the healthcheck is considered as failing by docker, the runtime status would become red. This can take quite some time, because healthcheck status will become reported unhealthy at minimum after interval times retries from healthcheck definition on docker-compose.yml, adding up potential confusion to the user.
With this change the runtime status will be "pending" as long as the the healthcheck is "healthcheck: starting".
By the runtime status I mean the red element on Tilt UI:
There was a problem hiding this comment.
do ContainerStatusRestarting and ContainerStatusCreated have different displays in the UI?
There was a problem hiding this comment.
ContainerStatusCreated ->> green runtime status
ContainerStatusRestarting ->> below animated. At the end of animation is a transition to unhealthy state.
Screen.Recording.2024-07-24.at.11.08.29.mov
Again, without the change in question when the healthcheck procedure is ongoing the runtime status would mistakenly indicate green status.
| if state.Health == nil || state.Health.Status != types.Unhealthy { | ||
| return "" | ||
| } | ||
| result := "container is unhealthy" |
There was a problem hiding this comment.
is this log displayed anywhere today? i didn't see it anywhere in the UI, only in the tilt cli output
There was a problem hiding this comment.
I didn't find it on the UI either.
|
OK, I played with this in a few projects, and now I remember why we did it this way. The Compose Spec says this:
i.e., the default definition of readiness is "the service has started", NOT "the service is healthy" if we define readiness the way this PR does it, it will break startup order. the problem here is that Tilt and Compose model dependencies differently -- in Tilt, if 2 resources depend on 'common', then both resources can start once 'common' is ready. In Compose, 2 resources can have dependencies on different parts of the 'common' lifecycle i have some ideas on how to address your use-case a bit differently but need to play around with it a bit. |
|
@nicks Thanks for explaining. Let me know if I can help more. In the projects I am using tilt, this change drastically improves UX, but I understand that the readiness aspect is more important here than just displaying it on the UI. |
|
Just to add to my previous comment. The healthcheck reporting is an important capability for devs by itself. Considering that docker does support concept of a healthchecks, there should be a way to present the healthcheck status on the tilt UI if it supports docker-compose in the first place. Missing that is a huge gap. In my case current behavior was a huge confusion (tilt supports probing, supports docker-compose and it misses supporting combination of both). Even if there was no news on tilt-dev website that Tilt has joined Docker. |
|
addressed this in another pr #6419 |
With this change docker compose healthcheck status details are populated into runtime status, making the tilt UI reflect detailed information.
Closes #6413