Terraform: Error destroying aws cloudfront distribution

[johnpemberton]

I'm trying to destroy a cloudfront distribution created with terraform, however I'm getting an error

Error applying plan:
1 error(s) occurred:
* aws_cloudfront_distribution.callback: InvalidArgument: The parameter Lambda function associations is required.

I've done a bit of digging and I wonder if this is related to the aws sdk 1.6.2 release where support for lambda function associations was introduced. (see references)

Terraform Version

v0.82

Note: I'm pretty sure the cloudfront distribution was created with v0.7.13. v0.8.2 is the version I'm currently using to try to destroy it with. Not had chance to check if this issue would occur if I was creating and destroying with the same version.

Affected Resource(s)

• aws_cloudfront_distribution

Expected Behavior

Should have destroyed the cloudfront distribution

Actual Behavior

Error aws_cloudfront_distribution.callback: InvalidArgument: The parameter Lambda function associations is required.

Steps to Reproduce

1. create a cloudfront distribution with terraform apply
2. try to delete it with terraform destroy

References

https://github.com/aws/aws-sdk-go/releases/tag/v1.6.2

[jsonmaur]

Getting this same error when trying to edit a CloudFront distribution. It worked fine when creating, but errors if I try to change anything. Kind of a big problem as I can't change anything in my distro without recreating or editing manually :(

[MrGossett]

CloudFront API docs say the LambdaFunctionAssociations parameter is optional.

I ran terraform apply with TF_LOG=debug (using self-compiled v0.8.2) and extracted the UpdateDistribution request. Here's the pretty-printed XML at /DistributionConfig/DefaultCacheBehavior:

<DefaultCacheBehavior>
  <TrustedSigners>
    <Enabled>false</Enabled>
    <Quantity>0</Quantity>
  </TrustedSigners>
  <ViewerProtocolPolicy>redirect-to-https</ViewerProtocolPolicy>
  <MaxTTL>86400</MaxTTL>
  <MinTTL>0</MinTTL>
  <TargetOriginId>s3</TargetOriginId>
  <ForwardedValues>
    <QueryStringCacheKeys>
      <Items/>
      <Quantity>0</Quantity>
    </QueryStringCacheKeys>
    <Cookies>
      <Forward>none</Forward>
      <WhitelistedNames>
        <Items/>
        <Quantity>0</Quantity>
      </WhitelistedNames>
    </Cookies>
    <Headers>
      <Items/>
      <Quantity>0</Quantity>
    </Headers>
    <QueryString>false</QueryString>
  </ForwardedValues>
  <SmoothStreaming>false</SmoothStreaming>
  <AllowedMethods>
    <Items>
      <Method>HEAD</Method>
      <Method>GET</Method>
    </Items>
    <Quantity>2</Quantity>
    <CachedMethods>
      <Items>
        <Method>HEAD</Method>
        <Method>GET</Method>
      </Items>
      <Quantity>2</Quantity>
    </CachedMethods>
  </AllowedMethods>
  <Compress>true</Compress>
  <DefaultTTL>3600</DefaultTTL>
</DefaultCacheBehavior>

The apply err'd with that same message:

Error applying plan:
2016/12/30 23:05:18 [DEBUG] plugin: waiting for all plugin processes to complete...

1 error(s) occurred:

* aws_cloudfront_distribution.blog: InvalidArgument: The parameter Lambda function associations is required.
    status code: 400, request id: 572b357c-cf0e-11e6-b1c0-e59b0cd863c5

Repeating the same with v0.8.3-dev (5de3a39f) resulted in the same XML fragment and the same error result.

Smells like a bug in the CloudFront API

[MrGossett]

I patched expandCacheBehavior in builtin/providers/aws/cloudfront_distribution_configuration_structure.go with this:

