Before creating the users, the master will do a RESET MASTER to remove the
automatically generated binlogs. The servers should now start a lot faster
since they no longer need to replicate the large amounts of data that were
in these generated binlogs.
The service and server tests were deleting the relationships object and
posting a body without it instead of posting an empty relationships object
to delete relationships.
The cli part of the code just passes the process argument vector the the
core part. The core part contains the actual functional parts of the
code. This split is done to make testing easier.
The host and port options were replace with one hosts option which
combines the two. This allows a single command to be executed on multiple
maxscale instances. Added accompanying code for checking responsiveness of
all maxscale instances and handling synchronization of the check
results. The code uses ECMAScript 2016 native promises to do this.
Added a configurable timeout to all requests. This should allow users to
interact with MaxScale over slow and laggy networks.
Before each executed command, all hosts given as parameters are pinged to
make sure they are alive. This should reduce the possibility of partial
execution of commands due to failed MaxScales.
The results of requests are grouped by the values of the hosts
option. This allows users to compare results of multiple servers with
relative ease.
Fixed reversion of the default credentials from mariadb:admin to
admin:mariadb.
The schemarouter should always use Backend::write for communication with
the backend servers. This keeps the backends in the correct state.
This fix solves some of the random test failures in the `sharding` test.
The keyword in the Json is now "match" and MatchRule class substitutes
CaptureRule
"replace": {
"column": "d_code",
"match": "(?<=aaa).*(?=-12)|(?<=-12).*"
},…
The tests should not drop the test database and then recreate it. This
adds an unnecessary burden on replication which will cause false positives
when replication is not fast enough.
When a PATCH request to a resource is made with no relationships defined,
it should be interpreted to be the same as the old relationships. Removal
of relationships can still be done by defining an empty relationships
object.
Altering monitor parameters without defining the relationships was
interpreted as an attempt to remove all relationships. This test
reproduces the problem.
The link/unlink commands are similar to the add/remove commands in
MaxAdmin but they link services and monitors to a list of servers instead
of linking servers to a list of either services or monitors. This can
reduce the number of required calls to alter the configuration while
making the process easier for MaxCtrl to do via the REST API.
Also fixed a false negative where a service alteration which results in a
no-op would be counted as an error.
Servers, monitors and listeners can now be created and destroyed with
MaxCtrl.
Exported lodash as a part of the common.js module so that commands can use
it to construct objects. If there are enough common uses of this library,
some of the object construction could be moved to the common module.
The common error logging function prints and colors the output in an
uniform way. The updateValue function allows easy PATCH updates to a
single value of a resource.
All resoures now use the `state` member to describe their internal
state. This includes servers, services and monitors. This means that the
`status` keyword can be reserved for something else and it can be removed
until it is needed again.
Changed the module maturity field to `maturity` to better describe its
purpose.
Added usage instructions for all commands. If the generated usage is used
with the `pkg` packager, it will contain generated script names which are
confusing.
Moved the option declaration to the main source file. Added default
functions for all modules to catch unknown command invokations. Cleaned up
and exposed more ways to use the doRequest function.
This is the administrative client that uses the REST API to communicate
with MaxScale. It is written in Node.js as it can handle the JSON format
data returned by the REST API natively. Currently only list and show
functionality is implemented.
The feedback system wasn't used and was starting to cause problems on
Debian 9 where the libcurl required different version of OpenSSL than what
MaxScale was linked against.