New project name psql role doesn't exist

[ericshively]

Thanks for this great setup guide! I was able to successfully change project names on an older build around the Django 4 update. However on the latest, I can ./run manage migrate on the default name, but if I change project names, docker-compose up --build, then I run into a problem doing ./run manage migrate.

From Docker logs: postgres_1 | 2022-01-11 21:42:09.081 UTC [33] FATAL: password authentication failed for user "new_project" postgres_1 | 2022-01-11 21:42:09.081 UTC [33] DETAIL: Role "new_project" does not exist.

From shell stdout: django.db.utils.OperationalError: FATAL: password authentication failed for user "new_project"

My .env has the: export POSTGRES_USER=new_project export POSTGRES_PASSWORD=password

[nickjj]

Hi,

What happens if you run a docker-compose down -v? That will completely wipe out your old DB and Postgres will make a new one with a new user / password based on your current .env.

If you ever change your DB user or password you need to either blow out your old DB (useful in dev) or run raw SQL commands to update the user's password (useful in prod). This is the same workflow with or without using Docker, it's just Docker is convenient because if it doesn't detect an existing volume it'll make a new DB user / pass for you by default based on the values in your .env, however changing those values won't update the credentials in an existing volume.

[ericshively]

Thank you, that worked and your explanation was very helpful! Yep, I forgot I must have had the original volumes with 'hello' username running the whole time. I was confused why even nuking the repo and going straight to renaming still wasn't working.

Am I missing something I did incorrectly? Wouldn't other new users also run into this issue after renaming and needing to destroy the old volumes (with the guide adding -v) or run SQL commands?

[nickjj]

The rename script should technically rename export COMPOSE_PROJECT_NAME=hellodjango in your .env file. This namespaces your volumes and other resources that Docker Compose creates.

If you use a different project name you should get a fresh volume (similar effect to docker-compose down -v) since you're starting from ground zero and wouldn't need to explicitly run any commands or change the user / pass.

Now I'm wondering how you got into this quagmire. Did you clone this, up it, play around, rename the project, up it, change your POSTGRES_USER or POSTGRES_PASS to something else? If so it's the last step that got you. If not, what did you do exactly?

[ericshively]

Oh, starting from scratch again, I see now that docker-compose down -v is in the rename script. Remembering more clearly, the problem first arose after a successful rename, when I nuked the repo, forgot to dc down the docker containers+volumes, but only killed the containers manually. I must have left the volumes up, but always 1-to-1 dc up / dc down, so it wasn't until there was a second dc down (during having a 'hello' username) that finally the old volumes were removed rather than the ones I had recently created? So essentially I always had an extra set of 'hello' volumes until I did a second dc down like you asked.

In that case, your instructions are correct, maybe just needs a note to make sure the relevant volumes are completely gone if a user runs into this issue.

Only relevant logs I have from the past indicating psql wasn't working is: postgres_1 | postgres_1 | PostgreSQL Database directory appears to contain a database; Skipping initialization postgres_1 |

[nickjj]

If the COMPOSE_PROJECT_NAME changes I think technically it should work even if -v wasn't included in the rename script. Although it sounds like maybe not based on what you wrote tho?

Your log output is expected if you up a project that already has a volume for Postgres. It skips creating a new db, user and password if it detects one. It sounds like you know that, but just including that here in case someone reads this in the future.