terraform-provider-aws icon indicating copy to clipboard operation
terraform-provider-aws copied to clipboard

provider default tags aren't applied to root block devices

Open rvandegrift opened this issue 4 years ago • 6 comments

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 other comments that do not add relevant new information or questions, 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

Terraform CLI and Terraform AWS Provider Version

$ terraform -v
Terraform v0.14.6
+ provider registry.terraform.io/hashicorp/aws v3.46.0

Affected Resource(s)

  • aws_instance

Terraform Configuration Files

Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.

provider "aws" {
  region = "us-west-2"

  default_tags {
    tags = {
      wooo = "yeah"
    }
  }
}

data "aws_ami" "debian_buster" {
  most_recent = true
  owners      = ["136693071363"]

  filter {
    name   = "name"
    values = ["debian-10-amd64-*"]
  }
}

resource "aws_instance" "example" {
  ami           = data.aws_ami.debian_buster.id
  instance_type = "t3.micro"

  tags = {
    Name = "heyy"
  }
}

Expected Behavior

ec2 instance root volumes should have default tags applied.

Actual Behavior

The ebs device created for the root volume did not get the default tags:

$ terraform state show aws_instance.example
resource "aws_instance" "example" {
    ...
    root_block_device {
        delete_on_termination = true
        device_name           = "/dev/xvda"
        encrypted             = true
        iops                  = 100
        kms_key_id            = "arn:aws:kms:us-west-2:012345678901:key/1e99b441-f5a0-4bfa-b772-eb0b5ae926cc"
        tags                  = {}
        throughput            = 0
        volume_id             = "vol-00646f0d935e22e7d"
        volume_size           = 8
        volume_type           = "gp2"
    }
$ aws ec2 describe-tags --filters Name=resource-id,Values=vol-00646f0d935e22e7d
{
    "Tags": []
}

Steps to Reproduce

  1. terraform apply
  2. check the resulting ebs volume tags

rvandegrift avatar Jun 18 '21 17:06 rvandegrift

Related:

  • #19188

ewbankkit avatar Jun 18 '21 20:06 ewbankkit

Since it has been deemed that volume_tags is incompatible with root_block_device and ebs_block_device tag usage, perhaps it would be better to revisit default_tags interacting with those two? volume_tags are much more complicated as they apply to root_block ebs_block AND attached aws_ebs_volume resources, of which only the last get default_tags.

devopsrick avatar Aug 20 '21 13:08 devopsrick

Any plans to implement default_tags for ebs/root block devices? This is making tagging enforcement quite complicated and slowing our adoption of default_tags.

devopsrick avatar Mar 09 '22 08:03 devopsrick

For anyone dealing with this, I found a decent way around this issue without having to re-define tags:

resource "aws_ec2_tag" "root_block_device" {
  for_each = merge({ for name, value in aws_instance.example.tags_all :
                       name => value
                     if name != "Name" }, 
                   { Name = "example-root" })
  resource_id = aws_instance.example.root_block_device[0].volume_id
  key         = each.key
  value       = each.value
}

I have allowed for a customized Name tag for the root block if you don't want that ability just remove it, should still work.

hikerspath avatar Jul 21 '22 12:07 hikerspath

Do you have updates? Today we found out that 10% of our yearly AWS costs are unlabeled because of untagged EBS volumes when using the tags_all on the provider. I think this should be considered a bug. Maybe while waiting for a fix the docs could be explicit about this behavior.

tom-ph avatar Nov 29 '22 21:11 tom-ph

We ended up fetching default tags via this datasource https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/default_tags and then merging them on root_block_device in resource "aws_instance"

Similar way like it's done in terraform-aws-eks module https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/modules/self-managed-node-group/main.tf#L5

nantiferov avatar Nov 30 '22 07:11 nantiferov

Is this being included in the 5.0.0 roadmap? This feature is really important for cost tracking.

devopsrick avatar May 04 '23 09:05 devopsrick

Has this been resolved? I am still seeing the default tags not being applied to the root device on aws version 5.6.2.

mmoreno2 avatar Jul 03 '23 18:07 mmoreno2

I faced the same issue and second all the requests. What I have done to work around it was use the aws_default_tags data source together with the volume_tags argument of the aws_instance resource.

Something like:

data "aws_default_tags" "foo" {}
resource "aws_instance" "instance" {
  volume_tags = data.aws_default_tags.foo.tags
  . . . 
}

j3mdamas avatar Aug 04 '23 10:08 j3mdamas

I am volunteering to look into this issue, issue number 6 of my 100 days of Terraform contributions challenge.

autotune avatar Oct 03 '23 12:10 autotune

You can select resource type and add tags by resource type, e.g. volume, in the GUI. The question is whether you can do this via API call. There is a CreateTags function https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/ec2#Client.CreateTags, so now the question becomes how to implement it as part of the instance creation process to a volume. Not going to comment anymore until this work is complete just saying it should be doable and I'm expecting to get this done within the next few days if not sooner.

autotune avatar Oct 03 '23 12:10 autotune

PR is pending, I'd like to have a quick conversation with you all about how terraform behavior will be handled with this one. Let's say we have the following code:

provider "aws" {
  region = "us-west-2"

  default_tags {
    tags = {
      Name = "bears"
    }
  }
}

resource "aws_instance" "example2" {
  ami           = data.aws_ami.debian_buster.id
  instance_type = "t3.micro"

  root_block_device {
    tags = {
      foo  = "bar"
    }
  }
}

Name = bears and foo = bar will successfully be added to the root block device. You can modify them as expected too, HOWEVER, terraform will always want to destroy the tags that get added to the root block device. It will fail to do so. So you would have a plan that always looks like this:

  ~ resource "aws_instance" "example2" {
        id                                   = "i-03eb86f4a5937a029"
        tags                                 = {}
        # (31 unchanged attributes hidden)

      ~ root_block_device {
          ~ tags                  = {
              - "Name" = "bears" -> null
                "foo"  = "bar"
            }
            # (8 unchanged attributes hidden)
        }

        # (7 unchanged blocks hidden)
    }

Because Name is a default tag. The fix would be to add the default tag to root block device tags, but I recognize this kind of defeats the purpose of what you all are looking for. What are your thoughts? Again, the apply will not successfully apply the change even though it would be a successful apply, it would be a permanent bug/feature. Just depends on what the community thinks.

autotune avatar Oct 05 '23 01:10 autotune

as it does everywhere else, it should merge default_tags with the root_block_device.tags of the same name taking precedence.

csrl avatar Jan 03 '24 06:01 csrl

This functionality has been released in v5.39.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

github-actions[bot] avatar Mar 01 '24 00:03 github-actions[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.

github-actions[bot] avatar Mar 31 '24 02:03 github-actions[bot]