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.

Sign up for GitHub

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

Jump to bottom

aws_ebs_volume unable to handle "Name" tag #927

Closed
flypenguin opened this issue Jun 21, 2017 · 3 comments · Fixed by #999
Closed

aws_ebs_volume unable to handle "Name" tag #927

flypenguin opened this issue Jun 21, 2017 · 3 comments · Fixed by #999
Assignees
@stack72
Labels
bug Addresses a defect in current functionality.

Comments

@flypenguin
Copy link

I am using aws_ebs_volume to create volumes and attach "Name" tags to them. Unfortunately the resource seems completely oblivious if you remove the tag after volume creation - it will not re-add it.

That in itself would not be a problem, had terraform not removed all our volume tags in version 0.9.5 I think (I guess this bug was fixed, hopefully). But now I still cannot use TF to re-add the tags automatically, since the bug exists at least for two versions.

We are using the tags to trigger certain actions (backups, to be precise) on the volumes, so the existance of those tags is really important to us.

Terraform Version

0.9.8 (and at least two versions before)

Affected Resource(s)

To my knowledge, at least:

  • aws_ebs_volume

Terraform Configuration Files

terraform {}

provider "aws" {
  region = "eu-central-1"
}

resource "aws_ebs_volume" "hashi-test" {
  availability_zone = "eu-central-1a"
  size              = "5"

  tags = {
    Name = "hashi-test"
  }
}

Steps to reproduce

  • run terraform with the config given above (terraform apply)
  • remove the "Name" tag from the created volume from the AWS console or the AWS cli (tested with console)
  • re-run terraform (terraform apply)

Expected Behavior

  • it should attempt to re-add the "Name" tag

Actual Behavior

  • it does not

References

maybe related to
@stack72
Copy link
Contributor

stack72 commented Jun 21, 2017

Hi @flypenguin

Can you tell me if you are using aws_instance volume tags as well?

@flypenguin
Copy link
Author

flypenguin commented Jun 21, 2017 •
edited
Loading

hi @stack72

the volume_tags parameter in the aws_instance resource? no.

and the example is completely self-contained, you can try and reproduce with this.

I use the volumes in another TF project though. originally a data source is responsible for locating the correct volume and then I attach it. I had to change that as well when TF removed all the tags and refused to re-add them.

@stack72 stack72 self-assigned this Jun 29, 2017
stack72 added a commit that referenced this issue Jun 29, 2017
@stack72
resource/aws_ebs_volume: Not setting the state for ebs_volume correctly
a2619e1 
Fixes: #927

When we ran the create, we didn't make a call to the API to Describe the
volume, therefore, we were not actually setting the values to state
based on what the API returned. We also only set the Tags to state if
they were not nil. Therefore, the scenario of someone creating a tag
with Terraform, then removing that tag (and thus no tags are left on the
resource) would mean that Terraform didn't see the state drift:

```
[stacko@Pauls-MBP:~/Code/terraform-org/terraform-recreations/current-working]
% terraform apply
aws_ebs_volume.hashi-test: Creating...
  availability_zone: "" => "eu-central-1a"
  encrypted:         "" => "<computed>"
  iops:              "" => "<computed>"
  kms_key_id:        "" => "<computed>"
  size:              "" => "5"
  snapshot_id:       "" => "<computed>"
  tags.%:            "" => "1"
  tags.Name:         "" => "hashi-test"
  type:              "" => "<computed>"
aws_ebs_volume.hashi-test: Still creating... (10s elapsed)
aws_ebs_volume.hashi-test: Creation complete (ID: vol-01133d4a2d74aa55b)

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

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path:
[stacko@Pauls-MBP:~/Code/terraform-org/terraform-recreations/current-working]
% terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

aws_ebs_volume.hashi-test: Refreshing state... (ID: vol-01133d4a2d74aa55b)
No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, Terraform
doesn't need to do anything.
```

This commit takes care of that but always setting the tags - d.Set handles the empty API response so we should use that:

