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

provider default tags aren't applied to root block devices #19890

Closed
rvandegrift opened this issue Jun 18, 2021 · 15 comments · Fixed by #33769
Closed

provider default tags aren't applied to root block devices #19890

rvandegrift opened this issue Jun 18, 2021 · 15 comments · Fixed by #33769
Assignees
Labels
enhancement Requests to existing resources that expand the functionality or scope. service/ec2 Issues and PRs that pertain to the ec2 service.
Milestone

Comments

@rvandegrift
Copy link

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
@github-actions github-actions bot added needs-triage Waiting for first response or review from a maintainer. service/ec2 Issues and PRs that pertain to the ec2 service. labels Jun 18, 2021
@ewbankkit
Copy link
Contributor

@ewbankkit ewbankkit added enhancement Requests to existing resources that expand the functionality or scope. and removed needs-triage Waiting for first response or review from a maintainer. labels Jun 18, 2021
@devopsrick
Copy link

devopsrick commented Aug 20, 2021

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

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.

@hikerspath
Copy link

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.

@tom-ph
Copy link

tom-ph commented Nov 29, 2022

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.

@nantiferov
Copy link
Contributor

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

@devopsrick
Copy link

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

@mmoreno2
Copy link

mmoreno2 commented Jul 3, 2023

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

@j3mdamas
Copy link

j3mdamas commented Aug 4, 2023

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
  . . . 
}

@autotune
Copy link
Contributor

autotune commented Oct 3, 2023

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

@autotune
Copy link
Contributor

autotune commented Oct 3, 2023

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

autotune commented Oct 5, 2023

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.

@csrl
Copy link

csrl commented Jan 3, 2024

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

@YakDriver YakDriver self-assigned this Feb 15, 2024
@terraform-aws-provider terraform-aws-provider bot added the prioritized Part of the maintainer teams immediate focus. To be addressed within the current quarter. label Feb 15, 2024
@github-actions github-actions bot added this to the v5.39.0 milestone Feb 29, 2024
@github-actions github-actions bot removed the prioritized Part of the maintainer teams immediate focus. To be addressed within the current quarter. label Mar 1, 2024
Copy link

github-actions bot commented Mar 1, 2024

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!

Copy link

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 github-actions bot locked as resolved and limited conversation to collaborators Mar 31, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement Requests to existing resources that expand the functionality or scope. service/ec2 Issues and PRs that pertain to the ec2 service.
Projects
None yet
Development

Successfully merging a pull request may close this issue.