Comment 0 for bug 1704011

Please include this patch in https://github.com/SchedMD/slurm/commit/cca1616b1a1aef9fe049e326a8936d006963b21b?diff=unified

Quote from the patch required.

/* In MySQL 5.7.4 we lost the ability to run 'alter ignore'. This was
 * needed when converting old tables to new schemas. If people convert
 * in the future from an older version of Slurm that needed the ignore
 * to work they will have to downgrade mysql to <= 5.7.3 to make things
 * work correctly or manually edit the database to get things to work.
 */

[Impact]
 * Anyone using SLURM in combination with MySQL on Xenial.
 * slurmdbd uses mysql commands that are no longer valid and will fail to start.

[Test Case]

 * Build yourself a SLURM cluster on Trusty. You can probably get away with only installing slurm-llnl-slurmdbd=2.6.5-1 and mysql-server=5.5.55-0ubuntu0.14.04.1.
 * Use MySQL 5.5 and set 'StorageType = accounting_storage/mysql' in slurmdbd.conf

  You may use the following files to help test if required:
   - http://people.cs.uchicago.edu/~kauffman/slurm-llnl/2017-07-12_mysql-5.5_slurmDB.sql.txt
   - http://people.cs.uchicago.edu/~kauffman/slurm-llnl/etc_slurm-llnl_slurmdbd.conf

  * I did the following as a superficial test:

git clone https://github.com/SchedMD/slurm.git
cd slurm
git show cca1616b1a1aef9fe049e326a8936d006963b21b > ~/slurm_mysql.patch
cd ../
apt-get source slurm-llnl
cd slurm-llnl*
quilt new fix_alter_ignore_unsupported_in_mysql
quilt add auxdir/x_ac_databases.m4 config.h.in configure src/database/mysql_common.c
patch -p1 < ~/slurm_mysql.patch
quilt header -e
quilt refresh
debchange -i
debuild -us -uc -i -I

  * add to my own repositories and since I incremented the version number my version gets installed automatically.

  * upgrade the slurmdbd server from Trusty to Xenial

  * On reboot you should see that the 'slurmdbd.service' is running. If you do not apply this patch it will not start. Error message can be seen by running 'slurmdbd -D -v' if the patch is not applied.

[Regression Potential]
 * I have no idea, I am not a SLURM dev. I'm just a guy that runs a SLURM cluster.
 * Though, I think the risk is very low since this fixes a bug that was fixed by the SLURM devs.