You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DNM (yet): Get MYSQL_PWD from cluster query, not env
In order to suit the use case of the MariaDB root password
being changed, we would like to use an approach where a new
secret object is created that contains the new password for root,
which would replace the previous secret. This secret object would
be specific to just the MariaDB root password and no longer part of
osp-secret, and it would ideally be immutable as well, thus the
requirement that a new secret is created, replacing a previous one,
in order to change the password.
(this architecture would also require the
previous secret be accessible in some way in order to facilitate a root
pw change, however that's out of the scope of this particular commit.
Additionally, we may seek to use the MariaDBAccount CR as a parent of
this root-holding secret, but that's also out of scope here and does
not change the fact that a new secret object replaces an old one in
order to change the password).
The implication of this architecture is that all JobSpecs created
by controllers must no longer include the name of the Galera "secret"
inside either any EnvVars or any Volumes, which historically
is the case when using SecretKeySelector, because the presence of
this (now potentially changing) name would become part of the
hash for the Job. This would mean that upon a change of
root secret name all jobs for galera objects
mariadbdatabase, mariadbaccount would go stale, leading to all these
scripts being re-run again, even though the mariadb root password
has no implication of the job results changing. There's also no mechanism
for an "indirect" form of SecretKeySelector to be named that
would move from a parent CR of some kind such as MariaDBAccount, as this goes against
the notion of the "downward API".
Additionally, the scripts running inside the Galera containers also need
access to an updated root password; the current approach of using a
combination of secret volume mounts as well as envvars would imply,
IIUC, these containers need to be rebuilt on root PW change.
This can all be replaced by a robust mechanism to retrieve the current
MySQL root password directly from the k8s API instead, where all scripts
in containers have access to the most recent secret / password at all
times. The approach here is therefore a POC that retrieves the
password from Galera->Spec->Secret. Later, when root password
changes are introduced, this secret will be pulled from a status
field instead indicating the corret root password at the current moment
regardless of changes to secret within the spec.
0 commit comments