mariadbaccount system accounts (PR 4 of 6)

[zzzeek]

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.

[zzzeek]

/retest

[zzzeek]

/retest

[zzzeek]

/retest

[dciabrin]

I need to understand how the deletion of a MariaDBAccount of type System would work if we plan to create one for the root database user. Right now I have the feeling we should have a safeguard mechanism to prevent deleting root.

Also, could you please rewrite the new KUTTL test into a Chainsaw test? I'm trying to get rid of all remaining KUTTL tests before disabling that CI test in prow to free up some CI resource.

[zzzeek]

re: deletion of the root user, the root MariaDBAccount in PR 6 the GaleraSpec gets a field that refers directly to the name of the MariaDBAccount used for root, and like all services that use MariaDBAccount, a finalizer gets associated with it which in this case is from the Galera instance. Galera creates its MariaDBAccount using the same mechanism / function that all the other services use right now to create their MariaDBAccounts.

[zzzeek]

if we are nervous about mistakes (because it's near impossible to recover root from mysql) we can add an additional explicit check in the mariadb controller that tests "this is not the account that Galera has". would have to be careful that doesnt mess up deletion scenarios

[zzzeek]

All the changes are made here and seems to be passing

[dciabrin]

/lgtm

[lmiccini]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lmiccini, zzzeek

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [lmiccini]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dciabrin]

/test mariadb-operator-build-deploy-kuttl

[openshift-ci]

@zzzeek: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/mariadb-operator-build-deploy-kuttl	e72f0dc	link	true	/test mariadb-operator-build-deploy-kuttl

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[zzzeek]

/recheck