Hello,
On Sun, Aug 29, 2021 at 11:28:43AM +0000, Prytoegrian wrote:
> I think I found a bug in Haproxy but I first want to be sure it's a real one.
> It might just be a semantic misunderstanding of mine.
>
> I described a backend with two servers, one of them with "slowstart" option.
> When I set it in maintenance then ready again, CLI `get weight` doesn't show
> current weight, like the stat page could displays, but the user defined one.
>
> The documentation in the associated function states
> ```c
> // cli_parse_get_weight
> /* return server's effective weight at the moment */
> ```
> effective weight having a precise meaning in haproxy.
The CLI's documentation (management.txt) is correct and says:
get weight <backend>/<server>
Report the current weight and the initial weight of server <server> in
backend <backend> or an error if either doesn't exist. The initial weight is
the one that appears in the configuration file. Both are normally equal
unless the current weight has been changed. Both the backend and the server
may be specified either by their name or by their numeric ID, prefixed with a
sharp ('#').
We wanted the "get" commands to perform the opposite of "set" so that
scripts can use "get" on a value, recompute it and send the new one
with "set".
Regarding servers' weights, there are 3 values:
- the initial one (that would rather be called the configured one),
it is the weight that was initially configured with the server and
that is used for percentages (e.g. if you change your weight to 50%,
it's 50% of this one).
- the user weight, which is the currently configured one, as the
result of a "set weight" command, either using an absolute value
or a relative one. It *used* to be called the effective one a long
time ago (which explains the comment you found in the source file
above).
- the effective weight, which is the one applied to the server at the
moment you're watching, and which is the user weight modulated by
the slowstart ratio. This one is reported in the stats so that it's
visible why a server only takes a small amount of charge (some users
used to have very long slowstart periods and were confused without
it).
Lesson learned: "never call something effective as you might still find
a new way to post-process it down the chain later"!
We could imagine to add the effective one to the "get weight" output
as well, but then we'd need to be extremely careful not to break
possibly existing scripts that rely on dumping $3 or last field etc
so that's not as easy as it seems.
> Did I understand the expected behavior right ?
Both yes and no :-) There was some confusion induced by the feature
having been extended over time to include a third value.
Hoping this helps,
Willy
