Change member weight normalization

[BenjaminLudwigSAP]

We normalize member weight by mapping the 256 possible weights of Octavia to the 100 possible weights of AS3 uniformly. However, this is probably not a good idea, because as a customer I would expect a weight of 2 to be more than 1, but for AS3 they're both the same:

1 => 1
2 => 1
3 => 2
4 => 2
5 => 2
6 => 3
7 => 3
8 => 4
9 => 4
(...)

Better to cut off weights at a hundred (min(weight, 100)) and put a warning on the GUI and docs.

Unfortunately there are already examples of several members on the same pool with different weights, all above 100 (e. g. 200 and 250). They'd all be clipped to a weight of 100, which is unexpected behavior as well.

[BenjaminLudwigSAP]

I also had the idea to map members on a case-by-case basis, that is, simply enumerating the AS3 weights according to the order of the weights on Octavia side. This works well as long as there are no more than 100 members (with unique weights) on any pool. For pools with >100 members we cannot guarantee that there are 100 or less unique member weights. Right now I count one region with any pools that have >100 members: eu-de-1 with 48 pools, 143 members each.

However, that would defeat Octavia's semantics that e. g. a member with weight value 10 receives five times as much traffic as one with weight value 2. In this case, capping at 100 would be better, since it'd retain these semantics.

Another argument for capping at 100 is that there are already a few members that share the same pool, but have only a difference of 1 between their weight values, resulting in the same effective weight value on the backend. This shows that customers are not aware of the mapping and we shouldn't force customers to calculate it themselves.

[BenjaminLudwigSAP]

My suggestion on this is to

• [ ] Enforce a value limit of 100 in Elektra
• [ ] Enforce a value limit of 100 on Octavia API
• [ ] Change mapping to min(weight, 100)
• [ ] Update documentation