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

New Issue

decentral1se · 2023-02-10T14:52:03Z

decentral1se commented

2023-02-10 14:52:03 +00:00

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

3wordchant commented

2023-02-10 16:01:20 +00:00

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

codegod100 referenced this issue

2023-02-15 02:56:16 +00:00

add a docker system prune with configurable options to undeploy step of lifecycle #417

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/organising#405