aws_elb access_logs Continuously Recreated

[jcderose]

Terraform Version

0.7.9

Affected Resource(s)

• aws_elb

Terraform Configuration Files

variable "elb_access_logs_enabled" {
  description = "Whether or not to enable ELB access logs"
  default = "false"
}

resource "aws_elb" "app0" {
  access_logs {
    bucket = "mybucket"
    bucket_prefix = "app0"
    interval = 60
    enabled = "${var.elb_access_logs_enabled}"
  }
}

Debug Output

https://gist.github.com/jcderose/2987d44acb8951d2f498709a26b3bee0

Panic Output

n/a

Expected Behavior

Since the access_logs are already configured and disabled (e.g. var.elb_access_logs_enabled = false), this change should no longer show up in the terraform plan/apply output.

Actual Behavior

Even though the access_logs are already configured and disabled for this particular resource, this change continues to show up every time I run the terraform plan/apply commands.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform plan
2. terraform apply
3. terraform plan (again)

Important Factoids

n/a

References

n/a

[minamijoyo]

I had the same issue.

I think it seems to be caused by the change in #3863 .
If Enabled = false, access_log setting is not persistent to tfstate. On the other hand, its attribute values are stored in AWS, and even if Enabled = false, it is possible to set them.
@catsby

[catsby]

Hey all – I looked into this some, and it turns out you can't actually remove those attributes(?), you can just mark the access_logs as disabled. AWS persists those values 🤔

I'll have to poke at this. Ideas I have are 1) only saving to state if we an access_logs block in the config, and AWS has one that is enabled, or 2) on removal try clearing out the values and pushing that up to the API. I'm not sure if either will work but I'll poke at it 😄

[minamijoyo]

Thanks! Looking at the API of ModifyLoadBalancerAttributes, it seems that access_logs can be disabled, but not be deleted. Assuming that we follow the API, we can disable the access_logs block, but once we define it, we can not delete the block until delete the ELB. If we do not save it in tfstate in disable state, it will become a difference in the next plan. I think that some restrictions are required on how to use the access_logs block.

[catsby]

I believe that, if we remove it from the config file, we should then:

• disable it in the API
• remove it from state

It will remain in the API but it is disabled. It's safe to ignore.

Future plan/refresh should not save the API information in the state, unless:

• Re-adding: It's re-added in the config and successfully applied to the API
• Configuration drift: the API reports an enabled AccessLog block (it was added externally, thus detecting the drift)

That's the solution I'm working on now. Let me know if there are any problems with that approach 😄

[catsby]

This should be fixed in #11120

[minamijoyo]

@catsby I tried fixed version and it works as expected 👍 Thank you very much.

[catsby]

@minamijoyo wonderful, thanks for reporting back 😄

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