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.
If a rule is defined with only an optional part, it should be of the
permission type. This type is used to signal that the rule matches if the
optional constraints are fulfilled.
Due to refactoring, the default type was changed from RT_PERMISSION to
RT_UNDEFINED.
The test restarts MaxScale while all backends are blocked. This will cause
MaxScale to wait until all connections to all servers time out which can
take a while.
Added a separate config for the test and lowered the timeouts. Also
inreased test timeouts.
The replication needs to be stopped before the binlogrouter is started. If
the replication is stopped after this, it is possible that two servers
with the same value of server_id attempt to register as slaves which
causes the later of them to fail.
The schemarouter can now resolve database mapping conflicts in a
deterministic manner. This will fix the problem of central databases which
are replicated shards being assigned in a non-deterministic manner.
When the current database is implicitly used in a query that also uses an
explicit database, it must be routed to the shard which has the current
database.
As cross-shard joins are not supported, the safest, and possibly the most
expected course of action to take, is to route it to the so-called default
shard. The default shard is the shard that contains the database that is
currently set as the active database with a COM_INIT_DB, a text protocol
USE <database> query or it was set at connection time.
