* 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>
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.
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.
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.
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.
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.
