Two ingress rules
Converts, and the iterator is named after the block rather than being each
resource "aws_security_group" "web" {
ingress {
from_port = 80
to_port = 80
}
ingress {
from_port = 443
to_port = 443
}
} Turn repeated nested blocks into a dynamic block and the locals that feeds it. One detail catches everybody exactly once, and it is the iterator name.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Convert. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Converts, and the iterator is named after the block rather than being each
resource "aws_security_group" "web" {
ingress {
from_port = 80
to_port = 80
}
ingress {
from_port = 443
to_port = 443
}
}Every iteration produces the same shape, so the odd one out needs a null
resource "aws_security_group" "web" {
ingress {
from_port = 80
description = "http"
}
ingress {
from_port = 443
}
}Meta-argument blocks are built before any expression is evaluated, so they cannot be dynamic
resource "aws_instance" "web" {
lifecycle {
ignore_changes = [tags]
}
lifecycle {
ignore_changes = [ami]
}
}These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
The iterator is named after the block, so it is ingress.value. The error says each is not available, which sends people to look for a missing for_each on the resource.
Instead:Use ingress.key and ingress.value, or set iterator = "x" and use x.value.
It adds a data structure and an indirection and removes nothing, so the resource gets harder to read for no benefit.
Instead:Convert when the number of blocks varies with a variable. Leave literal repetition literal.
Every iteration produces the same shape, so an attribute missing from one entry is an error rather than an omission.
Instead:Set the absent ones to null explicitly, and check the provider treats null as absent for that argument.
Inside dynamic "ingress" the variable is ingress.value. Writing each.value gives an error saying each is not available, which reads like the resource is missing a for_each rather than like the wrong name.
A dynamic block has exactly two parts: for_each, and a content block holding what one iteration produces. Attributes written directly inside the dynamic block rather than inside content are reported as unsupported arguments, which does not point at the missing wrapper.
iterator = "rule" makes it rule.key and rule.value. Worth doing when the block name is long, and necessary when one dynamic block is nested inside another, because two levels both named after their block cannot both be reached.
So an attribute only some of the original blocks set has to appear in all of them, usually as null. A missing key in the map is an error rather than an omission, and it is the thing that breaks a conversion done by hand.
lifecycle, provider, provisioner and connection, along with count, for_each and depends_on. Terraform builds the resource's own structure before any expression is evaluated, so those have to be literal. A lifecycle block in particular has to be written out, ignore_changes list included.
A dynamic block hides the resource's shape behind a data structure, so what a plan produces is no longer readable from the resource. That is a fair trade when the number of blocks genuinely varies with a variable, and a bad one for three fixed rules somebody found repetitive.
Whether the provider accepts null for the attributes that are uneven, or whether the resulting resource is the one you meant. It converts the structure, in your browser, and runs nothing.