Add option for adding lifecycle clause on tags

[bergrahm]

Me and my team are working with Kops for creating Kubernetes clusters. For Kops to work properly it wants to tag for instance subnets in a certain way. Since the module has a handle for the tags, if we were to run the VPC module again after running Kops that tags the resources it will use, the tags would be overwritten by either the empty map or what we have specified in the module.

To work around this we have temporarily added a module that just parses out all current existing tags and merges in on run. It works as we want, but we think that it feels a bit foul.

I presume that more teams have similar use-cases where external systems would want to tag resources for whatever reason. The following snippet is what we are looking for on our resources.

  lifecycle {
    ignore_changes = [
      tags,
    ]
  }

[bryantbiggs]

Terraform it self does not support this as a dynamic value

[bergrahm]

@bryantbiggs It seems you are correct, been doing some testing this morning. Again, I was able to do a foul solution to work around it. Do you have any comments on why the following may be unwanted? Thanks for taking your time.

variable "ignore_tags_changes" {
  type    = bool
  default = true
}

# Resource without lifecycle ignore_changes
resource "aws_vpc" "test_tags_without_ignore" {
  count = var.ignore_tags_changes ? 0 : 1

  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "test_tags"
  }
}

# Resource with lifecycle ignore_changes
resource "aws_vpc" "test_tags_with_ignore" {
  count = var.ignore_tags_changes ? 1 : 0

  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "test_tags"
  }

  lifecycle {
    ignore_changes = [tags]
  }
}

[bryantbiggs]

yes we have used this type of work around in other modules (RDS, ECS) but not for the trivial use case of ignoring tags. the main downside of this approach is how heavy handed it is - both from a maintenance perspective (maintainers have to ensure all resource replicas are kept in sync) as well as from a usability perspective (its a massive footgun where users can destroy their entire network by changing one variable that seems innocuous).

for now, I think its better to explore alternate approaches outside of what will be modified within this project

[github-actions[bot]]

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.