Conceptually I’ve got the following:
resource a a {
foreach [ some-key-value-map]
lifecycle {
create_before_destroy = true
}
}
resource b b {
depends_on [a.a]
foreach = [ some-other-key-value-map ]
}
Now when I rename a key in some-key-value-map
a resource is created and destroyed. So far so good.
However, a resource in b.b
is implicitly dependent on this, however I consistently refer to the renamed key in this resource in b.b
.
Without create_before_destroy
set to true, this fails, as the apply execution is as follows:
1a. create a.a[newkey] // these are executed parallel
1b. destroy a.a[oldkey] // these are executed parallel
2 update b.b[...]
…
This fails as the old resource is still referenced in the not-yet-updated b.b[...]
.
So far this is all expected.
However, I would’ve expected that introducing the create_before_destroy
would’ve shown the following order of exection:
- create
a.a[newkey]
- update
b.b[...]
- destroy
a.a[oldkey]
I expect this because the depends_on is on the whole of a.a
. The aforementioned plus the explanantion in terraform/docs/destroying.md at main · hashicorp/terraform · GitHub expected me to have the desired execution order stated above where the destroy of a.a[oldkey]
would be the last step.
Can someone explain me why the expected execution order is not happening for me?