-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
run
links containers that are not dependencies
#9459
Comments
I ran I'm able to produce the issue on this branch but not on the parent it was originally merged into & also skimming the code, it does seem related to dependency management. Unfortunately I'm not familiar enough with docker-compose & go to make much more progress on this. @arhemd, I think you were the original author of this patch. Does this change in behavior seem familiar to you at all? Thank you! |
Is anyone able to look at this? |
This issue should be fixed with latest release, by db69856 Please give 2.5.0 a try to confirm |
Hi @ndeloof! Thanks for taking a look at this - I am still able to reproduce this issue in 2.5.0 using the compose file shown above & the commands there:
When I do |
ok thanks, I'll test this tomorrow |
Thanks to Michael's excellent detective work, I was able to resolve this by removing every dependency in our docker-compose file, which is obviously not ideal and a very temporary workaround. The rest of our team is locked into Docker for mac v4.5 which bundles the older version of docker-compose before this bug was introduced. Our kryptonite was a shared dependency to mongo and redis which went up the dependency tree and exploded into all of the services listed in our docker compose starting at once and crashing
|
Hi @ndeloof! I noticed that v2.6.0 was just released and so I reran my tests and confirmed that this issue is still present in that version. Would an option be to revert the patch that seems to have introduced this behavior (9d73cc8)? Not sure if a revert would be easy to apply at this point or if it's okay to remove behavior like that. I could attempt to apply this and open up a PR if you think that's appropriate. |
Thanks @ndeloof and @laurazard for the work to fix this! It will make such a big impact for our teams 🎉 Do you have a sense of when a new version will be release that includes this great change? |
Description
Hi there! Starting in compose version 2.3.0, the
run
command is bringing up linked containers that are not strict dependencies of the service that is being started. This behavior only happens if I have previously usedup
with one of the unrelated services.I don't see anything that's jumping out to me in the changelog that would cause this & I don't see any updates to the docs suggesting that the behavior of these has changed, which makes me think this is a bug. Is this new behavior intentional though?
Steps to reproduce the issue:
I can demonstrate this issue with a toy compose definition:
Describe the results you received:
If I just execute
run service_a
, compose will start theshared_dep
container and theservice_a
container as expected:However, an docker version 2.3.0 and above if I (1) execute
up service_b
and then (2) executerun service_a
, I see the unrelatedservice_b
also get launched:Describe the results you expected:
I would not expect
run service_a
to ever launch theservice_b
container, since they have no dependencies against one anotherAdditional information you deem important (e.g. issue happens only occasionally):
I have confirmed that this behavior was not present in compose 2.2.3:
I do see the bug in the 2.3.0 release however:
Output of
docker compose version
:Output of
docker info
:Thanks so much for any help that ya'll can offer!
The text was updated successfully, but these errors were encountered: