aws_s3_bucket ignore_changes [ "bucket" ] broken

[gozer]

Very easy to reproduce on master. First apply will work, subsequent applies will not.

Terraform v0.6.15-dev (1b1e462)

resource "aws_s3_bucket" "uuid-test" {
  bucket = "gozer-test-${uuid()}"

  lifecycle {
  ignore_changes = [
      "bucket",
    ]
  }
}

$> terraform plan
[...]
~ aws_s3_bucket.uuid-test
    force_destroy: "true" => "0"

$> terraform apply
[...]

Error applying plan:

2 error(s) occurred:                                                                                                                                                                                              

* aws_s3_bucket.uuid-test: diffs didn't match during apply. This is a bug with Terraform and should be reported as a GitHub Issue.

Please include the following information in your report:

    Terraform Version: 0.6.15
    Resource ID: aws_s3_bucket.uuid-test
    Mismatch reason: diff: Destroy; old: false, new: true
    Diff One (usually from plan): *terraform.InstanceDiff{Attributes:map[string]*terraform.ResourceAttrDiff{"force_destroy":*terraform.ResourceAttrDiff{Old:"true", New:"0", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}}, Destroy:false, DestroyTainted:false}
    Diff Two (usually from apply): *terraform.InstanceDiff{Attributes:map[string]*terraform.ResourceAttrDiff{"hosted_zone_id":*terraform.ResourceAttrDiff{Old:"Z3BJ6K6RIION7M", New:"", NewComputed:true, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}, "website_endpoint":*terraform.ResourceAttrDiff{Old:"", New:"", NewComputed:true, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}, "acl":*terraform.ResourceAttrDiff{Old:"private", New:"private", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}, "force_destroy":*terraform.ResourceAttrDiff{Old:"true", New:"0", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}, "region":*terraform.ResourceAttrDiff{Old:"us-west-2", New:"", NewComputed:true, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}, "arn":*terraform.ResourceAttrDiff{Old:"arn:aws:s3:::gozer-test-794a5edb-3c4d-b9ef-20c8-7cab044f7e3f", New:"", NewComputed:true, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}, "website_domain":*terraform.ResourceAttrDiff{Old:"", New:"", NewComputed:true, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}}, Destroy:true, DestroyTainted:false}

[gozer]

I suspect it's realted to #5627

[stack72]

Hi @gozer

I believe we have fixed this since Terraform 0.7 release. I used your config as follows:

resource "aws_s3_bucket" "uuid-test" {
  bucket = "gozer-test-${uuid()}"

  lifecycle {
  ignore_changes = [
      "bucket",
    ]
  }
}

The first plan and apply looked as follows:

[stacko@Pauls-MacBook-Pro:~/Code/terraform-recreations/5911]
% 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.


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_s3_bucket.uuid-test
    acceleration_status: "<computed>"
    acl:                 "private"
    arn:                 "<computed>"
    bucket:              "gozer-test-3c5966bd-deae-235f-cf35-24a092c3b105"
    force_destroy:       "false"
    hosted_zone_id:      "<computed>"
    region:              "<computed>"
    request_payer:       "<computed>"
    website_domain:      "<computed>"
    website_endpoint:    "<computed>"


Plan: 1 to add, 0 to change, 0 to destroy.
[stacko@Pauls-MacBook-Pro:~/Code/terraform-recreations/5911]
% terraform apply
aws_s3_bucket.uuid-test: Creating...
  acceleration_status: "" => "<computed>"
  acl:                 "" => "private"
  arn:                 "" => "<computed>"
  bucket:              "" => "gozer-test-bc42a3a8-b0e7-b9f4-bfb8-df0e3ec0a588"
  force_destroy:       "" => "false"
  hosted_zone_id:      "" => "<computed>"
  region:              "" => "<computed>"
  request_payer:       "" => "<computed>"
  website_domain:      "" => "<computed>"
  website_endpoint:    "" => "<computed>"
aws_s3_bucket.uuid-test: Still creating... (10s elapsed)
aws_s3_bucket.uuid-test: Creation complete

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: terraform.tfstate

So the next plan looks as follows:

[stacko@Pauls-MacBook-Pro:~/Code/terraform-recreations/5911]
% 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_s3_bucket.uuid-test: Refreshing state... (ID: gozer-test-bc42a3a8-b0e7-b9f4-bfb8-df0e3ec0a588)

No changes. Infrastructure is up-to-date. This means that Terraform
could not detect any differences between your configuration and
the real physical resources that exist. As a result, Terraform
doesn't need to do anything.

Then a final apply looks as following:

[stacko@Pauls-MacBook-Pro:~/Code/terraform-recreations/5911]
% terraform apply
aws_s3_bucket.uuid-test: Refreshing state... (ID: gozer-test-bc42a3a8-b0e7-b9f4-bfb8-df0e3ec0a588)

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

I believe this is looking better now :) Please recomment on the issue if this is still an issue for you

Thanks

Paul

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