Integration of Health Checks with wait-for Not Honoring Container 'Healthy' Status

[FloSch-Nokia]

Background

The recent addition of health checks to Containerlab, implemented in Pull Request #1426, has been a significant advancement aligning Containerlab closer to Docker Compose's feature set. However, it has been observed that the wait-for: <containername> functionality is not fully integrating with these health checks, specifically, it does not wait for the container it is dependent on to reach a 'healthy' state before initiating.

Relation to Past Issues and Discussions

This behavior seems related to previous discussions which can be seen in:

• Issue #1042 and Discussion #1048 regarding wait-for functionality for vrnetlab containers.
• Issue #1027 on DependencyManager enhancement, where the difference between a container being 'readily configured' versus 'healthy' was brought up, and a redesign to allow the post-deploy phase to run per node was considered.

Current Problem

The wait-for mechanism proceeds with subsequent container startups without ensuring that the prior container has a 'healthy' status. This is inconsistent with the orchestration logic expected by users who are familiar with Docker Compose's health check dependencies.

Expected Behavior

It is anticipated that the wait-for flag would delay the startup of dependent containers until the preceding container is marked 'healthy' by the new health check system.

Steps to Reproduce

1. Implement health checks for container A.
2. Set up container B to include wait-for: A.
3. Start the Containerlab environment.
4. Notice that the initiation of container B is not delayed until container A reaches a 'healthy' state.

Impact

This issue undermines the reliability and predictability of container startup sequences in orchestrated environments, particularly where containers have explicit dependencies on the operational readiness of others.

Suggestion for Resolution

Revising the wait-for functionality to integrate a polling mechanism for health check status could provide a solution. This enhancement should consider the health check implementation details in PR #1426 and the insights from the related issues mentioned above.

Appreciating the team's efforts and looking forward to a collaborative resolution.

[hellt]

done in #1759, thanks @steiler !