8 Commits (5848d8a2b4e0c500c384bcbdcc84b5feec3f6549)

Author	SHA1	Message	Date
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	c67920ce4b	stackplan: Add HashiCorp copyright comments	2 years ago
Martin Atkins	fafa36e73a	stackeval: ApplyPlan function and initial supporting internals ... This is a first pass at actually driving the apply phase through to completion, using the ChangeExec function to schedule the real change operations from the plan and then, just like for planning, a visit to each participating object to ask it to check itself and report the results of any changes it has made. Many of our objects don't have any external side-effects of their own and so just need to check their results are still valid after the apply phase has replaced unknown values with known values. For those we can mostly just share the same logic between plan and apply aside from asking for ApplyPhase instead of PlanPhase. ComponentInstance and OutputValue are the two objects whose treatment differs the most between plan and apply, because both of those need to emit externally-visible "applied change" objects to explain their side-effects to the caller. The apply-walk driver has a lot of behavior in common with the existing plan-walk driver. For this commit we're just accepting that and having two very similar pieces of code that differ only in some leaf details. In a future commit we might try to generalize that so we can share more logic between the two, but only if we can do that without making the code significantly harder to read.	2 years ago
Martin Atkins	ba8af34679	stackplan: Stub of runtime models for representing plans ... This package includes both some model types to represent plans (and parts thereof) in memory, and logic for translating between the in-memory representation and our protocol-buffers-based storage serialization. Unlike the traditional saved plan file format, the stacks model for planning is slightly asymmetrical: while constructing the plan the system will emit chunks of the overall plan piecemeal as PlannedChange values, streamed to the rpcapi client. When reloading that plan to apply it, the client must provide all of the raw plan blobs in sequence which we can then decode one by one to construct a single Plan object covering the entire effect of the plan. Another intentional asymmetry is that PlannedChange includes enough information to produce both the raw internal plan representation and the public-facing plan description, whereas Plan only includes the subset of information actually required for Terraform Core to apply the plan, from the raw internal representation exclusively.	2 years ago
Martin Atkins	d857c75e33	stackplan: Initial models for a "meta-plan" over an entire stack	2 years ago