One-click apps destructive behaviour with volumes if they happen to have the same name

[sergioisidoro]

What is the problem?

I had one app called wiki running. I happened to create another app called wiki with a different one click app.

• One of the one click-apps creates the service $$cap_appname and the volume $$cap_appname-db-data

• The other creates the service $$cap_appname-outline and the volume $$cap_appname-db-data

As you can see, although these one click apps have the same app name, they do not create a service with the same name, so the deployment goes ahead. However they have the same volume name.

This means that these apps have destructive behaviour because they share the same volumes. There is not going to be any warning because there is no service with the same name. I almost lost all the data from the first app's volume.

PROPOSED SOLUTION Each one click app should at least have one service called $$cap_appname to prevent these issues. This will use the current validations (unique service name) and prevent the same $$cap_appname to be created, and ensure $$cap_appname is unique

Steps to reproduce the problem:

• Deploy a wiki.js called wiki with one click app
• Deploy a Outline called wiki with one click app

[githubsaturn]

Yes, it's better for apps to have distinguished names. We should add app name specific suffix to the volumes to avoid this.

[sergioisidoro]

@githubsaturn Sorry, I corrected a mistake on my description of the proposed solution.

Unfortunately adding the app name suffix to the volumes is not enough, and would still result in the same issue. Unless, of course, there is validation of app name uniqueness like you mentioned.

[githubsaturn]

This is even trickier than that. Having the same volume is not always bad, sometimes it's intentional.

One thing that would help is to edit the volume names to include the template ID. That way, if you pick a name like wiki for a wikijs app and an outline app. The volumes will be wiki-outline-db and wiki-wikijs-db

[sergioisidoro]

Yeah, I'm using shared volumes in some cases, but in those cases I manually configure the volumes to be shared.

One thing that would help is to edit the volume names to include the template ID.

I think this is perfect. Let me know if I can help. I'm don't do much typescript, but if you point me in the right direction I might be able to help out

[githubsaturn]

It's not something that we have to do in the code. We just need to write a script that:

• Iterates through all apps.yml files here: https://github.com/caprover/one-click-apps/tree/master/public/v4/apps
• Reads the volumes section of each app
• And ensures that it has a -{templateID} suffix

[sergioisidoro]

@githubsaturn I was wondering if it should be some sort of validation logic for the apps.yml files, and not just a one time thing. Either in the code, or as a validation in the linter / ci . Are you suggesting the last option? Shouldn't it be both? (I don't know how the internals work, so I have no idea...)

[githubsaturn]

Yes, in can come in two steps:

• First, ensuring that all existing apps have the proper suffix
• Second, running the validation on the linter to ensure that we won't introduce issues in future.