`up` command link dependencies seem reversed when restarting

[dcosson]

I've wondered about this for a while and haven't been able to find an explanation. If I have a simple docker-compose.yml file that looks like the following:

foo:
  image: ubuntu:precise
  command: sleep 3600
  links:
    - bar
bar:
  image: ubuntu:precise
  command: sleep 3600
  expose: 
    - 8000

If they are both already running and then I restart foo with docker-compose up -d foo, it will recreate foo & bar. If I do docker-compose up -d bar it will recreate just bar.

This seems like the opposite behavior of what I'd expect. If I restart bar, it might be at a different IP address (or different port if I have edited the exposed port), so foo should also be restarted since the linked env variables like $BAR_PORT might now be wrong. If I restart foo, presumably bar is still running fine so why do I need to wait for it to restart before foo restarts?

Is this behavior intentional? I might just be missing something

[rws-github]

When I try to stop, rm, and up a single service in my environment, it recreates everything. I would like it to not touch anything else. Recreating the entire collection of services is not ideal when you are developing a single service.

[dcosson]

Right. I think my description was confusingly generic, a more concrete example is a setup of 3 containers: web server -> app server -> database. If I restart app server, it may be at a new IP so web server needs to be restarted, but database does not. The current behavior is to restart database but not web server. Similarly, if I restart web server then nothing else needs to be restarted but the current behavior is to restart both of the other containers, which gets tedious in a dev environment.

@rws-github you can use the --no-recreate flag to not recreate anything. But in my example, if I restart app server with --no-recreate the setup will be broken because web server will now probably be sending traffic to the wrong place.

[aanand]

@rws-github You can use docker-compose up --no-deps SERVICE to stop Compose from automatically recreating dependencies.

@dcosson I agree that the current behaviour is confusing. It stems from the expectation of docker-compose up foo to mean "spin up foo and anything else it depends on", but it's reasonable to expect the flow of triggered actions to go in the other direction, for the reasons you've laid out.

Two things are happening that'll make this less of an issue:

1. The --x-smart-recreate flag in Compose 1.3 tells it to only recreate containers for services whose configuration or image tag has changed. This will eventually become the default behaviour.
2. Links are being deprecated in favour of networks - see WIP: Docker networking support #1676 - which will both reduce the number of hard dependencies between services and make them resilient to containers being recreated.

[dcosson]

Cool, thanks for responding. Looking forward to the network change, seems like a more robust way to do links and it'll solve this issue.