0.6.16
Please list the resources as a list, for example:
`````` hcl
resource "aws_cloudfront_distribution" "cloudfront" {
origin {
domain_name = "${var.lde_vm_domain_name}"
origin_id = "lde_vm"
custom_origin_config {
http_port = 80
https_port = 443
origin_protocol_policy = "match-viewer"
origin_ssl_protocols = [
"SSLv3",
"TLSv1"]
}
custom_header = {
name = "${var.lde_custom_header_name}"
value = "${var.lde_custom_header_value}"
}
}
aliases = ["${var.public_domain_name}"]
enabled = true
comment = "CloudFront Server"
default_cache_behavior {
target_origin_id = "lde_vm"
allowed_methods = [
"DELETE",
"GET",
"HEAD",
"OPTIONS",
"PATCH",
"POST",
"PUT"]
cached_methods = [
"GET",
"HEAD"]
compress = true
smooth_streaming = false
forwarded_values {
cookies {
forward = "all"
}
headers = ["Host"]
query_string = true
}
viewer_protocol_policy = "allow-all"
min_ttl = 0
default_ttl = 3600
max_ttl = 31536000
}
cache_behavior {
path_pattern = "user/digital_content/download/*"
target_origin_id = "lde_vm"
allowed_methods = [
"GET",
"HEAD",
"OPTIONS"]
cached_methods = [
"GET",
"HEAD"]
compress = true
smooth_streaming = false
forwarded_values {
cookies {
forward = "none"
}
headers = ["Host"]
query_string = true
}
trusted_signers = ["self"]
viewer_protocol_policy = "allow-all"
min_ttl = 0
default_ttl = 3600
max_ttl = 31536000
}
# JS files
cache_behavior {
path_pattern = "js/*"
target_origin_id = "lde_vm"
allowed_methods = [
"GET",
"HEAD",
"OPTIONS"]
cached_methods = [
"GET",
"HEAD"]
compress = true
smooth_streaming = false
forwarded_values {
cookies {
forward = "none"
}
headers = ["Host"]
query_string = true
}
viewer_protocol_policy = "allow-all"
min_ttl = 0
default_ttl = 3600
max_ttl = 31536000
}
# CSS files
cache_behavior {
path_pattern = "css/*"
target_origin_id = "lde_vm"
allowed_methods = [
"GET",
"HEAD",
"OPTIONS"]
cached_methods = [
"GET",
"HEAD"]
compress = true
smooth_streaming = false
forwarded_values {
cookies {
forward = "none"
}
headers = ["Host"]
query_string = true
}
viewer_protocol_policy = "allow-all"
min_ttl = 0
default_ttl = 3600
max_ttl = 31536000
}
restrictions {
geo_restriction {
restriction_type = "none"
}
}
viewer_certificate {
iam_certificate_id = "${aws_iam_server_certificate.alias_certificate.id}"
ssl_support_method = "sni-only"
minimum_protocol_version = "TLSv1"
}
retain_on_delete = false
price_class = "${var.cloudfront_price_class}"
}```
N/A
N/A
We should be able to specify the precedence of multiple cache_behavior definitions. Eg:
```hcl
cache_behavior {
precedence: 0
path_pattern: "js/*"
...
}
cache_behavior {
precedence: 1
path_pattern: "images/*"
}
``````
Alternately, the order that the cache_behaviour blocks are defined in the config should define the precedence.
Cache behaviours are created in random order:
Please list the steps required to reproduce the issue, for example:
terraform apply
Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?
Nothing special.
Not that I'm aware of.
Hi @randomeizer! Thanks for the detailed explanation. The issue here is that the cache behaviours are incorrectly defined as a Set instead of a List, and so there are no ordering guarantees - the code is here. This should be a relatively easy fix luckily - we'll get it sorted out.
@jen20 Great! So the precedence order would be defined by the defined order in the .tf?
Has there been any progress on this? We happen to use terraform for managing a lot of our AWS infrastructure, and whenever a cloudfront distribution is changed, we have to manually go back to ensure that the behavior order has not surprisingly changed, which doesn't give the team confidence in the tooling.
The most recent instantiation of this wackiness, I took changed a distributions iam_certificate_id
to an acm_certificate_arn
, no changes were performed to the cache behaviors at all. This resulted in reordering my /v1/*
behavior above my /v1/stats/*
behavior.
Just hit this issue in 0.8.5, where when you have different bahaviours for longer versions of the same path.
eg desired precendence:
/foo/bar => do something particular for bar
/foo/* => do some default action for everything else
So if /foo/*
appears in the order before /foo/bar
then bar
will not have its custom behaviour applied.
After some further testing, it appears that if terraform has to update the resource config on an apply
, the behaviours can end up out of sequence, even after manually correcting the order of precedence. IF the resource doesn't require any changes then the manual ordering persists over an apply
.
+1
+1
+1
+1
Is there an update on this?
It's still an issue on 0.8.8 @jochavez. I haven't migrated to 0.9 yet but given the lack of response here and open status of related tickets I'd say it's reasonable to assume there hasn't been a significant change in the status of this issue yet.
+1
+1
+1
(We're storing aws cli aws cloudfront get-distribution-config
result json in repo and manage via aws cli. Far from ideal but luckily cloudfront config doesn't need to change that often)
+1 please.... having to go back to the console to change the order after adding another behavior is quite a drag
Is anybody in the terraform community going to address this issue?
It causes serious problems and gives the impression that terraform is not stable or ready for production.
Please fix this, thanks a lot.
@jen20 maybe ?
Would appreciate if this issue is fixed.
Thanks in advance. :-)
Anyone ever find a fix for this? I'm amazed the linked issue is still open.
Yeah still being griefed by this in 0.9.11
@acejam @edify42 This issue is now over at the provider instead of in the main Terraform repository: terraform-providers/terraform-provider-aws#188.
Cheers @jen20.
I noticed that you can manually set the order in the UI and it doesn't affect the state kept in terraform (no changes seen afterwards when you do a terraform plan)
That probably (I haven't looked at any source and am replying on phone) means that the attribute is defined in the Terraform provider as a TypeSet
and not a TypeList
.
We're using Terraform v0.10.2 and still facing the same issue.
Any info on how to invalidate cache for objects via terraform as we have in distributions' "Invalidations" ?
Just in case people are still looking for a solution, you'll want to use ordered_cache_behavior for this
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.
Most helpful comment
Any info on how to invalidate cache for objects via terraform as we have in distributions' "Invalidations" ?