terraform/internal/plans/objchange/action.go

41 lines
1.3 KiB
Go
Raw Normal View History

backend/local: treat output changes as side-effects to be applied This is a baby-step towards an intended future where all Terraform actions which have side-effects in either remote objects or the Terraform state can go through the plan+apply workflow. This initial change is focused only on allowing plan+apply for changes to root module output values, so that these can be written into a new state snapshot (for consumption by terraform_remote_state elsewhere) without having to go outside of the primary workflow by running "terraform refresh". This is also better than "terraform refresh" because it gives an opportunity to review the proposed changes before applying them, as we're accustomed to with resource changes. The downside here is that Terraform Core was not designed to produce accurate changesets for root module outputs. Although we added a place for it in the plan model in Terraform 0.12, Terraform Core currently produces inaccurate changesets there which don't properly track the prior values. We're planning to rework Terraform Core's evaluation approach in a forthcoming release so it would itself be able to distinguish between the prior state and the planned new state to produce an accurate changeset, but this commit introduces a temporary stop-gap solution of implementing the logic up in the local backend code, where we can freeze a snapshot of the prior state before we take any other actions and then use that to produce an accurate output changeset to decide whether the plan has externally-visible side-effects and render any changes to output values. This temporary approach should be replaced by a more appropriately-placed solution in Terraform Core in a release, which should then allow further behaviors in similar vein, such as user-visible drift detection for resource instances.
2020-05-27 01:59:06 +02:00
package objchange
import (
"github.com/zclconf/go-cty/cty"
"github.com/hashicorp/terraform/internal/plans"
backend/local: treat output changes as side-effects to be applied This is a baby-step towards an intended future where all Terraform actions which have side-effects in either remote objects or the Terraform state can go through the plan+apply workflow. This initial change is focused only on allowing plan+apply for changes to root module output values, so that these can be written into a new state snapshot (for consumption by terraform_remote_state elsewhere) without having to go outside of the primary workflow by running "terraform refresh". This is also better than "terraform refresh" because it gives an opportunity to review the proposed changes before applying them, as we're accustomed to with resource changes. The downside here is that Terraform Core was not designed to produce accurate changesets for root module outputs. Although we added a place for it in the plan model in Terraform 0.12, Terraform Core currently produces inaccurate changesets there which don't properly track the prior values. We're planning to rework Terraform Core's evaluation approach in a forthcoming release so it would itself be able to distinguish between the prior state and the planned new state to produce an accurate changeset, but this commit introduces a temporary stop-gap solution of implementing the logic up in the local backend code, where we can freeze a snapshot of the prior state before we take any other actions and then use that to produce an accurate output changeset to decide whether the plan has externally-visible side-effects and render any changes to output values. This temporary approach should be replaced by a more appropriately-placed solution in Terraform Core in a release, which should then allow further behaviors in similar vein, such as user-visible drift detection for resource instances.
2020-05-27 01:59:06 +02:00
)
// ActionForChange determines which plans.Action value best describes a
// change from the value given in before to the value given in after.
//
// Because it has no context aside from the values, it can only return the
// basic actions NoOp, Create, Update, and Delete. Other codepaths with
// additional information might make this decision differently, such as by
// using the Replace action instead of the Update action where that makes
// sense.
//
// If the after value is unknown then the action can't be properly decided, and
// so ActionForChange will conservatively return either Create or Update
// depending on whether the before value is null. The before value must always
// be fully known; ActionForChange will panic if it contains any unknown values.
func ActionForChange(before, after cty.Value) plans.Action {
switch {
case !after.IsKnown():
if before.IsNull() {
return plans.Create
}
return plans.Update
case after.IsNull() && before.IsNull():
return plans.NoOp
case after.IsNull() && !before.IsNull():
return plans.Delete
case before.IsNull() && !after.IsNull():
return plans.Create
case after.RawEquals(before):
return plans.NoOp
default:
return plans.Update
}
}