11 Commits (46999364f04ad2df66202a1b9eaa0e7b1ebdca7e)

Author	SHA1	Message	Date
Liam Cervante	c0499647fa	stacks: include moved and removed in API (#35360) ... * stacks: include moved and removed in API * fix race test	2 years ago
Liam Cervante	108bd85053	Refactor deferred variable name to defer in terraform1 API (#35343) ... * Refactor deferred variable name to defer in terraform1 API * fix tests	2 years ago
Liam Cervante	9b95898f63	stacks: emit events for deferred actions (#35325) ... * stacks: emit events for deferred actions * deferral allowed is always on * Update internal/rpcapi/stacks.go Co-authored-by: Daniel Schmidt <danielmschmidt92@gmail.com> --------- Co-authored-by: Daniel Schmidt <danielmschmidt92@gmail.com>	2 years ago
Nick Fagerlund	7703a5aead	Stacks: Add ProviderAddr field to ResourceInstanceStatusHookData ... This updates the stackruntime `hooks.ResourceInstanceStatusHookData` struct to include the provider address, and updates everything that instantiates that struct to pass along the valid provider address it received from its own caller. In other words, this commit is a bridge between the terraform.Hook interface methods (which already have access to the provider address) and the stacks hook callbacks that result in RPC messages being sent to the agent.	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.	3 years ago
Martin Atkins	2559151d0a	stackruntime: Count actions successfully applied ... Callers expect to be given an updated set of counts for how many of each action were completed, which we'll achieve by having the terraform.Hook implementation keep track of those and then announce them based on what it collected. We can't use the plan for this directly because terraform.Context.Plan seems to modify the plan it's given during its work, and on success the plan ends up being totally empty.	3 years ago
Martin Atkins	947c483c49	rpcapi: Stack plan and apply use the same progress message type ... Previously we had the progress messages directly inlined as events of the PlanStackChanges operation, but that means that there's no common interface type for progress events across both the plan and apply phases, making it hard for Go implementations to share marshaling code between the two phases. Now we'll use a new StackChangeProgress message type to contain all of the progress message situations. This makes constructing and using the progress messages a little more verbose -- an extra layer of message -- but means that we can write code that works generically with the StackChangeProgress generated struct and thus share it between the two phases, leading to less code overall. As of this commit we don't yet have the apply phase generating any progress messages, but we'll extend it in a subsequent commit now that it's possible to share more of that event-generating code between the two phases.	3 years ago
Martin Atkins	d1b0632e82	stackruntime: Add HashiCorp copyright comments	3 years ago
Alisdair McDiarmid	927350eca8	rpcapi: Add component expansion and change summary ... We want to report the result of component expansion to the client as early as possible, so that it can prepare to receive any following information for each instance. This message is critical when a component's expansion expression evaluates to an empty set: without this message's confirmation of this case, it will be unable to determine that the component will receive no plans for any instances until the plan completes. We also want to report a roll-up of the resource changes upon completion of each component's plan and apply operations, so that a client can summarize the operation changes without performing the roll-up operation on all received change events.	3 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.	3 years ago
Martin Atkins	8af46fd38b	stackruntime: An extensible "hooks" API ... Following a similar model that we've previously used in other parts of Terraform to expose UI-oriented progress events, here we define stackruntime.Hooks as a collection of optional callbacks a caller can use to subscribe to events, and the supporting utility code to help us concisely and correctly call those hook functions from the main evaluation code without adding too much extra noise to the code. Although the primary focus of this API is driving realtime UI updates, the API design also aims to accommodate distributed tracing use-cases by allowing callers to propagate arbitrary values between related event notifications and to inject additional values into the context.Context used for downstream operations that might not be under the direct supervision of stackruntime/stackeval.	3 years ago