Hi, I’m having an odd behavior between “plan” and “apply”. I have modified some existing aws_iam_policy and when I execute a “terraform plan” using -target I get the following output:
Plan: 0 to add, 3 to change, 0 to destroy.
And when I try to execute the apply, the output is:
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
I am using version 0.13.7 and 3.53.0 of AWS provider.
Thanks
Hi @scuellar,
One common point of confusion is that because plan may not have enough information to fully determine the final set of targets, there may be extra resource instances in the plan which end up being filtered or become no-op changes once we get to the apply stage.
Since -target is not intended to be the normal operating mode for terraform, the extra changes are only temporary and resolved once the state is updated to no longer need the use of -target.
So the answer here is, yes, this is known and expected in some circumstances. If the plan output is causing an issue, then we would need to see a complete reproduction case in order to provide more feedback, but it’s likely that the only resolution would be to modify your workflow to not use -target.
Thanks @jbardin for your answer.
I was trying to use the following target:
terraform plan target="module.sso_roles.aws_iam_policy_attachment.admin-policy-attachment"
Plan: 0 to add, 3 to change, 0 to destroy.
The changes that were planned to be made, were correct.
As I mentioned, the apply didn’t execute any change.
Reviewing the output from plan I saw that Terraform was going to perform actions in the aws_iam_policy that I modified, so I changed the target to the policy, and Terraform now applied correctly the change.
terraform apply target="module.sso_roles.aws_iam_policy.admin-policy"
Apply complete! Resources: 0 added, 3 changed, 0 destroyed.
Thanks for the clarification in the use of -target
Hi @scuellar,
The situation that @jbardin was describing arises in situations where a value appears as (known after apply) in the plan, but then during the apply step the final value ends up actually matching the previous value after all, because the dynamic result just happened to select the same value.
Since you’re talking about IAM policies, one specific situation where that can arise is if your policy includes a reference to an arn attribute from some other resource that’s planned to be replaced in the current plan.
The AWS provider typically marks ARNs as (known after apply) when dealing with a create/replace, because the remote system is usually the one to decide on the ARN format, but lots of AWS services use your specified object name as the unique identifier portion of the ARN and so the final ARN ends up being the same after creating the replacement object. In that case, Terraform correctly notices that the final value for the ARN actually matches what was chosen before, and thus it skips replacing or updating the downstream objects that refer to the ARN, such as an IAM policy.
This can be true both in targeted and untargeted modes. I expect that something like what I described above is the cause of the behavior you saw.