Comment 7 for bug 1624013

We've been investigating this proposed fix, and we're not convinced it is the right fix. We now believe that this is a race condition / ordering issue - if we manually run the "mysql -uclustercheck -p50cUWiAnI86oXBhx7OcthBer -Nbe "show status like 'wsrep_local_state_comment'"" after a failed deployment, the command returns successfully As previously mentioned, a second attempt to deploy does often also succeed (but deploying a new controller to an existing environment has never succeeded)

Even with successful deployments, two of the symptoms I originally described still appear (service mysql status always shows it is stopped, and /var/log/mysql/error.log includes this error), and we noticed that the same mysql package is used in MOS8 and MOS7.

We've been unable to test the proposed fix as our attempts to regenerate the local package cache with the replacement package are failing with verification errors.

How can we prove that this proposed fix works in our environment?

Reverted to 'confirmed' for further input and requesting confirmation that, despite the above concerns, Mirantis are convinced that the mysql package upgrade will definitely fix this issue.