The module commands can now produce JSON formatted output which is passed
to the caller. The output should conform to the JSON API as closely as
possible.
Currently, the REST API wraps all JSON produced by module commands inside
a meta-object of the following type:
{
"meta": <output of module command>
}
This allows the output to be JSON API conformant without modifying the
modules and allows incremental updates to code.
The regex strings are compiled automatically. During file parsing,
the string is compiled once using default settings to check that
the pattern is valid. Once a module asks for the compiled pcre2_code,
the pattern is compiled again with module given settings.
The regex string in the config file should be enclosed within '/ ... /'
Refactored the backend authentication functions so that they can be
exposed to the tee filter. This allows the tee filter to use the same
functions as the protocol modules use without having to reimplement them
inside the tee filter.
The module command self links now point to an endpoint that executes the
module command. Depending on the type of the module command, either a GET
or a POST request must be made.
A quoted string is a string enclosed in '"':s. This makes it clear
where the string begins and ends, avoiding ambiguity with whitespace.
After the config file has been loaded, the '"':s at the beginning
and at the end of the string are erased. Querying the config value
with config_get_string() will return this de-quoted value.
For example, if the config file reads 'my_string="test""', the actual
string will be 'test"'.
The /users/ resource shows all user accounts that can be used with
MaxScale. This resource is further split into two resource collections,
/users/inet and /users/unix, which contain the network users and Linux
accounts respectively.
The REST API now uses the same users as MaxAdmin network interface. This
allows them to be created with MaxAdmin.
The next step is to add user creation to the REST API.
The requests that send a body should define at least a `data` member.
Added a simple test that checks that bad requests are rejected. This test
should be expanded to check that the returned error body contains the
correct members.
The template class wraps a HashMap such that only a few operations
are allowed. Usage requires specializing a RegistryTraits class
template for each entry type.
The /maxscale/ resource now has values for most of the configuration
parameters in the [maxscale] section as well as the version, commit and
uptime information.
If a connection has not been fully established (i.e. authentication has
been completed) then it should not be considered as a connection pool
candidate.
The server internal session id may be larger than 4 bytes (MariaDB uses 8)
but only 4 are sent in the handshake. The full value can be queried
from the server, but this query is not supported by MaxScale yet. In any
case, both the protocol and MXS_SESSION now have 64 bit counters. Only the
low 32 bits are sent in the handshake, similar to server.
The top level resource self links pointed to the collection instead of the
resource itself. The individual resoures now also have a links field that
contains the self link to the resource. This should make navigation of the
API easier as all objects have valid links in them.
The listener iterator hides the details of the listener iteration behind a
small set of functions.
The following for-loop demonstrates the main use-case for the iterator:
LISTENER_ITERATOR iter;
for (SERV_LISTENER *listener = listener_iterator_init(service, &iter);
listener; listener = listener_iterator_next(&iter))
{
/** Do something with the listener */
}
As the listeners are mostly iterated to either check a fact about them or
print their information, the functions cater to that use-case. For this
reason, they should always be allocated off the stack.
The service port list is now iterated in a safe and lock-free manner. This
makes the handling of service ports somewhat simpler since once an item
has been added to the list it will never be removed. It also removes the
need to lock the service when checking whether a service listens on a port
which caused potential deadlocks.
The listeners under the /services/:service/listeners collection are now
fully JSON API compliant resources.
The listeners could also be exposed as a /listeners collection to easily
group all listener type resources in one place. This approach does has
some semantical and practical problems, namely the fact that each listener
has a many-to-one relationship with its service and listeners by
themselves can't exist alone.
The JSON API specification suggests that the API returns the 403 Forbidden
error when the user does an invalid request. The 400 Bad Request isn't the
ideal error for cases where the syntax is correct but the action being
performed is wrong.
Using the JSON Pointer syntax specified in RFC 6901
(https://tools.ietf.org/html/rfc6901) allows for a convenient way to
access values deep in a JSON object.
The JSON objects that are created from the various core MaxScale objects
share a lot of common code. Moving this into a separate files removes the
redundant code.
The sessions resource now follows the JSON API specification:
http://jsonapi.org/
This makes the API relatively easier to use as the specification and the
client libraries to consume this data exist.
The atomic compare-and-swap can be used to implement lock-free
structures. The planned use for this is to remove some of the locking done
in the services when listeners are being manipulated.
Various small changes to part2, as suggested by comments and otherwise.
Mostly renaming, working logic should not change.
Exception: session id changed to 64bit in the container and associated
functions. Another commit will change it to 64bit in the session itself.
MySQL sessions are added to a hasmap when created, removed when closed.
MYSQL_COM_PROCESS_KILL is now detected, the thread_id is read and the kill
command sent to all worker threads to find the correct session. If found, a
fake hangup even is created for the client dcb.
As is, this function is of little use since the client could just disconnect
itself instead. Later on, additional commands of this nature will be added.
The modules, their types and default values are exposed via the
/maxscale/modules resource. Currently, only a list of resources can be
exposed as the externally exposed module object (MXS_MODULE) does not have
the name and type information in it.
