hcq/MaxScale
hcq/MaxScale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch '2.1' into 2.2

Browse Source
This commit is contained in:
Markus Mäkelä 2018-03-14 14:29:56 +02:00
commit d7c1d76065
No known key found for this signature in database
GPG Key ID: 72D48FCE664F7B19
9 changed files with 1145 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

312
maxscale-system-test/Documentation/BUILD_TEST_DEBUG.md Normal file
View File

@ -0,0 +1,312 @@
# Maxscale Continuous Integration and Test Automation
## Basics
Jenkins at http://max-tst-01.mariadb.com:8089/
is the main tool for providing build and test services for Maxscale,
but note that it _cannot_ be accessed directly (see further down).
A set of virtual machines (VMs) is in use for all building and testing.
The VMs are controlled by [Vagrant](https://www.vagrantup.com/)
and [MDBCI](https://github.com/OSLL/mdbci/).
3 types of VMs are supported:
* Libvirt/qemu
* AWS
* Docker containers
All Jenkins jobs are in
[Jenkins job Builder](https://docs.openstack.org/infra/jenkins-job-builder/)
YAML format and are available
[here](https://github.com/mariadb-corporation/maxscale-jenkins-jobs).
VMs for every build or test run are created from clean Vagrant box.
To speed up regular builds and tests there are a set of constantly running VMs:
* Build machine _centos\_7\_libvirt\_build_
* Test VMs set _centos\_7\_libvirt-mariadb-10.0-permanent_
Build and test Jenkins jobs generate e-mails with results report.
In addition, test run logs are stored [here](http://max-tst-01.mariadb.com/LOGS/).
## Accessing _max-tst-01_
Jenkins running on _max-tst-01_ can only be accessed from localhost. In order
to be able to access it from your computer, an ssh tunnel needs to be setup.
* Ensure that your public key is available on _max-tst-01_.
* Then setup the ssh tunnel:
```
$ ssh -f -N -L 8089:127.0.0.1:8089 vagrant@max-tst-01.mariadb.com
```
After that, Jenkins on _max-tst-01_ can be accessed by browsing to
http://localhost:8089.
In the following it is assumed that the above has been done.
## Build
* [Build](http://localhost:8089/job/build/) builds Maxscale
and creates a binary repository for one Linux distribution.
* [Build_all](http://localhost:8089/job/build_all/) builds
Maxscale and creates binary repository for _all_ supported Linux
distributions.
The list of supported distributions (Vagrant boxes) is
[here](https://github.com/mariadb-corporation/maxscale-jenkins-jobs/blob/master/maxscale_jobs/include/boxes.yaml).
### Main _Build_ and _Build_all_ jobs parameters
To start a build, click on _Build with Parameters_ to the left in
the Jenkins panel.
#### scm_source
The place in Maxscale source code.
* for branch - put branch name here
* for commit ID - put Git Commit ID here
* for tag - put `refs/tags/<tagName>` here
#### box
The name of Vagrant box to create VM.
Box name consists of the name of distribution, distribution version and the name of VM provider.
Whole list of supported boxes can be found [here](https://github.com/mariadb-corporation/maxscale-jenkins-jobs/blob/master/maxscale_jobs/include/boxes_all.yaml)
#### target
Then name of binary repository. Ensure that the name is reasonably
unique so that there can be no unintended overwrites. If you are
building a personal branch, then using the same value for _target_
as is the value for _scm_source_ should be fine.
Binaries will go to:
`http://max-tst-01.mariadb.com/ci-repository/<target>/mariadb-maxscale/<distribution_name>/<version>`
#### cmake_flags
Debug build:
```
-DBUILD_TESTS=Y -DCMAKE_BUILD_TYPE=Debug -DFAKE_CODE=Y -DBUILD_MMMON=Y -DBUILD_AVRO=Y -DBUILD_CDC=Y
```
Release build:
```
-DBUILD_TESTS=N -DFAKE_CODE=N -DBUILD_MMMON=Y -DBUILD_AVRO=Y -DBUILD_CDC=Y
```
Build scripts automatically add all other necessary flags (e.g. -DPACKAGE=Y)
#### do_not_destroy_vm
If `yes`, then the VM will not be destroyed after the build. Choose that **if** you,
for some specific reason (e.g. debugging), intend to log into the VM later.
#### repo_path
The location for binary repositories on _max-tst-01_. Usually no need to change.
#### try_alrady_running
If `yes` constantly running VM will be used for build instead of bringing clean
machines from scratch. The name of VM is `<box_name>_build`.
If this VM is not running it will be created from clean box. If new build
dependency is introduced and new package have to be installed (and build
script is modified to do it) before the build it is necessary to destroy
constantly running VM - in this case a new VM will be created and all stuff
will be installed.
#### run_upgrade_test
If `yes` upgrade test will be executed after build.
Upgrade test is executed on a separate VM.
* First, old version of Maxsale is installed (parameter **old_target**),
* then upgrade to recently built version is executed,
* then Maxscale is started with minimum configuration (only CLI service is
configured, no backend at all), and
* finally, _maxadmin_ is executed to check that Maxscale is running and available.
### Regular automatic builds
File `~/jobs_branches/build_all_branches.list` on _max-tst-02.mariadb.com contains
a list of regexes. If branch name matches one of the regex from this file
_build_all_ job will be executed for this branch every night.
Regular builds are executed with _run\_upgrade\_test=yes_
## Test execution
* [run_test](http://localhost:8089/view/test/job/run_test/) creates a set of
VMs: 1 VM for Maxscale, 4 VMs for Master/Slave setup and VMs for Galera cluster.
### Main _Run_test_ parameters
Before this job can be run, a
[build](#build)
job must have been executed first.
#### target
The name of Maxscale binary repository.
The value used here, should be the same as the value used in [target](#target).
#### box
The name of Vagrant box to create VM.
The value used here, must be the same as the value used in
[box](#box)
when the used **target** was built.
#### product
MariaDB or MySQL to be installed to all backend machines.
#### version
Version of MariaDB or MySQL to be installed on all MariaDB machines.
The list of versions contains all MariaDB and MySQL major version.
Selecting wrong version (e.g. 5.7 for MariaDB or 10.0 for MySQL) causes
VM creation error and job failure.
#### do_not_destroy_vm
If `yes` all VMs will run until manually destoroy by **Destroy** job.
It can be used for debugging. **Do not forget to destroy** VMs after debugging
is finished.
#### name
The name of test run. The names of the VMs will be:
* `<name>_maxscale`,
* `<name>_node_000`, ..., `<name>_node_003` and
* `<name>_galera_000`, ..., `<name>_galera_003`-
The **name** can be used to access VMs:
```bash
. ~/build-scripts/test/set_env_vagrant.sh <name>
ssh -i $<vm_name>_keyfile $<vm_name>_whoami@$<vm_name>_network
```
where `<vm_name>` can be 'maxscale', 'node_XXX' or 'galera_XXX'.
#### test_branch
The name of _MaxScale_ repository branch to be used in the test run.
It is usually the same as the one used in [scm_source](#scm_source).
#### slave_name
Host server to for VMs and _maxscale-system-test_ execution
|Name|Server|
|-------|:---------------------|
|master |localhost|
|maxtst2|max-tst-02.mariadb.com|
|maxtst3|max-tst-03.mariadb.com|
#### test_set
Defines tests to be run. See ctest documentation
https://cmake.org/cmake/help/v3.7/manual/ctest.1.html
for details.
Most common cases:
|Arguments|Description|
|-------------|:--------------------------------------------------|
|-I 1,5,,45,77| Execute tests from 1 to 5 and tests 45 and 77|
|-L HEAVY|Execute all tests with 'HEAVY' label|
|-LE UNSTABLE|Execute all tests except tests with 'UNSTABLE' label|
### Run_test_snapshot
This job uses already running VMs. The set of VMs have to have snapshot
(by default snapshot name is 'clean').
Instead of bringing up all VMs from scratch this job only reverts VMs to
the 'clean' state.
The name of running VMs set should be:
`<box>-<product>-<version>-permanent`
If there is no VMs set with such name it will be created automatically.
If case of broken VMs it can be destroyd with help of **Destroy** job
and **Run_test_snapshot** should be restarted after it to create a new
VMs set.
Only one VMs set on every server can be started for particular **box**,
**product** and **version** combination.
If two **Run_test_snapshot** jobs are runnig for the same
**box**, **product** and **version**
the second one will be waiting until the first job run ios finished.
(job sets 'snapshot_lock').
If case if locak is not removed automatically (for example
due to Jenkins crash) it can be removed manually:
```bash
rm ~/mdbci/centos_7_libvirt-mariadb-10.0-permanent_snapshot_lock
```
### Run_test_labels and Run_test_snapshot_labels
The only difference from **Run_test** and
**Run_test_snapshot** is the way to define set of tests to execute.
**\*_labels** jobs use checkboxes list of test labels.
Labels list have to be maintained manually.
It can be created by
https://github.com/mariadb-corporation/maxscale-jenkins-jobs/blob/master/create_labels_jobs.sh
script.
### Regular test runs
#### Test runs by timer
File
```
~/jobs_branches/run_test_branches.list
```
on max-tst-02.mariadb.com
contains a list of regexes. If branch name matches one of regexes
tests are executed for this branch every day.
The test set is defined also in this file.
Job **print_branches_which_matches_regex_in_file**
http://localhost:8089/view/All/job/print\_branches\_which\_matches\_regex\_in\_file/build
can be used to check the list of branches that match
regexes.
Job **weekly_smoke_run_test_matrix** triggers **build_regular**
and **run_test_matrix**
http://localhost:8089/view/test/job/run_test_matrix/
every week for 'develop' branch
with test set '-L LIGHT' (all tests with label 'LIGHT')
#### Test runs by GIT push
File
```
~/jobs_branches/on_push_maxscale_branches.list
```
on max-tst-02.mariadb.com
contains a list of regexes. If branch name matches one of regexes
tests are executed for this branch after every push.
Job **print_branches_which_matches_regex_in_file**
http://localhost:8089/view/All/job/print\_branches\_which\_matches\_regex\_in\_file/build
can be used to check the list of branches that match
regexes (select _on\_push\_maxscale\_branches.list_
file for _branches\_list_ parameter)
## Debugging
For regular debugging contsntly running set of VMs is recommended.
See [documentation here](DEBUG_ENVIRONMENT.md).
Another way is to use **do_not_destroy=yes** parameter of **run_test** job.
After **run_test** job executing VMs stay running and
can be accessed from the host server. See [here](LOCAL_DEPLOYMENT.md#accessing-vms)
for details.

113
maxscale-system-test/Documentation/DEBUG_ENVIRONMENT.md Normal file
View File

@ -0,0 +1,113 @@
# Debug environment
## Create ssh tunnel to Jenkins server
```bash
ssh -f -N -L 8089:127.0.0.1:8089 vagrant@max-tst-01.mariadb.com
```
## Create environment for debugging
To create virtual machines for debugging please
use Jenkins job 'create_env'
http://127.0.0.1:8089/view/env/job/create_env/build
This Jenkins job creates backend VMs
(4 Master/Slave and 4 Galera) and
Maxscale development machine.
Maxscale development machine will contain all
build tools and build dependencies as well as
Maxscale source Git.
Source is located in:
```
~/MaxScale/
```
## Environmental variables setup
```bash
. ~/build-scripts/test/set_env_vagrant.sh <name>
```
Example:
```bash
. ~/build-scripts/test/set_env_vagrant.sh debug_env
```
## Access to Maxscale VM
```bash
ssh -i $maxscale_sshkey $maxscale_whoami@maxscale_network
```
```bash
scp -i $maxscale_sshkey <stuff_to_copy> $maxscale_whoami@maxscale_network:/home/$maxscale_whoami/
```
```bash
scp -i $maxscale_sshkey $maxscale_whoami@maxscale_network:/home/$maxscale_whoami/<stuff_to_copy> .
```
## Executing tests
Clone https://github.com/mariadb-corporation/maxscale
and build tests
```bash
cd MaxScale/maxscale-system/test
cmake .
make
```
and then run
```bash
ctest -VV
```
or manually any test executable from _maxscale-system-test_
It is recommended to run
```bash
./check_backend
```
before manual testing to be sure Master/Slave and Galera setups are
in order (_check_backend_ also fixes broken replication or Galera)
## Restoring broken setup
Just use http://127.0.0.1:8089/view/snapshot/job/restore_snapshot/build
Manual snapshot reverting:
```bash
~/mdbci/mdbci snapshot revert --path-to-nodes debug_env --snapshot-name clean
```
## Destroying
Use http://127.0.0.1:8089/view/axilary/job/destroy/build
with _name=debug_env_
or _clean_vms.sh_ script
```bash
cd ~/mdbci/scripts
./clean_vms.sh debug_env
```
## Notes
Please check _slave_name_ parameter when executing any Jenkins job.
All jobs are executed only for defined slave (or for master).
i.e. VM set with the same name can be running on different slaves at the same time.

173
maxscale-system-test/Documentation/LOCAL_DEPLOYMENT.md Normal file
View File

@ -0,0 +1,173 @@
# Local deployment
## Prepare MDBCI environment
_Libvirt_, _Docker_ and _Vagrant_, with a set of plugins, are needed for MDBCI.
Please follow the instructions [here](https://github.com/mariadb-corporation/mdbci/blob/integration/PREPARATION_FOR_MDBCI.md).
## Creating VMs for local tests
[test/create_local_config.sh](test/create_local_config.sh) script creates a set of virtual machines
(1 maxscale VM, 4 Master/Slave and 4 Galera).
Direct execution of create_local_config.sh requires manuall paramters setting.
It is easiler to ese create_local_config_libvirt.sh and create_local_config_docker.sh
Script usage:
```bash
. ~/build-scripts/test/create_local_config.sh <target> <name>
```
where
target - Maxscale binary repository name
name - name of virtual machines set
Note: '.' before command allows script to load all environmental variables (needed for 'maxscale-system-test').
All other parameters have to be defined as environmental variables before executing the script.
Examples of parameters definition can be found in the following scripts:
[test/create_local_config_libvirt.sh](test/create_local_config_libvirt.sh)
[test/create_local_config_docker.sh](test/create_local_config_docker.sh)
```bash
. ~/build-scripts/test/create_local_config_libvirt.sh <target> <name>
```
```bash
. ~/build-scripts/test/create_local_config_docker.sh <target> <name>
```
## Execute test
Clone and compile https://github.com/mariadb-corporation/MaxScale
Build tests:
```bash
cd Maxscale/maxscale-system-test
cmake .
make
```
if environmental variables are not set:
```bash
. ~/build-scripts/test/set_env_vagrant.sh <name>
```
Execute single test by starting test binary or use ctest to run all or selected tests (see https://cmake.org/cmake/help/v3.8/manual/ctest.1.html)
To see test output:
```bash
ctest -VV
```
## Destroying VMs
```bash
cd ~/mdbci/scripts
./clean_vms.sh <name>
```
## Reverting default snapshot
create_local_config.sh script takes one snapshot of recently created set of VMs. Snapshot name is 'clean'
If VMs are damaged during testing process it is easy to restore them:
```bash
~/mdbci/mdbci snapshot revert --path-to-nodes <name> --snapshot-name clean
```
If needed, more snapshots can be created:
```bash
cd ~/mdbci
./mdbci snapshot take --path-to-nodes <name> --snapshot-name <snapshot_name>
```
## Accessing VMs
```bash
cd ~/mdbci/<name>
vagrant ssh <vm_name>
```
where <vm_name> can be 'maxscale', 'node_XXX' or 'galera_XXX'.
```bash
. ~/build-scripts/test/set_env_vagrant.sh <name>
ssh -i $<vm_name>_keyfile $<vm_name>_whoami@$<vm_name>_network
```
examples:
```bash
ssh -i $node_002_keyfile $node_002_whoami@$node_002_network
ssh -i $maxscale_keyfile $maxscale_whoami@$maxscale_network
```
### Own VM configuration template
By default scripts use
~/build-scripts/test/template.libvirt.json
and
~/build-scripts/test/template.docker.json
These templates can be used as examples to create your own templates.
To use own template:
put your template file to ~/build-scripts/test/templates/
and define 'template_name' variable
```bash
export template_name=<your_template_filename>
. ~/build-scripts/test/create_local_config_libvirt.sh <target> <name>
```
## Troubleshooting
### More info about libvirt and vagrant-libvirt plugin
https://help.ubuntu.com/lts/serverguide/libvirt.html
https://github.com/vagrant-libvirt/vagrant-libvirt#installation
### vagrant is locked, waiting ...
```bash
rm ~/vagrant_lock
```
### Random VM creation failures
Plese check the amount of free memory and amount of running VMs
```bash
virsh list
docker ps
```
and remove all VMs and containers you do not need
### Wrong time on host server
If server time is wrong it can cause random problems. Please do time sync: use ntp or
```bash
sudo date -s "$(curl -s --head http://google.com | grep ^Date: | sed 's/Date: //g')"
```
### Info from OSLL wiki
#### Libvirt DNS resolving problem quick fix
https://dev.osll.ru/projects/mdbci/wiki/Libvirt_DNS_resolving_problem_quick_fix

91
maxscale-system-test/Documentation/README.md Normal file
View File

@ -0,0 +1,91 @@
# build-scripts-vagrant
Build and test scripts to work with Vagrant-controlled VMs do follwoing:
* create VM for Maxscale build
* create a set of VMs (test environment) for running Maxscale tests
Test environment consists of:
* 'maxscale' machine
* 'nodeN' machines for Master/Slave setup (node0, node1, node2, node3)
* 'galeraN' machines for Galera cluster (galera0, galera1, galera2, galera3)
## Main files
File|Description
----|-----------
[prepare_and_build.sh](prepare_and_build.sh)|Create VM for build and execute build, publish resulting repository
build.\<provider\>.template.json|templates of MDBCI configuration description (build environment description) of build machines|
[test-setup-scripts/setup_repl.sh](test-setup-scripts/setup_repl.sh)|Prepares repl_XXX machines to be configured into Master/Slave
[test-setup-scripts/galera/setup_galera.sh](test-setup-scripts/galera/setup_galera.sh)|Prepares galera_XXX machines to be configured into Galera cluster
[test-setup-scripts/cnf/](test-setup-scripts/cnf/)|my.cnf files for all backend machines
test/template.\<provider\>.json|Templates of MDBCI configuration description (test environment description) of test machines|
[test/run_test.sh](test/run_test.sh)|Creates test environment, build maxscale-system-tests from source and execute tests using ctest
[test/set_env_vagrant.sh](test/set_env_vagrant.sh)|set all environment variables for existing test machines using MDBCI to get all values
[test/create_env.sh](test/create_env.sh)|Creates test environment, copy Maxscale source code to 'maxscale' machine in this environment, build Maxscale
## [prepare_and_build.sh](prepare_and_build.sh)
Following variables have to be defined before executing prepare_and_build.sh
|Variable|Meaning|
|--------|--------|
|$MDBCI_VM_PATH|Path to duirectory to store VM info and Vagrant files (by default $HOME/vms)|
|$box|name of MDBCI box (see [MDBCI docs](https://github.com/OSLL/mdbci#terminology))|
|$target|name of repository to put result of build|
|$scm_source|reference to the place in Maxscale source GIT repo|
|$cmake_flags|additional cmake flags|
|$do_not_destroy_vm|if 'yes' build VM won't be destroyed after the build. NOTE: do not forget destroy it manually|
|$no_repo|if 'yes' repository won't be built|
Scripts creates MDBCI configuration build_$box-<current data and time>.json, bringing it up (the directory build_$box-<current data and time> is created)
Resulting DEB or RPM first go to ~/pre-repo/$target/$box
NOTE: if ~/pre-repo/$target/$box contains older version they will also go to repostory
Resulting repository goes to ~/repository/$target/mariadb-maxscale/
It is recommeneded to publish ~/repository/ directory on a web server
## [test/run_test.sh](test/run_test.sh)
Following variables have to be defined before executing run_test.sh
|Variable|Meaning|
|--------|--------|
|$box|name of MDBCI box for Maxscale machine (see [MDBCI docs](https://github.com/OSLL/mdbci#terminology))|
|$name|unique name of test setup|
|$product|'mariadb' or 'mysql'|
|$version|version of backend DB|
|$target|name of Maxscale repository|
|$ci_url|URL of repostory web site, Maxscale will be installed from $ci_url/$target/mariadb-maxscale/
|$do_not_destroy_vm|if 'yes' build VM won't be destroyed after the build. NOTE: do not forget to destroy it manually|
|$smoke|if 'yes' all tests are executed in 'quick' mode (less iterations, skip heavy operations)|
|$test_set|definition of set of tests to run in ctest notation|
|test_set_labels|list of ctest labels. If it is not define 'test_set' will be used as a plain string|
## Test environment operations
### Accessing nodes
<pre>
cd $MDBCI_VM_PATH/$name/
vagrant ssh $node_name
</pre>
where $node_name - 'maxscale', 'node0', ..., 'node3', ..., 'nodeN', 'galera0', ..., 'galera3', ..., 'galeraN'
### Getting IP address and access keys
<pre>
~/mdbci/mdbci show network $name
~/mdbci/mdbci show network $name/$node_name
~/mdbci/mdbci show keyfile $name/$node_name
</pre>
### Destroying environemnt
<pre>
cd $MDBCI_VM_PATH/$name/
vagrant destroy -f
</pre>
### Set variables by [test/set_env_vagrant.sh](test/set_env_vagrant.sh)
<pre>
. ../build-scripts/test/set_env_vagrant.sh $name
</pre>

268
maxscale-system-test/Documentation/RELEASE.md Normal file
View File

@ -0,0 +1,268 @@
# Release process
## Pre-release Checklist
* Create new release notes and add all fixed bugs, use a previous one as a template
* Update the link to the latest release notes in Documentation-Contents.md
* Add link to release notes and document major changes in Changelog.md
* Add link to release notes in the Upgrading guide
## 1. Tag
Release builds are always made using a tag. However, the used
tag is a _tentative_ tag, to ensure that there never is a need
to _move_ any tag, should the release have to be modified after
it has been tagged. All that is needed is to create a new
tentative tag.
The source for release `x.y.z` is tagged with `maxscale-x.y.z-ttN`
where `N` is 1 for the first attempt and incremented in case the
`x.y.z` source still needs to be modified and the release rebuilt.
The final tag `maxscale-x.y.z` is created _after_ the packages have
been published and we are certain they will not be rebuilt, without
also the version number being changed.
So, ensure that the `maxscale-x.y.z-ttN` has been created and pushed
to the repository.
**NOTE** The tentative suffix - `-ttN` - is **only** used when
specifying the tag for the build, it must **not** be present in
any other names or paths.
## 2. Build and upgrade test
The Jenkins
[Build_all](http://localhost:8089/job/build_all/)
job should be used for building the packages.
Note that the above will not work unless you have set up an
ssh tunnel to Jenkins:
```
$ ssh -f -N -L 8089:127.0.0.1:8089 vagrant@max-tst-01.mariadb.com
```
Usually two runs are done: one for _release_ and one for _debug_ packages.
### Parameters to define
Use defaults for all other parameters.
#### source
```
refs/tags/maxscale-x.y.z-ttN
```
#### target
Debug build:
```
maxscale-x.y.z-debug
```
Release build:
```
maxscale-x.y.z-release
```
#### cmake_flags
Debug build:
```
-DBUILD_TESTS=Y -DCMAKE_BUILD_TYPE=Debug -DBUILD_MMMON=Y -DBUILD_CDC=Y
```
Release build:
```
-DBUILD_TESTS=N -DBUILD_MMMON=Y -DBUILD_CDC=Y
```
#### run_upgrade_test
```
yes
```
#### old_target
Name of some existing Maxscale repository
(please check http://max-tst-01.mariadb.com/ci-repository/
before build).
```
maxscale-x'.y'.z'-release
```
### Options for 1.4.x build
For `1.4` builds the default values of the following parameters
should be changed:
#### use_mariadbd
```
yes
```
#### cnf_file
```
maxscale.cnf.minimum.1.4.4
```
#### maxadmin_command
```
maxadmin -pmariadb show services
```
## 3. Copying to code.mariadb.com
ssh to `code.mariadb.com` with your LDAP credentials.
Create directories and copy repositories files:
```bash
cd /home/mariadb-repos/mariadb-maxscale/
mkdir x.y.z
mkdir x.y.z-debug
cd x.y.z
rsync -avz --progress --delete -e ssh vagrant@max-tst-01.mariadb.com:/home/vagrant/repository/maxscale-x.y.z-release/mariadb-maxscale/ .
cd ../x.y.z-debug
rsync -avz --progress --delete -e ssh vagrant@max-tst-01.mariadb.com:/home/vagrant/repository/maxscale-x.y.z-debug/mariadb-maxscale/ .
```
## 4. Email webops-requests@mariadb.com
Email example:
Subject: `MaxScale x.y.z release`
```
Hello,
Please publish Maxscale x.y.z binaries on web page.
Repos are on code.mariadb.com /home/mariadb-repos/mariadb-maxscale/x.y.z
symlink 'x.y' should be set to 'x.y.z'
symlink 'latest' [should|should NOT] be set to 'x.y.z'
Also please make sure that debug binaries are not visible from
https://mariadb.com/my_portal/download/maxscale
```
Replace `x.y.z` with the correct version.
**NOTE** Sometimes - especially at _big_ releases when the exact release
date is fixed in advance - the following steps 5, 6 and 7 are done right
after the packages have been uploaded, to ensure that the steps 4 and 8
can be done at the same time.
## 5. Create the final tag
Once the packages have been made available for download, create
the final tag
```
$ git checkout maxscale-x.y.z-ttN
$ git tag -a -m "Tag for MaxScale x.y.z" maxscale-x.y.z
$ git push --tags origin
```
and remove the tentative tag(s)
```
$ git tag -d maxscale-x.y.z-ttN
$ git push origin :refs/tags/maxscale-x.y.z-ttN
```
## 6. Create the branch
Release `x.y.z` is typically developed in the branch `x.y`.
Once `x.y.z` has been released, the branch `x.y.z` also needs
to be created.
```
$ git checkout maxscale-x.y.z
$ git checkout -b x.y.z
$ git push origin x.y.z
```
## 7. Update the release date
Once the branch `x.y.z` has been created and the actual release
date of the release is known, update the release date in the
release notes.
```
$ git checkout x.y.z
$ # Update release date in .../MaxScale-x.y.z-Release-Notes.md
$ git add .../MaxScale-x.y.z-Release-Notes.md
$ git commit -m "Update release date"
$ git push origin x.y.z
```
**NOTE** The `maxscale-x.y.z` tag is **not** moved. That is, the
release date is _not_ available in the documentation marked with
the tag `maxscale-x.y.z` but _is_ available in the branch marked
with `x.y.z`.
Merge `x.y.z` to `x.y`.
```
$ git checkout x.y
$ git merge x.y.z
```
At this point, the last commits on branches `x.y` and `x.y.z`
should be the same and the commit should be the one containing the
update of the release date. Further, that commit should be the only
difference between the branches and the tag `maxscale-x.y.z`.
**Check that indeed is the case**.
## 8. Update documentation
Email webops-requests@mariadb.com with a mail containing the
following.
```
subject: Please update MaxScale x.y knowledge base
body:
---
Hi,
Please update https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-XY/
from https://github.com/mariadb-corporation/MaxScale/tree/x.y.z/Documentation
using the "new" algorithm that does not honor single line-breaks.
Br,
Your Name
```
## 9. Send release email to mailing list
Email maxscale@googlegroups.com with a mail containing the following.
```
subject: MariaDB MaxScale x.y.z available for download
body:
---
Hi,
We are happy to announce that MariaDB MaxScale x.y.z GA is now available for download. This is a bugfix release.
The Jira list of fixed issues can be found here(ADD LINK HERE).
* [MXS-XYZ] BUG FIX DESCRIPTION HERE
Binaries:
https://mariadb.com/downloads/maxscale
https://mariadb.com/my_portal/download
Documentation:
LINK TO KB DOCUMENTATION HERE
Release notes:
LINK TO RELEASE NOTES HERE
Source code:
LINK TO maxscale-x.y.z TAG HERE
Please report any issues on Jira:
https://jira.mariadb.org/projects/MXS/issues
On behalf of the entire MaxScale team,
YOUR NAME HERE
```

105
maxscale-system-test/Documentation/RUN_TEST.md Normal file
View File

@ -0,0 +1,105 @@
# How to run test
## Prerequirements
Installed [MDBCI](https://github.com/mariadb-corporation/mdbci) (with dependencies, see
[MDBCI doc](https://github.com/mariadb-corporation/mdbci#mariadb-continuous-integration-infrastructure-mdbci)),
[build-scripts](https://github.com/mariadb-corporation/build-scripts-vagrant)
Componets should be in the following directories:
[build-scripts](https://github.com/mariadb-corporation/build-scripts-vagrant) - in ~/build-scripts/
[mdbci](https://github.com/mariadb-corporation/mdbci) - in ~/mdbci/
## Creating test environment and running tests
[run_test.sh](test/run_test.sh) generates MDBCI description of configuration, bring all VMs up, setup DB on all backends,
prapare DB for creating Master/Slave and Galera setups, build [maxscale-system-test](https://github.com/mariadb-corporation/MaxScale/tree/develop#maxscale-system-test)
package, execute ctest. Source code of
[maxscale-system-test](https://github.com/mariadb-corporation/MaxScale/tree/develop/maxscale-system-test#maxscale-system-test)
have to be in current directory before execution [run_test.sh](test/run_test.sh)
Environmental variables have to be defined before executing [run_test.sh](test/run_test.sh)
For details see [description](README.md#run_testsh)
Example:
<pre>
export export MDBCI_VM_PATH=$HOME/vms
export name="my-centos7-release-1.3.0-test"
export box="centos7"
export product="mariadb"
export version="5.5"
export target="develop"
export ci_url="http://max-tst-01.mariadb.com/ci-repository/"
export do_not_destroy_vm="yes"
export test_set="1,10,,20,30,95"
~/build-scripts/test/run_test.sh
</pre>
After the test, all machines can be accessed:
<pre>
cd $MDBCI_VM_PATH/$name
vagrant ssh \<machine_name\>
</pre>
where \<machine_name\> is 'maxscale', 'node0', ..., 'node3', ..., 'nodeN', 'galera0', ..., 'galera3', ..., 'galeraN'
http://max-tst-01.mariadb.com/ci-repository/develop/mariadb-maxscale/ have to contain Maxscale repository
## Running tests with existing test environment
[set_env_vagrant.sh](test/set_env_vagrant.sh) script sets all needed environmental variables for
[maxscale-system-test](https://github.com/mariadb-corporation/MaxScale/tree/develop/maxscale-system-test)
See [maxscale-system-test documentation](https://github.com/mariadb-corporation/MaxScale/tree/develop/maxscale-system-test#environmental-variables) for details regarding variables.
Example:
<pre>
export name="running_conf_name"
. ../build-scripts/test/set_env_vagrant.sh $name
set +x
git clone https://github.com/mariadb-corporation/maxscale.git
cd MaxScale/maxscale-system-test
cmake .
make
./test_executable_name
</pre>
or use ctest to run several tests
## Creating environment for Maxscale debugging
[create_env.sh](test/create_env.sh) script generates MDBCI description of configuration, bring all VMs up,
setup DB on all backends, prapare DB for creating Master/Slave and Galera setups, copy source code of
[Maxscale](https://github.com/mariadb-corporation/MaxScale) to 'maxscale' VM and build it.
Note: script does not install Maxscale, it have to be done manually.
Following variables have to be defined:
'name', 'box', 'product', 'version'
(see [run_test.sh documentation](https://github.com/mariadb-corporation/build-scripts-vagrant/blob/master/README.md#run_testsh))
'source', 'value'
(see
[prepare_and_build.sh documentation](https://github.com/mariadb-corporation/build-scripts-vagrant/blob/master/README.md#prepare_and_buildsh))
Example:
<pre>
export MDBCI_VM_PATH=$HOME/vms
export name="my-centos7-release-1.3.0-test"
export box="centos7"
export product="mariadb"
export version="5.5"
export source="BRANCH"
export value="develop"
~/build-scripts/test/create_env.sh
</pre>
**Note**: do not forget to destroy test environment by vagrant destroy:
<pre>
cd $MDBCI_VM_PATH/$name/
vagrant destroy -f
</pre>

78
maxscale-system-test/failover_mysqlmon.cpp Normal file
View File

@ -0,0 +1,78 @@
/**
* @file failover_mysqlmon.cpp MySQL Monitor Failover Test
* - block all nodes, but one
* - wait for minitor (monitor_interval)
* - check maxadmin output
* - check that queries work
* - unblock backend nodes
* - wait for monitor
* - check that we are still using the last node to which we failed over to and that the old nodes are in maintenance mode
*/
#include <iostream>
#include "testconnections.h"
int main(int argc, char *argv[])
{
TestConnections * test = new TestConnections(argc, argv);
test->tprintf(" Create the test table and insert some data ");
test->connect_maxscale();
test->try_query(test->conn_rwsplit, "CREATE OR REPLACE TABLE test.t1 (id int)");
test->try_query(test->conn_rwsplit, "INSERT INTO test.t1 VALUES (1)");
test->close_maxscale_connections();
test->repl->connect();
test->repl->sync_slaves();
test->tprintf(" Block all but one node ");
test->repl->block_node(0);
test->repl->block_node(1);
test->repl->block_node(2);
execute_query(test->repl->nodes[3], "STOP SLAVE;RESET SLAVE ALL;");
test->tprintf(" Wait for the monitor to detect it ");
sleep(15);
test->tprintf(" Connect and insert should work ");
char *output = test->ssh_maxscale_output(true, "maxadmin list servers");
test->tprintf("%s", output);
free(output);
test->connect_maxscale();
test->try_query(test->conn_rwsplit, "INSERT INTO test.t1 VALUES (1)");
test->close_maxscale_connections();
test->tprintf(" Unblock nodes ");
test->repl->unblock_node(0);
test->repl->unblock_node(1);
test->repl->unblock_node(2);
test->tprintf(" Wait for the monitor to detect it ");
sleep(15);
test->tprintf("Check that we are still using the last node to which we failed over "
"to and that the old nodes are in maintenance mode");
test->connect_maxscale();
test->try_query(test->conn_rwsplit, "INSERT INTO test.t1 VALUES (1)");
char maxscale_id[256], real_id[256];
find_field(test->conn_rwsplit, "SELECT @@server_id", "@@server_id", maxscale_id);
test->repl->connect();
find_field(test->repl->nodes[3], "SELECT @@server_id", "@@server_id", real_id);
test->add_result(strcmp(maxscale_id, real_id) != 0,
"@@server_id is different: %s != %s", maxscale_id, real_id);
test->close_maxscale_connections();
test->ssh_maxscale(true, "maxadmin clear server server1 maintenance");
test->ssh_maxscale(true, "maxadmin clear server server2 maintenance");
test->ssh_maxscale(true, "maxadmin clear server server3 maintenance");
test->repl->fix_replication();
test->tprintf(" Check that MaxScale is running ");
test->check_maxscale_alive();
int rval = test->global_result;
delete test;
return rval;
}

5
maxscale-system-test/mysqlmon_detect_standalone_master.cpp
View File

@ -88,13 +88,14 @@ int main(int argc, char *argv[])
test.tprintf(" Create the test table and insert some data ");
test.try_query(test.maxscales->conn_rwsplit[0], "CREATE OR REPLACE TABLE test.t1 (id int)");
test.try_query(test.maxscales->conn_rwsplit[0], "INSERT INTO test.t1 VALUES (1)");
sleep(2);
test.repl->sync_slaves();
print_gtids(test);
test.maxscales->close_maxscale_connections(0);
if (test.global_result != 0)
{
return test.global_result;
return test.global_result;
}
test.tprintf(" Block all but one node, stop slave on server 4 ");

4
server/modules/protocol/MySQL/mariadbbackend/mysql_backend.c
View File

@ -371,7 +371,6 @@ mxs_auth_state_t handle_server_response(DCB *dcb, GWBUF *buffer)
}
}
gwbuf_free(buffer);
return rval;
}
@ -518,7 +517,6 @@ gw_read_backend_event(DCB *dcb)
}
proto->protocol_auth_state = state;
gwbuf_free(readbuf);
}
else if (proto->protocol_auth_state == MXS_AUTH_STATE_RESPONSE_SENT)
{
@ -548,6 +546,8 @@ gw_read_backend_event(DCB *dcb)
/** Authentication failed */
gw_reply_on_error(dcb, proto->protocol_auth_state);
}
gwbuf_free(readbuf);
}
else if (proto->protocol_auth_state == MXS_AUTH_STATE_CONNECTED &&
dcb->ssl_state == SSL_ESTABLISHED)