IntenseWebs/opentofu
3
0
Fork 0
mirror of https://github.com/opentofu/opentofu.git synced 2025-02-25 18:45:20 -06:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'main' into test-refresh-only-test

Browse Source
This commit is contained in:
Elbaz 2023-09-03 17:29:15 +03:00 committed by GitHub
commit 39172c7bc5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
182 changed files with 2696 additions and 3066 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/ISSUE_TEMPLATE/feature_request.yml vendored
View File

@ -10,8 +10,6 @@ body:
value: |
# Thank you for opening a feature request.
The [OpenTF](https://github.com/placeholderplaceholderplaceholder/opentf) issue tracker is reserved for feature requests relating to the core OpenTF CLI application and configuration language.
- type: textarea
id: tf-version
attributes:

132
.github/ISSUE_TEMPLATE/rfc.yml vendored Normal file
View File

@ -0,0 +1,132 @@
# This RFC has been inspired by the Rust RFC template https://github.com/rust-lang/rfcs/blob/master/0000-template.md
name: Submit RFC
description: Submit a highly-structured change request for public discussion.
labels: ["rfc", "new"]
body:
- type: markdown
attributes:
value: |
Thank you for opening an RFC! RFCs are a highly-structured format for submitting change requests.
All major changes to OpenTF should first go through an RFC, to have a place for the community to discuss.
The template has a lot of fields and is inspired by the Rust RFC template.
Please take your time to fill it out carefully.
Working experimental PoCs in a draft Pull Request are a very welcome attachment to an RFC, especially
ones that are easy to check out and take for a spin.
- type: textarea
id: summary
attributes:
label: Summary
description: |
One paragraph explanation of the feature.
placeholder:
value:
validations:
required: true
- type: textarea
id: problem-statement
attributes:
label: Problem Statement
description: |
Why are we doing this? What problem are we solving?
placeholder:
value:
validations:
required: true
- type: textarea
id: user-facing-description
attributes:
label: User-facing description
description: |
Please describe in detail how the feature would work from the perspective of somebody using:
- How can the feature be used?
- How would you explain the feature to somebody?
- Please provide examples of the feature in action.
placeholder:
value:
validations:
required: true
- type: textarea
id: technical-description
attributes:
label: Technical Description
description: |
Please describe in detail how the feature would work from a technical perspective:
- Which components of OpenTF would be involved in the change?
- How would the components need to change?
- Are there any interactions with other features that should be mentioned?
- Are the any edge cases of the feature that should be discussed?
placeholder:
value:
validations:
required: true
- type: textarea
id: rationale-and-alternatives
attributes:
label: Rationale and alternatives
description: |
- What would be the impact of this feature?
- Why is this solution better than alternative solutions to this problem, if there are any?
- How would the OpenTF user experience suffer if we didn't do this.
placeholder:
value:
validations:
required: true
- type: textarea
id: downsides
attributes:
label: Downsides
description: |
- Are there any disadvantages of implementing this?
placeholder:
value:
validations:
required: false
- type: textarea
id: unresolved-questions
attributes:
label: Unresolved Questions
description: |
- Are there any specific parts of the feature you're not sure about?
- Are there any specific parts of the technical implementation you're not sure about?
- Are there any other questions or unknowns that need to be answered before implementing this?
placeholder:
value:
validations:
required: false
- type: textarea
id: related-issues
attributes:
label: Related Issues
description: |
- Please post any issues or RFCs related to this one.
placeholder:
value:
validations:
required: false
- type: textarea
id: poc-pull-request
attributes:
label: Proof of Concept
description: |
- If there is a Pull Request with a Proof of Concept, please link it here.
- Please concisely describe how to take the PoC for a spin.
placeholder:
value:
validations:
required: false
- type: markdown
attributes:
value: |
**Note:** If the submit button is disabled and you have filled out all required fields, please check that you did not forget a **Title** for the issue.

40
.github/CONTRIBUTING.md → CONTRIBUTING.md
View File

@ -1,42 +1,44 @@
# Contributing to OpenTF
This repository contains OpenTF core, which includes the command line interface and the main graph engine
This repository contains OpenTF Core, which includes the command line interface, the main graph engine, and the documentation for them.
This document provides guidance on OpenTF contribution recommended practices. It covers what we're looking for in order to help set some expectations and help you get the most out of participation in this project.
This document provides guidance on OpenTF contribution recommended practices. It covers how to submit issues, how to get involved in the discussion, how to work on the code, and how to contribute code changes.
To record a bug report, enhancement proposal, or give any other product feedback, please [open a GitHub issue](https://github.com/placeholderplaceholderplaceholder/opentf/issues/new/choose) using the most appropriate issue template
The easiest way to contribute is by [opening an issue](https://github.com/opentffoundation/opentf/issues/new/choose)! Bug reports, broken compatibility reports, feature requests, old issue reposts, and well-prepared RFCs are all very welcome.
The contribution guideline will change in the near future, as the management of the open-source project is stabilized
All major changes to OpenTF Core go through the public RFC process, including those proposed by the core team. Thus, if you'd like to propose such a change, please prepare an RFC, so that the community can discuss the change and everybody has a chance to voice their opinion. You're also welcome to voice your own opinion on existing RFCs! You can find them by [going to the issues view and filtering by the rfc label](https://github.com/opentffoundation/opentf/issues?q=is%3Aopen+is%3Aissue+label%3Arfc).
Generally, we appreciate external contributions very much and would love to work with you on them. **However, please make sure to read the [Contributing a Code Change](#contributing-a-code-change) section prior to making a contribution.**
---
<!-- MarkdownTOC autolink="true" -->
- [Proposing a Change](#proposing-a-change)
- [PR Checks](#pr-checks)
- [OpenTF CLI/Core Development Environment](#opentf-clicore-development-environment)
- [Contributing a Code Change](#contributing-a-code-change)
- [Working on the Code](#working-on-the-code)
- [Acceptance Tests: Testing interactions with external services](#acceptance-tests-testing-interactions-with-external-services)
- [Generated Code](#generated-code)
<!-- /MarkdownTOC -->
## Proposing a Change
## Contributing a Code Change
In order to be respectful of the time of community contributors, we aim to discuss potential changes in GitHub issues prior to implementation. That will allow us to give design feedback up front and set expectations about the scope of the change, and, for larger changes, how best to approach the work such that the OpenTF team can review it and merge it along with other concurrent work.
In order to contribute a code change, you should fork the repository, make your changes, and then submit a pull request. Crucially, all code changes should be preceded by an issue that you've been assigned to. If an issue for the change you'd like to introduce already exists, please communicate in the issue that you'd like to take ownership of it. If an issue doesn't yet exist, please create one expressing your interest in working on it and discuss it first, prior to working on the code. Code changes without a related issue will generally be rejected.
If the bug you wish to fix or enhancement you wish to implement isn't already covered by a GitHub issue, please do start a discussion (either in [a new GitHub issue](https://github.com/placeholderplaceholderplaceholder/opentf/issues/new/choose) or an existing one, as appropriate) before you invest significant development time.
In order for a code change to be accepted, you'll also have to accept the Developer Certificate of Origin (DCO). It's very lightweight, and you can find it [here](https://developercertificate.org). Accepting is accomplished by signing off on your commits, you can do this by adding a `Signed-off-by` line to your commit message, like here:
```
This is my commit message
### PR Checks
Signed-off-by: Random Developer <random@developer.example.org>
```
Git has a built-in flag to append this line automatically:
```
~> git commit -s -m 'This is my commit message'
```
Test checks run when a PR is opened. Tests include unit tests and acceptance tests, and all tests must pass before a PR can be merged
You can find more details about the DCO checker in the [DCO app repo](https://github.com/dcoapp/app).
----
## OpenTF CLI/Core Development Environment
This repository contains the source code for OpenTF CLI, which is the main component of OpenTF that contains the core OpenTF engine.
---
## Working on the Code
If you wish to work on the OpenTF CLI source code, you'll first need to install the [Go](https://golang.org/) compiler and the version control system [Git](https://git-scm.com/).

2
internal/logging/panic.go
View File

@ -25,7 +25,7 @@ shown below, and any additional information which may help replicate the issue.
[1]: https://github.com/placeholderplaceholderplaceholder/opentf/issues
!!!!!!!!!!!!!!!!!!!!!!!!!!! TERRAFORM CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!! OPENTF CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!
`

342
website/data/cli-nav-data.json
View File

@ -1,137 +1,129 @@
[
{ "heading": "OpenTF CLI" },
{ "title": "Overview", "path": "" },
{ "title": "Basic CLI Features", "href": "/cli/commands" },
{ "title": "Overview", "path": "cli/index" },
{ "title": "Basic CLI Features", "path": "cli/commands/index" },
{
"title": "Initializing Working Directories",
"routes": [
{ "title": "Overview", "path": "init" },
{ "title": "<code>init</code>", "href": "/cli/commands/init" },
{ "title": "<code>get</code>", "href": "/cli/commands/get" }
{ "title": "Overview", "path": "cli/init/index" },
{ "title": "<code>init</code>", "path": "cli/commands/init" },
{ "title": "<code>get</code>", "path": "cli/commands/get" }
]
},
{
"title": "Provisioning Infrastructure",
"routes": [
{ "title": "Overview", "path": "run" },
{ "title": "<code>plan</code>", "href": "/cli/commands/plan" },
{ "title": "<code>apply</code>", "href": "/cli/commands/apply" },
{ "title": "<code>destroy</code>", "href": "/cli/commands/destroy" }
{ "title": "Overview", "path": "cli/run/index" },
{ "title": "<code>plan</code>", "path": "cli/commands/plan" },
{ "title": "<code>apply</code>", "path": "cli/commands/apply" },
{ "title": "<code>destroy</code>", "path": "cli/commands/destroy" }
]
},
{
"title": "Authenticating",
"routes": [
{ "title": "Overview", "path": "auth" },
{ "title": "<code>login</code>", "href": "/cli/commands/login" },
{ "title": "<code>logout</code>", "href": "/cli/commands/logout" }
{ "title": "Overview", "path": "cli/auth/index" },
{ "title": "<code>login</code>", "path": "cli/commands/login" },
{ "title": "<code>logout</code>", "path": "cli/commands/logout" }
]
},
{
"title": "Writing and Modifying Code",
"routes": [
{ "title": "Overview", "path": "code" },
{ "title": "<code>console</code>", "href": "/cli/commands/console" },
{ "title": "<code>fmt</code>", "href": "/cli/commands/fmt" },
{ "title": "<code>validate</code>", "href": "/cli/commands/validate" },
{
"title": "<code>0.13upgrade</code>",
"href": "/cli/commands/0.13upgrade"
},
{
"title": "<code>0.12upgrade</code>",
"href": "/cli/commands/0.12upgrade"
}
{ "title": "Overview", "path": "cli/code/index" },
{ "title": "<code>console</code>", "path": "cli/commands/console" },
{ "title": "<code>fmt</code>", "path": "cli/commands/fmt" },
{ "title": "<code>validate</code>", "path": "cli/commands/validate" }
]
},
{
"title": "Inspecting Infrastructure",
"routes": [
{ "title": "Overview", "path": "inspect" },
{ "title": "<code>graph</code>", "href": "/cli/commands/graph" },
{ "title": "<code>output</code>", "href": "/cli/commands/output" },
{ "title": "<code>show</code>", "href": "/cli/commands/show" },
{ "title": "Overview", "path": "cli/inspect/index" },
{ "title": "<code>graph</code>", "path": "cli/commands/graph" },
{ "title": "<code>output</code>", "path": "cli/commands/output" },
{ "title": "<code>show</code>", "path": "cli/commands/show" },
{
"title": "<code>state list</code>",
"href": "/cli/commands/state/list"
"path": "cli/commands/state/list"
},
{
"title": "<code>state show</code>",
"href": "/cli/commands/state/show"
"path": "cli/commands/state/show"
}
]
},
{
"title": "Importing Infrastructure",
"routes": [
{ "title": "Overview", "path": "import" },
{ "title": "Overview", "path": "cli/import/index" },
{
"title": "<code>import</code>",
"href": "/cli/commands/import"
"path": "cli/commands/import"
},
{ "title": "Usage Tips", "path": "import/usage" },
{ "title": "Usage Tips", "path": "cli/import/usage" },
{
"title": "Resource Importability",
"path": "import/importability"
"path": "cli/import/importability"
}
]
},
{
"title": "Manipulating State",
"routes": [
{ "title": "Overview", "path": "state" },
{ "title": "Overview", "path": "cli/state/index" },
{
"title": "Resource Addressing",
"path": "state/resource-addressing"
"path": "cli/state/resource-addressing"
},
{ "title": "<code>state</code>", "href": "/cli/commands/state" },
{ "title": "<code>state</code>", "path": "cli/commands/state/index" },
{
"title": "Inspecting State",
"routes": [
{ "title": "Overview", "path": "state/inspect" },
{ "title": "Overview", "path": "cli/state/inspect" },
{
"title": "<code>state list</code>",
"href": "/cli/commands/state/list"
"path": "cli/commands/state/list"
},
{
"title": "<code>state show</code>",
"href": "/cli/commands/state/show"
"path": "cli/commands/state/show"
},
{
"title": "<code>refresh</code>",
"href": "/cli/commands/refresh"
"path": "cli/commands/refresh"
}
]
},
{
"title": "Forcing Re-creation (Tainting)",
"routes": [
{ "title": "Overview", "path": "state/taint" },
{ "title": "Overview", "path": "cli/state/taint" },
{
"title": "<code>taint</code>",
"href": "/cli/commands/taint"
"path": "cli/commands/taint"
},
{
"title": "<code>untaint</code>",
"href": "/cli/commands/untaint"
"path": "cli/commands/untaint"
}
]
},
{
"title": "Moving Resources",
"routes": [
{ "title": "Overview", "path": "state/move" },
{ "title": "Overview", "path": "cli/state/move" },
{
"title": "<code>state mv</code>",
"href": "/cli/commands/state/mv"
"path": "cli/commands/state/mv"
},
{
"title": "<code>state rm</code>",
"href": "/cli/commands/state/rm"
"path": "cli/commands/state/rm"
},
{
"title": "<code>state replace-provider</code>",
"href": "/cli/commands/state/replace-provider"
"path": "cli/commands/state/replace-provider"
}
]
},
@ -140,19 +132,19 @@
"routes": [
{
"title": "Overview",
"path": "state/recover"
"path": "cli/state/recover"
},
{
"title": "<code>state pull</code>",
"href": "/cli/commands/state/pull"
"path": "cli/commands/state/pull"
},
{
"title": "<code>state push</code>",
"href": "/cli/commands/state/push"
"path": "cli/commands/state/push"
},
{
"title": "<code>force-unlock</code>",
"href": "/cli/commands/force-unlock"
"path": "cli/commands/force-unlock"
}
]
}
@ -161,30 +153,30 @@
{
"title": "Managing Workspaces",
"routes": [
{ "title": "Overview", "path": "workspaces" },
{ "title": "Overview", "path": "cli/workspaces/index" },
{
"title": "<code>workspace</code>",
"routes": [
{ "title": "Overview", "href": "/cli/commands/workspace" },
{ "title": "Overview", "path": "cli/commands/workspace/index" },
{
"title": "<code>workspace list</code>",
"href": "/cli/commands/workspace/list"
"path": "cli/commands/workspace/list"
},
{
"title": "<code>workspace select</code>",
"href": "/cli/commands/workspace/select"
"path": "cli/commands/workspace/select"
},
{
"title": "<code>workspace new</code>",
"href": "/cli/commands/workspace/new"
"path": "cli/commands/workspace/new"
},
{
"title": "<code>workspace delete</code>",
"href": "/cli/commands/workspace/delete"
"path": "cli/commands/workspace/delete"
},
{
"title": "<code>workspace show</code>",
"href": "/cli/commands/workspace/show"
"path": "cli/commands/workspace/show"
}
]
}
@ -193,155 +185,146 @@
{
"title": "Managing Plugins",
"routes": [
{ "title": "Overview", "path": "plugins" },
{ "title": "Plugin Signing", "path": "plugins/signing" },
{ "title": "Overview", "path": "cli/plugins/index" },
{ "title": "Plugin Signing", "path": "cli/plugins/signing" },
{
"title": "<code>providers</code>",
"href": "/cli/commands/providers"
"path": "cli/commands/providers"
},
{
"title": "<code>version</code>",
"href": "/cli/commands/version"
"path": "cli/commands/version"
},
{
"title": "<code>providers lock</code>",
"href": "/cli/commands/providers/lock"
"path": "cli/commands/providers/lock"
},
{
"title": "<code>providers mirror</code>",
"href": "/cli/commands/providers/mirror"
"path": "cli/commands/providers/mirror"
},
{
"title": "<code>providers schema</code>",
"href": "/cli/commands/providers/schema"
"path": "cli/commands/providers/schema"
}
]
},
{
"title": "CLI Configuration",
"routes": [
{ "title": "Overview", "path": "config" },
{ "title": "CLI Configuration", "path": "config/config-file" },
{ "title": "Overview", "path": "cli/config/index" },
{ "title": "CLI Configuration", "path": "cli/config/config-file" },
{
"title": "Environment Variables",
"path": "config/environment-variables"
"path": "cli/config/environment-variables"
}
]
},
{
"title": "Using Cloud Backend",
"routes": [
{ "title": "Overview", "path": "cloud" },
{ "title": "Cloud Backend Settings", "path": "cloud/settings" },
{ "title": "Overview", "path": "cli/cloud/index" },
{ "title": "Cloud Backend Settings", "path": "cli/cloud/settings" },
{
"title": "Initializing and Migrating",
"path": "cloud/migrating"
"path": "cli/cloud/migrating"
},
{
"title": "Command Line Arguments",
"path": "cloud/command-line-arguments"
"path": "cli/cloud/command-line-arguments"
}
]
},
{
"title": "Alphabetical List of Commands",
"routes": [
{ "title": "Overview", "href": "/cli/commands" },
{ "title": "<code>apply</code>", "href": "/cli/commands/apply" },
{ "title": "<code>console</code>", "href": "/cli/commands/console" },
{ "title": "<code>destroy</code>", "href": "/cli/commands/destroy" },
{ "title": "<code>env</code>", "href": "/cli/commands/env" },
{ "title": "<code>fmt</code>", "href": "/cli/commands/fmt" },
{ "title": "Overview", "path": "cli/commands/index" },
{ "title": "<code>apply</code>", "path": "cli/commands/apply" },
{ "title": "<code>console</code>", "path": "cli/commands/console" },
{ "title": "<code>destroy</code>", "path": "cli/commands/destroy" },
{ "title": "<code>env</code>", "path": "cli/commands/env" },
{ "title": "<code>fmt</code>", "path": "cli/commands/fmt" },
{
"title": "<code>force-unlock</code>",
"href": "/cli/commands/force-unlock"
"path": "cli/commands/force-unlock"
},
{ "title": "<code>get</code>", "href": "/cli/commands/get" },
{ "title": "<code>graph</code>", "href": "/cli/commands/graph" },
{ "title": "<code>import</code>", "href": "/cli/commands/import" },
{ "title": "<code>init</code>", "href": "/cli/commands/init" },
{ "title": "<code>login</code>", "href": "/cli/commands/login" },
{ "title": "<code>logout</code>", "href": "/cli/commands/logout" },
{ "title": "<code>output</code>", "href": "/cli/commands/output" },
{ "title": "<code>plan</code>", "href": "/cli/commands/plan" },
{ "title": "<code>providers</code>", "href": "/cli/commands/providers" },
{ "title": "<code>get</code>", "path": "cli/commands/get" },
{ "title": "<code>graph</code>", "path": "cli/commands/graph" },
{ "title": "<code>import</code>", "path": "cli/commands/import" },
{ "title": "<code>init</code>", "path": "cli/commands/init" },
{ "title": "<code>login</code>", "path": "cli/commands/login" },
{ "title": "<code>logout</code>", "path": "cli/commands/logout" },
{ "title": "<code>output</code>", "path": "cli/commands/output" },
{ "title": "<code>plan</code>", "path": "cli/commands/plan" },
{ "title": "<code>providers</code>", "path": "cli/commands/providers" },
{
"title": "<code>providers lock</code>",
"href": "/cli/commands/providers/lock"
"path": "cli/commands/providers/lock"
},
{
"title": "<code>providers mirror</code>",
"href": "/cli/commands/providers/mirror"
"path": "cli/commands/providers/mirror"
},
{
"title": "<code>providers schema</code>",
"href": "/cli/commands/providers/schema"
"path": "cli/commands/providers/schema"
},
{
"title": "<code>push (deprecated)</code>",
"href": "/cli/commands/push"
},
{ "title": "<code>refresh</code>", "href": "/cli/commands/refresh" },
{ "title": "<code>show</code>", "href": "/cli/commands/show" },
{ "title": "<code>state</code>", "href": "/cli/commands/state" },
{ "title": "<code>refresh</code>", "path": "cli/commands/refresh" },
{ "title": "<code>show</code>", "path": "cli/commands/show" },
{ "title": "<code>state</code>", "path": "cli/commands/state/index" },
{
"title": "<code>state list</code>",
"href": "/cli/commands/state/list"
"path": "cli/commands/state/list"
},
{ "title": "<code>state mv</code>", "href": "/cli/commands/state/mv" },
{ "title": "<code>state mv</code>", "path": "cli/commands/state/mv" },
{
"title": "<code>state pull</code>",
"href": "/cli/commands/state/pull"
"path": "cli/commands/state/pull"
},
{
"title": "<code>state push</code>",
"href": "/cli/commands/state/push"
"path": "cli/commands/state/push"
},
{
"title": "<code>state replace-provider</code>",
"href": "/cli/commands/state/replace-provider"
"path": "cli/commands/state/replace-provider"
},
{ "title": "<code>state rm</code>", "href": "/cli/commands/state/rm" },
{ "title": "<code>state rm</code>", "path": "cli/commands/state/rm" },
{
"title": "<code>state show</code>",
"href": "/cli/commands/state/show"
"path": "cli/commands/state/show"
},
{ "title": "<code>taint</code>", "href": "/cli/commands/taint" },
{ "title": "<code>taint</code>", "path": "cli/commands/taint" },
{
"title": "<code>test (deprecated)</code>",
"href": "/cli/commands/test"
"path": "cli/commands/test"
},
{ "title": "<code>untaint</code>", "path": "cli/commands/untaint" },
{ "title": "<code>validate</code>", "path": "cli/commands/validate" },
{ "title": "<code>version</code>", "path": "cli/commands/version" },
{
"title": "<code>workspace</code>",
"path": "cli/commands/workspace/index"
},
{ "title": "<code>untaint</code>", "href": "/cli/commands/untaint" },
{ "title": "<code>validate</code>", "href": "/cli/commands/validate" },
{ "title": "<code>version</code>", "href": "/cli/commands/version" },
{ "title": "<code>workspace</code>", "href": "/cli/commands/workspace" },
{
"title": "<code>workspace list</code>",
"href": "/cli/commands/workspace/list"
"path": "cli/commands/workspace/list"
},
{
"title": "<code>workspace select</code>",
"href": "/cli/commands/workspace/select"
"path": "cli/commands/workspace/select"
},
{
"title": "<code>workspace new</code>",
"href": "/cli/commands/workspace/new"
"path": "cli/commands/workspace/new"
},
{
"title": "<code>workspace delete</code>",
"href": "/cli/commands/workspace/delete"
"path": "cli/commands/workspace/delete"
},
{
"title": "<code>workspace show</code>",
"href": "/cli/commands/workspace/show"
},
{
"title": "<code>0.12upgrade</code>",
"href": "/cli/commands/0.12upgrade"
},
{
"title": "<code>0.13upgrade</code>",
"href": "/cli/commands/0.13upgrade"
"path": "cli/commands/workspace/show"
}
]
},
@ -349,70 +332,83 @@
"title": "Alphabetical list of commands",
"hidden": true,
"routes": [
{ "title": "Overview", "path": "commands" },
{ "title": "apply", "path": "commands/apply" },
{ "title": "console", "path": "commands/console" },
{ "title": "destroy", "path": "commands/destroy" },
{ "title": "env", "path": "commands/env" },
{ "title": "fmt", "path": "commands/fmt" },
{ "title": "force-unlock", "path": "commands/force-unlock" },
{ "title": "get", "path": "commands/get" },
{ "title": "graph", "path": "commands/graph" },
{ "title": "import", "path": "commands/import" },
{ "title": "init", "path": "commands/init" },
{ "title": "login", "path": "commands/login" },
{ "title": "logout", "path": "commands/logout" },
{ "title": "output", "path": "commands/output" },
{ "title": "plan", "path": "commands/plan" },
{ "title": "Overview", "path": "cli/commands/index" },
{ "title": "apply", "path": "cli/commands/apply" },
{ "title": "console", "path": "cli/commands/console" },
{ "title": "destroy", "path": "cli/commands/destroy" },
{ "title": "env", "path": "cli/commands/env" },
{ "title": "fmt", "path": "cli/commands/fmt" },
{ "title": "force-unlock", "path": "cli/commands/force-unlock" },
{ "title": "get", "path": "cli/commands/get" },
{ "title": "graph", "path": "cli/commands/graph" },
{ "title": "import", "path": "cli/commands/import" },
{ "title": "init", "path": "cli/commands/init" },
{ "title": "login", "path": "cli/commands/login" },
{ "title": "logout", "path": "cli/commands/logout" },
{ "title": "output", "path": "cli/commands/output" },
{ "title": "plan", "path": "cli/commands/plan" },
{
"title": "providers",
"routes": [
{ "title": "providers", "path": "commands/providers" },
{ "title": "providers lock", "path": "commands/providers/lock" },
{ "title": "providers mirror", "path": "commands/providers/mirror" },
{ "title": "providers schema", "path": "commands/providers/schema" }
{ "title": "providers", "path": "cli/commands/providers" },
{ "title": "providers lock", "path": "cli/commands/providers/lock" },
{
"title": "providers mirror",
"path": "cli/commands/providers/mirror"
},
{
"title": "providers schema",
"path": "cli/commands/providers/schema"
}
]
},
{ "title": "push (deprecated)", "path": "commands/push" },
{ "title": "refresh", "path": "commands/refresh" },
{ "title": "show", "path": "commands/show" },
{ "title": "refresh", "path": "cli/commands/refresh" },
{ "title": "show", "path": "cli/commands/show" },
{
"title": "state",
"routes": [
{ "title": "state", "path": "commands/state" },
{ "title": "state list", "path": "commands/state/list" },
{ "title": "state mv", "path": "commands/state/mv" },
{ "title": "state pull", "path": "commands/state/pull" },
{ "title": "state push", "path": "commands/state/push" },
{ "title": "state", "path": "cli/commands/state" },
{ "title": "state list", "path": "cli/commands/state/list" },
{ "title": "state mv", "path": "cli/commands/state/mv" },
{ "title": "state pull", "path": "cli/commands/state/pull" },
{ "title": "state push", "path": "cli/commands/state/push" },
{
"title": "state replace-provider",
"path": "commands/state/replace-provider"
"path": "cli/commands/state/replace-provider"
},
{ "title": "state rm", "path": "commands/state/rm" },
{ "title": "state show", "path": "commands/state/show" }
{ "title": "state rm", "path": "cli/commands/state/rm" },
{ "title": "state show", "path": "cli/commands/state/show" }
]
},
{ "title": "taint", "path": "commands/taint" },
{ "title": "test (deprecated)", "path": "commands/test", "hidden": true },
{ "title": "untaint", "path": "commands/untaint" },
{ "title": "validate", "path": "commands/validate" },
{ "title": "version", "path": "commands/version" },
{ "title": "taint", "path": "cli/commands/taint" },
{
"title": "test (deprecated)",
"path": "cli/commands/test",
"hidden": true
},
{ "title": "untaint", "path": "cli/commands/untaint" },
{ "title": "validate", "path": "cli/commands/validate" },
{ "title": "version", "path": "cli/commands/version" },
{
"title": "workspace",
"routes": [
{
"title": "workspace",
"path": "commands/workspace"
"path": "cli/commands/workspace"
},
{ "title": "workspace list", "path": "commands/workspace/list" },
{ "title": "workspace select", "path": "commands/workspace/select" },
{ "title": "workspace new", "path": "commands/workspace/new" },
{ "title": "workspace delete", "path": "commands/workspace/delete" },
{ "title": "workspace show", "path": "commands/workspace/show" }
{ "title": "workspace list", "path": "cli/commands/workspace/list" },
{
"title": "workspace select",
"path": "cli/commands/workspace/select"
},
{ "title": "workspace new", "path": "cli/commands/workspace/new" },
{
"title": "workspace delete",
"path": "cli/commands/workspace/delete"
},
{ "title": "workspace show", "path": "cli/commands/workspace/show" }
]
},
{ "title": "0.12upgrade", "path": "commands/0.12upgrade" },
{ "title": "0.13upgrade", "path": "commands/0.13upgrade" }
}
]
},
{
@ -421,14 +417,12 @@
"routes": [
{
"title": "APT Packages for Debian and Ubuntu",
"path": "install/apt"
"path": "cli/install/apt"
},
{
"title": "Yum Packages for Red Hat Enterprise Linux, Fedora, and Amazon Linux",
"path": "install/yum"
"path": "cli/install/yum"
}
]
},
{ "divider": true },
{ "title": "OpenTF Internals", "href": "/internals" }
}
]

41
website/data/internals-nav-data.json
View File

@ -1,65 +1,56 @@
[
{ "heading": "OpenTF Internals" },
{
"title": "Overview",
"path": ""
},
"title": "Overview",
"path": "internals/index"
},
{
"title": "Credentials Helpers",
"path": "credentials-helpers"
"path": "internals/credentials-helpers"
},
{
"title": "Debugging OpenTF",
"path": "debugging"
"path": "internals/debugging"
},
{
"title": "Module Registry Protocol",
"path": "module-registry-protocol"
"path": "internals/module-registry-protocol"
},
{
"title": "Provider Network Mirror Protocol",
"path": "provider-network-mirror-protocol"
"path": "internals/provider-network-mirror-protocol"
},
{
"title": "Provider Registry Protocol",
"path": "provider-registry-protocol"
"path": "internals/provider-registry-protocol"
},
{
"title": "Resource Graph",
"path": "graph"
"path": "internals/graph"
},
{
"title": "Login Protocol",
"path": "login-protocol"
"path": "internals/login-protocol"
},
{
"title": "JSON Output Format",
"path": "json-format"
"path": "internals/json-format"
},
{
"title": "Remote Service Discovery",
"path": "remote-service-discovery"
"path": "internals/remote-service-discovery"
},
{
"title": "Provider Metadata",
"path": "provider-meta"
"path": "internals/provider-meta"
},
{
"title": "Functions Metadata",
"path": "functions-meta"
"path": "internals/functions-meta"
},
{
"title": "Machine Readable UI",
"path": "machine-readable-ui",
"path": "internals/machine-readable-ui",
"hidden": true
},
{
"title": "Archiving",
"path": "archiving",
"hidden": true
},
{ "divider": true },
{ "title": "OpenTF CLI", "href": "/cli" },
{ "divider": true },
{ "title": "Configuration Language", "href": "/language" }
}
]

19
website/data/intro-nav-data.json
View File

@ -1,20 +1,19 @@
[
{ "heading": "Introduction to OpenTF" },
{ "title": "What is OpenTF?", "path": "" },
{ "title": "Use Cases", "path": "use-cases" },
{ "title": "OpenTF Editions", "path": "terraform-editions" },
{ "title": "The Core OpenTF Workflow", "path": "core-workflow" },
{ "title": "What is OpenTF?", "path": "intro/index" },
{ "title": "Use Cases", "path": "intro/use-cases" },
{ "title": "The Core OpenTF Workflow", "path": "intro/core-workflow" },
{
"title": "OpenTF vs. Alternatives",
"routes": [
{ "title": "Overview", "path": "vs" },
{ "title": "Chef, Puppet, etc.", "path": "vs/chef-puppet" },
{ "title": "Overview", "path": "intro/vs/index" },
{ "title": "Chef, Puppet, etc.", "path": "intro/vs/chef-puppet" },
{
"title": "CloudFormation, Heat, etc.",
"path": "vs/cloudformation"
"path": "intro/vs/cloudformation"
},
{ "title": "Boto, Fog, etc.", "path": "vs/boto" },
{ "title": "Custom Solutions", "path": "vs/custom" }
{ "title": "Boto, Fog, etc.", "path": "intro/vs/boto" },
{ "title": "Custom Solutions", "path": "intro/vs/custom" }
]
}
]
]

972
website/data/language-nav-data.json
View File

File diff suppressed because it is too large Load Diff

167
website/docs/intro/core-workflow.mdx
View File

@ -1,11 +1,11 @@
---
page_title: The Core Terraform Workflow - Guides
description: 'An overview of how individuals, teams, and organizations can use Terraform. '
page_title: The Core OpenTF Workflow - Guides
description: 'An overview of how individuals, teams, and organizations can use OpenTF. '
---
# The Core Terraform Workflow
# The Core OpenTF Workflow
The core Terraform workflow has three steps:
The core OpenTF workflow has three steps:
1. **Write** - Author infrastructure as code.
1. **Plan** - Preview changes before applying.
@ -13,7 +13,7 @@ The core Terraform workflow has three steps:
This guide walks through how each of these three steps plays out in the context
of working as an individual practitioner, how they evolve when a team is
collaborating on infrastructure, and how Terraform Cloud enables this
collaborating on infrastructure, and how a cloud backend enables this
workflow to run smoothly for entire organizations.
## Working as an Individual Practitioner
@ -23,7 +23,7 @@ on infrastructure as code.
### Write
You write Terraform configuration just like you write code: in your editor of
You write OpenTF configuration just like you write code: in your editor of
choice. It's common practice to store your work in a version controlled
repository even when you're just operating as an individual.
@ -36,12 +36,12 @@ Initialized empty Git repository in /.../my-infra/.git/
# Write initial config
$ vim main.tf
# Initialize Terraform
$ terraform init
# Initialize OpenTF
$ opentf init
Initializing provider plugins...
# ...
Terraform has been successfully initialized!
OpenTF has been successfully initialized!
```
As you make progress on authoring your config, repeatedly running plans can help
@ -53,7 +53,7 @@ expect.
$ vim main.tf
# Review plan
$ terraform plan
$ opentf plan
# Make additional edits, and repeat
$ vim main.tf
@ -75,12 +75,12 @@ $ git commit -m 'Managing infrastructure as code!'
1 file changed, 1 insertion(+)
```
Because `terraform apply` will display a plan for confirmation before
Because `opentf apply` will display a plan for confirmation before
proceeding to change any infrastructure, that's the command you run for final
review.
```sh
$ terraform apply
$ opentf apply
An execution plan has been generated and is shown below.
# ...
@ -88,13 +88,13 @@ An execution plan has been generated and is shown below.
### Apply
After one last check, you are ready to tell Terraform to provision real
After one last check, you are ready to tell OpenTF to provision real
infrastructure.
```sh
Do you want to perform these actions?
Terraform will perform the actions described above.
OpenTF will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
@ -116,11 +116,11 @@ the process over from the beginning.
Notice how closely this workflow parallels the process of writing application
code or scripts as an individual? This is what we mean when we talk about
Terraform enabling infrastructure as code.
OpenTF enabling infrastructure as code.
## Working as a Team
Once multiple people are collaborating on Terraform configuration, new steps
Once multiple people are collaborating on OpenTF configuration, new steps
must be added to each part of the core workflow to ensure everyone is working
together smoothly. You'll see that many of these steps parallel the workflow
changes we make when we work on application code as teams rather than as
@ -128,7 +128,7 @@ individuals.
### Write
While each individual on a team still makes changes to Terraform configuration
While each individual on a team still makes changes to OpenTF configuration
in their editor of choice, they save their changes to version control _branches_
to avoid colliding with each other's work. Working in branches enables team
members to resolve mutually incompatible infrastructure changes using their
@ -148,23 +148,20 @@ required to run a plan.
To avoid the burden and the security risk of each team member arranging all
sensitive inputs locally, it's common for teams to migrate to a model in which
Terraform operations are executed in a shared Continuous Integration (CI)
OpenTF operations are executed in a shared Continuous Integration (CI)
environment. The work needed to create such a CI environment is nontrivial, and
is outside the scope of this core workflow overview, but a full deep dive on
this topic can be found in our
[Running Terraform in Automation](/terraform/tutorials/automation/automate-terraform?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS)
guide.
is outside the scope of this core workflow overview.
This longer iteration cycle of committing changes to version control and then
waiting for the CI pipeline to execute is often lengthy enough to prohibit using
speculative plans as a feedback loop while authoring individual Terraform
configuration changes. Speculative plans are still useful before new Terraform
speculative plans as a feedback loop while authoring individual OpenTF
configuration changes. Speculative plans are still useful before new OpenTF
changes are applied or even merged to the main development branch, however, as
we'll see in a minute.
### Plan
For teams collaborating on infrastructure, Terraform's plan output creates an
For teams collaborating on infrastructure, OpenTF's plan output creates an
opportunity for team members to review each other's work. This allows the team
to ask questions, evaluate risks, and catch mistakes before any potentially
harmful changes are made.
@ -176,13 +173,11 @@ config changes alongside speculative plan output, they can evaluate whether the
intent of the change is being achieved by the plan.
The problem becomes producing that speculative plan output for the team to
review. Some teams that still run Terraform locally make a practice that pull
review. Some teams that still run OpenTF locally make a practice that pull
requests should include an attached copy of speculative plan output generated
by the change author. Others arrange for their CI system to post speculative
plan output to pull requests automatically.
![Screenshot of Pull Request with manually posted Terraform plan output](/img/docs/manually-pasted-plan-output.png)
In addition to reviewing the plan for the proper expression of its author's
intent, the team can also make an evaluation whether they want this change to
happen now. For example, if a team notices that a certain change could result
@ -207,125 +202,19 @@ anything in our system that we should be watching as we apply this? Is there
anyone we need to notify that this change is happening?
Depending on the change, sometimes team members will want to watch the apply
output as it is happening. For teams that are running Terraform locally, this
may involve a screen share with the team. For teams running Terraform in CI,
output as it is happening. For teams that are running OpenTF locally, this
may involve a screen share with the team. For teams running OpenTF in CI,
this may involve gathering around the build log.
Just like the workflow for individuals, the core workflow for teams is a loop
that plays out for each change. For some teams this loop happens a few times a
week, for others, many times a day.
## The Core Workflow Enhanced by Terraform Cloud
While the above described workflows enable the safe, predictable, and
reproducible creating or changing of infrastructure, there are multiple
collaboration points that can be streamlined, especially as teams and
organizations scale. We designed Terraform Cloud to support and enhance
the core Terraform workflow for anyone collaborating on infrastructure, from
small teams to large organizations. Let's look at how Terraform Cloud makes
for a better experience at each step.
### Write
Terraform Cloud provides a centralized and secure location for storing
input variables and state while also bringing back a tight feedback loop for
speculative plans for config authors. Terraform configuration can interact with
Terraform Cloud through the [CLI integration](/terraform/cli/cloud).
```
terraform {
cloud {
organization = "my-org"
hostname = "app.terraform.io" # Optional; defaults to app.terraform.io
workspaces {
tags = ["networking", "source:cli"]
}
}
}
```
After you configure the integration, a Terraform Cloud API key is all your team members need to edit config and run speculative plans
against the latest version of the state file using all the remotely stored
input variables.
```sh
$ terraform workspace select my-app-dev
Switched to workspace "my-app-dev".
$ terraform plan
Running plan remotely in Terraform Enterprise.
Output will stream here. To view this plan in a browser, visit:
https://app.terraform.io/my-org/my-app-dev/.../
Refreshing Terraform state in-memory prior to plan...
# ...
Plan: 1 to add, 0 to change, 0 to destroy.
```
With the assistance of this plan output, team members can each work on
authoring config until it is ready to propose as a change via a pull request.
### Plan
Once a pull request is ready for review, Terraform Cloud makes the process
of reviewing a speculative plan easier for team members. First, the plan is
automatically run when the pull request is created. Status updates to the pull
request indicate while the plan is in progress.
Once the plan is complete, the status update indicates whether there were any
changes in the speculative plan, right from the pull request view.
![Screenshot of Pull Request with resource changes in the status update](/img/docs/pull-request.png)
For certain types of changes, this information is all that's needed for a team
member to be able to approve the pull request. When a teammate needs to do a
full review of the plan, clicking the link to Terraform Cloud brings up a
view that allows them to quickly analyze the full plan details.
![Screenshot of Pull Request run in Terraform Cloud](/img/docs/pr-plan.png)
This page allows the reviewer to quickly determine if the plan is matching the
config author's intent and evaluate the risk of the change.
### Apply
After merge, Terraform Cloud presents the concrete plan to the team for
review and approval.
![Screenshot of concrete plan](/img/docs/concrete-plan.png)
The team can discuss any outstanding questions about the plan before the change
is made.
![Screenshot of back-and-forth in Terraform Cloud comments](/img/docs/plan-comments.png)
Once the Apply is confirmed, Terraform Cloud displays the progress live
to anyone who'd like to watch.
![Screenshot of in-progress Apply](/img/docs/in-progress-apply.png)
<!--
TODO: Add this back in w/ screenshot of notification
And after the change completes, the team can be notified of its outcome.
[ Multi-screenshot of Slack alert indicating Apply completed successfully and
with error; except it's not gonna be Slack anymore? ]
-->
## Conclusion
There are many different ways to use Terraform: as an individual user, a single
There are many different ways to use OpenTF: as an individual user, a single
team, or an entire organization at scale. Choosing the best approach for the
density of collaboration needed will provide the most return on your investment
in the core Terraform workflow. For organizations using Terraform at scale,
Terraform Cloud introduces new layers that build on this core workflow to
in the core OpenTF workflow. For organizations using OpenTF at scale,
TACOS (TF Automation and Collaboration Software) introduces new layers that build on this core workflow to
solve problems unique to teams and organizations.

47
website/docs/intro/index.mdx
View File

@ -1,65 +1,58 @@
---
layout: "intro"
page_title: "What is Terraform"
page_title: "What is OpenTF"
sidebar_current: "what"
description: |-
Terraform is an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently.
OpenTF is an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently.
---
# What is Terraform?
# What is OpenTF?
HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features.
OpenTF is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. OpenTF can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features.
> **Hands On:** Try the Get Started tutorials to start managing infrastructure on popular cloud providers: [Amazon Web Services](/terraform/tutorials/aws-get-started), [Azure](/terraform/tutorials/azure-get-started), [Google Cloud Platform](/terraform/tutorials/gcp-get-started), [Oracle Cloud Infrastructure](/terraform/tutorials/oci-get-started), and [Docker](/terraform/tutorials/docker-get-started).
## How does OpenTF work?
## How does Terraform work?
Terraform creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs). Providers enable Terraform to work with virtually any platform or service with an accessible API.
OpenTF creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs). Providers enable OpenTF to work with virtually any platform or service with an accessible API.
![Terraform creates and manages cloud platforms and services through their APIs](/img/docs/intro-terraform-apis.png)
![OpenTF creates and manages cloud platforms and services through their APIs](/img/docs/intro-opentf-apis.png)
HashiCorp and the Terraform community have already written **thousands of providers** to manage many different types of resources and services. You can find all publicly available providers on the [Terraform Registry](https://registry.terraform.io/), including Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, and many more.
The OpenTF community have already written **thousands of providers** to manage many different types of resources and services. You can find all publicly available providers on the [Public Terraform Registry](https://registry.terraform.io/), including Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, and many more.
The core Terraform workflow consists of three stages:
The core OpenTF workflow consists of three stages:
- **Write:** You define resources, which may be across multiple cloud providers and services. For example, you might create a configuration to deploy an application on virtual machines in a Virtual Private Cloud (VPC) network with security groups and a load balancer.
- **Plan:** Terraform creates an execution plan describing the infrastructure it will create, update, or destroy based on the existing infrastructure and your configuration.
- **Apply:** On approval, Terraform performs the proposed operations in the correct order, respecting any resource dependencies. For example, if you update the properties of a VPC and change the number of virtual machines in that VPC, Terraform will recreate the VPC before scaling the virtual machines.
- **Plan:** OpenTF creates an execution plan describing the infrastructure it will create, update, or destroy based on the existing infrastructure and your configuration.
- **Apply:** On approval, OpenTF performs the proposed operations in the correct order, respecting any resource dependencies. For example, if you update the properties of a VPC and change the number of virtual machines in that VPC, OpenTF will recreate the VPC before scaling the virtual machines.
![The Terraform workflow has three steps: Write, Plan, and Apply](/img/docs/intro-terraform-workflow.png)
## Why Terraform?
HashiCorp co-founder and CTO Armon Dadgar explains how Terraform solves infrastructure challenges.
<iframe src="https://www.youtube.com/embed/h970ZBgKINg" frameborder="0" allowfullscreen="true" width="560" height="315" ></iframe>
![The OpenTF workflow has three steps: Write, Plan, and Apply](/img/docs/intro-opentf-workflow.png)
## Why OpenTF?
### Manage any infrastructure
Find providers for many of the platforms and services you already use in the [Terraform Registry](https://registry.terraform.io/). You can also [write your own](/terraform/plugin). Terraform takes an [immutable approach to infrastructure](https://www.hashicorp.com/resources/what-is-mutable-vs-immutable-infrastructure), reducing the complexity of upgrading or modifying your services and infrastructure.
Find providers for many of the platforms and services you already use in the [Public Terraform Registry](https://registry.terraform.io/). You can also [write your own](/opentf/plugin). OpenTF takes an [immutable approach to infrastructure](https://www.hashicorp.com/resources/what-is-mutable-vs-immutable-infrastructure), reducing the complexity of upgrading or modifying your services and infrastructure.
### Track your infrastructure
Terraform generates a plan and prompts you for your approval before modifying your infrastructure. It also keeps track of your real infrastructure in a [state file](/terraform/language/state), which acts as a source of truth for your environment. Terraform uses the state file to determine the changes to make to your infrastructure so that it will match your configuration.
OpenTF generates a plan and prompts you for your approval before modifying your infrastructure. It also keeps track of your real infrastructure in a [state file](/opentf/language/state), which acts as a source of truth for your environment. OpenTF uses the state file to determine the changes to make to your infrastructure so that it will match your configuration.
### Automate changes
Terraform configuration files are declarative, meaning that they describe the end state of your infrastructure. You do not need to write step-by-step instructions to create resources because Terraform handles the underlying logic. Terraform builds a resource graph to determine resource dependencies and creates or modifies non-dependent resources in parallel. This allows Terraform to provision resources efficiently.
OpenTF configuration files are declarative, meaning that they describe the end state of your infrastructure. You do not need to write step-by-step instructions to create resources because OpenTF handles the underlying logic. OpenTF builds a resource graph to determine resource dependencies and creates or modifies non-dependent resources in parallel. This allows OpenTF to provision resources efficiently.
### Standardize configurations
Terraform supports reusable configuration components called [modules](/terraform/language/modules) that define configurable collections of infrastructure, saving time and encouraging best practices. You can use publicly available modules from the Terraform Registry, or write your own.
OpenTF supports reusable configuration components called [modules](/opentf/language/modules) that define configurable collections of infrastructure, saving time and encouraging best practices. You can use publicly available modules from the Terraform Registry, or write your own.
### Collaborate
Since your configuration is written in a file, you can commit it to a Version Control System (VCS) and use [Terraform Cloud](/terraform/intro/terraform-editions#terraform-cloud) to efficiently manage Terraform workflows across teams. Terraform Cloud runs Terraform in a consistent, reliable environment and provides secure access to shared state and secret data, role-based access controls, a private registry for sharing both modules and providers, and more.
Since your configuration is written in a file, you can commit it to a Version Control System (VCS) and use a cloud backend to efficiently manage OpenTF workflows across teams. A cloud backend runs OpenTF in a consistent, reliable environment and provides secure access to shared state and secret data, role-based access controls, a private registry for sharing both modules and providers, and more.
-> **Tip:** Learn more about [Terraform use cases](/terraform/intro/use-cases) and [how Terraform compares to alternatives](/terraform/intro/vs).
-> **Tip:** Learn more about [OpenTF use cases](/opentf/intro/use-cases) and [how OpenTF compares to alternatives](/opentf/intro/vs).
## Community
We welcome questions, suggestions, and contributions from the community.
- Ask questions in [HashiCorp Discuss](https://discuss.hashicorp.com/c/terraform-core/27).
- Ask questions in [OpenTF Discuss](https://github.com/placeholderplaceholderplaceholder/opentf/discussions).
- Read our [contributing guide](https://github.com/placeholderplaceholderplaceholder/opentf/blob/main/.github/CONTRIBUTING.md).
- [Submit an issue](https://github.com/placeholderplaceholderplaceholder/opentf/issues/new/choose) for bugs and feature requests.

70
website/docs/intro/terraform-editions.mdx
View File

@ -1,70 +0,0 @@
---
layout: "intro"
page_title: "Terraform Editions"
sidebar_current: "what"
description: |-
Terraform Open Source, Terraform Cloud, and Terraform Enterprise solve increasingly complex infrastructure and collaboration challenges.
---
# Terraform Editions
As your organization adopts infrastructure as code (IaC), you will encounter increasingly complex technical and collaboration challenges. We offer three Terraform editions designed to help you solve them.
## Terraform Open Source
Terraform open source is a free, downloadable tool that you interact with on the command line. It lets you provision infrastructure on any cloud provider and manages configuration, plugins, infrastructure, and state.
### Why Terraform Open Source?
Terraform open source lets you:
- Adopt infrastructure as code and use a common configuration language to provision thousands of different types of resources and services.
- Codify your infrastructure so that you can check configuration files into a version control system (VCS) to safely manage contributions. Manually pull the most up-to-date version to perform Terraform operations.
- Use and publish public infrastructure templates called modules to implement industry and organization best practices, group your infrastructure into logically-related components, and deploy infrastructure more quickly.
### Resources
- Get Started tutorials for popular providers: [Amazon Web Services](/terraform/tutorials/aws-get-started), [Azure](/terraform/tutorials/azure-get-started), [Google Cloud Platform](/terraform/tutorials/gcp-get-started), [Oracle Cloud Infrastructure](/terraform/tutorials/oci-get-started), and [Docker](/terraform/tutorials/docker-get-started)
- [What is Terraform?](/terraform/intro)
- [Configuration Language Documentation](/terraform/language)
- [CLI Documentation](/terraform/cli)
## Terraform Cloud
Terraform Cloud is a SaaS application that runs Terraform in a stable, remote environment and securely stores state and secrets. It includes a rich user interface that helps you better understand your Terraform operations and resources, allows you to define role-based access controls, and offers a private registry for sharing modules and providers. Terraform Cloud also integrates with the Terraform CLI and connects to common version control systems (VCS) like GitHub, GitLab, and Bitbucket. When you connect a Terraform Cloud workspace to a VCS repository, new commits and changes can automatically trigger Terraform plans. Terraform Cloud also offers an API, allowing you to integrate it into existing workflows.
Many Terraform Cloud features are free for small teams; we offer paid plans for larger organizations with additional collaboration and governance features.
### Why Terraform Cloud?
Terraform Cloud lets you:
- Run Terraform from the local CLI or in a remote environment, trigger operations through your version control system, or use an API to integrate Terraform Cloud into your existing workflows.
- Ensure that only approved teams can access, edit, and provision infrastructure with Terraform Cloud workspaces, single sign-on, and role-based access controls.
- Securely store and version Terraform state remotely, with encryption at rest. Versioned state files allow you to access state file history.
- Publish configuration modules in the Terraform Cloud private registry that define approved infrastructure patterns. For example, a module may allow users to choose the cloud provider on which to deploy their Java application. This allows consumers to implement your organization’s best practices without becoming infrastructure or cloud experts.
- Enforce best practices and security rules with the Sentinel embedded policy as code framework. For example, policies may restrict regions for production deployments.
### Resources
- [Create a Terraform Cloud Account](https://app.terraform.io/public/signup/account)
- [Terraform Cloud Documentation](/terraform/cloud-docs)
- [Sentinel Documentation](/terraform/cloud-docs/policy-enforcement)
- [Get Started - Terraform Cloud](/terraform/tutorials/cloud-get-started) tutorials show you how to manage infrastructure using Terraform Cloud's VCS integration
## Terraform Enterprise
Terraform Enterprise allows you to set up a self-hosted distribution of Terraform Cloud. It offers customizable resource limits and is ideal for organizations with strict security and compliance requirements.
### Why Terraform Enterprise?
Terraform Enterprise lets you:
- Set up a private instance of Terraform Cloud with dedicated support from HashiCorp.
- Accommodate advanced security and compliance requirements. Terraform Enterprise supports several types of installations, including air gapped and active/active architecture, and allows private networking and job scaling for better performance.
### Resources
- [Terraform Pricing](https://www.hashicorp.com/products/terraform/pricing)
- [Terraform Enterprise Documentation](/terraform/enterprise)
- [Recommended Enterprise Patterns](/terraform/tutorials/recommended-patterns) guides

69
website/docs/intro/use-cases.mdx
View File

@ -3,90 +3,51 @@ layout: "intro"
page_title: "Use Cases"
sidebar_current: "use-cases"
description: |-
Learn how Terraform enables multi-cloud deployments, application management, policy compliance, and self-service infrastructure.
Learn how OpenTF enables multi-cloud deployments, application management, policy compliance, and self-service infrastructure.
---
# Use Cases
[HashiCorp Terraform](/terraform/intro) is an infrastructure as code tool that lets you define infrastructure resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to safely and efficiently provision and manage your infrastructure throughout its lifecycle.
[OpenTF](/opentf/intro) is an infrastructure as code tool that lets you define infrastructure resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to safely and efficiently provision and manage your infrastructure throughout its lifecycle.
This page describes popular Terraform use cases and provides related resources that you can use to create Terraform configurations and workflows.
This page describes popular OpenTF use cases and provides related resources that you can use to create OpenTF configurations and workflows.
## Multi-Cloud Deployment
Provisioning infrastructure across multiple clouds increases fault-tolerance, allowing for more graceful recovery from cloud provider outages. However, multi-cloud deployments add complexity because each provider has its own interfaces, tools, and workflows. Terraform lets you use the same workflow to manage multiple providers and handle cross-cloud dependencies. This simplifies management and orchestration for large-scale, multi-cloud infrastructures.
Provisioning infrastructure across multiple clouds increases fault-tolerance, allowing for more graceful recovery from cloud provider outages. However, multi-cloud deployments add complexity because each provider has its own interfaces, tools, and workflows. OpenTF lets you use the same workflow to manage multiple providers and handle cross-cloud dependencies. This simplifies management and orchestration for large-scale, multi-cloud infrastructures.
### Resources
- Try our [Deploy Federated Multi-Cloud Kubernetes Clusters](/terraform/tutorials/networking/multicloud-kubernetes) tutorial to provision Kubernetes clusters in both Azure and AWS environments, configure Consul federation with mesh gateways across the two clusters, and deploy microservices across the two clusters to verify federation.
- Browse the [Terraform Registry](https://registry.terraform.io/browse/providers) to find thousands of publicly available providers.
- Browse the [Public Terraform Registry](https://registry.terraform.io/browse/providers) to find thousands of publicly available providers.
## Application Infrastructure Deployment, Scaling, and Monitoring Tools
You can use Terraform to efficiently deploy, release, scale, and monitor infrastructure for multi-tier applications. N-tier application architecture lets you scale application components independently and provides a separation of concerns. An application could consist of a pool of web servers that use a database tier, with additional tiers for API servers, caching servers, and routing meshes. Terraform allows you to manage the resources in each tier together, and automatically handles dependencies between tiers. For example, Terraform will deploy a database tier before provisioning the web servers that depend on it.
### Resources
- Try our [Automate Monitoring with the Terraform Datadog Provider](/terraform/tutorials/applications/datadog-provider) tutorial to deploy a demo Nginx application to a Kubernetes cluster with Helm and install the Datadog agent across the cluster. The Datadog agent reports the cluster health back to your Datadog dashboard.
- Try our [Use Application Load Balancers for Blue-Green and Canary Deployments](/terraform/tutorials/aws/blue-green-canary-tests-deployments) tutorial. You will provision the blue and green environments, add feature toggles to your Terraform configuration to define a list of potential deployment strategies, conduct a canary test, and incrementally promote your green environment.
You can use OpenTF to efficiently deploy, release, scale, and monitor infrastructure for multi-tier applications. N-tier application architecture lets you scale application components independently and provides a separation of concerns. An application could consist of a pool of web servers that use a database tier, with additional tiers for API servers, caching servers, and routing meshes. OpenTF allows you to manage the resources in each tier together, and automatically handles dependencies between tiers. For example, OpenTF will deploy a database tier before provisioning the web servers that depend on it.
## Self-Service Clusters
At a large organization, your centralized operations team may get many repetitive infrastructure requests. You can use Terraform to build a "self-serve" infrastructure model that lets product teams manage their own infrastructure independently. You can create and use Terraform modules that codify the standards for deploying and managing services in your organization, allowing teams to efficiently deploy services in compliance with your organization’s practices. Terraform Cloud can also integrate with ticketing systems like ServiceNow to automatically generate new infrastructure requests.
### Resources
- Try the [Use Modules from the Registry](/terraform/tutorials/modules/module-use) tutorial to get started using public modules in your Terraform configuration.
Try the [Build and Use a Local Module](/terraform/tutorials/modules/module-create) tutorial to create a module to manage AWS S3 buckets.
- Follow these [ServiceNow Service Catalog Integration Setup Instructions](/terraform/cloud-docs/integrations/service-now) to connect ServiceNow to Terraform Cloud.
At a large organization, your centralized operations team may get many repetitive infrastructure requests. You can use OpenTF to build a "self-serve" infrastructure model that lets product teams manage their own infrastructure independently. You can create and use OpenTF modules that codify the standards for deploying and managing services in your organization, allowing teams to efficiently deploy services in compliance with your organization’s practices. A cloud backend can also integrate with ticketing systems like ServiceNow to automatically generate new infrastructure requests.
## Policy Compliance and Management
Terraform can help you enforce policies on the types of resources teams can provision and use. Ticket-based review processes are a bottleneck that can slow down development. Instead, you can use Sentinel, a policy-as-code framework, to automatically enforce compliance and governance policies before Terraform makes infrastructure changes. Sentinel policies are available in Terraform Enterprise and [Terraform Cloud](https://www.hashicorp.com/products/terraform/pricing).
### Resources
- Try the [Control Costs with Policies](/terraform/tutorials/cloud-get-started/cost-estimation) tutorial to estimate the cost of infrastructure changes and define policy to limit it.
- The [Sentinel documentation](/terraform/cloud-docs/policy-enforcement) provides more in-depth information and a list of example policies that you can adapt for your use cases.
OpenTF can help you enforce policies on the types of resources teams can provision and use. Ticket-based review processes are a bottleneck that can slow down development. Instead, you can use Sentinel, a policy-as-code framework, to automatically enforce compliance and governance policies before OpenTF makes infrastructure changes. Sentinel policies are available in cloud backends.
## PaaS Application Setup
Platform as a Service (PaaS) vendors like Heroku allow you to create web applications and attach add-ons, such as databases or email providers. Heroku can elastically scale the number of dynos or workers, but most non-trivial applications need many add-ons and external services. You can use Terraform to codify the setup required for a Heroku application, configure a DNSimple to set a CNAME, and set up Cloudflare as a Content Delivery Network (CDN) for the app. Terraform can quickly and consistently do all of this without a web interface.
### Resources
Try the [Deploy, Manage, and Scale an Application on Heroku](/terraform/tutorials/applications/heroku-provider) tutorial to manage an application’s lifecycle with Terraform.
Platform as a Service (PaaS) vendors like Heroku allow you to create web applications and attach add-ons, such as databases or email providers. Heroku can elastically scale the number of dynos or workers, but most non-trivial applications need many add-ons and external services. You can use OpenTF to codify the setup required for a Heroku application, configure a DNSimple to set a CNAME, and set up Cloudflare as a Content Delivery Network (CDN) for the app. OpenTF can quickly and consistently do all of this without a web interface.
## Software Defined Networking
Terraform can interact with Software Defined Networks (SDNs) to automatically configure the network according to the needs of the applications running in it. This lets you move from a ticket-based workflow to an automated one, reducing deployment times.
For example, when a service registers with [HashiCorp Consul](https://www.consul.io/), [Consul-Terraform-Sync](/consul/docs/nia) can automatically generate Terraform configuration to expose appropriate ports and adjust network settings for any SDN that has an associated Terraform provider. Network Infrastructure Automation (NIA) allows you to safely approve the changes that your applications require without having to manually translate tickets from developers into the changes you think their applications need.
### Resources
- Try the [Network Infrastructure Automation with Consul-Terraform-Sync Intro](/consul/tutorials/network-infrastructure-automation/consul-terraform-sync-intro) tutorial to install Consul-Terraform-Sync on a node. You will then configure it to communicate with a Consul datacenter, react to service changes, and execute an example task.
- Try the [Consul-Terraform-Sync and Terraform Enterprise/Cloud Integration](/consul/tutorials/network-infrastructure-automation/consul-terraform-sync-terraform-enterprise) tutorial to configure Consul-Terraform-Sync to interact with Terraform Enterprise and Terraform Cloud.
OpenTF can interact with Software Defined Networks (SDNs) to automatically configure the network according to the needs of the applications running in it. This lets you move from a ticket-based workflow to an automated one, reducing deployment times.
## Kubernetes
Kubernetes is an open-source workload scheduler for containerized applications. Terraform lets you both deploy a Kubernetes cluster and manage its resources (e.g., pods, deployments, services, etc.). You can also use the [Kubernetes Operator for Terraform](https://github.com/hashicorp/terraform-k8s) to manage cloud and on-prem infrastructure through a Kubernetes Custom Resource Definition (CRD) and Terraform Cloud.
### Resources
- Try the [Manage Kubernetes Resources via Terraform](/terraform/tutorials/kubernetes/kubernetes-provider) tutorial. You will use Terraform to schedule and expose a NGINX deployment on a Kubernetes cluster.
- Try the [Deploy Infrastructure with the Terraform Cloud Operator for Kubernetes](/terraform/tutorials/kubernetes/kubernetes-operator) tutorial. You will configure and deploy the Operator to a Kubernetes cluster and use it to create a Terraform Cloud workspace and provision a message queue for an example application.
Kubernetes is an open-source workload scheduler for containerized applications. OpenTF lets you both deploy a Kubernetes cluster and manage its resources (e.g., pods, deployments, services, etc.).
## Parallel Environments
You may have staging or QA environments that you use to test new applications before releasing them in production. As the production environment grows larger and more complex, it can be increasingly difficult to maintain an up-to-date environment for each stage of the development process. Terraform lets you rapidly spin up and decommission infrastructure for development, test, QA, and production. Using Terraform to create disposable environments as needed is more cost-efficient than maintaining each one indefinitely.
You may have staging or QA environments that you use to test new applications before releasing them in production. As the production environment grows larger and more complex, it can be increasingly difficult to maintain an up-to-date environment for each stage of the development process. OpenTF lets you rapidly spin up and decommission infrastructure for development, test, QA, and production. Using OpenTF to create disposable environments as needed is more cost-efficient than maintaining each one indefinitely.
## Software Demos
You can use Terraform to create, provision, and bootstrap a demo on various cloud providers. This lets end users easily try the software on their own infrastructure and even enables them to adjust parameters like cluster size to more rigorously test tools at any scale.
You can use OpenTF to create, provision, and bootstrap a demo on various cloud providers. This lets end users easily try the software on their own infrastructure and even enables them to adjust parameters like cluster size to more rigorously test tools at any scale.

10
website/docs/intro/vs/boto.mdx
View File

@ -1,9 +1,9 @@
---
page_title: 'Terraform vs. Boto, Fog, etc.'
description: 'How Terraform compares to cloud provider client libraries like Boto and Fog. '
page_title: 'OpenTF vs. Boto, Fog, etc.'
description: 'How OpenTF compares to cloud provider client libraries like Boto and Fog. '
---
# Terraform vs. Boto, Fog, etc.
# OpenTF vs. Boto, Fog, etc.
Libraries like Boto, Fog, etc. are used to provide native access
to cloud providers and services by using their APIs. Some
@ -12,9 +12,9 @@ to bridge them all and mask the semantic differences. Using a client
library only provides low-level access to APIs, requiring application
developers to create their own tooling to build and manage their infrastructure.
Terraform is not intended to give low-level programmatic access to
OpenTF is not intended to give low-level programmatic access to
providers, but instead provides a high level syntax for describing
how cloud resources and services should be created, provisioned, and
combined. Terraform is very flexible, using a plugin-based model to
combined. OpenTF is very flexible, using a plugin-based model to
support providers and provisioners, giving it the ability to support
almost any service that exposes APIs.

12
website/docs/intro/vs/chef-puppet.mdx
View File

@ -1,23 +1,23 @@
---
page_title: 'Terraform vs. Chef, Puppet, etc.'
page_title: 'OpenTF vs. Chef, Puppet, etc.'
description: >-
How Terraform compares to configuration management tools like Chef and
How OpenTF compares to configuration management tools like Chef and
Puppet.
---
# Terraform vs. Chef, Puppet, etc.
# OpenTF vs. Chef, Puppet, etc.
Configuration management tools install and manage software on a machine
that already exists. Terraform is not a configuration management tool,
that already exists. OpenTF is not a configuration management tool,
and it allows existing tooling to focus on their strengths: bootstrapping
and initializing resources.
Terraform focuses on the higher-level abstraction of the datacenter and
OpenTF focuses on the higher-level abstraction of the datacenter and
associated services, while allowing you to use configuration management
tools on individual systems. It also aims to bring the same benefits of
codification of your system configuration to infrastructure management.
If you are using traditional configuration management within your compute
instances, you can use Terraform to configure bootstrapping software like
instances, you can use OpenTF to configure bootstrapping software like
cloud-init to activate your configuration management software on first
system boot.

24
website/docs/intro/vs/cloudformation.mdx
View File

@ -1,39 +1,39 @@
---
page_title: 'Terraform vs. CloudFormation, Heat, etc.'
page_title: 'OpenTF vs. CloudFormation, Heat, etc.'
description: >-
How Terraform compares to other infrastructure as code tools like
CloudFormation and Heat. Terraform can simultaneously manage multiple cloud
How OpenTF compares to other infrastructure as code tools like
CloudFormation and Heat. OpenTF can simultaneously manage multiple cloud
providers (AWS, OpenStack, etc.) and services (Cloudflare, DNSimple, etc.).
---
# Terraform vs. CloudFormation, Heat, etc.
# OpenTF vs. CloudFormation, Heat, etc.
Tools like CloudFormation, Heat, etc. allow the details of an infrastructure
to be codified into a configuration file. The configuration files allow
the infrastructure to be elastically created, modified and destroyed. Terraform
the infrastructure to be elastically created, modified and destroyed. OpenTF
is inspired by the problems they solve.
Terraform similarly uses configuration files to detail the infrastructure
OpenTF similarly uses configuration files to detail the infrastructure
setup, but it goes further by being both cloud-agnostic and enabling
multiple providers and services to be combined and composed. For example,
Terraform can be used to orchestrate an AWS and OpenStack cluster simultaneously,
OpenTF can be used to orchestrate an AWS and OpenStack cluster simultaneously,
while enabling 3rd-party providers like Cloudflare and DNSimple to be integrated
to provide CDN and DNS services. This enables Terraform to represent and
to provide CDN and DNS services. This enables OpenTF to represent and
manage the entire infrastructure with its supporting services, instead of
only the subset that exists within a single provider. It provides a single
unified syntax, instead of requiring operators to use independent and
non-interoperable tools for each platform and service.
Terraform also separates the planning phase from the execution phase,
by using the concept of an execution plan. By running `terraform plan`,
OpenTF also separates the planning phase from the execution phase,
by using the concept of an execution plan. By running `opentf plan`,
the current state is refreshed and the configuration is consulted to
generate an action plan. The plan includes all actions to be taken:
which resources will be created, destroyed or modified. It can be
inspected by operators to ensure it is exactly what is expected. Using
`terraform graph`, the plan can be visualized to show dependent ordering.
`opentf graph`, the plan can be visualized to show dependent ordering.
Once the plan is captured, the execution phase can be limited to only
the actions in the plan. Other tools combine the planning and execution
phases, meaning operators are forced to mentally reason about the effects
of a change, which quickly becomes intractable in large infrastructures.
Terraform lets operators apply changes with confidence, as they know exactly
OpenTF lets operators apply changes with confidence, as they know exactly
what will happen beforehand.

18
website/docs/intro/vs/custom.mdx
View File

@ -1,11 +1,11 @@
---
page_title: Terraform vs. Custom Solutions
page_title: OpenTF vs. Custom Solutions
description: >-
Why Terraform is easier to use and maintain than custom, internal
Why OpenTF is easier to use and maintain than custom, internal
infrastructure solutions.
---
# Terraform vs. Custom Solutions
# OpenTF vs. Custom Solutions
Most organizations start by manually managing infrastructure through
simple scripts or web-based interfaces. As the infrastructure grows,
@ -22,7 +22,7 @@ updated in lockstep with any new features or infrastructure,
it becomes the limiting factor for how quickly the infrastructure
can evolve.
Terraform is designed to tackle these challenges. It provides a simple,
OpenTF is designed to tackle these challenges. It provides a simple,
unified syntax, allowing almost any resource to be managed without
learning new tooling. By capturing all the resources required, the
dependencies between them can be resolved automatically so that operators
@ -30,9 +30,9 @@ do not need to remember and reason about them. Removing the burden
of building the tool allows operators to focus on their infrastructure
and not the tooling.
Furthermore, Terraform is an open source tool. In addition to
HashiCorp, the community around Terraform helps to extend its features,
fix bugs and document new use cases. Terraform helps solve a problem
that exists in every organization and provides a standard that can
be adopted to avoid reinventing the wheel between and within organizations.
Furthermore, OpenTF is an open source tool. The community around OpenTF
helps to extend its features, fix bugs and document new use cases.
OpenTF helps solve a problem that exists in every organization and provides
a standard that can be adopted to avoid reinventing the wheel between
and within organizations.
Its open source nature ensures it will be around in the long term.

24
website/docs/intro/vs/index.mdx
View File

@ -1,22 +1,22 @@
---
page_title: Terraform vs. Alternatives
description: An overview of how Terraform compares to alternative software and tools.
page_title: OpenTF vs. Alternatives
description: An overview of how OpenTF compares to alternative software and tools.
---
# Terraform vs. Alternatives
# OpenTF vs. Alternatives
Terraform provides a flexible abstraction of resources and providers. This model
OpenTF provides a flexible abstraction of resources and providers. This model
allows for representing everything from physical hardware, virtual machines, and
containers, to email and DNS providers. Because of this flexibility, Terraform
containers, to email and DNS providers. Because of this flexibility, OpenTF
can be used to solve many different problems. This means there are a number of
existing tools that overlap with the capabilities of Terraform. We compare Terraform
to a number of these tools, but it should be noted that Terraform is not mutually
existing tools that overlap with the capabilities of OpenTF. We compare OpenTF
to a number of these tools, but it should be noted that OpenTF is not mutually
exclusive with other systems. It can be used to manage a single application, or the
entire datacenter.
Learn how Terraform compares to:
Learn how OpenTF compares to:
- [Chef, Puppet, etc.](/terraform/intro/vs/chef-puppet)
- [CloudFormation, Heat, etc.](/terraform/intro/vs/cloudformation)
- [Boto, Fog, etc.](/terraform/intro/vs/boto)
- [Custom Solutions](/terraform/intro/vs/custom)
- [Chef, Puppet, etc.](/opentf/intro/vs/chef-puppet)
- [CloudFormation, Heat, etc.](/opentf/intro/vs/cloudformation)
- [Boto, Fog, etc.](/opentf/intro/vs/boto)
- [Custom Solutions](/opentf/intro/vs/custom)

27
website/docs/language/attr-as-blocks.mdx
View File

@ -9,7 +9,7 @@ description: >-
# Attributes as Blocks
-> **Note:** This page is an appendix to the Terraform documentation. Most users do not need to know the full details of this behavior.
-> **Note:** This page is an appendix to the OpenTF documentation. Most users do not need to know the full details of this behavior.
## Summary
@ -23,14 +23,14 @@ is set to an empty list (`<ATTR> = []`).
Most users do not need to know any further details of this "nested block or
empty list" behavior. However, read further if you need to:
- Use Terraform's [JSON syntax](/terraform/language/syntax/json) with this
- Use OpenTF's [JSON syntax](/opentf/language/syntax/json) with this
type of resource.
- Create a reusable module that wraps this type of resource.
## Details
In Terraform v0.12 and later, the language makes a distinction between
[argument syntax and nested block syntax](/terraform/language/syntax/configuration#arguments-and-blocks)
The language makes a distinction between
[argument syntax and nested block syntax](/opentf/language/syntax/configuration#arguments-and-blocks)
within blocks:
- Argument syntax sets a named argument for the containing object. If the
@ -44,24 +44,11 @@ within blocks:
merging in with any explicitly-defined arguments.
The distinction between these is particularly important for
[JSON syntax](/terraform/language/syntax/json)
[JSON syntax](/opentf/language/syntax/json)
because the same primitive JSON constructs (lists and objects) will be
interpreted differently depending on whether a particular name is an argument
or a nested block type.
However, in some cases existing provider features were relying on the
conflation of these two concepts in the language of Terraform v0.11 and earlier,
using nested block syntax in most cases but using argument syntax to represent
explicitly the idea of removing all existing objects of that type, since the
absence of any blocks was interpreted as "ignore any existing objects".
The information on this page only applies to certain special arguments that
were relying on this usage pattern prior to Terraform v0.12. The documentation
for each of those features links to this page for details of the special usage
patterns that apply. In all other cases, use either argument or nested block
syntax as directed by the examples in the documentation for a particular
resource type.
## Defining a Fixed Object Collection Value
When working with resource type arguments that behave in this way, it is valid
@ -151,7 +138,7 @@ example = [
For the arguments that use the attributes-as-blocks usage mode, the above is
a better pattern than using
[`dynamic` blocks](/terraform/language/expressions/dynamic-blocks)
[`dynamic` blocks](/opentf/language/expressions/dynamic-blocks)
because the case where the
caller provides an empty list will result in explicitly assigning an empty
list value, rather than assigning no value at all and thus retaining and
@ -161,7 +148,7 @@ dynamically-generating _normal_ nested blocks, though.
## In JSON syntax
Arguments that use this special mode are specified in JSON syntax always using
the [JSON expression mapping](/terraform/language/syntax/json#expression-mapping)
the [JSON expression mapping](/opentf/language/syntax/json#expression-mapping)
to produce a list of objects.
The interpretation of these values in JSON syntax is, therefore, equivalent

4
website/docs/language/data-sources/index.mdx
View File

@ -107,7 +107,7 @@ For example, local-only data sources exist for
[rendering AWS IAM policies](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/iam_policy_document).
The behavior of local-only data sources is the same as all other data
sources, but their result data exists only temporarily during a OpenTF
sources, but their result data exists only temporarily during an OpenTF
operation, and is re-calculated each time a new plan is created.
## Data Resource Dependencies
@ -199,7 +199,7 @@ and name must be unique.
Within the block (the `{ }`) is configuration for the data instance. The
configuration is dependent on the type; as with
[resources](/opentf/language/resources), each provider on the
[Provider Registry](https://registry.terraform.io/browse/providers) has its own
[Public Terraform Registry](https://registry.terraform.io/browse/providers) has its own
documentation for configuring and using the data types it provides.
Each data instance will export one or more attributes, which can be

2
website/docs/language/expressions/function-calls.mdx
View File

@ -77,7 +77,7 @@ practical difference when OpenTF would call them.
However, a small subset of functions interact with outside state and so for
those it can be helpful to know when OpenTF will call them in relation to
other events that occur in a OpenTF run.
other events that occur in an OpenTF run.
The small set of special functions includes
[`file`](/opentf/language/functions/file),

8
website/docs/language/expressions/references.mdx
View File

@ -131,7 +131,7 @@ The following values are available:
advanced cases where OpenTF is run from a directory other than the root module
directory. We recommend using `path.root` or `path.module` over `path.cwd` where
possible.
- `opentf.workspace` is the name of the currently selected
- `terraform.workspace` is the name of the currently selected
[workspace](/opentf/language/state/workspaces).
Use the values in this section carefully, because they include information
@ -145,7 +145,7 @@ the provider to consider the change of path to be a change to be applied, even
if the path still refers to the same file.
Similarly, if you use any of these values as a form of namespacing in a shared
module, such as using `opentf.workspace` as a prefix for globally-unique
module, such as using `terraform.workspace` as a prefix for globally-unique
object names, it may not be possible to call your module more than once in
the same configuration.
@ -153,14 +153,14 @@ Aside from `path.module`, we recommend using the values in this section only
in the root module of your configuration. If you are writing a shared module
which needs a prefix to help create unique names, define an input variable
for your module and allow the calling module to define the prefix. The
calling module can then use `opentf.workspace` to define it if appropriate,
calling module can then use `terraform.workspace` to define it if appropriate,
or some other value if not:
```hcl
module "example" {
# ...
name_prefix = "app-${opentf.workspace}"
name_prefix = "app-${terraform.workspace}"
}
```

142
website/docs/language/files/dependency-lock.mdx
View File

@ -1,102 +1,96 @@
---
page_title: Dependency Lock File (.terraform.lock.hcl) - Configuration Language
description: >-
Terraform uses the dependency lock file .teraform.lock.hcl to track and select
OpenTF uses the dependency lock file .teraform.lock.hcl to track and select
provider versions. Learn about dependency installation and lock file changes.
---
# Dependency Lock File
-> **Note:** This page is about a feature of Terraform 0.14 and later. Prior
versions of Terraform did not track dependency selections at all, so the
information here is not relevant to those versions.
> **Hands-on:** Try the [Lock and Upgrade Provider Versions](/terraform/tutorials/configuration-language/provider-versioning?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
A Terraform configuration may refer to two different kinds of external
An OpenTF configuration may refer to two different kinds of external
dependency that come from outside of its own codebase:
- [Providers](/terraform/language/providers/requirements), which are plugins for Terraform
- [Providers](/opentf/language/providers/requirements), which are plugins for OpenTF
that extend it with support for interacting with various external systems.
- [Modules](/terraform/language/modules), which allow
splitting out groups of Terraform configuration constructs (written in the
Terraform language) into reusable abstractions.
- [Modules](/opentf/language/modules), which allow
splitting out groups of OpenTF configuration constructs (written in the
OpenTF language) into reusable abstractions.
Both of these dependency types can be published and updated independently from
Terraform itself and from the configurations that depend on them. For that
reason, Terraform must determine which versions of those dependencies are
OpenTF itself and from the configurations that depend on them. For that
reason, OpenTF must determine which versions of those dependencies are
potentially compatible with the current configuration and which versions are
currently selected for use.
[Version constraints](/terraform/language/expressions/version-constraints) within the configuration
[Version constraints](/opentf/language/expressions/version-constraints) within the configuration
itself determine which versions of dependencies are _potentially_ compatible,
but after selecting a specific version of each dependency Terraform remembers
but after selecting a specific version of each dependency OpenTF remembers
the decisions it made in a _dependency lock file_ so that it can (by default)
make the same decisions again in future.
At present, the dependency lock file tracks only _provider_ dependencies.
Terraform does not remember version selections for remote modules, and so
Terraform will always select the newest available module version that meets
OpenTF does not remember version selections for remote modules, and so
OpenTF will always select the newest available module version that meets
the specified version constraints. You can use an _exact_ version constraint
to ensure that Terraform will always select the same module version.
to ensure that OpenTF will always select the same module version.
## Lock File Location
The dependency lock file is a file that belongs to the configuration as a
whole, rather than to each separate module in the configuration. For that reason
Terraform creates it and expects to find it in your current working directory
when you run Terraform, which is also the directory containing the `.tf` files
OpenTF creates it and expects to find it in your current working directory
when you run OpenTF, which is also the directory containing the `.tf` files
for the root module of your configuration.
The lock file is always named `.terraform.lock.hcl`, and this name is intended
to signify that it is a lock file for various items that Terraform caches in
to signify that it is a lock file for various items that OpenTF caches in
the `.terraform` subdirectory of your working directory.
Terraform automatically creates or updates the dependency lock file each time
you run [the `terraform init` command](/terraform/cli/commands/init). You should
OpenTF automatically creates or updates the dependency lock file each time
you run [the `opentf init` command](/opentf/cli/commands/init). You should
include this file in your version control repository so that you can discuss
potential changes to your external dependencies via code review, just as you
would discuss potential changes to your configuration itself.
The dependency lock file uses the same low-level syntax as the main Terraform
language, but the dependency lock file is not itself a Terraform language
The dependency lock file uses the same low-level syntax as the main OpenTF
language, but the dependency lock file is not itself an OpenTF language
configuration file. It is named with the suffix `.hcl` instead of `.tf` in
order to signify that difference.
## Dependency Installation Behavior
When `terraform init` is working on installing all of the providers needed for
a configuration, Terraform considers both the version constraints in the
When `opentf init` is working on installing all of the providers needed for
a configuration, OpenTF considers both the version constraints in the
configuration _and_ the version selections recorded in the lock file.
If a particular provider has no existing recorded selection, Terraform will
If a particular provider has no existing recorded selection, OpenTF will
select the newest available version that matches the given version constraint,
and then update the lock file to include that selection.
If a particular provider already has a selection recorded in the lock file,
Terraform will always re-select that version for installation, even if a
OpenTF will always re-select that version for installation, even if a
newer version has become available. You can override that behavior by adding
the `-upgrade` option when you run `terraform init`, in which case Terraform
the `-upgrade` option when you run `opentf init`, in which case OpenTF
will disregard the existing selections and once again select the newest
available version matching the version constraint.
If a particular `terraform init` call makes changes to the lock file, Terraform
If a particular `opentf init` call makes changes to the lock file, OpenTF
will mention that as part of its output:
```
Terraform has made some changes to the provider dependency selections recorded
OpenTF has made some changes to the provider dependency selections recorded
in the .terraform.lock.hcl file. Review those changes and commit them to your
version control system if they represent changes you intended to make.
```
When you see this message, you can use your version control system to
[review the changes Terraform has proposed in the file](#understanding-lock-file-changes),
[review the changes OpenTF has proposed in the file](#understanding-lock-file-changes),
and if they represent changes you made intentionally you can send the change
through your team's usual code review process.
### Checksum verification
Terraform will also verify that each package it installs matches at least one
OpenTF will also verify that each package it installs matches at least one
of the checksums it previously recorded in the lock file, if any, returning an
error if none of the checksums match:
@ -112,20 +106,20 @@ This checksum verification is intended to represent a
_[trust on first use](https://en.wikipedia.org/wiki/Trust_on_first_use)_
approach. When you add a new provider for the first time you can verify it
in whatever way you choose or any way you are required to by relevant
regulations, and then trust that Terraform will raise an error if a future
run of `terraform init` encounters a non-matching package for the same
regulations, and then trust that OpenTF will raise an error if a future
run of `opentf init` encounters a non-matching package for the same
provider version.
There are two special considerations with the "trust on first use" model:
- If you install a provider from an origin registry which provides checksums
that are signed with a cryptographic signature, Terraform will treat all
that are signed with a cryptographic signature, OpenTF will treat all
of the signed checksums as valid as long as one checksum matches. The lock
file will therefore include checksums for both the package you installed for
your current platform _and_ any other packages that might be available for
other platforms.
In this case, the `terraform init` output will include the fingerprint of
In this case, the `opentf init` output will include the fingerprint of
the key that signed the checksums, with a message like
`(signed by a HashiCorp partner, key ID DC9FC6B1FCE47986)`. You may wish to
confirm that you trust the holder of the given key before committing the
@ -133,35 +127,35 @@ There are two special considerations with the "trust on first use" model:
full set of available packages for the given provider version.
- If you install a provider for the first time using an alternative
installation method, such as a filesystem or network mirror, Terraform will
installation method, such as a filesystem or network mirror, OpenTF will
not be able to verify the checksums for any platform other than the one
where you ran `terraform init`, and so it will not record the checksums
where you ran `opentf init`, and so it will not record the checksums
for other platforms and so the configuration will not be usable on any other
platform.
To avoid this problem you can pre-populate checksums for a variety of
different platforms in your lock file using
[the `terraform providers lock` command](/terraform/cli/commands/providers/lock),
which will then allow future calls to `terraform init` to verify that the
[the `opentf providers lock` command](/opentf/cli/commands/providers/lock),
which will then allow future calls to `opentf init` to verify that the
packages available in your chosen mirror match the official packages from
the provider's origin registry.
## Understanding Lock File Changes
Because the dependency lock file is primarily maintained automatically by
Terraform itself, rather than being updated manually by you or your team,
OpenTF itself, rather than being updated manually by you or your team,
your version control system may show you that the file has changed.
There are a few different types of changes that Terraform can potentially make
There are a few different types of changes that OpenTF can potentially make
to your lock file, which you may need to understand in order to review the
proposed changes. The following sections will describe these common situations.
### Dependency on a new provider
If you add a new entry to the
[provider requirements](/terraform/language/providers/requirements) for any module in your
[provider requirements](/opentf/language/providers/requirements) for any module in your
configuration, or if you add an external module that includes a new provider
dependency itself, `terraform init` will respond to that by selecting the
dependency itself, `opentf init` will respond to that by selecting the
newest version of that provider which meets all of the version constraints
in the configuration, and it will record its decision as a new `provider`
block in the dependency lock file.
@ -200,10 +194,10 @@ block in the dependency lock file.
The new lock file entry records several pieces of information:
- `version`: the exact version that Terraform selected based on the version
- `version`: the exact version that OpenTF selected based on the version
constraints in the configuration.
- `constraints`: all of the version constraints that Terraform considered when
making this selection. (Terraform doesn't actually use this information to
- `constraints`: all of the version constraints that OpenTF considered when
making this selection. (OpenTF doesn't actually use this information to
make installation decisions, but includes it to help explain to human readers
how the previous decision was made.)
- `hashes`: a number of checksums that are all considered to be valid for
@ -213,8 +207,8 @@ The new lock file entry records several pieces of information:
### New version of an existing provider
If you run `terraform init -upgrade` to ask Terraform to consider newer provider
versions that still match the configured version constraints, Terraform may
If you run `opentf init -upgrade` to ask OpenTF to consider newer provider
versions that still match the configured version constraints, OpenTF may
then select a newer version for a provider and update its existing `provider`
block to reflect that change.
@ -262,7 +256,7 @@ block to reflect that change.
The primary effect of selecting a new provider version is to change the
value of `version` in the `provider` block. If the upgrade came along with
a change to the configured version constraints, Terraform will also record
a change to the configured version constraints, OpenTF will also record
that change in the `constraints` value.
Because each version has its own set of distribution packages, switching to
@ -288,7 +282,7 @@ in the `provider` block has changed:
"zh:4c5682ba1e0fc7e2e602d3f103af1638f868c31fe80cc1a884a97f6dad6e1c11",
```
The addition of a new checksum into the `hashes` value represents Terraform
The addition of a new checksum into the `hashes` value represents OpenTF
gradually transitioning between different _hashing schemes_. The `h1:` and
`zh:` prefixes on these values represent different hashing schemes, each
of which represents calculating a checksum using a different algorithm.
@ -299,14 +293,14 @@ additional benefit.
The two hashing schemes currently supported are:
- `zh:`: a mnemonic for "zip hash", this is a legacy hash format which is
part of the Terraform provider registry protocol and is therefore used for
part of the OpenTF provider registry protocol and is therefore used for
providers that you install directly from an origin registry.
This hashing scheme captures a SHA256 hash of each of the official `.zip`
packages indexed in the origin registry. This is an effective scheme for
verifying the official release packages when installed from a registry, but
it's not suitable for verifying packages that come from other
[provider installation methods](/terraform/cli/config/config-file#provider-installation),
[provider installation methods](/opentf/cli/config/config-file#provider-installation),
such as filesystem mirrors using the unpacked directory layout.
- `h1:`: a mnemonic for "hash scheme 1", which is the current preferred hashing
@ -319,38 +313,38 @@ The two hashing schemes currently supported are:
same contents, or a recompressed `.zip` file which contains the same files
but potentially different metadata or compression schemes.
Due to the limited scope of the `zh:` scheme, Terraform will
Due to the limited scope of the `zh:` scheme, OpenTF will
opportunistically add in the corresponding `h1:` checksums as it learns
of them, which is what caused the addition of a second `h1:` checksum
in the example change shown above.
Terraform will add a new hash to an existing provider only if the hash is
OpenTF will add a new hash to an existing provider only if the hash is
calculated from a package that _also_ matches one of the existing hashes. In
the above example, Terraform installed a `hashicorp/azurerm` package for a
the above example, OpenTF installed a `hashicorp/azurerm` package for a
different platform than that which produced the original `h1:` checksum, but was
able to match it against one of the `zh:` checksums recorded previously.
After confirming the `zh:` checksum match, Terraform then recorded the
After confirming the `zh:` checksum match, OpenTF then recorded the
corresponding `h1:` checksum in order to gradually migrate from the old scheme
to the new scheme.
When installing a particular provider for the first time (where there is no
existing `provider` block for it), Terraform will pre-populate the `hashes`
existing `provider` block for it), OpenTF will pre-populate the `hashes`
value with any checksums that are covered by the provider developer's
cryptographic signature, which usually covers all of the available packages
for that provider version across all supported platforms. However, because
the provider registry protocol still uses the `zh:` scheme, the initial set
will consist primarily of hashes using that scheme, which Terraform will then
will consist primarily of hashes using that scheme, which OpenTF will then
upgrade opportunistically as you install the packages on different platforms.
If you wish to avoid ongoing additions of new `h1:` hashes as you work with
your configuration on new target platforms, or if you are installing providers
from a mirror that therefore can't provide official signed checksums, you
can ask Terraform to pre-populate hashes for a chosen set of platforms
can ask OpenTF to pre-populate hashes for a chosen set of platforms
using
[the `terraform providers lock` command](/terraform/cli/commands/providers/lock):
[the `opentf providers lock` command](/opentf/cli/commands/providers/lock):
```
terraform providers lock \
opentf providers lock \
-platform=linux_arm64 \
-platform=linux_amd64 \
-platform=darwin_amd64 \
@ -360,16 +354,16 @@ terraform providers lock \
The above command will download and verify the official packages for all of
the required providers across all four of the given platforms, and then record
both `zh:` and `h1:` checksums for each of them in the lock file, thus avoiding
the case where Terraform will learn about a `h1:` equivalent only at a later
time. See the `terraform providers lock` documentation for more information on
the case where OpenTF will learn about a `h1:` equivalent only at a later
time. See the `opentf providers lock` documentation for more information on
this command.
### Providers that are no longer required
To determine whether there still exists a dependency on a given provider,
Terraform uses two sources of truth: the configuration itself, and the state.
OpenTF uses two sources of truth: the configuration itself, and the state.
If you remove the last dependency on a particular provider from both your
configuration and state, then `terraform init` will remove any existing lock
configuration and state, then `opentf init` will remove any existing lock
file entry for that provider.
```diff
@ -405,15 +399,7 @@ file entry for that provider.
```
If you add a new requirement for the same provider at a later date and run
`terraform init` again, Terraform will treat it as if it were
`opentf init` again, OpenTF will treat it as if it were
[an entirely new provider](#dependency-on-a-new-provider)
and so will not necessarily select the same version that was previously
selected and will not be able to verify that the checksums remained unchanged.
-> **Note:** In Terraform v1.0 and earlier, `terraform init` does not
automatically remove now-unneeded providers from the lock file, and instead
just ignores them. If you removed a provider dependency while using an
earlier version of Terraform and then upgraded to Terraform v1.1 or later
then you may see the error "missing or corrupted provider plugins", referring to
the stale lock file entries. If so, run `terraform init` with the new Terraform
version to tidy those unneeded entries and then retry the previous operation.

26
website/docs/language/files/index.mdx
View File

@ -1,20 +1,20 @@
---
page_title: Files and Directories - Configuration Language
description: >-
Learn how to name, organize, and store Terraform configuration files. Also
learn how Terraform evaluates modules.
Learn how to name, organize, and store OpenTF configuration files. Also
learn how OpenTF evaluates modules.
---
# Files and Directories
## File Extension
Code in the Terraform language is stored in plain text files with the `.tf` file
Code in the OpenTF language is stored in plain text files with the `.tf` file
extension. There is also
[a JSON-based variant of the language](/terraform/language/syntax/json) that is named with
[a JSON-based variant of the language](/opentf/language/syntax/json) that is named with
the `.tf.json` file extension.
Files containing Terraform code are often called _configuration files._
Files containing OpenTF code are often called _configuration files._
## Text Encoding
@ -27,32 +27,32 @@ line endings (CRLF), though both are accepted.
A _module_ is a collection of `.tf` and/or `.tf.json` files kept together in a
directory.
A Terraform module only consists of the top-level configuration files in a
An OpenTF module only consists of the top-level configuration files in a
directory; nested directories are treated as completely separate modules, and
are not automatically included in the configuration.
Terraform evaluates all of the configuration files in a module, effectively
OpenTF evaluates all of the configuration files in a module, effectively
treating the entire module as a single document. Separating various blocks into
different files is purely for the convenience of readers and maintainers, and
has no effect on the module's behavior.
A Terraform module can use [module calls](/terraform/language/modules) to
An OpenTF module can use [module calls](/opentf/language/modules) to
explicitly include other modules into the configuration. These child modules can
come from local directories (nested in the parent module's directory, or
anywhere else on disk), or from external sources like the
[Terraform Registry](https://registry.terraform.io).
[Public Terraform Registry](https://registry.terraform.io).
## The Root Module
Terraform always runs in the context of a single _root module._ A complete
_Terraform configuration_ consists of a root module and the tree of child
OpenTF always runs in the context of a single _root module._ A complete
_OpenTF configuration_ consists of a root module and the tree of child
modules (which includes the modules called by the root module, any modules
called by those modules, etc.).
- In Terraform CLI, the root module is the working directory where Terraform is
- In OpenTF CLI, the root module is the working directory where OpenTF is
invoked. (You can use command line options to specify a root module outside
the working directory, but in practice this is rare.)
- In Terraform Cloud and Terraform Enterprise, the root module for a workspace
- In TACOS (TF Automation and Collaboration Software), the root module for a workspace
defaults to the top level of the configuration directory (supplied via version
control repository or direct upload), but the workspace settings can specify a
subdirectory to use instead.

22
website/docs/language/files/override.mdx
View File

@ -7,25 +7,25 @@ description: >-
# Override Files
Terraform normally loads all of the `.tf` and `.tf.json` files within a
OpenTF normally loads all of the `.tf` and `.tf.json` files within a
directory and expects each one to define a distinct set of configuration
objects. If two files attempt to define the same object, Terraform returns
objects. If two files attempt to define the same object, OpenTF returns
an error.
In some rare cases, it is convenient to be able to override specific portions
of an existing configuration object in a separate file. For example, a
human-edited configuration file in the Terraform language native syntax
human-edited configuration file in the OpenTF language native syntax
could be partially overridden using a programmatically-generated file
in JSON syntax.
For these rare situations, Terraform has special handling of any configuration
For these rare situations, OpenTF has special handling of any configuration
file whose name ends in `_override.tf` or `_override.tf.json`. This special
handling also applies to a file named literally `override.tf` or
`override.tf.json`.
Terraform initially skips these _override files_ when loading configuration,
OpenTF initially skips these _override files_ when loading configuration,
and then afterwards processes each one in turn (in lexicographical order). For
each top-level block defined in an override file, Terraform attempts to find
each top-level block defined in an override file, OpenTF attempts to find
an already-defined object corresponding to that block and then merges the
override block contents into the existing object.
@ -38,7 +38,7 @@ override files apply changes to each block.
## Example
If you have a Terraform configuration `example.tf` with the following contents:
If you have an OpenTF configuration `example.tf` with the following contents:
```hcl
resource "aws_instance" "web" {
@ -55,7 +55,7 @@ resource "aws_instance" "web" {
}
```
Terraform will merge the latter into the former, behaving as if the original
OpenTF will merge the latter into the former, behaving as if the original
configuration had been as follows:
```hcl
@ -119,7 +119,7 @@ described above, but some special considerations apply due to the interactions
between the `type` and `default` arguments.
If the original block defines a `default` value and an override block changes
the variable's `type`, Terraform attempts to convert the default value to
the variable's `type`, OpenTF attempts to convert the default value to
the overridden type, producing an error if this conversion is not possible.
Conversely, if the original block defines a `type` and an override block changes
@ -154,7 +154,7 @@ original block. If both the base block and the override block both set
The presence of a block defining a backend (either `cloud` or `backend`) in an override
file always takes precedence over a block defining a backend in the original configuration.
That is, if a `cloud` block is set within the original configuration and a `backend` block is
set in the override file, Terraform will use the `backend` block specified in the override file upon merging.
set in the override file, OpenTF will use the `backend` block specified in the override file upon merging.
Similarly, if a `backend` block is set within the original configuration and a `cloud` block
is set in the override file, Terraform will use the `cloud` block specified in the override
is set in the override file, OpenTF will use the `cloud` block specified in the override
file upon merging.

4
website/docs/language/functions/abspath.mdx
View File

@ -12,12 +12,12 @@ with the current working directory.
Referring directly to filesystem paths in resource arguments may cause
spurious diffs if the same configuration is applied from multiple systems or on
different host operating systems. We recommend using filesystem paths only
for transient values, such as the argument to [`file`](/terraform/language/functions/file) (where
for transient values, such as the argument to [`file`](/opentf/language/functions/file) (where
only the contents are then stored) or in `connection` and `provisioner` blocks.
## Examples
```
> abspath(path.root)
/home/user/some/terraform/root
/home/user/some/opentf/root
```

2
website/docs/language/functions/alltrue.mdx
View File

@ -7,8 +7,6 @@ description: |-
# `alltrue` Function
-> **Note:** This function is available in Terraform 0.14 and later.
`alltrue` returns `true` if all elements in a given collection are `true`
or `"true"`. It also returns `true` if the collection is empty.

2
website/docs/language/functions/anytrue.mdx
View File

@ -7,8 +7,6 @@ description: |-
# `anytrue` Function
-> **Note:** This function is available in Terraform 0.14 and later.
`anytrue` returns `true` if any element in a given collection is `true`
or `"true"`. It also returns `false` if the collection is empty.

16
website/docs/language/functions/base64decode.mdx
View File

@ -8,15 +8,15 @@ description: The base64decode function decodes a string containing a base64 sequ
`base64decode` takes a string containing a Base64 character sequence and
returns the original string.
Terraform uses the "standard" Base64 alphabet as defined in
OpenTF uses the "standard" Base64 alphabet as defined in
[RFC 4648 section 4](https://tools.ietf.org/html/rfc4648#section-4).
Strings in the Terraform language are sequences of unicode characters rather
Strings in the OpenTF language are sequences of unicode characters rather
than bytes, so this function will also interpret the resulting bytes as
UTF-8. If the bytes after Base64 decoding are _not_ valid UTF-8, this function
produces an error.
While we do not recommend manipulating large, raw binary data in the Terraform
While we do not recommend manipulating large, raw binary data in the OpenTF
language, Base64 encoding is the standard way to represent arbitrary byte
sequences, and so resource types that accept or return binary data will use
Base64 themselves, which avoids the need to encode or decode it directly in
@ -24,7 +24,7 @@ most cases. Various other functions with names containing "base64" can generate
or manipulate Base64 data directly.
`base64decode` is, in effect, a shorthand for calling
[`textdecodebase64`](/terraform/language/functions/textdecodebase64) with the encoding name set to
[`textdecodebase64`](/opentf/language/functions/textdecodebase64) with the encoding name set to
`UTF-8`.
## Examples
@ -36,11 +36,11 @@ Hello World
## Related Functions
* [`base64encode`](/terraform/language/functions/base64encode) performs the opposite operation,
* [`base64encode`](/opentf/language/functions/base64encode) performs the opposite operation,
encoding the UTF-8 bytes for a string as Base64.
* [`textdecodebase64`](/terraform/language/functions/textdecodebase64) is a more general function that
* [`textdecodebase64`](/opentf/language/functions/textdecodebase64) is a more general function that
supports character encodings other than UTF-8.
* [`base64gzip`](/terraform/language/functions/base64gzip) applies gzip compression to a string
* [`base64gzip`](/opentf/language/functions/base64gzip) applies gzip compression to a string
and returns the result with Base64 encoding.
* [`filebase64`](/terraform/language/functions/filebase64) reads a file from the local filesystem
* [`filebase64`](/opentf/language/functions/filebase64) reads a file from the local filesystem
and returns its raw bytes with Base64 encoding.

18
website/docs/language/functions/base64encode.mdx
View File

@ -7,25 +7,25 @@ description: The base64encode function applies Base64 encoding to a string.
`base64encode` applies Base64 encoding to a string.
Terraform uses the "standard" Base64 alphabet as defined in
OpenTF uses the "standard" Base64 alphabet as defined in
[RFC 4648 section 4](https://tools.ietf.org/html/rfc4648#section-4).
Strings in the Terraform language are sequences of unicode characters rather
Strings in the OpenTF language are sequences of unicode characters rather
than bytes, so this function will first encode the characters from the string
as UTF-8, and then apply Base64 encoding to the result.
The Terraform language applies Unicode normalization to all strings, and so
The OpenTF language applies Unicode normalization to all strings, and so
passing a string through `base64decode` and then `base64encode` may not yield
the original result exactly.
While we do not recommend manipulating large, raw binary data in the Terraform
While we do not recommend manipulating large, raw binary data in the OpenTF
language, Base64 encoding is the standard way to represent arbitrary byte
sequences, and so resource types that accept or return binary data will use
Base64 themselves, and so this function exists primarily to allow string
data to be easily provided to resource types that expect Base64 bytes.
`base64encode` is, in effect, a shorthand for calling
[`textencodebase64`](/terraform/language/functions/textencodebase64) with the encoding name set to
[`textencodebase64`](/opentf/language/functions/textencodebase64) with the encoding name set to
`UTF-8`.
## Examples
@ -37,12 +37,12 @@ SGVsbG8gV29ybGQ=
## Related Functions
* [`base64decode`](/terraform/language/functions/base64decode) performs the opposite operation,
* [`base64decode`](/opentf/language/functions/base64decode) performs the opposite operation,
decoding Base64 data and interpreting it as a UTF-8 string.
* [`textencodebase64`](/terraform/language/functions/textencodebase64) is a more general function that
* [`textencodebase64`](/opentf/language/functions/textencodebase64) is a more general function that
supports character encodings other than UTF-8.
* [`base64gzip`](/terraform/language/functions/base64gzip) applies gzip compression to a string
* [`base64gzip`](/opentf/language/functions/base64gzip) applies gzip compression to a string
and returns the result with Base64 encoding all in one operation.
* [`filebase64`](/terraform/language/functions/filebase64) reads a file from the local filesystem
* [`filebase64`](/opentf/language/functions/filebase64) reads a file from the local filesystem
and returns its raw bytes with Base64 encoding, without creating an
intermediate Unicode string.

12
website/docs/language/functions/base64gzip.mdx
View File

@ -10,22 +10,22 @@ description: |-
`base64gzip` compresses a string with gzip and then encodes the result in
Base64 encoding.
Terraform uses the "standard" Base64 alphabet as defined in
OpenTF uses the "standard" Base64 alphabet as defined in
[RFC 4648 section 4](https://tools.ietf.org/html/rfc4648#section-4).
Strings in the Terraform language are sequences of unicode characters rather
Strings in the OpenTF language are sequences of unicode characters rather
than bytes, so this function will first encode the characters from the string
as UTF-8, then apply gzip compression, and then finally apply Base64 encoding.
While we do not recommend manipulating large, raw binary data in the Terraform
While we do not recommend manipulating large, raw binary data in the OpenTF
language, this function can be used to compress reasonably sized text strings
generated within the Terraform language. For example, the result of this
generated within the OpenTF language. For example, the result of this
function can be used to create a compressed object in Amazon S3 as part of
an S3 website.
## Related Functions
* [`base64encode`](/terraform/language/functions/base64encode) applies Base64 encoding _without_
* [`base64encode`](/opentf/language/functions/base64encode) applies Base64 encoding _without_
gzip compression.
* [`filebase64`](/terraform/language/functions/filebase64) reads a file from the local filesystem
* [`filebase64`](/opentf/language/functions/filebase64) reads a file from the local filesystem
and returns its raw bytes with Base64 encoding.

6
website/docs/language/functions/base64sha256.mdx
View File

@ -13,7 +13,7 @@ returns hexadecimal representation.
The given string is first encoded as UTF-8 and then the SHA256 algorithm is applied
as defined in [RFC 4634](https://tools.ietf.org/html/rfc4634). The raw hash is
then encoded with Base64 before returning. Terraform uses the "standard" Base64
then encoded with Base64 before returning. OpenTF uses the "standard" Base64
alphabet as defined in [RFC 4648 section 4](https://tools.ietf.org/html/rfc4648#section-4).
## Examples
@ -25,7 +25,7 @@ uU0nuZNNPgilLlLX2n2r+sSE7+N6U4DukIj3rOLvzek=
## Related Functions
* [`filebase64sha256`](/terraform/language/functions/filebase64sha256) calculates the same hash from
* [`filebase64sha256`](/opentf/language/functions/filebase64sha256) calculates the same hash from
the contents of a file rather than from a string value.
* [`sha256`](/terraform/language/functions/sha256) calculates the same hash but returns the result
* [`sha256`](/opentf/language/functions/sha256) calculates the same hash but returns the result
in a more-verbose hexadecimal encoding.

6
website/docs/language/functions/base64sha512.mdx
View File

@ -13,7 +13,7 @@ returns hexadecimal representation.
The given string is first encoded as UTF-8 and then the SHA512 algorithm is applied
as defined in [RFC 4634](https://tools.ietf.org/html/rfc4634). The raw hash is
then encoded with Base64 before returning. Terraform uses the "standard" Base64
then encoded with Base64 before returning. OpenTF uses the "standard" Base64
alphabet as defined in [RFC 4648 section 4](https://tools.ietf.org/html/rfc4648#section-4).
## Examples
@ -25,7 +25,7 @@ MJ7MSJwS1utMxA9QyQLytNDtd+5RGnx6m808qG1M2G+YndNbxf9JlnDaNCVbRbDP2DDoH2Bdz33FVC6T
## Related Functions
* [`filebase64sha512`](/terraform/language/functions/filebase64sha512) calculates the same hash from
* [`filebase64sha512`](/opentf/language/functions/filebase64sha512) calculates the same hash from
the contents of a file rather than from a string value.
* [`sha512`](/terraform/language/functions/sha512) calculates the same hash but returns the result
* [`sha512`](/opentf/language/functions/sha512) calculates the same hash but returns the result
in a more-verbose hexadecimal encoding.

4
website/docs/language/functions/basename.mdx
View File

@ -24,7 +24,7 @@ it uses backslash `\` as the path segment separator. On Unix systems, the slash
Referring directly to filesystem paths in resource arguments may cause
spurious diffs if the same configuration is applied from multiple systems or on
different host operating systems. We recommend using filesystem paths only
for transient values, such as the argument to [`file`](/terraform/language/functions/file) (where
for transient values, such as the argument to [`file`](/opentf/language/functions/file) (where
only the contents are then stored) or in `connection` and `provisioner` blocks.
## Examples
@ -36,6 +36,6 @@ baz.txt
## Related Functions
* [`dirname`](/terraform/language/functions/dirname) returns all of the segments of a filesystem path
* [`dirname`](/opentf/language/functions/dirname) returns all of the segments of a filesystem path
_except_ the last, discarding the portion that would be returned by
`basename`.

2
website/docs/language/functions/bcrypt.mdx
View File

@ -26,7 +26,7 @@ blocks, or in data resources whose results are only used in `provisioner`
blocks.
The version prefix on the generated string (e.g. `$2a$`) may change in future
versions of Terraform.
versions of OpenTF.
## Examples

8
website/docs/language/functions/can.mdx
View File

@ -12,12 +12,12 @@ whether the expression produced a result without any errors.
This is a special function that is able to catch errors produced when evaluating
its argument. For most situations where you could use `can` it's better to use
[`try`](/terraform/language/functions/try) instead, because it allows for more concise definition of
[`try`](/opentf/language/functions/try) instead, because it allows for more concise definition of
fallback values for failing expressions.
The primary purpose of `can` is to turn an error condition into a boolean
validation result when writing
[custom variable validation rules](/terraform/language/values/variables#custom-validation-rules).
[custom variable validation rules](/opentf/language/values/variables#custom-validation-rules).
For example:
```
@ -41,7 +41,7 @@ as a malformed resource reference.
variable validation rules. Although it can technically accept any sort of
expression and be used elsewhere in the configuration, we recommend against
using it in other contexts. For error handling elsewhere in the configuration,
prefer to use [`try`](/terraform/language/functions/try).
prefer to use [`try`](/opentf/language/functions/try).
## Examples
@ -70,5 +70,5 @@ A local value with the name "nonexist" has not been declared.
## Related Functions
* [`try`](/terraform/language/functions/try), which tries evaluating a sequence of expressions and
* [`try`](/opentf/language/functions/try), which tries evaluating a sequence of expressions and
returns the result of the first one that succeeds.

2
website/docs/language/functions/ceil.mdx
View File

@ -21,5 +21,5 @@ given value, which may be a fraction.
## Related Functions
* [`floor`](/terraform/language/functions/floor), which rounds to the nearest whole number _less than_
* [`floor`](/opentf/language/functions/floor), which rounds to the nearest whole number _less than_
or equal.

2
website/docs/language/functions/chomp.mdx
View File

@ -23,5 +23,5 @@ hello
## Related Functions
* [`trimspace`](/terraform/language/functions/trimspace), which removes all types of whitespace from
* [`trimspace`](/opentf/language/functions/trimspace), which removes all types of whitespace from
both the start and the end of a string.

4
website/docs/language/functions/cidrhost.mdx
View File

@ -21,7 +21,7 @@ cidrhost(prefix, hostnum)
no more than the number of digits remaining in the address after the given
prefix. For more details on how this function interprets CIDR prefixes and
populates host numbers, see the worked example for
[`cidrsubnet`](/terraform/language/functions/cidrsubnet).
[`cidrsubnet`](/opentf/language/functions/cidrsubnet).
Conventionally host number zero is used to represent the address of the
network itself and the host number that would fill all the host bits with
@ -50,5 +50,5 @@ fd00:fd12:3456:7890::22
## Related Functions
* [`cidrsubnet`](/terraform/language/functions/cidrsubnet) calculates a subnet address under a given
* [`cidrsubnet`](/opentf/language/functions/cidrsubnet) calculates a subnet address under a given
network address prefix.

12
website/docs/language/functions/cidrsubnet.mdx
View File

@ -27,7 +27,7 @@ additional bits added to the prefix.
This function accepts both IPv6 and IPv4 prefixes, and the result always uses
the same addressing scheme as the given prefix.
Unlike the related function [`cidrsubnets`](/terraform/language/functions/cidrsubnets), `cidrsubnet`
Unlike the related function [`cidrsubnets`](/opentf/language/functions/cidrsubnets), `cidrsubnet`
allows you to give a specific network number to use. `cidrsubnets` can allocate
multiple network addresses at once, but numbers them automatically starting
with zero.
@ -93,7 +93,7 @@ This gives us some additional information but also confirms (using a slightly
different notation) the conversion from decimal to binary and shows the range
of possible host addresses in this network.
While [`cidrhost`](/terraform/language/functions/cidrhost) allows calculating single host IP addresses,
While [`cidrhost`](/opentf/language/functions/cidrhost) allows calculating single host IP addresses,
`cidrsubnet` on the other hand creates a new network prefix _within_ the given
network prefix. In other words, it creates a subnet.
@ -148,7 +148,7 @@ Hosts/Net: 14 Class A, Private Internet
The new subnet has four bits available for host numbering, which means
that there are 14 host addresses available for assignment once we subtract
the network's own address and the broadcast address. You can thus use
[`cidrhost`](/terraform/language/functions/cidrhost) function to calculate those host addresses by
[`cidrhost`](/opentf/language/functions/cidrhost) function to calculate those host addresses by
providing it a value between 1 and 14:
```
@ -163,9 +163,9 @@ For more information on CIDR notation and subnetting, see
## Related Functions
* [`cidrhost`](/terraform/language/functions/cidrhost) calculates the IP address for a single host
* [`cidrhost`](/opentf/language/functions/cidrhost) calculates the IP address for a single host
within a given network address prefix.
* [`cidrnetmask`](/terraform/language/functions/cidrnetmask) converts an IPv4 network prefix in CIDR
* [`cidrnetmask`](/opentf/language/functions/cidrnetmask) converts an IPv4 network prefix in CIDR
notation into netmask notation.
* [`cidrsubnets`](/terraform/language/functions/cidrsubnets) can allocate multiple consecutive
* [`cidrsubnets`](/opentf/language/functions/cidrsubnets) can allocate multiple consecutive
addresses under a prefix at once, numbering them automatically.

12
website/docs/language/functions/cidrsubnets.mdx
View File

@ -23,7 +23,7 @@ value is therefore a list with one element per `newbits` argument, each
a string containing an address range in CIDR notation.
For more information on IP addressing concepts, see the documentation for the
related function [`cidrsubnet`](/terraform/language/functions/cidrsubnet). `cidrsubnet` calculates
related function [`cidrsubnet`](/opentf/language/functions/cidrsubnet). `cidrsubnet` calculates
a single subnet address within a prefix while allowing you to specify its
subnet number, while `cidrsubnets` can calculate many at once, potentially of
different sizes, and assigns subnet numbers automatically.
@ -42,7 +42,7 @@ octets that have leading zeros as decimal numbers, which is contrary to some
other systems which interpret them as octal. We have preserved this behavior
for backward compatibility, but recommend against relying on this behavior.
-> **Note:** [The Terraform module `hashicorp/subnets/cidr`](https://registry.terraform.io/modules/hashicorp/subnets/cidr)
-> **Note:** [The `hashicorp/subnets/cidr` module](https://registry.terraform.io/modules/hashicorp/subnets/cidr)
wraps `cidrsubnets` to provide additional functionality for assigning symbolic
names to your networks and skipping prefixes for obsolete allocations. Its
documentation includes usage examples for several popular cloud virtual network
@ -69,7 +69,7 @@ platforms.
```
You can use nested `cidrsubnets` calls with
[`for` expressions](/terraform/language/expressions/for)
[`for` expressions](/opentf/language/expressions/for)
to concisely allocate groups of network address blocks:
```
@ -96,9 +96,9 @@ to concisely allocate groups of network address blocks:
## Related Functions
* [`cidrhost`](/terraform/language/functions/cidrhost) calculates the IP address for a single host
* [`cidrhost`](/opentf/language/functions/cidrhost) calculates the IP address for a single host
within a given network address prefix.
* [`cidrnetmask`](/terraform/language/functions/cidrnetmask) converts an IPv4 network prefix in CIDR
* [`cidrnetmask`](/opentf/language/functions/cidrnetmask) converts an IPv4 network prefix in CIDR
notation into netmask notation.
* [`cidrsubnet`](/terraform/language/functions/cidrsubnet) calculates a single subnet address, allowing
* [`cidrsubnet`](/opentf/language/functions/cidrsubnet) calculates a single subnet address, allowing
you to specify its network number.

8
website/docs/language/functions/coalesce.mdx
View File

@ -10,7 +10,7 @@ description: |-
`coalesce` takes any number of arguments and returns the first one
that isn't null or an empty string.
All of the arguments must be of the same type. Terraform will try to
All of the arguments must be of the same type. OpenTF will try to
convert mismatched arguments to the most general of the types that all
arguments can convert to, or return an error if the types are incompatible.
The result type is the same as the type of all of the arguments.
@ -34,9 +34,9 @@ symbol to expand the list as arguments:
b
```
Terraform attempts to select a result type that all of the arguments can
OpenTF attempts to select a result type that all of the arguments can
convert to, so mixing argument types may produce surprising results due to
Terraform's automatic type conversion rules:
OpenTF's automatic type conversion rules:
```
> coalesce(1, "hello")
@ -52,5 +52,5 @@ Call to function "coalesce" failed: all arguments must have the same type.
## Related Functions
* [`coalescelist`](/terraform/language/functions/coalescelist) performs a similar operation with
* [`coalescelist`](/opentf/language/functions/coalescelist) performs a similar operation with
list arguments rather than individual arguments.

2
website/docs/language/functions/coalescelist.mdx
View File

@ -38,5 +38,5 @@ symbol to expand the outer list as arguments:
## Related Functions
* [`coalesce`](/terraform/language/functions/coalesce) performs a similar operation with string
* [`coalesce`](/opentf/language/functions/coalesce) performs a similar operation with string
arguments rather than list arguments.

12
website/docs/language/functions/csvdecode.mdx
View File

@ -39,7 +39,7 @@ number of fields, or this function will produce an error.
## Use with the `for_each` meta-argument
You can use the result of `csvdecode` with
[the `for_each` meta-argument](/terraform/language/meta-arguments/for_each)
[the `for_each` meta-argument](/opentf/language/meta-arguments/for_each)
to describe a collection of similar objects whose differences are
described by the rows in the given CSV file.
@ -72,22 +72,22 @@ resource "aws_instance" "example" {
The `for` expression in our `for_each` argument transforms the list produced
by `csvdecode` into a map using the `local_id` as a key, which tells
Terraform to use the `local_id` value to track each instance it creates.
Terraform will create and manage the following instance addresses:
OpenTF to use the `local_id` value to track each instance it creates.
OpenTF will create and manage the following instance addresses:
- `aws_instance.example["foo1"]`
- `aws_instance.example["foo2"]`
- `aws_instance.example["foo3"]`
- `aws_instance.example["bar1"]`
If you modify a row in the CSV on a subsequent plan, Terraform will interpret
If you modify a row in the CSV on a subsequent plan, OpenTF will interpret
that as an update to the existing object as long as the `local_id` value is
unchanged. If you add or remove rows from the CSV then Terraform will plan to
unchanged. If you add or remove rows from the CSV then OpenTF will plan to
create or destroy associated instances as appropriate.
If there is no reasonable value you can use as a unique identifier in your CSV
then you could instead use
[the `count` meta-argument](/terraform/language/meta-arguments/count)
[the `count` meta-argument](/opentf/language/meta-arguments/count)
to define an object for each CSV row, with each one identified by its index into
the list returned by `csvdecode`. However, in that case any future updates to
the CSV may be disruptive if they change the positions of particular objects in

4
website/docs/language/functions/dirname.mdx
View File

@ -23,7 +23,7 @@ any slashes in the given path will be replaced by backslashes before returning.
Referring directly to filesystem paths in resource arguments may cause
spurious diffs if the same configuration is applied from multiple systems or on
different host operating systems. We recommend using filesystem paths only
for transient values, such as the argument to [`file`](/terraform/language/functions/file) (where
for transient values, such as the argument to [`file`](/opentf/language/functions/file) (where
only the contents are then stored) or in `connection` and `provisioner` blocks.
## Examples
@ -35,5 +35,5 @@ foo/bar
## Related Functions
* [`basename`](/terraform/language/functions/basename) returns _only_ the last portion of a filesystem
* [`basename`](/opentf/language/functions/basename) returns _only_ the last portion of a filesystem
path, discarding the portion that would be returned by `dirname`.

6
website/docs/language/functions/element.mdx
View File

@ -32,7 +32,7 @@ If the given index is greater than the length of the list then the index is
a
```
To get the last element from the list use [`length`](/terraform/language/functions/length) to find
To get the last element from the list use [`length`](/opentf/language/functions/length) to find
the size of the list (minus 1 as the list is zero-based) and then pick the
last element:
@ -43,5 +43,5 @@ c
## Related Functions
* [`index`](/terraform/language/functions/index_function) finds the index for a particular element value.
* [`lookup`](/terraform/language/functions/lookup) retrieves a value from a _map_ given its _key_.
* [`index`](/opentf/language/functions/index_function) finds the index for a particular element value.
* [`lookup`](/opentf/language/functions/lookup) retrieves a value from a _map_ given its _key_.

2
website/docs/language/functions/endswith.mdx
View File

@ -24,4 +24,4 @@ false
## Related Functions
- [`startswith`](/terraform/language/functions/startswith) takes two values: a string to check and a prefix string. The function returns true if the string begins with that exact prefix.
- [`startswith`](/opentf/language/functions/startswith) takes two values: a string to check and a prefix string. The function returns true if the string begins with that exact prefix.

14
website/docs/language/functions/file.mdx
View File

@ -14,16 +14,16 @@ a string.
file(path)
```
Strings in the Terraform language are sequences of Unicode characters, so
Strings in the OpenTF language are sequences of Unicode characters, so
this function will interpret the file contents as UTF-8 encoded text and
return the resulting Unicode characters. If the file contains invalid UTF-8
sequences then this function will produce an error.
This function can be used only with files that already exist on disk
at the beginning of a Terraform run. Functions do not participate in the
at the beginning of an OpenTF run. Functions do not participate in the
dependency graph, so this function cannot be used with files that are generated
dynamically during a Terraform operation. We do not recommend using dynamic
local files in Terraform configurations, but in rare situations where this is
dynamically during an OpenTF operation. We do not recommend using dynamic
local files in OpenTF configurations, but in rare situations where this is
necessary you can use
[the `local_file` data source](https://registry.terraform.io/providers/hashicorp/local/latest/docs/data-sources/file)
to read files while respecting resource dependencies.
@ -37,10 +37,10 @@ Hello World
## Related Functions
* [`filebase64`](/terraform/language/functions/filebase64) also reads the contents of a given file,
* [`filebase64`](/opentf/language/functions/filebase64) also reads the contents of a given file,
but returns the raw bytes in that file Base64-encoded, rather than
interpreting the contents as UTF-8 text.
* [`fileexists`](/terraform/language/functions/fileexists) determines whether a file exists
* [`fileexists`](/opentf/language/functions/fileexists) determines whether a file exists
at a given path.
* [`templatefile`](/terraform/language/functions/templatefile) renders using a file from disk as a
* [`templatefile`](/opentf/language/functions/templatefile) renders using a file from disk as a
template.

12
website/docs/language/functions/filebase64.mdx
View File

@ -15,19 +15,19 @@ filebase64(path)
```
The result is a Base64 representation of the raw bytes in the given file.
Strings in the Terraform language are sequences of Unicode characters, so
Strings in the OpenTF language are sequences of Unicode characters, so
Base64 is the standard way to represent raw binary data that cannot be
interpreted as Unicode characters. Resource types that operate on binary
data will accept this data encoded in Base64, thus avoiding the need to
decode the result of this function.
Terraform uses the "standard" Base64 alphabet as defined in
OpenTF uses the "standard" Base64 alphabet as defined in
[RFC 4648 section 4](https://tools.ietf.org/html/rfc4648#section-4).
This function can be used only with functions that already exist as static
files on disk at the beginning of a Terraform run. Language functions do not
files on disk at the beginning of an OpenTF run. Language functions do not
participate in the dependency graph, so this function cannot be used with
files that are generated dynamically during a Terraform operation.
files that are generated dynamically during an OpenTF operation.
## Examples
@ -38,9 +38,9 @@ SGVsbG8gV29ybGQ=
## Related Functions
* [`file`](/terraform/language/functions/file) also reads the contents of a given file,
* [`file`](/opentf/language/functions/file) also reads the contents of a given file,
but interprets the data as UTF-8 text and returns the result directly
as a string, without any further encoding.
* [`base64decode`](/terraform/language/functions/base64decode) can decode a Base64 string representing
* [`base64decode`](/opentf/language/functions/base64decode) can decode a Base64 string representing
bytes in UTF-8, but in practice `base64decode(filebase64(...))` is equivalent
to the shorter expression `file(...)`.

4
website/docs/language/functions/filebase64sha256.mdx
View File

@ -7,9 +7,9 @@ description: |-
# `filebase64sha256` Function
`filebase64sha256` is a variant of [`base64sha256`](/terraform/language/functions/base64sha256)
`filebase64sha256` is a variant of [`base64sha256`](/opentf/language/functions/base64sha256)
that hashes the contents of a given file rather than a literal string.
This is similar to `base64sha256(file(filename))`, but
because [`file`](/terraform/language/functions/file) accepts only UTF-8 text it cannot be used to
because [`file`](/opentf/language/functions/file) accepts only UTF-8 text it cannot be used to
create hashes for binary files.

4
website/docs/language/functions/filebase64sha512.mdx
View File

@ -7,9 +7,9 @@ description: |-
# `filebase64sha512` Function
`filebase64sha512` is a variant of [`base64sha512`](/terraform/language/functions/base64sha512)
`filebase64sha512` is a variant of [`base64sha512`](/opentf/language/functions/base64sha512)
that hashes the contents of a given file rather than a literal string.
This is similar to `base64sha512(file(filename))`, but
because [`file`](/terraform/language/functions/file) accepts only UTF-8 text it cannot be used to
because [`file`](/opentf/language/functions/file) accepts only UTF-8 text it cannot be used to
create hashes for binary files.

4
website/docs/language/functions/fileexists.mdx
View File

@ -13,7 +13,7 @@ fileexists(path)
Functions are evaluated during configuration parsing rather than at apply time,
so this function can only be used with files that are already present on disk
before Terraform takes any actions.
before OpenTF takes any actions.
This function works only with regular files. If used with a directory, FIFO,
or other special mode, it will return an error.
@ -31,4 +31,4 @@ fileexists("custom-section.sh") ? file("custom-section.sh") : local.default_cont
## Related Functions
* [`file`](/terraform/language/functions/file) reads the contents of a file at a given path
* [`file`](/opentf/language/functions/file) reads the contents of a file at a given path

4
website/docs/language/functions/filemd5.mdx
View File

@ -7,9 +7,9 @@ description: |-
# `filemd5` Function
`filemd5` is a variant of [`md5`](/terraform/language/functions/md5)
`filemd5` is a variant of [`md5`](/opentf/language/functions/md5)
that hashes the contents of a given file rather than a literal string.
This is similar to `md5(file(filename))`, but
because [`file`](/terraform/language/functions/file) accepts only UTF-8 text it cannot be used to
because [`file`](/opentf/language/functions/file) accepts only UTF-8 text it cannot be used to
create hashes for binary files.

4
website/docs/language/functions/fileset.mdx
View File

@ -34,7 +34,7 @@ Character classes support the following:
Functions are evaluated during configuration parsing rather than at apply time,
so this function can only be used with files that are already present on disk
before Terraform takes any actions.
before OpenTF takes any actions.
## Examples
@ -66,7 +66,7 @@ before Terraform takes any actions.
```
A common use of `fileset` is to create one resource instance per matched file, using
[the `for_each` meta-argument](/terraform/language/meta-arguments/for_each):
[the `for_each` meta-argument](/opentf/language/meta-arguments/for_each):
```hcl
resource "example_thing" "example" {

4
website/docs/language/functions/filesha1.mdx
View File

@ -7,9 +7,9 @@ description: |-
# `filesha1` Function
`filesha1` is a variant of [`sha1`](/terraform/language/functions/sha1)
`filesha1` is a variant of [`sha1`](/opentf/language/functions/sha1)
that hashes the contents of a given file rather than a literal string.
This is similar to `sha1(file(filename))`, but
because [`file`](/terraform/language/functions/file) accepts only UTF-8 text it cannot be used to
because [`file`](/opentf/language/functions/file) accepts only UTF-8 text it cannot be used to
create hashes for binary files.

4
website/docs/language/functions/filesha256.mdx
View File

@ -7,9 +7,9 @@ description: |-
# `filesha256` Function
`filesha256` is a variant of [`sha256`](/terraform/language/functions/sha256)
`filesha256` is a variant of [`sha256`](/opentf/language/functions/sha256)
that hashes the contents of a given file rather than a literal string.
This is similar to `sha256(file(filename))`, but
because [`file`](/terraform/language/functions/file) accepts only UTF-8 text it cannot be used to
because [`file`](/opentf/language/functions/file) accepts only UTF-8 text it cannot be used to
create hashes for binary files.

4
website/docs/language/functions/filesha512.mdx
View File

@ -7,9 +7,9 @@ description: |-
# `filesha512` Function
`filesha512` is a variant of [`sha512`](/terraform/language/functions/sha512)
`filesha512` is a variant of [`sha512`](/opentf/language/functions/sha512)
that hashes the contents of a given file rather than a literal string.
This is similar to `sha512(file(filename))`, but
because [`file`](/terraform/language/functions/file) accepts only UTF-8 text it cannot be used to
because [`file`](/opentf/language/functions/file) accepts only UTF-8 text it cannot be used to
create hashes for binary files.

6
website/docs/language/functions/flatten.mdx
View File

@ -28,9 +28,9 @@ Indirectly-nested lists, such as those in maps, are _not_ flattened.
## Flattening nested structures for `for_each`
The
[resource `for_each`](/terraform/language/meta-arguments/for_each)
[resource `for_each`](/opentf/language/meta-arguments/for_each)
and
[`dynamic` block](/terraform/language/expressions/dynamic-blocks)
[`dynamic` block](/opentf/language/expressions/dynamic-blocks)
language features both require a collection value that has one element for
each repetition.
@ -101,6 +101,6 @@ the associations between the subnets and their containing networks.
## Related Functions
* [`setproduct`](/terraform/language/functions/setproduct) finds all of the combinations of multiple
* [`setproduct`](/opentf/language/functions/setproduct) finds all of the combinations of multiple
lists or sets of values, which can also be useful when preparing collections
for use with `for_each` constructs.

2
website/docs/language/functions/floor.mdx
View File

@ -21,5 +21,5 @@ given value, which may be a fraction.
## Related Functions
* [`ceil`](/terraform/language/functions/ceil), which rounds to the nearest whole number _greater than_
* [`ceil`](/opentf/language/functions/ceil), which rounds to the nearest whole number _greater than_
or equal.

10
website/docs/language/functions/format.mdx
View File

@ -34,7 +34,7 @@ Hello, Valentina!
Hello, Valentina!
```
The formatting verb `%#v` accepts a value of any type and presents it using JSON encoding, similar to jsonencode. This can be useful for describing the values given to a module in [custom condition check](/terraform/language/expressions/custom-conditions#error-messages) error messages.
The formatting verb `%#v` accepts a value of any type and presents it using JSON encoding, similar to jsonencode. This can be useful for describing the values given to a module in [custom condition check](/opentf/language/expressions/custom-conditions#error-messages) error messages.
```
> format("%#v", "hello")
@ -96,7 +96,7 @@ The specification may contain the following verbs.
### Default Format Verbs
When `%v` is used, Terraform chooses the appropriate format verb based on the value type.
When `%v` is used, OpenTF chooses the appropriate format verb based on the value type.
| Type | Verb |
| --------- | ----- |
@ -110,7 +110,7 @@ Null values produce the string `null` if formatted with `%v` or `%#v`, and cause
### Width Modifier
Use a width modifier with an optional decimal number immediately
preceding the verb letter to specify how many characters will be used to represent the value. You can specify precision after the (optional) width with a period (`.`) followed by a decimal number. If width or precision are omitted, Terraform selects default values based on the given value.
preceding the verb letter to specify how many characters will be used to represent the value. You can specify precision after the (optional) width with a period (`.`) followed by a decimal number. If width or precision are omitted, OpenTF selects default values based on the given value.
The following examples demonstrate example use cases for the width modifier.
@ -139,7 +139,7 @@ Use the following symbols immediately after the `%` symbol to set additional for
## Related Functions
* [`formatdate`](/terraform/language/functions/formatdate) is a specialized formatting function for
* [`formatdate`](/opentf/language/functions/formatdate) is a specialized formatting function for
human-readable timestamps.
* [`formatlist`](/terraform/language/functions/formatlist) uses the same specification syntax to
* [`formatlist`](/opentf/language/functions/formatlist) uses the same specification syntax to
produce a list of strings.

6
website/docs/language/functions/formatdate.mdx
View File

@ -11,7 +11,7 @@ description: The formatdate function converts a timestamp into a different time
formatdate(spec, timestamp)
```
In the Terraform language, timestamps are conventionally represented as
In the OpenTF language, timestamps are conventionally represented as
strings using [RFC 3339](https://tools.ietf.org/html/rfc3339)
"Date and Time format" syntax. `formatdate` requires the `timestamp` argument
to be a string conforming to this syntax.
@ -99,7 +99,7 @@ configuration as needed:
## Related Functions
- [`format`](/terraform/language/functions/format) is a more general formatting function for arbitrary
- [`format`](/opentf/language/functions/format) is a more general formatting function for arbitrary
data.
- [`timestamp`](/terraform/language/functions/timestamp) returns the current date and time in a format
- [`timestamp`](/opentf/language/functions/timestamp) returns the current date and time in a format
suitable for input to `formatdate`.

4
website/docs/language/functions/formatlist.mdx
View File

@ -15,7 +15,7 @@ formatlist(spec, values...)
```
The specification string uses
[the same syntax as `format`](/terraform/language/functions/format#specification-syntax).
[the same syntax as `format`](/opentf/language/functions/format#specification-syntax).
The given values can be a mixture of list and non-list arguments. Any given
lists must be the same length, which decides the length of the resulting list.
@ -45,5 +45,5 @@ once per element of the list arguments.
## Related Functions
* [`format`](/terraform/language/functions/format) defines the specification syntax used by this
* [`format`](/opentf/language/functions/format) defines the specification syntax used by this
function and produces a single string as its result.

14
website/docs/language/functions/index.mdx
View File

@ -7,9 +7,7 @@ description: >-
# Built-in Functions
> **Hands-on:** Try the [Perform Dynamic Operations with Functions](/terraform/tutorials/configuration-language/functions?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
The Terraform language includes a number of built-in functions that you can
The OpenTF language includes a number of built-in functions that you can
call from within expressions to transform and combine values. The general
syntax for function calls is a function name followed by comma-separated
arguments in parentheses:
@ -19,15 +17,15 @@ max(5, 12, 9)
```
For more details on syntax, see
[_Function Calls_](/terraform/language/expressions/function-calls)
[_Function Calls_](/opentf/language/expressions/function-calls)
in the Expressions section.
The Terraform language does not support user-defined functions, and so only
The OpenTF language does not support user-defined functions, and so only
the functions built in to the language are available for use. The documentation includes a page for all of the available built-in functions.
You can experiment with the behavior of Terraform's built-in functions from
the Terraform expression console, by running
[the `terraform console` command](/terraform/cli/commands/console):
You can experiment with the behavior of OpenTF's built-in functions from
the OpenTF expression console, by running
[the `opentf console` command](/opentf/cli/commands/console):
```
> max(5, 12, 9)

2
website/docs/language/functions/index_function.mdx
View File

@ -23,5 +23,5 @@ value is not present in the list.
## Related Functions
* [`element`](/terraform/language/functions/element) retrieves a particular element from a list given
* [`element`](/opentf/language/functions/element) retrieves a particular element from a list given
its index.

2
website/docs/language/functions/join.mdx
View File

@ -27,5 +27,5 @@ foo
## Related Functions
* [`split`](/terraform/language/functions/split) performs the opposite operation: producing a list
* [`split`](/opentf/language/functions/split) performs the opposite operation: producing a list
by separating a single string using a given delimiter.

10
website/docs/language/functions/jsondecode.mdx
View File

@ -13,19 +13,19 @@ of the result of decoding that string.
The JSON encoding is defined in [RFC 7159](https://tools.ietf.org/html/rfc7159).
This function maps JSON values to
[Terraform language values](/terraform/language/expressions/types)
[OpenTF language values](/opentf/language/expressions/types)
in the following way:
| JSON type | Terraform type |
| JSON type | OpenTF type |
| --------- | ------------------------------------------------------------ |
| String | `string` |
| Number | `number` |
| Boolean | `bool` |
| Object | `object(...)` with attribute types determined per this table |
| Array | `tuple(...)` with element types determined per this table |
| Null | The Terraform language `null` value |
| Null | The OpenTF language `null` value |
The Terraform language automatic type conversion rules mean that you don't
The OpenTF language automatic type conversion rules mean that you don't
usually need to worry about exactly what type is produced for a given value,
and can just use the result in an intuitive way.
@ -42,5 +42,5 @@ true
## Related Functions
* [`jsonencode`](/terraform/language/functions/jsonencode) performs the opposite operation, _encoding_
* [`jsonencode`](/opentf/language/functions/jsonencode) performs the opposite operation, _encoding_
a value as JSON.

11
website/docs/language/functions/jsonencode.mdx
View File

@ -10,10 +10,10 @@ description: The jsonencode function encodes a given value as a JSON string.
The JSON encoding is defined in [RFC 7159](https://tools.ietf.org/html/rfc7159).
This function maps
[Terraform language values](/terraform/language/expressions/types)
[OpenTF language values](/opentf/language/expressions/types)
to JSON values in the following way:
| Terraform type | JSON type |
| OpenTF type | JSON type |
| -------------- | --------- |
| `string` | String |
| `number` | Number |
@ -25,15 +25,14 @@ to JSON values in the following way:
| `object(...)` | Object |
| Null value | `null` |
Since the JSON format cannot fully represent all of the Terraform language
Since the JSON format cannot fully represent all of the OpenTF language
types, passing the `jsonencode` result to `jsondecode` will not produce an
identical value, but the automatic type conversion rules mean that this is
rarely a problem in practice.
When encoding strings, this function escapes some characters using
Unicode escape sequences: replacing `<`, `>`, `&`, `U+2028`, and `U+2029` with
`\u003c`, `\u003e`, `\u0026`, `\u2028`, and `\u2029`. This is to preserve
compatibility with Terraform 0.11 behavior.
`\u003c`, `\u003e`, `\u0026`, `\u2028`, and `\u2029`.
The `jsonencode` command outputs a minified representation of the input.
@ -46,5 +45,5 @@ The `jsonencode` command outputs a minified representation of the input.
## Related Functions
* [`jsondecode`](/terraform/language/functions/jsondecode) performs the opposite operation, _decoding_
* [`jsondecode`](/opentf/language/functions/jsondecode) performs the opposite operation, _decoding_
a JSON string to obtain its represented value.

2
website/docs/language/functions/keys.mdx
View File

@ -23,4 +23,4 @@ be identical as long as the keys in the map don't change.
## Related Functions
* [`values`](/terraform/language/functions/values) returns a list of the _values_ from a map.
* [`values`](/opentf/language/functions/values) returns a list of the _values_ from a map.

4
website/docs/language/functions/length.mdx
View File

@ -34,6 +34,6 @@ number of bytes or Unicode sequences that form them:
A "character" is a _grapheme cluster_, as defined by
[Unicode Standard Annex #29](http://unicode.org/reports/tr29/). Note that
remote APIs may have a different definition of "character" for the purpose of
length limits on string arguments; a Terraform provider is responsible for
translating Terraform's string representation into that used by its respective
length limits on string arguments; an OpenTF provider is responsible for
translating OpenTF's string representation into that used by its respective
remote system and applying any additional validation rules to it.

26
website/docs/language/functions/list.mdx
View File

@ -1,26 +0,0 @@
---
page_title: list - Functions - Configuration Language
description: The list function constructs a list from some given elements.
---
# `list` Function
The `list` function is no longer available. Prior to Terraform v0.12 it was
the only available syntax for writing a literal list inside an expression,
but Terraform v0.12 introduced a new first-class syntax.
To update an expression like `list(a, b, c)`, write the following instead:
```
tolist([a, b, c])
```
The `[ ... ]` brackets construct a tuple value, and then the `tolist` function
then converts it to a list. For more information on the value types in the
Terraform language, see [Type Constraints](/terraform/language/expressions/types).
## Related Functions
* [`concat`](/terraform/language/functions/concat) produces a new list by concatenating together the
elements from other lists.
* [`tolist`](/terraform/language/functions/tolist) converts a set or tuple value to a list.

2
website/docs/language/functions/lookup.mdx
View File

@ -27,4 +27,4 @@ what?
## Related Functions
* [`element`](/terraform/language/functions/element) retrieves a value from a _list_ given its _index_.
* [`element`](/opentf/language/functions/element) retrieves a value from a _list_ given its _index_.

4
website/docs/language/functions/lower.mdx
View File

@ -22,5 +22,5 @@ This function uses Unicode's definition of letters and of upper- and lowercase.
## Related Functions
* [`upper`](/terraform/language/functions/upper) converts letters in a string to _uppercase_.
* [`title`](/terraform/language/functions/title) converts the first letter of each word in a string to uppercase.
* [`upper`](/opentf/language/functions/upper) converts letters in a string to _uppercase_.
* [`title`](/opentf/language/functions/title) converts the first letter of each word in a string to uppercase.

29
website/docs/language/functions/map.mdx
View File

@ -1,29 +0,0 @@
---
page_title: map - Functions - Configuration Language
description: The map function constructs a map from some given elements.
---
# `map` Function
The `map` function is no longer available. Prior to Terraform v0.12 it was
the only available syntax for writing a literal map inside an expression,
but Terraform v0.12 introduced a new first-class syntax.
To update an expression like `map("a", "b", "c", "d")`, write the following instead:
```
tomap({
a = "b"
c = "d"
})
```
The `{ ... }` braces construct an object value, and then the `tomap` function
then converts it to a map. For more information on the value types in the
Terraform language, see [Type Constraints](/terraform/language/expressions/types).
## Related Functions
* [`tomap`](/terraform/language/functions/tomap) converts an object value to a map.
* [`zipmap`](/terraform/language/functions/zipmap) constructs a map dynamically, by taking keys from
one list and values from another list.

2
website/docs/language/functions/max.mdx
View File

@ -24,4 +24,4 @@ to individual arguments:
## Related Functions
* [`min`](/terraform/language/functions/min), which returns the _smallest_ number from a set.
* [`min`](/opentf/language/functions/min), which returns the _smallest_ number from a set.

2
website/docs/language/functions/md5.mdx
View File

@ -27,5 +27,5 @@ considerations applying to the MD5 algorithm.
## Related Functions
* [`filemd5`](/terraform/language/functions/filemd5) calculates the same hash from
* [`filemd5`](/opentf/language/functions/filemd5) calculates the same hash from
the contents of a file rather than from a string value.

2
website/docs/language/functions/merge.mdx
View File

@ -39,7 +39,7 @@ type structure of the attributes after the merging rules have been applied.
}
```
The following example uses the expansion symbol (...) to transform the value into separate arguments. Refer to [Expanding Function Argument](/terraform/language/expressions/function-calls#expanding-function-arguments) for details.
The following example uses the expansion symbol (...) to transform the value into separate arguments. Refer to [Expanding Function Argument](/opentf/language/expressions/function-calls#expanding-function-arguments) for details.
```
> merge([{a="b", c="d"}, {}, {e="f", c="z"}]...)

2
website/docs/language/functions/min.mdx
View File

@ -24,4 +24,4 @@ to individual arguments:
## Related Functions
* [`max`](/terraform/language/functions/max), which returns the _greatest_ number from a set.
* [`max`](/opentf/language/functions/max), which returns the _greatest_ number from a set.

24
website/docs/language/functions/nonsensitive.mdx
View File

@ -2,31 +2,29 @@
page_title: nonsensitive - Functions - Configuration Language
description: >-
The nonsensitive function removes the sensitive marking from a value that
Terraform considers to be sensitive.
OpenTF considers to be sensitive.
---
# `nonsensitive` Function
-> **Note:** This function is only available in Terraform v0.15 and later.
`nonsensitive` takes a sensitive value and returns a copy of that value with
the sensitive marking removed, thereby exposing the sensitive value.
~> **Warning:** Using this function indiscriminately will cause values that
Terraform would normally have considered as sensitive to be treated as normal
values and shown clearly in Terraform's output. Use this function only when
OpenTF would normally have considered as sensitive to be treated as normal
values and shown clearly in OpenTF's output. Use this function only when
you've derived a new value from a sensitive value in a way that eliminates the
sensitive portions of the value.
Normally Terraform tracks when you use expressions to derive a new value from
Normally OpenTF tracks when you use expressions to derive a new value from
a value that is marked as sensitive, so that the result can also be marked
as sensitive.
However, you may wish to write expressions that derive non-sensitive results
from sensitive values. For example, if you know based on details of your
particular system and its threat model that a SHA256 hash of a particular
sensitive value is safe to include clearly in Terraform output, you could use
the `nonsensitive` function to indicate that, overriding Terraform's normal
sensitive value is safe to include clearly in OpenTF output, you could use
the `nonsensitive` function to indicate that, overriding OpenTF's normal
conservative behavior:
```hcl
@ -57,7 +55,7 @@ locals {
# username_from_json would normally be considered to be
# sensitive too, but system-specific knowledge tells us
# that the username is a non-sensitive fragment of the
# original document, and so we can override Terraform's
# original document, and so we can override OpenTF's
# determination.
username_from_json = nonsensitive(local.mixed_content["username"])
}
@ -66,11 +64,11 @@ locals {
When you use this function, it's your responsibility to ensure that the
expression passed as its argument will remove all sensitive content from
the sensitive value it depends on. By passing a value to `nonsensitive` you are
declaring to Terraform that you have done all that is necessary to ensure that
declaring to OpenTF that you have done all that is necessary to ensure that
the resulting value has no sensitive content, even though it was derived
from sensitive content. If a sensitive value appears in Terraform's output
from sensitive content. If a sensitive value appears in OpenTF's output
due to an inappropriate call to `nonsensitive` in your module, that's a bug in
your module and not a bug in Terraform itself.
your module and not a bug in OpenTF itself.
**Use this function sparingly and only with due care.**
`nonsensitive` will return an error if you pass a value that isn't marked
@ -84,7 +82,7 @@ care to preserve under future modifications.
## Examples
The following examples are from `terraform console` when running in the
The following examples are from `opentf console` when running in the
context of the example above with `variable "mixed_content_json"` and
the local value `mixed_content`, with a valid JSON string assigned to
`var.mixed_content_json`.

6
website/docs/language/functions/one.mdx
View File

@ -7,8 +7,6 @@ description: |-
# `one` Function
-> **Note:** This function is available only in Terraform v0.15 and later.
`one` takes a list, set, or tuple value with either zero or one elements.
If the collection is empty, `one` returns `null`. Otherwise, `one` returns
the first element. If there are two or more elements then `one` will return
@ -46,8 +44,8 @@ no instances were created.
## Relationship to the "Splat" Operator
The Terraform language has a built-in operator `[*]`, known as
[the _splat_ operator](/terraform/language/expressions/splat), and one of its functions
The OpenTF language has a built-in operator `[*]`, known as
[the _splat_ operator](/opentf/language/expressions/splat), and one of its functions
is to translate a primitive value that might be null into a list of either
zero or one elements:

2
website/docs/language/functions/parseint.mdx
View File

@ -46,5 +46,5 @@ Invalid value for "number" parameter: cannot parse "12" as a base 2 integer.
## Related Functions
* [`format`](/terraform/language/functions/format) can format numbers and other values into strings,
* [`format`](/opentf/language/functions/format) can format numbers and other values into strings,
with optional zero padding, alignment, etc.

4
website/docs/language/functions/pathexpand.mdx
View File

@ -30,7 +30,7 @@ depending on host operating system.
**For Unix systems**, the following sources are consulted, in order of preference:
* The `HOME` environment variable.
* The result of running `getent passwd` followed by the Terraform process uid.
* The result of running `getent passwd` followed by the OpenTF process uid.
* The result of running `cd && pwd` in `sh`.
**For Windows systems**, there is not really the concept of a home directory
@ -42,7 +42,7 @@ order of preference:
* The `USERPROFILE` environment variable.
The exact rules employed for each operating system may change in future
releases of Terraform.
releases of OpenTF.
## Examples

18
website/docs/language/functions/plantimestamp.mdx
View File

@ -7,26 +7,24 @@ description: |-
# `plantimestamp` Function
-> **Note:** This function is only available in Terraform v1.5 and later.
`plantimestamp` returns a UTC timestamp string in [RFC 3339](https://tools.ietf.org/html/rfc3339) format.
In the Terraform language, timestamps are conventionally represented as
In the OpenTF language, timestamps are conventionally represented as
strings using [RFC 3339](https://tools.ietf.org/html/rfc3339)
"Date and Time format" syntax, and so `plantimestamp` returns a string
in this format.
The result of this function will change for every plan operation. It is intended
for use within [Custom Conditions](/terraform/language/expressions/custom-conditions)
for use within [Custom Conditions](/opentf/language/expressions/custom-conditions)
as a way to validate time sensitive resources such as TLS certificates.
There are circumstances, such as during a Terraform [Refresh-only](/terraform/cli/commands/plan#planning-modes) plan, where
There are circumstances, such as during an OpenTF [Refresh-only](/opentf/cli/commands/plan#planning-modes) plan, where
the value for this function will be recomputed but not propagated to resources
defined within the configuration. As such, it is recommended that this function
only be used to compare against timestamps exported by providers and not against
timestamps generated in the configuration.
The `plantimestamp` function is not available within the Terraform console.
The `plantimestamp` function is not available within the OpenTF console.
## Examples
@ -35,7 +33,7 @@ The `plantimestamp` function is not available within the Terraform console.
2018-05-13T07:44:12Z
```
```terraform
```hcl
check "placeholderplaceholderplaceholder_io_certificate" {
data "tls_certificate" "placeholderplaceholderplaceholder_io" {
url = "https://www.placeholderplaceholderplaceholder.io/"
@ -43,12 +41,12 @@ check "placeholderplaceholderplaceholder_io_certificate" {
assert {
condition = timecmp(plantimestamp(), data.tls_certificate.placeholderplaceholderplaceholder_io.certificates[0].not_after) < 0
error_message = "terraform.io certificate has expired"
error_message = "placeholderplaceholderplaceholder.io certificate has expired"
}
}
```
## Related Functions
* [`timestamp`](/terraform/language/functions/timestamp) returns the current timestamp when it is evaluated
during the apply step.
* [`timestamp`](/opentf/language/functions/timestamp) returns the current timestamp when it is evaluated
during the apply step.

2
website/docs/language/functions/range.mdx
View File

@ -35,7 +35,7 @@ while num < limit: (or, for negative step, num > limit)
return the sequence
```
Because the sequence is created as a physical list in memory, Terraform imposes
Because the sequence is created as a physical list in memory, OpenTF imposes
an artificial limit of 1024 numbers in the resulting sequence in order to avoid
unbounded memory usage if, for example, a very large value were accidentally
passed as the limit or a very small value as the step. If the algorithm above

16
website/docs/language/functions/regex.mdx
View File

@ -30,12 +30,12 @@ It's not valid to mix both named and unnamed capture groups in the same pattern.
If the given pattern does not match at all, the `regex` raises an error. To
_test_ whether a given pattern matches a string, use
[`regexall`](/terraform/language/functions/regexall) and test that the result has length greater than
[`regexall`](/opentf/language/functions/regexall) and test that the result has length greater than
zero.
The pattern is a string containing a mixture of literal characters and special
matching operators as described in the following table. Note that when giving a
regular expression pattern as a literal quoted string in the Terraform
regular expression pattern as a literal quoted string in the OpenTF
language, the quoted string itself already uses backslash `\` as an escape
character for the string, so any backslashes intended to be recognized as part
of the pattern must be escaped as `\\`.
@ -102,7 +102,7 @@ no characters. These are "zero-width" matching operators:
| `\b` | At an ASCII word boundary (transition between `\w` and either `\W`, `\A` or `\z`, or vice-versa) |
| `\B` | Not at an ASCII word boundary |
Terraform uses the
OpenTF uses the
[RE2](https://github.com/google/re2/wiki/Syntax) regular expression language.
This engine does not support all of the features found in some other regular
expression engines; in particular, it does not support backreferences.
@ -136,9 +136,9 @@ aaabbbccc
"01",
]
> regex("^(?:(?P<scheme>[^:/?#]+):)?(?://(?P<authority>[^/?#]*))?", "https://terraform.io/docs/")
> regex("^(?:(?P<scheme>[^:/?#]+):)?(?://(?P<authority>[^/?#]*))?", "https://example.com/docs/")
{
"authority" = "terraform.io"
"authority" = "example.com"
"scheme" = "https"
}
@ -152,10 +152,10 @@ string.
## Related Functions
- [`regexall`](/terraform/language/functions/regexall) searches for potentially multiple matches of a given pattern in a string.
- [`replace`](/terraform/language/functions/replace) replaces a substring of a string with another string, optionally matching using the same regular expression syntax as `regex`.
- [`regexall`](/opentf/language/functions/regexall) searches for potentially multiple matches of a given pattern in a string.
- [`replace`](/opentf/language/functions/replace) replaces a substring of a string with another string, optionally matching using the same regular expression syntax as `regex`.
If Terraform already has a more specialized function to parse the syntax you
If OpenTF already has a more specialized function to parse the syntax you
are trying to match, prefer to use that function instead. Regular expressions
can be hard to read and can obscure your intent, making a configuration harder
to read and understand.

6
website/docs/language/functions/regexall.mdx
View File

@ -15,7 +15,7 @@ to a string and returns a list of all matches.
regexall(pattern, string)
```
`regexall` is a variant of [`regex`](/terraform/language/functions/regex) and uses the same pattern
`regexall` is a variant of [`regex`](/opentf/language/functions/regex) and uses the same pattern
syntax. For any given input to `regex`, `regexall` returns a list of whatever
type `regex` would've returned, with one element per match. That is:
@ -48,10 +48,10 @@ false
## Related Functions
- [`regex`](/terraform/language/functions/regex) searches for a single match of a given pattern, and
- [`regex`](/opentf/language/functions/regex) searches for a single match of a given pattern, and
returns an error if no match is found.
If Terraform already has a more specialized function to parse the syntax you
If OpenTF already has a more specialized function to parse the syntax you
are trying to match, prefer to use that function instead. Regular expressions
can be hard to read and can obscure your intent, making a configuration harder
to read and understand.

4
website/docs/language/functions/replace.mdx
View File

@ -16,7 +16,7 @@ replace(string, substring, replacement)
If `substring` is wrapped in forward slashes, it is treated as a regular
expression, using the same pattern syntax as
[`regex`](/terraform/language/functions/regex). If using a regular expression for the substring
[`regex`](/opentf/language/functions/regex). If using a regular expression for the substring
argument, the `replacement` string can incorporate captured strings from
the input by using an `$n` sequence, where `n` is the index or name of a
capture group.
@ -33,5 +33,5 @@ hello everybody
## Related Functions
- [`regex`](/terraform/language/functions/regex) searches a given string for a substring matching a
- [`regex`](/opentf/language/functions/regex) searches a given string for a substring matching a
given regular expression pattern.

2
website/docs/language/functions/reverse.mdx
View File

@ -21,4 +21,4 @@ with all of the same elements as the given sequence but in reverse order.
## Related Functions
* [`strrev`](/terraform/language/functions/strrev) reverses a string.
* [`strrev`](/opentf/language/functions/strrev) reverses a string.

4
website/docs/language/functions/rsadecrypt.mdx
View File

@ -13,13 +13,13 @@ rsadecrypt(ciphertext, privatekey)
```
`ciphertext` must be a base64-encoded representation of the ciphertext, using
the PKCS #1 v1.5 padding scheme. Terraform uses the "standard" Base64 alphabet
the PKCS #1 v1.5 padding scheme. OpenTF uses the "standard" Base64 alphabet
as defined in [RFC 4648 section 4](https://tools.ietf.org/html/rfc4648#section-4).
`privatekey` must be a PEM-encoded RSA private key that is not itself
encrypted.
Terraform has no corresponding function for _encrypting_ a message. Use this
OpenTF has no corresponding function for _encrypting_ a message. Use this
function to decrypt ciphertexts returned by remote services using a keypair
negotiated out-of-band.

10
website/docs/language/functions/sensitive.mdx
View File

@ -5,16 +5,14 @@ description: The sensitive function marks a value as being sensitive.
# `sensitive` Function
-> **Note:** This function is only available in Terraform v0.15 and later.
`sensitive` takes any value and returns a copy of it marked so that Terraform
`sensitive` takes any value and returns a copy of it marked so that OpenTF
will treat it as sensitive, with the same meaning and behavior as for
[sensitive input variables](/terraform/language/values/variables#suppressing-values-in-cli-output).
[sensitive input variables](/opentf/language/values/variables#suppressing-values-in-cli-output).
Wherever possible we recommend marking your input variable and/or output value
declarations as sensitive directly, instead of using this function, because in
that case you can be sure that there is no way to refer to those values without
Terraform automatically considering them as sensitive.
OpenTF automatically considering them as sensitive.
The `sensitive` function might be useful in some less-common situations where a
sensitive value arises from a definition _within_ your module, such as if you've
@ -28,7 +26,7 @@ locals {
However, we generally don't recommend writing sensitive values directly within
your module any of the files you distribute statically as part of that module,
because they may be exposed in other ways outside of Terraform's control.
because they may be exposed in other ways outside of OpenTF's control.
## Examples

8
website/docs/language/functions/setintersection.mdx
View File

@ -30,10 +30,10 @@ the ordering of the given elements is not preserved.
## Related Functions
* [`contains`](/terraform/language/functions/contains) tests whether a given list or set contains
* [`contains`](/opentf/language/functions/contains) tests whether a given list or set contains
a given element value.
* [`setproduct`](/terraform/language/functions/setproduct) computes the _Cartesian product_ of multiple
* [`setproduct`](/opentf/language/functions/setproduct) computes the _Cartesian product_ of multiple
sets.
* [`setsubtract`](/terraform/language/functions/setsubtract) computes the _relative complement_ of two sets
* [`setunion`](/terraform/language/functions/setunion) computes the _union_ of
* [`setsubtract`](/opentf/language/functions/setsubtract) computes the _relative complement_ of two sets
* [`setunion`](/opentf/language/functions/setunion) computes the _union_ of
multiple sets.

16
website/docs/language/functions/setproduct.mdx
View File

@ -85,7 +85,7 @@ only one element, which is the first element of each argument:
```
Each argument must have a consistent type for all of its elements. If not,
Terraform will attempt to convert to the most general type, or produce an
OpenTF will attempt to convert to the most general type, or produce an
error if such a conversion is impossible. For example, mixing both strings and
numbers results in the numbers being converted to strings so that the result
elements all have a consistent type:
@ -115,9 +115,9 @@ elements all have a consistent type:
## Finding combinations for `for_each`
The
[resource `for_each`](/terraform/language/meta-arguments/for_each)
[resource `for_each`](/opentf/language/meta-arguments/for_each)
and
[`dynamic` block](/terraform/language/expressions/dynamic-blocks)
[`dynamic` block](/opentf/language/expressions/dynamic-blocks)
language features both require a collection value that has one element for
each repetition.
@ -269,13 +269,13 @@ The `network_subnets` output would look similar to the following:
## Related Functions
- [`contains`](/terraform/language/functions/contains) tests whether a given list or set contains
- [`contains`](/opentf/language/functions/contains) tests whether a given list or set contains
a given element value.
- [`flatten`](/terraform/language/functions/flatten) is useful for flattening hierarchical data
- [`flatten`](/opentf/language/functions/flatten) is useful for flattening hierarchical data
into a single list, for situations where the relationships between two
object types are defined explicitly.
- [`setintersection`](/terraform/language/functions/setintersection) computes the _intersection_ of
- [`setintersection`](/opentf/language/functions/setintersection) computes the _intersection_ of
multiple sets.
- [`setsubtract`](/terraform/language/functions/setsubtract) computes the _relative complement_ of two sets
- [`setunion`](/terraform/language/functions/setunion) computes the _union_ of multiple
- [`setsubtract`](/opentf/language/functions/setsubtract) computes the _relative complement_ of two sets
- [`setunion`](/opentf/language/functions/setunion) computes the _union_ of multiple
sets.

6
website/docs/language/functions/setsubtract.mdx
View File

@ -35,8 +35,8 @@ toset([
## Related Functions
* [`setintersection`](/terraform/language/functions/setintersection) computes the _intersection_ of multiple sets
* [`setproduct`](/terraform/language/functions/setproduct) computes the _Cartesian product_ of multiple
* [`setintersection`](/opentf/language/functions/setintersection) computes the _intersection_ of multiple sets
* [`setproduct`](/opentf/language/functions/setproduct) computes the _Cartesian product_ of multiple
sets.
* [`setunion`](/terraform/language/functions/setunion) computes the _union_ of
* [`setunion`](/opentf/language/functions/setunion) computes the _union_ of
multiple sets.

8
website/docs/language/functions/setunion.mdx
View File

@ -33,10 +33,10 @@ the ordering of the given elements is not preserved.
## Related Functions
* [`contains`](/terraform/language/functions/contains) tests whether a given list or set contains
* [`contains`](/opentf/language/functions/contains) tests whether a given list or set contains
a given element value.
* [`setintersection`](/terraform/language/functions/setintersection) computes the _intersection_ of
* [`setintersection`](/opentf/language/functions/setintersection) computes the _intersection_ of
multiple sets.
* [`setproduct`](/terraform/language/functions/setproduct) computes the _Cartesian product_ of multiple
* [`setproduct`](/opentf/language/functions/setproduct) computes the _Cartesian product_ of multiple
sets.
* [`setsubtract`](/terraform/language/functions/setsubtract) computes the _relative complement_ of two sets
* [`setsubtract`](/opentf/language/functions/setsubtract) computes the _relative complement_ of two sets

2
website/docs/language/functions/sha1.mdx
View File

@ -27,5 +27,5 @@ relevant literature to understand the security implications.
## Related Functions
* [`filesha1`](/terraform/language/functions/filesha1) calculates the same hash from
* [`filesha1`](/opentf/language/functions/filesha1) calculates the same hash from
the contents of a file rather than from a string value.

4
website/docs/language/functions/sha256.mdx
View File

@ -25,7 +25,7 @@ b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
## Related Functions
* [`filesha256`](/terraform/language/functions/filesha256) calculates the same hash from
* [`filesha256`](/opentf/language/functions/filesha256) calculates the same hash from
the contents of a file rather than from a string value.
* [`base64sha256`](/terraform/language/functions/base64sha256) calculates the same hash but returns
* [`base64sha256`](/opentf/language/functions/base64sha256) calculates the same hash but returns
the result in a more-compact Base64 encoding.

4
website/docs/language/functions/sha512.mdx
View File

@ -23,7 +23,7 @@ then encoded to lowercase hexadecimal digits before returning.
## Related Functions
* [`filesha512`](/terraform/language/functions/filesha512) calculates the same hash from
* [`filesha512`](/opentf/language/functions/filesha512) calculates the same hash from
the contents of a file rather than from a string value.
* [`base64sha512`](/terraform/language/functions/base64sha512) calculates the same hash but returns
* [`base64sha512`](/opentf/language/functions/base64sha512) calculates the same hash but returns
the result in a more-compact Base64 encoding.

2
website/docs/language/functions/slice.mdx
View File

@ -27,5 +27,5 @@ list.
## Related Functions
* [`substr`](/terraform/language/functions/substr) performs a similar function for characters in a
* [`substr`](/opentf/language/functions/substr) performs a similar function for characters in a
string, although it uses a length instead of an end index.

2
website/docs/language/functions/split.mdx
View File

@ -35,5 +35,5 @@ split(separator, string)
## Related Functions
* [`join`](/terraform/language/functions/join) performs the opposite operation: producing a string
* [`join`](/opentf/language/functions/join) performs the opposite operation: producing a string
joining together a list of strings with a given separator.

2
website/docs/language/functions/startswith.mdx
View File

@ -24,4 +24,4 @@ false
## Related Functions
- [`endswith`](/terraform/language/functions/endswith) takes two values: a string to check and a suffix string. The function returns true if the first string ends with that exact suffix.
- [`endswith`](/opentf/language/functions/endswith) takes two values: a string to check and a suffix string. The function returns true if the first string ends with that exact suffix.

2
website/docs/language/functions/strrev.mdx
View File

@ -23,4 +23,4 @@ olleh
## Related Functions
* [`reverse`](/terraform/language/functions/reverse) reverses a sequence.
* [`reverse`](/opentf/language/functions/reverse) reverses a sequence.

28
website/docs/language/functions/templatefile.mdx
View File

@ -15,30 +15,30 @@ templatefile(path, vars)
```
The template syntax is the same as for
[string templates](/terraform/language/expressions/strings#string-templates)
in the main Terraform language, including interpolation sequences delimited with
[string templates](/opentf/language/expressions/strings#string-templates)
in the main OpenTF language, including interpolation sequences delimited with
`${` ... `}`. This function just allows longer template sequences to be factored
out into a separate file for readability.
The "vars" argument must be an object. Within the template file, each of the
keys in the map is available as a variable for interpolation. The template may
also use any other function available in the Terraform language, except that
also use any other function available in the OpenTF language, except that
recursive calls to `templatefile` are not permitted. Variable names must
each start with a letter, followed by zero or more letters, digits, or
underscores.
Strings in the Terraform language are sequences of Unicode characters, so
Strings in the OpenTF language are sequences of Unicode characters, so
this function will interpret the file contents as UTF-8 encoded text and
return the resulting Unicode characters. If the file contains invalid UTF-8
sequences then this function will produce an error.
This function can be used only with files that already exist on disk at the
beginning of a Terraform run. Functions do not participate in the dependency
beginning of an OpenTF run. Functions do not participate in the dependency
graph, so this function cannot be used with files that are generated
dynamically during a Terraform operation.
dynamically during an OpenTF operation.
`*.tftpl` is the recommended naming pattern to use for your template files.
Terraform will not prevent you from using other names, but following this
OpenTF will not prevent you from using other names, but following this
convention will help your editor understand the content and likely provide
better editing experience as a result.
@ -99,9 +99,9 @@ YAML that will be interpreted correctly when using lots of individual
interpolation sequences and directives.
Instead, you can write a template that consists only of a single interpolated
call to either [`jsonencode`](/terraform/language/functions/jsonencode) or
[`yamlencode`](/terraform/language/functions/yamlencode), specifying the value to encode using
[normal Terraform expression syntax](/terraform/language/expressions)
call to either [`jsonencode`](/opentf/language/functions/jsonencode) or
[`yamlencode`](/opentf/language/functions/yamlencode), specifying the value to encode using
[normal OpenTF expression syntax](/opentf/language/expressions)
as in the following examples:
```
@ -121,9 +121,9 @@ this will produce a valid JSON or YAML representation of the given data
structure, without the need to manually handle escaping or delimiters.
In the latest examples above, the repetition based on elements of `ip_addrs` is
achieved by using a
[`for` expression](/terraform/language/expressions/for)
[`for` expression](/opentf/language/expressions/for)
rather than by using
[template directives](/terraform/language/expressions/strings#directives).
[template directives](/opentf/language/expressions/strings#directives).
```json
{"backends":["10.0.0.1:8080","10.0.0.2:8080"]}
@ -142,9 +142,9 @@ locals {
```
For more information, see the main documentation for
[`jsonencode`](/terraform/language/functions/jsonencode) and [`yamlencode`](/terraform/language/functions/yamlencode).
[`jsonencode`](/opentf/language/functions/jsonencode) and [`yamlencode`](/opentf/language/functions/yamlencode).
## Related Functions
* [`file`](/terraform/language/functions/file) reads a file from disk and returns its literal contents
* [`file`](/opentf/language/functions/file) reads a file from disk and returns its literal contents
without any template interpretation.

Some files were not shown because too many files have changed in this diff Show More