pulumi
Need to reorder creation/updates of ALB ListnerRule resources
A Pulumi program which creates aws.elasticloadbalancingv2.ListenerRule can get into a state where the stack is essentially wedged. The issue has to do with the fact that priorities must be unique within all of the listener rules attached to an ALB.
If there is an update to a ListenerRule that changes its priority, the update fails with the following error. It's reasonable, but just annoying because the existing listener rule in-use would have been deleted/reassigned if the program continued to execute.
error: Plan apply failed: creating urn:pulumi:pulumi-svc-chris::pulumi-service::aws:elasticloadbalancingv2/listenerRule:ListenerRule::homepage-rule-http-/: Error creating LB Listener Rule: PriorityInUse: Priority '1500' is currently in use
status code: 400, request id: 5c81aec0-2899-11e8-a3be-6f5f10459723
Even if the program is authored correctly, and each ListenerRule is unique, there is an implicit dependency on the order in which the listener rules are created or updated.
I'm not sure how we could generally solve such a problem, other than delaying ListenerRule updates and trying to get clever about ordering.
There's not a repro here to be 100% sure - but I think this must be a case where there are at least two ListenerRule's, with two different priorities. And then, for example, the priorities of the two rules are swapped. I would imagine that an update after that would definitely run into this error.
That is, by itself, by design. That change is an "update", and whichever of the two updates first will try to reuse the priority of the other, which AWS does not allow, which will correctly fail the update.
Indeed, there is no way to accomplish this change without downtime in AWS. The only way to accomplish it would be to delete one of them first, and then update, and then recreate. This is irrespective of Pulumi.
This is, most likely, a key part of why ListenerRule's have a priority mechanism in the first place, to allow rules to be added at any desired priority level, so that things can be reordered without downtime just by moving them to a priority slightly above or slightly below the other, without being exactly the same.
I believe that what is needed here for user code is a rule to not reuse the exact same priority, but to pick a new priority that is aligned correctly relative to the others. Code has to be written to handle any existing deployment of previous instances of the code, so technically should not reuse any priority that there is still a deployed instance of.
In the case that it is not a swap but a one way dependency, it would be possible to workaround with dependsOn to tell Pulumi about the dependency - that the old user of priority N must be updated before the new user of priority N takes it over. Including a dependsOn should work for that.
It is not clear to me that Pulumi or the Pulumi AWS provider has any way to address this at a lower level than those two user level approaches.
Closing out - as I believe this is by design within the limitations of AWS' service design.