In Atmos v1.55 (PR #515) we switched to using the While Atmos is a powerful tool and for some there is a desire to make Atmos fully capable of replacing the The issue of selecting a Terraform "workspace" highlights the kind of difficulty one runs into when designing a solution where Atmos and Terraform can work side by side. Terraform has the concept of, for each component, a "current workspace", which is a segregated Terraform state. Cloud Posse uses a different workspace for each deployment of a component (account and region and, where the component is deployed multiple times in the same account and region, each separate deployment).
The problem with a workspace selection is that it is stateful, modal, and mostly hidden. When you run a with the environment variable taking precedence.
To further complicate matters, if you run Whichever mechanism you choose, you are setting some kind of persistent state which affects what Prior to Atmos version 1.55, its behavior was that if it ran any Terraform command that applied to a specific workspace (anything other than As of Atmos 1.55, Atmos changed how it selects a workspace. It started using the environment variable So in summary, the change made using In the long run, we are seeking ways to make these kinds of behaviors optional and easier to choose. For now, we are just reverting to the "tried-and-true" behavior to avoid further surprises.
TF_WORKSPACE environment variable for selecting Terraform workspaces when issuing Terraform commands. This had the unintended consequence that the workspace was no longer being set for use outside of Atmos as a side effect. This version reverses that change, once again setting the workspace via terraform workspace select so that it remains selected after Atmos finishes. Expand the details below for an extended explanation.
Use `terraform workspace select` to select workspace @Nuru (#580)
what
terraform workspace select to select the workspace when needed
terraform workspace new when select returns with exit code 1; report any other kind of error
why
terraform commands outside of Atmos
atmos terraform shell from having issues running terraform workspace commands or having the workspace remain selected after changing directories
discussion
terraform CLI entirely, we are not there yet. For now, there is a need to be able to use terraform alongside with atmos in some edge cases. Also, for some, there is a desire to bypass some of Atmos' overhead when running repeated tasks (especially failing tasks) by invoking terraform commands directly.
terraform command, the component it applies to is determined by the current working directory (one form of mode/state), and the workspace it uses is determined by either:
terraform workspace select in that directory
TF_WORKSPACE
terraform workspace select foo and the workspace foo has not been created, you get an error. Likewise, if you run TF_WORKSPACE=foo terraform init -reconfigure and the workspace foo does not exist, you get an error. But if you run TF_WORKSPACE=foo terraform plan and the workspace foo does not exist, it will silently and automatically be created for you (so beware of typos).
terraform commands affect, and it becomes easy to get lost as to what you are actually working on. Atmos handles this by always setting the state for its Terraform commands, which is admirable, and it can be more helpful to people using terraform directly if it helps those users manage this hidden state effectively.
init), it selected the workspace, creating it if needed, and left the workspace selected. This means that if you working in the component directory, then any terraform commands like terraform state show would work on the component in the workspace of the stack you most recently used for that component. After running atmos terraform plan <component> -s <stack>, you could do everything else using plain Terraform commands if you wanted to (the only trick being that, for some commands, you would need to supply the -var-file that Atmos generated). While many users would never do things this way, in some use cases it can be particularly time saving. For example, you may want to run the same set of Terraform commands repeatedly on the same component, using different stacks, as can happen when migrating a component to a new version requires some manual steps.
TF_WORKSPACE instead of terraform workspace select. While this works for Atmos, it changes the behavior for running the bare terraform commands. No longer did Atmos set the workspace for you, nor would atmos terraform workspace <component> -s <stack> set the workspace for you, either. In fact, there was no longer any direct way to find out the correct workspace name to use. Your plain terraform commands worked on the default workspace, or whatever one was selected the last time you used an old version of Atmos.
terraform harder to use, without appreciably making atmos easier to use. The change did eliminate a bug that was causing problems, and the consequences were not obvious (nor universally considered negative), so it was made. This PR fixes the bug a different way and restores the behavior of v1.54 and earlier.
references