Terraform-provider-aws: Variable changes from TF 0.11 have affected functionality - not in changelog

[myoung34]

Terraform Version

0.10.6

Affected Resource(s)

anything inside of a module, possibly any resource using default = ""

Terraform Configuration Files

variables.tf:

 42 variable "private_ip" {
 43   default = ""
 44 }

main.tf

 81 resource "aws_instance" "main" {
...snip...
 94   private_ip             = "${var.private_ip}"
...snip...

Expected Behavior

Running apply multiple times would not change the resource

Actual Behavior

Running apply wants to remove/create the resource on every apply due to it thinking that private ip has changed and wants to recreate it

Steps to Reproduce

$ rm -rf .terraform; terraform init >/dev/null; cat *.tf | grep -E 'provider..aws' -A 1; terraform plan -var staging_nat_enable=true -var dev_nat_enable=false | tail -n 8
provider "aws" {
  version = "1.2"

------------------------------------------------------------------------

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, no
actions need to be performed.

$ find . -name '*.tf' -exec sed -i 's/version = "1.2"/version = "1.3"/g' {} \;                                                                                                                                     

$ rm -rf .terraform; terraform init >/dev/null; cat *.tf | grep -E 'provider..aws' -A 1; terraform plan -var staging_nat_enable=true -var dev_nat_enable=false | tail -n 8
provider "aws" {
  version = "1.3"
Plan: 3 to add, 3 to change, 3 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

Important Factoids

In aws 1.2 this was fine, in aws 1.3 its not

References

2345

[grzegorzlisowski]

I was hit by the same issue in aws_vpc.

One additional example with simple lb:

Terraform 0.11, provider: 1.2

main.tf

provider "aws" {
  region  = "us-east-1"
  version = "= 1.2"
}

resource "aws_lb" "lb" {
// ...
}

output "elb_name" {
  value = "${aws_lb.lb.name}"
}

$ terraform init && terraform plan

...

Terraform will perform the following actions:

  + aws_lb.lb
      id:                         <computed>
      access_logs.#:              <computed>
      arn:                        <computed>
...

Plan: 1 to add, 0 to change, 0 to destroy.



md5-8bf7e5b7dfa98abbe322bcb03cdc57dd



provider "aws" {
  region  = "us-east-1"
  version = "= 1.3"
}

resource "aws_lb" "lb" {
// ...
}

output "elb_name" {
  value = "${aws_lb.lb.name}"
}



md5-219b53b6a1469faa0d611a6f88c20a65



$ terraform init && terraform plan
...

Error: Error running plan: 1 error(s) occurred:

* output.elb_name: Resource 'aws_lb.lb' does not have attribute 'name' for variable 'aws_lb.lb.name'



md5-7708cb3f50032cad8ed50fb04a6e4824



provider "aws" {
  region  = "us-east-1"
  version = "= 1.3"
}

resource "aws_lb" "lb" {
    name = "test"
// ...
}

output "elb_name" {
  value = "${aws_lb.lb.name}"
}



md5-219b53b6a1469faa0d611a6f88c20a65



$ terraform init && terraform plan
...

Terraform will perform the following actions:

  + aws_lb.lb
      id:                         <computed>
      access_logs.#:              <computed>
      arn:                        <computed>
...
Plan: 1 to add, 0 to change, 0 to destroy.



md5-29853b0b8ed29971019aee402141909d



provider "aws" {
  region  = "us-east-1"
  version = "= 1.3"
}

resource "aws_lb" "lb" {
    name_prefix = "test"
// ...
}

output "elb_name" {
  value = "${aws_lb.lb.name}"
}



md5-219b53b6a1469faa0d611a6f88c20a65



$ terraform init && terraform plan
...

Error: Error running plan: 1 error(s) occurred:

* output.elb_name: Resource 'aws_lb.lb' does not have attribute 'name' for variable 'aws_lb.lb.name'

[jocelynthode]

Any news regarding this issue ? It completely prevents us from moving to 1.3.1.

[ccslamstack]

Please fix this!!! ASAP this is screwing off a lot of stuff and breaking all our modules!!

[egarbi]

same here

[grems6]

+1

[grzegorzlisowski]

I have made some simple bisecting of the changes and it seems that strange things started to happen after this commit:

vendor: github.com/hashicorp/terraform/[email protected]

This is update to the vendor which introduced a lot from terraform core. Within those changes I see some related to new way of calculating resources diffs. This change seems to have very negative impact on lots of my modules where default empty values are in use.

[shanewarner]

This is a production breaking issue. Please fix ASAP

[robertwe]

I got exactly the same issue. The only solution for now was to pin AWS provider plugin version to v 1.2.0 otherwise we are not able to use latest version of AWs provider at all. From my perspective this is super critical issue.

[bdashrad]

@grzegorzlisowski i think the .name issue is because .name is a parameter, but not an attribute, so when it's not set explicitly, terraform doesn't know it's value.

https://www.terraform.io/docs/providers/aws/r/lb.html

[grzegorzlisowski]

@bdashrad

The name parameter is optional which means it should be autogenerated so ELB will have name. It works this way until plugin 1.2.

Actually this is related to this issue 2498

[seanjfellows]

We are similarly affected, Terraform wants to continually destroy+create our ec2 instances because of this issue.

[apparentlymart]

Hi all! Sorry for this unintended regression.

It looks like this same issue was also reported in #2451 and #2468, which I've now closed to consolidate the discussion over here. However, I want to capture some notes on those issues here so we don't lose track:

• Per #2451, this seems to affect all attributes that are Optional+Computed when the user-supplied value is the empty string. The new behavior is "more correct" in the theoretical sense, but breaks an assumption that was previously allowing (by accident) conditional setting of arguments even though Terraform currently lacks an explicit idea of null.
• As I'd noted in #2468, we are currently working on integrating a new version of the configuration language that _does_ have explicit null support that would allow this to be resolved "properly" in some sense, but it's true that the regression here was not intended and so we will find a way to restore the prior behavior so that existing modules can continue to work until the configuration language improvements are complete. (The new language features will come in a major release as a documented breaking change.)

As @bdashrad noted, this is likely to be a result of upgrading the vendored version of the Terraform provider framework (the packages under helper/ in the core repository, and helper/schema in particular). I suspect it is caused specifically by hashicorp/terraform#14887, which altered slightly the diffing behavior to allow providers to customize it on a per-resource basis, but may have inadvertently changed the implementation detail of treating empty strings as unset when producing a diff.

We'll investigate this further to get to the bottom of what's going on here. In the mean time, I suggest staying on v1.2.0 if you use modules that depend on the prior behavior, until this issue is closed.

[brikis98]

Thx for the clear explanation @apparentlymart! This seems like a pretty major regression that will break most Terraform modules, so keep us posted on your progress.

[bflad]

We recently vendored some Terraform core updates into now released terraform-provider-aws version 1.7.0, which was why the issue was closed two days ago. It would be great to receive some feedback if these issues are fully resolved. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

[JohnMorales]

Hi @apparentlymart Martin, I don't think this is fixed. I'm still seeing this behavior in v.011 + aws 1.9. specifically when working with the aws_rds_cluster resource

[tonygyerr]

@apparentlymart is there an ETA on this or has this been fixed?

[DoKan3]

@apparentlymart also having issues with this in v.0.11.7 and aws 1.11.0 - specifically aws_db_instance

[atbida]

@apparentlymart I'm facing the same issue.
Terraform v.0.11.4 and aws provider 1.60.0 - specifically aws_db_instance

[apparentlymart]

I don't work on the AWS provider currently so I can't help directly here, but since this is a closed issue I would suggest opening a new issue if you are seeing a problem, and be sure to include all of the information requested in the issue template so that the AWS provider team can understand how your situation is different than the one that was fixed by the PR that closed this issue.

[hashibot[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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!