Changing stack name doesn't also change secrets on undeploy/deploy #405

Open
opened 2023-02-10 14:52:03 +00:00 by decentral1se · 1 comment
Owner

You deploy foo_example_com. You generate secrets. Later, you rename to example_com. via hacking the DOMAIN=... or simply renaming the .env file. All the secrets still have foo_example_com in their naming. We can't retrieve the secrets, so delete/re-create wouldn't work? Could abra do some sort of duplication of secrets to help this scenario?

You deploy foo_example_com. You generate secrets. Later, you rename to `example_com`. via hacking the `DOMAIN=...` or simply renaming the `.env` file. All the secrets still have `foo_example_com` in their naming. We can't retrieve the secrets, so delete/re-create wouldn't work? Could `abra` do some sort of duplication of secrets to help this scenario?
decentral1se added the
enhancement
label 2023-02-10 14:52:03 +00:00
Owner

To me abra app rename would be the answer, then we strongly recommend against manually renaming the .env file or setting STACK_NAME.

rename knows both the old and the new name (as CLI args) so it should be chill to copy over the data.

To me `abra app rename` would be the answer, then we strongly recommend against manually renaming the `.env` file or setting `STACK_NAME`. `rename` knows both the old and the new name (as CLI args) so it should be chill to copy over the data.
decentral1se added the
abra
label 2023-02-14 07:22:53 +00:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/organising#405
No description provided.