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.
When default parameters are loaded, the type and module name are
added. This helps object serialization and allows all the code to expect
that all the parameters needed to create an object are always present.
The last server wasn't removed as the set of relationships was empty. In
addition to this, changes to relationships via the relations endpoint
wasn't reflected by the monitor parameters.
If a monitor was created at runtime, it was missing some parameters that
were assumed to be always present. In addition to that, the parameters
weren't validated against the list of common and module parameters.
Since the monitors always reconstruct the server list, the new servers can
be stored as a parameter. To make this possible, the
server_relationship_to_parameter helper function is needed.
This commit fixes the MaxCtrl test suite failures but does not fix the
failures in the REST API test suite.
Reactivating monitors shouldn't be done as it's simpler to actually
destroy and create a new one. The performance of reactivation is
insignificant compared to the possible inconsistency problems it allows.
Storing all the runtime errors makes it possible to return all of them
them via the REST API. MaxAdmin will still only show the latest error but
MaxCtrl will now show all errors if more than one error occurs.
Alterations to monitors are now done with all changes present in the first
call to configure. This fixes the case where two parameters depended on
each other and one would get configured before the other.
The rank can now only be used to define two groups of servers: primary and
secondary servers. This limits the exposure and reduces the number of
possibilities that can arise from the use of this parameter thus making it
more predictable.
Although the default value is the maximum value of a signed 32-bit
integer, the value is stored as a 64-bit integer. The integer type
conversion functions return 64-bit values so storing it as one makes
sense.
Currently values higher than the default are allowed but the accepted
range of input should be restricted in the future.
