Explore provisioner compatibility with OpenTofu

[bpmct]

We're an official Hahsicorp Partner and are unimpacted by Hashicorp's BSL license change. However, our product aims to be neutral to clouds, deployment methods, and even provisioners. While we only support Terraform at this time, we intentionally built an abstract provisioner layer to support other provisioners (e.g. pulumi, opentofu, terragrunt, typescript) down the road.

It could be beneficial to understand and document whether we support OpenTofu binaries if folks would prefer to use that over the official Hashicorp binary. Today, Coder deployments can use a custom Terraform binary as long as it is in PATH and is within the supported versions. I believe the hardcoded version check is somewhat arbitrary, but ensures compatibility with our example templates.

[mtojek]

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.

[coadler]

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.

[johnstcn]

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.

[bpmct]

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

[mtojek]

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?

[johnstcn]

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?

[bpmct]

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

[mtojek]

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.

[johnstcn]

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.

[bpmct]

We will continue to support users who use the OpenTofu binary with Coder and will address any bugs (or incompatibilities) with OpenTofu as the APIs diverge.

Today, this will "just work" if you symlink the tofu binary to terraform inside the Coder server/container image. When the APIs diverge (and we update our version support), we will ensure Coder still continues to work with OpenTofu and Terraform APIs. This is clearly a valuable project to cloud native communities and we want to give folks confidence they can continue to use Coder even if they implement an organization-wide policy (or make a personal choice) to use on one solution over the other.

We built Coder with flexibility and neutrality in mind, even making our provisioner layer abstract. As mentioned in the issue above, we're also considering other building other provisioner types, such as Javascript and Pulumi #4528, but haven't seen wide demand for this yet.

[kvendingoldo]

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.

[michaelbrewer]

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.

[strike]

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.