Objects have changed outside of Terraform - ignore_changes ignored

Terraform
1

With Terraform 0.15 there appears to be a new section of the plan “Objects have changed outside of Terraform”.

I am finding that this is showing diffs for resource internal fields that are managed by AWS (for example the current_version for a MSK cluster).

I attempted to add a lifecycle ignore_changes adding that field. However the plan still shows the diff.

This is somewhat confusing to end users who are use to not seeing a diff when running plan/apply.

5 Likes
2

Hi @cyrus-mc,

Indeed, this new feature makes Terraform show something that it was previously keeping silent: updating the state to match the remote system.

The ignore_changes argument disables Terraform’s behavior of comparing the configuration with the state to plan any necessary new actions, but the “Objects have change outside of Terraform” is reporting a difference between the prior state and the remote object.

Terraform has always been detecting such changes and updating the state to include them, but it was previously silent about it. Being silent about it would means that Terraform could propose to make a change in response to what it detected even though it gave no indication that it had detected anything, and so Terraform is now reporting the updated data it’s using in order to decide what to propose.

The only mechanism Terraform currently has in order to disable detecting changes during refresh is the global -refresh=false option, which will cause Terraform to not refresh anything at all. If you elect to have Terraform refresh during planning (the default behavior) then it’ll report what it detected in order to be clear about what new values Terraform used as the basis of the plan.

3

I just recently upgraded and also find this confusing. I’m saying “I expect this to change, and that’s okay” and Terraform is telling me that it changed. It’s like git giving me a diff of stuff in my .gitignore file: I literally just said I don’t care about it, why am I seeing it? There should be a way to say “I expect this to change, it’s harmless and out of my control, please don’t bother me about it.”

I can deal with annoying things-- don’t let my whining deter you-- but there’s a larger issue to consider. Normally I’d really want to know if something in my infra is changing out from under me. By showing things there that we really don’t care about (and tried to communicate), Terraform is training us to subconsciously skip that section entirely, and eventually that’s going to bite somebody. Probably me. I really suggest we reconsider this feature.

1 Like
4

We do intend to iterate on this feature in future versions. The current incarnation has Terraform explain things as they currently exist. We hope to improve on it by changing aspects of Terraform’s model so that an honest representation of what happened will also be a more useful representation of what happened, by making Terraform’s behavior itself more useful (rather than pretending in the UI that it behaves differently than it actually does).

I can assure you that we’re taking this feedback on board and considering how best to address it, but it isn’t likely to be a quick solution because of the current design assumptions I described in my earlier comment, which we’ll need to refine in order to get a better result.

3 Likes
5

Yes please add a flag to disable this output, even if only to disable output generated by attributes which are explicitly included in “ignore_changes”. This now creates a lot of noise in our delivery pipelines and obscures the actually planned and potentially dangerous changes somewhere within. My auto-scaling groups having a mis-matched “desired capacity” because they are auto-scaling is totally irrelevant to my plan.

1 Like
6

I have to say that I’d absolutely love this. Terraform is now properly seeing for a lot of AWS policy documents that they’re just being shuffled on the AWS end and reporting no changes - with the exception of ECR policies, and it’s great that I can see that they’re in a different order, but at the same time, they badly muddy the water when I’m looking at terraform output before approving a code change. For that I really just need to see what changes terraform is threatening to make.

7

I am seeing the same message in our pipeline and it’s showing changes that we don’t think are necessary. It would be awesome to somehow silence these. I am just trying to think of a reason why this diff will be useful?

8

I ran Terraform locally, with state file in S3 backend. Later, when I pushed the same code to repo, the pipeline which should be referring to the same state file in S3, is picking up changes outside of Terraform!!

9

@apparentlymart, We recently upgraded to terraform and seeing the message stated in this post.
Sorry for the lengthy post.

Below are some things I found below points

  • RDS instances the Last restorable time which is not under our control. How do you expect us to handle these.
  • EKS platform version which we cant add in the module how do you expect these to be handled

As per your documentation the above values are Exported values which we cant add in our IaC. If you want to continue with the feature

  • you need to make sure that the plan should show only the changes which can be added / modified / updated through IaC.
  • Else, you need to add separate section to declare exported values(Here, we need to check plan make necessary changes to IaC and make sure the Terraform plan shows a good and executable plan).
  • If not please remove this feature completely because this will create more confusion on how we are looking for a plan before approving. We are not sure if Terraform apply will replace / update the changes to the Infrastructure or not.
1 Like