```
% terraform apply
aws_ebs_volume.hashi-test: Creating...
  availability_zone: "" => "eu-central-1a"
  encrypted:         "" => "<computed>"
  iops:              "" => "<computed>"
  kms_key_id:        "" => "<computed>"
  size:              "" => "5"
  snapshot_id:       "" => "<computed>"
  tags.%:            "" => "1"
  tags.Name:         "" => "hashi-test"
  type:              "" => "<computed>"
aws_ebs_volume.hashi-test: Still creating... (10s elapsed)
aws_ebs_volume.hashi-test: Creation complete (ID: vol-0746b8a7d4f6ac0b5)

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

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path:
[stacko@Pauls-MBP:~/Code/terraform-org/terraform-recreations/current-working]
% terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

aws_ebs_volume.hashi-test: Refreshing state... (ID: vol-0746b8a7d4f6ac0b5)
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

~ aws_ebs_volume.hashi-test
    tags.%:    "0" => "1"
    tags.Name: "" => "hashi-test"

Plan: 0 to add, 1 to change, 0 to destroy.
```
@stack72 stack72 added the bug Addresses a defect in current functionality. label Jun 29, 2017
@stack72 stack72 mentioned this issue Jun 29, 2017
Merged
stack72 added a commit that referenced this issue Jun 29, 2017
@stack72
resource/aws_ebs_volume: Not setting the state for ebs_volume correct…
1450a55 
…ly (#999)

Fixes: #927

When we ran the create, we didn't make a call to the API to Describe the
volume, therefore, we were not actually setting the values to state
based on what the API returned. We also only set the Tags to state if
they were not nil. Therefore, the scenario of someone creating a tag
with Terraform, then removing that tag (and thus no tags are left on the
resource) would mean that Terraform didn't see the state drift:

```
[stacko@Pauls-MBP:~/Code/terraform-org/terraform-recreations/current-working]
% terraform apply
aws_ebs_volume.hashi-test: Creating...
  availability_zone: "" => "eu-central-1a"
  encrypted:         "" => "<computed>"
  iops:              "" => "<computed>"
  kms_key_id:        "" => "<computed>"
  size:              "" => "5"
  snapshot_id:       "" => "<computed>"
  tags.%:            "" => "1"
  tags.Name:         "" => "hashi-test"
  type:              "" => "<computed>"
aws_ebs_volume.hashi-test: Still creating... (10s elapsed)
aws_ebs_volume.hashi-test: Creation complete (ID: vol-01133d4a2d74aa55b)

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

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path:
[stacko@Pauls-MBP:~/Code/terraform-org/terraform-recreations/current-working]
% terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

aws_ebs_volume.hashi-test: Refreshing state... (ID: vol-01133d4a2d74aa55b)
No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, Terraform
doesn't need to do anything.
```

This commit takes care of that but always setting the tags - d.Set handles the empty API response so we should use that:

```
% terraform apply
aws_ebs_volume.hashi-test: Creating...
  availability_zone: "" => "eu-central-1a"
  encrypted:         "" => "<computed>"
  iops:              "" => "<computed>"
  kms_key_id:        "" => "<computed>"
  size:              "" => "5"
  snapshot_id:       "" => "<computed>"
  tags.%:            "" => "1"
  tags.Name:         "" => "hashi-test"
  type:              "" => "<computed>"
aws_ebs_volume.hashi-test: Still creating... (10s elapsed)
aws_ebs_volume.hashi-test: Creation complete (ID: vol-0746b8a7d4f6ac0b5)

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

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path:
[stacko@Pauls-MBP:~/Code/terraform-org/terraform-recreations/current-working]
% terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

aws_ebs_volume.hashi-test: Refreshing state... (ID: vol-0746b8a7d4f6ac0b5)
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

~ aws_ebs_volume.hashi-test
    tags.%:    "0" => "1"
    tags.Name: "" => "hashi-test"

Plan: 0 to add, 1 to change, 0 to destroy.
```
@ghost
Copy link

ghost commented Apr 12, 2020

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!

@ghost ghost locked and limited conversation to collaborators Apr 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@stack72 stack72

Labels
bug Addresses a defect in current functionality.
Projects
None yet
Milestone
No milestone
2 participants
@stack72 @flypenguin