5 Commits (69aa51b9ffb5187814febc6353c846fa17b9f2b4)

Author	SHA1	Message	Date
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