Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
rkulagowski opened this issue Jan 15, 2016 · 5 comments

Comments

@rkulagowski
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link

ghost commented Mar 31, 2020

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.

@ghost ghost locked and limited conversation to collaborators Mar 31, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants