depends_on with instance replacement not working as expected #16200
Comments
|
Hi @bacoboy, This is a hard problem to solve. Yes, the fundamental issue here is that Terraform can't re-order the new resources, precisely because of the dependencies you put in the configuration. The new One workaround is obviously to run terraform 3 times, replacing the instances in the order required. I don't think there's a way to interject some null resources in there to force the order, but it might be worth playing with to see what the graph looks like. I think the idea of a new lifecycle (e.g. Another idea would be to have some sort of lifecycle group in the configuration, where one could declare the order of operations for a set of resources. Thanks for the great example! |
|
Some diagrams to help think about it. The dotted line is from the "must delete before create" lifecycle in Not sure if github will render these inline so will include links... graph LR
1c((create one))-->2c((create two))
2c-->3c((create three))
The Replace cycle as it currently works when no lifecycle is specified: graph TB
3d-->2d
2d-->1d
1c-->2c
2c-->3c
subgraph one
1d{destroy one}-.->1c((create one))
end
subgraph two
2d{destroy two}-.->2c((create two))
end
subgraph three
3d{destroy three}-.->3c((create three))
end
This flag (if set) would swap out the calculated links between the create steps and link across dependencies more explicitly note the 3rd and 4th link in the code changes: graph TB
3d-->2d
2d-->1d
3c-->2d
2c-->1d
subgraph one
1d{destroy one}-.->1c((create one))
end
subgraph two
2d{destroy two}-.->2c((create two))
end
subgraph three
3d{destroy three}-.->3c((create three))
end
|
|
Long time passed since I submitted this, but (currently) 0.11.11 still has this behavior. Trying to sequence 3 "force new resource/tainted) changes. Graphs of behaviors still follow this previous comment Will there be a way to handle this in 0.12? I've tried the null_resource chaining to no avail. The |
|
@jbardin Been another year so checking in on any progress/thoughts on more specific lifecycle management in TF? |
|
Has it really been 5 years?! Would still love to see some movement on this (as it just came up in (different) job - again). |
The setup for this problem is I'm trying to figure out how to roll instances in AWS in sequence
using explicit
depends_onbetween resources. In cases where new instances can be created firstusing the lifecycle directive
create_before_destroy=true, this works just fine. However, for instancesthat have an unsharable property (like a fixed IP), the replacement sequence does not work as expected.
This is needed to be able to do things like quorum replacements (consul, etcd, zookeeper, etc) or
DNS servers at fixed ips without resorting to external script hackery when the rest of your infrastructure
is nicely managed in terraform.
Here is the terraform code I used to demonstrate this:
Here I create 3 instances in sequence as described in this dependency graph:
Now the first time I run this, there are no instances so they get created in dependency sequence:
The
applyrun (note the sequence of instance creation):OK so everything looks good, but now I have a new image I need to swap out one at a time.
To simulate this I change the
ami_idto something else and you see the plan wantsto swap the instances, but delete first since the fixed IP doesn't
allow for
lifecycle { create_before_destroy = true }semantics.It even says
destroy and then create replacementwhich is what I wanted:Now when I run, I expected this sequence:
What I got was:
as you can see here:
Other people have brought this up and said things like "I'm sure there is some kind of work-around",
but I've looked and looked and this just doesn't seem to be supported.
Perhaps there is some ambiguity that can be addressed with an explicit block like:
Items which may or may not be related, but smell similar:
The text was updated successfully, but these errors were encountered: