feature request: allow tags for ebs_block_device entities within an aws_instance resource

[FlorinAndrei]

I would like to be able to tag the additional volumes that I create attached to new instances. Like this:

resource "aws_instance" "pg02-prod2-useast1-aws" {
    ami = "ami-17fbbc72"
    instance_type = "c4.xlarge"
    key_name = "XXXXXXXXXXXXXXXX"
    subnet_id = "${aws_subnet.prod2-db-b.id}"
    source_dest_check = true
    security_groups = ["${aws_security_group.prod2-pg-instances.id}"]
    ebs_block_device {
      device_name = "/dev/sdf"
      volume_size = 2048
      volume_type = "gp2"
      delete_on_termination = true
      encrypted = false
      tags {
        Name = "pg02-prod2-useast1-aws:/var/lib/postgres"
      }
    }
    tags {
        Name = "pg02-prod2-useast1-aws"
    }
}

[mmmorris1975]

My team relies on ebs volume tags heavily for identifying attachment information, and snapshot management. This would be very helpful for us to add into TF

[astropuffin]

Yes I need this as well.

[jimmystewpot]

This is very useful. There should also be the capability to automatically create tags for the volumes based on the instance tags.

[jkopacze]

Good idea, its clearly a missing feature.

[caarlos0]

👍

[kovyrin]

Would be a great feature. Without it every time we drop an instance with delete_on_termination=false on its root partition (we rely heavily on EBS for root volumes) we end up with a volume that is pretty hard to associate with a particular node...

[endymion00]

+1

[tamsky]

👍

[jkinred]

I'm keen to have a go at this but would appreciate input from @phinze or @jen20 before starting, as this enhancement requires changing the behaviour of the aws_instance resource when tags are specified.

The AWS API BlockDeviceMapping doesn't allow for tags to be set at creation time:
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_BlockDeviceMapping.html
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_EbsBlockDevice.html

The most obvious way for me to implement this is to duplicate the behaviour from the aws_ebs_volume resource, which waits for the volume(s) to become available before setting the tags:
https://github.com/hashicorp/terraform/blob/master/builtin/providers/aws/resource_aws_ebs_volume.go#L115

I'm imagining a similar wait before a call to readBlockDevicesFromInstance and a subsequent setTags call.

Thoughts?

[JulienChampseix]

👍

[rasheedamir]

+1 please add this feature!

[JulienChampseix]

any update on this feature ?

[paultyng]

This would be very useful for me as well. Need to tag these volumes on an instance for billing.

An additional feature that would be nice would maybe just be a flag at the instance level to use the same tags on the instance as on the volumes.

[FlorinAndrei]

@paultyng Global tags are better than nothing, but I'd still like to tag the instance with "hostname", but tag the volumes with "hostname:/mountpoint".

[liammac]

+1 really need this as well

[ljohnston]

+1 extremely important for us!

[nitinsatish]

+1 need this!

[ghost]

+1 need this also. Rather than create a new enhancement, can i also request that this ability (being able to add tags) be added for the root_block_device type also.

[nicolas17]

