RFD - Switch from Terraform to OpenTofu

[marcelovilla]

Status	Open for comments 💬
Author(s)	@Adam-D-Lewis @dcmcand @marcelovilla @viniciusdc
Date Created	24-10-2024
Date Last updated	25-10-2024
Decision deadline

Title

Switch from Terraform to OpenTofu

Summary

On August 10, 2023, HashiCorp announced a transition from MPL to BUSL in all of the new releases of their products. BUSL imposes limitations on how the software can be used commercially, which could introduce restrictions for Nebari users, depending on their use case. Given this uncertainty and in the spirit of open source, we have pinned the Terraform version downloaded automatically by Nebari during the deployment process to 1.5.7, the latest version before the licensing change. For reference, the most recent Terraform version at the time of writing this is 1.9.8.

Shortly after HashiCorp's announcement, several companies created a Terraform fork called OpenTofu (formerly named OpenTF), which is now a project managed by the Linux Foundation. OpenTofu is supposed to be a a drop-in replacement for Terraform. Hence, the proposal here is to switch from Terraform to OpenTofu.

User benefit

Switching to OpenTofu allows us to update a major dependency of Nebari without being affected by a license change.

Some of the benefits of being able to update this dependency include access to:

• Security improvements and Bug Fixes - We are currently pinned to an old version of Terraform. This means that we do not have access to newer bug fixes or security improvements released by Hashicorp. This switch would allow us to remain up to date with the latest version of OpenTofu ensuring that we benefit from all security patches and bug fixes
• New features - OpenTofu has already introduced new features that the community has long asked for, but Terraform never delivered. One example would be dynamic provider blocks. Since OpenTofu is a community project owned by the Linux Foundation it will very likely continue to innovate and add new features. This switch would allow us to use these new features.
• Better compatibility - By not upgrading, we risk conflicts as tooling stops supporting older versions of Terraform. This has not yet been an issue, but it is very likely to become an issue in the future. As Nebari relies on integrating a large number of open source projects, compatibility is very important for the project.

Design Proposal

OpenTofu acts as a drop-in replacement for Terraform and we just need to change the way we download and execute the binary. Changes would be relatively small and non-invasive and all the HCL files we currently have would stay the same.

Here is a draft PR used to investigate the feasibility of switching from Terraform to OpenTofu. It has been successfully tested in the following scenarios:

• Local deployment
• AWS deployment
• GCP deployment
• Upgrade of existing 2024.9.1 GCP deployment to nebari-dev/nebari@8f709da

Alternatives or approaches considered (if any)

• Keep using Terraform 1.5.7 indefinitely
• Switch to a newer version of Terraform and

Neither of these alternatives seems realistic to me. While it's true that nothing is currently being blocked by our inability to upgrade Terraform, I don't see how staying behind could be sustainable in the long run. Over time, the gap between our version and the latest release will widen, potentially leading to security vulnerabilities, compatibility issues, and missed opportunities for improvements and new features.

As for the second option, keeping a permissive license offers several benefits over a restrictive one, such as a wider community adoption and contribution, fewer legal and compliance concerns, and better compatibility with other open source projects.

Best practices

User impact

This implementation wouldn't have user-facing changes and it would be rolled out in a new Nebari version, without users having to do anything besides upgrading.

Unresolved questions

[dcmcand]

In my opinion, there are almost no downsides here and a ton of upsides. I fully support this transition at this time. Initially I didn't want to because at the time OpenTofu was so new that I wanted to ensure that it was going to actually be around. At this point, there has been sufficient community adoption and support that I think this is a very safe transition that will take minimal effort.

[dharhas]

Notes:

OpenTofu will not have its own providers. Terraform providers have not altered their licenses, and the potential for such a change is virtually zero. OpenTofu works with the current Terraform providers, but it uses a separate registry.

Also there are some interesting security features that are available in OpenTofu now, like state encryption - https://opentofu.org/blog/opentofu-1-7-0/