terraform/internal/configs/testdata/escaping-blocks/resource/resource-escaping-block.tf

44 lines
1.2 KiB
Terraform
Raw Permalink Normal View History

configs: Meta-argument escaping blocks Several top-level block types in the Terraform language have a body where two different schemas are overlayed on top of one another: Terraform first looks for "meta-arguments" that are built into the language, and then evaluates all of the remaining arguments against some externally-defined schema whose content is not fully controlled by Terraform. So far we've been cautiously adding new meta-arguments in these namespaces after research shows us that there are relatively few existing providers or modules that would have functionality masked by those additions, but that isn't really a viable path forward as we prepare to make stronger compatibility promises. In an earlier commit we've introduced the foundational parts of a new language versioning mechanism called "editions" which should allow us to make per-module-opt-in breaking changes in the future, but these shared namespaces remain a liability because it would be annoying if adopting a new edition made it impossible to use a feature of a third-party provider or module that was already using a name that has now become reserved in the new edition. This commit introduces a new syntax intended to be a rarely-used escape hatch for that situation. When we're designing new editions we will do our best to choose names that don't conflict with commonly-used providers and modules, but there are many providers and modules that we cannot see and so there is a risk that any name we might choose could collide with at least one existing provider or module. The automatic migration tool to upgrade an existing module to a new edition should therefore detect that situation and make use of this escaping block syntax in order to retain the existing functionality until all the called providers or modules are updated to no longer use conflicting names. Although we can't put in technical constraints on using this feature for other purposes (because we don't know yet what future editions will add), this mechanism is intentionally not documented for now because it serves no immediate purpose. In effect, this change is just squatting on the syntax of a special block type named "_" so that later editions can make use of it without it _also_ conflicting, creating a confusing nested escaping situation. However, the first time a new edition actually makes use of this syntax we should then document alongside the meta-arguments so folks can understand the meaning of escaping blocks produced by edition upgrade tools.
2021-05-15 01:09:51 +02:00
resource "foo" "bar" {
count = 2
normal = "yes"
normal_block {}
_ {
# This "escaping block" is an escape hatch for when a resource
# type declares argument names that collide with meta-argument
# names. The examples below are not really realistic because they
# are long-standing names that predate the need for escaping,
# but we're using them as a proxy for new meta-arguments we might
# add in future language editions which might collide with
# names defined in pre-existing providers.
# note that count is set both as a meta-argument above _and_ as
# an resource-type-specific argument here, which is valid and
# should result in both being populated.
count = "not actually count"
# for_each is only set in here, not as a meta-argument
for_each = "not actually for_each"
lifecycle {
# This is a literal lifecycle block, not a meta-argument block
}
_ {
# It would be pretty weird for a resource type to define its own
# "_" block type, but that's valid to escape in here too.
}
}
provisioner "boop" {
when = destroy
_ {
when = "hell freezes over"
}
normal = "yep"
}
}