Add ability to ignore tags not set via the various azurerm resource blocks

[dpbustos]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Add ability to ignore tags not set via the various azurerm resource blocks.

At the least, add the ability to be able to specify tag key's which ARE under management and to ignore changes on any other tag key that may be encountered. (This would be the opposite of the ignore_tags block functionality for the AWS provider, by having both an ignore and manage option, like a allow/block list, working together might give the most flexibility.)

New or Affected Resource(s)

All resources with the tags property.

Potential Terraform Configuration

Option 1 - Add a boolean flag to each resource to be able to ignore changes to tags not deliberately set by the resource, e.g.:

resource "azurerm_resource_group" "example" {
  name     = "example"
  location = "West Europe"
  tags = {
    foo = "bar"
  }
  ignore_unmanaged_tags = true
}

Option 2 - Add ability to add set of managed tag keys on the provider block (and to ignore changes made on any other keys), e.g.:

provider "azurerm" {
  features = {}

  managed_tags {
    key_prefixes = ["foo"]
  }
}

References

Related Issues:

• An inverse of ignore_changes or regex support terraform#24908
• Ignore changes for a single AWS Resource Tag terraform#6632

[markslater]

Perhaps it could work like this similar change that was implemented recently for the AWS provider?

As it stands, thanks to my organisation's decision to add several tags at the subscription level, every one of my Terraform resources has a lengthy list of fake values for tags, plus an equivalent list in the ignore_changes. For many resources, the actual definition is swamped by the tag ignoring boilerplate, which is unfortunate (maybe there's a simpler way of doing this I've missed).

[sennerholm]

A simular use case that would be good to support is the possibility to:

resource "azurerm_resource_group" "example" {
  name     = "example"
  location = "West Europe"
  tags = {
    foo = "bar"
  }
  lifecycle {
    ignore_changes = [tags.changedbyui]
  }
}

So the provider should ignore changes to the tag changedbyui.
At least I can't get this working in 2.25.0 of the provider, but that's maybe more of a bug?
Inspired by: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/resource-tagging#ignoring-changes-in-individual-resources

[gplusplus314]

This is will eventually be a blocker for my organization, so I may be able to spend some time implementing this. I think we'll be better off mimicking the existing functionality and syntax from the AWS provider, as pointed out by @markslater , rather than trying something new. The AWS folks have already battle tested the pattern, so that's the route I'll take, unless we have some strong objections.

[tombuildsstuff]

hey @dpbustos

Thanks for opening this issue.

Taking a look through here whilst there's a couple of approaches suggested above, were we to add support for this we'd likely do this closer to the AWS model of using "default tags" on the provider block than ignoring prefixes (or all tags entirely). Support for that is being tracked in #11682 - as such whilst this issue has more 👍, since #11682 is a more focused feature request I'm going to close this issue in favour of #11682, would you mind subscribing to that issue for updates?

It's worth noting that whilst tags in are generally more consistent in Azure than in AWS, there's a similar number of "got-ya's" - insofar as resources which have different constraints on their tags (for example some resources can only have 15 character keys, some API's don't track changes to values if the casing doesn't change whilst others do, some only allow lower-case/certain characters) - so whilst this is technically possible this still requires investigation to confirm that's the best approach here.

As mentioned above whilst I'd like to thank you for opening this issue, I'm going to close this issue in favour of #11682 - so please subscribe to that issue for updates.

Thanks!

[dpbustos]

Ok thanks @tombuildsstuff , I'll track that issue and thanks for letting me know

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.