(ElasticLoadBalancingV2): CDK to automatically calculate priority for host-based load balancer rules

[mimozell]

Use Case

When creating a host-based load balancer rule, I really don't care about the rule priority because I rely on exact matches, so I don't want to have to keep track of the priority values and make sure I don't try to set the same value twice or else I'll get an error on deployment. I realize this is a problem with AWS itself (it should really be fixed there so no one would have to do anything custom like today), but other tools like Terraform have solved this problem internally so that the end user doesn't have to care about it. It would be great if CDK did this by default as well, and the user would provide the value if there's an exception to the rule.

Desired behavior:

When creating a load balancer rule like this:

        ApplicationListenerRule.Builder.create(this, "Listener Rule")
            .action(ListenerAction.forward(listOf(defaultTargetGroup)))
            .conditions(listOf(ListenerCondition.hostHeaders(listOf(hostName))))
            .listener(httpsListener)
            .priority(1)
            .build()

I shouldn't have to add the priority myself as I don't rely on priority matches when using host-based rules.

---

This is a 🚀 Feature Request

[njlynch]

Thanks for the feature request.

This seems reasonable; we could keep track of existing rules, and if no priority is specified, set the priority based on the count (and/or priority) of existing rules. One "gotcha" will be that we currently use the presence of priority in ApplicationListener.addAction to determine if we create a rule or not. That can likely be handled, however.

[mimozell]

Sounds good. I would just increment by one the highest priority used by any existing rule. There will be issues with concurrency - if multiple stacks are trying to create a rule with the same generated priority at the exact same time, then that will fail, but perhaps a good error message is good enough? Ideally there would also be some automatic retries with the next available priority, but that's not absolutely necessary to have as long as the error message is there.

[efrodriguez]

Any update on this? @njlynch have you found a workaround for this?

[metametadata]

Our current workaround is to assign a priority based on hashing the rule's unique ID. In Clojure:

rule-id (str domain "-rule")
priority (mod (hash rule-id) 50001) ; Range: 0-50000

...

(-> (ApplicationListenerRule$Builder/create stack rule-id)
     ...
     (.conditions [(ListenerCondition/hostHeaders [domain])])
     (.priority priority)
     .build)

It's prone to hash collisions but we were lucky so far.

[Kazpers]

Is there anything new on this one @ericzbeard @rix0rrr or others? It's a serious deficiency (although I know it's the fault of underlying AWS, not cdk), that makes it extremely hard to use CDK for deployments involving multiple listener rules. We really don't want to micro-manage priority for hundreds of services that each have a forward rule on the ALBs...

The workaround with hashes is... fragile. I appreciate it as a temporary measure, but I really don't want fragility in my ops deployments...

[github-actions]

This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue.

[juinquok]

Just wondering if anyone has any idea if using AwsCustomResource will be able to solve this problem? If so, it might be possible to use a aws-sdk call via the custom resource to derive the rule priority. Else, if anyone can point me in the right direction of where the aws-sdk can be added in the aws-cdk codebase, I would be happy to give this a go.

[luxaritas]

I want to add my support for this as well. I wound up implementing this by having a global counter my stacks could reference, but I wound up realizing that if I reordered or inserted a stack between stacks that used it, deployments would fail since all of the stacks would change their priorities (and the first stack would try to take the ID already assigned to the second stack, etc). Would be great to have the CDK figure it out!

[adamghowiba]

I'd also like to add my support for this. It's very difficult to handle ALB priorities at CDK level. I also implemented a solution similar to @luxaritas, which works well until I reorder my ALB rules.

I can't seem to come up with a temporary solution, aside from removing ALB rules beforehand, utilizing hashing, or making AWS API calls before running deployments. All solutions are problematic.

Would love to see a feature like this implemented.

[MayconFrr]

Bump

Edit: Also would be nice to have a parameter to set if I want to get the first available priority using a first-to-last or last-to-first strategy

[marwan-alloreview]

Would also be very interested by this

[timothy-cloudopsguy]

Attempted this with 146 domains, and had 9 collisions.

def hash_modulus(i: str, n: int):
    snum = 0
    for c in i:
        snum += ord(c)
    m = snum % n
    return m

where i == domain name, and n == 50001

Also, FWIW... when deploying the same stack that creates iam roles/policies to us-east-2 and us-west-2 i get collisions with the internal naming function in CDK. So whatever they use to unique/hash also is collision prone.

[metametadata]

This is a poor hashing algorithm as it seems to lack uniform distribution: https://web.stanford.edu/class/archive/cs/cs106b/cs106b.1172/handouts/8-Hashing.pdf.

[rogerchi]

FYI, this is how I've solved it for our use cases: https://github.com/rogerchi/cdk-listener-next-available-priority

[n-miles]

Adding another bump to the pile

[Kazpers]

The lack of action (or even an update) on this after over 3 years is very disappointing. How can we take CDK seriously as an ops tool this way?