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

Change docs links: /opentf-> /docs (#367)

Browse Source 
Signed-off-by: Roman Grinovski <roman.grinovski@gmail.com>
This commit is contained in:
Roman Grinovski 2023-09-15 14:10:27 +02:00 committed by GitHub
parent bb1783c63b
commit a4f9c63288
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
235 changed files with 974 additions and 974 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
website/docs/cli/auth/index.mdx
View File

@ -22,5 +22,5 @@ TACOS user account.
For details, see:
- [The `opentf login` command](/opentf/cli/commands/login)
- [The `opentf logout` command](/opentf/cli/commands/logout)
- [The `opentf login` command](/docs/cli/commands/login)
- [The `opentf logout` command](/docs/cli/commands/logout)

6
website/docs/cli/cloud/index.mdx
View File

@ -14,7 +14,7 @@ Workspaces can also be configured for local execution, in which case the cloud b
## Documentation Summary
- [Cloud Backend Settings](/opentf/cli/cloud/settings) documents the `cloud` block that you must add to your configuration to enable cloud backend support.
- [Initializing and Migrating](/opentf/cli/cloud/migrating) describes
- [Cloud Backend Settings](/docs/cli/cloud/settings) documents the `cloud` block that you must add to your configuration to enable cloud backend support.
- [Initializing and Migrating](/docs/cli/cloud/migrating) describes
how to start using the cloud backend with a working directory that already has state data.
- [Command Line Arguments](/opentf/cli/cloud/command-line-arguments) lists the OpenTF command flags that are specific to using OpenTF with the cloud backend.
- [Command Line Arguments](/docs/cli/cloud/command-line-arguments) lists the OpenTF command flags that are specific to using OpenTF with the cloud backend.

6
website/docs/cli/cloud/migrating.mdx
View File

@ -6,7 +6,7 @@ description: >-
# Initializing and Migrating
After [configuring cloud backend settings](/opentf/cli/cloud/settings) for a working directory, you must run `opentf init` to finish setting up. If the working directory has no existing OpenTF state, you can start using OpenTF with a cloud backend right away.
After [configuring cloud backend settings](/docs/cli/cloud/settings) for a working directory, you must run `opentf init` to finish setting up. If the working directory has no existing OpenTF state, you can start using OpenTF with a cloud backend right away.
When you run `opentf init` in the following scenarios, OpenTF will ask you to choose whether or not to migrate state from any existing workspaces.
@ -17,7 +17,7 @@ When you run `opentf init` in the following scenarios, OpenTF will ask you to ch
## Migrating from Local State or State Backends
If the working directory already has state data available (using either local state or a [state
backend](/opentf/language/settings/backends/configuration)), OpenTF asks your approval to migrate
backend](/docs/language/settings/backends/configuration)), OpenTF asks your approval to migrate
that state to the cloud backend. You will need permission to manage workspaces in the destination cloud backend organization. This process is interactive and self-documenting, and resembles
moving between state backends.
@ -36,7 +36,7 @@ according to a pattern relative to their existing names. This can indicate the f
If the working directory was already connected to a cloud backend with the `remote` backend, OpenTF can continue using the same cloud backend workspaces. The local names shown for those workspaces will change to match their remote names.
The [`remote` backend](/opentf/language/settings/backends/remote) was the primary implementation for cloud backends for Terraform versions 0.11.13 through 1.0.x. We recommend using the native `cloud` integration for OpenTF and Terraform versions 1.1 or later, as it provides an improved user experience and various enhancements.
The [`remote` backend](/docs/language/settings/backends/remote) was the primary implementation for cloud backends for Terraform versions 0.11.13 through 1.0.x. We recommend using the native `cloud` integration for OpenTF and Terraform versions 1.1 or later, as it provides an improved user experience and various enhancements.
### Block Replacement

12
website/docs/cli/cloud/settings.mdx
View File

