An inverse of ignore_changes or regex support

[mbrancato]

Current Terraform Version

Terraform v0.12.24

Use-cases

The primary use case here is with tags, and the now multitude of apps / tools that have some management responsibility with Cloud and other platforms. Terraform users are left with two main options:

1. Ignore all tags.
2. Ignore specific tags that other tools may modify, add, or remove.

Both have problems. When ignoring all tags, that also means that Terraform will not update tags that Terraform itself created. If only specific tags are ignored, there is the possibility that config drift will be seen if some different management tool adds tags that were not previously known in the Terraform config.

So there is a use case where I as a Terraform user only care about my tags, but want to ignore all others used for internal billing, etc. - even if I don't know what those are or will be in the future.

Attempted Solutions

Proposal

I feel like this could be achieved with an inverse config block that takes precedence over ignore_changes:

always_update = [
  tags["foo"],
  tags["bar"]
]

or by supporting regular expressions:

ignore_changes = [
  tags["/\b(?!foo\b|bar\b)\w+/"]
]

References

[apparentlymart]

Hi @mbrancato! Thanks for this feature request.

Knowing that this is a common situation for tags in particular, the provider teams have started to introduce specific features to represent in a central place that certain tag patterns/prefixes are managed by other software. For example, in the AWS provider configuration you can use an ignore_tags block to specify that tags with the foobar: prefix are not managed by Terraform:

provider "aws" {
  region = "us-west-2"

  ignore_tags {
    key_prefixes = ["foobar:"]
  }
}

Focusing the solution on the specific use-case at hand means that this problem can be solved without waiting for a fully-generalized solution to be designed. ignore_changes is a deceptively complex feature because it interferes with several assumptions in the Terraform workflow, and so it's unlikely we'll be able to make any significant changes to its behavior in the near future.

The tag-specific mechanisms in providers avoid these problems by taking the relevant tags out of consideration by Terraform altogether. That is, rather than having Terraform see them and ignore them, Terraform just never sees them because the provider pretends they don't exist.

If you're using a provider that doesn't yet have a feature like that ignore_tags block in AWS, it's likely that the best path forward in the short term is to open a request with that provider to see if they can implement a feature similar to the one in the AWS provider.

[dpbustos]

@apparentlymart -- it's the opposite use case that is being requested here, it would be to add something like: manage_tags to indicate the tags that are actually being managed... (and therefore be able to ignore anything else)

[mbrancato]

Yes I’m asking for the inverse / opposite of ignore_changes. My problem is basically there are many teams who might have rights to add tags for different purposes. I have no control of how they name them etc. My goal is to allow me to specify the fields I always want to update. My only other option is to try and keep an updated list of tags to ignore, but that list seems to change periodically.

[apparentlymart]

Hi @mbrancato! Thanks for pointing out my misunderstanding.

With that said, I think the most likely path for a feature like this being available in the near future is to request it as an AWS provider feature. They already put the internal infrastructure in place to support ignore_tags, so it seems likely that it would be easier to extend that to support the opposite than to design a radical change in how ignore_changes work in Terraform Core. I can't say for certain that the AWS provider team would be able to prioritize implementing this either (it's an entirely separate team) but I think starting a discussion in a feature request issue in the AWS provider repository would be the best way to find out what they think of it.

[mbrancato]

I’m not using the AWS provider but I understand your point. This was more a long-term enhancement request. Tags are the best use case but so is resource metadata like on Azure storage containers and Google storage objects.