When using workspaces how to switch safely between them in order to prevent destroying the wrong one.
# terraform workspace select test
# terraform workspace select default // in another terminal, session
# terraform destroy -force
How to specify, define that test workspace will be destroyed and not the default or how to add a param to double check / ensure that the desired workspace will be destroyed, applied etc.
Terraform v0.10.2
# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.
Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.
If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.
What should have happened?
Delete only specified workspace, probably something like this could work:
terraform destroy -force -workspace="name of the workspace"
What actually happened?
no certainty about in what workspace things are happen
Please list the steps required to reproduce the issue, for example:
terraform applyAre there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?
Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:
Hi @nbari! Thanks for this feedback.
In another issue (which, sadly, I wasn't able to find quickly) we discussed the idea of including the workspace name in the confirmation message printed out when destroy is run, which I think would be the best answer here.
Terraform will delete all your managed infrastructure in the workspace "test", as shown above.
There is no undo. Only 'yes' will be accepted to confirm.
>
I notice you're using -force when you invoke terraform destroy, which is itself _always_ unsafe; for safety, you should always use terraform destroy without -force, review the proposed set of changes (which could, in future, include the workspace name) and then decide if the proposed set of deletions is what you want. This interactive prompt is Terraform's primary safety measure.
If you're using -force because you're running in a non-interactive, automated context then it may be preferable to not use terraform workspace select at all and instead to override the workspace just for the single destroy command using the TF_WORKSPACE environment variable:
$ TF_WORKSPACE=test terraform destroy -force
This variable takes precedence over the on-disk setting maintained by terraform workspace select. We do _not_ recommend use of this environment variable as a persistent one set in your shell because it can be easy to forget it's set. However, this environment variable helpful for wrapper scripts and other automation because it's not affected by, as you say, having run terraform workspace select in another terminal.
hi @apparentlymart many thanks, I will give a try to:
$ TF_WORKSPACE=test terraform destroy -force
Indeed I am running this in an automated way, wondering if once the state is created I could run something like:
$ TF_WORKSPACE=test terraform apply
rather the current workspace? Or are there any constraints I should be aware of?
Thanks in advance.
The TF_WORKSPACE variable should work with any command that is workspace-sensitive, including terraform plan and terraform apply.
There are some more general guidelines for running Terraform automation in the guide _Running Terraform in Automation_, which might be helpful to you. In particular, there's some advice in there about how to safely run a separate plan before applying, and also a future-proof way of running terraform apply in a non-interactive environment since in a future release we plan to make it have an interactive confirmation prompt by default, just like terraform destroy does.
Many thanks, closing this for now
I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Most helpful comment
The
TF_WORKSPACEvariable should work with any command that is workspace-sensitive, includingterraform planandterraform apply.There are some more general guidelines for running Terraform automation in the guide _Running Terraform in Automation_, which might be helpful to you. In particular, there's some advice in there about how to safely run a separate plan before applying, and also a future-proof way of running
terraform applyin a non-interactive environment since in a future release we plan to make it have an interactive confirmation prompt by default, just liketerraform destroydoes.