As far as I can see, setting tags in an "additional" EBS volume is possible by using a separate aws_ebs_volume resource instead of the ebs_block_device argument of the instance (which doesn't devalue this feature request, since doing it directly in ebs_block_device would be pretty handy). However, for the root device it seems there is no way to set tags at all...

[alexraju91]

There should be an option to tag the block device like below irrespective of the global tag feature.

resource "aws_instance" "test" {
...
...
  tags {
      Name = "Instance name"
  }
  root_block_device {
      volume_size = "50"
      tags {
          Name = "volume-tag"
      }
  }
}

[KamilKeski]

From a cost tracking perspective this is huge! I'd like the volumes created for an instance to inherit the tags from the instance.

[dhawal55]

+1. Inherit tags from instance by default as first step and allow override at ebs_block_device as second step.

[ortz]

+1

[fgimian]

Hey there guys, is there any workaround to provide tags for the root volume currently?

Cheers
Fotis

[tamsky]

I haven't tried it, but it seems a possible workaround might be to:

• use a local_exec script to "manually" add the tags

[thearrow]

Would this new AWS feature help with implementing this in terraform?

You now have the ability to specify tags for EC2 instances and EBS volumes as part of the API call that creates the resources (if the call creates both instances and volumes, you can specify distinct tags for the instance and for each volume).

https://aws.amazon.com/blogs/aws/new-tag-ec2-instances-ebs-volumes-on-creation/

[chan-alex]

Yes I need this feature as well

[davebotelho]

+1 I need this feature as well.

[DvirM]

+1
This is needed on our end as well - we would like to be able to filter our usage using the tags, and currently most of the volumes are untagged.
Appreciate the help!

[stumyp]

I think this was implemented in /pull/14007.
now if you use volume_tags block you cans set tags for root EBS
also other attached volumes and it is a mess at the moment, but this is a good start 😄

[stack72]

Yay :) Closed via #14007 - thanks for pointing this out @stumyp :)

[stumyp]

It is related to /issues/14107 though, still having issues with the new behaviour

[stack72]

@stumyp what is the issue you are facing?

[stumyp]

@stack72 I've linked it here for information, will try to replicate the issue with 0.9.5, we should discuss it there, I think.

[toamarnath]

Currently we have 100 instances created without tags using terraform. our requirement is to update tags to ebs_block_device also along with EC2 e.t.c .

When I update terraform to update tags for ebs_block_Device, its throwing error "ebs_block_device.0: invalid or unknown key: tags"

Anyone has work around .

[DvirM]

We wrote a simple script using the AWS SDK that goes over all EBS volumes and if untagged with the tag we want, we look for the instance resource ID and we take the tag from there. for example - if we have a tag "Stack" on the instance and we need it on the EBS volume as well, we're taking the same value from the instance and creating a tag on the untagged EBS.
The script runs in a Cron job and for now is a manageable workaround, until we'll be able to use terraform for it :)

[toamarnath]

DvirM, would you be able to share script in this forum as we are trying to do above step in us-east-2 region

Appreciated...

[DvirM]

Sure - this is Ruby, You'll need to edit the script to make it suit your needs. I'm looking for "Business Unit" and the volume "Name".
I'm using credential file with profiles for each account I'm using in AWS:

require 'json'

profiles = ["", "",.....]   # Add your profiles here for your account
profiles.each do |profile|
	failed = false
	string_response = `aws ec2 describe-volumes --profile #{profile}`
	response = JSON.parse(string_response)
	response["Volumes"].each do |resource|
		begin
			bu_tag = ""
			vol_name = ""
			instanceID = resource["Attachments"][0]["InstanceId"]
			volumeId = resource["Attachments"][0]["VolumeId"]
			vol_name = resource["Tags"].to_a.select {|tag| tag["Key"] == "Name"}[0]["Value"]
			bu_tag = resource["Tags"].to_a.select {|tag| tag["Key"] == "Business Unit"}[0]["Value"]
		rescue Exception => e
			# puts e.message  
			puts "No Business Unit tag for volume #{volumeId} : #{vol_name}"
			# puts e.backtrace.inspect
		end
		puts "Volume BU tag = #{bu_tag}"
		if (instanceID != nil and instanceID != "" and (bu_tag == nil or bu_tag == ""))
			resource_tags = JSON.parse(`aws ec2 describe-tags --filters "Name=resource-id,Values=#{instanceID}" --profile #{profile}`)
			begin
				instance_bu_tag = resource_tags["Tags"].to_a.select {|tag| tag["Key"] == "Business Unit"}[0]["Value"]
				instance_name = resource_tags["Tags"].to_a.select {|tag| tag["Key"] == "Name"}[0]["Value"]
			rescue Exception => e
				# puts e.message  
				puts " Exception in getting the business unit or name from the instance !!!"
				# puts e.backtrace.inspect
			end
			if instance_bu_tag != ""
				puts "Instance BU Tag to Add to volume: #{instance_bu_tag}"
				result = `aws ec2 create-tags --resources #{volumeId} --tags 'Key="Business Unit",Value=#{instance_bu_tag}' --profile #{profile}`
				puts "Added the tag : #{instance_bu_tag} to the volume : #{volumeId}"
			end
			if instance_name != ""
				puts "Adding name to the volume: #{instance_name}"
				result = `aws ec2 create-tags --resources #{volumeId} --tags 'Key="Name",Value=#{instance_name}' --profile #{profile}`
				puts "Added the name tag : #{instance_name} to the volume : #{volumeId}"
			end
		end
	end
