mirror of
https://github.com/opentofu/opentofu.git
synced 2025-02-25 18:45:20 -06:00
website: v0.12 upgrade guide about list variables and brackets
This commit is contained in:
parent
83dea200c0
commit
2238fbda1b
@ -275,6 +275,58 @@ because it does not have enough information to know if floating point or integer
|
|||||||
division was intended by the configuration author, so this change must be made
|
division was intended by the configuration author, so this change must be made
|
||||||
manually where needed.
|
manually where needed.
|
||||||
|
|
||||||
|
## Referring to List Variables
|
||||||
|
|
||||||
|
In early versions of Terraform, before list support became first-class, we
|
||||||
|
required using seemingly-redundant list brackets around a single expression
|
||||||
|
in order to hint to the language interpreter that a list interpretation was
|
||||||
|
desired:
|
||||||
|
|
||||||
|
```hcl
|
||||||
|
# Example for older versions of Terraform; not valid for v0.12
|
||||||
|
example = ["${var.any_list}"]
|
||||||
|
```
|
||||||
|
|
||||||
|
This strange requirement was subsequently lifted after the introduction of
|
||||||
|
first-class list support, but we retained compatibility with this older usage
|
||||||
|
for a transitional period by including some fixup logic that would detect when
|
||||||
|
list brackets contain list expressions and automatically flatten to a single
|
||||||
|
list.
|
||||||
|
|
||||||
|
As part of implementing the first-class expressions support for v0.12, we needed
|
||||||
|
to finally remove that backward-compatibility mechanism to avoid ambiguity
|
||||||
|
in the language, so an expression like the above will now produce a list of
|
||||||
|
lists and thus produce a type checking error for any argument that was expecting
|
||||||
|
a list of some other type.
|
||||||
|
|
||||||
|
The upgrade tool is able to recognize most simple usage of this pattern and
|
||||||
|
rewrite automatically to just refer to the list directly:
|
||||||
|
|
||||||
|
```hcl
|
||||||
|
example = var.any_list
|
||||||
|
```
|
||||||
|
|
||||||
|
However, an unintended side-effect of this compatiblity mechanism was to
|
||||||
|
also flatten mixed lists of single-value and list expressions into a single
|
||||||
|
list automatically. We didn't intend for this to be a part of the language, but
|
||||||
|
in retrospect it was an obvious consequence of how the compatibility mechanism
|
||||||
|
was implemented. If you have expressions in your modules that produce a list
|
||||||
|
of strings by using list brackets with a mixture of string and list-of-string
|
||||||
|
sub-expressions, you will need to rewrite this to explicitly use
|
||||||
|
[the `flatten` function](/docs/configuration/functions/flatten.html)
|
||||||
|
to make the special treatment more obvious to the reader:
|
||||||
|
|
||||||
|
```hcl
|
||||||
|
example = flatten([
|
||||||
|
"single string",
|
||||||
|
var.any_list,
|
||||||
|
])
|
||||||
|
```
|
||||||
|
|
||||||
|
The configuration upgrade tool unfortunately cannot make this change
|
||||||
|
automatically, because it doesn't have enough information to know for certain
|
||||||
|
which interpretation was intended for a given list.
|
||||||
|
|
||||||
## Terraform Configuration upgrades requiring human intervention
|
## Terraform Configuration upgrades requiring human intervention
|
||||||
|
|
||||||
There are some known situations that will be detected, but not upgrade, by the
|
There are some known situations that will be detected, but not upgrade, by the
|
||||||
|
Loading…
Reference in New Issue
Block a user