Le 1/11/22 à 22:47, William Dauchy a écrit :
Agree. But, if possible, a warning may be added in the documentation to warn
about implicit changes.

 From the discussion, I would be tempted to say the opposite, as I feel
like keeping implicit things for this command is worse.

I don't know what is the expected behavior on the stable releases for users. The actual state is buggy because health-check are only updated when ssl is disabled. When SSL is enabled on a server, there is no implicit change on the check. when SSL is disabled, there is an implicit change. So we must first state for the expected behavior on stable releases. But, keep in mind there is no way to dynamically enable/disable SSL on health-checks. So if a user configures the SSL on its server but disables it on startup, when he enables ssl, he probably want to do so on the health-check, explicitly or not.


as mentioned above I am not sure I am aligned here; I would rather
remove the side effect of changing s->check.

Honestly, I've misread you patch and kept in mind you alternative solution... But as said, if there is no implicit change (and I'm fine with this solution), a new command or an option to current ones must be introduced to be able to change SSL setting for health-check too. Otherwise, it will be unusable.

Note I don't know if all this stuff works properly with the server-state file...

I am always scared to look at the server state functionality...

I truly understand :( ...

--
Christopher Faulet

Reply via email to