search

aws-cloudformation / cloudformation-cli

The CloudFormation Provider Development Toolkit allows you to author your own resource providers and modules that can be used by CloudFormation.
Apache License 2.0
318 stars 161 forks source link

AWS elastic load balancer stickiness didn't update with CloudFormation #992

Closed garretwilson closed 12 months ago

garretwilson commented 1 year ago

I first raised this issue on Stack Overflow.

I had an AWS CloudFormation template for ECS with an elastic load balancer with sticky sessions turned on:

  WebTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties: 
      …
      Port: 80
      Protocol: HTTP
      TargetGroupAttributes:
        - Key: stickiness.enabled
          Value: true
        - Key: stickiness.type
          Value: lb_cookie

I changed the back-end to be stateless, and updated the CloudFormation template by simply deleting the TargetGroupAttributes section.

  WebTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties: 
      …
      Port: 80
      Protocol: HTTP
      TargetGroupAttributes:
        - Key: stickiness.enabled
          Value: true
        - Key: stickiness.type
          Value: lb_cookie

After all, the TargetGroupAttributes section is optional, and stickiness.enabled defaults to false.

But after I redeployed the CloudFormation template, increasing minimum number of desired instances as a test, the number of instances went up but refreshing a page got the same instance each time. Sure enough, in the console if I edit the target group attributes, it shows "Stickiness" is still turned on!

I added back the TargetGroupAttributes section with stickiness.enabled explicitly turned off:

  WebTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties: 
      …
      Port: 80
      Protocol: HTTP
      TargetGroupAttributes:
        - Key: stickiness.enabled
          Value: false

This was sufficient to turn off stickiness.

From a developer's viewpoint, I would suspect that CloudFormation, creating its graph of settings, didn't even include the TargetGroupAttributes section, so therefore it didn't compare the old TargetGroupAttributes subgraph for any changes. (But this is an obvious gotcha for graph comparison and splicing. It should be accounted for in the algorithm.)

Yet again, as with #989 and #991, some hidden settings in CloudFormation get stuck in some position, and I never know whether my deploy is really going to deploy everything or not.

mircealam commented 12 months ago

This is not the right place to report this issue. Please verify if there is an issue here and if not please open one: https://github.com/aws-cloudformation/cloudformation-coverage-roadmap

Also, when reporting the issue it helps if you can provide a bit more details to help replicate the issue (e.g. a minimal template that helps reproduce the issue can immensely help)