In cases where servers are known to be down on startup, this feature does
more harm than good. Disabling it in these cases would be preferable but
due to how the parameter is used, it is not possible.
The TLS parameters were defined but the main parameter that enables it
wasn't automatically added. As the REST API documentation states that this
parameter does not need to be defined, the runtime configuration must add
it.
The servers created via the REST API now use code separate from the
maxadmin interface. This removes the cumbersome requirement of having to
first create the server and then configure it. With this change, it is
possible to completely remove the ability to set the server SSL after
creation.
Since listeners cannot be reconfigured, we can accept this limitation and
impose it on the servers as well. This keeps the behavior consistent and
removes the need to resolve the deletion issue (for the time being).
The Listener::create method now takes a set of configuration parameters
from which it constructs a listener. This removes the duplicated code and
makes the behavior of listener creation similar to other objects in
MaxScale. It also allows the configuration parameters to be stored in the
listener object itself.
The functions that searched for listeners compared both sockets and
addresses in the same function. This made its use error prone and caused
false positives in some cases.
With the addition of SO_REUSEPORT support, it is no longer possible to
rely on the network stack to prevent multiple listeners from listening on
the same port. Without explicitly checking for the ports it would be
possible for two listeners from two different services to listen on the
same port in which case the service would be almost randomly chosen.
The creation of a monitor from JSON relied on the non-JSON version for the
addition of default parameters but it proceeded to check the validity of
the parameters before it. Whenever parameters are checked, the default
parameters should be present.
If the last server was removed, the parameter would be rejected due to it
being empty. To remove the parameter, the
MonitorManager::reconfigure_monitor should be used. Also fixed the
unnecessary serialization after a failure to remove server from a monitor
and the fact that some errors were logged instead of written to the caller
of the command.
This way the state is encapsulated in the object and the required changes
are done in one place. This makes the code reusable across all functions
making it easier to implement better monitor alteration code.
