You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

Martin Atkins be33a7e9e0 stackeval: Use prior state outputs when planning component destroy ... When a component is planned for full destroy, we should assume that its apply phase will be delayed until everything that depends on it has been destroyed, since otherwise we'd be violating the dependency relationship. That means that the expression value for a component pending destruction ought to be based on the output values from the prior state (which ought to have been refreshed as part of planning destroy) rather than the desired state (in which case all of the output values would be unset). This commit only deals with the _planning_ part of this problem, and only deals with the situation where we're planning a "full destroy" of the entire stack configuration and therefore all component instances in the configuration are going to be destroyed. In future commits we'll need at least the following additional work to complete this: - The apply phase needs to learn to schedule component instance destroy actions differently than other component instance actions, so that destroy cannot begin until everything that depends on the component has already been destroyed. - We also need to deal with the situation where only a particular component instance has been removed from the configuration, in which case only that one component instance is planned for destroy and everything else is planned as normal. In that case it would be invalid for anything to still be referring to that component instance in the configuration, and so the work in this commit would actually be irrelevant, but it'll take some other separate machinery to make sure that the removed component instances still get planned properly, which they don't today. This commit is just an incremental step toward the final correct behavior, which should allow the planning of a full destroy to succeed, although actually applying that plan is still likely to fail because the apply phase will not respect the required order of operations yet.		2 years ago
..
hooks	stacks+rpcapi(stacks): Model deposed objects for resource instances	2 years ago
internal/stackeval	stackeval: Use prior state outputs when planning component destroy	2 years ago
testdata/mainbundle	stacks/stackruntime: fix TestPlanWithSingleResource	2 years ago
apply.go	stackruntime: Add HashiCorp copyright comments	2 years ago
doc.go	stackruntime: Add HashiCorp copyright comments	2 years ago
eval_expr.go	stacks+rpcapi: Add some missing copyright comments	2 years ago
helper_test.go	stackruntime: Add HashiCorp copyright comments	2 years ago
hooks.go	stackruntime: Add HashiCorp copyright comments	2 years ago
plan.go	stacks+rpcapi: Wire through the "plan mode" to the stacks runtime	2 years ago
plan_test.go	stackplan: Track provider config for every resource instance change	2 years ago
telemetry.go	stackruntime: Add HashiCorp copyright comments	2 years ago
telemetry_test.go	stackruntime: Add HashiCorp copyright comments	2 years ago
validate.go	stackruntime: Add HashiCorp copyright comments	2 years ago
validate_test.go	stackruntime: Add HashiCorp copyright comments	2 years ago