Dump and restore galera db during major upgrades

When the overcloud is upgraded we do a yum update of the packages.
This step might introduce a newer galera version. In such a situation
we need to dump the db and restore it. The high-level workflow should
be the following:
1) During the main upgrade step, before shutting down the cluster
   we need to dump the db
2) We upgrade the packages
3) We briefly start mysql on a single node while making sure that
   /root/.my.cnf is briefly moved out of the way (because it contains
   a password) and import the data. After the import we shutdown this
   mysql instance
4) We let the cluster start up normally

The above steps will take place in the following scenarios.
Given a locally installed mariadb version X.Y.Z and release R,
we will dump and restore the DB under the following conditions:
A) MySqlMajorUpgrade template parameter is set to 'auto' and
   the upgraded package differs in X, Y *or* Z. We basically don't
   dump automatically if the release field changes.

B) MySqlMajorUpgrade template parameter is set to 'yes'

When MySqlMajorUpgrade is set to 'no', no dumping will be performed.
Note that this will give a non functional upgrade if a major mariadb
upgrade is taking place.

Partial-Bug: #1587449

Co-Author: Damien Ciabrin <dciabrin@redhat.com>
Co-Author: Mike Bayer <mbayer@redhat.com>

Depends-On: I8cb4cb3193e6b823aad48ad7dbbbb227364d2a58
Depends-On: I38dcacfabc44539aab1f7da85168fe44a1b43a51

Change-Id: I374628547aed091129d0deaa29764bfc998d76ea

1 files changed, 44 insertions, 0 deletions

diff --git a/extraconfig/tasks/major_upgrade_pacemaker_migrations.sh b/extraconfig/tasks/major_upgrade_pacemaker_migrations.sh
index b63198db..164269dc 100644
--- a/extraconfig/tasks/major_upgrade_pacemaker_migrations.sh
+++ b/extraconfig/tasks/major_upgrade_pacemaker_migrations.sh
@@ -13,6 +13,50 @@
 # been already applied, it should be possible to call the function
 # again without damaging the deployment or failing the upgrade.
 
+# If the major version of mysql is going to change after the major
+# upgrade, the database must be upgraded on disk to avoid failures
+# due to internal incompatibilities between major mysql versions
+# https://bugs.launchpad.net/tripleo/+bug/1587449
+# This function detects whether a database upgrade is required
+# after a mysql package upgrade. It returns 0 when no major upgrade
+# has to take place, 1 otherwise.
+function is_mysql_upgrade_needed {
+    # The name of the package which provides mysql might differ
+    # after the upgrade. Consider the generic package name, which
+    # should capture the major version change (e.g. 5.5 -> 10.1)
+    local name="mariadb"
+    local output
+    local ret
+    set +e
+    output=$(yum -q check-update $name)
+    ret=$?
+    set -e
+    if [ $ret -ne 100 ]; then
+        # no updates so we exit
+        echo "0"
+        return
+    fi
+
+    local currentepoch=$(rpm -q --qf "%{epoch}" $name)
+    local currentversion=$(rpm -q --qf "%{version}" $name)
+    local currentrelease=$(rpm -q --qf "%{release}" $name)
+    local newoutput=$(repoquery -a --pkgnarrow=updates --qf "%{epoch} %{version} %{release}\n" $name)
+    local newepoch=$(echo "$newoutput" | awk '{ print $1 }')
+    local newversion=$(echo "$newoutput" | awk '{ print $2 }')
+    local newrelease=$(echo "$newoutput" | awk '{ print $3 }')
+
+    # With this we trigger the dump restore/path if we change either epoch or
+    # version in the package If only the release tag changes we do not do it
+    # FIXME: we could refine this by trying to parse the mariadb version
+    # into X.Y.Z and trigger the update only if X and/or Y change.
+    output=$(python -c "import rpm; rc = rpm.labelCompare((\"$currentepoch\", \"$currentversion\", None), (\"$newepoch\", \"$newversion\", None)); print rc")
+    if [ "$output" != "-1" ]; then
+        echo "0"
+        return
+    fi
+    echo "1"
+}
+
 function add_missing_openstack_core_constraints {
     # The CIBs are saved under /root as they might contain sensitive data
     CIB="/root/migration.cib"