Terraform: How do i add tag variables to aws_autoscaling_group resource?

[babatundebusari]

terraform 0.9.8

I have some tags declared in variables

tags = {
       "name" = "robotr",
       "title" = "engineer",
       "location" = "paris",
       "platform" = "cloud",
       "environment" = "prod"
}

and i will like to add these tags to aws_autoscaling_group resource

but when i add inside of the resource like this

tags = "${merge(var.tags, map("Name", format("%s", var.name)))}"

i get the following errors

... tags: should be a list

Is it possible to add tags from variable to aws_autoscaling_group resource?

Thanks

[alexsomesan]

The error message is pointing in the right direction: this attribute should be set with a list.

However, merge(..) returns a map, so that is the first problem you're hitting there.
Next, tags expects a list of maps, each with the following structure:

tag = [
  {
    "key" = "name"
    "value" = "robotr"
    "propagate_at_launch" = <boolean_value>
  },
  {
    "key" = "title"
    "value" = "engineer"
    "propagate_at_launch" = <boolean_value>
  },
]

So in order to satisfy that format you need to transform your input variable to the format I've shown above.

Then, you would use:

tags = ["${
concat(
  var.tags,
  list(
    map(
      "key", "Name",
      "value", var.name,
      "propagate_at_launch", true
    )
  )
)
}"]

to set the tags attribute like you wanted.

Hope this clarifies things a bit.

[babatundebusari]

@alexsomesan

The input variable format you mentioned

tags = ["${
concat(
  var.tags,
  list(
    map(

  "key", "Name",

      "value", var.name,
      "propagate_at_launch", true
    )
  )
)
}"]

How will the key map the different values? You only put Name in above
You get my question here right?

[andrelohmann]

Hi there, the last question of @babatundebusari doesn't seem to be answered so far. I came across the same problem now, and also have no answer how to solve it. Can anyone give a hint here?

[jensbodal]

My current understanding is that this is not possible through terraform alone. You'd need to use a script to generate the file. Terraform doesn't have great loop support, and the only thing that can be "looped" through are resources (using count). If there was a propagate_tag resource we could use or something like that it might be, but after giving this a go I ended up just using a locals variable to populate the tag.

locals {
  ec2_tags = [
    {
      key = "Foo"
      value = "${data.aws_ssm_parameter.foo.value}"
      propagate_at_launch = true
    },
    {
      key = "Bar"
      value = "${data.aws_ssm_parameter.bar.value}"
      propagate_at_launch = true
    }
  ]
}

You could take the above approach and write a script to populate this. Tags that are populated through pure maps are easy to do using merge.

[mxlan]

Is the need to surround a list object with "[]" a limitation on go-lang or the implementation? I thought that list() or concat() should return the expected type following the Interpolation documentation but I guess instead it's interpreted as the interface in this case? I'm not too clear on the cause for the confusion since I've also just run into this syntax issue as well.

Would you be able to point us to the documentation that mentions this gotcha?

For example:

  tags = ["${concat(null_resource.shared_asg_tags.*.triggers,
             list(
               map("key", "Name",
                   "value", "Tag_sample",
                   "propagate_at_launch", "false"),
               map("key", "Autoscaling",
                   "value", "True",
                    "propagate_at_launch", "true")
              ))}"]

vs

  tags = "${concat(null_resource.shared_asg_tags.*.triggers,
             list(
               map("key", "Name",
                   "value", "Tag_sample",
                   "propagate_at_launch", "false"),
               map("key", "Autoscaling",
                   "value", "True",
                    "propagate_at_launch", "true")
              ))}"

Coming from a java or python background this is rather odd to think about, As I would imagine the first way to resolve to a list containing a single list item with map items but it's clearly not when I run the terraform validate, plan, and apply.

null_resource_asg_tags.*.triggers, being a list of maps as well.

[msvechla]

I have the same issue. Is there a specific reason, why the tags format is different for aws_autoscaling_group and aws_instance ?

[red8888]

I have a shared map of tags, I'd like to not have to duplicate it for asg resources. Is there a way to transform the tags map into one the asg resource can use?

[SinghDivneet]

Can someone direct me to correct syntax ?

[red8888]

to convert regular tags map to asg tags map (sorry forgot who I stole this snippet from!)

data "null_data_source" "asg-tags" {
  count = "${length(keys(var.tags))}"
  inputs = {
    key                 = "${element(keys(var.tags), count.index)}"
    value               = "${element(values(var.tags), count.index)}"
    propagate_at_launch = "true"
  }
}

resource "aws_autoscaling_group" "my-group" {
  ....
  tags = ["${data.null_data_source.asg-tags.*.outputs}"]

[benderillo]

@red8888 thank you, sir.
@radeksimko Honestly, this should be better reflected in the official documentation. Current doc is not very helpful, especially for someone who is not a terraform ninja. Or addressed otherwise.

I assume, it is not uncommon to have a set of standard tags that reflect project, environment or billing purpose and are global to entire infrastructure. And those are defined in one place, and usually in "key": "value" format.

Not being able to propagate them to "autoscaling_group" in a straightforward way due to format mismatch is a bummer.

Could it have been solved by having two maps of tags on the "aws_autoscaling_group" resource?

Say:

tags = {}
propagate_at_launch_tags = {}

This way there will be no need for two tag formats at all, less pain and more happiness in the world :)

[hashibot[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.