end

[Jonnymcc]

https://www.terraform.io/docs/providers/aws/r/instance.html#volume_tags seems to work fine... but it would be nice to have unique tags per ebs_block_device. Would be better if "tags" was an argument to ebs_block_device mappings.

[nick4fake]

Hi,

Thank you guys for the fix.
Is there a way to use it in autoscaling launch configuration?

[anmiles]

+1 to @Jonnymcc
https://www.terraform.io/docs/providers/aws/r/instance.html#volume_tags allows to set the same tags for all block devices.
If there are aws_ebs_volume's -- they will have their own tags but next "apply" will rewrite these tags with single volume_tags.
In the end we'll have the same tags for any block devices that attached to instance.
Does it worth to create a separate issue?

[sumit13587]

+1 to nick4fake

Will be good to allow specifying volume_tags from autoscaling group configuration.
Or a way to specify that the "Name" tag from the instance gets propagated to the attached EBS volumes.

[mr-olson]

Agree with @Jonnymcc and @anmiles - per the original issue description, having a tags block in the *_block_device block of an aws_instance would be much more useful than volume_tags for my use cases, since volume_tags scribbles on all of the attached volumes indiscriminately.

What's the protocol for reopening issues on this project? Or should we file a new one?

[bflad]

@mr-olson as this sounds like an enhancement to a resource in the AWS provider, please feel free to double check for an existing issue and open a new enhancement issue in its repository: https://github.com/terraform-providers/terraform-provider-aws/ -- thanks!

[lucas-dall]

@anmiles i agree, given that many of us have a dynamic infraestructure the use of AutoScaling Groups is pretty common. So we need a feature for setting tags to those volumes. Given that the EC2 on an ASG ar ephemeral is difficult to set tags to those volumes in terraform

[Alifener]

volume_tags is available only for aws_instance resource, is there any plan to add volume_tags to aws_opsworks_instance resource too?

[Spechal]

or a plan to add volume tags to launch configurations?

[trinitronx]

Agree with @Jonnymcc and @anmiles - per the original issue description, having a tags block in the *_block_device block of an aws_instance would be much more useful than volume_tags for my use cases, since volume_tags scribbles on all of the attached volumes indiscriminately.

This is a very good point given the concept of Idempotency in Terraform. When testing the volume_tags setting for aws_instance combined with separate aws_ebs_volume.tags settings for detachable EBS volumes, the terraform plan shows that tags will be overwritten back and forth in an alternating fashion. It appears that this is due to the resource overlap with volume_tags wanting to manage tags across all attached volumes, whereas the more specific tags on each individual aws_ebs_volume are overwritten.

The test case involved launching an aws_instance with a single root_block_device, and volume_tags. Then, adding later 3 aws_ebs_volume & aws_volume_attachment resources to this instance, each with different tags.

Next time you run terraform apply and terraform plan, the aws_ebs_volume tags see that they need to make a new change back. Running this again and again results in Terraform fighting itself for the state of these tags changing back and forth, much like that scene from the old Disney movie "Sleeping Beauty" where the dress color is changed blue, pink, and back again.

[e-moshaya]

@trinitronx I'm having the same issue as you... Did you find a workaround?

[trinitronx]

@e-moshaya : Unfortunately there seems to be no workaround other than to remove volume_tags from the aws_instance resource.

[ghost]

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.