diff --git a/builtin/providers/aws/cloudfront_distribution_configuration_structure.go b/builtin/providers/aws/cloudfront_distribution_configuration_structure.go
index b891bd26b..1eff7689f 100644
--- a/builtin/providers/aws/cloudfront_distribution_configuration_structure.go
+++ b/builtin/providers/aws/cloudfront_distribution_configuration_structure.go
@@ -261,6 +261,9 @@ func expandCacheBehavior(m map[string]interface{}) *cloudfront.CacheBehavior {
                MinTTL:               aws.Int64(int64(m["min_ttl"].(int))),
                MaxTTL:               aws.Int64(int64(m["max_ttl"].(int))),
                DefaultTTL:           aws.Int64(int64(m["default_ttl"].(int))),
+               LambdaFunctionAssociations: &cloudfront.LambdaFunctionAssociations{
+                       Quantity: aws.Int64(0),
+               },
        }
        if v, ok := m["trusted_signers"]; ok {
                cb.TrustedSigners = expandTrustedSigners(v.([]interface{}))

Compiled and ran the apply again. This time, the request included a LambdaFunctionAssociations element:

<LambdaFunctionAssociations>
  <Quantity>0</Quantity>
</LambdaFunctionAssociations>

and the apply completed successfully.

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

This is a horrible hack; proper support of LambdaFunctionAssociations would be ideal. But maybe this is sufficient to unblock updating CloudFront distributions in the meantime.

[johnpemberton]

@MrGossett Yes, the aws cloudfront api documentation is misleading at best. While it says the LambdaFunctionAssociations parameter is optional on the page you linked to, if you look at the docs for the LambdaFunctionAssociations object, it states:

If you don't want to invoke any Lambda functions for the requests that match PathPattern, specify 0 for Quantity and omit Items.

Looks to me like the latter is correct based on the success of your above patch. Nice work on the PR btw!

[naftulikay]

I am getting hit by this issue as well. I cannot update my CloudFront distributions due to this. @MrGossett can a patch for this be slated for Terraform 0.8.3?

[bflad]

Just to chime in, affected me as well today. Would love to see this fixed! If any help is needed please reach out.

[w32-blaster]

Same here. Any update?

[catsby]

Hey friends – it looks like #10985 should address this, and I hope to get it merged soon I just have ~2 questions to get resolved and we should get this patched up. Thanks!

[sebolabs]

+1, please fix

[przemos]

+1 for accepting merge.

[xoob]

+1 any chance to get this fixed? we are unable to apply changes to our cloudfront dists at the moment.

[kurudans]

Same issue here. Unable to update the distribution. I upgraded terraform to v0.8.4. No luck.

[akramhussein]

I had the same issue, so I did the following for the time being (may help you):

1. Follow building instructions

2. Fetch the pull-request commit (as referenced above) - i've named the branch it cf_lambda_fix:

   $ git fetch origin pull/10985/head:cf_lambda_fix

3. Checkout the branch cf_lambda_fix:

   $ get checkout cf_lambda_fix

4. Build the branch:

   $ make dev

5. In your terraform environment, you should be able to run this version via:

   $ $GOPATH/src/github.com/hashicorp/terraform/bin/terraform plan

Note: I think (not 100% sure) that you won't able to revert to using an older version of Terraform on your project. Just like when you upgrade Terraform version and then try and use an older version, the state is represented using a newer format so it throws an error. This branch represents a newer version I believe.

Hope this helps. I had a couple issues at the start with getting go installed correctly but after that rest worked.

[juhoojala]

:+1: For getting this fixed.

We have been unable to update our cloudfront distributions via terraform now for more than 3 weeks.

[simonox]

+1. Same issue here.

[grebois]

+1

[jch254]

:+1:

[kurudans]

Any luck ?

[MrGossett]

PR #11291 is in flight. Looks like this should be resolved as soon as that PR is merged.

[catsby]

Hey all – #11291 should address this (thanks @MrGossett !) I'm just waiting for some local tests to pass before merging.

[lkishalmi]

Just compiled dev with this patch yesterday. I've gained back my control over cloudfront distributions.

[catsby]

Sorry for the trouble @lkishalmi , thank you for reporting it was fixed!

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