[lbaas] Health monitors: Fix mapping of max retries to API parameter #1175
Conversation
BenjaminLudwigSAP
requested review from
edda,
andypf,
ArtieReus and
hgw77
as code owners
|
Hi @BenjaminLudwigSAP thank you for the notice and the PR. I just have seen, that it should be also changed in other parts of the application as the HM model or the edit view, etc. I will check it next week. |
Probe Timeout (`timeout` on the API) is not honored by the Octavia provider driver. This is intentional. I understand this might be confusing, so an optional detailed technical explanation can be found below. PR #1175 might seem similar to this, but it's not; #1175 fixes a mapping between Elektra parameter name and API parameter name, while this PR removes an unused parameter entirely. Optional detailed technical explanation: Health monitors on the F5 backend only accept two parameters: `interval` and `timeout`. While the `interval` backend parameter has the same semantics as the `delay` Octavia API parameter (that is, the amount of seconds between probes), the `timeout` backend parameter has slightly different semantics than the Octavia API `timeout` parameter: While the `timeout` Octavia API parameter denotes the timeout *of a single probe*, the `timeout` backend parameter denotes the timeout `over all probes`. Therefore the `timeout` Octavia API parameter cannot be used here. Instead we calculate the `timeout` backend parameter (that is, the overall timeout) as the value of the `max_retries_down` Octavia API parameter (that is, the number of failing probes before the member is set to OFFLINE) multiplied by the `delay` Octavia API parameter (that is, the amount of seconds between probes) plus one spare second to give the last probe a chance to not run into a timeout. That calculation happens here: https://github.com/sapcc/octavia-f5-provider-driver/blob/stable/yoga-m3/octavia_f5/restclient/as3objects/monitor.py#L122
max_retries has been split up in Octavia API into max_retries and max_retries_down. max_retries_down specifies the amount of retries for a HM before the pool member is considered down, while max_retries specifies the amount of retries for a HM before the pool member is considered up again. We're only interested in the max retries before a member is down.
BenjaminLudwigSAP
force-pushed
the
lbaas_hm_fix_maxretries
branch
from
cafaee6 to
b9d432c
Compare
|
(the force-push was to remove the change of Max Retries maximum value from 10 to 9. Turns out 10 is indeed the maximum value accepted by the Octavia API, while 9 is the maximum number accepted by the CLI... m( |
|
@BenjaminLudwigSAP are you sure that you can submit a HM without The API description for the field |
|
Thanks for pointing this out. I suggest always supplying a fixed value of 1 for |
|
Closed in favor of #1179 |
max_retrieshas been split up in Octavia API intomax_retriesandmax_retries_down.max_retries_downspecifies the amount of retries for a HM before the pool member is considered down, whilemax_retriesspecifies the amount of retries for a HM before the pool member is considered up again.We're only interested in the max retries before a member is down.