json-output: Add resource drift to machine readable UI#29072
Conversation
There was a problem hiding this comment.
Functionality-wise, this looks great to me.
I share your concern but also the uncertainty about how better to factor the logic for taking two states and detecting drift from them. Given the circular-import challenges we had with trying to reuse the types from plans, the best idea I have to hand right now is to establish a new package plans/drift which defines some types similar to some of the model types we have in plans to model changes.
I do wonder about potentially factoring out the change-model-related types into a separate plans/changes package which various other packages could then call on, but that'd be a pretty noisy change in terms of how many users it would update, and also the models in plans are tailored for the specific need of serializing changes into a plan file, and we don't really have those needs here because we can always re-derive the same answer from the pair of state snapshots we already have serialized in there.
Given that, maybe it's not too bad to have some similar-but-not-identical model types specialized for representing drift, particularly if we make an effort to keep them as similar as makes sense to be in case we find a path to converging them later.
🤔
|
I like the |
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
The new
resource_driftmessage allows consumers of theterraform plan -jsonoutput to determine which resources Terraform found to have changed externally after the refresh phase.Note to reviewers: this implementation is a third copy of the logic for determining resource drift for a plan. I'm not happy about this, but I'm struggling to see a way to extract the logic to a single place, given the intertwingled dependencies. Any suggestions?