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.
Originally reported on Terraform v0.6.11. Reproducible on v0.11.8 + provider.aws v1.17.0
resource "aws_security_group" "default" {
name = "default"
description = "default VPC security group"
vpc_id = "vpc-0c37xxxx" // redacted
tags {
"Name" = "base-default"
"blah:description" = "value"
}
}
Resource gets updated with appropriate tag. Subsequent runs of terraform plan
return an empty plan.
Resource tag does not get updated. Subsequent runs of terraform plan
continue to show unapplied changes.
tags
block where one of the keys has a :
in the name.terraform apply
terraform plan
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
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!
Most helpful comment
cc participants in https://github.com/hashicorp/terraform/issues/5021: @brandongalbraith @joeig @holybit @jaferrando @mildwonkey