-
Notifications
You must be signed in to change notification settings - Fork 9.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better planing of unknown dynamic blocks #28424
Conversation
This will allow any dynamic blocks that are fixed up as a blocktoattr still decode into an unknown value.
Dynamic blocks with unknown for_each expressions are now decoded into an unknown value rather than using a sentinel object with unknown and null attributes. This will allow providers to precisely plan the block values, rather than trying to heuristically paper over the incorrect plans when dynamic is in use.
The new hcldec dynamic block behavior no longer tried to validate MinItems and MaxItems when the number of values is unknown.
Codecov Report
|
update to v2.10.0
66eeebe
to
f8493bf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very nice, I like the change!
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. |
Make use of the new
hcldec.UnknownBody
feature in HCL to allow unknowndynamic
blocks to be decoded as entirely unknown values. A more complete description of this new feature is in hashicorp/hcl#461Now that the dynamic sentinel values are no longer a factor, the logic around
couldHaveUnknownBlockPlaceholder
is no longer needed, asAssertObjectCompatible
can directly check of the entire block container is unknown.The
hcldec
package will also now no longer need terraform to changeMinItems
andMaxItems
to account for dynamic blocks, because they will no longer be compared at all when dealing with unknown dynamic blocks.The end result here is that providers will now be able to correctly customize (within the constraints of the Resource Instance Change Lifecycle) any proposed block values during
PlanResourceChange
.Fixes #28340