Cannot ignore_changes on specific tags on objects like nsxt_policysegment

[RussPitcher]

Is your feature request related to a problem? Please describe.

We are using tags extensively on our segments to help us programatically find them based on known values. In our terraform code we specify a number of tag scope/value pairs. This works fine until we create an external network in vCloud Director using an NSXT segment. VCD adds a new tag to the NSXT segment with the ID of the external network, presumably to locate the correct segment as we are doing. Unfortunately this means that Terraform them tries to remove the tag that VCD added when we perform another apply. Whilst we can ignore_changes on all tags, we need the ability to change tags in the future.

Describe the solution you'd like

We would like the option to ignore_changes on individual tag scopes. For example:

To ignore changes on a tag with a scope of "SYSTEM" perhaps we could have something like this.

lifecycle {
ignore_changes = {
tag["SYSTEM"]
}
}

This should also allow for the fact that tags specified in the ignore_changes block may not exist in the terraform config. The main aim is for the ability to ignore certain tags that may be managed outside of terraform.

Describe alternatives you've considered

Currently I'm thinking of running a -refresh-only immediately after the apply, them parsing the state file to look for new "SYSTEM" scoped tags and then adding that tag back into the config. Although I can see a number of probable issues with that approach.

Additional context

No response

[annakhm]

Thanks for reporting this issue! We are considering provider-wide definition of tag scopes that should be ignored by terraform. We'd appreciate your feedback on this - is this a good enough solution for your use case? Thank you!

[RussPitcher]

For me, that would be enough. I really just want the ability to specify a scope string that will cause any tags with that string to be ignored on updates. Thanks.

[benzander]

I have exactly the same issue and would like to have the possibility to ignore specific tag scopes.
By the way... the vCD TF Provider has exactly the same issue with his metadata entries:
vmware/terraform-provider-vcd#959

[annakhm]

Thanks for the feedback @RussPitcher and @benzander. We looking into prioritizing this.

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[benzander]

Any News? We still need a feature to ignore specific tags. :-)

[annakhm]

sorry it takes so long @benzander. I'll check if we can accommodate this for 3.7.0. We were considering making this feature generic, but if its specific to tags it shouldn't take long to develop

[benzander]

@annakhm: The reason why we need it for tags is the Cloud Director Integration. I create objects with the NSX TF Provider and set tags to them. Then I import those to VMware Cloud Director and vCD adds its own tags which NSX-T TF Provider wants to remove later.

I like the Idea to have such a feature generic. We could also replace a tag specific ignore feature against a generic feature later if you still want to do it that way.

[annakhm]

Hi @RussPitcher, @benzander - it would help us to identify a list of objects where this feature is relevant.
Also, would you prefer regexp match, or just string comparison for the scope is good enough?

[benzander]

Hi @RussPitcher, @benzander - it would help us to identify a list of objects where this feature is relevant. Also, would you prefer regexp match, or just string comparison for the scope is good enough?

I noticed this conflict between NSX-T TF Provider and vCD only with segments.
Exclude just the scope with a string comparison would be enough for me. Today I don't see any more requirements.