UI issues when deploying a stack with name containing uppercase characters

[Craphtex]

Bug description
When deploying a stack via the web UI and setting a name including any character other than lowercase or dash (-) there'll be two stacks displayed in the list of stacks (see Attachment 1).

• Stack 1: Name as specified, Control as specified, Created timestamp appended with "by username", no related containers listed when inspecting (see Attachment 2).
• Stack 2: Name is normalized (lowercase and dashes), Control set to Limited, Created timestamp without appended "by username", all related containers listed when inspecting (see Attachment 3).

Upon stopping and deleting the stack the former will be dangling and labeled as "Inactive", and cannot be removed as it fails with the error message

Failure
open /data/compose/16/stack.env: no such file or directory

Expected behavior
I expected only one stack to be displayed as follows

• Expected stack: Name as specified, Control as specified, Created timestamp appended with "by username", all related containers listed when inspecting.

Portainer Logs
Issue is not related to a specific container.

Steps to reproduce the issue:

1. Go to 'Stacks' on the left hand menu
2. Click on '+ Add stack'
3. Give a name containing an uppercase character
4. Specify any valid compose file
5. Click on 'Deploy the stack'
6. Go to 'Stacks' on the left hand menu
7. Observe the 2 stacks

Technical details:

• Portainer version: 2.6.3
• Docker version (managed by Portainer): Docker version 20.10.8, build 3967b7d / docker-compose version 1.25.5, build 8a1c60f6
• Kubernetes version (managed by Portainer):
• Platform (windows/linux): linux
• Command used to start Portainer: docker-compose up -d with the following docker compose file

version: '3.2'

services:
  agent:
    image: portainer/agent
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /var/lib/docker/volumes:/var/lib/docker/volumes

  portainer:
    image: portainer/portainer-ce
    command: -H tcp://agent:9001 --tlsskipverify
    ports:
      - "9000:9000"
      - "8000:8000"
    volumes:
      - portainer_data:/data

volumes:
  portainer_data:

• Browser: Chrome
• Use Case (delete as appropriate): Using Portainer at Home.
• Have you reviewed our technical documentation and knowledge base? Yes

Additional context

• Attachment 1
• Attachment 2
• Attachment 3

[huib-portainer]

This should be solved by the upcoming release: #5153.

You can give it a try by using the image portainerci/portainer:develop.
Please let us know how that's working for you.
Note that this is a development build and should not be used in a production environment.

Love the amount of detail you've put into this though!

[Craphtex]

Awesome, I'll have a go with the dev build and revert in a day or two with status. 👍
And sorry for missing the previous issue card, I clearly used the wrong search parameters when looking around. 🤦

PS! A detailed bug report is the least I can do, I've tried Portainer on my home server now for a few months and your software absolutely rocks. 🤘

[Craphtex]

@huib-portainer I can confirm that the dev build is preventing the above problem to happen for me, thanks a lot. 👍
(I have to say though, that supporting non-normalized names for the UI would have been a nice feature 😉)

The remaining issue for me will be to clean up the state that Portainer is stuck in from performing the above actions on the older version. Any advice on that would be appreciated, and in worst case I'll dump the Portainer volume and re-setup the Stacks and configs anew. 🙏

[samdulam]

@Craphtex
The version you tested is about to be released very soon (~this week). You should then be able to upgrade when it is released.

[huib-portainer]

the dev build is preventing the above problem to happen for me

Excellent!

supporting non-normalized names for the UI would have been a nice feature

That's a compose limitation though:

docker/compose#541
https://github.com/docker/compose/pull/211/files#diff-2f988147d72e45c2c0c6d48bc6516bbc406719695c4ea56dc776ed87550dc20cL72
microsoft/DockerTools#171
docker/compose#45

And I’m not aware of any spec that’s specifically defining what’s valid.

remaining issue for me will be to clean up the state

To remove the deployed stack, are you able to remove Airflow from the Portainer UI? and then doing a docker stack rm airflow?

[vicbyte]

@huib-portainer
Just for the clarity.
Is the support for uppercase stack names going to be added?
It was working fine in older portainer (2.0.0) and the question is if we now need to go ahead and rename all the stacks to lowercase or if we can wait for the fix.

[huib-portainer]

There are no plans to support uppercase stack names no.
We're following compose, which allows: -_a-z0-9.
More conversation on this topic can be found in #5759.

[Jamby93]

This changes made our testing environment completely broken, as we have a lot of stacks that uses uppercase names. After we updated portainer, any consequent update to any of those stacks inevitably fails, as docker complains about network with conflicting name: deploying via portainer is trying to create a network "astack_default", while network "AStack_default" already exists. We had no choice other than removing every single service on that environment along side with every network that was previously created with an uppercase name. In production we have about 50-100 different swarms which will probably never see an update, as this changes are breaking changes for us, and we can't afford to delete all the services in production.