Compose: project-name -p is sanitized, resulting container name difficult to read

[rosskevin]

docker-compose version: 1.4.0

My case is multi-project, multi-environment concurrent CI builds. While I can use labels to find my containers, the output of docker ps is almost jibberish.

For example, my web container started with -p acme_test_333 turns into a container named acmetest333_web_1. Is there a reason that -p is being sanitized with re.sub(r'[^a-z0-9]', '', name.lower())?

[dnephin]

It's mostly for backwards compatibility now. We should be able to relax this restriction when we implement #745

[schmunk42]

I'd still not allow an underscore _ because this separates the stack from the container name.
But if we could use also [-.A-Z] that would be great.

[dnephin]

The only blocker for this is backwards compatibility. If someone has a project name with any non-alphabetic characters in it their project name would change unexpectedly on upgrade.

Some options would be:

• release a version that warns if the project name contains special characters, then in a following version remove the sanitization
• only support these characters if they're set by whatever mechanism we chose for #745

[v01t]

Is there any plans / milestone for this?

[dylanninin]

+1

[ndrewl]

Ok, I understand backward-compatibility issues, and I think we can live without removing the sanitization.

But this is a must have:

release a version that warns if the project name contains special characters

Of course there should be a warning. And a couple of words in the documentation.
I had to spend some time trying to find a good separator that docker-compose would accept, only to find out later that no separators are allowed. It was annoying.

Does someone do something about it? How can I help?

[orodbhen]

Agree with @sawlogs . This is what's known as a "gotcha".

[gimenete]

Why not adding an option --project-name-strict or --no-stanitize-project-name or similar?

The default behavior would be the current behavior to be backwards-compatible. And the opt-in flag would allow to use those characters and prevent the sanitization of the project-name.

[itscaro]

COMPOSE_MODERN=true or COMPOSE_BETA=true to activate all beta-features that will become standards and features thats break backwards compat.

[Mange]

This behavior seems to have changed in 1.21.0. Changelog mentions no longer stripping underscores and dashes.

[ndrewl]

Yes, it was fixed, here: https://github.com/docker/compose/commit/5fe3aff1c310d6b8684404b19a8246736cfe8f1a#diff-a04be36073678de95917341f90c2cf58

[schmunk42]

@shin- @mnottale
I don't understand how changes with such an impact do not have at least two releases with deprecation notices or warnings! Not even this issue is closed or commented.

[shin-]

My mistake, I pulled the trigger a bit too fast on that one.

I've started working on a fix that allows continuity after upgrading in #5896 , which should alleviate most of the problems I've seen mentioned.

At this point I don't think reverting the default behavior or making yet another change is the right approach, as it will only cause further breakage, but we'll be more careful in the future.

[shin-]

I'm going to close this issue as the original request has been addressed, but if you have more thoughts on this feel free to keep the discussion going either here or on #5874

[schmunk42]

Mistakes happen, no big deal.

But just to note this here: If you're relying on directory names for your stacks (somewhere), you might run into trouble when using 1.21, ie. a database started in a directory stacks/db-mysql will start another instance when using docker-compose up -d :bomb: Not the thing you want when using ie. host-volumes for a db :boom:

Related in this context: https://github.com/docker/compose/issues/745

[emalihin]

1.21.0 will also break some Jenkins jobs where -p flag is not provided and dir name is used for project name. Workspace (dir) names formed by Jenkins can sometimes start with a _ or -, due to how Jenkins trims their names from the beginning ("super-project-name/branch" => "-project-name-branch-randomlonghash").

Including -p becomes necessary in such case.

[jamiejackson]

So what is the behavior now supposed to be?

I've started working on a fix that allows continuity after upgrading in #5896 , which should alleviate most of the problems I've seen mentioned. ( @shin- )

What's the behavior of the fix? I'm left with a confusing hodgepodge of conventions. I don't know what's legacy and what's modern:

$ docker network ls
NETWORK ID          NAME                            DRIVER              SCOPE
3200e47a1d1a        bridge                          bridge              local
420115ef8c4a        host                            host                local
2e8693f6a399        myprojectstage_elastic_fess          bridge              local
9a92cc69c094        myprojectstage_elastic_kibana        bridge              local
36d82087ad03        myprojectstage_lucee_db_solr         bridge              local
9ed9c0021f39        myprojectstage_lucee_elasticsearch   bridge              local
90e76a520123        myprojectstage_lucee_mail            bridge              local
1451c247e76d        myprojectstage_lucee_web             bridge              local
85562e5eb738        myprojectstage_web_fess              bridge              local
72c973189ec5        none                            null                local
$ docker volume ls
DRIVER              VOLUME NAME
local               myproject_stage_lucee-fusionreactor-logs
local               myproject_stage_lucee-logs
local               myproject_stage_lucee-remote-client
local               myproject_stage_lucee-tomcat-logs
local               myprojectstage_es_data
local               myprojectstage_httpd-logs
local               myprojectstage_solr_data
local               myprojectstage_solr_logs
$ docker ps
CONTAINER ID        IMAGE                          COMMAND                  CREATED             STATUS              PORTS                                            NAMES
2d3dd4a2533f        myproject_stage_lucee               "docker-entrypoint.sh"   41 minutes ago      Up 41 minutes       8080/tcp, 0.0.0.0:8088->8088/tcp                 lucee
b5d8b6e88c04        myproject_stage_fess                "/bin/bash bin/fess-…"   41 minutes ago      Up 41 minutes       0.0.0.0:8082->8080/tcp                           fess
b26cd11eff87        myproject_stage_kibana              "/docker-entrypoint.…"   41 minutes ago      Up 41 minutes       0.0.0.0:5601->5601/tcp                           kibana
53ddfebfecaa        local/solr-dih-mariadb:6.6.3   "docker-entrypoint.s…"   42 minutes ago      Up 41 minutes       0.0.0.0:8980->8983/tcp                           solr
b3ae3faac9f4        myproject_stage_elasticsearch       "/bin/bash bin/es-do…"   42 minutes ago      Up 41 minutes       0.0.0.0:9200->9200/tcp, 0.0.0.0:9300->9300/tcp   elasticsearch
ce4425d70cc8        myproject_stage_web                 "httpd-foreground"       42 minutes ago      Up 41 minutes       0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp         web