13 Commits (8564e934aa57cc59459581ee06479879ebf41bf0)

Author	SHA1	Message	Date
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
Liam Cervante	afc83356ca	stacks: actions for a no-op change are a concrete list (#34260)	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	3d8e95d153	rpcapi(Stacks): Support multiple descriptions in a "PlannedChange" ... Previously we had an asymmetry between PlannedChange and AppliedChange, where the latter supported any number of "description" objects whereas the former only supported zero or one. This change then is primarily motivated by making these two APIs consistent, but also has some other benefits: - The generated RPC stub packages will now have a specific type to use to represent _just_ a change description for a plan, so callers can pass around and preserve just those objects in isolation, rather than always having to use the entire PlannedChange message for that purpose. - This gives us a little more flexibility if later we find we need to return more than one description associated with a single logical change in future. For example, if we end up needing to make a breaking change to how we describe a particular kind of change, we might send an object containing both the old form and the new form together, and instruct clients that support the new form to treat it as taking priority over the old form when both are present. We don't yet know of any specific reason to do this, but this protocol is likely to be with us for a long time and so we need to prioritize leaving room for future additions we haven't thought of yet. This is a breaking change to the API from a client's perspective, but that's acceptable at the current stage of development where nothing has been committed in a stable release yet.	2 years ago
Martin Atkins	5372d5eb98	stacks+rpcapi(stacks): Model deposed objects for resource instances ... Previously we incorrectly assumed that resource instances only have one "current" object each. However, resource instances can also have deposed objects which we must also keep track of. This is a breaking change to the rpcapi since we're now using a new message type for a resource instance _object_ address in several places. That breakage is intentional here because at the time of writing this commit the rpcapi is not yet in any stable release and we want to force updating our existing internal client to properly handle deposed objects too.	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	e66f4aacdb	stackplan: Include schema correlation info in resource change descriptions ... In order to find the appropriate schema to use when decoding the dynamic values for a particular resource instance, callers will need to know which provider's schema to consult, and which resource type and mode to consult within that provider's schema. We don't want callers to try to implement their own parsers for Terraform's resource address syntax, and the provider information isn't available any other way anyway, so we'll expose the three required lookup keys as new fields in the events that report that a resource instance change has been planned.	2 years ago
Alisdair McDiarmid	54062a52cb	stacks: More extensive in-progress plan events ... Expand the existing hooks to emit events throughout the planning process, providing enough information for the Terraform Cloud UI to render a live-updating representation of the plan. We also sketch out the equivalent hooks for the apply operation.	2 years ago
Martin Atkins	d3e93e4a31	stackruntime: Initial stubbing of Plan ... This is just enough implementation of "Plan" for embedded stacks with their own input variables and output values, and exposing the final top-level output values as "planned changes". This still doesn't really do anything end-user-useful but it's helpful to have the expression evaluation and plan walk driver machinery in place before moving on to the main useful language element: component blocks. Support for components will follow in subsequent commits.	2 years ago
Martin Atkins	a4ca5f687c	stackplan: Expose the applyable flag as external description ... Previously we retained the applyable flag only in the raw plan sequence, but callers of PlanStackChange also need to know whether the plan they've generated is applyable so that they can e.g. skip showing the plan approval UI. To support that we'll also expose the applyable flag as an externally-consumable PlannedChange.Description variant, just encoding the boolean result directly since there is no other metadata to represent in this case.	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