diff --git a/maxscale-system-test/Documentation/BUILD_TEST_DEBUG.md b/maxscale-system-test/Documentation/BUILD_TEST_DEBUG.md new file mode 100644 index 000000000..5f1325020 --- /dev/null +++ b/maxscale-system-test/Documentation/BUILD_TEST_DEBUG.md @@ -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/` 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//mariadb-maxscale//` + +#### 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 `_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: + +* `_maxscale`, +* `_node_000`, ..., `_node_003` and +* `_galera_000`, ..., `_galera_003`- + +The **name** can be used to access VMs: + +```bash +. ~/build-scripts/test/set_env_vagrant.sh +ssh -i $_keyfile $_whoami@$_network +``` +where `` 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: + +`---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. + + diff --git a/maxscale-system-test/Documentation/DEBUG_ENVIRONMENT.md b/maxscale-system-test/Documentation/DEBUG_ENVIRONMENT.md new file mode 100644 index 000000000..3279c23dc --- /dev/null +++ b/maxscale-system-test/Documentation/DEBUG_ENVIRONMENT.md @@ -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 +``` + +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 $maxscale_whoami@maxscale_network:/home/$maxscale_whoami/ +``` + +```bash +scp -i $maxscale_sshkey $maxscale_whoami@maxscale_network:/home/$maxscale_whoami/ . +``` + +## 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. + + diff --git a/maxscale-system-test/Documentation/LOCAL_DEPLOYMENT.md b/maxscale-system-test/Documentation/LOCAL_DEPLOYMENT.md new file mode 100644 index 000000000..39c1ba337 --- /dev/null +++ b/maxscale-system-test/Documentation/LOCAL_DEPLOYMENT.md @@ -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 +``` +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 +``` + +```bash +. ~/build-scripts/test/create_local_config_docker.sh +``` + +## 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 +``` + +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 +``` + +## 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 --snapshot-name clean +``` + +If needed, more snapshots can be created: + + +```bash +cd ~/mdbci +./mdbci snapshot take --path-to-nodes --snapshot-name +``` +## Accessing VMs + +```bash +cd ~/mdbci/ +vagrant ssh +``` +where can be 'maxscale', 'node_XXX' or 'galera_XXX'. + +```bash +. ~/build-scripts/test/set_env_vagrant.sh +ssh -i $_keyfile $_whoami@$_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= +. ~/build-scripts/test/create_local_config_libvirt.sh +``` + +## 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 + diff --git a/maxscale-system-test/Documentation/README.md b/maxscale-system-test/Documentation/README.md new file mode 100644 index 000000000..b28053d48 --- /dev/null +++ b/maxscale-system-test/Documentation/README.md @@ -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.\.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.\.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-.json, bringing it up (the directory build_$box- 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 +
+cd $MDBCI_VM_PATH/$name/
+vagrant ssh $node_name
+
+ +where $node_name - 'maxscale', 'node0', ..., 'node3', ..., 'nodeN', 'galera0', ..., 'galera3', ..., 'galeraN' + +### Getting IP address and access keys +
+~/mdbci/mdbci show network $name
+~/mdbci/mdbci show network $name/$node_name
+~/mdbci/mdbci show keyfile $name/$node_name
+
+ +### Destroying environemnt +
+cd $MDBCI_VM_PATH/$name/
+vagrant destroy -f
+
+ +### Set variables by [test/set_env_vagrant.sh](test/set_env_vagrant.sh) +
+. ../build-scripts/test/set_env_vagrant.sh $name
+
diff --git a/maxscale-system-test/Documentation/RELEASE.md b/maxscale-system-test/Documentation/RELEASE.md new file mode 100644 index 000000000..a555b5670 --- /dev/null +++ b/maxscale-system-test/Documentation/RELEASE.md @@ -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 +``` diff --git a/maxscale-system-test/Documentation/RUN_TEST.md b/maxscale-system-test/Documentation/RUN_TEST.md new file mode 100644 index 000000000..36146fece --- /dev/null +++ b/maxscale-system-test/Documentation/RUN_TEST.md @@ -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: +
+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
+
+ +After the test, all machines can be accessed: +
+cd $MDBCI_VM_PATH/$name
+vagrant ssh \
+
+ +where \ 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: +
+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
+
+ +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: +
+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
+
+ +**Note**: do not forget to destroy test environment by vagrant destroy: + +
+cd $MDBCI_VM_PATH/$name/
+vagrant destroy -f 
+
diff --git a/maxscale-system-test/failover_mysqlmon.cpp b/maxscale-system-test/failover_mysqlmon.cpp new file mode 100644 index 000000000..d3315c917 --- /dev/null +++ b/maxscale-system-test/failover_mysqlmon.cpp @@ -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 +#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; +} diff --git a/maxscale-system-test/mysqlmon_detect_standalone_master.cpp b/maxscale-system-test/mysqlmon_detect_standalone_master.cpp index 7d8f8d80f..6ad889c0b 100644 --- a/maxscale-system-test/mysqlmon_detect_standalone_master.cpp +++ b/maxscale-system-test/mysqlmon_detect_standalone_master.cpp @@ -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 "); diff --git a/server/modules/protocol/MySQL/mariadbbackend/mysql_backend.c b/server/modules/protocol/MySQL/mariadbbackend/mysql_backend.c index adc8acbd7..9ac01054a 100644 --- a/server/modules/protocol/MySQL/mariadbbackend/mysql_backend.c +++ b/server/modules/protocol/MySQL/mariadbbackend/mysql_backend.c @@ -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)