Terraform-provider-aws: provider/aws: colon character rejected when used with `tags`

Created on 23 Aug 2018  ยท  14Comments  ยท  Source: hashicorp/terraform-provider-aws

I'm still encountering this issue: https://github.com/hashicorp/terraform/issues/5021 though in my case I'm seeing it with security groups.

When using the tag block with the aws_autoscaling_group resource, I'm able to specify tags in the following format:

tag {
  key = "blah:description"
  value = "Instances for whatever."
  propagate_at_launch = true
}

It appears that the tag block cannot be used with the aws_instance resource though.

tags {
  "blah:description" = "value"
}

When I attempt to use the tags block with aws_instance, and specify a key with a colon character (:) in it, I receive and error about an invalid character. I have attempted to specify the key with the semicolon both quoted and unquoted.

Community Note

  • Please vote on this issue by adding a ๐Ÿ‘ reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Originally reported on Terraform v0.6.11. Reproducible on v0.11.8 + provider.aws v1.17.0

Affected Resource(s)

  • aws_autoscaling_group
  • aws_security_group
  • likely others as well

Terraform Configuration Files

resource "aws_security_group" "default" {
  name = "default"

  description = "default VPC security group"

  vpc_id = "vpc-0c37xxxx" // redacted

  tags {
    "Name" = "base-default"
    "blah:description" = "value"
  }
}

Expected Behavior

Resource gets updated with appropriate tag. Subsequent runs of terraform plan return an empty plan.

Actual Behavior

Resource tag does not get updated. Subsequent runs of terraform plan continue to show unapplied changes.

Steps to Reproduce

  1. Create a resource with a tags block where one of the keys has a : in the name.
  2. terraform apply
  3. terraform plan

References

original issue on the old repo: https://github.com/hashicorp/terraform/issues/5021

Likely related to https://github.com/terraform-providers/terraform-provider-aws/issues/3466

bug servicec2

Most helpful comment

cc participants in https://github.com/hashicorp/terraform/issues/5021: @brandongalbraith @joeig @holybit @jaferrando @mildwonkey

All 14 comments

cc participants in https://github.com/hashicorp/terraform/issues/5021: @brandongalbraith @joeig @holybit @jaferrando @mildwonkey

Hi folks, we are also experiencing this issue. This blocks moving to our new scalable deployment architecture which relies on terraform to return 0 changes when there are no actual changes. Are there any workarounds or may be pointers how to fix it quickly in Go code, so we can contribute?

Also, this is especially annoying as some of the AWS services set those tags with colons explicitly and we cannot avoid using them, thus we always have some of the services present in terraform plan which is not what we would be expecting.

Thanks for any help.

Terraform should support all the allowable characters for keys and values. Does anyone have a pull request on this?

bumping this, it's been almost a year since original bug submission, any chance on this bug being addressed soon?

Am I also hitting the same issue.

Same

it would be definitely nice to have feature.

CloudFormation loves to vomit out these tag names with colons. It's making my mapping and bootstrapping rather annoying.

Hi folks ๐Ÿ‘‹ I'm not able to reproduce this with the following self-contained configuration similar to the original report (neither Terraform 0.11.8, 0.11.14, nor 0.12.2):

terraform {
  required_providers {
    aws = "2.15.0"
  }
  required_version = "0.12.2"
}

provider "aws" {
  region = "us-east-2"
}

resource "aws_vpc" "test" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_security_group" "test" {
  vpc_id = aws_vpc.test.id

  tags = {
    Name               = "test"
    "blah:description" = "value"
  }
}
$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_security_group.test will be created
  + resource "aws_security_group" "test" {
      + arn                    = (known after apply)
      + description            = "Managed by Terraform"
      + egress                 = (known after apply)
      + id                     = (known after apply)
      + ingress                = (known after apply)
      + name                   = (known after apply)
      + owner_id               = (known after apply)
      + revoke_rules_on_delete = false
      + tags                   = {
          + "Name"             = "test"
          + "blah:description" = "value"
        }
      + vpc_id                 = (known after apply)
    }

  # aws_vpc.test will be created
  + resource "aws_vpc" "test" {
      + arn                              = (known after apply)
      + assign_generated_ipv6_cidr_block = false
      + cidr_block                       = "10.0.0.0/16"
      + default_network_acl_id           = (known after apply)
      + default_route_table_id           = (known after apply)
      + default_security_group_id        = (known after apply)
      + dhcp_options_id                  = (known after apply)
      + enable_classiclink               = (known after apply)
      + enable_classiclink_dns_support   = (known after apply)
      + enable_dns_hostnames             = (known after apply)
      + enable_dns_support               = true
      + id                               = (known after apply)
      + instance_tenancy                 = "default"
      + ipv6_association_id              = (known after apply)
      + ipv6_cidr_block                  = (known after apply)
      + main_route_table_id              = (known after apply)
      + owner_id                         = (known after apply)
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_vpc.test: Creating...
aws_vpc.test: Creation complete after 2s [id=vpc-0dc59749333edce8e]
aws_security_group.test: Creating...
aws_security_group.test: Creation complete after 1s [id=sg-0d812c66ba3a8d947]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

$ terraform apply
aws_vpc.test: Refreshing state... [id=vpc-0dc59749333edce8e]
aws_security_group.test: Refreshing state... [id=sg-0d812c66ba3a8d947]

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Can someone please provide a self-contained reproducing configuration that demonstrates this issue along with their Terraform and Terraform AWS Provider versions? Thanks.

This problem only with terraform 0.12, when I use quotes for the tag keys then it says:
Error: Invalid argument name
....
"Argument names must not be quoted."

Hi @htrappmann ๐Ÿ‘‹ In Terraform 0.12, the Terraform configurations for almost all AWS resources (except the aws_autoscaling_group resource) should declare tags arguments with an equals sign (=) after the word tags e.g.

resource "aws_XXX" "example" {
  # ... other configuration ...

  tags = {
    "examplekey1" = "examplevalue1"
  }
}

Sometimes the configuration language parsing will flag the Argument names must not be quoted. error instead of the real error that is fixed with a change like the above. If you are performing an upgrade from Terraform 0.11, the terraform 0.12upgrade command in the Terraform 0.12 Upgrade Guide should catch these (see also the Attributes vs Blocks section for more details about this particular configuration language change in 0.12). For improvements with this particular error message or the upgrade command, please file an issue upstream in Terraform Core.


To remain on topic with this particular issue, we are still waiting for a self-contained reproducing configuration that demonstrates this issue along with their Terraform and Terraform AWS Provider versions.

Thanks a lot, @bflad !

Hi folks ๐Ÿ‘‹

Since we have not been provided a self-contained reproducing configuration that demonstrates this issue along with the Terraform and Terraform AWS Provider versions, I'm going to close this issue. If you're still having this problem, please feel free to open a new issue and complete all of the information requested in the Bug Report template so that we can attempt to understand and reproduce the problem. Thanks.

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!

Was this page helpful?
0 / 5 - 0 ratings