Ignore drift, enforce changes

[hobbyhorse]

Terraform Version

Terraform v1.9.1
on darwin_arm64

Use Cases

There will be other applications of the idea, but in our case we need to be able to scale resources outside of terraform, and have terraform ignore the scaling that we did. This is easy enough with the ignore_changes lifecycle, but we also want terraform to make scaling changes if we update the terraform code to scale.

So, if we scaled via the AWS console, then ignore it. If we scale via the code, perform it.

The normal argument would be that all changes should be via terraform as that is the pattern it was designed for, but our terraform pipelines are wrapped in layers of approvals and checks which mean that they are much too slow for certian scenarios. However, we do not want whatever scaling we do outside of terraform to be reversed unless we specifically change the resource numbers/sizes in terraform.

Attempted Solutions

We have attempted ignore_changes but it applies to every kind of change, not just drift.

Proposal

I would like a new lifecycle option ignore_drift which does what it says on the can. Ignore drift, but enforce code changes. This should be possible based on what I understand about the state, but I could be wrong.

References

No response

[crw]

Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!

[jbardin]

Hi @hobbyhorse,

Terraform doesn't really have a concept of "drift" to begin with, so that might be part of the confusion. Terraform does note when changes have been made outside of Terraform by comparing the last known state to the current state, but the differences in those values are not available to Terraform during the planning process, and not exposed as a concept in the configuration language.

Can you explain a little more about what it would mean to ignore the drift, but also enforce those changes?

The closest configuration construct we have is ignore_changes as you've mentioned, but what exactly would a new construct do differently? The only comparison made in Terraform while planning is between the current state and the desired state from the configuration. We can either accept changes based on the configuration, or keep the existing value from the current state via ignore_changes. Since the "drifted" values would already be part of the current state, and ignore_changes would keep those values, what would ignore_drift do differently in this situation?

Thanks!

[hobbyhorse]

I guess I was wrong about how the state works. I thought that the state tracked what was last applied. This would mean that the state would be able to tell when a template had changed, and so apply the change. It would also be able to tell that while a particular real world resource had drifted, it should be ignored since the change had not come from a template.

[jbardin]

Thanks @hobbyhorse. So if I understand correctly, what you mean by "enforce changes" is that you would only want to apply changes when the config itself has changed? That isn't something you can determine via the remote state alone, it would also require Terraform to track multiple versions of the configuration for comparison, which Terraform was not designed to do. While there are a few niche cases where tracking configuration might be helpful, none so far have warranted the additional complexity required.

[hobbyhorse]

It is possible that I am still not fully understanding everything, but it looks to me like it would be possible to implement this without multiple versions of the configuration by making the state track the properties tagged with ignore_drift differently. They could entirely ignore the real world and just leave them always only tracking the configuration. That way if the real world is changed, nothing happens, and if the configuration changes then the state notices and changes the real world too. If the change to the real world succeeds, then update the state for that property, if it fails, leave it as it was. However, it may not be desirable to change how the state works, but given that the change would only affect targeted properties, maybe it would not have much of a blast radius.

[jbardin]

Thanks, I think I was thrown off by the "enforce changes" aspect, but it sounds more like what you want to do is selectively freeze part of the state, such that it won't be refreshed by the provider. It's actually a common misconception that ignore_changes does this, because it can appear to result in the same behavior a lot of the time, though they are subtly different. We've considered the idea before, but we didn't have enough of a use case to demand a slightly different version of ignore_changes. I don't see an existing issue though, so we can track it here.

The idea on its own is still a little problematic, in that as part of the protocol we guarantee Terraform returns to the provider exactly what the provider stored in the state. It also comes with the same language problems that ignore_changes currently has, where we need static addresses and can't deal with multiple objects within containers, especially within sets. The protocol problem may require some larger changes to make it feasible, while the language problem is more of a note about known limitations, and to keep it in mind for any future ideas for something better than `ignore_changes.

Thanks!