Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove unnecessary links to xdock test_driver #507
changed the title from
xdock remove unnecessary links to test_driver
Remove unnecessary links to xdock test_driver
Nov 2, 2017
Nov 2, 2017
I am not sure what you mean exactly? Depends_on just ensure that certain container starts before something so for instance DNS resolution will work. it also ensures that
What didn't work? I noticed that there are problems with java xdock, UDP sender sometimes fails to resolve agent's name.
What I mean is that, for example, crossdock driver pings the health endpoint of all services participating in the test until they respond with 200, and it keeps logging the attempts until it succeeds on all of them or times out. Using dependencies in the compose achieves a similar result, to a certain degree, but if something gets stuck do we have any logs about who's waiting on whom?
Also, starting the container is not the same as having that container being ready to service requests. E.g. the cassandra-schema container depends on cassandra, but internally loops until cassandra is actually available. While it loops, it itself is already "running" so the other containers that depend on it in compose will be started (like the collector), even though the underlying storage may still be unavailable.
I am not saying what you have here is not an improvement, I just wonder if we can use compose even more to actually manage dependencies with readiness, not just "process started".
Orchestrator does not wait it just executes or fails if the dependency does not exist.
I see what you mean. Right now we let jaeger-services fail and wait for the restart (also in k8s). It's not the most efficient solution but it works and we don't have to pollute the code with retries and checks. Here are some tips how we could deal with it https://docs.docker.com/compose/startup-order/.
@jpkrohling do you have some recommendations? My first impression is that it's better to keep things clean and just use restart.
I'm not familiar with Docker Compose, but in general, having the test infra assess the readiness of the components under test would make sense to me. Letting things fail/restart is how we do for Kubernetes, but the ideal is to have services not to fail unless they really need to. For instance, the collector could not mark itself ready while a Cassandra connection isn't available, with a hard failure after a timeout of 1 minute (like the create-schema image).