13 Commits (660ff86c4cccf5528f23adcd9e2a1936ea4af67a)

Author	SHA1	Message	Date
Martin Atkins	d3b8a55781	go.mod: go get google.golang.org/protobuf@v1.33.0 ... Many of the changes between these two versions seem to be in parts of the library that Terraform doesn't use, but there are a few sensitive parts: - Slight changes to details of how the library implements the JSON encoding of protobuf. Terraform CLI/Core don't use this, but some of the backends might use it indirectly when talking to their underlying APIs. - Some details of the "protoreflect" package for working with protobuf descriptors dynamically (rather than using generated stubs) have changed, but it seems pretty marginal and unlikely to cause problems.	2 years ago
CJ Horton	5a750561e6	round-trip check results through stack plans ... Components expect that check results will be round-tripped through the plan in order to update unknown check results during the apply. We hadn't wired this up for stack plans, resulting in panics when the apply tries to update a check status that doesn't exist.	2 years ago
Martin Atkins	884e1fb2a4	terraform: Plans can be "complete" and "applyable" ... These ideas are both already implied by some logic elsewhere in the system, but until now we didn't have the decision logic centralized in a single place that could therefore evolve over time without necessarily always updating every caller together. We'll now have the modules runtime produce its own boolean ruling about each characteristic, which callers can rely on for the mechanical decision-making of whether to offer the user an "approve" prompt, and whether to remind the user after apply that it was an incomplete plan that will probably therefore need at least one more plan/apply round to converge. The "Applyable" flag directly replaces the previous method Plan.CanApply, with equivalent logic. Making this a field instead of a method means that we can freeze it as part of a saved plan, rather than recalculating it when we reload the plan, and we can export the field value in our export formats like JSON while ensuring it'll always be consistent with what Terraform is using internally. Callers can (and should) still use other context in the plan to return more tailored messages for specific situations they already know about that might be useful to users, but with these flags as a baseline callers can now just fall back to a generic presentation when encountering a situation they don't yet understand, rather than making the wrong decision and causing something strange to happen. That is: a lack of awareness of a new rule will now cause just a generic message in the UI, rather than incorrect behavior. This commit mostly just deals with populating the flags, and then all of the direct consequences of that on our various tests. Further changes to actually make use of these flags elsewhere in the system will follow in later commits, both in this repository and in other repositories.	2 years ago
Martin Atkins	a4d61733f6	stackplan: Include extra info in raw component instance plan ... We'll now track the planned action, the component addresses we depend on, and the planned output values.	2 years ago
Martin Atkins	bcccd67e32	tfstackdata1: A local DynamicValue message type ... Previously we were directly using the planproto.DynamicValue message type, but that's symmetrical with plans.DynamicValue in that it encodes only the value itself and not associated metadata such as the paths that have sensitive value marks. This new tfstackdata1.DynamicValue therefore echoes terraform1.DynamicValue by carrying both the value and the metadata together. This implies a slight change to one of the existing message types that was encoding a map of planned input values for each component instance, but in practice we're not currently making use of that data anyway -- it's there to enable a hypothetical extra correctness check in the stacks runtime so that we can detect inconsistency problems closer to their source -- and so this change doesn't affect anything in practice. Before we make use of it we'll probably want to change the internal API a little so that we can preserve the sensitive value metadata on those values, but that's beyond the scope of this PR. The main point of adding this is to track the output values for a component instance as part of the raw state, and so the new field for that is also added here although nothing will read or write it yet. Actual use of that new field will follow in future commits.	2 years ago
Martin Atkins	972f1c0678	stackplan: Track provider config for every resource instance change ... Previously we were still partially relying on the record of this in the embedded planproto object, but since we're now allowing "planned changes" that don't actually include a change in that traditional sense we need to track the provider configuration address separately as a top-level field. As with some of the addresses before, this means we're now storing the provider config address redundantly in two places when there _is_ a planproto change. Hopefully we'll improve that someday, but we don't need to sweat it too much right now because this only affects the internal raw plan format that is not subject to any compatibility promises between releases, so we can freely change it in any future version.	2 years ago
Martin Atkins	4e34e6ebfa	stacks: Track prior state for all resource instance objects ... Previously our raw plan data structure only included information about resource instances that have planned actions, which meant we were missing those which only get their state updated during refresh and don't actually need any real work done. Now we'll track everything, accepting that some "planned changes" for resource instance objects will not actually include a planned change in the typical sense, and instead only represent a state update.	2 years ago
Martin Atkins	8fd29e9439	stacks: Preserve prior state from plan to apply ... We need to retain the prior state (in a form that Terraform Core's modules runtime can accept) between the plan and apply phases because Terraform uses it to verify that the provider's "final plan" is consistent with the initial plan. We previously tried to do this by reusing the "old" value from the planned change, but that's not really possible in practice because of the historical implementation detail that Terraform wants state information in a JSON format and plan information in MessagePack. This also contains the beginnings of handling the "discarding" of unrecognized keys from the state data structures, although we'll probably need to do more in that area later since this is just the bare minimum.	2 years ago
Martin Atkins	69aa51b9ff	stackruntime: Fix some quirks of data sent from plan to apply ... We previously took a few shortcuts just to more quickly produce a proof of concept. This gets us considerably closer to a properly-working handoff from plan to apply, at least for create, update, and replace actions. Destroying stuff that's been removed from the configuration will take some further work since currently everything we do is driven by objects in the configuration. That will follow in later commits.	2 years ago
Martin Atkins	49511fe9a8	stackstate: Fuller round-tripping of resource instance object state ... This gets us ever closer to being able to preserve resource instance objects from one run to the next. In subsequent commits we'll make use of the "LoadFromProto" option to load the prior state during the planning phase and take it into account when we're deciding what actions to propose.	2 years ago
Martin Atkins	54622c68a5	stackstate: Generate "raw state" objects for resource instance objects ... Previously we just had a stub that only generated basic external description objects. Now we'll also emit "raw state" objects for these, and have some initial support for deposed objects too.	2 years ago
Martin Atkins	d99985720f	stacks: Carry input variable values from plan to apply ... We need to preserve the input variable values provided during the plan phase so we can reuse them during the apply phase to recalculate derived results based on new information learned during the apply process. We also need to recalculate the input values for individual components during the apply phase, so we can react to previously-unknown values that come from other upstream components.	2 years ago
Martin Atkins	f9317731e9	tfstackdata1: Protobuf schema for stack plan and state serialization ... This represents our _internal_ plan and state formats, which are private to Terraform Core so that we can evolve them over time without needing to coordinate with other systems. The plan parts of this are the stack-specific container messages around the existing "tfplan" proto schema that traditional Terraform uses for saved plan files. The state parts of this are really just stubs since we're not really dealing with state just yet, but they're here to illustrate where we intend to expand in future commits when we start implementing the apply phase and the ability to plan based on a prior state.	2 years ago