testcontainers/testcontainers-python

Bug: [minio] _healthcheck calls for nested wait_container_is_ready resulting in long wait time

sushi30 opened this issue · 5 comments

Describe the bug

MinioContainer._healthcheck is decorated with wait_container_is_ready and calls get_exposed_port which is also decorated wait_container_is_ready. This results in a default wait time of 120*120=14400 seconds...

As a workaround I set the testcontainers_config.max_tries manually:

import pytest
from testcontainers.core.config import testcontainers_config

@pytest.fixture(scope="session", autouse=True)
def config_testcontatiners():
    testcontainers_config.max_tries = 10

if this workaround works, it means the container is coming up successfully but the healthcheck is reporting a false negative result. this means the healthcheck for minio is broken. can you confirm which os/arch/python/docker/tc you're using?

this script takes about 2 seconds to run on my mac (m1/3.12/tc runtime/4.5.0):

python -m venv .venv && . .venv/bin/activate
pip install testcontainers[minio]
from testcontainers.minio import *

with MinioContainer() as m:
    client = Minio(
      f"localhost:{m.get_exposed_port(9000)}",
      access_key="minioadmin",
      secret_key="minioadmin",
      secure=False
    )

    client.make_bucket("abc")
    print(client.list_buckets())
run output
(.venv) $ time python script.py
using host tcp://127.0.0.1:57980
WARNING:root:DOCKER_AUTH_CONFIG is experimental, see testcontainers/testcontainers-python#566
using host tcp://127.0.0.1:57980
INFO:testcontainers.core.docker_client:using host tcp://127.0.0.1:57980
Pulling image testcontainers/ryuk:0.7.0
INFO:testcontainers.core.container:Pulling image testcontainers/ryuk:0.7.0
Container started: 22927a92f547
INFO:testcontainers.core.container:Container started: 22927a92f547
Waiting for container <Container: 22927a92f547> with image testcontainers/ryuk:0.7.0 to be ready ...
INFO:testcontainers.core.waiting_utils:Waiting for container <Container: 22927a92f547> with image testcontainers/ryuk:0.7.0 to be ready ...
Pulling image minio/minio:RELEASE.2022-12-02T19-19-22Z
INFO:testcontainers.core.container:Pulling image minio/minio:RELEASE.2022-12-02T19-19-22Z
Container started: 580c1203767b
INFO:testcontainers.core.container:Container started: 580c1203767b
Waiting for container <Container: 580c1203767b> with image minio/minio:RELEASE.2022-12-02T19-19-22Z to be ready ...
INFO:testcontainers.core.waiting_utils:Waiting for container <Container: 580c1203767b> with image minio/minio:RELEASE.2022-12-02T19-19-22Z to be ready ...
Waiting for container <Container: 580c1203767b> with image minio/minio:RELEASE.2022-12-02T19-19-22Z to be ready ...
INFO:testcontainers.core.waiting_utils:Waiting for container <Container: 580c1203767b> with image minio/minio:RELEASE.2022-12-02T19-19-22Z to be ready ...
Waiting for container <Container: 580c1203767b> with image minio/minio:RELEASE.2022-12-02T19-19-22Z to be ready ...
INFO:testcontainers.core.waiting_utils:Waiting for container <Container: 580c1203767b> with image minio/minio:RELEASE.2022-12-02T19-19-22Z to be ready ...
[Bucket('abc')]

real	0m1.855s
user	0m0.258s
sys	0m0.054s

I can confirm this issue is with elasticsearch too.. Just but a debugger in waiting_utils and you'll the nested calls:
image

the nested calls are fine - you do need to wait for all of that before getting mapped ports

but shouldn't the total timeout be 120 seconds? the nested calls should have awareness of how much time passed since the container was started.

that could be improved, i agree, but in general it doesn't introduce new errors