Only adding targets retries when the balancer is busy, and every other change to a balancer still fails the whole reconcile on the first temporary rejection.
#59 retries locked, conflict, robot_unavailable and 5xx for adding targets. Removing a target, changing the type or the algorithm, attaching or detaching a network, and adding, updating or deleting a service do not retry. A reconcile that changes several of these in a row, for example the type and then the services, is likely to get 423 locked from the action the previous call started. Then it waits for the next retry of the whole service.
The same code has a smaller case. When Hetzner applies an add-target call but answers with a 5xx, the retry gets target_already_defined. That target is then not counted as live, so a balancer with a single target reports "No target could be added" although the target is there.
I'd like the other changing calls to use the same retry #59 adds for targets, and target_already_defined to count as success when adding a target.
Only adding targets retries when the balancer is busy, and every other change to a balancer still fails the whole reconcile on the first temporary rejection.
#59 retries
locked,conflict,robot_unavailableand 5xx for adding targets. Removing a target, changing the type or the algorithm, attaching or detaching a network, and adding, updating or deleting a service do not retry. A reconcile that changes several of these in a row, for example the type and then the services, is likely to get 423lockedfrom the action the previous call started. Then it waits for the next retry of the whole service.The same code has a smaller case. When Hetzner applies an add-target call but answers with a 5xx, the retry gets
target_already_defined. That target is then not counted as live, so a balancer with a single target reports "No target could be added" although the target is there.I'd like the other changing calls to use the same retry #59 adds for targets, and
target_already_definedto count as success when adding a target.