Open m-kratochvil opened 1 year ago
For the record: If this issue depends on member weights in Octavia (as opposed to purely AS3/BigIP), please take into account the non-bijective member weight mapping as explained in #129 Edit: I wrote this because I assumed that "priority" means member weights of some kind. If this does not depend on member weights in Octavia please ignore this comment, thank you.
If this issue depends on member weights in Octavia
I can confirm this does not depend on member weights. It is confined to the --enable-backup
option and the priority values.
If this issue depends on member weights in Octavia
I can confirm this does not depend on member weights. It is confined to the
--enable-backup
option and the priority values.
Correct, we don't set any weight here.
When the option "enable-backup" is used at member creation or update, the priority of all the other members in the respective pool is increased by 1. This causes reconfiguration of the whole pool by AS3 and thus all monitor operational statuses for all the existing members are reset to initial status "unknown".
This causes an issue for loadbalancers created out of Gardener/Kubernikus when "ExternalTrafficPolicy: Local" is used. That issue as described in detail in #238
@notandy mentioned we could possibly raise the default priority for members to "2" to prevent the reconfiguration from happening. This would have to be tested, the Big-IP could possibly again raise the priority for the remaining members to "3".
My personal believe is that at this point it's not worth to spend the time/effort on this. This was a finding by Anton when he was testing various ways to create members in context of the above issue, and I'm not aware of any Gardener/Kubernikus loadbalancer deployments that would use/require the backup member option.