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.

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

Error destroying aws cloudfront distribution #10938

Closed
johnpemberton opened this Issue Dec 28, 2016 · 22 comments

Comments

Projects
None yet
@johnpemberton

johnpemberton commented Dec 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jsonmaur

jsonmaur Dec 29, 2016

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 :(

jsonmaur commented Dec 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@MrGossett

MrGossett Dec 31, 2016

Contributor

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 (5de3a39) resulted in the same XML fragment and the same error result.

Smells like a bug in the CloudFront API

Contributor

MrGossett commented Dec 31, 2016

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 (5de3a39) resulted in the same XML fragment and the same error result.

Smells like a bug in the CloudFront API

@MrGossett

This comment has been minimized.

Show comment
Hide comment
@MrGossett

MrGossett Dec 31, 2016

Contributor

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.

Contributor

MrGossett commented Dec 31, 2016

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

This comment has been minimized.

Show comment
Hide comment
@johnpemberton

johnpemberton Jan 3, 2017

@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!

@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

This comment has been minimized.

Show comment
Hide comment
@naftulikay

naftulikay Jan 5, 2017

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?

naftulikay commented Jan 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bflad

bflad Jan 5, 2017

Contributor

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

Contributor

bflad commented Jan 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@w32-blaster

w32-blaster Jan 5, 2017

Contributor

Same here. Any update?

Contributor

w32-blaster commented Jan 5, 2017

Same here. Any update?

@catsby

This comment has been minimized.

Show comment
Hide comment
@catsby

catsby Jan 5, 2017

Member

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!

Member

catsby commented Jan 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@sebolabs

sebolabs Jan 13, 2017

+1, please fix

+1, please fix

@przemos

This comment has been minimized.

Show comment
Hide comment
@przemos

przemos Jan 13, 2017

+1 for accepting merge.

przemos commented Jan 13, 2017

+1 for accepting merge.

@xoob

This comment has been minimized.

Show comment
Hide comment
@xoob

xoob Jan 16, 2017

Contributor

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

Contributor

xoob commented Jan 16, 2017

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

@kurudans

This comment has been minimized.

Show comment
Hide comment
@kurudans

kurudans Jan 17, 2017

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

kurudans commented Jan 17, 2017

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

@akramhussein

This comment has been minimized.

Show comment
Hide comment
@akramhussein

akramhussein Jan 17, 2017

Contributor

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.

Contributor

akramhussein commented Jan 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@juhoojala

juhoojala Jan 17, 2017

👍 For getting this fixed.

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

juhoojala commented Jan 17, 2017

👍 For getting this fixed.

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

@simonox

This comment has been minimized.

Show comment
Hide comment
@simonox

simonox Jan 17, 2017

+1. Same issue here.

simonox commented Jan 17, 2017

+1. Same issue here.

@grebois

This comment has been minimized.

Show comment
Hide comment

grebois commented Jan 18, 2017

+1

@jch254

This comment has been minimized.

Show comment
Hide comment

jch254 commented Jan 19, 2017

👍

@kurudans

This comment has been minimized.

Show comment
Hide comment
@kurudans

kurudans Jan 19, 2017

Any luck ?

Any luck ?

@MrGossett

This comment has been minimized.

Show comment
Hide comment
@MrGossett

MrGossett Jan 19, 2017

Contributor

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

Contributor

MrGossett commented Jan 19, 2017

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

@catsby

This comment has been minimized.

Show comment
Hide comment
@catsby

catsby Jan 19, 2017

Member

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

Member

catsby commented Jan 19, 2017

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

@lkishalmi

This comment has been minimized.

Show comment
Hide comment
@lkishalmi

lkishalmi Jan 19, 2017

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

lkishalmi commented Jan 19, 2017

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

@catsby

This comment has been minimized.

Show comment
Hide comment
@catsby

catsby Jan 23, 2017

Member

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

Member

catsby commented Jan 23, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment