opentofu/opentofu

OpenTofu lets you declaratively manage your cloud infrastructure.

OpenTofu

• Manifesto
• About the OpenTofu fork
• How to install
• Join our Slack community!
• Weekly OpenTofu Status Updates

OpenTofu is an OSS tool for building, changing, and versioning infrastructure safely and efficiently. OpenTofu can manage existing and popular service providers as well as custom in-house solutions.

The key features of OpenTofu are:

• Infrastructure as Code: Infrastructure is described using a high-level configuration syntax. This allows a blueprint of your datacenter to be versioned and treated as you would any other code. Additionally, infrastructure can be shared and re-used.

• Execution Plans: OpenTofu has a "planning" step where it generates an execution plan. The execution plan shows what OpenTofu will do when you call apply. This lets you avoid any surprises when OpenTofu manipulates infrastructure.

• Resource Graph: OpenTofu builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources. Because of this, OpenTofu builds infrastructure as efficiently as possible, and operators get insight into dependencies in their infrastructure.

• Change Automation: Complex changesets can be applied to your infrastructure with minimal human interaction. With the previously mentioned execution plan and resource graph, you know exactly what OpenTofu will change and in what order, avoiding many possible human errors.

Getting help and contributing

• Have a question? Post it in GitHub Discussions or on the OpenTofu Slack!
• Want to contribute? Please read the Contribution Guide.
• Want to stay up to date? Read the weekly updates, TSC summary, or join the community meetings on Wednesdays at 14:30 CET / 8:30 AM Eastern / 5:30 AM Western / 19:00 India time on this link: https://meet.google.com/xfm-cgms-has (📅 calendar link)

Tip

For more OpenTofu events, subscribe to the OpenTofu Events Calendar!

Reporting security vulnerabilities

If you've found a vulnerability or a potential vulnerability in OpenTofu please follow Security Policy. We'll send a confirmation email to acknowledge your report, and we'll send an additional email when we've identified the issue positively or negatively.

Reporting possible copyright issues

If you believe you have found any possible copyright or intellectual property issues, please contact [email protected]. We'll send a confirmation email to acknowledge your report.

License

Mozilla Public License v2.0

opentofu's Issues

Rename all *user-facing* occurrences of Terraform to OpenTF

So occurrences in messages and similar.

s/Terraform/OpenTF/g
s/terraform/opentf/g

Please create PRs that aren't too large, so we can effectively review them. Don't create one PR for everything. A few packages at a time.

Check packages that are taken.

• #28
• #29
• #31
• #35
• #39
• #40
• #41
• #43
• #59
• #63
• #69
• #90
• #77
• #61
• #62
• #70
• #73
• #74
• #75
• #76
• #78
• #79
• #80
• #89
• #83
• #84
• #44
• #45
• #50
• #51
• #53
• #55
• #56
• #57
• #82
• #86
• #92
• #98
• #66
• #67
• #94
• #99
• #101
• #103
• #105
• #106
• #107
• #108
• #109
• #112
• #113
• #114
• #115
• #116
• #117
• #118
• #120
• #122
• #123
• #124
• #126
• #127
• #128
• #129
• #131
• #132
• #136
• #137
• #138
• #139
• #147
• #148
• #150
• #140
• #141
• #142
• #143
• #221
• #203
• #170
• #177
• #178
• #201
• #220
• #206
• #213
• #159
• #157
• #158
• #218
• #217

internal/httpclient

Disable telemetry

At least it shouldn't be going to where it's going now.

internal/configs

internal

Update Copyright notices.

There is an automatic copyright header generator, so update that and run it.

internal/depsfile

internal/cloudplugin

Rename TFC/TFE remote backend references.

Since other vendors support them too, we should call it in a more generic way. Either completely omit the product name, or call it TACOS client. As in Failed to create the Terraform Cloud/Enterprise client would be Failed to create the remote client or Failed to create the TACOS client.

In the future we might also support backends as plugins, in that case each TACOS will be able to provide their own and the existing remote backend would become deprecated.

Create a backup of all dependencies

• Agree on a location to store the backups
  • can just be private repos in this org if it's not too much work
  • could also be a big tarball on a google drive
• Things to backup
  • All direct and/or indirect dependencies in go.mod
  • All GitHub Actions used in the workflows
  • Not just files (so not just go mod vendor). The whole git repos, so we have the histories.

