afdfaf390d
"GODEBUG" is a mechanism that the Go runtime forces on OpenTofu that allows dynamic changes to various nuances of Go standard library behavior. We cannot control when GODEBUG workarounds are added and removed from Go, so if someone chooses to rely on them then they are likely to get broken by a later release of OpenTofu that uses a newer version of Go. Therefore we'd like anyone relying on these to tell us so we can try to find a more sustainable solution to their problem early on while the workaround is still available to them. We also occasionally force certain GODEBUG workarounds on by default in our official builds in anticipation of breakage caused by upstream Go changes. In that case we'd still like to know if anyone is relying on them so that we can remove those workarounds in a future release, but we'd prefer to get the reports about it in an issue or discussion we'd already created for that purpose. This therefore introduces warning diagnostics any time something in the "init", "plan", or "apply" commands relies on non-default GODEBUG settings. For ones we enabled intentionally we provide a specific URL to report usage as part of the diagnostic message, but we also have a generic message for any GODEBUG settings the user chose to enable for themselves for reasons we probably don't know about yet but would like to learn more about. This is included in only that subset of commands as a compromise because those are the commands most likely to interact with Go library features that are affected by these workarounds -- they most commonly affect functionality related to networking, TLS, etc -- and additional diagnostics in these locations should not to cause breakage for anyone consuming the machine-readable output, but there are other commands where additional diagnostics are more likely to cause problems. Unfortunately it isn't really possible to unit-test this because it relies directly on information reported by the Go metrics system and there's no facility to produce fake metrics for testing. However, Go 1.26 (which we're currently using) there is a GODEBUG setting "netedns0=0" which causes a warning any time OpenTofu makes a DNS request, so I've tested this manually by running "tofu init" with that workaround enabled in a configuration that depends on at least one provider (causing DNS lookups for the provider registry) and seen it generate the expected warning message referring to "netedns0". These new warnings replace our previous quieter messages about this in the TF_LOG=warn output, because those were only useful in situations where GODEBUG was causing a problem that led to someone opening a bug report, but we actually want to know of situations where GODEBUG was needed in order for OpenTofu to _succeed_ and so for that we need more prominent messages to let the operator know there's something they ought to report to us even though there wasn't an error. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Homepage | Slack | Get Started
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.
Getting help and contributing
- Have a question?
- Post it in GitHub Discussions
- Open a GitHub issue
- Join us in the #opentofu channel on the CNCF Slack!
- Want to contribute?
- Please read the Contribution Guide.
- Recurring Events
- Community Meetings on Wednesdays at 12:30 UTC (calendar)
- Technical Steering Committee Meetings every other Tuesday at 4pm UTC (calendar)
Tip
For more OpenTofu events, subscribe to the OpenTofu Events Calendar!
Key features
-
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.
Nightly Builds
Nightly builds are available for testing the latest changes on main. These are experimental and not intended for production use. Each build is removed after 30 days.
Nightly builds can be found at https://nightlies.opentofu.org/nightlies. For those who want to automate with tooling, https://nightlies.opentofu.org/nightlies/latest.json will be kept up to date with the latest build information.
For more details, see RELEASE.md.
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 liaison@opentofu.org. We'll send a confirmation email to acknowledge your report.
Registry Access
In an effort to comply with applicable sanctions, we block access from specific countries of origin. For more details, see the Registry Inclusion Policy.