When a persisted configuration file is read, the values in it are
considered to be more up-to-date than the ones in the main configuration
file. This allows all objects to be persisted in a more complete form
making it easier to change configuration values at runtime.
This change is intended to help make runtime alterations to services
possible.
The `user`, `password`, `version_string` and `weightby` values should be
allocated as a part of the service structure. This allows them to be
modified at runtime without having to worry about memory allocation
problems.
Although this removes the problem of reallocation, it still does not make
the updating of the strings thread-safe. This can cause invalid values to
be read from the service strings.
The service, filter and monitor resources now have a "parameters" value
which contains a set of all configuration parameters for that object. This
set contains both standard and non-standard parameters.
Also fixed a mistake in the constant name definitions for the monitor
parameters "events" and "script".
The service resource now exposes the parameters that were given to
it. This allows general service parameters to be changed at runtime
through the REST API.
A self link to the resource itself provides a convenient way for the
client to request a resource, modify it and call the self link to update
it. This removes some of the burden on the client to keep track of the
resource links by placing these in the resource itself.
The relationships from servers to services and monitors and filters to
services were not implemented. Now each server lists the services and
monitors that use it and each filter lists the services that use the
filter.
This enables the creation of a server and linking of that server to
services and monitors in one atomic operation.
The JSON API (http://jsonapi.org/) specifies a way to express relations in
a somewhat generic way. By moving towards a more generic schema for the
resources, it will be easier to handle the modification of the relations
between these resources.
When a resource has a relation to another resource, it should be expressed
as a working link to the resource. By passing the hostname of the server
to the functions, we are able to generate working relation links.
If a resource can be accessed from more than one place, it should be a
link. The previous change that duplicated the content for nested resources
wasn't a very clean solution. With links, the content is easier to browse
using a normal browser.
The modules that implement a diagnostics entry point now return a JSON
type object. This removes the need to format data inside the modules.
The module implementations of these are not yet complete which means that
MaxScale will fail to compile.
As a service is a collection of other resources, it makes sense to expand
those resources that were previously expressed as relative paths. This way
the API can be readily consumed without altering the pathnames to
links. The downside to this is the increased bandwidth consumption and
possible excess data.
The functions don't modify the filters when the JSON is generated. This
means that the parameters can be const.
Minor formatting fixes to service sources.
Both the filters and services can be queried via the REST API now that
these resources can be expressed in JSON format.
As with the other resources, these directly call the functions that
generate the data. This will be done via the inter-thread messaging system
once it's in place.
