website/docs/language/meta-arguments (#229)

Signed-off-by: Marcin Białoń <mbialon@spacelift.io>
This commit is contained in:
Marcin Białoń 2023-08-29 16:36:54 +02:00 committed by GitHub
parent 51bb449ac3
commit 0a37fade1f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 70 additions and 86 deletions

View File

@ -7,28 +7,23 @@ description: >-
# The `count` Meta-Argument # The `count` Meta-Argument
-> **Version note:** Module support for `count` was added in Terraform 0.13, and
previous versions can only use it with resources.
-> **Note:** A given resource or module block cannot use both `count` and `for_each`. -> **Note:** A given resource or module block cannot use both `count` and `for_each`.
> **Hands-on:** Try the [Manage Similar Resources With Count](/terraform/tutorials/0-13/count?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial. By default, a [resource block](/opentf/language/resources/syntax) configures one real
By default, a [resource block](/terraform/language/resources/syntax) configures one real
infrastructure object. (Similarly, a infrastructure object. (Similarly, a
[module block](/terraform/language/modules/syntax) includes a [module block](/opentf/language/modules/syntax) includes a
child module's contents into the configuration one time.) child module's contents into the configuration one time.)
However, sometimes you want to manage several similar objects (like a fixed However, sometimes you want to manage several similar objects (like a fixed
pool of compute instances) without writing a separate block for each one. pool of compute instances) without writing a separate block for each one.
Terraform has two ways to do this: OpenTF has two ways to do this:
`count` and [`for_each`](/terraform/language/meta-arguments/for_each). `count` and [`for_each`](/opentf/language/meta-arguments/for_each).
If a resource or module block includes a `count` argument whose value is a whole number, If a resource or module block includes a `count` argument whose value is a whole number,
Terraform will create that many instances. OpenTF will create that many instances.
## Basic Syntax ## Basic Syntax
`count` is a meta-argument defined by the Terraform language. It can be used `count` is a meta-argument defined by the OpenTF language. It can be used
with modules and with every resource type. with modules and with every resource type.
The `count` meta-argument accepts a whole number, and creates that many The `count` meta-argument accepts a whole number, and creates that many
@ -60,16 +55,16 @@ This object has one attribute:
## Using Expressions in `count` ## Using Expressions in `count`
The `count` meta-argument accepts numeric [expressions](/terraform/language/expressions). The `count` meta-argument accepts numeric [expressions](/opentf/language/expressions).
However, unlike most arguments, the `count` value must be known However, unlike most arguments, the `count` value must be known
_before_ Terraform performs any remote resource actions. This means `count` _before_ OpenTF performs any remote resource actions. This means `count`
can't refer to any resource attributes that aren't known until after a can't refer to any resource attributes that aren't known until after a
configuration is applied (such as a unique ID generated by the remote API when configuration is applied (such as a unique ID generated by the remote API when
an object is created). an object is created).
## Referring to Instances ## Referring to Instances
When `count` is set, Terraform distinguishes between the block itself When `count` is set, OpenTF distinguishes between the block itself
and the multiple _resource or module instances_ associated with it. Instances are and the multiple _resource or module instances_ associated with it. Instances are
identified by an index number, starting with `0`. identified by an index number, starting with `0`.

View File

@ -7,22 +7,19 @@ description: >-
# The `depends_on` Meta-Argument # The `depends_on` Meta-Argument
Use the `depends_on` meta-argument to handle hidden resource or module dependencies that Terraform cannot automatically infer. You only need to explicitly specify a dependency when a resource or module relies on another resource's behavior but does not access any of that resource's data in its arguments. Use the `depends_on` meta-argument to handle hidden resource or module dependencies that OpenTF cannot automatically infer. You only need to explicitly specify a dependency when a resource or module relies on another resource's behavior but does not access any of that resource's data in its arguments.
-> **Note:** Module support for `depends_on` was added in Terraform version 0.13, and prior versions can only use it with resources.
## Processing and Planning Consequences ## Processing and Planning Consequences
The `depends_on` meta-argument instructs Terraform to complete all actions on the dependency object (including Read actions) before performing actions on the object declaring the dependency. When the dependency object is an entire module, `depends_on` affects the order in which Terraform processes all of the resources and data sources associated with that module. Refer to [Resource Dependencies](/terraform/language/resources/behavior#resource-dependencies) and [Data Resource Dependencies](/terraform/language/data-sources#data-resource-dependencies) for more details. The `depends_on` meta-argument instructs OpenTF to complete all actions on the dependency object (including Read actions) before performing actions on the object declaring the dependency. When the dependency object is an entire module, `depends_on` affects the order in which OpenTF processes all of the resources and data sources associated with that module. Refer to [Resource Dependencies](/opentf/language/resources/behavior#resource-dependencies) and [Data Resource Dependencies](/opentf/language/data-sources#data-resource-dependencies) for more details.
You should use `depends_on` as a last resort because it can cause Terraform to create more conservative plans that replace more resources than necessary. For example, Terraform may treat more values as unknown “(known after apply)” because it is uncertain what changes will occur on the upstream object. This is especially likely when you use `depends_on` for modules. You should use `depends_on` as a last resort because it can cause OpenTF to create more conservative plans that replace more resources than necessary. For example, OpenTF may treat more values as unknown “(known after apply)” because it is uncertain what changes will occur on the upstream object. This is especially likely when you use `depends_on` for modules.
Instead of `depends_on`, we recommend using [expression references](/terraform/language/expressions/references) to imply dependencies when possible. Expression references let Terraform understand which value the reference derives from and avoid planning changes if that particular value hasnt changed, even if other parts of the upstream object have planned changes. Instead of `depends_on`, we recommend using [expression references](/opentf/language/expressions/references) to imply dependencies when possible. Expression references let OpenTF understand which value the reference derives from and avoid planning changes if that particular value hasnt changed, even if other parts of the upstream object have planned changes.
## Usage ## Usage
You can use the `depends_on` meta-argument in `module` blocks and in all `resource` blocks, regardless of resource type. It requires a list of references to other resources or child modules in the same calling module. This list cannot include arbitrary expressions because the `depends_on` value must be known before Terraform knows resource relationships and thus before it can safely evaluate expressions. You can use the `depends_on` meta-argument in `module` blocks and in all `resource` blocks, regardless of resource type. It requires a list of references to other resources or child modules in the same calling module. This list cannot include arbitrary expressions because the `depends_on` value must be known before OpenTF knows resource relationships and thus before it can safely evaluate expressions.
We recommend always including a comment that explains why using `depends_on` is necessary. The following example uses `depends_on` to handle a "hidden" dependency on the `aws_iam_instance_profile.example`. We recommend always including a comment that explains why using `depends_on` is necessary. The following example uses `depends_on` to handle a "hidden" dependency on the `aws_iam_instance_profile.example`.
@ -36,7 +33,7 @@ resource "aws_iam_role" "example" {
} }
resource "aws_iam_instance_profile" "example" { resource "aws_iam_instance_profile" "example" {
# Because this expression refers to the role, Terraform can infer # Because this expression refers to the role, OpenTF can infer
# automatically that the role must be created first. # automatically that the role must be created first.
role = aws_iam_role.example.name role = aws_iam_role.example.name
} }
@ -58,13 +55,13 @@ resource "aws_instance" "example" {
ami = "ami-a1b2c3d4" ami = "ami-a1b2c3d4"
instance_type = "t2.micro" instance_type = "t2.micro"
# Terraform can infer from this that the instance profile must # OpenTF can infer from this that the instance profile must
# be created before the EC2 instance. # be created before the EC2 instance.
iam_instance_profile = aws_iam_instance_profile.example iam_instance_profile = aws_iam_instance_profile.example
# However, if software running in this EC2 instance needs access # However, if software running in this EC2 instance needs access
# to the S3 API in order to boot properly, there is also a "hidden" # to the S3 API in order to boot properly, there is also a "hidden"
# dependency on the aws_iam_role_policy that Terraform cannot # dependency on the aws_iam_role_policy that OpenTF cannot
# automatically infer, so it must be declared explicitly: # automatically infer, so it must be declared explicitly:
depends_on = [ depends_on = [
aws_iam_role_policy.example aws_iam_role_policy.example

View File

@ -7,30 +7,24 @@ description: >-
# The `for_each` Meta-Argument # The `for_each` Meta-Argument
By default, a [resource block](/terraform/language/resources/syntax) configures one real By default, a [resource block](/opentf/language/resources/syntax) configures one real
infrastructure object (and similarly, a infrastructure object (and similarly, a
[module block](/terraform/language/modules/syntax) includes a [module block](/opentf/language/modules/syntax) includes a
child module's contents into the configuration one time). child module's contents into the configuration one time).
However, sometimes you want to manage several similar objects (like a fixed However, sometimes you want to manage several similar objects (like a fixed
pool of compute instances) without writing a separate block for each one. pool of compute instances) without writing a separate block for each one.
Terraform has two ways to do this: OpenTF has two ways to do this:
[`count`](/terraform/language/meta-arguments/count) and `for_each`. [`count`](/opentf/language/meta-arguments/count) and `for_each`.
> **Hands-on:** Try the [Manage Similar Resources With For Each](/terraform/tutorials/configuration-language/for-each) tutorial.
If a resource or module block includes a `for_each` argument whose value is a map or If a resource or module block includes a `for_each` argument whose value is a map or
a set of strings, Terraform creates one instance for each member of a set of strings, OpenTF creates one instance for each member of
that map or set. that map or set.
-> **Version note:** `for_each` was added in Terraform 0.12.6. Module support
for `for_each` was added in Terraform 0.13; previous versions can only use
it with resources.
-> **Note:** A given resource or module block cannot use both `count` and `for_each`. -> **Note:** A given resource or module block cannot use both `count` and `for_each`.
## Basic Syntax ## Basic Syntax
`for_each` is a meta-argument defined by the Terraform language. It can be used `for_each` is a meta-argument defined by the OpenTF language. It can be used
with modules and with every resource type. with modules and with every resource type.
The `for_each` meta-argument accepts a map or a set of strings, and creates an The `for_each` meta-argument accepts a map or a set of strings, and creates an
@ -109,16 +103,16 @@ that cannot be determined before apply, and a `-target` may be needed.
including `uuid`, `bcrypt`, or `timestamp`, as their evaluation is deferred during the including `uuid`, `bcrypt`, or `timestamp`, as their evaluation is deferred during the
main evaluation step. main evaluation step.
Sensitive values, such as [sensitive input variables](/terraform/language/values/variables#suppressing-values-in-cli-output), Sensitive values, such as [sensitive input variables](/opentf/language/values/variables#suppressing-values-in-cli-output),
[sensitive outputs](/terraform/language/values/outputs#sensitive-suppressing-values-in-cli-output), [sensitive outputs](/opentf/language/values/outputs#sensitive-suppressing-values-in-cli-output),
or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), or [sensitive resource attributes](/opentf/language/expressions/references#sensitive-resource-attributes),
cannot be used as arguments to `for_each`. The value used in `for_each` is used cannot be used as arguments to `for_each`. The value used in `for_each` is used
to identify the resource instance and will always be disclosed in UI output, to identify the resource instance and will always be disclosed in UI output,
which is why sensitive values are not allowed. which is why sensitive values are not allowed.
Attempts to use sensitive values as `for_each` arguments will result in an error. Attempts to use sensitive values as `for_each` arguments will result in an error.
If you transform a value containing sensitive data into an argument to be used in `for_each`, be aware that If you transform a value containing sensitive data into an argument to be used in `for_each`, be aware that
[most functions in Terraform will return a sensitive result if given an argument with any sensitive content](/terraform/language/expressions/function-calls#using-sensitive-data-as-function-arguments). [most functions in OpenTF will return a sensitive result if given an argument with any sensitive content](/opentf/language/expressions/function-calls#using-sensitive-data-as-function-arguments).
In many cases, you can achieve similar results to a function used for this purpose by In many cases, you can achieve similar results to a function used for this purpose by
using a `for` expression. For example, if you would like to call `keys(local.map)`, where using a `for` expression. For example, if you would like to call `keys(local.map)`, where
`local.map` is an object with sensitive values (but non-sensitive keys), you can create a `local.map` is an object with sensitive values (but non-sensitive keys), you can create a
@ -126,28 +120,28 @@ value to pass to `for_each` with `toset([for k,v in local.map : k])`.
## Using Expressions in `for_each` ## Using Expressions in `for_each`
The `for_each` meta-argument accepts map or set [expressions](/terraform/language/expressions). The `for_each` meta-argument accepts map or set [expressions](/opentf/language/expressions).
However, unlike most arguments, the `for_each` value must be known However, unlike most arguments, the `for_each` value must be known
_before_ Terraform performs any remote resource actions. This means `for_each` _before_ OpenTF performs any remote resource actions. This means `for_each`
can't refer to any resource attributes that aren't known until after a can't refer to any resource attributes that aren't known until after a
configuration is applied (such as a unique ID generated by the remote API when configuration is applied (such as a unique ID generated by the remote API when
an object is created). an object is created).
The `for_each` value must be a map or set with one element per desired resource The `for_each` value must be a map or set with one element per desired resource
instance. To use a sequence as the `for_each` value, you must use an expression instance. To use a sequence as the `for_each` value, you must use an expression
that explicitly returns a set value, like the [toset](/terraform/language/functions/toset) that explicitly returns a set value, like the [toset](/opentf/language/functions/toset)
function. To prevent unwanted surprises during conversion, the `for_each` argument function. To prevent unwanted surprises during conversion, the `for_each` argument
does not implicitly convert lists or tuples to sets. does not implicitly convert lists or tuples to sets.
If you need to declare resource instances based on a nested If you need to declare resource instances based on a nested
data structure or combinations of elements from multiple data structures you data structure or combinations of elements from multiple data structures you
can use Terraform expressions and functions to derive a suitable value. can use OpenTF expressions and functions to derive a suitable value.
For example: For example:
- Transform a multi-level nested structure into a flat list by - Transform a multi-level nested structure into a flat list by
[using nested `for` expressions with the `flatten` function](/terraform/language/functions/flatten#flattening-nested-structures-for-for_each). [using nested `for` expressions with the `flatten` function](/opentf/language/functions/flatten#flattening-nested-structures-for-for_each).
- Produce an exhaustive list of combinations of elements from two or more - Produce an exhaustive list of combinations of elements from two or more
collections by collections by
[using the `setproduct` function inside a `for` expression](/terraform/language/functions/setproduct#finding-combinations-for-for_each). [using the `setproduct` function inside a `for` expression](/opentf/language/functions/setproduct#finding-combinations-for-for_each).
### Chaining `for_each` Between Resources ### Chaining `for_each` Between Resources
@ -198,13 +192,13 @@ output "vpc_ids" {
This chaining pattern explicitly and concisely declares the relationship This chaining pattern explicitly and concisely declares the relationship
between the internet gateway instances and the VPC instances, which tells between the internet gateway instances and the VPC instances, which tells
Terraform to expect the instance keys for both to always change together, OpenTF to expect the instance keys for both to always change together,
and typically also makes the configuration easier to understand for human and typically also makes the configuration easier to understand for human
maintainers. maintainers.
## Referring to Instances ## Referring to Instances
When `for_each` is set, Terraform distinguishes between the block itself When `for_each` is set, OpenTF distinguishes between the block itself
and the multiple _resource or module instances_ associated with it. Instances are and the multiple _resource or module instances_ associated with it. Instances are
identified by a map key (or set member) from the value provided to `for_each`. identified by a map key (or set member) from the value provided to `for_each`.
@ -226,8 +220,8 @@ as a whole.
## Using Sets ## Using Sets
The Terraform language doesn't have a literal syntax for The OpenTF language doesn't have a literal syntax for
[set values](/terraform/language/expressions/type-constraints#collection-types), but you can use the `toset` [set values](/opentf/language/expressions/type-constraints#collection-types), but you can use the `toset`
function to explicitly convert a list of strings to a set: function to explicitly convert a list of strings to a set:
```hcl ```hcl
@ -256,7 +250,7 @@ removes any duplicate elements. `toset(["b", "a", "b"])` will produce a set
containing only `"a"` and `"b"` in no particular order; the second `"b"` is containing only `"a"` and `"b"` in no particular order; the second `"b"` is
discarded. discarded.
If you are writing a module with an [input variable](/terraform/language/values/variables) that If you are writing a module with an [input variable](/opentf/language/values/variables) that
will be used as a set of strings for `for_each`, you can set its type to will be used as a set of strings for `for_each`, you can set its type to
`set(string)` to avoid the need for an explicit type conversion: `set(string)` to avoid the need for an explicit type conversion:

View File

@ -7,9 +7,7 @@ description: >-
# The `lifecycle` Meta-Argument # The `lifecycle` Meta-Argument
> **Hands-on:** Try the [Lifecycle Management](/terraform/tutorials/state/resource-lifecycle?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial. The [Resource Behavior](/opentf/language/resources/behavior) page describes the general lifecycle for resources. Some details of
The [Resource Behavior](/terraform/language/resources/behavior) page describes the general lifecycle for resources. Some details of
that behavior can be customized using the special nested `lifecycle` block that behavior can be customized using the special nested `lifecycle` block
within a resource block body: within a resource block body:
@ -32,9 +30,9 @@ for all `resource` blocks regardless of type.
The arguments available within a `lifecycle` block are `create_before_destroy`, The arguments available within a `lifecycle` block are `create_before_destroy`,
`prevent_destroy`, `ignore_changes`, and `replace_triggered_by`. `prevent_destroy`, `ignore_changes`, and `replace_triggered_by`.
* `create_before_destroy` (bool) - By default, when Terraform must change * `create_before_destroy` (bool) - By default, when OpenTF must change
a resource argument that cannot be updated in-place due to a resource argument that cannot be updated in-place due to
remote API limitations, Terraform will instead destroy the existing object remote API limitations, OpenTF will instead destroy the existing object
and then create a new replacement object with the new configured arguments. and then create a new replacement object with the new configured arguments.
The `create_before_destroy` meta-argument changes this behavior so that The `create_before_destroy` meta-argument changes this behavior so that
@ -45,12 +43,12 @@ The arguments available within a `lifecycle` block are `create_before_destroy`,
name requirements or other constraints that must be accommodated for name requirements or other constraints that must be accommodated for
both a new and an old object to exist concurrently. Some resource types both a new and an old object to exist concurrently. Some resource types
offer special options to append a random suffix onto each object name to offer special options to append a random suffix onto each object name to
avoid collisions, for example. Terraform CLI cannot automatically activate avoid collisions, for example. OpenTF CLI cannot automatically activate
such features, so you must understand the constraints for each resource such features, so you must understand the constraints for each resource
type before using `create_before_destroy` with it. type before using `create_before_destroy` with it.
Note that Terraform propagates and applies the `create_before_destroy` meta-attribute Note that OpenTF propagates and applies the `create_before_destroy` meta-attribute
behaviour to all resource dependencies. For example, if `create_before_destroy` is enabled on resource A but not on resource B, but resource A is dependent on resource B, then Terraform enables `create_before_destroy` for resource B behaviour to all resource dependencies. For example, if `create_before_destroy` is enabled on resource A but not on resource B, but resource A is dependent on resource B, then OpenTF enables `create_before_destroy` for resource B
implicitly by default and stores it to the state file. You cannot override `create_before_destroy` implicitly by default and stores it to the state file. You cannot override `create_before_destroy`
to `false` on resource B because that would imply dependency cycles in the graph. to `false` on resource B because that would imply dependency cycles in the graph.
@ -58,34 +56,34 @@ The arguments available within a `lifecycle` block are `create_before_destroy`,
is set to `true`. This [GitHub issue](https://github.com/hashicorp/terraform/issues/13549) contains more details. is set to `true`. This [GitHub issue](https://github.com/hashicorp/terraform/issues/13549) contains more details.
* `prevent_destroy` (bool) - This meta-argument, when set to `true`, will * `prevent_destroy` (bool) - This meta-argument, when set to `true`, will
cause Terraform to reject with an error any plan that would destroy the cause OpenTF to reject with an error any plan that would destroy the
infrastructure object associated with the resource, as long as the argument infrastructure object associated with the resource, as long as the argument
remains present in the configuration. remains present in the configuration.
This can be used as a measure of safety against the accidental replacement This can be used as a measure of safety against the accidental replacement
of objects that may be costly to reproduce, such as database instances. of objects that may be costly to reproduce, such as database instances.
However, it will make certain configuration changes impossible to apply, However, it will make certain configuration changes impossible to apply,
and will prevent the use of the `terraform destroy` command once such and will prevent the use of the `opentf destroy` command once such
objects are created, and so this option should be used sparingly. objects are created, and so this option should be used sparingly.
Since this argument must be present in configuration for the protection to Since this argument must be present in configuration for the protection to
apply, note that this setting does not prevent the remote object from apply, note that this setting does not prevent the remote object from
being destroyed if the `resource` block were removed from configuration being destroyed if the `resource` block were removed from configuration
entirely: in that case, the `prevent_destroy` setting is removed along entirely: in that case, the `prevent_destroy` setting is removed along
with it, and so Terraform will allow the destroy operation to succeed. with it, and so OpenTF will allow the destroy operation to succeed.
* `ignore_changes` (list of attribute names) - By default, Terraform detects * `ignore_changes` (list of attribute names) - By default, OpenTF detects
any difference in the current settings of a real infrastructure object any difference in the current settings of a real infrastructure object
and plans to update the remote object to match configuration. and plans to update the remote object to match configuration.
The `ignore_changes` feature is intended to be used when a resource is The `ignore_changes` feature is intended to be used when a resource is
created with references to data that may change in the future, but should created with references to data that may change in the future, but should
not affect said resource after its creation. In some rare cases, settings not affect said resource after its creation. In some rare cases, settings
of a remote object are modified by processes outside of Terraform, which of a remote object are modified by processes outside of OpenTF, which
Terraform would then attempt to "fix" on the next run. In order to make OpenTF would then attempt to "fix" on the next run. In order to make
Terraform share management responsibilities of a single object with a OpenTF share management responsibilities of a single object with a
separate process, the `ignore_changes` meta-argument specifies resource separate process, the `ignore_changes` meta-argument specifies resource
attributes that Terraform should ignore when planning updates to the attributes that OpenTF should ignore when planning updates to the
associated remote object. associated remote object.
The arguments corresponding to the given attribute names are considered The arguments corresponding to the given attribute names are considered
@ -109,14 +107,14 @@ The arguments available within a `lifecycle` block are `create_before_destroy`,
``` ```
Instead of a list, the special keyword `all` may be used to instruct Instead of a list, the special keyword `all` may be used to instruct
Terraform to ignore _all_ attributes, which means that Terraform can OpenTF to ignore _all_ attributes, which means that OpenTF can
create and destroy the remote object but will never propose updates to it. create and destroy the remote object but will never propose updates to it.
Only attributes defined by the resource type can be ignored. Only attributes defined by the resource type can be ignored.
`ignore_changes` cannot be applied to itself or to any other meta-arguments. `ignore_changes` cannot be applied to itself or to any other meta-arguments.
* `replace_triggered_by` (list of resource or attribute references) - * `replace_triggered_by` (list of resource or attribute references) -
_Added in Terraform 1.2._ Replaces the resource when any of the referenced Replaces the resource when any of the referenced
items change. Supply a list of expressions referencing managed resources, items change. Supply a list of expressions referencing managed resources,
instances, or instance attributes. When used in a resource that uses `count` instances, or instance attributes. When used in a resource that uses `count`
or `for_each`, you can use `count.index` or `each.key` in the expression to or `for_each`, you can use `count.index` or `each.key` in the expression to
@ -149,7 +147,7 @@ The arguments available within a `lifecycle` block are `create_before_destroy`,
} }
``` ```
`replace_triggered_by` allows only resource addresses because the decision is based on the planned actions for all of the given resources. Plain values such as local values or input variables do not have planned actions of their own, but you can treat them with a resource-like lifecycle by using them with [the `terraform_data` resource type](/terraform/language/resources/tf-data). `replace_triggered_by` allows only resource addresses because the decision is based on the planned actions for all of the given resources. Plain values such as local values or input variables do not have planned actions of their own, but you can treat them with a resource-like lifecycle by using them with [the `terraform_data` resource type](/opentf/language/resources/tf-data).
## Custom Condition Checks ## Custom Condition Checks
@ -173,10 +171,10 @@ resource "aws_instance" "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. 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 Conditions](/terraform/language/expressions/custom-conditions#preconditions-and-postconditions) for more details. Refer to [Custom Conditions](/opentf/language/expressions/custom-conditions#preconditions-and-postconditions) for more details.
## Literal Values Only ## Literal Values Only
The `lifecycle` settings all affect how Terraform constructs and traverses The `lifecycle` settings all affect how OpenTF constructs and traverses
the dependency graph. As a result, only literal values can be used because the dependency graph. As a result, only literal values can be used because
the processing happens too early for arbitrary expression evaluation. the processing happens too early for arbitrary expression evaluation.

View File

@ -7,9 +7,9 @@ description: >-
# The Module `providers` Meta-Argument # The Module `providers` Meta-Argument
In a [module call](/terraform/language/modules/syntax) block, the In a [module call](/opentf/language/modules/syntax) block, the
optional `providers` meta-argument specifies which optional `providers` meta-argument specifies which
[provider configurations](/terraform/language/providers/configuration) from the parent [provider configurations](/opentf/language/providers/configuration) from the parent
module will be available inside the child module. module will be available inside the child module.
```hcl ```hcl
@ -38,7 +38,7 @@ module "example" {
## Default Behavior: Inherit Default Providers ## Default Behavior: Inherit Default Providers
If the child module does not declare any [configuration aliases](/terraform/language/modules/develop/providers#provider-aliases-within-modules), If the child module does not declare any [configuration aliases](/opentf/language/modules/develop/providers#provider-aliases-within-modules),
the `providers` argument is optional. If you omit it, a child module inherits the `providers` argument is optional. If you omit it, a child module inherits
all of the _default_ provider configurations from its parent module. (Default all of the _default_ provider configurations from its parent module. (Default
provider configurations are ones that don't use the `alias` argument.) provider configurations are ones that don't use the `alias` argument.)
@ -58,7 +58,7 @@ For default configurations, this is the local name of the provider; for
alternate configurations, this is a `<PROVIDER>.<ALIAS>` reference. alternate configurations, this is a `<PROVIDER>.<ALIAS>` reference.
Within a child module, resources are assigned to provider configurations as Within a child module, resources are assigned to provider configurations as
normal — either Terraform chooses a default based on the name of the resource normal — either OpenTF chooses a default based on the name of the resource
type, or the resource specifies an alternate configuration with the `provider` type, or the resource specifies an alternate configuration with the `provider`
argument. If the module receives a `providers` map when it's called, the argument. If the module receives a `providers` map when it's called, the
provider configuration names used within the module are effectively remapped to provider configuration names used within the module are effectively remapped to
@ -76,7 +76,7 @@ There are two main reasons to use the `providers` argument:
Most re-usable modules only use default provider configurations, which they can Most re-usable modules only use default provider configurations, which they can
automatically inherit from their caller when `providers` is omitted. automatically inherit from their caller when `providers` is omitted.
However, in Terraform configurations that use multiple configurations of the However, in OpenTF configurations that use multiple configurations of the
same provider, you might want some child modules to use the default provider same provider, you might want some child modules to use the default provider
configuration and other ones to use an alternate. (This usually happens when configuration and other ones to use an alternate. (This usually happens when
using one configuration to manage resources in multiple different regions of the using one configuration to manage resources in multiple different regions of the
@ -123,4 +123,4 @@ names it needs.
For more details and guidance about working with providers inside a re-usable For more details and guidance about working with providers inside a re-usable
child module, see child module, see
[Module Development: Providers Within Modules](/terraform/language/modules/develop/providers). [Module Development: Providers Within Modules](/opentf/language/modules/develop/providers).

View File

@ -1,23 +1,23 @@
--- ---
page_title: The Resource provider Meta-Argument - Configuration Language page_title: The Resource provider Meta-Argument - Configuration Language
description: >- description: >-
The provider meta-argument specifies the provider configuration Terraform The provider meta-argument specifies the provider configuration OpenTF
should use for a resource, overriding Terraform's default behavior. should use for a resource, overriding OpenTF's default behavior.
--- ---
# The Resource `provider` Meta-Argument # The Resource `provider` Meta-Argument
The `provider` meta-argument specifies which provider configuration to use for a resource, The `provider` meta-argument specifies which provider configuration to use for a resource,
overriding Terraform's default behavior of selecting one based on the resource overriding OpenTF's default behavior of selecting one based on the resource
type name. Its value should be an unquoted `<PROVIDER>.<ALIAS>` reference. type name. Its value should be an unquoted `<PROVIDER>.<ALIAS>` reference.
As described in [Provider Configuration](/terraform/language/providers/configuration), you can optionally As described in [Provider Configuration](/opentf/language/providers/configuration), you can optionally
create multiple configurations for a single provider (usually to manage create multiple configurations for a single provider (usually to manage
resources in different regions of multi-region services). Each provider can have resources in different regions of multi-region services). Each provider can have
one default configuration, and any number of alternate configurations that one default configuration, and any number of alternate configurations that
include an extra name segment (or "alias"). include an extra name segment (or "alias").
By default, Terraform interprets the initial word in the resource type name By default, OpenTF interprets the initial word in the resource type name
(separated by underscores) as the local name of a provider, and uses that (separated by underscores) as the local name of a provider, and uses that
provider's default configuration. For example, the resource type provider's default configuration. For example, the resource type
`google_compute_instance` is associated automatically with the default `google_compute_instance` is associated automatically with the default
@ -53,7 +53,7 @@ ensure that the provider is fully configured before any resource actions
are taken. are taken.
The `provider` meta-argument expects The `provider` meta-argument expects
[a `<PROVIDER>.<ALIAS>` reference](/terraform/language/providers/configuration#referring-to-alternate-provider-configurations), [a `<PROVIDER>.<ALIAS>` reference](/opentf/language/providers/configuration#referring-to-alternate-provider-configurations),
which does not need to be quoted. Arbitrary expressions are not permitted for which does not need to be quoted. Arbitrary expressions are not permitted for
`provider` because it must be resolved while Terraform is constructing the `provider` because it must be resolved while OpenTF is constructing the
dependency graph, before it is safe to evaluate expressions. dependency graph, before it is safe to evaluate expressions.