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
store absolute addresses for resource dependencies in the state #23252
We need to be able to reference all possible dependencies for ordering
The state version remains the same with this change, since it's only
The inter-instance dependencies will be determined from the complete
The new StateDependencies are used in the DestroyEdgeTransformer
The old code in DestroyEdgeTransformer may no longer be needed in the
We need to be able to reference all possible dependencies for ordering when the configuration is no longer present, which means that absolute addresses must be used. Since this is only to recreate the proper ordering for instance destruction, only resources addresses need to be listed rather than individual instance addresses.
The test fixture did not like having modules when using the generic json map, so read and compare the states in the final *File datastructure.
Make use of the new Dependencies field in the instance state. The inter-instance dependencies will be determined from the complete reference graph, so that absolute addresses can be stored, rather than just references within a module. The Dependencies are added to the node in the same manner as state, i.e. via an "attacher" interface and transformer. This is because dependencies are calculated from the graph itself, and not from the config.
Refresh should load any new dependencies found because of configuration or state changes, but retain any dependencies already in the state. Orphaned resources would not be in config, but we do not want to lose the destroy ordering for the later apply.
Updates resulting from orphaned instances should happen after the deletion of the instances.
The DestroyEdgeTransformer cannot determine ordering from the graph when the destroyers are from orphaned resources, because there are no references to resolve. The new stored Dependencies provides what we need to connect the instances in this case. We also add the StateDependencies method directly in the GraphNodeResourceInstance interface, since all instances already implement this, and we don't need another optional interface to check. The old code in DestroyEdgeTransformer may no longer be needed in the long run, but that can be determined separately, since too many of the tests start with an incomplete state and rely on the Dependencies being determined from the configuration alone.