Changing a .tf file from specified tags to variable results in the removal of tags.

[rkulagowski]

I had configured tags on some of my resources by explicitly putting them into the configuration of each element:

tags={
    Owner="rkulagowski"
    Application="test"
}

However, I realized that adding a new key in the future would result in a lot of places that would need to be touched.

So, I created tags in a variables.tf:

variable "tags" {
  default = {
    Owner = "rkulagowski"
    Application = "test"
  }
}

And updated my main.tf:

# Security group to access Redis
resource "aws_security_group" "test-elasticache-redis" {
  description = "Security group to restrict access to Redis"
  name = "test_elasticache_redis"
  tags = {"${var.tags.default}"}

However, a terraform plan changed the number of tags from 2, to 0.

[rkulagowski]

Hrmm. After a terraform destroy and then plan / apply, it appears that the tags aren't being expanded at all anymore, and so all of my tags on the resources that I've been creating are now gone.

[arthurschreiber]

Try the following:

resource "aws_security_group" "test-elasticache-redis" {
  description = "Security group to restrict access to Redis"
  name = "test_elasticache_redis"
  tags {
    Application = "${var.tags.Application}"
    Owner = "${var.tags.Owner}"
  }
}

tags is a block, not an assignable property.

[rkulagowski]

Is there a way to dynamically generate the tags though? If I add a new tag called "Expires" and want to apply it to my resources, then can I do that by updating the "tags" variable in variables.tf, and then have that automagically reflected in the resources without having to create a new tags block that includes "Expires"?

Also, the "tags=" that's at the top of the first ticket works, so tags vs. tags = doesn't seem to be breaking anything.

[apparentlymart]

Hi all!

I'm just looking through some older issues that we've missed on previous issue management passes due to them using an older labeling scheme.

At the time this issue was originally filed, Terraform 0.6 was the latest major release and that didn't have full support for maps, instead faking them at the configuration level as variables named with dot-separated keys. I expect this bug was a result of that older implementation.

What you did here should've been working from 0.7 onwards, since that's when support for real lists and maps was added. There were still some limitations left at that point, but the use-case here (a map of strings) should've been functional.

The forthcoming Terraform v0.12.0 completes this by introducing a full new type system that includes support for maps and lists of any type, and so any remaining issues that were present in 0.11 with this should be addressed.

Although it's true that you can't assign to a nested block using the attribute syntax, tags is actually an attribute argument expecting a map value, so this sort of dynamic construction is possible and valid. @arthurschreiber is right that for nested blocks it was not previously possible to construct them dynamically, although that too is addressed by a new feature coming in v0.12.0 which is discussed more in #7034.

Since the problems this issue was discussing should now be resolved -- if not fully in v0.11 then at least in v0.12 -- I'm going to close this out. Sorry for missing this one on previous updates.

[ghost]

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.