Hi Willy, thanks for your message. I studied the code base responsible of CLI response, it's indeed tricky to change.
In your opinion, what's the next step ? Is creating a new bug issue relevant ? Prytoegrian Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Le jeudi 2 septembre 2021 à 14:49, Willy Tarreau <[email protected]> a écrit : > 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 > > > > // 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
publickey - [email protected] - 0xD78075EC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
