use system MariaDBAccount for the galera server's root pw (PR 6 of 6) #347
+1,056
−130
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: zzzeek The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
zzzeek
changed the title
zzzeek
force-pushed
the
OSPRH-14916-pr6
branch
3 times, most recently
from
07f0ddb to
ff2d053
Compare
zzzeek
force-pushed
the
OSPRH-14916-pr6
branch
2 times, most recently
from
54d31c7 to
2fd8211
Compare
zzzeek
force-pushed
the
OSPRH-14916-pr6
branch
5 times, most recently
from
e311b40 to
10549a9
Compare
zzzeek
commented
Oct 12, 2025
| fi | ||
| # If we get here, credentials are invalid, fall through to refresh | ||
| fi | ||
|
|
Contributor
Author
There was a problem hiding this comment.
note we need some extra logic here to detect a root password change in flight. for now we will look in both places to always have a good root password
zzzeek
force-pushed
the
OSPRH-14916-pr6
branch
5 times, most recently
from
6711288 to
3050206
Compare
zzzeek
force-pushed
the
OSPRH-14916-pr6
branch
2 times, most recently
from
e51d940 to
ef65a28
Compare
introduce a new class of MariaDBAccount called a "system" MariaDBAccount, indicated by a new enumerated field AccountType on the CR. Such accounts link directly to a Galera instance and have no dependency on a MariaDBDatabase CR. The expected targets for "system" accounts will include the Galera/mysql root username and password, as well as a system account used by mariadbbackup for SST. Refactor mariadbaccount_controller to isolate logic used for acquiring MariaDBDatabase and Galera CRs into separate functions, and ensure all MariaDBDatabase logic takes place only for "user" accounts (which would be all current MariaDBAccount CRs). Also correct an oversight where MariaDBAccount would not unconditionally apply a finalizer to its Secret object. This logic now takes place in addition to an unconditional removal of the finalizer when the MariaDBAccount object is deleted. A subsequent change will allow system-level passwords to be changed in place by applying the secret name to two separate fields MariaDBAccount/Spec/Secret and MariaDBAccount/Status/Secret. When these two names differ it will indicate an in-place password change should take place.
The existing mariadb operator in fact already "supports" in-place change of secret, since if you change Spec.Secret to a new secret name, that would imply a new job hash, and the account.sh script running using only GRANT statements would update the password per mariadb. This already works for flipping the TLS flag on and off too. So in this patch, we clean this up and add a test to include: * a new field Status.CurrentSecret, which is used to indicate the previous secret from which the finalizer should be removed. This will also be used when we migrate the root password to use MariaDBAccount by providing the "current" root password when changing to a new root password * improved messaging in log messages, name of job. This changes the job hash for mariadbaccount which will incur a run on existing environments, however the job hashes are already changing on existing environments due to the change in how the mysql root password is sent, i.e. via volume mounted script rather than env var secret * update account.sh to use modern idiomatic patterns for user create /alter, while mariadb is fine with the legacy style of using only GRANT statements, MySQL 8 no longer allows this statement to proceed without a CREATE USER, so formalize the commands used here to use distinct CREATE USER, ALTER USER, GRANT statements and clarify the script is good for all create/update user operations.
This commit ties together the previous ones to create a new MariaDBAccount when a Galera instance is created, and then to use the password from that account/secret in the mariadb bootstrap/maintenance scripts. Galera gets bootstrapped with this secret, then the mariadbaccount controller, who is waiting for galera to be available to set up this new "root" account, wakes up when galera is running, and changes the root password to itself, establishing the initial job hash for the mariadbaccount. As we now have a mariadbaccount linked to the outermost lifecycle of a galera instance, some hardening of the deletion process has been added to clarify that mariadbaccount will run deletion jobs only if Galera is not marked for deletion. If galera is marked for deletion, then we have to assume the service/pods are gone and no more drops can take place, even if the Galera CR is still present (chainsaw conveniently adds its own finalizer to Galera when running, preventing it from being fully deleted, which exposed this issue). Additional changes to the mysql_root_auth.sh and account.sh scripts allow for in-place changes of root password. 🤖 Generated with Claude Code (https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
zzzeek
force-pushed
the
OSPRH-14916-pr6
branch
from
ef65a28 to
4e3f794
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit ties together the previous ones to create a new
MariaDBAccount when a Galera instance is created, and then to
use the password from that account/secret in the mariadb
bootstrap/maintenance scripts.
Galera gets bootstrapped with this secret, then the mariadbaccount
controller, who is waiting for galera to be available to set up this
new "root" account, wakes up when galera is running, and changes
the root password to itself, establishing the initial job hash
for the mariadbaccount.
As we now have a mariadbaccount linked to the outermost lifecycle
of a galera instance, some hardening of the deletion process has been
added to clarify that mariadbaccount will run deletion jobs only if
Galera is not marked for deletion. If galera is marked for deletion,
then we have to assume the service/pods are gone and no more drops can
take place, even if the Galera CR is still present (chainsaw
conveniently adds its own finalizer to Galera when running, preventing
it from being fully deleted, which exposed this issue).