Recent aws_cloudfront_distribution change breaks a usage pattern

[lievertz]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

TERRAFORM_VERSION=0.11.11

Affected Resource(s)

• aws_cloudfront_distribution

Terraform Configuration Files

Relevant bit:

  viewer_certificate {
    acm_certificate_arn             = "${var.acm_certificate_arn}"
    cloudfront_default_certificate  = "${var.acm_certificate_arn == "" ? true : false}"
    ssl_support_method              = "sni-only"
  }

Also see similar example: https://github.com/cloudposse/terraform-aws-cloudfront-cdn/blob/master/main.tf

Debug Output

This is a pretty straightforward situation, so omitting this step.

Panic Output

N/A

Expected Behavior

Provider users were previously specifying the acm_certificate_arn and the cloudfront_default_certificate where the default option would use a ternary to only show true if acm_certificate_arn was blank.

Actual Behavior

Now you guys are explicitly enforcing only using one of those options.

Steps to Reproduce

Use both acm_certificate_arn as well as cloudfront_default_certificate in viewer_certificate. Use normally.

Important Factoids

References

• 3dc190a
• Specifically at: https://github.com/terraform-providers/terraform-provider-aws/blame/master/aws/resource_aws_cloudfront_distribution.go#L611

Mostly I just wanted to file this to make sure you guys were aware that this was going to break some, perhaps a non-trivial number, of users... technically it matches the documentation (i.e., https://www.terraform.io/docs/providers/aws/r/cloudfront_distribution.html#viewer-certificate-arguments), so feel free to close as FAD... but... thought you might want a heads up... and I think the nature of this commit could potentially have introduced other issues as well... so again, just a heads up in case any of this is surprising or undesirable.

[bflad]

Hi @lievertz 👋 Thanks for writing in.

Yesterday we released version 2.0.0 of the Terraform AWS Provider, which includes this resource schema change. Originally the code intended to include this ConflictsWith statement, but it was errantly written in the original implementation and it did not work as expected. During our major version upgrade work, this was noticed and fixed from the Terraform AWS Provider perspective.

The inclusion of the fix was actually stemming from the upcoming Terraform 0.12 ability to also support null values in arguments, which the upstream Terraform Module would be expected to properly implement in this case when Terraform 0.12 is more generally available, e.g. something like

# variables.tf
variable "acm_certificate_arn" {
  description = "Existing ACM Certificate ARN"
  default     = null
  type        = string
}

# main.tf
resource "aws_cloudfront_distribution" "default" {
  # ... other configuration ...

  viewer_certificate {
    acm_certificate_arn            = var.acm_certificate_arn
    ssl_support_method             = "sni-only"
    minimum_protocol_version       = var.viewer_minimum_protocol_version
    cloudfront_default_certificate = var.acm_certificate_arn ? null : true
  }

However, given the Terraform 0.12 release timing and longer tail for general Terraform 0.12 adoption, I believe we would be amenable to temporarily remove the "fixed" ConflictsWith usage in this point and defer its usage until another future major version release of the Terraform AWS Provider.

I'll mark this issue for our current release milestone (releasing next week) and ensure it is triaged.

If you need to pin to the last 1.X Terraform AWS Provider release, a configuration like this can do that in the meantime:

provider "aws" {
  # ... other configuration ...

  version = "~> 1.60"
}

[lievertz]

Hi @bflad Thanks for the response! Yeah... we appear to have stumbled kind of wholesale into 2.0 unawares, so thank you for for the context... sorry I missed that searching for a more specific issue -- I kind of missed the larger boat there!

Thank you for looking at that hold-off for implementing that validation as it will be nice to approach the later fix with a direct replacement.

Much appreciated!

[bflad]

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

[rburke789]

Does anyone have a workaround for this until 2.1.0 is available? I am kinda blocked by this

[bflad]

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.

[rburke789]

awesome. Problem solved! Thanks!

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