maxscale-system-test changed in order to control test environment by itself.
Every test checks which machines are running, compare with list of needed machines
and start new VMs is they are missing in the running machines list.
Tests are executiong MDBCI commands, MDBCI executable should be in the PATH
Some SQL clients may default to a different authentication plugin than
"mysql_native_password". Since this is the only one supported by MySQL-
authenticator, the client is instructed to swap its plugin.
Because runtime changes are performed one at a time, adding replication credentials
to a mariadbmon which didn't have any would cause an error to be printed, and
the monitor would not start.
This is now fixed by allowing replication_user without replication_password. This
is not an ideal solution as a configuration file with only replication_user would be
accepted. Also, when adding the credentials to a monitor, replication_user must be
given first to avoid the error.
If a routing of a queued query caused it to be put back on the query
queue, the order in which the queue was reorganized was wrong. The first
query would get appended as the last query which caused the order to be
reversed.
The `start services` and `stop services` command aliases now map to the
same command as `start maxscale` and `stop maxscale`. This should help
alleviate the confusion that the command naming caused.
vagrant_lock was created in order to prevent parallel execution of two 'Vagrant up' operations in parallel. Previously it was necessary due to Vagrant internal Chef issue. Now several bugs in Vagrant are fixed and MDBCI uses own Chef to provision nodes for builds and tests. There is no need to wait for previous Vagrant run finished, removing all waiting from all scripts.
'rm vagrant_lock is still present to remove locks created by previous versions of build and test scripts-
MXS-2236 Add own long test and possibility to run tests under Valgrind
Long test executes INSERT queries, transactions, prepared statements in parallel to create weird load on Maxscale to catch crashes and leaks
Test is not included into ctest scope. Test should be executed manually. For BuildBot (and also for run_test.sh) 'test_set' should be set 'NAME# ./long_test'
Time to run test is defined by 'long_test_time' variable (in seconds)
Possibility to run Maxscale under Valgrind is also added. To run Maxscale under Vaslgrind 'use_valgrind=yes' variable have to be defined
Moved hintfilter documentation to the correct place and cleaned it
up. Added a note at the start of the syntax documentation about the
behavior of the hint parsing to warn users of possible unexpected
behavior. The hint parsing could really use some refactoring to make it
more manageable which is why the preliminary fix version of the bug will
be 2.4.
By repeatedly doing reads instead of one read per second, it is more
likely that MXS-2311 is reproduced. This is still not a deterministic
process but in theory it can reproduce the problem.
If an ignorable packet was followed by more than one queued packets, they
would all get routed in the same batch. This would cause unexpected
replies from the server if multiple ignorable packets were queued up.
Using a void return value as an integer results in undefined behavior.
apparently in this case it doesn't translate into a crash and instead only
manifests itself when all the planets align.
Fixed the documentation on the arguments to maxkeys, which is a directory,
and added a short paragraph about alternative key file locations. Also
documented that keys are read from the directory where the `datadir`
parameter points to.
The test now uses maxctrl to count how many connections there are. This
helps avoid creating new users on the database and works around the slave
syncing problems.
