Add the deferred changes into the plan #34946
Conversation
…te/deferred-actions-in-plan
|
Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch. |
| // WildcardKey represents the "unknown" value of an InstanceKey. This is used | ||
| // within the deferral logic to express absolute module and resource addresses | ||
| // that are not known at the time of planning. | ||
| var WildcardKey InstanceKey = StringKey("*") |
There was a problem hiding this comment.
While unlikely, "*" is a valid instance key on its own. Is it possible that could collide here?
There was a problem hiding this comment.
This would only be set when combined with the DeferredReasonInstanceCountUnknown reason. That reason will never have a "valid" instance key associated with it. I've used this just as a convenience for when the address is rendered, in reality nothing should attempt to parse an address from a deferred change with the mentioned reason as the value in there is inherently meaningless.
|
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. |
This PR adds any changes deferred during the plan into the produced plan artefact. We place the changes into a new field called
DeferredResourcesalongside the existing drifted resources and changed resources.I've added the representation of a wildcard instance key (
[*]) into theAbsResourceInstanceaddress, so we can represent unknown instances in the same way as other instances that are being deferred for other reasons. As this is only written into a new field that isn't referenced anywhere yet this shouldn't cause any breaking changes.I've refactored the existing deferrals package so that it accepts and tracks the complete changes that can be written into the plan at the end instead of the partial information it was tracking before.