Closed grooverdan closed 5 months ago
@tanji I'm having trouble finding people willing to review these kind of changes, so if you have time your input would be appreciated.
@grooverdan sorry for the delay. It's a bit difficult for me to review something else than the bash code that looks OK.
I am missing (or not understanding) the scenario to test this.
When .my-healthcheck.cnf
is missing /recreate or reset the healtheck
user password and recreate the file.
The .test/run.sh does this ensuring the file is missing, and performs a docker exec ... healthcheck.sh
after the restore, which would fail if the reset didn't happen.
It may be something we should test in the CI
like pre-merge - rather than https://buildbot.mariadb.org/#/builders/311/builds/21042/steps/3/logs/stdio, probably right.
next
branch is meant to be able to work with unreleased MariaDB server, so needs a little rework to use https://ci.mariadb.org/10.11-latest-amd64-ubuntu-2004-deb-autobake.sources. Will be done.
also, the entrypoint is becoming quite big so, it would really help to have a bunch of unit tests automatically executed in the CI.
ok.
…sings
Factor our create_healthcheck_users.
Make sure that when recreating users, if they already exist, we just password reset these and ensure the .my-healtcheck.cnf file is there for usage. We don't want to clobber any existing grants if we happen not to have MARIADB_HEALTHCHECK_GRANTS set.
Because creating users needs to move past --skip-grant-tables with FLUSH PRIVILEGES, and mariadb-upgrade also issue FLUSH PRIVILEGES, then unfortunately is yet another restart.
@NiroDeveloper in #515 you wanted healthcheck user and an easy path, how does using MARIADB_AUTO_UPGRADE=1 (or a db restore), sound as a place to recreate those users if needed?