Compose: [question] detecting resources using "legacy" naming convetion

Created on 3 May 2018  Â·  3Comments  Â·  Source: docker/compose

In 1.21.0, we introduced a change to how project names are sanitized for
internal use in resource names. This caused issues when manipulating an
existing, deployed application whose name had changed as a result.
This release properly detects resources using "legacy" naming conventions.

How does exactly compose detect resources using legacy naming conventions?

arecli kinenhancement kinquestion

Most helpful comment

Oh, I see - yeah, some commands (like ps) will not work properly until you run docker-compose up again.

I'll try and fix it in the next release.

All 3 comments

The legacy compatibility does not seems to be working for me.

user@host:/repo/codex-backend-full# docker-compose ps api
Name   Command   State   Ports
------------------------------
user@host:/repo/codex-backend-full# docker-compose-1.19.0 ps api
         Name                       Command               State    Ports
------------------------------------------------------------------------
codexbackendfull_api_1   bash -c echo updating pip  ...   Exit 1        
user@host:/repo/codex-backend-full# docker ps -a | grep codexbackendfull_api_1
feac585699b0        codexgigassys/codex-backend-full:latest         "bash -c 'echo updat…"   8 weeks ago         Exited (1) 25 minutes ago                                          codexbackendfull_api_1
user@host:/repo/codex-backend-full# docker inspect codexbackendfull_api_1 | grep compose
                "com.docker.compose.config-hash": "8637bb20a90a1d924fe4591711d2b8b855122590fdfa5eaba419348bae3d5189",
                "com.docker.compose.container-number": "1",
                "com.docker.compose.oneoff": "False",
                "com.docker.compose.project": "codexbackendfull",
                "com.docker.compose.service": "api",
                "com.docker.compose.version": "1.18.0"
user@host:/repo/codex-backend-full# docker-compose --version
docker-compose version 1.21.2, build a133471
user@host:/repo/codex-backend-full# docker-compose-1.19.0 --version
docker-compose version 1.19.0, build 9e633ef

Renaming does not fix the issue.

user@host:/repo/codex-backend-full# docker rename codexbackendfull_api_1 codex-backend-full_api_1
user@host:/repo/codex-backend-full# docker-compose ps api
Name   Command   State   Ports
------------------------------
user@host:/repo/codex-backend-full# docker rename codex-backend-full_api_1 codexbackendfull_api_1

But deleting the container with the old compose and recreating the container with the new does fix the issue.

user@host:/repo/codex-backend-full# docker-compose-1.19.0 rm api
Going to remove codexbackendfull_api_1
Are you sure? [yN] y
Removing codexbackendfull_api_1 ... done
user@host:/repo/codex-backend-full# docker-compose up -d --no-recreate api
Starting codexbackendfull_elasticsearch_1 ... done
Starting codexbackendfull_syslog_1        ... done
Starting codexbackendfull_db_1            ... done
Starting codexbackendfull_httpd_1         ... done
Creating codex-backend-full_api_1         ... done
user@host:/repo/codex-backend-full# docker-compose ps
          Name                        Command               State           Ports
------------------------------------------------------------------------------------------
codex-backend-full_api_1   bash -c echo updating pip  ...   Up      0.0.0.0:4500->8080/tcp
user@host:/repo/codex-backend-full# 

Oh, I see - yeah, some commands (like ps) will not work properly until you run docker-compose up again.

I'll try and fix it in the next release.

Was this page helpful?
0 / 5 - 0 ratings