Explore provisioner compatibility with OpenTofu #27605

Thanks @bpmct for raising the issue.

I believe the hardcoded version check is somewhat arbitrary, but ensures compatibility with our example templates.

If we create another provider for OpenTofu, and we are legally safe with a BUSL license, then we should be good to go and remove the version constraint. It might be the right moment in time as according to this site, Terraform will not release security patches for 1.5.7 anymore. We shouldn't "vendor-lock" our customers to unsafe versions.

I know @johnstcn did some research recently, so he might give more technical details to evaluate the challenge.

I believe the hardcoded version check is somewhat arbitrary, but ensures compatibility with our example templates.

The version constraint isn't purely to prevent us from using the BUSL Terraform versions, but mainly to prevent using newer Terraform versions than we've tested ourselves. Chatted with @ammario and @bpmct the other week and decided to finally move to the BUSL versions of Terraform, so we should be moving off of the EOL 1.5.x release soon.

FWIW we have experimented with using OpenTofu (terraform version = 1.6.1) in place of Terraform over the weekend and did not notice any issues. This can be done simply by symlinking the tofu binary to terraform and bumping the max terraform version in Coder.

bumping the max terraform version in Coder

This is the part that will probably be difficult for users as it involves modifying Coder's source code (albeit in a simple way), creating a build, and maintaining a "fork/patch" of Coder that just bumps that max version.

so we should be moving off of the EOL 1.5.x release soon

Nice, so we can this can be easier for users as soon as we do this and bump our maxTerraformVersion

Nice, so we can this can be easier for users as soon as we do this and bump our maxTerraformVersion

Isn't there any problems around linking it with homebrew?

One other option we have here is to make the max terraform version constraint a soft constraint instead of a hard one.

Currently the logic is:

if terraform binary is present and terraform version is between minTerraformVersion and maxTerraformVersion:
  use existing terraform binary
else:
  install default terraform version

We could potentially change this to:

if terraform binary is present and terraform version is between minTerraformVersion and maxTerraformVersion:
  use existing terraform binary
else if terraform versions is greater than maxTerraform version:
  use existing terraform binary but warn about potential incompatibilities
else:
  install default terraform version

WDYT?

else if terraform versions is greater than maxTerraform version: use existing terraform binary but warn about potential incompatibilities

I like this. Can we also apply it to the minimum version as well? Perhaps some folks will want to stay on the non-BSL version of the official Terraform even after we stop "supporting" it

Don't forget that this is a fork, so at some point APIs of both products may diverge, and we will need to treat opentofu as another provider.

Don't forget that this is a fork, so at some point APIs of both products may diverge, and we will need to treat opentofu as another provider.

Correct. Right now the only way to use OpenTofu is to symlink tofu -> terraform so there's no chance of this happening by accident.

At this moment if you need to have a support of Terraform as well as OpenTofu (and Terragrunt :) ) in one tool you can use https://github.com/tofuutils/tenv which my team wrote some months ago. A lot of users switched to that tool to unify version management in the world of Terraform.

You're welcome to open any issues or contribute to tenv.

Also as Coder is FOSS product at its core, to support OpenTofu allow people to continue to use Coder without worrying about BSL. Of coz getting Pulumi is a bonus for sure.

When migrating from Terraform to Tofu, keep in mind that the pinning in .terraform.lock.hcl will be affected.

For example, the .terraform.lock.hcl for Terraform:

provider "registry.terraform.io/coder/coder" {
}

For Tofu:

provider "registry.opentofu.org/coder/coder" {
}

I use Tofu locally and encountered this issue.

Has anything changed? Can we get an update on the steps to use OpenTofu in 2025.