internal/builtin

Support .opentfignore in addition to .terraformignore

We might be able to support both, or just the opentf one.

Replace logo with OpenTF logo

We should replace any logo of terraform that exists in the repository.
For example - the logo that appears in the README.md

Get release process working

We should have a formalized process that leads to a GitHub release with binaries attached to it. See what we can salvage in the current GitHub Actions (possibly everything, and this task will be a quick one).

• It seems like the GitHub Actions produce deb and rpm archives, do we want to support these? If yes, where do we host them?
• Decide where we want to host docker images. Public docker registry? ghcr.io?
• Maybe it's worth using goreleaser for the release creation process? Or maybe it's fine to keep it manual.
• Adjust .release/release-metadata.hcl and any other metadata.

internal/command/jsonformat

Support opentf keyword in tf files in addition to the terraform keyword

As in

opentf {
  required_providers {
    aws = {
      source = "hashicorp/aws"
    }
  }
}

Change data and tempfile names.

When running terraform init you'll get .terraform and .terraform.lock.hcl. Both should be .opentf-prefixed.

.terraform -> .opentf
.terraform.lock.hcl -> .opentf.lock.hcl

Same for ~/.terraform.d, though for this one we'd ideally support both versions.

Adjust community-documents.

Adjust issue templates, code of conduct, contributing guidelines, codeowners, etc.

Get rid of all the links on the Issue creation page.

internal/addrs

Support OpenTofu in TFenv

We would want to make our presence in popular tools in the community.
Being able to use OpenTF when using TFenv would be a great way to do that.

internal/addrs

internal/backend

internal/experiments

internal/helper

Set up documentation website.

• This should involve a cleanup of the website directory to get rid of any kind of "marketing material".
• It might require design + frontend work to change the styling.
• Set it up on some hosting, could even be github actions.

Support .opentfrc in addition to .terraformrc

We might be able to support both, or we might only support .opentfrc

Support opentf backend files

support

• opentf.tfstate.d
• opentf.tfstate

internal/cloud

root directory

internal/didyoumean

Make sure all GitHub Actions are green

Currently not all GitHub Actions are passing:

• Lock Threads fails (we probably don't need that right now)
• Backport assistant runner fails - same
• Label removals are failing with errors, in a successful action - link

Those are some examples, we should make sure all GitHub Actions are working as intended, adjusted if needed, or completely removed if they are unnecessary

internal/command/clistate

Get 1.6 Testing Feature Production-ready

• Investigate exactly how the feature currently works and is supposed to work.
• Investigate how much is implemented already.
• Investigate the tests to see how well-tested it is.
• Add tests for any scenarios not covered.
• Understand what else we need to implement and improve for it to be usable, stable and secure.
• Write out the necessary work left in this issue.
• Implement it.
• Write documentation for it.

internal/command/jsonconfig

Support OpenTofu in Terragrunt

We would want to make our presence in popular tools in the community.
Being able to use OpenTF when using Terragrunt would be a great way to do taht.

internal/command/jsonplan

internal/copy

Set up a homebrew package.

We can start with a homebrew tap initially (as we can prepare that easily in private).

See

• https://github.com/spacelift-io/spacectl/blob/main/.github/workflows/release.yml
• https://github.com/spacelift-io/homebrew-spacelift
  for inspiration.

Then, after the first public stable release, we can also contribute a homebrew-core package. See https://github.com/Homebrew/homebrew-core/blob/master/Formula/t/terraform.rb for inspiration.

The brew should be brew install opentofu

internal/command/jsonchecks

internal/command/jsonfunction

internal/command

internal/checks

Get rid of Terraform from markdown documents and documentation.

• Terraform -> OpenTF
• terraform -> opentf
• Hashicorp -> OpenTFFoundation

internal/command/cliconfig

Change module name

Change module name from github.com/hashicorp/terraform to github.com/placeholderplaceholderplaceholder/opentf (so that we can later easily replace with the right organization name).

We need to do this asap as it will most likely collide with any other changes.

tfstate and tfvars name handling

Right now terraform by default works with terraform.tfstate and terraform.tfvars

Ideally, we should support reading these, but always write and primarily operate on opentf.xyz files.

internal/communicator

internal/e2e

internal/dag

internal/command/arguments