Allow parallel deploys of same component across different root stacks and tfstate buckets

[nitrocode]

Have a question? Please checkout our Slack Community or visit our Slack Archive.

Describe the Feature

Allow parallel deploys of same component across different root stacks

Terragrunt, for example, will copy the terraform into a separate temporary directory for each terragrunt run.

For example, if we ran these 3 commands today at the same time locally, we'd have different terraform runs trying to save state into the backend that was last initialized which can be devastating.

atmos terraform eks --stack tenant-use2-dev
atmos terraform eks --stack tenant-use2-staging
atmos terraform eks --stack tenant-use2-prod

If each run created its own separate terraform data directory then these files would not have conflicting backends.

https://developer.hashicorp.com/terraform/cli/config/environment-variables#tf_data_dir https://support.hashicorp.com/hc/en-us/articles/360043550953-Selecting-a-workspace-when-running-Terraform-in-automation

e.g.

# atmos terraform eks --stack tenant-use2-dev
# TF_DATA_DIR=.terraform-tenant-use2-dev
# the `environment` file would contain the workspace `tenant-use2-dev`
components/terraform/eks/.terraform-tenant-use2-dev/environment
# atmos terraform eks --stack tenant-use2-staging
# TF_DATA_DIR=.terraform-tenant-use2-staging
# the `environment` file would contain the workspace `tenant-use2-staging`
components/terraform/eks/.terraform-tenant-use2-staging/environment
# etc

Expected Behavior

Separate terraform namespace per run like terragrunt

Use Case

See above

Describe Ideal Solution

Match terragrunt

The above description may not be the exact way terragrunt does it but it would be good to see how they do it in order to match it since they have implemented it a while back so it should be a relatively stable spec.

Alternatives Considered

Run commands linearly

or

use atmos workflows to run linearly

or

run in spacelift

Additional Context

N/A

[aknysh]

this could be implemented using TF_DATA_DIR but with a flag (e.g. in atmos.yaml) to enable/disable the feature

[nitrocode]

Yes! This is what I was mentioning in slack the other day. I updated the ticket with this info too. If the TF_DATA_DIR is set to the root stack, then we can do it.

cc @jamengual

[osterman]

I think we should support this, with the option of TF_DATA_DIR matching the workspace the way we disambiguate it in the S3 state backend.

Similarly, I think we should add a parallel step in the workflows, to support running multiple steps in parallel. Of course, that would depend on this TF_DATA_DIR functionality being implemented first.