Migrating: how to ensure that you don't run terraform instead of tofu or vice versa?

[fredrikjwip]

We've started to migrate some configurations from Terraform to Opentofu, and it mostly just works. Thanks everyone!

Now, it will take us some time to migrate and redeploy all our Terraform configurations to Opentofu. For the period until that migration is completed, where we use Opentofu for some configurations and Terraform for others, I wish to ensure that I don't by mistake use the wrong tool somewhere. E.g use Opentofu for a Terraform configuration, or vice versa.

Is there any support in the language to validate and assert which client is used to execute the current configuration?

I'm aware of required_providers { required_version ... } but it is implementation independent. Any other options?

[ghost]

As of OpenTofu 1.8 you will be able to rename your .tf files to .tofu, which will only work with OpenTofu. Unfortunately, I know of no way to verify the reverse (only Terraform).

[RLRabinowitz]

While currently there's no native option that'll allow you to easily tell whether your current configuration is of OpenTofu or Terraform, there are some possible workarounds, that are not full proof

• You could take a look at the providers in the state (or using a tofu providers command), to see if the providers are of the OpenTofu Registry or of the Terraform Registry. This is not full proof, as there are cases where you might still be using the Terraform Registry in OpenTofu or vise-versa (when it is defined explicitly in the configuration, or when migrating before applying the configuration)
• If you have a .terraform.lock.hcl file, it should start with a comment # This file is maintained automatically by "tofu init".. This should give you a hint whether the configuration was applied using OpenTofu or Terraform

However, I would recommend being more explicit, and once OpenTofu 1.8 version is released, to switch your .tf files to .tofu files (or at least some of them), to help make it clearer when the configuration is of OpenTofu and when it is of Terraform

[zhimsel]

While it won't enforce one or the other, using something like asdf may make it easier to manage which versions of which each root module uses and expects.

[zhimsel]

Oh, I have an idea to "enforce" it: in asdf's .tool-versions file, specify a dummy version (something that would never be a "correct" version like 999.999.999 or dontuse) for the one you don't want running in that root module. That way, if you try to run the wrong tool, asdf won't be able to find that version and produce an error. In other words, when you want to run Terraform:

terraform latest # (or whatever) 
opentofu 999999 # prevent using this

Just flip that to use opentofu.

The one downside I can think of is that a simple asdf install will fail (you'd have to explicitly specify the plug-in to install install of "all").

[zhimsel]

Hmm, it may be possible to utilize plugin hooks to produce a non-zero exit code if some file is present or something (each root module could have a flag file to indicate which one to use).

[fredrikjwip]

Thanks for the comments everyone!

What about this... from the department of awful hacks? :)

data "external" "validate_tofu" {
  program = ["sh", "-ec", "ps -C tofu -o comm > /dev/stderr && echo '{}'"]
}

Of course it will fall trough if the user is calling this config using terraform while also executing tofu in another shell. Oh, well.

I'm sure some nice combination of pgrep and pstree can exclude all processes that are not parent pids of the current shell, but I'll leave that bit of goldplating for another day.