Terraform: Changing the SSL certificate in aws_elb removes the cookie stickiness policy

[daisuke-morita]

Terraform Version

Terraform v0.6.16

Affected Resources

• aws_elb
• aws_lb_cookie_stickiness_policy
• aws_app_cookie_stickiness_policy
  

  Terraform Configuration Files

resource "aws_elb" "test" {
  name = "test-elb"
  cross_zone_load_balancing = true
  subnets = ["xxx", "yyy"]
  listener {
    instance_port = 80
    instance_protocol = "http"
    lb_port = 443
    lb_protocol = "https"
    ssl_certificate_id = "arn:aws:iam::xxx" # change
  }
}

resource "aws_lb_cookie_stickiness_policy" "test" {
  name = "TestStickiness"
  load_balancer = "${aws_elb.test.id}"
  lb_port = 443
  cookie_expiration_period = 3600
}

Actual Behavior

When I change the SSL certificate on an aws_elb and apply it, the cookie stickiness policy which was already applied to the listener will be removed (changed to Stickiness: Disabled).

Is this an expected behavior?

[jbardin]

Hi @daisuke-morita,

No that's not the expected behavior, but I think this may be handled correctly in the upcoming release. Can you include the output from terraform plan?

[daisuke-morita]

Hi @jbardin,

Here is the output of terraform plan when I try to change the ssl certificate (I replaced the real arns with dummy ones):

$ terraform plan
Refreshing Terraform state prior to plan...

aws_elb.test: Refreshing state... (ID: test-elb)
aws_lb_cookie_stickiness_policy.test: Refreshing state... (ID: test-elb:443:TestStickiness)

The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

~ aws_elb.test
    listener.1331219042.instance_port:      "" => "80"
    listener.1331219042.instance_protocol:  "" => "http"
    listener.1331219042.lb_port:            "" => "443"
    listener.1331219042.lb_protocol:        "" => "https"
    listener.1331219042.ssl_certificate_id: "" => "arn:aws:iam::00000:server-certificate/new_cert"
    listener.1685428641.instance_port:      "80" => "0"
    listener.1685428641.instance_protocol:  "http" => ""
    listener.1685428641.lb_port:            "443" => "0"
    listener.1685428641.lb_protocol:        "https" => ""
    listener.1685428641.ssl_certificate_id: "arn:aws:iam::00000:server-certificate/old_cert" => ""


Plan: 0 to add, 1 to change, 0 to destroy.

And the output of terraform apply:

$ terraform apply
aws_elb.test: Refreshing state... (ID: test-elb)
aws_lb_cookie_stickiness_policy.test: Refreshing state... (ID: test-elb:443:TestStickiness)
aws_elb.test: Modifying...
  listener.1331219042.instance_port:      "" => "80"
  listener.1331219042.instance_protocol:  "" => "http"
  listener.1331219042.lb_port:            "" => "443"
  listener.1331219042.lb_protocol:        "" => "https"
  listener.1331219042.ssl_certificate_id: "" => "arn:aws:iam::00000:server-certificate/new_cert"
  listener.1685428641.instance_port:      "80" => "0"
  listener.1685428641.instance_protocol:  "http" => ""
  listener.1685428641.lb_port:            "443" => "0"
  listener.1685428641.lb_protocol:        "https" => ""
  listener.1685428641.ssl_certificate_id: "arn:aws:iam::00000:server-certificate/old_cert" => ""
aws_elb.test: Modifications complete

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

After applying this change, the stickiness has been removed.

[jbardin]

Thanks for the extra info @daisuke-morita! I can reproduce the problem here.

Unfortunately this issue is _not_ fixed in the pending release. I'll have to investigate further.

[jbardin]

It's not a solution, but it's good to note that in next release the stickiness policy will be updated on a subsequent run of terraform apply.

The underlying issue here is that there is no way to directly depend on an attribute of another resource. The short-term fix will be to break out elb listeners into their own top-level resource.

[mrcrilly]

Hi @jbardin,

Is there any movement on a fix for this? We're currently using 0.7.1-dev, and we're about to move to 0.7.3, yet this problem persists. It's quite a bad issue to leave laying around as stickiness being dropped completely destroys our application - not ideal. For now we're having to manage stickiness manually.

As another note, I cannot see a means of moving, "elb listeners into their own top-level resource." Can you show me where in the documentation this is covered as I cannot find it under the AWS provider.

Thanks for your help.

[jbardin]

Hi @mrcrilly,

Creating a top-level elb_listener as mentioned in issue 7246 is something we would have to add to the provider. I'll see if this is something we can schedule including soon, as there's not currently any workaround other than running apply a second time.

[mrcrilly]

Thanks mate. That's appreciated.

[Yogesh-D]

Hi @jbardin

Just checking - Is there any work around this issue. I am facing the same issue while creating stickiness policy for ELB with https.

[jbardin]

Hi @Yogesh-D,

Unfortunately due to constraints in the AWS API we can't separate out the elb listeners.
A complete fix for this issue will require a larger change to the provider schemas, which we have on our roadmap.

[Yogesh-D]

Thanks for the update @jbardin . Appreciate it. 👍

[hashibot[bot]]

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.