Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
instances.Expander: A utility for encapsulating "count" and "for_each" concerns #23462
Our existing handling of
This PR represents some initial experimentation towards centralizing the expansion logic for resources and for modules (looking forward to future module
Each family feeds into the next, so they must be called in a particular order for correct operation. The graph walk can take care of ensuring the correct ordering of calls so that data is always available before it is needed.
As an initial proof-of-concept I integrated
In principle though, if the
If this were to be taken forward as the basis for module
This does appear to work and pass all the existing context tests without modification, but for the moment it's mainly intended as a conversation starter for whether this particular direction --
This package aims to encapsulate the module/resource repetition problem so that Terraform Core's graph node DynamicExpand implementations can be simpler. This is also a building block on the path towards module repetition, by modelling the recursive expansion of modules and their contents. This will allow the Terraform Core plan graph to have one node per configuration construct, each of which will DynamicExpand into as many sub-nodes as necessary to cover all of the recursive module instantiations. For the moment this is just dead code, because Terraform Core isn't yet updated to use it.
When ModuleInstanceStep values appear alone in debug messages, it's easier to read them in a compact, HCL-like form than as the default struct printing style.
This is not used yet, but in future commits will be used as a "blackboard" to centrally aggregate the information pertaining to expansion of resources and modules (using "count" or "for_each") to help ensure consistent treatment of the expansion process during a graph walk. In practice this only really makes sense for the plan walk, because the apply walk doesn't do any dynamic expansion.
This is a minimal integration of instances.Expander used just for resource count and for_each, for now just forcing modules to always be singletons because the rest of Terraform Core isn't ready to deal with expanding module calls yet. This doesn't integrate super cleanly yet because we still have some cleanup work to do in the design of the plan walk, to make it explicit that the nodes in the plan graph represent static configuration objects rather than expanded instances, including for modules. To make this work in the meantime, there is some shimming between addrs.Module and addrs.ModuleInstance to correct for the discontinuities that result from the fact that Terraform currently assumes that modules are always singletons.
We're not far enough along yet to be able to actually use the RepetitionData instances provided by the instances package, but having these types be considered identical will help us to gradually migrate over as we prepare the rest of Terraform to properly populate the Expander.