_This issue was originally opened by @mariozet as hashicorp/terraform#12170. It was migrated here as part of the provider split. The original body of the issue is below._
Hello,
Please find a description of unexpected terraform behavior below.
Terraform v0.8.7
resource "aws_lb_ssl_negotiation_policy" "stg_publish_elb_ssl_policy" {
name = "stg-publish-ssl-negotiation-policy"
load_balancer = "${aws_elb.public_stg_elb.id}"
lb_port = 443
attribute {
name = "Protocol-TLSv1.1"
value = "true"
}
attribute {
name = "Protocol-TLSv1.2"
value = "true"
}
attribute {
name = "Server-Defined-Cipher-Order"
value = "true"
}
attribute {
name = "ECDHE-ECDSA-AES128-GCM-SHA256"
value = "true"
}
attribute {
name = "ECDHE-RSA-AES128-GCM-SHA256"
value = "true"
}
attribute {
name = "ECDHE-ECDSA-AES128-SHA256"
value = "true"
}
attribute {
name = "ECDHE-RSA-AES128-SHA256"
value = "true"
}
attribute {
name = "ECDHE-ECDSA-AES128-SHA"
value = "true"
}
attribute {
name = "ECDHE-RSA-AES128-SHA"
value = "true"
}
attribute {
name = "ECDHE-ECDSA-AES256-GCM-SHA384"
value = "true"
}
attribute {
name = "ECDHE-RSA-AES256-GCM-SHA384"
value = "true"
}
attribute {
name = "ECDHE-ECDSA-AES256-SHA384"
value = "true"
}
attribute {
name = "ECDHE-RSA-AES256-SHA384"
value = "true"
}
attribute {
name = "ECDHE-RSA-AES256-SHA"
value = "true"
}
attribute {
name = "ECDHE-ECDSA-AES256-SHA"
value = "true"
}
}
resource "aws_lb_cookie_stickiness_policy" "pub_stg" {
name = "pub-stg-stickiness-policy"
load_balancer = "${aws_elb.public_stg_elb.id}"
lb_port = 443
cookie_expiration_period = 600
}
Both ELB's policies should be applied.
Currently, after first terraform apply, terraform detects configuration changes and try to apply both policies. However, after successful "apply" only SSL negotiation policy is set on ELB.
When we execute terraform plan then we can notice that stickiness policy is not applied.
During a second round of terraform apply stickiness policy is applied but SSL negotiation policy is overwritten by default ELB policy.
terraform applyterraform planterraform applyThe same thing happens when you have aws_lb_cookie_stickiness_policy at the same time you have a aws_load_balancer_policy and aws_load_balancer_listener_policy for the same ELB.
A workaround is to just use aws_load_balancer_policy and aws_load_balancer_listener_policy
resource "aws_load_balancer_policy" "stg_publish_elb_ssl_policy" {
load_balancer_name = "${aws_elb.public_stg_elb.name}"
policy_name = "stg-publish-ssl-negotiation-policy"
policy_type_name = "SSLNegotiationPolicyType"
policy_attribute {
name = "Protocol-TLSv1.1"
value = "true"
}
policy_attribute {
name = "Protocol-TLSv1.2"
value = "true"
}
// and so on ...
}
resource "aws_load_balancer_policy" "pub_stg" {
load_balancer_name = "${aws_elb.public_stg_elb.name}"
policy_name = "pub-stg-stickiness-policy"
policy_type_name = "LBCookieStickinessPolicyType"
policy_attribute {
name = "CookieExpirationPeriod"
value = "600"
}
}
resource "aws_load_balancer_listener_policy" "stg_publish_policies" {
load_balancer_name = "${aws_elb.public_stg_elb.name}"
load_balancer_port = 443
policy_names = [
"${aws_load_balancer_policy.stg_publish_elb_ssl_policy.policy_name}",
"${aws_load_balancer_policy.pub_stg.policy_name}",
]
}
The workaround is so good, I think it should actually be the chosen way to do this. Just delete the aws_lb_cookie_stickiness_policy resource and document aws_load_balancer_policy as the right way.
Slightly related: if you have both a aws_load_balancer_policy.main and a aws_lb_cookie_stickiness_policy.main, one of them will be overwritten with the other. I suspect they are treated as the same kind of resource in an underlying layer.
Just got the same issue.
I think aws_lb_ssl_negotiation_policy and aws_lb_cookie_stickiness_policy should be:
aws_load_balancer_policyThe documentation should also mention that it conflits with each others
Facing similar issue.
Closing as a duplicate of #349.
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!
Most helpful comment
A workaround is to just use
aws_load_balancer_policyandaws_load_balancer_listener_policy