Closed nathanagood closed 4 years ago
See related issue #15
A bit duplicate of #18 (more or less). Closing #18 and moving here.
Should the remote (S3) behavior be preserved? Should there be an optional flag or something (eg., "--use-s3-backend") that when set would use the existing behavior but the default will simply be the local backend?
The plan we discussed was to not create any kind of TF backend for you, but to allow the end-user to configure their own backend in dce.yml
eg, something like:
terraform:
backend:
type: s3
bucket: my-state-bucket
key: terraform.tfstate
Should the remote (S3) behavior be preserved
Also note that the s3 backend never actually worked -- it would create a new backend and tfstate file with every call to dce system deploy
.
The plan we discussed was to not create any kind of TF backend for you, but to allow the end-user to configure their own backend in dce.yml
eg, something like:
terraform: backend: type: s3 bucket: my-state-bucket key: terraform.tfstate
OK. I re-opened #15 to handle the second part of this problem. This issue is specifically addressing not creating any kind of TF backend for you.
Using a local terraform backend is currently now the default behavior for the dce system deploy
command, and technically the only supported behavior until #54 is pushed out (which is my next priority). The backend file is created in ~/.dce/.cache/module/main.tf
.
Is your feature request related to a problem? Please describe.
If I am using the CLI, I may not want to keep TF state in a S3 bucket.
Describe the solution you'd like
By default, the CLI will use a TF local state file for the backend configuration.
Describe alternatives you've considered
Additional context