Skip to content
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.

Sign up for GitHub

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

Jump to bottom

CloudFront deletion seems to disable first when already disabled #3077

Closed
spanktar opened this issue Jan 21, 2018 · 4 comments · Fixed by #7794
Closed

CloudFront deletion seems to disable first when already disabled #3077

spanktar opened this issue Jan 21, 2018 · 4 comments · Fixed by #7794
Labels
bug Addresses a defect in current functionality. service/cloudfront Issues and PRs that pertain to the cloudfront service.
Milestone
v2.1.0

Comments

@spanktar
Copy link

spanktar commented Jan 21, 2018 •
edited
Loading

Terraform Version

0.10.7-0.11.3

We create our CloudFront distributions (aws_cloudfront_distribution) as "disabled" by default (for testing). We've noticed that, even when 100% deployed and disabled, a Terraform destroy takes just as long as if they were enabled. If we go to the AWS Console before a destroy and perform a manual Delete, the distributions delete very quickly (1-2m), whereas a Terraform destroy takes 15m+. What it seems like is Terraform is performing a "disable" action on the distro, even if it is already disabled (and AWS is respecting that for who knows why).

To be clear, the distros are completely disabled, not disabling or updating (spinning circle in the UI). They are fully deployed and disabled.

My suggestion is that TF check the state before performing "disable & delete" and only disable those which are currently enabled.

Expected Behavior

A previously disabled CF distro should delete quickly.

Actual Behavior

A previously disabled CF distro takes just as long to destroy as it would if it were enabled.

Steps to Reproduce

Create 2 different cloudfront distributions, disabled by default.
Once they are fully deployed, delete one using the AWS Console, note the time it takes.
Once that has been deleted, run Terraform destroy on the remaining one, again noting the time.
Note the time difference and weep.
@jbardin jbardin added bug Addresses a defect in current functionality. service/cloudfront Issues and PRs that pertain to the cloudfront service. labels Jan 23, 2018
@bflad bflad mentioned this issue Mar 2, 2019
Merged
bflad added a commit that referenced this issue Mar 3, 2019
@bflad
resource/aws_cloudfront_distribution: Remove viewer_certificate con…
286f294 
…figuration block argument `ConflictsWith` usage and fix various related issues with deployment timing

References:
* #7773
* #3077
* #1074
* #260

Here we remove the problematic `viewer_certificate` argument `ConflictsWith` schema configuration as it interferes with Terraform Module usage until Terraform 0.12 is more prevalent. More details: #7773 (comment)

When writing acceptance testing to cover setting both the `viewer_certificate` configuration block `acm_certificate_arn` and `cloudfront_default_certificate` arguments being defined, the below error was consistently happening when the test configuration included `enabled = false`:

```
--- FAIL: TestAccAWSCloudFrontDistribution_ViewerCertificate_AcmCertificateArn (1935.57s)
    testing.go:599: Error destroying resource! WARNING: Dangling resources
        may exist. The full state and error is shown below.

        Error: Error applying: 1 error occurred:
          * aws_cloudfront_distribution.test (destroy): 1 error occurred:
          * aws_cloudfront_distribution.test: CloudFront Distribution E3GDAPNU6UPO0O cannot be deleted: PreconditionFailed: The request failed because it didn't meet the preconditions in one or more request-header fields.
          status code: 412, request id: 4e73a086-3c33-11e9-832f-7732257f45e8
```

While debugging this the following further issues were encountered:

* The resource did not wait for deployment to complete on creation and updates so in the acceptance testing the deletion function was always handling `InProgress` operations.
* Disabled distributions would always update the distribution on deletion to disable them without checking if it was necessary, causing unnecessary delays.
* The `PreconditionFailed` error seemed to be related to some eventual consistency issue within CloudFront right after disabling the distribution, which was always done. Retrying was a sufficient workaround for the error.
* The deletion process did not ignore `NoSuchDistribution` errors such as the below:

```
--- FAIL: TestAccAWSCloudFrontDistribution_ViewerCertificate_AcmCertificateArn (1835.97s)
    testing.go:599: Error destroying resource! WARNING: Dangling resources
        may exist. The full state and error is shown below.

        Error: Error applying: 1 error occurred:
          * aws_cloudfront_distribution.test (destroy): 1 error occurred:
          * aws_cloudfront_distribution.test: CloudFront Distribution E2HQM77NFHV9T cannot be deleted: NoSuchDistribution: The specified distribution does not exist.
```

This changeset bundles all these fixes together as they are related.

Previous output for `ConflictsWith` acceptance testing:

```
--- FAIL: TestAccAWSCloudFrontDistribution_ViewerCertificate_AcmCertificateArn_ConflictsWithCloudFrontDefaultCertificate (1.64s)
    testing.go:538: Step 0 error: config is invalid: 2 problems:

        - aws_cloudfront_distribution.test: "viewer_certificate.0.acm_certificate_arn": conflicts with viewer_certificate.0.cloudfront_default_certificate
        - aws_cloudfront_distribution.test: "viewer_certificate.0.cloudfront_default_certificate": conflicts with viewer_certificate.0.acm_certificate_arn
```

Output from acceptance testing:

```
--- PASS: TestAccAWSCloudFrontDistribution_Origin_EmptyDomainName (2.15s)
--- PASS: TestAccAWSCloudFrontDistribution_Origin_EmptyOriginID (2.19s)
--- PASS: TestAccAWSCloudFrontDistribution_ViewerCertificate_AcmCertificateArn_ConflictsWithCloudFrontDefaultCertificate (1915.48s)
--- PASS: TestAccAWSCloudFrontDistribution_ViewerCertificate_AcmCertificateArn (1958.08s)
--- PASS: TestAccAWSCloudFrontDistribution_noCustomErrorResponseConfig (2121.58s)
--- PASS: TestAccAWSCloudFrontDistribution_HTTP11Config (2123.60s)
--- PASS: TestAccAWSCloudFrontDistribution_orderedCacheBehavior (2126.73s)
--- PASS: TestAccAWSCloudFrontDistribution_noOptionalItemsConfig (2126.82s)
--- PASS: TestAccAWSCloudFrontDistribution_IsIPV6EnabledConfig (2176.09s)
--- PASS: TestAccAWSCloudFrontDistribution_customOrigin (2178.92s)
--- PASS: TestAccAWSCloudFrontDistribution_S3Origin (2178.98s)
--- PASS: TestAccAWSCloudFrontDistribution_multiOrigin (2179.08s)
--- PASS: TestAccAWSCloudFrontDistribution_S3OriginWithTags (3251.14s)
```
@bflad bflad added this to the v2.1.0 milestone Mar 4, 2019
@bflad
Copy link
Contributor

bflad commented Mar 4, 2019

The fix for this has been merged and will release with version 2.1.0 of the Terraform AWS Provider, likely middle of this week. 👍

@spanky-R7
Copy link

That's great news, thanks!

@bflad
Copy link
Contributor

bflad commented Mar 8, 2019

This has been released in version 2.1.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

@ghost
Copy link

ghost commented Mar 31, 2020

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!

@ghost ghost locked and limited conversation to collaborators Mar 31, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
bug Addresses a defect in current functionality. service/cloudfront Issues and PRs that pertain to the cloudfront service.
Projects
None yet
Milestone
v2.1.0
4 participants
@jbardin @bflad @spanktar @spanky-R7