5 Commits (add-missing-variable-loading)

Author	SHA1	Message	Date
Radek Simko	0fe906fa8c	make copyrightfix	2 months ago
Martin Atkins	9851cd456e	terraform: decide module instances using new API ... We've been gradually improving the design of how we keep track of "named values" such as output values, but the expression evaluator for output values was still doing some things in more manual/bespoke way, rather than making use of the new abstractions. We'll now use a combination of instances.Expander and namedvalues.State as the source of truth for which instances exist for a given module call and what output values each of those instances have. The configuration remains the decider for which output value names are declared, but the final result associated with each of the declared output values is tracked by namedvalues.State. This also removes the temporary namedvals GetOutputValuesForModuleCall method we added as a stopgap to allow introducing the namedvals.State API without such a disruptive rewrite of our output value handling. We have no further need for that helper because instances.Expander already knows which instances should exist for each module call, and the configuration knows which output values should exist in the result, and so namedvals only needs to be able to return one final output value result at a time, via namedvals.State.GetOutputValue. With all of the tricky inline logic factored out of this part of the evaluator, the TestEvaluatorGetModule test becomes considerably simpler since it's no longer the evaluator's responsibility to choose between various different sources for the module output values depending on the situation, and instead we just need to set the evaluator and the instance expander up in a realistic way, with the correct handling of both of those utilities already being covered by this package's main integration tests.	2 years ago
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