I created an execution plan with: terraform plan -out=somename
When I attempt to use the plan with this command: terraform apply somename
I get an error message “Error: Saved plan is stale”. My question is how can I figure out what has changed? It’s been a couple of days so I have no doubt something has changed I’m just curious what.
Terraform doesn’t have a way to directly compare one plan with another plan; that would be a diff of a diff, rather than just a diff of direct changes.
However, you could perhaps “fake it” by viewing the saved plan and then running a fresh terraform plan and see what’s different between them:
terraform show -no-color somename >old.txt
terraform plan -no-color >new.txt
diff -u old.txt new.txt
With that said, a plan being “stale” is defined in a pretty low-level way, by checking if the latest state snapshot is identical to the one saved in the plan file. That means that this can happen even if there aren’t any “meaningful” changes, if e.g. someone ran an operation that only modified the state, like terraform import or terraform state rm.
You could potentially get a lower-level look at that by digging into the implementation weeds a bit, but this is just a current implementation detail and so might change in future Terraform versions:
Rename somename to somename.zip, because a saved plan is currently a Zip archive.
Open somename.zip in your favorite archive manager and extract the state snapshot file inside it.
Run terraform state pull to fetch the current state snapshot.
Compare those two snapshots.
That is, in effect, what Terraform itself is doing in order to produce that error message.
Thanks for the mention! I personally have not encountered the stale state so I didn’t think about this edge case when writing the drift detector. I’m glad to know about this concept though.
Not to get too of topic here, but I believe the software would currently catch this exception in the “catch all” that’s written if that. The tool at the moment doesn’t perform terraform apply but is capable of writing the plans + showing the plan so with some additional logic the diff strategy that was mentioned by apparentlymart could be implemented.
I will keep this in mind though! I definitely value having actionable insights on what to do next within the Terraform codebase, so displaying what could be causing the “stale state” error would be very useful in addition to the existing drift report.