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