Instead of using the correct version in in-source builds, a dummy file is
copied in place. This removes the need to explicitly include the
VERSION.cmake file.
The VERSION.cmake file defines which VERSION.cmake file is included. By
changing the file that it points to, the version can be changed without it
affecting other parts of the code that use it.
When MaxCtrl is being built, the source is copied into the build directory
to prevent polluting the source tree with node_modules. This means that
any relative references MaxCtrl builds make outside of the maxctrl
directory must be copied to the build directory.
Displaying the MaxScale version helps identify which package the
executable was bundled with. As the MaxCtrl source is a part of MaxScale,
there's no need for separate versioning.
If only one server is used, the amount of requests can be reduced from a
minimum of two to a minimum of one. In most cases this cuts down the
response time in half.
Being able to perform raw REST API calls that leverage the value
extraction capabilities of Node.js gives more control to the end user. It
also doubles as a handy tool for creating scripts that only require one
particular value from the REST API.
When the -p parameter is given without an argument, the password is read
from the command line. This allows passwords to be given to MaxCtrl in a
safer manner.
Test that `list servers` works with both monitored and unmonitored
servers. The test doesn't check that the GTID is present as the test setup
uses file and position based replication.
When TSV output is requested, the output should not contain the ANSI color
codes. This appears to be a "feature" of the table generation library but
it is quite simple to work around.
When the servers were iterated, each related monitor was requested. This
caused as many requests for monitors as there are servers.
By creating a set of unique monitor names and requesting them once, we
avoid the redundant requests from the monitor.
The function getResource had two different implementations that did very
different things. The newer version, that returns the raw JSON object that
represents a resource, was renamed to getJson.
Added the `GTID` field to make it easier to track GTID values of the
servers. This is done by requesting the related monitors for each server
and injecting an extra parameter into the server resource.
MaxCtrl now supports explicit paths for certificates and optional server
certificate verification. This allows testing by using a self-signed
certificate with the server certificate verification turned off.
Using commas instead of spaces prevents a the misinterpretation of
commands as hostnames. If the `--hosts` option was given just before a
command, it would consume the commands as arguments to the `--hosts` list.
The internal header directory conflicted with in-source builds causing a
build failure. This is fixed by renaming the internal header directory to
something other than maxscale.
The renaming pointed out a few problems in a couple of source files that
appeared to include internal headers when the headers were in fact public
headers.
Fixed maxctrl in-source builds by making the copying of the sources
optional.
The scripts start MaxScale processes on two different servers. The support
framework for the tests is in place but the tests themselves still need to
be modified to allow the use of non-localhost addresses.
The yargs framework combined with the pkg packaging causes the executable
name to be mangled on installation. For this reason, the usage should be
explicitly added to each command.
The timestamp of the last change from passive to active is now
tracked. This, with the timestamps of the last master_down and master_up
events, allows detection of cases when MaxScale was failed over but the
failover was not done.
Currently, only a warning is logged if no new master has appeared within
90 seconds of a master_down event and MaxScale was set to active from
passive.
The last event and when the event was triggered is now shown for all
servers. The latest change from passive to active is also shown.
The enabled admins for the Linux users were shown as basic users. This was
caused by the separation of the two admin types.
Added tests that check that enabled Linux accounts show the correct type
in the output.
The documentation stated that the users are created with administrative
privileges by default when in fact they were created with read-only
privileges.
Updated documentation generation script and regenerated documentation. Now
all command documentation is generated by using the output of the `help`
commands.
