Open Adam-Carr opened 5 months ago
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as not stale anymore due to the recent activity.
Description
This was initially logged in #11460 but only part of it was fixed. The fix applied by #11473 does prevent scale down recreating a container incorrectly, however it didn't solve the issue of the container sorting being wrong when finding which ones need to be removed to scale down.
If I scale up to 2 instances, then scale down to 1, the newest container is the one that's removed instead of the oldest. This causes an issue if you use scale up with no-recreate to deploy the new version of an image, then use scale down to get rid of the old one. Currently the newest gets removed so you're left with the old version of an image running.
The old sort logic before #11473:
The new sort logic after #11473:
The loop following:
So more logic is added to check which containers are obsolete which is great, as well as then going by date created, but the order we remove them in is still wrong. Obsolete/old containers are first in the list, but when looping and scaling down the containers first in the list are treated as valid, we instead get rid of those lower down in the list of containers i believe.
Steps To Reproduce
docker compose up -d --scale (service-name)=2 --no-recreate
, which will launch another container for the same service.docker compose up -d --scale (service-name)=1 --no-recreate
Even if the image used for container 2 is newer, it'll still remove container 2 first, leaving the older image in container 1 running.
Compose Version
Docker Environment
Anything else?
No response