@ -11,7 +11,7 @@ OpenTF CLI can integrate with a cloud backend, acting as a client for it.
You must configure the following settings to use the cloud backend for a particular working directory:
- Provide credentials to access the cloud backend, preferably by using the
[`opentf login`](/opentf/cli/commands/login) command.
[`opentf login`](/docs/cli/commands/login) command.
- Add a `cloud` block to the directory's OpenTF configuration, to specify
which organization and workspace(s) to use.
- Optionally, use a `.terraformignore` file to specify files that shouldn't be
@ -42,7 +42,7 @@ terraform {
The `cloud` block also has some special restrictions:
- A configuration can only provide one `cloud` block.
- A `cloud` block cannot be used with [state backends](/opentf/language/settings/backends/configuration).
- A `cloud` block cannot be used with [state backends](/docs/language/settings/backends/configuration).
A configuration can use one or the other, but not both.
- A `cloud` block cannot refer to named values (like input variables, locals, or
data source attributes).
@ -66,7 +66,7 @@ The `cloud` block supports the following configuration arguments:
- `tags` - (Optional) A set of cloud backend workspace tags. You will be able to use
this working directory with any workspaces that have all of the specified tags,
and can use [the `opentf workspace` commands](/opentf/cli/workspaces)
and can use [the `opentf workspace` commands](/docs/cli/workspaces)
to switch between them or create new workspaces. New workspaces will automatically have
the specified tags. This option conflicts with `name`.
@ -81,9 +81,9 @@ The `cloud` block supports the following configuration arguments:
- `token` - (Optional) The token used to authenticate with the cloud backend.
We recommend omitting the token from the configuration, and instead using
[`opentf login`](/opentf/cli/commands/login) or manually configuring
[`opentf login`](/docs/cli/commands/login) or manually configuring
`credentials` in the
[CLI config file](/opentf/cli/config/config-file#credentials).
[CLI config file](/docs/cli/config/config-file#credentials).
### Environment Variables
@ -99,7 +99,7 @@ Use the following environment variables to configure the `cloud` block:
- `TF_CLOUD_PROJECT` - The name of a cloud backend project. OpenTF reads this when `workspaces.project` is omitted from the `cloud` block. If both are specified, the cloud block configuration takes precedence.
- `TF_WORKSPACE` - The name of a single cloud backend workspace. OpenTF reads this when `workspaces` is omitted from the `cloud` block. The cloud backend will not create a new workspace from this variable; the workspace must exist in the specified organization. You can set `TF_WORKSPACE` if the `cloud` block uses tags. However, the value of `TF_WORKSPACE` must be included in the set of tags. This variable also selects the workspace in your local environment. Refer to [TF_WORKSPACE](/opentf/cli/config/environment-variables#tf_workspace) for details.
- `TF_WORKSPACE` - The name of a single cloud backend workspace. OpenTF reads this when `workspaces` is omitted from the `cloud` block. The cloud backend will not create a new workspace from this variable; the workspace must exist in the specified organization. You can set `TF_WORKSPACE` if the `cloud` block uses tags. However, the value of `TF_WORKSPACE` must be included in the set of tags. This variable also selects the workspace in your local environment. Refer to [TF_WORKSPACE](/docs/cli/config/environment-variables#tf_workspace) for details.
## Excluding Files from Upload with .terraformignore

10
website/docs/cli/code/index.mdx
View File

@ -7,7 +7,7 @@ description: >-
# Writing and Modifying OpenTF Code
The [OpenTF language](/opentf/language) is OpenTF's primary
The [OpenTF language](/docs/language) is OpenTF's primary
user interface, and all of OpenTF's workflows rely on configurations written
in the OpenTF language.
@ -15,17 +15,17 @@ OpenTF CLI includes several commands to make OpenTF code more convenient
to work with. Integrating these commands into your editing workflow can
potentially save you time and effort.
- [The `opentf console` command](/opentf/cli/commands/console) starts an
- [The `opentf console` command](/docs/cli/commands/console) starts an
interactive shell for evaluating OpenTF
[expressions](/opentf/language/expressions), which can be a faster way
[expressions](/docs/language/expressions), which can be a faster way
to verify that a particular resource argument results in the value you expect.
- [The `opentf fmt` command](/opentf/cli/commands/fmt) rewrites OpenTF
- [The `opentf fmt` command](/docs/cli/commands/fmt) rewrites OpenTF
configuration files to a canonical format and style, so you don't have to
waste time making minor adjustments for readability and consistency. It works
well as a pre-commit hook in your version control system.
- [The `opentf validate` command](/opentf/cli/commands/validate) validates the
- [The `opentf validate` command](/docs/cli/commands/validate) validates the
syntax and arguments of the OpenTF configuration files in a directory,
including argument and attribute names and types for resources and modules.
The `plan` and `apply` commands automatically validate a configuration before

24
website/docs/cli/commands/apply.mdx
View File

@ -18,8 +18,8 @@ Usage: `opentf apply [options] [plan file]`
### Automatic Plan Mode
When you run `opentf apply` without passing a saved plan file, OpenTF automatically creates a new execution plan as if you had run [`opentf plan`](/opentf/cli/commands/plan), prompts you to approve that plan, and takes the indicated actions. You can use all of the [planning modes](/opentf/cli/commands/plan#planning-modes) and
[planning options](/opentf/cli/commands/plan#planning-options) to customize how OpenTF will create the plan.
When you run `opentf apply` without passing a saved plan file, OpenTF automatically creates a new execution plan as if you had run [`opentf plan`](/docs/cli/commands/plan), prompts you to approve that plan, and takes the indicated actions. You can use all of the [planning modes](/docs/cli/commands/plan#planning-modes) and
[planning options](/docs/cli/commands/plan#planning-options) to customize how OpenTF will create the plan.
You can pass the `-auto-approve` option to instruct OpenTF to apply the plan without asking for confirmation.
@ -27,9 +27,9 @@ You can pass the `-auto-approve` option to instruct OpenTF to apply the plan wit
### Saved Plan Mode
When you pass a [saved plan file](/opentf/cli/commands/plan#out-filename) to `opentf apply`, OpenTF takes the actions in the saved plan without prompting you for confirmation. You may want to use this two-step workflow when running OpenTF in automation.
When you pass a [saved plan file](/docs/cli/commands/plan#out-filename) to `opentf apply`, OpenTF takes the actions in the saved plan without prompting you for confirmation. You may want to use this two-step workflow when running OpenTF in automation.
Use [`opentf show`](/opentf/cli/commands/show) to inspect a saved plan file before applying it.
Use [`opentf show`](/docs/cli/commands/show) to inspect a saved plan file before applying it.
When using a saved plan, you cannot specify any additional planning modes or options. These options only affect OpenTF's decisions about which
actions to take, and the plan file contains the final results of those
@ -39,8 +39,8 @@ decisions.
Without a saved plan file, `opentf apply` supports all planning modes and planning options available for `opentf plan`.
- **[Planning Modes](/opentf/cli/commands/plan#planning-modes):** These include `-destroy`, which creates a plan to destroy all remote objects, and `-refresh-only`, which creates a plan to update OpenTF state and root module output values.
- **[Planning Options](/opentf/cli/commands/plan#planning-options):** These include specifying which resource instances OpenTF should replace, setting OpenTF input variables, etc.
- **[Planning Modes](/docs/cli/commands/plan#planning-modes):** These include `-destroy`, which creates a plan to destroy all remote objects, and `-refresh-only`, which creates a plan to update OpenTF state and root module output values.
- **[Planning Options](/docs/cli/commands/plan#planning-options):** These include specifying which resource instances OpenTF should replace, setting OpenTF input variables, etc.
### Apply Options
@ -82,22 +82,22 @@ The following options change how the apply command executes and reports on the a
rendered by a system that cannot interpret terminal formatting.
- `-parallelism=n` - Limit the number of concurrent operation as OpenTF
[walks the graph](/opentf/internals/graph#walking-the-graph). Defaults to
[walks the graph](/docs/internals/graph#walking-the-graph). Defaults to
10\.
- All [planning modes](/opentf/cli/commands/plan#planning-modes) and
[planning options](/opentf/cli/commands/plan#planning-options) for
- All [planning modes](/docs/cli/commands/plan#planning-modes) and
[planning options](/docs/cli/commands/plan#planning-options) for
`opentf plan` - Customize how OpenTF will create the plan. Only available when you run `opentf apply` without a saved plan file.
For configurations using
[the `local` backend](/opentf/language/settings/backends/local) only,
[the `local` backend](/docs/language/settings/backends/local) only,
`opentf apply` also accepts the legacy options
[`-state`, `-state-out`, and `-backup`](/opentf/language/settings/backends/local#command-line-arguments).
[`-state`, `-state-out`, and `-backup`](/docs/language/settings/backends/local#command-line-arguments).
## Passing a Different Configuration Directory
If your workflow relies on overriding the root module directory, use
[the `-chdir` global option](/opentf/cli/commands#switching-working-directory-with-chdir)
[the `-chdir` global option](/docs/cli/commands#switching-working-directory-with-chdir)
instead, which works across all commands and makes OpenTF consistently look
in the given directory for all files it would normally read or write in the
current working directory.

14
website/docs/cli/commands/console.mdx
View File

@ -8,26 +8,26 @@ description: >-
# Command: console
The `opentf console` command provides an interactive console for
evaluating [expressions](/opentf/language/expressions).
evaluating [expressions](/docs/language/expressions).
## Usage
Usage: `opentf console [options]`
This command provides an interactive command-line console for evaluating and
experimenting with [expressions](/opentf/language/expressions).
experimenting with [expressions](/docs/language/expressions).
You can use it to test interpolations before using them in configurations
and to interact with any values currently saved in
[state](/opentf/language/state). If the current state is empty or has not yet been created, you can use the console to experiment with the expression syntax and
[built-in functions](/opentf/language/functions). The console holds a [lock on the state](/opentf/language/state/locking), and you will not be able to use the console while performing other actions that modify state.
[state](/docs/language/state). If the current state is empty or has not yet been created, you can use the console to experiment with the expression syntax and
[built-in functions](/docs/language/functions). The console holds a [lock on the state](/docs/language/state/locking), and you will not be able to use the console while performing other actions that modify state.
To close the console, enter the `exit` command or press Control-C
or Control-D.
For configurations using
[the `local` backend](/opentf/language/settings/backends/local) only,
[the `local` backend](/docs/language/settings/backends/local) only,
`opentf console` accepts the legacy command line option
[`-state`](/opentf/language/settings/backends/local#command-line-arguments).
[`-state`](/docs/language/settings/backends/local#command-line-arguments).
## Scripting
@ -48,7 +48,7 @@ tolist([
## Remote State
If [remote state](/opentf/language/state/remote) is used by the current backend,
If [remote state](/docs/language/state/remote) is used by the current backend,
OpenTF will read the state for the current workspace from the backend
before evaluating any expressions.

4
website/docs/cli/commands/destroy.mdx
View File

@ -27,7 +27,7 @@ opentf apply -destroy
```
For that reason, this command accepts most of the options that
[`opentf apply`](/opentf/cli/commands/apply) accepts, although it does
[`opentf apply`](/docs/cli/commands/apply) accepts, although it does
not accept a plan file argument and forces the selection of the "destroy"
planning mode.
@ -38,5 +38,5 @@ destroying would be, by running the following command:
opentf plan -destroy
```
This will run [`opentf plan`](/opentf/cli/commands/plan) in _destroy_ mode, showing
This will run [`opentf plan`](/docs/cli/commands/plan) in _destroy_ mode, showing
you the proposed destroy changes without executing them.

2
website/docs/cli/commands/env.mdx
View File

@ -8,5 +8,5 @@ description: >-
# Command: env
The `opentf env` command is deprecated.
[The `opentf workspace` command](/opentf/cli/commands/workspace)
[The `opentf workspace` command](/docs/cli/commands/workspace)
should be used instead.

2
website/docs/cli/commands/fmt.mdx
View File

@ -9,7 +9,7 @@ description: >-
The `opentf fmt` command is used to rewrite OpenTF configuration files
to a canonical format and style. This command applies a subset of
the [OpenTF language style conventions](/opentf/language/syntax/style),
the [OpenTF language style conventions](/docs/language/syntax/style),
along with other minor adjustments for readability.
Other OpenTF commands that generate OpenTF configuration will produce

2
website/docs/cli/commands/get.mdx
View File

@ -6,7 +6,7 @@ description: The opentf get command downloads and updates modules.
# Command: get
The `opentf get` command is used to download and update
[modules](/opentf/language/modules/develop) mentioned in the root module.
[modules](/docs/language/modules/develop) mentioned in the root module.
## Usage

24
website/docs/cli/commands/import.mdx
View File

@ -5,7 +5,7 @@ description: The opentf import command brings existing resources into OpenTF sta
# Command: import
The `opentf import` command [imports existing resources](/opentf/cli/import)
The `opentf import` command [imports existing resources](/docs/cli/import)
into OpenTF.
## Usage
@ -15,7 +15,7 @@ Usage: `opentf import [options] ADDRESS ID`
Import will find the existing resource from ID and import it into your OpenTF
state at the given ADDRESS.
ADDRESS must be a valid [resource address](/opentf/cli/state/resource-addressing).
ADDRESS must be a valid [resource address](/docs/cli/state/resource-addressing).
Because any resource address is valid, the import command can import resources
into modules as well as directly into the root of your state.
@ -31,7 +31,7 @@ itself having created all objects. If you import existing objects into OpenTF,
be careful to import each remote object to only one OpenTF resource address.
If you import the same object multiple times, OpenTF may exhibit unwanted
behavior. For more information on this assumption, see
[the State section](/opentf/language/state).
[the State section](/docs/language/state).
The command-line flags are all optional. The following flags are available:
@ -51,7 +51,7 @@ The command-line flags are all optional. The following flags are available:
- `-no-color` - If specified, output won't contain any color.
- `-parallelism=n` - Limit the number of concurrent operation as OpenTF
[walks the graph](/opentf/internals/graph#walking-the-graph). Defaults
[walks the graph](/docs/internals/graph#walking-the-graph). Defaults
to 10.
- `-provider=provider` - **Deprecated** Override the provider configuration to
@ -60,11 +60,11 @@ The command-line flags are all optional. The following flags are available:
- `-var 'foo=bar'` - Set a variable in the OpenTF configuration. This flag
can be set multiple times. Variable values are interpreted as
[literal expressions](/opentf/language/expressions/types) in the
[literal expressions](/docs/language/expressions/types) in the
OpenTF language, so list and map values can be specified via this flag.
- `-var-file=foo` - Set variables in the OpenTF configuration from
a [variable file](/opentf/language/values/variables#variable-definitions-tfvars-files). If
a [variable file](/docs/language/values/variables#variable-definitions-tfvars-files). If
a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
directory, they will be automatically loaded. `terraform.tfvars` is loaded
first and the `.auto.tfvars` files after in alphabetical order. Any files
@ -72,15 +72,15 @@ The command-line flags are all optional. The following flags are available:
the working directory. This flag can be used multiple times. This is only
useful with the `-config` flag.
For configurations using the [`cloud` backend](/opentf/cli/cloud) or the [`remote` backend](/opentf/language/settings/backends/remote)
For configurations using the [`cloud` backend](/docs/cli/cloud) or the [`remote` backend](/docs/language/settings/backends/remote)
only, `opentf import`
also accepts the option
[`-ignore-remote-version`](/opentf/cli/cloud/command-line-arguments#ignore-remote-version).
[`-ignore-remote-version`](/docs/cli/cloud/command-line-arguments#ignore-remote-version).
For configurations using
[the `local` backend](/opentf/language/settings/backends/local) only,
[the `local` backend](/docs/language/settings/backends/local) only,
`opentf import` also accepts the legacy options
[`-state`, `-state-out`, and `-backup`](/opentf/language/settings/backends/local#command-line-arguments).
[`-state`, `-state-out`, and `-backup`](/docs/language/settings/backends/local#command-line-arguments).
## Provider Configuration
@ -128,7 +128,7 @@ $ opentf import module.foo.aws_instance.bar i-abcd1234
## Example: Import into Resource configured with count
The example below will import an AWS instance into the first instance of the `aws_instance` resource named `baz` configured with
[`count`](/opentf/language/meta-arguments/count):
[`count`](/docs/language/meta-arguments/count):
```shell
$ opentf import 'aws_instance.baz[0]' i-abcd1234
@ -137,7 +137,7 @@ $ opentf import 'aws_instance.baz[0]' i-abcd1234
## Example: Import into Resource configured with for_each
The example below will import an AWS instance into the `"example"` instance of the `aws_instance` resource named `baz` configured with
[`for_each`](/opentf/language/meta-arguments/for_each):
[`for_each`](/docs/language/meta-arguments/for_each):
Linux, Mac OS, and UNIX:

2
website/docs/cli/commands/index.mdx
View File

@ -87,7 +87,7 @@ will be read or written in the given directory instead.
There are two exceptions where OpenTF will use the original working directory
even when you specify `-chdir=...`:
* Settings in the [CLI Configuration](/opentf/cli/config/config-file) are not for a specific
* Settings in the [CLI Configuration](/docs/cli/config/config-file) are not for a specific
subcommand and OpenTF processes them before acting on the `-chdir`
option.

16
website/docs/cli/commands/init.mdx
View File

@ -72,7 +72,7 @@ activating credentials) before running `opentf init`.
## Backend Initialization
During init, the root configuration directory is consulted for
[backend configuration](/opentf/language/settings/backends/configuration) and the chosen backend
[backend configuration](/docs/language/settings/backends/configuration) and the chosen backend
is initialized using the given configuration settings.
Re-running init with an already-initialized backend will update the working
@ -94,14 +94,14 @@ when the working directory was already previously initialized for a particular
backend.
The `-backend-config=...` option can be used for
[partial backend configuration](/opentf/language/settings/backends/configuration#partial-configuration),
[partial backend configuration](/docs/language/settings/backends/configuration#partial-configuration),
in situations where the backend settings are dynamic or sensitive and so cannot
be statically specified in the configuration file.
## Child Module Installation
During init, the configuration is searched for `module` blocks, and the source
code for referenced [modules](/opentf/language/modules/develop) is retrieved from the locations
code for referenced [modules](/docs/language/modules/develop) is retrieved from the locations
given in their `source` arguments.
Re-running init with modules already installed will install the sources for
@ -126,13 +126,13 @@ third-party provider registry, `opentf init` will automatically find,
download, and install the necessary provider plugins. If you cannot or do not
wish to install providers from their origin registries, you can customize how
OpenTF installs providers using
[the provider installation settings in the CLI configuration](/opentf/cli/config/config-file#provider-installation).
[the provider installation settings in the CLI configuration](/docs/cli/config/config-file#provider-installation).
For more information about specifying which providers are required for each
of your modules, see [Provider Requirements](/opentf/language/providers/requirements).
of your modules, see [Provider Requirements](/docs/language/providers/requirements).
After successful installation, OpenTF writes information about the selected
providers to [the dependency lock file](/opentf/language/files/dependency-lock).
providers to [the dependency lock file](/docs/language/files/dependency-lock).
You should commit this file to your version control system to ensure that
when you run `opentf init` again in future OpenTF will select exactly
the same provider versions. Use the `-upgrade` option if you want OpenTF
@ -149,7 +149,7 @@ You can modify `opentf init`'s plugin behavior with the following options:
the specified directory, as if it had been configured as a `filesystem_mirror`
in the CLI configuration. If you intend to routinely use a particular
filesystem mirror then we recommend
[configuring OpenTF's installation methods globally](/opentf/cli/config/config-file#provider-installation).
[configuring OpenTF's installation methods globally](/docs/cli/config/config-file#provider-installation).
You can use `-plugin-dir` as a one-time override for exceptional situations,
such as if you are testing a local build of a provider plugin you are
currently developing.
@ -177,7 +177,7 @@ re-installation.
If your workflow relies on overriding
the root module directory, use
[the `-chdir` global option](/opentf/cli/commands#switching-working-directory-with-chdir)
[the `-chdir` global option](/docs/cli/commands#switching-working-directory-with-chdir)
instead, which works across all commands and makes OpenTF consistently look
in the given directory for all files it would normally read or write in the
current working directory.

6
website/docs/cli/commands/login.mdx
View File

@ -14,7 +14,7 @@ API token for any host that offers OpenTF-compatible services.
where it is possible to launch a web browser on the same host where OpenTF
is running. If you are running OpenTF in an unattended automation scenario,
you can
[configure credentials manually in the CLI configuration](/opentf/cli/config/config-file#credentials).
[configure credentials manually in the CLI configuration](/docs/cli/config/config-file#credentials).
## Usage
@ -30,11 +30,11 @@ not as desired.
If you don't wish to store your API token in the default location, you can
optionally configure a
[credentials helper program](/opentf/cli/config/config-file#credentials-helpers) which knows
[credentials helper program](/docs/cli/config/config-file#credentials-helpers) which knows
how to store and later retrieve credentials in some other system, such as
your organization's existing secrets management system.
## Login Server Support
The `opentf login` command works with any server supporting the
[login protocol](/opentf/internals/login-protocol).
[login protocol](/docs/internals/login-protocol).

2
website/docs/cli/commands/logout.mdx
View File

@ -21,5 +21,5 @@ the remote server, so it will remain valid until manually revoked.
By default, OpenTF will remove the token stored in plain text in a local CLI
configuration file called `credentials.tfrc.json`. If you have configured a
[credentials helper program](/opentf/cli/config/config-file#credentials-helpers), OpenTF
[credentials helper program](/docs/cli/config/config-file#credentials-helpers), OpenTF
will use the helper's `forget` command to remove it.

4
website/docs/cli/commands/output.mdx
View File

@ -30,11 +30,11 @@ The command-line flags are all optional. The following flags are available:
for processing complex data types.
* `-no-color` - If specified, output won't contain any color.
* `-state=path` - Path to the state file. Defaults to "opentf.tfstate".
Ignored when [remote state](/opentf/language/state/remote) is used.
Ignored when [remote state](/docs/language/state/remote) is used.
-> **Note:** When using the `-json` or `-raw` command-line flag, any sensitive
values in OpenTF state will be displayed in plain text. For more information,
see [Sensitive Data in State](/opentf/language/state/sensitive-data).
see [Sensitive Data in State](/docs/language/state/sensitive-data).
## Examples

36
website/docs/cli/commands/plan.mdx
View File

@ -28,12 +28,12 @@ to be taken.
If you are using OpenTF directly in an interactive terminal and you expect
to apply the changes OpenTF proposes, you can alternatively run
[`opentf apply`](/opentf/cli/commands/apply) directly. By default, the "apply" command
[`opentf apply`](/docs/cli/commands/apply) directly. By default, the "apply" command
automatically generates a new plan and prompts for you to approve it.
You can use the optional `-out=FILE` option to save the generated plan to a
file on disk, which you can later execute by passing the file to
[`opentf apply`](/opentf/cli/commands/apply) as an extra argument. This two-step workflow
[`opentf apply`](/docs/cli/commands/apply) as an extra argument. This two-step workflow
is primarily intended for when running OpenTF in automation.
If you run `opentf plan` without the `-out=FILE` option then it will create
@ -80,10 +80,10 @@ The remaining sections on this page describe the various options:
The previous section describes OpenTF's default planning behavior, which
changes the remote system to match the changes you make to
your configuration. OpenTF has two alternative planning modes, each of which creates a plan with a different intended outcome. These options are available for both `opentf plan` and [`opentf apply`](/opentf/cli/commands/apply).
your configuration. OpenTF has two alternative planning modes, each of which creates a plan with a different intended outcome. These options are available for both `opentf plan` and [`opentf apply`](/docs/cli/commands/apply).
* **Destroy mode:** creates a plan whose goal is to destroy all remote objects
that currently exist, leaving an empty OpenTF state. It is the same as running [`opentf destroy`](/opentf/cli/commands/destroy). Destroy mode can be useful for situations like transient development environments, where the managed objects cease to be useful once the development task is complete.
that currently exist, leaving an empty OpenTF state. It is the same as running [`opentf destroy`](/docs/cli/commands/destroy). Destroy mode can be useful for situations like transient development environments, where the managed objects cease to be useful once the development task is complete.
Activate destroy mode using the `-destroy` command line option.
@ -108,7 +108,7 @@ one alternative mode at the same time.
## Planning Options
In addition to alternate [planning modes](#planning-modes), there are several options that can modify planning behavior. These options are available for both `opentf plan` and [`opentf apply`](/opentf/cli/commands/apply).
In addition to alternate [planning modes](#planning-modes), there are several options that can modify planning behavior. These options are available for both `opentf plan` and [`opentf apply`](/docs/cli/commands/apply).
- `-refresh=false` - Disables the default behavior of synchronizing the
OpenTF state with remote objects before checking for configuration changes. This can make the planning operation faster by reducing the number of remote API requests. However, setting `refresh=false` causes OpenTF to ignore external changes, which could result in an incomplete or incorrect plan. You cannot use `refresh=false` in refresh-only planning mode because it would effectively disable the entirety of the planning operation.
@ -123,25 +123,25 @@ In addition to alternate [planning modes](#planning-modes), there are several op
-> **Note:** Use `-target=ADDRESS` in exceptional circumstances only, such as recovering from mistakes or working around OpenTF limitations. Refer to [Resource Targeting](#resource-targeting) for more details.
- `-var 'NAME=VALUE'` - Sets a value for a single
[input variable](/opentf/language/values/variables) declared in the
[input variable](/docs/language/values/variables) declared in the
root module of the configuration. Use this option multiple times to set
more than one variable. Refer to
[Input Variables on the Command Line](#input-variables-on-the-command-line) for more information.
- `-var-file=FILENAME` - Sets values for potentially many
[input variables](/opentf/language/values/variables) declared in the
[input variables](/docs/language/values/variables) declared in the
root module of the configuration, using definitions from a
["tfvars" file](/opentf/language/values/variables#variable-definitions-tfvars-files).
["tfvars" file](/docs/language/values/variables#variable-definitions-tfvars-files).
Use this option multiple times to include values from more than one file.
There are several other ways to set values for input variables in the root
module, aside from the `-var` and `-var-file` options. Refer to
[Assigning Values to Root Module Variables](/opentf/language/values/variables#assigning-values-to-root-module-variables) for more information.
[Assigning Values to Root Module Variables](/docs/language/values/variables#assigning-values-to-root-module-variables) for more information.
### Input Variables on the Command Line
You can use the `-var` command line option to specify values for
[input variables](/opentf/language/values/variables) declared in your
[input variables](/docs/language/values/variables) declared in your
root module.
However, to do so will require writing a command line that is parsable both
@ -190,7 +190,7 @@ so we do not recommend using OpenTF with PowerShell when you are on Windows.
Use Windows Command Prompt instead.
The appropriate syntax for writing the variable value is different depending
on the variable's [type constraint](/opentf/language/expressions/type-constraints).
on the variable's [type constraint](/docs/language/expressions/type-constraints).
The primitive types `string`, `number`, and `bool` all expect a direct string
value with no special punctuation except that required by your shell, as
shown in the above examples. For all other type constraints, including list,
@ -210,13 +210,13 @@ opentf plan -var "name=[\"a\", \"b\", \"c\"]"
Similar constraints apply when setting input variables using environment
variables. For more information on the various methods for setting root module
input variables, see
[Assigning Values to Root Module Variables](/opentf/language/values/variables#assigning-values-to-root-module-variables).
[Assigning Values to Root Module Variables](/docs/language/values/variables#assigning-values-to-root-module-variables).
### Resource Targeting
You can use the `-target` option to focus OpenTF's attention on only a
subset of resources.
You can use [resource address syntax](/opentf/cli/state/resource-addressing)
You can use [resource address syntax](/docs/cli/state/resource-addressing)
to specify the constraint. OpenTF interprets the resource address as follows:
* If the given address identifies one specific resource instance, OpenTF
@ -248,7 +248,7 @@ of resources relates to configuration.
Instead of using `-target` as a means to operate on isolated portions of very
large configurations, prefer instead to break large configurations into
several smaller configurations that can each be independently applied.
[Data sources](/opentf/language/data-sources) can be used to access
[Data sources](/docs/language/data-sources) can be used to access
information about resources created in other configurations, allowing
a complex system architecture to be broken down into more manageable parts
that can be updated independently.
@ -321,18 +321,18 @@ The available options are:
saved plan files as potentially-sensitive artifacts.
* `-parallelism=n` - Limit the number of concurrent operations as OpenTF
[walks the graph](/opentf/internals/graph#walking-the-graph). Defaults
[walks the graph](/docs/internals/graph#walking-the-graph). Defaults
to 10.
For configurations using
[the `local` backend](/opentf/language/settings/backends/local) only,
[the `local` backend](/docs/language/settings/backends/local) only,
`opentf plan` accepts the legacy command line option
[`-state`](/opentf/language/settings/backends/local#command-line-arguments).
[`-state`](/docs/language/settings/backends/local#command-line-arguments).
### Passing a Different Configuration Directory
If your workflow relies on overriding the root module directory, use
[the `-chdir` global option](/opentf/cli/commands#switching-working-directory-with-chdir)
[the `-chdir` global option](/docs/cli/commands#switching-working-directory-with-chdir)
instead, which works across all commands and makes OpenTF consistently look
in the given directory for all files it would normally read or write in the
current working directory.

2
website/docs/cli/commands/providers.mdx
View File

@ -8,7 +8,7 @@ description: >-
# Command: providers
The `opentf providers` command shows information about the
[provider requirements](/opentf/language/providers/requirements) of the
[provider requirements](/docs/language/providers/requirements) of the
configuration in the current working directory, as an aid to understanding
where each requirement was detected from.

16
website/docs/cli/commands/providers/lock.mdx
View File

@ -9,15 +9,15 @@ description: |-
The `opentf providers lock` consults upstream registries (by default) in
order to write provider dependency information into
[the dependency lock file](/opentf/language/files/dependency-lock).
[the dependency lock file](/docs/language/files/dependency-lock).
The common way to update the dependency lock file is as a side-effect of normal
provider installation during
[`opentf init`](/opentf/cli/commands/init), but there are several situations where that
[`opentf init`](/docs/cli/commands/init), but there are several situations where that
automatic approach may not be sufficient:
* If you are running OpenTF in an environment that uses
[alternative provider installation methods](/opentf/cli/config/config-file#provider-installation),
[alternative provider installation methods](/docs/cli/config/config-file#provider-installation),
such as filesystem or network mirrors, normal provider installation will not
access the origin registry for a provider and therefore OpenTF will not
be able to populate all of the possible package checksums for the selected
@ -33,7 +33,7 @@ automatic approach may not be sufficient:
on both Windows and Linux) and the upstream registry for a provider is unable
to provide signed checksums using the latest hashing scheme, subsequent runs
of OpenTF on other platforms may
[add additional checksums to the lock file](/opentf/language/files/dependency-lock#new-provider-package-checksums).
[add additional checksums to the lock file](/docs/language/files/dependency-lock#new-provider-package-checksums).
You can avoid that by pre-populating hashes for all of the platforms you
intend to use, using the `opentf providers lock` command.
@ -45,7 +45,7 @@ With no additional command line arguments, `opentf providers lock` will
analyze the configuration in the current working directory to find all of
the providers it depends on, and it will fetch the necessary data about those
providers from their origin registries and then update
[the dependency lock file](/opentf/language/files/dependency-lock) to
[the dependency lock file](/docs/language/files/dependency-lock) to
include a selected version for each provider and all of the package checksums
that are covered by the provider developer's cryptographic signature.
@ -70,7 +70,7 @@ You can customize the default behavior using the following additional option:
* `-net-mirror=URL` - Direct OpenTF to look for provider packages in the
given network mirror service, instead of in upstream registries. The
given URL must implement
[the OpenTF provider network mirror protocol](/opentf/internals/provider-network-mirror-protocol).
[the OpenTF provider network mirror protocol](/docs/internals/provider-network-mirror-protocol).
* `-platform=OS_ARCH` - Specify a platform you intend to use to work with this
OpenTF configuration. OpenTF will ensure that the providers are all
@ -146,7 +146,7 @@ multiple times and specify a different subset of your providers each time.
The `-fs-mirror` and `-net-mirror` options have the same meaning as
`filesystem_mirror` and `network_mirror` blocks in
[the provider installation methods configuration](/opentf/cli/config/config-file#provider-installation),
[the provider installation methods configuration](/docs/cli/config/config-file#provider-installation),
but specify only a single method in order to be explicit about where you
intend to derive the package checksum information from.
@ -163,4 +163,4 @@ If you wish, you can publish your in-house providers via an in-house provider
registry, which will then allow locking and installation of those providers
without any special options or additional CLI configuration. For more
information, see
[the provider registry protocol](/opentf/internals/provider-registry-protocol).
[the provider registry protocol](/docs/internals/provider-registry-protocol).

4
website/docs/cli/commands/providers/mirror.mdx
View File

@ -17,7 +17,7 @@ from provider registries as part of initializing the current working directory.
Sometimes OpenTF is running in an environment where that isn't possible,
such as on an isolated network without access to an OpenTF Registry. In
that case,
[explicit installation method configuration](/opentf/cli/config/config-file#explicit-installation-method-configuration)
[explicit installation method configuration](/docs/cli/config/config-file#explicit-installation-method-configuration)
allows you to configure OpenTF, when running on a particular system, to
consult only a local filesystem directory where you've created a local mirror
of the necessary plugins, and to skip accessing the upstream registry at all.
@ -37,7 +37,7 @@ themselves.
OpenTF will also generate various `.json` index files which contain suitable
responses to implement
[the network mirror protocol](/opentf/internals/provider-network-mirror-protocol),
[the network mirror protocol](/docs/internals/provider-network-mirror-protocol),
if you upload the resulting directory to a static website host. OpenTF
ignores those index files when using the directory as a filesystem mirror,
because the directory entries themselves are authoritative in that case.

2
website/docs/cli/commands/providers/schema.mdx
View File

@ -32,7 +32,7 @@ value `"1.0"`. The semantics of this version are:
version.
We will introduce new major versions only within the bounds of
[the OpenTF 1.0 Compatibility Promises](/opentf/language/v1-compatibility-promises).
[the OpenTF 1.0 Compatibility Promises](/docs/language/v1-compatibility-promises).
## Format Summary

8
website/docs/cli/commands/refresh.mdx
View File

@ -15,14 +15,14 @@ unsafe if you have misconfigured credentials for any of your providers.
See below for more information and recommended alternatives.
This won't modify your real remote objects, but it will modify the
[OpenTF state](/opentf/language/state).
[OpenTF state](/docs/language/state).
You shouldn't typically need to use this command, because OpenTF
automatically performs the same refreshing actions as a part of creating
a plan in both the
[`opentf plan`](/opentf/cli/commands/plan)
[`opentf plan`](/docs/cli/commands/plan)
and
[`opentf apply`](/opentf/cli/commands/apply)
[`opentf apply`](/docs/cli/commands/apply)
commands. This command is here primarily for backward compatibility, but
we don't recommend using it because it provides no opportunity to review
the effects of the operation before updating the state.
@ -38,7 +38,7 @@ opentf apply -refresh-only -auto-approve
```
Consequently, it supports all of the same options as
[`opentf apply`](/opentf/cli/commands/apply) except that it does not accept a saved
[`opentf apply`](/docs/cli/commands/apply) except that it does not accept a saved
plan file, it doesn't allow selecting a planning mode other than "refresh only",
and `-auto-approve` is always enabled.

4
website/docs/cli/commands/show.mdx
View File

@ -19,7 +19,7 @@ flag.
-> **Note:** When using the `-json` command-line flag, any sensitive values in
OpenTF state will be displayed in plain text. For more information, see
[Sensitive Data in State](/opentf/language/state/sensitive-data).
[Sensitive Data in State](/docs/language/state/sensitive-data).
## JSON Output
@ -35,7 +35,7 @@ was written, the state needs to be upgraded before it can be displayed with
`-refresh=false`. If you are viewing a state file, run `opentf refresh`
first.
The output format is covered in detail in [JSON Output Format](/opentf/internals/json-format).
The output format is covered in detail in [JSON Output Format](/docs/internals/json-format).
## Usage

4
website/docs/cli/commands/state/index.mdx
View File

@ -7,7 +7,7 @@ description: The `opentf state` command is used for advanced state management.
The `opentf state` command is used for advanced state management.
As your OpenTF usage becomes more advanced, there are some cases where
you may need to modify the [OpenTF state](/opentf/language/state).
you may need to modify the [OpenTF state](/docs/language/state).
Rather than modify the state directly, the `opentf state` commands can
be used in many cases instead.
@ -32,7 +32,7 @@ written to disk and the CLI usage is the same as if it were local state.
All `opentf state` subcommands that modify the state write backup
files. The path of these backup file can be controlled with `-backup`.
Subcommands that are read-only (such as [list](/opentf/cli/commands/state/list))
Subcommands that are read-only (such as [list](/docs/cli/commands/state/list))
do not write any backup files since they aren't modifying the state.
Note that backups for state modification _can not be disabled_. Due to

6
website/docs/cli/commands/state/list.mdx
View File

@ -8,7 +8,7 @@ description: >-
# Command: state list
The `opentf state list` command is used to list resources within a
[OpenTF state](/opentf/language/state).
[OpenTF state](/docs/language/state).
## Usage
@ -24,12 +24,12 @@ within modules are listed last.
For complex infrastructures, the state can contain thousands of resources.
To filter these, provide one or more patterns to the command. Patterns are
in [resource addressing format](/opentf/cli/state/resource-addressing).
in [resource addressing format](/docs/cli/state/resource-addressing).
The command-line flags are all optional. The following flags are available:
* `-state=path` - Path to the state file. Defaults to "opentf.tfstate".
Ignored when [remote state](/opentf/language/state/remote) is used.
Ignored when [remote state](/docs/language/state/remote) is used.
* `-id=id` - ID of resources to show. Ignored when unset.
## Example: All Resources

24
website/docs/cli/commands/state/mv.mdx
View File

@ -7,7 +7,7 @@ description: >-
# Command: state mv
The main function of [OpenTF state](/opentf/language/state) is
The main function of [OpenTF state](/docs/language/state) is
to track the bindings between resource instance addresses in your configuration
and the remote objects they represent. Normally OpenTF automatically
updates the state in response to actions taken when applying a plan, such as
@ -28,7 +28,7 @@ remote objects currently associated with the source to be tracked instead
by the destination.
Both the source and destination addresses must use
[resource address syntax](/opentf/cli/state/resource-addressing), and
[resource address syntax](/docs/cli/state/resource-addressing), and
they must both refer to the same kind of object: you can only move a resource
instance to another resource instance, a whole module instance to another
whole module instance, etc. Furthermore, if you are moving a resource or
@ -66,22 +66,22 @@ This command also accepts the following options:
returning an error. The duration syntax is a number followed by a time
unit letter, such as "3s" for three seconds.
For configurations using the [`cloud` backend](/opentf/cli/cloud) or the [`remote` backend](/opentf/language/settings/backends/remote)
For configurations using the [`cloud` backend](/docs/cli/cloud) or the [`remote` backend](/docs/language/settings/backends/remote)
only, `opentf state mv`
also accepts the option
[`-ignore-remote-version`](/opentf/cli/cloud/command-line-arguments#ignore-remote-version).
[`-ignore-remote-version`](/docs/cli/cloud/command-line-arguments#ignore-remote-version).
The legacy options [`-backup` and `-backup-out`](/opentf/language/settings/backends/local#command-line-arguments)
The legacy options [`-backup` and `-backup-out`](/docs/language/settings/backends/local#command-line-arguments)
operate on a local state file only. Configurations using
[the `remote` backend](/opentf/language/settings/backends/remote)
must specify a local state file with the [`-state`](/opentf/language/settings/backends/local#command-line-arguments)
option in order to use the [`-backup` and `-backup-out`](/opentf/language/settings/backends/local#command-line-arguments)
[the `remote` backend](/docs/language/settings/backends/remote)
must specify a local state file with the [`-state`](/docs/language/settings/backends/local#command-line-arguments)
option in order to use the [`-backup` and `-backup-out`](/docs/language/settings/backends/local#command-line-arguments)
options.
For configurations using
[the `local` state mv](/opentf/language/settings/backends/local) only,
[the `local` state mv](/docs/language/settings/backends/local) only,
`opentf state mv` also accepts the legacy options
[`-state`, `-state-out`, `-backup`, and `-backup-out`](/opentf/language/settings/backends/local#command-line-arguments).
[`-state`, `-state-out`, `-backup`, and `-backup-out`](/docs/language/settings/backends/local#command-line-arguments).
## Example: Rename a Resource
@ -133,7 +133,7 @@ opentf state mv module.app module.parent.module.app
## Example: Move a Particular Instance of a Resource using `count`
A resource defined with [the `count` meta-argument](/opentf/language/meta-arguments/count)
A resource defined with [the `count` meta-argument](/docs/language/meta-arguments/count)
has multiple instances that are each identified by an integer. You can
select a particular instance by including an explicit index in your given
address:
@ -158,7 +158,7 @@ The above examples show the typical quoting syntax for Unix-style shells.
## Example: Move a Resource configured with for_each
A resource defined with [the `for_each` meta-argument](/opentf/language/meta-arguments/for_each)
A resource defined with [the `for_each` meta-argument](/docs/language/meta-arguments/for_each)
has multiple instances that are each identified by an string. You can
select a particular instance by including an explicit key in your given
address.

2
website/docs/cli/commands/state/pull.mdx
View File

@ -8,7 +8,7 @@ description: >-
# Command: state pull
The `opentf state pull` command is used to manually download and output
the state from [remote state](/opentf/language/state/remote). This command also
the state from [remote state](/docs/language/state/remote). This command also
works with local state.
## Usage

8
website/docs/cli/commands/state/push.mdx
View File

@ -6,7 +6,7 @@ description: The `opentf state push` command pushes items to the OpenTF state.
# Command: state push
The `opentf state push` command is used to manually upload a local
state file to [remote state](/opentf/language/state/remote). This command also
state file to [remote state](/docs/language/state/remote). This command also
works with local state.
This command should rarely be used. It is meant only as a utility in case
@ -17,7 +17,7 @@ manual intervention is necessary with the remote state.
Usage: `opentf state push [options] PATH`
This command pushes the state specified by PATH to the currently
configured [backend](/opentf/language/settings/backends/configuration).
configured [backend](/docs/language/settings/backends/configuration).
If PATH is "-" then the state data to push is read from stdin. This data
is loaded completely into memory and verified prior to being written to
@ -42,7 +42,7 @@ Both of these safety checks can be disabled with the `-force` flag.
**This is not recommended.** If you disable the safety checks and are
pushing state, the destination state will be overwritten.
For configurations using the [`cloud` backend](/opentf/cli/cloud) or the [`remote` backend](/opentf/language/settings/backends/remote)
For configurations using the [`cloud` backend](/docs/cli/cloud) or the [`remote` backend](/docs/language/settings/backends/remote)
only, `opentf state push`
also accepts the option
[`-ignore-remote-version`](/opentf/cli/cloud/command-line-arguments#ignore-remote-version).
[`-ignore-remote-version`](/docs/cli/cloud/command-line-arguments#ignore-remote-version).

10
website/docs/cli/commands/state/replace-provider.mdx
View File

@ -8,7 +8,7 @@ description: >-
# Command: state replace-provider
The `opentf state replace-provider` command is used to replace the provider
for resources in a [OpenTF state](/opentf/language/state).
for resources in a [OpenTF state](/docs/language/state).
## Usage
@ -32,15 +32,15 @@ This command also accepts the following options:
- `-lock-timeout=0s` - Duration to retry a state lock.
For configurations using the [`cloud` backend](/opentf/cli/cloud) or the [`remote` backend](/opentf/language/settings/backends/remote)
For configurations using the [`cloud` backend](/docs/cli/cloud) or the [`remote` backend](/docs/language/settings/backends/remote)
only, `opentf state replace-provider`
also accepts the option
[`-ignore-remote-version`](/opentf/cli/cloud/command-line-arguments#ignore-remote-version).
[`-ignore-remote-version`](/docs/cli/cloud/command-line-arguments#ignore-remote-version).
For configurations using
[the `local` state](/opentf/language/settings/backends/local) only,
[the `local` state](/docs/language/settings/backends/local) only,
`opentf state replace-provider` also accepts the legacy options
[`-state`, `-state-out`, and `-backup`](/opentf/language/settings/backends/local#command-line-arguments).
[`-state`, `-state-out`, and `-backup`](/docs/language/settings/backends/local#command-line-arguments).
## Example

18
website/docs/cli/commands/state/rm.mdx
View File

@ -7,7 +7,7 @@ description: >-
# Command: state rm
The main function of [OpenTF state](/opentf/language/state) is
The main function of [OpenTF state](/docs/language/state) is
to track the bindings between resource instance addresses in your configuration
and the remote objects they represent. Normally OpenTF automatically
updates the state in response to actions taken when applying a plan, such as
@ -23,13 +23,13 @@ to exist in the remote system.
Usage: `opentf state rm [options] ADDRESS...`
OpenTF will search the state for any instances matching the given
[resource address](/opentf/cli/state/resource-addressing), and remove
[resource address](/docs/cli/state/resource-addressing), and remove
the record of each one so that OpenTF will no longer be tracking the
corresponding remote objects.
This means that although the objects will still continue to exist in the
remote system, a subsequent
[`opentf plan`](/opentf/cli/commands/plan)
[`opentf plan`](/docs/cli/commands/plan)
will include an action to create a new object for each of the "forgotten"
instances. Depending on the constraints imposed by the remote system, creating
those objects might fail if their names or other identifiers conflict with
@ -49,15 +49,15 @@ This command also accepts the following options:
returning an error. The duration syntax is a number followed by a time
unit letter, such as "3s" for three seconds.
For configurations using the [`cloud` backend](/opentf/cli/cloud) or the [`remote` backend](/opentf/language/settings/backends/remote)
For configurations using the [`cloud` backend](/docs/cli/cloud) or the [`remote` backend](/docs/language/settings/backends/remote)
only, `opentf state rm`
also accepts the option
[`-ignore-remote-version`](/opentf/cli/cloud/command-line-arguments#ignore-remote-version).
[`-ignore-remote-version`](/docs/cli/cloud/command-line-arguments#ignore-remote-version).
For configurations using
[the `local` state rm](/opentf/language/settings/backends/local) only,
[the `local` state rm](/docs/language/settings/backends/local) only,
`opentf state rm` also accepts the legacy options
[`-state`, `-state-out`, and `-backup`](/opentf/language/settings/backends/local#command-line-arguments).
[`-state`, `-state-out`, and `-backup`](/docs/language/settings/backends/local#command-line-arguments).
## Example: Remove all Instances of a Resource
@ -92,7 +92,7 @@ $ opentf state rm 'module.foo'
## Example: Remove a Particular Instance of a Resource using `count`
A resource defined with [the `count` meta-argument](/opentf/language/meta-arguments/count)
A resource defined with [the `count` meta-argument](/docs/language/meta-arguments/count)
has multiple instances that are each identified by an integer. You can
select a particular instance by including an explicit index in your given
address:
@ -107,7 +107,7 @@ The above shows the typical quoting syntax for Unix-style shells.
## Example: Remove a Particular Instance of a Resource using `for_each`
A resource defined with [the `for_each` meta-argument](/opentf/language/meta-arguments/for_each)
A resource defined with [the `for_each` meta-argument](/docs/language/meta-arguments/for_each)
has multiple instances that are each identified by an string. You can
select a particular instance by including an explicit key in your given
address.

12
website/docs/cli/commands/state/show.mdx
View File

@ -9,7 +9,7 @@ description: >-
The `opentf state show` command is used to show the attributes of a
single resource in the
[OpenTF state](/opentf/language/state).
[OpenTF state](/docs/language/state).
## Usage
@ -20,16 +20,16 @@ state file that matches the given address.
This command requires an address that points to a single resource in the
state. Addresses are
in [resource addressing format](/opentf/cli/state/resource-addressing).
in [resource addressing format](/docs/cli/state/resource-addressing).
The command-line flags are all optional. The following flags are available:
* `-state=path` - Path to the state file. Defaults to "opentf.tfstate".
Ignored when [remote state](/opentf/language/state/remote) is used.
Ignored when [remote state](/docs/language/state/remote) is used.
The output of `opentf state show` is intended for human consumption, not
programmatic consumption. To extract state data for use in other software, use
[`opentf show -json`](/opentf/cli/commands/show#json-output) and decode the result
[`opentf show -json`](/docs/cli/commands/show#json-output) and decode the result
using the documented structure.
## Example: Show a Resource
@ -60,7 +60,7 @@ $ opentf state show 'module.foo.packet_device.worker'
## Example: Show a Resource configured with count
The example below shows the first instance of a `packet_device` resource named `worker` configured with
[`count`](/opentf/language/meta-arguments/count):
[`count`](/docs/language/meta-arguments/count):
```shell
$ opentf state show 'packet_device.worker[0]'
@ -68,7 +68,7 @@ $ opentf state show 'packet_device.worker[0]'
## Example: Show a Resource configured with for_each
The following example shows the `"example"` instance of a `packet_device` resource named `worker` configured with the [`for_each`](/opentf/language/meta-arguments/for_each) meta-argument. You must place the resource name in single quotes when it contains special characters like double quotes.
The following example shows the `"example"` instance of a `packet_device` resource named `worker` configured with the [`for_each`](/docs/language/meta-arguments/for_each) meta-argument. You must place the resource name in single quotes when it contains special characters like double quotes.
Linux, Mac OS, and UNIX:

12
website/docs/cli/commands/taint.mdx
View File

@ -16,7 +16,7 @@ propose to replace it in the next plan you create.
## Recommended Alternative
We recommend using the [`-replace` option](/opentf/cli/commands/plan#replace-address) with `opentf apply` to force OpenTF to replace an object even though there are no configuration changes that would require it.
We recommend using the [`-replace` option](/docs/cli/commands/plan#replace-address) with `opentf apply` to force OpenTF to replace an object even though there are no configuration changes that would require it.
```
$ opentf apply -replace="aws_instance.example[0]"
@ -32,7 +32,7 @@ $ opentf taint [options] <address>
The `address` argument is the address of the resource to mark as tainted.
The address is in
[the resource address syntax](/opentf/cli/state/resource-addressing),
[the resource address syntax](/docs/cli/state/resource-addressing),
as shown in the output from other commands, such as:
- `aws_instance.foo`
@ -55,11 +55,11 @@ This command accepts the following options:
returning an error. The duration syntax is a number followed by a time
unit letter, such as "3s" for three seconds.
For configurations using the [`cloud` backend](/opentf/cli/cloud) or the [`remote` backend](/opentf/language/settings/backends/remote) only, `opentf taint`
For configurations using the [`cloud` backend](/docs/cli/cloud) or the [`remote` backend](/docs/language/settings/backends/remote) only, `opentf taint`
also accepts the option
[`-ignore-remote-version`](/opentf/cli/cloud/command-line-arguments#ignore-remote-version).
[`-ignore-remote-version`](/docs/cli/cloud/command-line-arguments#ignore-remote-version).
For configurations using
[the `local` backend](/opentf/language/settings/backends/local) only,
[the `local` backend](/docs/language/settings/backends/local) only,
`opentf taint` also accepts the legacy options
[`-state`, `-state-out`, and `-backup`](/opentf/language/settings/backends/local#command-line-arguments).
[`-state`, `-state-out`, and `-backup`](/docs/language/settings/backends/local#command-line-arguments).

2
website/docs/cli/commands/test.mdx
View File

@ -6,7 +6,7 @@ description: Part of the ongoing design research for module integration testing.
# Command: test
The `opentf test` command is currently serving as part of
[the module integration testing experiment](/opentf/language/modules/testing-experiment).
[the module integration testing experiment](/docs/language/modules/testing-experiment).
It's not ready for routine use, but if you'd be interested in trying the
prototype functionality then we'd love to hear your feedback. See the

12
website/docs/cli/commands/untaint.mdx
View File

@ -16,7 +16,7 @@ a multi-step "create" action, because OpenTF can't be sure that the object
was left in a fully-functional state.
You can also manually mark an object as "tainted" using the deprecated command
[`opentf taint`](/opentf/cli/commands/taint), although we no longer recommend that
[`opentf taint`](/docs/cli/commands/taint), although we no longer recommend that
workflow.
If OpenTF currently considers a particular object as tainted but you've
@ -38,7 +38,7 @@ opentf apply -replace="aws_instance.example[0]"
Usage: `opentf untaint [options] address`
The `address` argument is a [resource address](/opentf/cli/state/resource-addressing)
The `address` argument is a [resource address](/docs/cli/state/resource-addressing)
identifying a particular resource instance which is currently tainted.
This command also accepts the following options:
@ -61,12 +61,12 @@ This command also accepts the following options:
if you are running OpenTF in a context where its output will be
rendered by a system that cannot interpret terminal formatting.
For configurations using the [`cloud` backend](/opentf/cli/cloud) or the [`remote` backend](/opentf/language/settings/backends/remote)
For configurations using the [`cloud` backend](/docs/cli/cloud) or the [`remote` backend](/docs/language/settings/backends/remote)
only, `opentf untaint`
also accepts the option
[`-ignore-remote-version`](/opentf/cli/cloud/command-line-arguments#ignore-remote-version).
[`-ignore-remote-version`](/docs/cli/cloud/command-line-arguments#ignore-remote-version).
For configurations using
[the `local` backend](/opentf/language/settings/backends/local) only,
[the `local` backend](/docs/language/settings/backends/local) only,
`opentf untaint` also accepts the legacy options
[`-state`, `-state-out`, and `-backup`](/opentf/language/settings/backends/local#command-line-arguments).
[`-state`, `-state-out`, and `-backup`](/docs/language/settings/backends/local#command-line-arguments).

2
website/docs/cli/commands/validate.mdx
View File

@ -65,7 +65,7 @@ value `"1.0"`. The semantics of this version are:
version.
We will introduce new major versions only within the bounds of
[the OpenTF 1.0 Compatibility Promises](/opentf/language/v1-compatibility-promises).
[the OpenTF 1.0 Compatibility Promises](/docs/language/v1-compatibility-promises).
In the normal case, OpenTF will print a JSON object to the standard output
stream. The top-level JSON object will have the following properties:

2
website/docs/cli/commands/workspace/delete.mdx
View File

@ -17,7 +17,7 @@ To delete a workspace, it must already exist, it must not be tracking resources,
and it must not be your current workspace. If the workspace is tracking resources,
OpenTF will not allow you to delete it unless the `-force` flag is specified.
Additionally, different [backends](/opentf/language/settings/backends/configuration#backend-types) may implement other
Additionally, different [backends](/docs/language/settings/backends/configuration#backend-types) may implement other
restrictions on whether a workspace is considered safe to delete without the `-force` flag, such as whether the workspace is locked.
If you delete a workspace which is tracking resources (via `-force`), then resources

2
website/docs/cli/commands/workspace/index.mdx
View File

@ -6,7 +6,7 @@ description: The workspace command helps you manage workspaces.
# Command: workspace
The `opentf workspace` command is used to manage
[workspaces](/opentf/language/state/workspaces).
[workspaces](/docs/language/state/workspaces).
This command is a container for further subcommands that each have their own page in the documentation.

14
website/docs/cli/config/config-file.mdx
View File

@ -9,7 +9,7 @@ description: >-
The CLI configuration file configures per-user settings for CLI behaviors,
which apply across all OpenTF working directories. This is separate from
[your infrastructure configuration](/opentf/language).
[your infrastructure configuration](/docs/language).
## Locations
@ -35,7 +35,7 @@ as just `opentf.rc`. Use `dir` from PowerShell or Command Prompt to
confirm the filename.
The location of the OpenTF CLI configuration file can also be specified
using the `TF_CLI_CONFIG_FILE` [environment variable](/opentf/cli/config/environment-variables).
using the `TF_CLI_CONFIG_FILE` [environment variable](/docs/cli/config/environment-variables).
Any such file should follow the naming pattern `*.tfrc`.
## Configuration File Syntax
@ -79,7 +79,7 @@ credentials "app.placeholderplaceholderplaceholder.io" {
}
```
If you are running the OpenTF CLI interactively on a computer with a web browser, you can use [the `opentf login` command](/opentf/cli/commands/login)
If you are running the OpenTF CLI interactively on a computer with a web browser, you can use [the `opentf login` command](/docs/cli/commands/login)
to get credentials and automatically save them in the CLI configuration. If
not, you can manually write `credentials` blocks.
@ -134,7 +134,7 @@ for a specific hostname by writing a `credentials` block alongside the
OpenTF does not include any credentials helpers in the main distribution.
To learn how to write and install your own credentials helpers to integrate
with existing in-house credentials management systems, see
[the guide to Credentials Helper internals](/opentf/internals/credentials-helpers).
[the guide to Credentials Helper internals](/docs/internals/credentials-helpers).
### Credentials Source Priority Order
@ -239,7 +239,7 @@ The following are the two supported installation method types:
use the `https:` scheme and end with a trailing slash.
OpenTF expects the given URL to be a base URL for an implementation of
[the provider network mirror protocol](/opentf/internals/provider-network-mirror-protocol),
[the provider network mirror protocol](/docs/internals/provider-network-mirror-protocol),
which is designed to be relatively easy to implement using typical static
website hosting mechanisms.
@ -364,7 +364,7 @@ understand the consequences of enabling it.
By default OpenTF will use packages from the global cache directory only
if they match at least one of the checksums recorded in the
[dependency lock file](/opentf/language/files/dependency-lock)
[dependency lock file](/docs/language/files/dependency-lock)
for that provider. This ensures that OpenTF can always
generate a complete and correct dependency lock file entry the first time you
use a new provider in a particular configuration.
@ -445,7 +445,7 @@ provider_installation {
With development overrides in effect, the `opentf init` command will still
attempt to select a suitable published version of your provider to install and
record in
[the dependency lock file](/opentf/language/files/dependency-lock)
[the dependency lock file](/docs/language/files/dependency-lock)
for future use, but other commands like
`opentf apply` will disregard the lock file's entry for `hashicorp/null` and
will use the given directory instead. Once your new changes are included in a

18
website/docs/cli/config/environment-variables.mdx
View File

@ -27,7 +27,7 @@ To disable, either unset it, or set it to `off`. For example:
export TF_LOG=off
```
For more on debugging OpenTF, check out the section on [Debugging](/opentf/internals/debugging).
For more on debugging OpenTF, check out the section on [Debugging](/docs/internals/debugging).
## TF_LOG_PATH
@ -37,7 +37,7 @@ This specifies where the log should persist its output to. Note that even when `
export TF_LOG_PATH=./terraform.log
```
For more on debugging OpenTF, check out the section on [Debugging](/opentf/internals/debugging).
For more on debugging OpenTF, check out the section on [Debugging](/docs/internals/debugging).
## TF_INPUT
@ -58,7 +58,7 @@ export TF_VAR_alist='[1,2,3]'
export TF_VAR_amap='{ foo = "bar", baz = "qux" }'
```
For more on how to use `TF_VAR_name` in context, check out the section on [Variable Configuration](/opentf/language/values/variables).
For more on how to use `TF_VAR_name` in context, check out the section on [Variable Configuration](/docs/language/values/variables).
## TF_CLI_ARGS and TF_CLI_ARGS_name
@ -114,7 +114,7 @@ export TF_WORKSPACE=your_workspace
Using this environment variable is recommended only for non-interactive usage, since in a local shell environment it can be easy to forget the variable is set and apply changes to the wrong state.
For more information regarding workspaces, check out the section on [Using Workspaces](/opentf/language/state/workspaces).
For more information regarding workspaces, check out the section on [Using Workspaces](/docs/language/state/workspaces).
## TF_IN_AUTOMATION
@ -143,7 +143,7 @@ export TF_REGISTRY_CLIENT_TIMEOUT=15
## TF_CLI_CONFIG_FILE
The location of the [OpenTF CLI configuration file](/opentf/cli/config/config-file).
The location of the [OpenTF CLI configuration file](/docs/cli/config/config-file).
```shell
export TF_CLI_CONFIG_FILE="$HOME/.opentfrc-custom"
@ -151,9 +151,9 @@ export TF_CLI_CONFIG_FILE="$HOME/.opentfrc-custom"
## TF_PLUGIN_CACHE_DIR
The `TF_PLUGIN_CACHE_DIR` environment variable is an alternative way to set [the `plugin_cache_dir` setting in the CLI configuration](/opentf/cli/config/config-file#provider-plugin-cache).
The `TF_PLUGIN_CACHE_DIR` environment variable is an alternative way to set [the `plugin_cache_dir` setting in the CLI configuration](/docs/cli/config/config-file#provider-plugin-cache).
You can also use `TF_PLUGIN_CACHE_MAY_BREAK_DEPENDENCY_LOCK_FILE` to activate [the transitional compatibility setting `plugin_cache_may_break_dependency_lock_file`](/opentf/cli/config/config-file#allowing-the-provider-plugin-cache-to-break-the-dependency-lock-file).
You can also use `TF_PLUGIN_CACHE_MAY_BREAK_DEPENDENCY_LOCK_FILE` to activate [the transitional compatibility setting `plugin_cache_may_break_dependency_lock_file`](/docs/cli/config/config-file#allowing-the-provider-plugin-cache-to-break-the-dependency-lock-file).
## TF_IGNORE
@ -163,10 +163,10 @@ If `TF_IGNORE` is set to "trace", OpenTF will output debug messages to display i
export TF_IGNORE=trace
```
For more details on `.terraformignore`, please see [Excluding Files from Upload with .terraformignore](/opentf/language/settings/backends/remote#excluding-files-from-upload-with-terraformignore).
For more details on `.terraformignore`, please see [Excluding Files from Upload with .terraformignore](/docs/language/settings/backends/remote#excluding-files-from-upload-with-terraformignore).
## Cloud Backend CLI Integration
The CLI integration with cloud backends lets you use them on the command line. The integration requires including a `cloud` block in your OpenTF configuration. You can define its arguments directly in your configuration file or supply them through environment variables, which can be useful for non-interactive workflows like Continuous Integration (CI).
Refer to [Cloud Backend Settings](/opentf/cli/cloud/settings#environment-variables) for a full list of `cloud` block environment variables.
Refer to [Cloud Backend Settings](/docs/cli/cloud/settings#environment-variables) for a full list of `cloud` block environment variables.

4
website/docs/cli/config/index.mdx
View File

@ -16,9 +16,9 @@ most of the global settings relate to advanced or automated workflows, or
unusual environmental conditions like running OpenTF on an airgapped
instance.
- The [CLI config file](/opentf/cli/config/config-file) configures provider
- The [CLI config file](/docs/cli/config/config-file) configures provider
installation and security features.
- Several [environment variables](/opentf/cli/config/environment-variables) can
- Several [environment variables](/docs/cli/config/environment-variables) can
configure OpenTF's inputs and outputs; this includes some alternate ways to
provide information that is usually passed on the command line or read from
the state of the shell.

2
website/docs/cli/import/importability.mdx
View File

@ -13,4 +13,4 @@ importable. As a result, you cannot import all OpenTF resources.
The resources that you can import are documented at the bottom of
each resource documentation page in the [public Terraform Registry](https://registry.terraform.io/). If you have issues importing a resource, report an issue in the relevant provider repository.
To make a resource importable, refer to [Extending OpenTF: Resources — Import](/opentf/plugin/sdkv2/resources/import).
To make a resource importable, refer to [Extending OpenTF: Resources — Import](/docs/plugin/sdkv2/resources/import).

6
website/docs/cli/import/index.mdx
View File

@ -9,13 +9,13 @@ description: >-
OpenTF can import existing infrastructure resources. This functionality lets you bring existing resources under OpenTF management.
-> **Note:** OpenTF supports `import` blocks. Unlike the `opentf import` command, you can use `import` blocks to import more than one resource at a time, and you can review imports as part of your normal plan and apply workflow. [Learn more about `import` blocks](/opentf/language/import).
-> **Note:** OpenTF supports `import` blocks. Unlike the `opentf import` command, you can use `import` blocks to import more than one resource at a time, and you can review imports as part of your normal plan and apply workflow. [Learn more about `import` blocks](/docs/language/import).
## State Only
~> **Warning:** OpenTF expects that each remote object is bound to a _single_ resource address. You should import each remote object to _one_ OpenTF resource address. If you import the same object multiple times, OpenTF may exhibit unwanted behavior. See [State](/opentf/language/state) for more details.
~> **Warning:** OpenTF expects that each remote object is bound to a _single_ resource address. You should import each remote object to _one_ OpenTF resource address. If you import the same object multiple times, OpenTF may exhibit unwanted behavior. See [State](/docs/language/state) for more details.
The `opentf import` CLI command can only import resources into the [state](/opentf/language/state). Importing via the CLI does _not_ generate configuration. If you want to generate the accompanying configuration for imported resources, [use the `import` block instead](/opentf/language/import).
The `opentf import` CLI command can only import resources into the [state](/docs/language/state). Importing via the CLI does _not_ generate configuration. If you want to generate the accompanying configuration for imported resources, [use the `import` block instead](/docs/language/import).
Before you run `opentf import` you must manually write a `resource` configuration block for the resource. The resource block describes where OpenTF should map the imported object.

6
website/docs/cli/import/usage.mdx
View File

@ -15,7 +15,7 @@ itself having created all objects. If you import existing objects into OpenTF,
be careful to import each remote object to only one OpenTF resource address.
If you import the same object multiple times, OpenTF may exhibit unwanted
behavior. For more information on this assumption, see
[the State section](/opentf/language/state).
[the State section](/docs/language/state).
To import a resource, first write a resource block for it in your
configuration, establishing the name by which it will be known to OpenTF:
@ -49,7 +49,7 @@ OpenTF state.
It is also possible to import to resources in child modules, using their paths,
and to single instances of a resource with `count` or `for_each` set. See
[_Resource Addressing_](/opentf/cli/state/resource-addressing) for more
[_Resource Addressing_](/docs/cli/state/resource-addressing) for more
details on how to specify a target resource.
The syntax of the given ID is dependent on the resource type being imported.
@ -75,4 +75,4 @@ a `resource` block in configuration for each secondary resource. If this is
not done, OpenTF will plan to destroy the imported objects on the next run.
If you want to rename or otherwise move the imported resources, the
[state management commands](/opentf/cli/commands/state) can be used.
[state management commands](/docs/cli/commands/state) can be used.

2
website/docs/cli/index.mdx
View File

@ -14,4 +14,4 @@ TACOS (TF Automation and Collaboration Software).
Notably, this documentation does not cover the syntax and usage of the OpenTF
language. For that, see the
[OpenTF Language Documentation](/opentf/language).
[OpenTF Language Documentation](/docs/language).

6
website/docs/cli/init/index.mdx
View File

@ -10,7 +10,7 @@ description: >-
OpenTF expects to be invoked from a working directory that contains
configuration files written in
[the OpenTF language](/opentf/language). OpenTF uses
[the OpenTF language](/docs/language). OpenTF uses
configuration content from this directory, and also uses the directory to store
settings, cached plugins and modules, and sometimes state data.
@ -25,7 +25,7 @@ A OpenTF working directory typically contains:
configuration is expected to change over time.
- A hidden `.terraform` directory, which OpenTF uses to manage cached
provider plugins and modules, record which
[workspace](/opentf/cli/workspaces) is currently active, and
[workspace](/docs/cli/workspaces) is currently active, and
record the last known backend configuration in case it needs to migrate state
on the next run. This directory is automatically managed by OpenTF, and is
created during initialization.
@ -50,7 +50,7 @@ plugins, and downloading modules. Under some conditions (usually when changing
from one backend to another), it might ask the user for guidance or
confirmation.
For details, see [the `opentf init` command](/opentf/cli/commands/init).
For details, see [the `opentf init` command](/docs/cli/commands/init).
## Reinitialization

12
website/docs/cli/inspect/index.mdx
View File

@ -17,19 +17,19 @@ OpenTF CLI includes some commands for inspecting or transforming this data.
You can use these to integrate other tools with OpenTF's infrastructure data,
or just to gain a deeper or more holistic understanding of your infrastructure.
- [The `opentf graph` command](/opentf/cli/commands/graph) creates a visual
- [The `opentf graph` command](/docs/cli/commands/graph) creates a visual
representation of a configuration or a set of planned changes.
- [The `opentf output` command](/opentf/cli/commands/output) can get the
values for the top-level [output values](/opentf/language/values/outputs) of
- [The `opentf output` command](/docs/cli/commands/output) can get the
values for the top-level [output values](/docs/language/values/outputs) of
a configuration, which are often helpful when making use of the infrastructure
OpenTF has provisioned.
- [The `opentf show` command](/opentf/cli/commands/show) can generate
- [The `opentf show` command](/docs/cli/commands/show) can generate
human-readable versions of a state file or plan file, or generate
machine-readable versions that can be integrated with other tools.
- [The `opentf state list` command](/opentf/cli/commands/state/list) can list
- [The `opentf state list` command](/docs/cli/commands/state/list) can list
the resources being managed by the current working directory and workspace,
providing a complete or filtered list.
- [The `opentf state show` command](/opentf/cli/commands/state/show) can print
- [The `opentf state show` command](/docs/cli/commands/state/show) can print
all of the attributes of a given resource being managed by the current working
directory and workspace, including generated read-only attributes like the
unique ID assigned by the cloud provider.

4
website/docs/cli/install/apt.mdx
View File

@ -15,7 +15,7 @@ Debian and Ubuntu systems, which allow you to install OpenTF using the
`apt install` command or any other APT frontend.
If you are instead using Red Hat Enterprise Linux, CentOS, or Fedora, you
might prefer to [install OpenTF from our Yum repositories](/opentf/cli/install/yum).
might prefer to [install OpenTF from our Yum repositories](/docs/cli/install/yum).
## Repository Configuration
@ -28,7 +28,7 @@ architecture, which is also sometimes known as `x86_64`.
There are no official packages available for other architectures, such as
`arm64`. If you wish to use OpenTF on a non-`amd64` system,
[download a normal release `.zip` file](/opentf/downloads) instead.
[download a normal release `.zip` file](/docs/downloads) instead.
## Installing a Specific Version of OpenTF

4
website/docs/cli/install/yum.mdx
View File

@ -15,7 +15,7 @@ RedHat Enterprise Linux, Fedora, and Amazon Linux systems, which allow you to
install OpenTF using the `yum install` or `dnf install` commands.
If you are instead using Debian or Ubuntu, you
might prefer to [install OpenTF from our APT repositories](/opentf/cli/install/apt).
might prefer to [install OpenTF from our APT repositories](/docs/cli/install/apt).
## Repository Configuration
@ -56,7 +56,7 @@ architecture, which is also sometimes known as `amd64`.
There are no official packages available for other architectures, such as
`aarch64`. If you wish to use OpenTF on a non-`x86_64` system,
[download a normal release `.zip` file](/opentf/downloads) instead.
[download a normal release `.zip` file](/docs/downloads) instead.
## Supported Distribution Releases

18
website/docs/cli/plugins/index.mdx
View File

@ -9,15 +9,15 @@ description: >-
OpenTF relies on plugins called "providers" in order to manage various types
of resources. (For more information about providers, see
[Providers](/opentf/language/providers) in the OpenTF
[Providers](/docs/language/providers) in the OpenTF
language docs.)
-> **Note:** Providers are the only plugin type most OpenTF users interact with. OpenTF also supports third-party provisioner plugins, but
we discourage their use.
OpenTF downloads and/or installs any providers
[required](/opentf/language/providers/requirements) by a configuration
when [initializing](/opentf/cli/init) a working directory. By default,
[required](/docs/language/providers/requirements) by a configuration
when [initializing](/docs/cli/init) a working directory. By default,
this works without any additional interaction but requires network access to
download providers from their source registry.
@ -31,29 +31,29 @@ environments.
OpenTF's configuration file includes options for caching downloaded plugins,
or explicitly specifying a local or HTTPS mirror to install plugins from. For
more information, see [CLI Config File](/opentf/cli/config/config-file).
more information, see [CLI Config File](/docs/cli/config/config-file).
## Getting Plugin Information
Use the [`opentf providers`](/opentf/cli/commands/providers) command to get information
Use the [`opentf providers`](/docs/cli/commands/providers) command to get information
about the providers required by the current working directory's configuration.
Use the [`opentf version`](/opentf/cli/commands/version) command (or
Use the [`opentf version`](/docs/cli/commands/version) command (or
`opentf -version`) to show the specific provider versions installed for the
current working directory.
Use the [`opentf providers schema`](/opentf/cli/commands/providers/schema) command to
Use the [`opentf providers schema`](/docs/cli/commands/providers/schema) command to
get machine-readable information about the resources and configuration options
offered by each provider.
## Managing Plugin Installation
Use the [`opentf providers mirror`](/opentf/cli/commands/providers/mirror) command to
Use the [`opentf providers mirror`](/docs/cli/commands/providers/mirror) command to
download local copies of every provider required by the current working
directory's configuration. This directory will use the nested directory layout
that OpenTF expects when installing plugins from a local source, so you can
transfer it directly to an airgapped system that runs OpenTF.
Use the [`opentf providers lock`](/opentf/cli/commands/providers/lock) command
Use the [`opentf providers lock`](/docs/cli/commands/providers/lock) command
to update the lock file that OpenTF uses to ensure predictable runs when
using ambiguous provider version constraints.

12
website/docs/cli/run/index.mdx
View File

@ -7,7 +7,7 @@ description: 'Learn about commands for core provisioning tasks: plan, apply, and
OpenTF's primary function is to create, modify, and destroy infrastructure
resources to match the desired state described in a
[OpenTF configuration](/opentf/language).
[OpenTF configuration](/docs/language).
When people refer to "running OpenTF," they generally mean performing these
provisioning actions in order to affect real infrastructure objects. The
@ -16,8 +16,8 @@ actions, but these basic provisioning tasks are the core of OpenTF.
OpenTF's provisioning workflow relies on three commands: `plan`, `apply`, and
`destroy`. All of these commands require an
[initialized](/opentf/cli/init) working directory, and all of them act
only upon the currently selected [workspace](/opentf/cli/workspaces).
[initialized](/docs/cli/init) working directory, and all of them act
only upon the currently selected [workspace](/docs/cli/workspaces).
## Planning
@ -38,7 +38,7 @@ resulting actions are as expected. However, `opentf plan` can also save its
plan as a runnable artifact, which `opentf apply` can use to carry out those
exact changes.
For details, see [the `opentf plan` command](/opentf/cli/commands/plan).
For details, see [the `opentf plan` command](/docs/cli/commands/plan).
## Applying
@ -54,7 +54,7 @@ running a new plan. You can use this to reliably perform an exact set of
pre-approved changes, even if the configuration or the state of the real
infrastructure has changed in the minutes since the original plan was created.
For details, see [the `opentf apply` command](/opentf/cli/commands/apply).
For details, see [the `opentf apply` command](/docs/cli/commands/apply).
## Destroying
@ -68,4 +68,4 @@ and then running an apply, except that it doesn't require editing the
configuration. This is more convenient if you intend to provision similar
resources at a later date.
For details, see [the `opentf destroy` command](/opentf/cli/commands/destroy).
For details, see [the `opentf destroy` command](/docs/cli/commands/destroy).

12
website/docs/cli/state/index.mdx
View File

@ -7,7 +7,7 @@ description: >-
# Manipulating OpenTF State
OpenTF uses [state data](/opentf/language/state) to remember which
OpenTF uses [state data](/docs/language/state) to remember which
real-world object corresponds to each resource in the configuration;
this allows it to modify an existing object when its resource declaration
changes.
@ -19,12 +19,12 @@ infrastructure.
OpenTF CLI supports several workflows for interacting with state:
- [Inspecting State](/opentf/cli/state/inspect)
- [Forcing Re-creation](/opentf/cli/state/taint)
- [Moving Resources](/opentf/cli/state/move)
- [Inspecting State](/docs/cli/state/inspect)
- [Forcing Re-creation](/docs/cli/state/taint)
- [Moving Resources](/docs/cli/state/move)
- Importing Pre-existing Resources (documented in the
[Importing Infrastructure](/opentf/cli/import) section)
- [Disaster Recovery](/opentf/cli/state/recover)
[Importing Infrastructure](/docs/cli/import) section)
- [Disaster Recovery](/docs/cli/state/recover)
~> **Important:** Modifying state data outside a normal plan or apply can cause
OpenTF to lose track of managed resources, which might waste money, annoy

6
website/docs/cli/state/inspect.mdx
View File

@ -8,14 +8,14 @@ description: Commands that allow you to read and update state.
OpenTF includes some commands for reading and updating state without taking
any other actions.
- [The `opentf state list` command](/opentf/cli/commands/state/list)
- [The `opentf state list` command](/docs/cli/commands/state/list)
shows the resource addresses for every resource OpenTF knows about in a
configuration, optionally filtered by partial resource address.
- [The `opentf state show` command](/opentf/cli/commands/state/show)
- [The `opentf state show` command](/docs/cli/commands/state/show)
displays detailed state data about one resource.
- [The `opentf refresh` command](/opentf/cli/commands/refresh) updates
- [The `opentf refresh` command](/docs/cli/commands/refresh) updates
state data to match the real-world condition of the managed resources. This is
done automatically during plans and applies, but not when interacting with
state directly.

10
website/docs/cli/state/move.mdx
View File

@ -8,7 +8,7 @@ description: >-
# Moving Resources
OpenTF's state associates each real-world object with a configured resource
at a specific [resource address](/opentf/cli/state/resource-addressing). This
at a specific [resource address](/docs/cli/state/resource-addressing). This
is seamless when changing a resource's attributes, but OpenTF will lose track
of a resource if you change its name, move it to a different module, or change
its provider.
@ -22,24 +22,24 @@ can explicitly tell OpenTF to associate it with a different configured
resource.
For most cases we recommend using
[the OpenTF language's refactoring features](/opentf/language/modules/develop/refactoring)
[the OpenTF language's refactoring features](/docs/language/modules/develop/refactoring)
to document in your module exactly how the resource names have changed over
time. OpenTF reacts to this information automatically during planning, so users of your module do not need to take any unusual extra steps.
There are some other situations which require explicit state modifications,
though. For those, consider the following OpenTF commands:
- [The `opentf state mv` command](/opentf/cli/commands/state/mv) changes
- [The `opentf state mv` command](/docs/cli/commands/state/mv) changes
which resource address in your configuration is associated with a particular
real-world object. Use this to preserve an object when renaming a resource, or
when moving a resource into or out of a child module.
- [The `opentf state rm` command](/opentf/cli/commands/state/rm) tells
- [The `opentf state rm` command](/docs/cli/commands/state/rm) tells
OpenTF to stop managing a resource as part of the current working directory
and workspace, _without_ destroying the corresponding real-world object. (You
can later use `opentf import` to start managing that resource in a
different workspace or a different OpenTF configuration.)
- [The `opentf state replace-provider` command](/opentf/cli/commands/state/replace-provider)
- [The `opentf state replace-provider` command](/docs/cli/commands/state/replace-provider)
transfers existing resources to a new provider without requiring them to be
re-created.

6
website/docs/cli/state/recover.mdx
View File

@ -11,7 +11,7 @@ If something has gone horribly wrong (possibly due to accidents when performing
other state manipulation actions), you might need to take drastic actions with
your state data.
- [The `opentf force-unlock` command](/opentf/cli/commands/force-unlock) can
- [The `opentf force-unlock` command](/docs/cli/commands/force-unlock) can
override the protections OpenTF uses to prevent two processes from
modifying state at the same time. You might need this if a OpenTF process
(like a normal apply) is unexpectedly terminated (like by the complete
@ -19,7 +19,7 @@ your state data.
state backend. Do not run this until you are completely certain what happened
to the process that caused the lock to get stuck.
- [The `opentf state pull` command](/opentf/cli/commands/state/pull) and
[the `opentf state push` command](/opentf/cli/commands/state/push) can
- [The `opentf state pull` command](/docs/cli/commands/state/pull) and
[the `opentf state push` command](/docs/cli/commands/state/push) can
directly read and write entire state files from and to the configured backend.
You might need this for obtaining or restoring a state backup.

6
website/docs/cli/state/taint.mdx
View File

@ -18,7 +18,7 @@ to the problem, because OpenTF only directly manages the machine as a whole.
If you know that an object is damaged, or if you want to force OpenTF to
replace it for any other reason, you can override OpenTF's default behavior
using [the `-replace=...` planning option](/opentf/cli/commands/plan#replace-address)
using [the `-replace=...` planning option](/docs/cli/commands/plan#replace-address)
when you run either `opentf plan` or `opentf apply`:
```shellsession
@ -53,11 +53,11 @@ address using `-replace=...` as described above.
If OpenTF has marked an object as tainted but you consider it to be working
correctly and do not want to replace it, you can override OpenTF's
determination using [the `opentf untaint` command](/opentf/cli/commands/untaint),
determination using [the `opentf untaint` command](/docs/cli/commands/untaint),
after which OpenTF will consider the object to be ready for use by any
downstream resource declarations.
You can also _force_ OpenTF to mark a particular object as tainted using
[the `opentf taint` command](/opentf/cli/commands/taint), but that approach is
[the `opentf taint` command](/docs/cli/commands/taint), but that approach is
deprecated in favor of the `-replace=...` option, which avoids the need to
create an interim state snapshot with a tainted object.

20
website/docs/cli/workspaces/index.mdx
View File

@ -7,7 +7,7 @@ description: >-
# Managing Workspaces
Workspaces in the OpenTF CLI refer to separate instances of [state data](/opentf/language/state) inside the same OpenTF working directory. They are distinctly different from workspaces in a cloud backend, which each have their own OpenTF configuration and function as separate working directories.
Workspaces in the OpenTF CLI refer to separate instances of [state data](/docs/language/state) inside the same OpenTF working directory. They are distinctly different from workspaces in a cloud backend, which each have their own OpenTF configuration and function as separate working directories.
OpenTF relies on state to associate resources with real-world objects. When you run the same configuration multiple times with separate state data, OpenTF can manage multiple sets of non-overlapping resources.
@ -16,18 +16,18 @@ Workspaces can be helpful for specific [use cases](#use-cases), but they are not
## Managing CLI Workspaces
Every [initialized working directory](/opentf/cli/init) starts with one workspace named `default`.
Every [initialized working directory](/docs/cli/init) starts with one workspace named `default`.
Use the [`opentf workspace list`](/opentf/cli/commands/workspace/list), [`opentf workspace new`](/opentf/cli/commands/workspace/new), and [`opentf workspace delete`](/opentf/cli/commands/workspace/delete) commands to manage the available workspaces in the current working directory.
Use the [`opentf workspace list`](/docs/cli/commands/workspace/list), [`opentf workspace new`](/docs/cli/commands/workspace/new), and [`opentf workspace delete`](/docs/cli/commands/workspace/delete) commands to manage the available workspaces in the current working directory.
Use [the `opentf workspace select` command](/opentf/cli/commands/workspace/select) to change the currently selected workspace. For a given working directory, you can only select one workspace at a time. Most OpenTF commands only interact with the currently selected workspace. This includes [provisioning](/opentf/cli/run) and [state manipulation](/opentf/cli/state).
Use [the `opentf workspace select` command](/docs/cli/commands/workspace/select) to change the currently selected workspace. For a given working directory, you can only select one workspace at a time. Most OpenTF commands only interact with the currently selected workspace. This includes [provisioning](/docs/cli/run) and [state manipulation](/docs/cli/state).
When you provision infrastructure in each workspace, you usually need to manually specify different [input variables](/opentf/language/values/variables) to differentiate each collection. For example, you might deploy test infrastructure to a different region.
When you provision infrastructure in each workspace, you usually need to manually specify different [input variables](/docs/language/values/variables) to differentiate each collection. For example, you might deploy test infrastructure to a different region.
## Use Cases
You can create multiple [working directories](/opentf/cli/init) to maintain multiple instances of a configuration with completely separate state data. However, OpenTF installs a separate cache of plugins and modules for each working directory, so maintaining multiple directories can waste bandwidth and disk space. This approach also requires extra tasks like updating configuration from version control for each directory separately and reinitializing each directory when you change the configuration. Workspaces are convenient because they let you create different sets of infrastructure with the same working copy of your configuration and the same plugin and module caches.
You can create multiple [working directories](/docs/cli/init) to maintain multiple instances of a configuration with completely separate state data. However, OpenTF installs a separate cache of plugins and modules for each working directory, so maintaining multiple directories can waste bandwidth and disk space. This approach also requires extra tasks like updating configuration from version control for each directory separately and reinitializing each directory when you change the configuration. Workspaces are convenient because they let you create different sets of infrastructure with the same working copy of your configuration and the same plugin and module caches.
A common use for multiple workspaces is to create a parallel, distinct copy of
a set of infrastructure to test a set of changes before modifying production infrastructure.
@ -48,7 +48,7 @@ development stages or different internal teams. In this case, the backend for ea
## Alternatives to Workspaces
Instead of creating CLI workspaces, you can use one or more [re-usable modules](/opentf/language/modules/develop) to represent the common elements and then represent each instance as a separate configuration that instantiates those common elements in the context of a different [backend](/opentf/language/settings/backends/configuration). The root module of each configuration consists only of a backend configuration and a small number of `module` blocks with arguments describing any small differences between the deployments.
Instead of creating CLI workspaces, you can use one or more [re-usable modules](/docs/language/modules/develop) to represent the common elements and then represent each instance as a separate configuration that instantiates those common elements in the context of a different [backend](/docs/language/settings/backends/configuration). The root module of each configuration consists only of a backend configuration and a small number of `module` blocks with arguments describing any small differences between the deployments.
When multiple configurations represent distinct system components rather than multiple deployments, you can pass data from one component to another using paired resources types and data sources.
@ -58,7 +58,7 @@ When multiple configurations represent distinct system components rather than mu
- For server addresses, use a provider-specific resource to create a DNS record with a predictable name. Then you can either use that name directly or use [the `dns` provider](https://registry.terraform.io/providers/hashicorp/dns/latest/docs) to retrieve the published addresses in other configurations.
- If you store a OpenTF state for one configuration in a remote backend that other configurations can access, then the other configurations can use [`terraform_remote_state`](/opentf/language/state/remote-state-data) to directly consume its root module outputs. This setup creates a tighter coupling between configurations, and the root configuration does not need to publish its results in a separate system.
- If you store a OpenTF state for one configuration in a remote backend that other configurations can access, then the other configurations can use [`terraform_remote_state`](/docs/language/state/remote-state-data) to directly consume its root module outputs. This setup creates a tighter coupling between configurations, and the root configuration does not need to publish its results in a separate system.
## Workspace Internals
@ -68,6 +68,6 @@ Workspaces are also meant to be a shared resource. They are not private, unless
For local state, OpenTF stores the workspace states in a directory called `terraform.tfstate.d`. This directory should be treated similarly to local-only `terraform.tfstate`. Some teams commit these files to version control, but we recommend using a remote backend instead when there are multiple collaborators.
For [remote state](/opentf/language/state/remote), the workspaces are stored directly in the configured [backend](/opentf/language/settings/backends/configuration). For example, if you use [Consul](/opentf/language/settings/backends/consul), the workspaces are stored by appending the workspace name to the state path. To ensure that workspace names are stored correctly and safely in all backends, the name must be valid to use in a URL path segment without escaping.
For [remote state](/docs/language/state/remote), the workspaces are stored directly in the configured [backend](/docs/language/settings/backends/configuration). For example, if you use [Consul](/docs/language/settings/backends/consul), the workspaces are stored by appending the workspace name to the state path. To ensure that workspace names are stored correctly and safely in all backends, the name must be valid to use in a URL path segment without escaping.
OpenTF stores the current workspace name locally in the ignored `.terraform` directory. This allows multiple team members to work on different workspaces concurrently. Workspace names are also attached to associated remote workspaces in a cloud backend. For more details about workspace names in cloud backends, refer to the [CLI Integration (recommended)](/opentf/cli/cloud/settings#arguments) and [remote backend](/opentf/language/settings/backends/remote#workspaces) and documentation.
OpenTF stores the current workspace name locally in the ignored `.terraform` directory. This allows multiple team members to work on different workspaces concurrently. Workspace names are also attached to associated remote workspaces in a cloud backend. For more details about workspace names in cloud backends, refer to the [CLI Integration (recommended)](/docs/cli/cloud/settings#arguments) and [remote backend](/docs/language/settings/backends/remote#workspaces) and documentation.

12
website/docs/internals/credentials-helpers.mdx
View File

@ -8,9 +8,9 @@ description: >-
# Credentials Helpers
For OpenTF-specific features that interact with remote network services,
such as [module registries](/opentf/registry), OpenTF by default looks for
such as [module registries](/docs/registry), OpenTF by default looks for
API credentials to use in these calls in
[the CLI configuration](/opentf/cli/config/config-file).
[the CLI configuration](/docs/cli/config/config-file).
Credentials helpers offer an alternative approach that allows you to customize
how OpenTF obtains credentials using an external program, which can then
@ -18,7 +18,7 @@ directly access an existing secrets management system in your organization.
This page is about how to write and install a credentials helper. To learn
how to configure a credentials helper that was already installed, see
[the CLI config Credentials Helpers section](/opentf/cli/config/config-file#credentials-helpers).
[the CLI config Credentials Helpers section](/docs/cli/config/config-file#credentials-helpers).
## How OpenTF finds Credentials Helpers
@ -28,7 +28,7 @@ particular location and whose name follows a specific naming convention.
A credentials helper called "credstore", for example, would be implemented as
an executable program named `terraform-credentials-credstore` (with an `.exe`
extension on Windows only), and installed in one of the
[default plugin search locations](/opentf/plugin/how-opentf-works#plugin-locations).
[default plugin search locations](/docs/plugin/how-opentf-works#plugin-locations).
## How OpenTF runs Credentials Helpers
@ -55,7 +55,7 @@ The current set of verbs are:
To represent credentials, the credentials helper protocol uses a JSON object
whose contents correspond with the contents of
[`credentials` blocks in the CLI configuration](/opentf/cli/config/config-file#credentials).
[`credentials` blocks in the CLI configuration](/docs/cli/config/config-file#credentials).
To represent an API token, the object contains a property called "token" whose
value is the token string:
@ -158,7 +158,7 @@ other properties as described above.
OpenTF does not have any automatic installation mechanism for credentials
helpers. Instead, the user must extract the helper program executable into
one of the [default plugin search locations](/opentf/plugin/how-opentf-works#plugin-locations).
one of the [default plugin search locations](/docs/plugin/how-opentf-works#plugin-locations).
If you are packaging a credentials helper for distribution, place it in an
named with the expected naming scheme (`terraform-credentials-example`) and,

2
website/docs/internals/functions-meta.mdx
View File

@ -30,7 +30,7 @@ value `"1.0"`. The semantics of this version are:
version.
We will introduce new major versions only within the bounds of
[the OpenTF 1.0 Compatibility Promises](/opentf/language/v1-compatibility-promises).
[the OpenTF 1.0 Compatibility Promises](/docs/language/v1-compatibility-promises).
## Format Summary

4
website/docs/internals/graph.mdx
View File

@ -110,8 +110,8 @@ The amount of parallelism is limited using a semaphore to prevent too many
concurrent operations from overwhelming the resources of the machine running
OpenTF. By default, up to 10 nodes in the graph will be processed
concurrently. This number can be set using the `-parallelism` flag on the
[plan](/opentf/cli/commands/plan), [apply](/opentf/cli/commands/apply), and
[destroy](/opentf/cli/commands/destroy) commands.
[plan](/docs/cli/commands/plan), [apply](/docs/cli/commands/apply), and
[destroy](/docs/cli/commands/destroy) commands.
Setting `-parallelism` is considered an advanced operation and should not be
necessary for normal usage of OpenTF. It may be helpful in certain special

6
website/docs/internals/json-format.mdx
View File

@ -11,7 +11,7 @@ When OpenTF plans to make changes, it prints a human-readable summary to the ter
Since the format of plan files isn't suited for use with external tools (and likely never will be), OpenTF can output a machine-readable JSON representation of a plan file's changes. It can also convert state files to the same format, to simplify data loading and provide better long-term compatibility.
Use `opentf show -json <FILE>` to generate a JSON representation of a plan or state file. See [the `opentf show` documentation](/opentf/cli/commands/show) for more details.
Use `opentf show -json <FILE>` to generate a JSON representation of a plan or state file. See [the `opentf show` documentation](/docs/cli/commands/show) for more details.
The output includes a `format_version` key, which has
value `"1.0"`. The semantics of this version are:
@ -24,7 +24,7 @@ value `"1.0"`. The semantics of this version are:
version.
We will introduce new major versions only within the bounds of
[the OpenTF 1.0 Compatibility Promises](/opentf/language/v1-compatibility-promises).
[the OpenTF 1.0 Compatibility Promises](/docs/language/v1-compatibility-promises).
## Format Summary
@ -341,7 +341,7 @@ The following example illustrates the structure of a `<values-representation>`:
}
```
The translation of attribute and output values is the same intuitive mapping from HCL types to JSON types used by OpenTF's [`jsonencode`](/opentf/language/functions/jsonencode) function. This mapping does lose some information: lists, sets, and tuples all lower to JSON arrays while maps and objects both lower to JSON objects. Unknown values and null values are both treated as absent or null.
The translation of attribute and output values is the same intuitive mapping from HCL types to JSON types used by OpenTF's [`jsonencode`](/docs/language/functions/jsonencode) function. This mapping does lose some information: lists, sets, and tuples all lower to JSON arrays while maps and objects both lower to JSON objects. Unknown values and null values are both treated as absent or null.
Output values include a `"type"` field, which is a [serialization of the value's type](https://pkg.go.dev/github.com/zclconf/go-cty/cty#Type.MarshalJSON). For primitive types this is a string value, such as `"number"` or `"bool"`. Complex types are represented as a nested JSON array, such as `["map","string"]` or `["object",{"a":"number"}]`. This can be used to reconstruct the output value with the correct type.

6
website/docs/internals/login-protocol.mdx
View File

@ -8,18 +8,18 @@ description: >-
# Server-side Login Protocol
~> **Note:** You don't need to read these docs to _use_
[`opentf login`](/opentf/cli/commands/login). The information below is for
[`opentf login`](/docs/cli/commands/login). The information below is for
anyone intending to implement the server side of `opentf login` in order to
offer OpenTF-native services in a third-party system.
The `opentf login` command supports performing an OAuth 2.0 authorization
request using configuration provided by the target host. You may wish to
implement this protocol if you are producing a third-party implementation of
any [OpenTF-native services](/opentf/internals/remote-service-discovery),
any [OpenTF-native services](/docs/internals/remote-service-discovery),
such as an OpenTF module registry.
First, OpenTF uses
[remote service discovery](/opentf/internals/remote-service-discovery) to
[remote service discovery](/docs/internals/remote-service-discovery) to
find the OAuth configuration for the host. The host must support the service
name `login.v1` and define for it an object containing OAuth client
configuration values, like this:

8
website/docs/internals/machine-readable-ui.mdx
View File

@ -22,7 +22,7 @@ value `"1.0"`. The semantics of this version are:
version.
We will introduce new major versions only within the bounds of
[the OpenTF 1.0 Compatibility Promises](/opentf/language/v1-compatibility-promises).
[the OpenTF 1.0 Compatibility Promises](/docs/language/v1-compatibility-promises).
## Sample JSON Output
@ -58,7 +58,7 @@ The following message types are supported:
- `version`: information about the OpenTF version and the version of the schema used for the following messages
- `log`: unstructured human-readable log lines
- `diagnostic`: diagnostic warning or error messages; [see the `opentf validate` docs for more details on the format](/opentf/cli/commands/validate#json)
- `diagnostic`: diagnostic warning or error messages; [see the `opentf validate` docs for more details on the format](/docs/cli/commands/validate#json)
### Operation Results
@ -101,7 +101,7 @@ If drift is detected during planning, OpenTF will emit a `resource_drift` messag
- `resource`: object describing the address of the resource to be changed; see [resource object](#resource-object) below for details
- `action`: the action planned to be taken for the resource. Values: `update`, `delete`.
This message does not include details about the exact changes which caused the change to be planned. That information is available in [the JSON plan output](/opentf/internals/json-format).
This message does not include details about the exact changes which caused the change to be planned. That information is available in [the JSON plan output](/docs/internals/json-format).
### Example
@ -144,7 +144,7 @@ At the end of a plan or before an apply, OpenTF will emit a `planned_change` mes
- `delete_because_each_key`: resource instance key is not included in the `for_each` argument
- `delete_because_no_module`: enclosing module instance is not in configuration
This message does not include details about the exact changes which caused the change to be planned. That information is available in [the JSON plan output](/opentf/internals/json-format).
This message does not include details about the exact changes which caused the change to be planned. That information is available in [the JSON plan output](/docs/internals/json-format).
### Example

8
website/docs/internals/module-registry-protocol.mdx
View File

@ -21,7 +21,7 @@ publishing them on the public Terraform Registry.
The public Terraform Registry implements a superset of the API described on
this page, in order to capture additional information used in the registry UI.
For information on those extensions, see
[OpenTF Registry HTTP API](/opentf/registry/api-docs). Third-party registry
[OpenTF Registry HTTP API](/docs/registry/api-docs). Third-party registry
implementations may choose to implement those extensions if desired, but
OpenTF CLI itself does not use them.
@ -79,7 +79,7 @@ blocks have the same source address.
## Service Discovery
The module registry protocol begins with OpenTF CLI using
[OpenTF's remote service discovery protocol](/opentf/internals/remote-service-discovery),
[OpenTF's remote service discovery protocol](/docs/internals/remote-service-discovery),
with the hostname in the module address acting as the "User-facing Hostname".
The service identifier for the module registry protocol is `modules.v1`.
@ -207,10 +207,10 @@ A successful response has no body, and includes the location from which the
module version's source can be downloaded in the `X-Terraform-Get` header.
The value of this header accepts the same values as the `source` argument
in a `module` block in OpenTF configuration, as described in
[Module Sources](/opentf/language/modules/sources),
[Module Sources](/docs/language/modules/sources),
except that it may not recursively refer to another module registry address.
The value of `X-Terraform-Get` may instead be a relative URL, indicated by
beginning with `/`, `./` or `../`, in which case it is resolved relative to
the full URL of the download endpoint to produce
[an HTTP URL module source](/opentf/language/modules/sources#http-urls).
[an HTTP URL module source](/docs/language/modules/sources#http-urls).

12
website/docs/internals/provider-network-mirror-protocol.mdx
View File

@ -14,7 +14,7 @@ implement to provide an alternative installation source for Terraform providers,
regardless of their origin registries.
OpenTF uses network mirrors only if you activate them explicitly in
[the CLI configuration's `provider_installation` block](/opentf/cli/config/config-file#provider-installation).
[the CLI configuration's `provider_installation` block](/docs/cli/config/config-file#provider-installation).
When enabled, a network mirror can serve providers belonging to any registry
hostname, which can allow an organization to serve all of the OpenTF
providers they intend to use from an internal server, rather than from each
@ -24,7 +24,7 @@ This is _not_ the protocol that should be implemented by a host intending to
serve as an origin registry for OpenTF Providers. To provide an origin
registry (whose hostname would then be included in the source addresses of the
providers it hosts), implement
[the provider registry protocol](/opentf/internals/provider-registry-protocol)
[the provider registry protocol](/docs/internals/provider-registry-protocol)
instead.
## Provider Addresses
@ -32,7 +32,7 @@ instead.
Each OpenTF provider has an associated address which uniquely identifies it
within OpenTF. A provider address has the syntax `hostname/namespace/type`,
which is described in more detail in
[the Provider Requirements documentation](/opentf/language/providers/requirements).
[the Provider Requirements documentation](/docs/language/providers/requirements).
By default, the `hostname` portion of a provider address serves both as part
of its unique identifier _and_ as the location of the registry to retrieve it
@ -50,7 +50,7 @@ the hostname where the provider network mirror is deployed.
## Protocol Base URL
Most OpenTF-native services use
[the remote service discovery protocol](/opentf/internals/remote-service-discovery) so
[the remote service discovery protocol](/docs/internals/remote-service-discovery) so
that the physical location of the endpoints can potentially be separated from
the hostname used in identifiers. The Provider Network Mirror protocol does
_not_ use the service discovery indirection, because a network mirror location
@ -92,7 +92,7 @@ base URL from the above CLI configuration example.
### Authentication
If the CLI configuration includes
[credentials](/opentf/cli/config/config-file#credentials) for the hostname
[credentials](/docs/cli/config/config-file#credentials) for the hostname
given in the network mirror base URL, OpenTF will include those credentials
in its requests for operations described below.
@ -256,7 +256,7 @@ in the appropriate nested subdirectories, and ensure that your system is
configured to serve `.json` files with the `application/json` media type.
As a convenience, OpenTF CLI includes
[the `opentf providers mirror` subcommand](/opentf/cli/commands/providers/mirror),
[the `opentf providers mirror` subcommand](/docs/cli/commands/providers/mirror),
which will analyze the current configuration for the providers it requires,
download the packages for those providers from their origin registries, and
place them into a local directory suitable for use as a mirror.

6
website/docs/internals/provider-registry-protocol.mdx
View File

@ -33,7 +33,7 @@ where:
* `hostname` is the registry host that the provider is considered to have
originated from, and the default location OpenTF will consult for
information about the provider
[unless overridden in the CLI configuration](/opentf/cli/config/config-file#provider-installation).
[unless overridden in the CLI configuration](/docs/cli/config/config-file#provider-installation).
* `namespace` is the name of a namespace, unique on a particular hostname, that
can contain one or more providers that are somehow related. On the public
Terraform Registry the "namespace" represents the organization that is
@ -69,7 +69,7 @@ to see it as an entirely separate provider that will _not_ be usable by modules
that declare a dependency on `hashicorp/azurerm`. If your goal is to create
an alternative local distribution source for an existing provider -- that is,
a _mirror_ of the provider -- refer to
[the provider installation method configuration](/opentf/cli/config/config-file#provider-installation)
[the provider installation method configuration](/docs/cli/config/config-file#provider-installation)
instead.
## Provider Versions
@ -89,7 +89,7 @@ version selection.
## Service Discovery
The providers protocol begins with OpenTF CLI using
[OpenTF's remote service discovery protocol](/opentf/internals/remote-service-discovery),
[OpenTF's remote service discovery protocol](/docs/internals/remote-service-discovery),
with the hostname in the provider address acting as the "User-facing Hostname".
The service identifier for the provider registry protocol is `providers.v1`.

8
website/docs/internals/remote-service-discovery.mdx
View File

@ -83,14 +83,14 @@ version 1 of the module registry protocol:
At present, the following service identifiers are in use:
* `login.v1`: [login protocol version 1](/opentf/cli/commands/login)
* `modules.v1`: [module registry API version 1](/opentf/internals/module-registry-protocol)
* `providers.v1`: [provider registry API version 1](/opentf/internals/provider-registry-protocol)
* `login.v1`: [login protocol version 1](/docs/cli/commands/login)
* `modules.v1`: [module registry API version 1](/docs/internals/module-registry-protocol)
* `providers.v1`: [provider registry API version 1](/docs/internals/provider-registry-protocol)
## Authentication
If credentials for the given hostname are available in
[the CLI config](/opentf/cli/config/config-file#Credentials) through a `credentials_helper` or a host-specific environment variable, then they will be included in the request for the discovery document.
[the CLI config](/docs/cli/config/config-file#Credentials) through a `credentials_helper` or a host-specific environment variable, then they will be included in the request for the discovery document.
The credentials may also be provided to endpoints declared in the discovery
document, depending on the requirements of the service in question.

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

@ -29,11 +29,11 @@ The core OpenTF workflow consists of three stages:
### Manage any 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.
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](/docs/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
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.
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](/docs/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
@ -41,13 +41,13 @@ OpenTF configuration files are declarative, meaning that they describe the end s
### Standardize configurations
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.
OpenTF supports reusable configuration components called [modules](/docs/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 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 [OpenTF use cases](/opentf/intro/use-cases) and [how OpenTF compares to alternatives](/opentf/intro/vs).
-> **Tip:** Learn more about [OpenTF use cases](/docs/intro/use-cases) and [how OpenTF compares to alternatives](/docs/intro/vs).
## Community

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

@ -8,7 +8,7 @@ description: |-
# Use Cases
[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.
[OpenTF](/docs/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 OpenTF use cases and provides related resources that you can use to create OpenTF configurations and workflows.

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

@ -16,7 +16,7 @@ entire datacenter.
Learn how OpenTF compares to:
- [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)
- [Chef, Puppet, etc.](/docs/intro/vs/chef-puppet)
- [CloudFormation, Heat, etc.](/docs/intro/vs/cloudformation)
- [Boto, Fog, etc.](/docs/intro/vs/boto)
- [Custom Solutions](/docs/intro/vs/custom)

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

@ -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 OpenTF's [JSON syntax](/opentf/language/syntax/json) with this
- Use OpenTF's [JSON syntax](/docs/language/syntax/json) with this
type of resource.
- Create a reusable module that wraps this type of resource.
## Details
The language makes a distinction between
[argument syntax and nested block syntax](/opentf/language/syntax/configuration#arguments-and-blocks)
[argument syntax and nested block syntax](/docs/language/syntax/configuration#arguments-and-blocks)
within blocks:
- Argument syntax sets a named argument for the containing object. If the
@ -44,7 +44,7 @@ within blocks:
merging in with any explicitly-defined arguments.
The distinction between these is particularly important for
[JSON syntax](/opentf/language/syntax/json)
[JSON syntax](/docs/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.
@ -138,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](/opentf/language/expressions/dynamic-blocks)
[`dynamic` blocks](/docs/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
@ -148,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](/opentf/language/syntax/json#expression-mapping)
the [JSON expression mapping](/docs/language/syntax/json#expression-mapping)
to produce a list of objects.
The interpretation of these values in JSON syntax is, therefore, equivalent

24
website/docs/language/checks/index.mdx
View File

@ -8,7 +8,7 @@ description: >-
The `check` block can validate your infrastructure outside the usual resource lifecycle. Check blocks address a gap between post-apply and functional validation of infrastructure.
Check blocks allow you to define [custom conditions](/opentf/language/expressions/custom-conditions) that execute on every OpenTF plan or apply operation without affecting the overall status of an operation. Check blocks execute as the last step of a plan or apply after OpenTF has planned or provisioned your infrastructure.
Check blocks allow you to define [custom conditions](/docs/language/expressions/custom-conditions) that execute on every OpenTF plan or apply operation without affecting the overall status of an operation. Check blocks execute as the last step of a plan or apply after OpenTF has planned or provisioned your infrastructure.
## Syntax
@ -33,13 +33,13 @@ check "health_check" {
You can use any data source from any provider as a scoped data source within a `check` block.
A `check` block can optionally contain a nested (a.k.a. scoped) data source. This `data` block behaves like an external [data source](/opentf/language/data-sources), except you can not reference it outside its enclosing `check` block. Additionally, if a scoped data source's provider raises any errors, they are masked as warnings and do not prevent OpenTF from continuing operation execution.
A `check` block can optionally contain a nested (a.k.a. scoped) data source. This `data` block behaves like an external [data source](/docs/language/data-sources), except you can not reference it outside its enclosing `check` block. Additionally, if a scoped data source's provider raises any errors, they are masked as warnings and do not prevent OpenTF from continuing operation execution.
You can use a scoped data source to validate the status of a piece of infrastructure outside of the usual OpenTF resource lifecycle. [In the above example](#syntax), if the `placeholderplaceholderplaceholder_io` data source fails to load, you receive a warning instead of a blocking error, which would occur if you declared this data source outside of a `check` block.
#### Meta-Arguments
Scoped data sources support the `depends_on` and `provider` [meta-arguments](/opentf/language/resources/syntax#meta-arguments). Scoped data sources do not support the `count` or`for_each` meta-arguments.
Scoped data sources support the `depends_on` and `provider` [meta-arguments](/docs/language/resources/syntax#meta-arguments). Scoped data sources do not support the `count` or`for_each` meta-arguments.
##### `depends_on`
@ -47,7 +47,7 @@ The `depends_on` meta-argument can be particularly powerful when used within sco
The first time OpenTF creates the _initial_ plan for our [previous example](#syntax), the plan fails because OpenTF has not applied its configuration yet. Meaning this test fails because OpenTF must still create the resources to make this website exist. Therefore, the first time OpenTF runs this check, it always throws a potentially distracting error message.
You can fix this by adding [`depends_on`](/opentf/language/meta-arguments/depends_on) to your scoped data source, ensuring it depends on an essential piece of your site's infrastructure, such as the load balancer. The check returns `known after apply` until that crucial piece of your website is ready. This strategy avoids producing unnecessary warnings during setup, and the check executes during subsequent plans and applies.
You can fix this by adding [`depends_on`](/docs/language/meta-arguments/depends_on) to your scoped data source, ensuring it depends on an essential piece of your site's infrastructure, such as the load balancer. The check returns `known after apply` until that crucial piece of your website is ready. This strategy avoids producing unnecessary warnings during setup, and the check executes during subsequent plans and applies.
One problem with this strategy is that if the resource your scoped data source `depends_on` changes, the check block returns `known after apply` until OpenTF has updated that resource. Depending on your use case, this behavior could be acceptable or problematic.
@ -55,17 +55,17 @@ We recommend implementing the `depends_on` meta-argument if your scoped data sou
### Assertions
Check blocks validate your custom assertions using `assert` blocks. Each `check` block must have at least one, but potentially many, `assert` blocks. Each `assert` block has a [`condition` attribute](/opentf/language/expressions/custom-conditions#condition-expressions) and an [`error_message` attribute](/opentf/language/expressions/custom-conditions#error-messages).
Check blocks validate your custom assertions using `assert` blocks. Each `check` block must have at least one, but potentially many, `assert` blocks. Each `assert` block has a [`condition` attribute](/docs/language/expressions/custom-conditions#condition-expressions) and an [`error_message` attribute](/docs/language/expressions/custom-conditions#error-messages).
Unlike other [custom conditions](/opentf/language/expressions/custom-conditions), assertions do not affect OpenTF's execution of an operation. A failed assertion reports a warning without halting the ongoing operation. This contrasts with other custom conditions, such as a postcondition, where OpenTF produces an error immediately, halting the operation and blocking the application or planning of future resources.
Unlike other [custom conditions](/docs/language/expressions/custom-conditions), assertions do not affect OpenTF's execution of an operation. A failed assertion reports a warning without halting the ongoing operation. This contrasts with other custom conditions, such as a postcondition, where OpenTF produces an error immediately, halting the operation and blocking the application or planning of future resources.
Condition arguments within `assert` blocks can refer to scoped data sources within the enclosing `check` block and any variables, resources, data sources, or module outputs within the current module.
[Learn more about assertions](/opentf/language/expressions/custom-conditions#checks-with-assertions).
[Learn more about assertions](/docs/language/expressions/custom-conditions#checks-with-assertions).
### Meta-Arguments
Check blocks do not currently support [meta-arguments](/opentf/language/resources/syntax#meta-arguments). We are still collecting feedback on this feature, so if your use case would benefit from check blocks supporting meta-arguments, please [let us know](https://github.com/placeholderplaceholderplaceholder/opentf/issues/new/choose).
Check blocks do not currently support [meta-arguments](/docs/language/resources/syntax#meta-arguments). We are still collecting feedback on this feature, so if your use case would benefit from check blocks supporting meta-arguments, please [let us know](https://github.com/placeholderplaceholderplaceholder/opentf/issues/new/choose).
## Continuous validation in TACOS (TF Automation and Collaboration Software)
@ -73,13 +73,13 @@ TACOS (TF Automation and Collaboration Software) can automatically validate whet
## Choosing Checks or other Custom Conditions
Check blocks offer the most _flexible_ validation solution within OpenTF. You can reference outputs, variables, resources, and data sources within check assertions. You can also use checks to model every alternate [Custom Condition](/opentf/language/expressions/custom-conditions). However, that does not mean you should replace all your custom conditions with check blocks.
Check blocks offer the most _flexible_ validation solution within OpenTF. You can reference outputs, variables, resources, and data sources within check assertions. You can also use checks to model every alternate [Custom Condition](/docs/language/expressions/custom-conditions). However, that does not mean you should replace all your custom conditions with check blocks.
There are major behavioral differences between check block assertions and other custom conditions, the main one being that check blocks do _not_ affect OpenTF's execution of an operation. You can use this non-blocking behavior to decide the best type of validation for your use case.
### Outputs and variables
[Output postconditions](/opentf/language/expressions/custom-conditions#outputs) and [variable validations](/opentf/language/expressions/custom-conditions#input-variable-validation) both make assertions around inputs and outputs.
[Output postconditions](/docs/language/expressions/custom-conditions#outputs) and [variable validations](/docs/language/expressions/custom-conditions#input-variable-validation) both make assertions around inputs and outputs.
This is one of the cases where you might want OpenTF to block further execution.
@ -87,9 +87,9 @@ For example, it is not helpful for OpenTF to warn that an input variable is inva
### Resource Preconditions and Postconditions
The difference between [preconditions and postconditions](/opentf/language/expressions/custom-conditions#preconditions-and-postconditions) and check blocks is more nuanced.
The difference between [preconditions and postconditions](/docs/language/expressions/custom-conditions#preconditions-and-postconditions) and check blocks is more nuanced.
Preconditions are unique amongst the custom conditions in that they execute _before_ a resource change is applied or planned. [Choosing Between Preconditions and Postconditions](/opentf/language/expressions/custom-conditions#choosing-between-preconditions-and-postconditions) offers guidance on choosing between a precondition and a postcondition, and the same topics also apply to choosing between a precondition and a check block.
Preconditions are unique amongst the custom conditions in that they execute _before_ a resource change is applied or planned. [Choosing Between Preconditions and Postconditions](/docs/language/expressions/custom-conditions#choosing-between-preconditions-and-postconditions) offers guidance on choosing between a precondition and a postcondition, and the same topics also apply to choosing between a precondition and a check block.
You can often use postconditions interchangeably with check blocks to validate resources and data sources.

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

@ -11,8 +11,8 @@ description: >-
_Data sources_ allow OpenTF to use information defined outside of OpenTF,
defined by another separate OpenTF configuration, or modified by functions.
Each [provider](/opentf/language/providers) may offer data sources
alongside its set of [resource](/opentf/language/resources)
Each [provider](/docs/language/providers) may offer data sources
alongside its set of [resource](/docs/language/resources)
types.
## Using Data Sources
@ -59,14 +59,14 @@ Each data resource is associated with a single data source, which determines
the kind of object (or objects) it reads and what query constraint arguments
are available.
Each data source in turn belongs to a [provider](/opentf/language/providers),
Each data source in turn belongs to a [provider](/docs/language/providers),
which is a plugin for OpenTF that offers a collection of resource types and
data sources that most often belong to a single cloud or on-premises
infrastructure platform.
Most of the items within the body of a `data` block are defined by and
specific to the selected data source, and these arguments can make full
use of [expressions](/opentf/language/expressions) and other dynamic
use of [expressions](/docs/language/expressions) and other dynamic
OpenTF language features.
However, there are some "meta-arguments" that are defined by OpenTF itself
@ -113,7 +113,7 @@ operation, and is re-calculated each time a new plan is created.
## Data Resource Dependencies
Data resources have the same dependency resolution behavior
[as defined for managed resources](/opentf/language/resources/behavior#resource-dependencies).
[as defined for managed resources](/docs/language/resources/behavior#resource-dependencies).
Setting the `depends_on` meta-argument within `data` blocks defers reading of
the data source until after all changes to the dependencies have been applied.
@ -145,13 +145,13 @@ data "aws_ami" "example" {
Custom conditions can help capture assumptions, helping future maintainers understand the configuration design and intent. They also return useful information about errors earlier and in context, helping consumers more easily diagnose issues in their configurations.
Refer to [Custom Condition Checks](/opentf/language/expressions/custom-conditions#preconditions-and-postconditions) for more details.
Refer to [Custom Condition Checks](/docs/language/expressions/custom-conditions#preconditions-and-postconditions) for more details.
## Multiple Resource Instances
Data resources support [`count`](/opentf/language/meta-arguments/count)
and [`for_each`](/opentf/language/meta-arguments/for_each)
Data resources support [`count`](/docs/language/meta-arguments/count)
and [`for_each`](/docs/language/meta-arguments/for_each)
meta-arguments as defined for managed resources, with the same syntax and behavior.
As with managed resources, when `count` or `for_each` is present it is important to
@ -161,7 +161,7 @@ own variant of the constraint arguments, producing an indexed result.
## Selecting a Non-default Provider Configuration
Data resources support [the `provider` meta-argument](/opentf/language/meta-arguments/resource-provider)
Data resources support [the `provider` meta-argument](/docs/language/meta-arguments/resource-provider)
as defined for managed resources, with the same syntax and behavior.
## Lifecycle Customizations
@ -198,7 +198,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
[resources](/docs/language/resources), each provider on the
[Public Terraform Registry](https://registry.terraform.io/browse/providers) has its own
documentation for configuring and using the data types it provides.
@ -216,13 +216,13 @@ resource "aws_instance" "web" {
## Meta-Arguments
As data sources are essentially a read only subset of resources, they also
support the same [meta-arguments](/opentf/language/resources/syntax#meta-arguments) of resources
support the same [meta-arguments](/docs/language/resources/syntax#meta-arguments) of resources
with the exception of the
[`lifecycle` configuration block](/opentf/language/meta-arguments/lifecycle).
[`lifecycle` configuration block](/docs/language/meta-arguments/lifecycle).
### Non-Default Provider Configurations
Similarly to [resources](/opentf/language/resources), when
Similarly to [resources](/docs/language/resources), when
a module has multiple configurations for the same provider you can specify which
configuration to use with the `provider` meta-argument:
@ -235,7 +235,7 @@ data "aws_ami" "web" {
```
See
[The Resource `provider` Meta-Argument](/opentf/language/meta-arguments/resource-provider)
[The Resource `provider` Meta-Argument](/docs/language/meta-arguments/resource-provider)
for more information.
## Data Source Lifecycle

4
website/docs/language/expressions/conditionals.mdx
View File

@ -43,7 +43,7 @@ You can create conditions that produce custom error messages for several types o
Custom conditions can help capture assumptions, helping future maintainers understand the configuration design and intent. They also return useful information about errors earlier and in context, helping consumers more easily diagnose issues in their configurations.
Refer to [Custom Condition Checks](/opentf/language/expressions/custom-conditions#input-variable-validation) for details.
Refer to [Custom Condition Checks](/docs/language/expressions/custom-conditions#input-variable-validation) for details.
## Result Types
@ -70,7 +70,7 @@ be some uncertainty about the expected result type.
The following example is contrived because it would be easier to write the
constant `"12"` instead of the type conversion in this case, but shows how to
use [`tostring`](/opentf/language/functions/tostring) to explicitly convert a number to
use [`tostring`](/docs/language/functions/tostring) to explicitly convert a number to
a string.
```hcl

20
website/docs/language/expressions/custom-conditions.mdx
View File

@ -22,7 +22,7 @@ OpenTF's different custom conditions are best suited to various situations. Use
1. [Validation conditions](#input-variable-validation) or [output postconditions](#preconditions-and-postconditions) can ensure your configuration's inputs and outputs meet specific requirements.
1. Resource [preconditions and postconditions](#preconditions-and-postconditions) can validate that OpenTF produces your configuration with predictable results.
For more information on when to use certain custom conditions, see [Choosing Between Preconditions and Postconditions](#choosing-between-preconditions-and-postconditions) and [Choosing Checks or Other Custom Conditions](/opentf/language/checks#choosing-checks-or-other-custom-conditions).
For more information on when to use certain custom conditions, see [Choosing Between Preconditions and Postconditions](#choosing-between-preconditions-and-postconditions) and [Choosing Checks or Other Custom Conditions](/docs/language/checks#choosing-checks-or-other-custom-conditions).
## Input Variable Validation
@ -45,7 +45,7 @@ variable "image_id" {
}
```
If the failure of an expression determines the validation decision, use the [`can` function](/opentf/language/functions/can) as demonstrated in the following example.
If the failure of an expression determines the validation decision, use the [`can` function](/docs/language/functions/can) as demonstrated in the following example.
```hcl
variable "image_id" {
@ -205,7 +205,7 @@ You should also consider the following questions when creating preconditions and
## Checks with Assertions
[Check blocks](/opentf/language/checks) can validate your infrastructure outside the usual resource lifecycle. You can add custom conditions via `assert` blocks, which execute at the end of the plan and apply stages and produce warnings to notify you of problems within your infrastructure.
[Check blocks](/docs/language/checks) can validate your infrastructure outside the usual resource lifecycle. You can add custom conditions via `assert` blocks, which execute at the end of the plan and apply stages and produce warnings to notify you of problems within your infrastructure.
You can add one or more `assert` blocks within a `check` block to verify custom conditions. Each assertion requires a [`condition` argument](#condition-expressions), a boolean expression that should return `true` if the intended assumption or guarantee is fulfilled or `false` if it does not. Your `condition` expression can refer to any resource, data source, or variable available to the surrounding `check` block.
@ -245,11 +245,11 @@ Use the logical operators `&&` (AND), `||` (OR), and `!` (NOT) to combine multip
condition = var.name != "" && lower(var.name) == var.name
```
You can also use arithmetic operators (e.g. `a + b`), equality operators (eg., `a == b`) and comparison operators (e.g., `a < b`). Refer to [Arithmetic and Logical Operators](/opentf/language/expressions/operators) for details.
You can also use arithmetic operators (e.g. `a + b`), equality operators (eg., `a == b`) and comparison operators (e.g., `a < b`). Refer to [Arithmetic and Logical Operators](/docs/language/expressions/operators) for details.
### `contains` Function
Use the [`contains` function](/opentf/language/functions/contains) to test whether a given value is one of a set of predefined valid values.
Use the [`contains` function](/docs/language/functions/contains) to test whether a given value is one of a set of predefined valid values.
```hcl
condition = contains(["STAGE", "PROD"], var.environment)
@ -257,7 +257,7 @@ Use the [`contains` function](/opentf/language/functions/contains) to test wheth
### `length` Function
Use the [`length` function](/opentf/language/functions/length) to test a collection's length and require a non-empty list or map.
Use the [`length` function](/docs/language/functions/length) to test a collection's length and require a non-empty list or map.
```hcl
condition = length(var.items) != 0
@ -266,7 +266,7 @@ This is a better approach than directly comparing with another collection using
### `for` Expressions
Use [`for` expressions](/opentf/language/expressions/for) in conjunction with the functions `alltrue` and `anytrue` to test whether a condition holds for all or for any elements of a collection.
Use [`for` expressions](/docs/language/expressions/for) in conjunction with the functions `alltrue` and `anytrue` to test whether a condition holds for all or for any elements of a collection.
```hcl
condition = alltrue([
@ -276,7 +276,7 @@ Use [`for` expressions](/opentf/language/expressions/for) in conjunction with th
### `can` Function
Use the [`can` function](/opentf/language/functions/can) to concisely use the validity of an expression as a condition. It returns `true` if its given expression evaluates successfully and `false` if it returns any error, so you can use various other functions that typically return errors as a part of your condition expressions.
Use the [`can` function](/docs/language/functions/can) to concisely use the validity of an expression as a condition. It returns `true` if its given expression evaluates successfully and `false` if it returns any error, so you can use various other functions that typically return errors as a part of your condition expressions.
For example, you can use `can` with `regex` to test if a string matches a particular pattern because `regex` returns an error when given a non-matching string.
@ -334,7 +334,7 @@ resource "aws_instance" "example" {
### `each` and `count` Objects
In blocks where [`for_each`](/opentf/language/meta-arguments/for_each) or [`count`](/opentf/language/meta-arguments/count) are set, use `each` and `count` objects to refer to other resources that are expanded in a chain.
In blocks where [`for_each`](/docs/language/meta-arguments/for_each) or [`count`](/docs/language/meta-arguments/count) are set, use `each` and `count` objects to refer to other resources that are expanded in a chain.
```hcl
variable "vpc_cidrs" {
@ -380,7 +380,7 @@ The selected AMI must be tagged with the Component value "nomad-server".
```
The `error_message` argument can be any expression that evaluates to a string.
This includes literal strings, heredocs, and template expressions. You can use the [`format` function](/opentf/language/functions/format) to convert items of `null`, `list`, or `map` types into a formatted string. Multi-line
This includes literal strings, heredocs, and template expressions. You can use the [`format` function](/docs/language/functions/format) to convert items of `null`, `list`, or `map` types into a formatted string. Multi-line
error messages are supported, and lines with leading whitespace will not be
word wrapped.

10
website/docs/language/expressions/dynamic-blocks.mdx
View File

@ -44,7 +44,7 @@ resource "aws_elastic_beanstalk_environment" "tfenvtest" {
}
```
A `dynamic` block acts much like a [`for` expression](/opentf/language/expressions/for), but produces
A `dynamic` block acts much like a [`for` expression](/docs/language/expressions/for), but produces
nested blocks instead of a complex typed value. It iterates over a given
complex value, and generates a nested block for each element of that complex
value.
@ -84,9 +84,9 @@ nested block. If you need to declare resource instances based on a nested
data structure or combinations of elements from multiple data structures you
can use OpenTF expressions and functions to derive a suitable value.
For some common examples of such situations, see the
[`flatten`](/opentf/language/functions/flatten)
[`flatten`](/docs/language/functions/flatten)
and
[`setproduct`](/opentf/language/functions/setproduct)
[`setproduct`](/docs/language/functions/setproduct)
functions.
## Multi-level Nested Block Structures
@ -151,5 +151,5 @@ nested blocks using directly-corresponding attributes from an input variable
then that might suggest that your module is not creating a useful abstraction.
It may be better for the calling module to define the resource itself then
pass information about it into your module. For more information on this design
tradeoff, see [When to Write a Module](/opentf/language/modules/develop#when-to-write-a-module)
and [Module Composition](/opentf/language/modules/develop/composition).
tradeoff, see [When to Write a Module](/docs/language/modules/develop#when-to-write-a-module)
and [Module Composition](/docs/language/modules/develop/composition).

4
website/docs/language/expressions/for.mdx
View File

@ -127,7 +127,7 @@ using lexical sorting.
For sets of strings, OpenTF sorts the elements by their value, using
lexical sorting.
For sets of other types, OpenTF uses an arbitrary ordering that may change in future versions. We recommend converting the expression result into a set to make it clear elsewhere in the configuration that the result is unordered. You can use [the `toset` function](/opentf/language/functions/toset)
For sets of other types, OpenTF uses an arbitrary ordering that may change in future versions. We recommend converting the expression result into a set to make it clear elsewhere in the configuration that the result is unordered. You can use [the `toset` function](/docs/language/functions/toset)
to concisely convert a `for` expression result to be of a set type.
```hcl
@ -204,4 +204,4 @@ Some resource types also define _nested block types_, which typically represent
separate objects that belong to the containing resource in some way. You can't
dynamically generate nested blocks using `for` expressions, but you _can_
generate nested blocks for a resource dynamically using
[`dynamic` blocks](/opentf/language/expressions/dynamic-blocks).
[`dynamic` blocks](/docs/language/expressions/dynamic-blocks).

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

@ -8,7 +8,7 @@ description: >-
# Function Calls
The OpenTF language has a number of
[built-in functions](/opentf/language/functions) that can be used
[built-in functions](/docs/language/functions) that can be used
in expressions to transform and combine values. These
are similar to the operators but all follow a common syntax:
@ -33,7 +33,7 @@ A function call expression evaluates to the function's return value.
## Available Functions
For a full list of available functions, see
[the function reference](/opentf/language/functions).
[the function reference](/docs/language/functions).
## Expanding Function Arguments
@ -50,8 +50,8 @@ The expansion symbol is three periods (`...`), not a Unicode ellipsis character
## Using Sensitive Data as Function Arguments
When using sensitive data, such as [an input variable](/opentf/language/values/variables#suppressing-values-in-cli-output)
or [an output defined](/opentf/language/values/outputs#sensitive-suppressing-values-in-cli-output) as sensitive
When using sensitive data, such as [an input variable](/docs/language/values/variables#suppressing-values-in-cli-output)
or [an output defined](/docs/language/values/outputs#sensitive-suppressing-values-in-cli-output) as sensitive
as function arguments, the result of the function call will be marked as sensitive.
This is a conservative behavior that is true irrespective of the function being
@ -80,10 +80,10 @@ those it can be helpful to know when OpenTF will call them in relation to
other events that occur in an OpenTF run.
The small set of special functions includes
[`file`](/opentf/language/functions/file),
[`templatefile`](/opentf/language/functions/templatefile),
[`timestamp`](/opentf/language/functions/timestamp),
and [`uuid`](/opentf/language/functions/uuid).
[`file`](/docs/language/functions/file),
[`templatefile`](/docs/language/functions/templatefile),
[`timestamp`](/docs/language/functions/timestamp),
and [`uuid`](/docs/language/functions/uuid).
If you are not working with these functions then you don't need
to read this section, although the information here may still be interesting
background information.
@ -102,7 +102,7 @@ both cause the final configuration during the apply step not to match the
actions shown in the plan, which violates the OpenTF execution model.
For that reason, OpenTF arranges for both of those functions to produce
[unknown value](/opentf/language/expressions/references#values-not-yet-known) results during the
[unknown value](/docs/language/expressions/references#values-not-yet-known) results during the
plan step, with the real result being decided only during the apply step.
For `timestamp` in particular, this means that the recorded time will be
the instant when OpenTF began applying the change, rather than when

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

@ -16,54 +16,54 @@ and a number of built-in functions.
Expressions can be used in a number of places in the OpenTF language,
but some contexts limit which expression constructs are allowed,
such as requiring a literal value of a particular type or forbidding
[references to resource attributes](/opentf/language/expressions/references#references-to-resource-attributes).
[references to resource attributes](/docs/language/expressions/references#references-to-resource-attributes).
Each language feature's documentation describes any restrictions it places on
expressions.
You can experiment with the behavior of OpenTF's expressions from
the OpenTF expression console, by running
[the `opentf console` command](/opentf/cli/commands/console).
[the `opentf console` command](/docs/cli/commands/console).
The other pages in this section describe the features of OpenTF's
expression syntax.
- [Types and Values](/opentf/language/expressions/types)
- [Types and Values](/docs/language/expressions/types)
documents the data types that OpenTF expressions can resolve to, and the
literal syntaxes for values of those types.
- [Strings and Templates](/opentf/language/expressions/strings)
- [Strings and Templates](/docs/language/expressions/strings)
documents the syntaxes for string literals, including interpolation sequences
and template directives.
- [References to Values](/opentf/language/expressions/references)
- [References to Values](/docs/language/expressions/references)
documents how to refer to named values like variables and resource attributes.
- [Operators](/opentf/language/expressions/operators)
- [Operators](/docs/language/expressions/operators)
documents the arithmetic, comparison, and logical operators.
- [Function Calls](/opentf/language/expressions/function-calls)
- [Function Calls](/docs/language/expressions/function-calls)
documents the syntax for calling OpenTF's built-in functions.
- [Conditional Expressions](/opentf/language/expressions/conditionals)
- [Conditional Expressions](/docs/language/expressions/conditionals)
documents the `<CONDITION> ? <TRUE VAL> : <FALSE VAL>` expression, which
chooses between two values based on a bool condition.
- [For Expressions](/opentf/language/expressions/for)
- [For Expressions](/docs/language/expressions/for)
documents expressions like `[for s in var.list : upper(s)]`, which can
transform a complex type value into another complex type value.
- [Splat Expressions](/opentf/language/expressions/splat)
- [Splat Expressions](/docs/language/expressions/splat)
documents expressions like `var.list[*].id`, which can extract simpler
collections from more complicated expressions.
- [Dynamic Blocks](/opentf/language/expressions/dynamic-blocks)
- [Dynamic Blocks](/docs/language/expressions/dynamic-blocks)
documents a way to create multiple repeatable nested blocks within a resource
or other construct.
- [Type Constraints](/opentf/language/expressions/type-constraints)
- [Type Constraints](/docs/language/expressions/type-constraints)
documents the syntax for referring to a type, rather than a value of that
type. Input variables expect this syntax in their `type` argument.
- [Version Constraints](/opentf/language/expressions/version-constraints)
- [Version Constraints](/docs/language/expressions/version-constraints)
documents the syntax of special strings that define a set of allowed software
versions. OpenTF uses version constraints in several places.

4
website/docs/language/expressions/operators.mdx
View File

@ -56,9 +56,9 @@ as results:
* `-a` returns the result of multiplying `a` by `-1`.
OpenTF supports some other less-common numeric operations as
[functions](/opentf/language/expressions/function-calls). For example, you can calculate exponents
[functions](/docs/language/expressions/function-calls). For example, you can calculate exponents
using
[the `pow` function](/opentf/language/functions/pow).
[the `pow` function](/docs/language/functions/pow).
## Equality Operators

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

@ -28,7 +28,7 @@ The main kinds of named values available in OpenTF are:
The sections below explain each kind of named value in detail.
Although many of these names use dot-separated paths that resemble
[attribute notation](/opentf/language/expressions/types#indices-and-attributes) for elements of object values, they are not
[attribute notation](/docs/language/expressions/types#indices-and-attributes) for elements of object values, they are not
implemented as real objects. This means you must use them exactly as written:
you cannot use square-bracket notation to replace the dot-separated paths, and
you cannot iterate over the "parent object" of a named entity; for example, you
@ -37,7 +37,7 @@ instance resource.
### Resources
`<RESOURCE TYPE>.<NAME>` represents a [managed resource](/opentf/language/resources) of
`<RESOURCE TYPE>.<NAME>` represents a [managed resource](/docs/language/resources) of
the given type and name.
The value of a resource reference can vary, depending on whether the resource
@ -45,7 +45,7 @@ uses `count` or `for_each`:
* If the resource doesn't use `count` or `for_each`, the reference's value is an
object. The resource's attributes are elements of the object, and you can
access them using [dot or square bracket notation](/opentf/language/expressions/types#indices-and-attributes).
access them using [dot or square bracket notation](/docs/language/expressions/types#indices-and-attributes).
* If the resource has the `count` argument set, the reference's value is a
_list_ of objects representing its instances.
* If the resource has the `for_each` argument set, the reference's value is a
@ -59,7 +59,7 @@ For more information about how to use resource references, see
### Input Variables
`var.<NAME>` is the value of the [input variable](/opentf/language/values/variables) of the given name.
`var.<NAME>` is the value of the [input variable](/docs/language/values/variables) of the given name.
If the variable has a type constraint (`type` argument) as part of its
declaration, OpenTF will automatically convert the caller's given value
@ -77,7 +77,7 @@ constraint all of the attributes you intend to use elsewhere in your module.
### Local Values
`local.<NAME>` is the value of the [local value](/opentf/language/values/locals) of the given name.
`local.<NAME>` is the value of the [local value](/docs/language/values/locals) of the given name.
Local values can refer to other local values, even within the same `locals`
block, as long as you don't introduce circular dependencies.
@ -85,12 +85,12 @@ block, as long as you don't introduce circular dependencies.
### Child Module Outputs
`module.<MODULE NAME>` is an value representing the results of
[a `module` block](/opentf/language/modules/syntax).
[a `module` block](/docs/language/modules/syntax).
If the corresponding `module` block does not have either `count` nor `for_each`
set then the value will be an object with one attribute for each output value
defined in the child module. To access one of the module's
[output values](/opentf/language/values/outputs), use `module.<MODULE NAME>.<OUTPUT NAME>`.
[output values](/docs/language/values/outputs), use `module.<MODULE NAME>.<OUTPUT NAME>`.
If the corresponding `module` uses `for_each` then the value will be a map
of objects whose keys correspond with the keys in the `for_each` expression,
@ -104,7 +104,7 @@ elements, each one representing one module instance.
### Data Sources
`data.<DATA TYPE>.<NAME>` is an object representing a
[data resource](/opentf/language/data-sources) of the given data
[data resource](/docs/language/data-sources) of the given data
source type and name. If the resource has the `count` argument set, the value
is a list of objects representing its instances. If the resource has the `for_each`
argument set, the value is a map of objects representing its instances.
@ -132,7 +132,7 @@ The following values are available:
directory. We recommend using `path.root` or `path.module` over `path.cwd` where
possible.
- `terraform.workspace` is the name of the currently selected
[workspace](/opentf/language/state/workspaces).
[workspace](/docs/language/state/workspaces).
Use the values in this section carefully, because they include information
about the context in which a configuration is being applied and so may
@ -172,19 +172,19 @@ These local names are described in the documentation for the specific contexts
where they appear. Some of most common local names are:
* `count.index`, in resources that use
[the `count` meta-argument](/opentf/language/meta-arguments/count).
[the `count` meta-argument](/docs/language/meta-arguments/count).
* `each.key` / `each.value`, in resources that use
[the `for_each` meta-argument](/opentf/language/meta-arguments/for_each).
* `self`, in [provisioner](/opentf/language/resources/provisioners/syntax) and
[connection](/opentf/language/resources/provisioners/connection) blocks.
[the `for_each` meta-argument](/docs/language/meta-arguments/for_each).
* `self`, in [provisioner](/docs/language/resources/provisioners/syntax) and
[connection](/docs/language/resources/provisioners/connection) blocks.
-> **Note:** Local names are often referred to as _variables_ or
_temporary variables_ in their documentation. These are not [input
variables](/opentf/language/values/variables); they are just arbitrary names
variables](/docs/language/values/variables); they are just arbitrary names
that temporarily represent a value.
The names in this section relate to top-level configuration blocks only.
If you use [`dynamic` blocks](/opentf/language/expressions/dynamic-blocks) to dynamically generate
If you use [`dynamic` blocks](/docs/language/expressions/dynamic-blocks) to dynamically generate
resource-type-specific _nested_ blocks within `resource` and `data` blocks then
you'll refer to the key and value of each element differently. See the
`dynamic` blocks documentation for details.
@ -233,7 +233,7 @@ for use in references, as follows:
* The `id` attribute exported by this resource type can be read using the
same syntax, giving `aws_instance.example.id`.
* The arguments of the `ebs_block_device` nested blocks can be accessed using
a [splat expression](/opentf/language/expressions/splat). For example, to obtain a list of
a [splat expression](/docs/language/expressions/splat). For example, to obtain a list of
all of the `device_name` values, use
`aws_instance.example.ebs_block_device[*].device_name`.
* The nested blocks in this particular resource type do not have any exported
@ -259,24 +259,24 @@ for use in references, as follows:
as `aws_instance.example.device["foo"].size`.
To obtain a map of values of a particular argument for _labelled_ nested
block types, use a [`for` expression](/opentf/language/expressions/for):
block types, use a [`for` expression](/docs/language/expressions/for):
`{for k, device in aws_instance.example.device : k => device.size}`.
When a resource has the
[`count`](/opentf/language/meta-arguments/count)
[`count`](/docs/language/meta-arguments/count)
argument set, the resource itself becomes a _list_ of instance objects rather than
a single object. In that case, access the attributes of the instances using
either [splat expressions](/opentf/language/expressions/splat) or index syntax:
either [splat expressions](/docs/language/expressions/splat) or index syntax:
* `aws_instance.example[*].id` returns a list of all of the ids of each of the
instances.
* `aws_instance.example[0].id` returns just the id of the first instance.
When a resource has the
[`for_each`](/opentf/language/meta-arguments/for_each)
[`for_each`](/docs/language/meta-arguments/for_each)
argument set, the resource itself becomes a _map_ of instance objects rather than
a single object, and attributes of instances must be specified by key, or can
be accessed using a [`for` expression](/opentf/language/expressions/for).
be accessed using a [`for` expression](/docs/language/expressions/for).
* `aws_instance.example["a"].id` returns the id of the "a"-keyed resource.
* `[for value in aws_instance.example: value.id]` returns a list of all of the ids
@ -294,21 +294,21 @@ placeholder marker `(sensitive value)` instead of the actual value when renderin
a plan involving that attribute.
A provider attribute marked as sensitive behaves similarly to an
[an input variable declared as sensitive](/opentf/language/values/variables#suppressing-values-in-cli-output),
[an input variable declared as sensitive](/docs/language/values/variables#suppressing-values-in-cli-output),
where OpenTF will hide the value in the plan and apply messages and will
also hide any other values you derive from it as sensitive.
However, there are some limitations to that behavior as described in
[Cases where OpenTF may disclose a sensitive variable](/opentf/language/values/variables#cases-where-opentf-may-disclose-a-sensitive-variable).
[Cases where OpenTF may disclose a sensitive variable](/docs/language/values/variables#cases-where-opentf-may-disclose-a-sensitive-variable).
If you use a sensitive value from a resource attribute as part of an
[output value](/opentf/language/values/outputs) then OpenTF will require
[output value](/docs/language/values/outputs) then OpenTF will require
you to also mark the output value itself as sensitive, to confirm that you
intended to export it.
OpenTF will still record sensitive values in the [state](/opentf/language/state),
OpenTF will still record sensitive values in the [state](/docs/language/state),
and so anyone who can access the state data will have access to the sensitive
values in cleartext. For more information, see
[_Sensitive Data in State_](/opentf/language/state/sensitive-data).
[_Sensitive Data in State_](/docs/language/state/sensitive-data).
### Values Not Yet Known

6
website/docs/language/expressions/splat.mdx
View File

@ -43,12 +43,12 @@ The above expression is equivalent to the following `for` expression:
The splat expression patterns shown above apply only to lists, sets, and
tuples. To get a similar result with a map or object value you must use
[`for` expressions](/opentf/language/expressions/for).
[`for` expressions](/docs/language/expressions/for).
Resources that use the `for_each` argument will appear in expressions as a map
of objects, so you can't use splat expressions with those resources.
For more information, see
[Referring to Resource Instances](/opentf/language/meta-arguments/for_each#referring-to-instances).
[Referring to Resource Instances](/docs/language/meta-arguments/for_each#referring-to-instances).
## Single Values as Lists
@ -85,7 +85,7 @@ resource "aws_s3_bucket" "example" {
}
```
The above example uses a [`dynamic` block](/opentf/language/expressions/dynamic-blocks), which
The above example uses a [`dynamic` block](/docs/language/expressions/dynamic-blocks), which
generates zero or more nested blocks based on a collection value. The input
variable `var.website_setting` is defined as a single object that might be null,
so the `dynamic` block's `for_each` expression uses `[*]` to ensure that

4
website/docs/language/expressions/strings.mdx
View File

@ -77,8 +77,8 @@ allowed, but conventionally this identifier is in all-uppercase and begins with
### Generating JSON or YAML
Don't use "heredoc" strings to generate JSON or YAML. Instead, use
[the `jsonencode` function](/opentf/language/functions/jsonencode) or
[the `yamlencode` function](/opentf/language/functions/yamlencode) so that OpenTF
[the `jsonencode` function](/docs/language/functions/jsonencode) or
[the `yamlencode` function](/docs/language/functions/yamlencode) so that OpenTF
can be responsible for guaranteeing valid JSON or YAML syntax.
```hcl

6
website/docs/language/expressions/type-constraints.mdx
View File

@ -25,9 +25,9 @@ function-like constructs called _type constructors._
represent a type; instead, it represents a _kind_ of similar types.
Type constraints look like other kinds of OpenTF
[expressions](/opentf/language/expressions), but are a special syntax. Within the
[expressions](/docs/language/expressions), but are a special syntax. Within the
OpenTF language, they are only valid in the `type` argument of an
[input variable](/opentf/language/values/variables).
[input variable](/docs/language/values/variables).
## Primitive Types
@ -152,7 +152,7 @@ like the following:
The OpenTF language has literal expressions for creating tuple and object
values, which are described in
[Expressions: Literal Expressions](/opentf/language/expressions/types#literal-expressions) as
[Expressions: Literal Expressions](/docs/language/expressions/types#literal-expressions) as
"list/tuple" literals and "map/object" literals, respectively.
OpenTF does _not_ provide any way to directly represent lists, maps, or sets.

6
website/docs/language/expressions/types.mdx
View File

@ -55,7 +55,7 @@ characters, `"like this"`. There is also a "heredoc" syntax for more complex
strings.
String literals are the most complex kind of literal expression in
OpenTF, and have their own page of documentation. See [Strings](/opentf/language/expressions/strings)
OpenTF, and have their own page of documentation. See [Strings](/docs/language/expressions/strings)
for information about escape sequences, the heredoc syntax, interpolation, and
template directives.
@ -99,7 +99,7 @@ The values in a map
can be arbitrary expressions.
The keys in a map must be strings; they can be left unquoted if
they are a valid [identifier](/opentf/language/syntax/configuration#identifiers), but must be quoted
they are a valid [identifier](/docs/language/syntax/configuration#identifiers), but must be quoted
otherwise. You can use a non-literal string expression as a key by wrapping it in
parentheses, like `(var.business_unit_tag_name) = "SRE"`.
@ -128,7 +128,7 @@ offer different ways to restrict the allowed values for input variables and
resource arguments.
For complete details about these types (and an explanation of why the difference
usually doesn't matter), see [Type Constraints](/opentf/language/expressions/type-constraints).
usually doesn't matter), see [Type Constraints](/docs/language/expressions/type-constraints).
## Type Conversion

8
website/docs/language/expressions/version-constraints.mdx
View File

@ -11,9 +11,9 @@ Anywhere that OpenTF lets you specify a range of acceptable versions for
something, it expects a specially formatted string known as a version
constraint. Version constraints are used when configuring:
- [Modules](/opentf/language/modules)
- [Provider requirements](/opentf/language/providers/requirements)
- [The `required_version` setting](/opentf/language/settings#specifying-a-required-opentf-version) in the `opentf` block.
- [Modules](/docs/language/modules)
- [Provider requirements](/docs/language/providers/requirements)
- [The `required_version` setting](/docs/language/settings#specifying-a-required-opentf-version) in the `opentf` block.
## Version Constraint Syntax
@ -24,7 +24,7 @@ other dependency management systems like Bundler and NPM.
version = ">= 1.2.0, < 2.0.0"
```
A version constraint is a [string literal](/opentf/language/expressions/strings)
A version constraint is a [string literal](/docs/language/expressions/strings)
containing one or more conditions, which are separated by commas.
Each condition consists of an operator and a version number.

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

@ -10,9 +10,9 @@ description: >-
An OpenTF configuration may refer to two different kinds of external
dependency that come from outside of its own codebase:
- [Providers](/opentf/language/providers/requirements), which are plugins for OpenTF
- [Providers](/docs/language/providers/requirements), which are plugins for OpenTF
that extend it with support for interacting with various external systems.
- [Modules](/opentf/language/modules), which allow
- [Modules](/docs/language/modules), which allow
splitting out groups of OpenTF configuration constructs (written in the
OpenTF language) into reusable abstractions.
@ -22,7 +22,7 @@ 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](/opentf/language/expressions/version-constraints) within the configuration
[Version constraints](/docs/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 OpenTF remembers
the decisions it made in a _dependency lock file_ so that it can (by default)
@ -47,7 +47,7 @@ to signify that it is a lock file for various items that OpenTF caches in
the `.terraform` subdirectory of your working directory.
OpenTF automatically creates or updates the dependency lock file each time
you run [the `opentf init` command](/opentf/cli/commands/init). You should
you run [the `opentf init` command](/docs/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.
@ -135,7 +135,7 @@ There are two special considerations with the "trust on first use" model:
To avoid this problem you can pre-populate checksums for a variety of
different platforms in your lock file using
[the `opentf providers lock` command](/opentf/cli/commands/providers/lock),
[the `opentf providers lock` command](/docs/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.
@ -153,7 +153,7 @@ 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](/opentf/language/providers/requirements) for any module in your
[provider requirements](/docs/language/providers/requirements) for any module in your
configuration, or if you add an external module that includes a new provider
dependency itself, `opentf init` will respond to that by selecting the
newest version of that provider which meets all of the version constraints
@ -300,7 +300,7 @@ The two hashing schemes currently supported are:
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](/opentf/cli/config/config-file#provider-installation),
[provider installation methods](/docs/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
@ -341,7 +341,7 @@ 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 OpenTF to pre-populate hashes for a chosen set of platforms
using
[the `opentf providers lock` command](/opentf/cli/commands/providers/lock):
[the `opentf providers lock` command](/docs/cli/commands/providers/lock):
```
opentf providers lock \

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

@ -11,7 +11,7 @@ description: >-
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](/opentf/language/syntax/json) that is named with
[a JSON-based variant of the language](/docs/language/syntax/json) that is named with
the `.tf.json` file extension.
Files containing OpenTF code are often called _configuration files._
@ -36,7 +36,7 @@ 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.
An OpenTF module can use [module calls](/opentf/language/modules) to
An OpenTF module can use [module calls](/docs/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

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

@ -12,7 +12,7 @@ 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`](/opentf/language/functions/file) (where
for transient values, such as the argument to [`file`](/docs/language/functions/file) (where
only the contents are then stored) or in `connection` and `provisioner` blocks.
## Examples

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

@ -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`](/opentf/language/functions/textdecodebase64) with the encoding name set to
[`textdecodebase64`](/docs/language/functions/textdecodebase64) with the encoding name set to
`UTF-8`.
## Examples
@ -36,11 +36,11 @@ Hello World
## Related Functions
* [`base64encode`](/opentf/language/functions/base64encode) performs the opposite operation,
* [`base64encode`](/docs/language/functions/base64encode) performs the opposite operation,
encoding the UTF-8 bytes for a string as Base64.
* [`textdecodebase64`](/opentf/language/functions/textdecodebase64) is a more general function that
* [`textdecodebase64`](/docs/language/functions/textdecodebase64) is a more general function that
supports character encodings other than UTF-8.
* [`base64gzip`](/opentf/language/functions/base64gzip) applies gzip compression to a string
* [`base64gzip`](/docs/language/functions/base64gzip) applies gzip compression to a string
and returns the result with Base64 encoding.
* [`filebase64`](/opentf/language/functions/filebase64) reads a file from the local filesystem
* [`filebase64`](/docs/language/functions/filebase64) reads a file from the local filesystem
and returns its raw bytes with Base64 encoding.

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

@ -25,7 +25,7 @@ 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`](/opentf/language/functions/textencodebase64) with the encoding name set to
[`textencodebase64`](/docs/language/functions/textencodebase64) with the encoding name set to
`UTF-8`.
## Examples
@ -37,12 +37,12 @@ SGVsbG8gV29ybGQ=
## Related Functions
* [`base64decode`](/opentf/language/functions/base64decode) performs the opposite operation,
* [`base64decode`](/docs/language/functions/base64decode) performs the opposite operation,
decoding Base64 data and interpreting it as a UTF-8 string.
* [`textencodebase64`](/opentf/language/functions/textencodebase64) is a more general function that
* [`textencodebase64`](/docs/language/functions/textencodebase64) is a more general function that
supports character encodings other than UTF-8.
* [`base64gzip`](/opentf/language/functions/base64gzip) applies gzip compression to a string
* [`base64gzip`](/docs/language/functions/base64gzip) applies gzip compression to a string
and returns the result with Base64 encoding all in one operation.
* [`filebase64`](/opentf/language/functions/filebase64) reads a file from the local filesystem
* [`filebase64`](/docs/language/functions/filebase64) reads a file from the local filesystem
and returns its raw bytes with Base64 encoding, without creating an
intermediate Unicode string.

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

@ -25,7 +25,7 @@ an S3 website.
## Related Functions
* [`base64encode`](/opentf/language/functions/base64encode) applies Base64 encoding _without_
* [`base64encode`](/docs/language/functions/base64encode) applies Base64 encoding _without_
gzip compression.
* [`filebase64`](/opentf/language/functions/filebase64) reads a file from the local filesystem
* [`filebase64`](/docs/language/functions/filebase64) reads a file from the local filesystem
and returns its raw bytes with Base64 encoding.

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

@ -25,7 +25,7 @@ uU0nuZNNPgilLlLX2n2r+sSE7+N6U4DukIj3rOLvzek=
## Related Functions
* [`filebase64sha256`](/opentf/language/functions/filebase64sha256) calculates the same hash from
* [`filebase64sha256`](/docs/language/functions/filebase64sha256) calculates the same hash from
the contents of a file rather than from a string value.
* [`sha256`](/opentf/language/functions/sha256) calculates the same hash but returns the result
* [`sha256`](/docs/language/functions/sha256) calculates the same hash but returns the result
in a more-verbose hexadecimal encoding.

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

@ -25,7 +25,7 @@ MJ7MSJwS1utMxA9QyQLytNDtd+5RGnx6m808qG1M2G+YndNbxf9JlnDaNCVbRbDP2DDoH2Bdz33FVC6T
## Related Functions
* [`filebase64sha512`](/opentf/language/functions/filebase64sha512) calculates the same hash from
* [`filebase64sha512`](/docs/language/functions/filebase64sha512) calculates the same hash from
the contents of a file rather than from a string value.
* [`sha512`](/opentf/language/functions/sha512) calculates the same hash but returns the result
* [`sha512`](/docs/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`](/opentf/language/functions/file) (where
for transient values, such as the argument to [`file`](/docs/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`](/opentf/language/functions/dirname) returns all of the segments of a filesystem path
* [`dirname`](/docs/language/functions/dirname) returns all of the segments of a filesystem path
_except_ the last, discarding the portion that would be returned by
`basename`.

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`](/opentf/language/functions/try) instead, because it allows for more concise definition of
[`try`](/docs/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](/opentf/language/values/variables#custom-validation-rules).
[custom variable validation rules](/docs/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`](/opentf/language/functions/try).
prefer to use [`try`](/docs/language/functions/try).
## Examples
@ -70,5 +70,5 @@ A local value with the name "nonexist" has not been declared.
## Related Functions
* [`try`](/opentf/language/functions/try), which tries evaluating a sequence of expressions and
* [`try`](/docs/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`](/opentf/language/functions/floor), which rounds to the nearest whole number _less than_
* [`floor`](/docs/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`](/opentf/language/functions/trimspace), which removes all types of whitespace from
* [`trimspace`](/docs/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`](/opentf/language/functions/cidrsubnet).
[`cidrsubnet`](/docs/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`](/opentf/language/functions/cidrsubnet) calculates a subnet address under a given
* [`cidrsubnet`](/docs/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`](/opentf/language/functions/cidrsubnets), `cidrsubnet`
Unlike the related function [`cidrsubnets`](/docs/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`](/opentf/language/functions/cidrhost) allows calculating single host IP addresses,
While [`cidrhost`](/docs/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`](/opentf/language/functions/cidrhost) function to calculate those host addresses by
[`cidrhost`](/docs/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`](/opentf/language/functions/cidrhost) calculates the IP address for a single host
* [`cidrhost`](/docs/language/functions/cidrhost) calculates the IP address for a single host
within a given network address prefix.
* [`cidrnetmask`](/opentf/language/functions/cidrnetmask) converts an IPv4 network prefix in CIDR
* [`cidrnetmask`](/docs/language/functions/cidrnetmask) converts an IPv4 network prefix in CIDR
notation into netmask notation.
* [`cidrsubnets`](/opentf/language/functions/cidrsubnets) can allocate multiple consecutive
* [`cidrsubnets`](/docs/language/functions/cidrsubnets) can allocate multiple consecutive
addresses under a prefix at once, numbering them automatically.

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