3 Commits (ba63e8080b7fdb1069d00a4ff3e0304c89d1867e)

Author	SHA1	Message	Date
Martin Atkins	b0b8d4aa6f	states: Only track root module output values ... For a very long time we've had an annoying discrepancy between the in-memory state model and our state snapshot format where the in-memory format stores output values for all modules whereas the snapshot format only tracks the root module output values because those are all we actually need to preserve between runs. That design wart was a result of us using the state both as an internal and an external artifact, due to having nowhere else to store the transient values of non-root module output values while Terraform Core does its work. We now have namedvals.State to internally track all of the throwaway results from named values that don't need to persist between runs, so now we'll use that for our internal work instead and reserve the states.State model only for the data that we will preserve between runs in state snapshots. The namedvals internal model isn't really designed to support enumerating all of the output values for a particular module call, but our expression evaluator currently depends on being able to do that and so we have a temporary inefficient implementation of that which just scans the entire table of values as a stopgap just to avoid this commit growing even larger than it already is. In a future commit we'll rework the evaluator to support the PartialEval mode and at the same time move the responsiblity for enumerating all of the output values into the evaluator itself, since it should be able to determine what it's expecting by analyzing the configuration rather than just by trusting that earlier evaluation has completed correctly. Because our legacy state string serialization previously included output values for all modules, some of our context tests were accidentally depending on the implementation detail of how those got stored internally. Those tests are updated here to test only the data that is a real part of Terraform Core's result, by ensuring that the relevant data appears somewhere either in a root output value or in a resource attribute.	2 years ago
Martin Atkins	f41f47563e	namedvals: Can ask if a particular value has been registered ... We shouldn't need this in normal code because the graph walk should ensure that values are always registered before we read them, but this will be useful in test code to avoid panicking in situations where the graph walk doesn't behave correctly and we _do_ end up reading and writing in the wrong order.	2 years ago
Martin Atkins	869750da61	namedvals: A new package to encapsulate the tracking of named values ... Currently we have a slightly different treatment for each of the different kinds of named values, which makes it hard to generalize the implementations of their very similar behaviors. This package should over time take ownership of the problem of tracking all three kinds of named value during a graph walk, with result data structures that use this information (such as state and plan objects) copying the relevant values out of here only once the graph walk is complete. Nothing is using this yet, though. Some retrofitting of this into Terraform Core will follow in subsequent commits.	2 years ago