Using docker-compose scale prevents --x-smart-recreate from skipping service

[lphuberdeau]

Sample set-up

• dispatcher
• worker_a
• worker_b

docker-compose up -d
docker-compose scale worker_b=2

Update code for worker_a, rebuild image (worker_b unaffected)

docker-compose up -d --x-smart-recreate
> sample_dispatcher_1 is up-to-date
> Recreating sample_worker_a_1...
> Recreating sample_worker_b_1...
> Recreating sample_worker_b_2...

Would expect worker_b instances to be left untouched.

[lphuberdeau]

In fact, rebuilding all images, even without modifications, worker_b recreates when scale > 1, but not when scale == 1.

[thunderk]

I have the same problem, it seems to be caused by the container_options['environment']['affinity:container'] changing between scaled containers of the same service, which changes the config_hash that triggers a recreate (in service.py):

if previous_container:
    container_options['environment']['affinity:container'] = ('=' + previous_container.id)

When you scale with 2, the second container is created with an affinity to the first one, so their config_hash diverge.

[aanand]

I think that's a red herring. The config hash is based solely on the image ID and the service config defined in the YAML file, and shouldn't be affected by the affinity variable.

[dnephin]

I think there might be a legit bug here. I was debugging an unrelated issue and I started to see that self.options was being polluted with config-hash when scale is run. Working on a fix.