If a service was created at runtime, it would be in the Allocated state
until it was stopped. The serviceStart function isn't necessary from a
functional point of view (a new service cannot have listeners that need
starting) but it does set the correct state and it's the "right" thing to
do.
Monitors created via the REST API that were started and configured
successfully should also be started. This removes the extra step of
starting the monitor after creating it.
The parameter validation for all module types follows roughly the same
path: first check whether it's a known parameter and then whether the
value is valid. This can be moved into common functions that removes
duplicated code.
The SSL initialization should only be attempted if `ssl_key`, `ssl_cert`
or `ssl_ca_cert` is defined. In addition to this, the SSL parameters
requirements for servers and listeners are different: servers require only
`ssl_ca_cert` but listeners require all three.
The runtime modification of servers, services and monitors now validates
the parameters before starting the update process. This guarantees that
the set of parameters is valid before it is processed.
After the validation, the parameters are now also stored in the list of
configuration parameters. This will simplify the serialization process by
removing the need to explicitly serialize all common object parameters.
If a module is not found, a proper error message is now given to the
user. Other system errors are also printed if errno is set. Dynamic
library errors aren't printed as they are apparently reset after a call to
`dlerror`, at least according to documentation.
Took the size type validity check function into use in runtime
configuration. This fixes the problem with zero not being accepted as a
valid size for query_classifier_cache_size.
If the filter does not declare defaults and no parameters are defined, the
list of parameters would be NULL. This was interpreted as an error and the
filter creation failed.
The functions
bool runtime_is_string_or_null(json_t* json, const char* path);
bool runtime_is_bool_or_null(json_t* json, const char* path);
bool runtime_is_count_or_null(json_t* json, const char* path);
can now be called from anywhere inside MaxScale.
If a relationship isn't defined, it should not be removed. Only if a
relationship is change to a null relationship, should it be removed.
Also fixed the maxctrl test suite to verify that both it and the REST API
tests pass.
The data of the relationship should be set to null to delete the
relationship. Conceptually it is different from setting it to an empty
relationship but in practice both lead to the same end result.
Updated tests to use correct relationships and added test cases for
detection of invalid relationships.
The filter relationships of a service are now interpreted as an ordered
list of filters being used by the service. As the relationship data in the
JSON API specification is represented as an array, it does not prevent
multiple relationships from appearing. For MaxScale, this means that
interpreting the filter's order does not break it.
Removed the explicit setters for the service parameters. Not all of them
were implemented and they were only used internally. Moved the parameter
validation and update processing inside the Service class to reduce the
load on the other parts of the core.
The service now uses a std::vector<SFilterDef> to store the filters it
uses. Most internal parts deal with the SFilterDef but debugcmd.cc still
moves raw pointers around (needs to be changed).
Comparing two fixed std::strings would have equal C strings but comparing
with operator== they would be different. This was a result of the string
modification done by fix_object_name.
Converted the internal header into a C++ header, added std::string
overload and fixed use of the function.
The filter implementation is now fully hidden. Also converted it to a C++
struct allocated with new and stored the filters in a global list instead
of embedding the list in the object itself.
The relationships of a service are handled by the service alteration
code. Currently, only server relationships are handled by the code in
question and filter relationships are ignored.
If an invalid value or type is given to the REST API, having the expected
type as well as the given type make problem resolution easier.
Also added a value check into MaxCtrl for listener ports.
Services can now be destroyed if they have no active listeners and they
are not linked to servers. When these conditions are met, the service will
be destroyed when the last session for the service is closed.
The closing of a service will close all listeners that were once assigned
to the service. This allows closing of the ports at runtime which
previously was done only on shutdown.
Exposed the command through the REST API but not through MaxAdmin as it is
deprecated.
The runtime configuration JSON validation now allows multiple
relationships to be verified at one time. This makes it easier to validate
all objects using the same framework.
The C++ version with the lock guard is easier to manage when there are
multiple return points from a function. It also makes sure that the lock
is freed after it's used.
The configuration system that modules use allows the SSL parameter
validation to be simplified. It should also provide more consistent error
messages for similar types of errors.
The SSL_LISTENER initialization is now done in one step. There was no good
reason to do it in two separate steps for listeners but in one step for
servers.
The `ssl` parameter now also accepts boolean values. As the parameter
behaves like a boolean and looks like a boolean, it ought to be a
boolean. It still accepts the custom `required` and `disabled` values
simply for backwards compatibility.
Also added the missing freeing functions for the SSL_LISTENER type. This
prevents failed SSL_LISTENER creations from leaking memory.
The common monitor parameters are now stored as module-style
parameters. This makes the error reporting as well as the type checks for
the parameters consistent with parameters declared by the modules.
The same mechanism that is used for modules can be used for the
configuration of the core objects. This removes the need for the redundant
code that validates various values that is already present in the code
that modules use.
If a router parameter has no default value, the previous value would be
returned as an empty string. A debug assertion would be triggered when a
parameter of this type was altered.
When a new router parameter is encountered and the alteration fails, the
modified value in the service need to be removed. Previously, the new
value would have been stored in the service with an empty value which
would have caused problems.
Extended the test to cover modifications to readconnroute as well as do
checks on detection of invalid parameters.
Also allowed modifications to router_options at runtime.
