The path type is validated if the module requested path
validation. Service checks can be done both on startup and at
runtime. This allows dynamic changes to module parameters to be validated
without a configuration context.
The options allow the modules to impose type specific restrictions on the
parameters. This can be used to offload file permission and mandatory
parameter checks to the core.
All monitors now declare the parameters that they use. This allows the
core to check the validity of the parameters before they are passed to the
monitor. It also simplifies the processing of the parameters as they are
guaranteed to be valid.
The declared parameters are now used to check whether the configuration is
valid. As the filters and monitors don't use the new declarations, the
code needs to be commented out. Once the parameter processing has been
migrated to the new system, the code can be enabled.
Filters, monitors and routers can now declare parameters and those
parameters will always be present. Currently, this removes the need to
parse simple values like booleans and integers.
Some of the more common parameter types could be added in the future
e.g. paths to files.
The MXS_MODULE structure now contains a member for parameters. This can be
used by the modules to declare accepted parameters, their types and the
default values. Currently only count, integer, boolean, string and enum
values are supported.
The configuration processing requires that all parameters for monitors
exist before they are used. This is wrong if we are aiming for a modular
system but is a necessary evil for the time being.
If no message is logged, it will be very hard to figure out where some
configurations are coming from. For this reason, it's good to log a
message whenever a persistent configuration change is taken into use.
The code prevented scaling by imposing global spinlocks for the DCBs and
SESSIONs. Removing this list means that a thread-local list must be taken
into use to replace it.
The service header in include/maxscale/ contains the public part of the
service API. These functions can be safely used by the modules.
The internal header located in service/core/maxscale/ is used by the core
to initialize MaxScale at startup or to provide other services in a more
controlled way (the config_runtime, for example).
The created listeners are now stored to disk like created servers
are. This allows them to be used even after a restart.
Currently, the listeners cannot be deleted and need to be manually
removed.
The modules can now return human-readable error messages to the caller of
the function. The internals of the modulecmd system also use this to
return errors to the users.
The error messages can be retrieved with a common error function which
should make it easy to use in various clients.
When a server is added to a monitor, an supplementary configuration file
is generated to persist this information. This will allow dynamic
modifications to server lists which will survive restarts and unexpected
downtime.
The monitor will only add new servers to its list of monitored
servers. This prevents duplicate entries in the list and makes it safe to
persist all used servers to the supplementary configuration file instead of only the ones that are not listed in the main configuration.
The functions allow simple operations on configuration context
objects. This makes it easier to understand what the code does and allows
reuse of the configuration processing code.
Server creation and allocation are now the same apart from the fact that
allocation only adds the server to the running configuration where as the
creation of a server also persist it to disk.
The server serialization should not be seen through the server.h API. This
allows the serialization method to change without actually having to
change the interfaces.
Previously, negative values were allowed for persistpoolmax and
persistmaxtime. Now they cause an error. Also, monitor_interval
allowed negative (or zero) values, which were then implicitly cast to
unsigned, causing unintended behaviour. Now this causes a warning
and the default value is used.
The persisted configuration directory is created and/or read when MaxScale
starts. This allows the servers created at runtime to be recreated when
MaxScale is restarted.
The persisted configuration subdirectory will be used to store changes to
the configuration. The gwdirs.h header now supports setting and getting
the value for this directory.
The address, port, monuser and monpw parameters of an existing server can
be changed at runtime. The support for enabling SSL will come in a later
commit.
Allowing servers to be modified could also be done by destroying and
recreating them. Since the servers are never actually destroyed, it is
better to allow the alteration of the existing ones.
MaxScale can now start without any defined monitors. This allows the core
services to be configured beforehand. With the changes to dynamic
modifications to servers, automatic scaling of slaves is possible.
The check for the success of the configuration file always resulted in a
successful return value even if the loading failed.
In addition to this, a log message referred to the active configuration
when the active configuration was set only after the processing was
complete. Since configuration failures are always fatal, there's no harm
in preemptively setting the active configuration to the one currently
being processed.
Given a config file "config.cnf", we look for the directory
"config.cnf.d" and recursively in that hierarhcy load all files
whose suffix is ".cnf"; other files are ignored.
Currently duplicate sections are checked on a file by file basis.
That will be changed so that duplicate sections are not allowed
across all the files.
The dbusers.c was a MySQL protocol specific file which was used directly
by some of the modules.
Added a new return value for the loadusers authenticator entry point which
allows fatal failures to occur when users are loaded. Currently this is
only taken into notice when the service is first started. If a listener
later returns a fatal error, it is only logged but the service stays in
operation.
Moved the MySQLAuth authenticator sources and the tests that relate to
this module into a subdirectory in the authenticator
directory. Eventually, all authenticators could have a subdirectory of
their own.
In a subsequent change, the includes of server/core/*.c will be
cleaned up, and if there is a common set of include files, needed
by most, then a server/core/maxscale/core.h that includes those
will be introduced.
The general purpose stuff in skygw_utils.h was moved to utils.h
and the corresponding implementation from skygw_utils.cc to utils.c.
Includes updated accordingly.
Skygw_utils.h is now only used by log_manager and by mlist, which
is only used by log_manager. Consequently, skygw_utils.h was moved
to server/maxscale.
Utils.h needs a separate overhaul.
- STRERROR_BUFLEN moved to cdefs.h and renamed to MXS_STRERROR_BUFLEN.
Better would be to provide a 'const char* mxs_strerror(int errno)'
that would have a thread specific buffer for the error message.
- MIN and MAX also moved to defs.h as MXS_MIN and MXS_MAX.
- Now only mlist.h of the headers depend upon skygw_utils.h.
- Headers now to be included as <maxscale/xyz.h>
- First step, no cleanup of headers has been made. Only moving
from one place to another + necessary modifications.
Authenticators now have a similar mechanism to the `router_options`
parameter which enables configurable authentication.
The authenticators also have a new initialize entry point which is similar
to the createInstance entry point of the filters and routers. The value of
`authenticator_options` is passed as a parameter to this function. The
return vaulue of the `initialize` entry point is passed to the `create`
entry point.
The backend responses are now read in one place and the functions just
read the data. The protocol level will now handle the packet gathering
process and the authentication part just inspects the data.
Backend connections now load authenticators when they are being
connected. In the future, this enables the use of authentication modules
for backend connection.
The mysqlmon simple failover mode allows it to direct write traffic to a
secondary node. This enables a very simple failover mode with MaxScale
when it is used in a two node master-slave setup.
MaxScale shouldn't require the service and monitor user checks. It makes
sense to disable the checks to speed up the startup process when the user
knows that the permissions are OK.
The mysqlmon now supports proper detection of multi-master topologies by
building a directed graph out of the monitored server. If cycles are found from
this graph, they are assigned a master group ID. All servers with a positive
master group ID will receive the Master status unless they have `@@read_only`
enabled.
This new functionality can be enabled with the 'multimaster' boolean
parameter.
