compose: Update to docker-compose version 1.21 breaks certain deployments

Description of the issue

docker-compose version 1.21.0 is not able to handle com.docker.compose.project labels set with an older version of docker-compose that contain - or _ in their container names.

Our deployment does the following:

// pull new images
$ docker-compose pull
// stop old containers
$ docker-compose rm -s -f
// replace docker-compose.yml
// start new containers
$ docker-compose up -d

Context

docker-compose version 1.21.0, build 5920eb0

Docker version 18.03.0-ce, build 0520e24

Steps to reproduce the issue

Deploy some containers with - or _ in their container names with docker-compose version 1.20
Change docker-compose to version 1.21
Try to restart the containers

Observed result

docker-compose does not recognize containers deployed with an older version. It fails to stop already deployed containers and fails to start the new containers afterwards.

Expected result

docker-compose recognizes containers deployed with an old version and transparently rewrites existing com.docker.compose.project labels to the new format.

Stacktrace / full error message

$ docker-compose rm -s -f
No stopped containers
$ sudo -E docker-compose up -d
Creating container-name ... 

Creating container-name ... error

ERROR: for container-name  Cannot create container for service container-name: Conflict. The container name "/container-name" is already in use by container "e7dfd157fed12251ed21a70f8243d87baa6fb1e2768e872875c101d37cf99891". You have to remove (or rename) that container to be able to reuse that name.

Additional information

This issue was introduced with #5844 at https://github.com/docker/compose/blob/9cc30ad0e940453228d6d968e4827cae34eda770/compose/cli/command.py

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 3
Comments: 23

Most upvoted comments

@shin- Totally agree with that, but conventions shouldn’t be broken in a minor release, even without any kind of warning or announcement.

Since you don’t intend to revert the change, I’d suggest adding a warning/announcement somewhere, at least.

cpfeiffer on May 24, 2018

@shin- This change of behavior deserves a major version bump.

Picture this real-world scenario:

I tell power-users, “run this using docker-compose up”
Power users do so with docker-compose 1.20
Other power users do so with docker-compose 1.21
“Oh, no!” I say … and I fix my command, docker-compose up --project-name myprojectwithoutdashes

Now some users have volumes with the wrong name. And I have scripts that use raw docker commands that expect a certain project name. So whom should suffer after I recover from this undocumented change: the users from step 2, or the users from step 3?

My suggestion: mark 1.21 a “bad” release and publish a 1.22 that undoes the change to minimize the damage. Save this (very welcome) change for docker-compose 2.0.

adamhooper on May 17, 2018

I’m pretty sure there are many people still using versions < 1.21. At some point they are going to upgrade and suffer from the breakage, so reverting the breaking change would save them the hassle.

Additionally, since docker volumes cannot be renamed people are scripting around docker and compose, using the well-known docker-compose naming conventions. All these scripts and configurations are being broken.

cpfeiffer on May 23, 2018

It also affects using options like ipc for sharing IPC namespaces. This naming change should be reverted.

ryanolson on Apr 22, 2018

That happened to me. I was running an older docker-compose version that didn’t have hyphens. I have some services that were created and started before hyphens in names were a thing.

Now docker-compose ps etc do not work with those services anymore because it’s looking for my-project_service_# names instead of the existing myproject_service_#.

And new projects are broken too. If I start a new project that didn’t exist before updating to 1.21.2 with docker-compose up, it will still name without hyphens, and every docker-compose command is broken.

This happens with 1.21.2

For anyone with this issue, the only solution is to go back to 1.20.1 (the last version before the breaking change):

$ which docker-compose # to see where it's installed
$ sudo rm $(which docker-compose)
$ sudo curl -L https://github.com/docker/compose/releases/download/1.20.1/docker-compose-Linux-x86_64 -o /usr/local/bin/docker-compose # or wherever your previous docker-compose was
$ sudo chmod +x /usr/local/bin/docker-compose # or wherever you put it
$ sudo docker-compose --version
docker-compose version 1.20.1, build 5d8c71b

coaxial on May 29, 2018