[tls] Reflect tls enabled and add func to create my.cnf client cfg

[stuggi]

Moves function to get the my.cnf client config from lib-common to this operator and returns the client config for both tls and non tls use case depending if the Galera cluster is configured to support TLS.

Jira: OSPRH-4547

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: stuggi

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 [stuggi]

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

[dciabrin]

/lgtm

[stuggi]

/hold

[stuggi]

/test mariadb-operator-build-deploy-kuttl

[stuggi]

/test mariadb-operator-build-deploy-kuttl

[stuggi]

/test mariadb-operator-build-deploy-kuttl

[zzzeek]

Why is this copied to each MariaDBDatabase? When we populate this in Database{} we could look it up directly from Galera can't we ? What happens if Galera.Spec.TLS.Enabled is changed from False->True or True->False, does that get propagated to every MariaDBDatabase CR that already exists?

[stuggi]

technically yes, but there is on issue with the way we do it right now and not using something like the transporturl for DB is to make the owner (service-operator) to reconcile if there is a config change. right now the service-operators creates/owns the mariadbdatabase, but there is no connection/relation to the galera instance. if the configuration for galera changes, e.g. non tls -> tls, the services would not reconcile and get an updated my.cnf. reflecting this in the status here would do it as they own the mariadbdatabase. there is still a todo for the mariadbdatabase to watch the galera object they relate to.

iirc, you plan to move the mariadbaccount creation to the openstack-operator, which is the one who knows if galera was configured with tls, an option would be to make the my.cnf a part of the account secret the service-operator the would consume, but still the mariadbaccount then would have to reconcile if the galera changes

[zzzeek]

OK we should think about this, that is, we have Galera -> MariaDBDatabase -> MariaDBAccount , then what are the resource(s) that consuming operators are actually watching and using to get their information from. These three CRs are separate because they point to different things that start and stop, create and destroy. But, a controller that just wants to connect doesnt need to know all that which is why we have the Database facade, which right now does not feel to be too clear how this is used, right now it feels like a command object to send instructions but not so much consumed for information....but also I dont like using the Database object to consume because it makes for state variables being copied from CR to facade and that gets confusing too.

I think getting things into my.cnf and really using that as a single point of (nearly) everything will help with all this so we dont have to keep copying individual flags in multiple places.

[stuggi]

we need to consume and watch something, otherwise we can not detect changes, right? This patch is the initial version to get things into my.cnf and the connection url always refers to it. I think the question is not if we should use my.cnf for a single point, it is more where do we create the my.cnf and how would it be updated on required changes due to an DB/instance change, like in the current example change from non tls -> tls. The service operators will consume MariaDBDatabase and MariaDBAccount, I don't think we also want them to watch or have a relation to Galera, or do we?
I am not sure if there will be any other galera instance parameter important to reconcile. replicating the tls to the DB was meant to show to the owner of the MariaDBDatabase "your DB is ready and it supports TLS". If tls is used is then driven by the RequireTLS from MariaDBAccount and the resulting generated my.cnf, where RequireTLS is not yet taken into account to create it. Where would you create the my.cnf and trigger a reconcile if tls support changes on the galera instance?

[zzzeek]

point taken, we have to watch something, it cant be Database{} because that's not a resource, so it's MariaDBDatabase, that's fine. galera_controller and/or mariadb_controller need to be updated so that when TLS changes on Galera, it gets copied out to all the MariaDBDatabase instances on that Galera, which will complete the chain. is that accurate ?

[stuggi]

the service operators own the MariaDBDatabase, so they already should watch it. the only thing we need to do is add a watch to the MariaDBDatabase to reconcile when the Galera it corresponds to changes. if this results in an object change the service operator will also reconcile. MariaDBDatabase uses a labelselector [1] to get its galera instance can use the same to create a watch. An alternative would be to change the MariaDBDatabase to pass in the DatabaseInstance from the owner instead of the label selector.

[1] https://github.com/openstack-k8s-operators/mariadb-operator/blob/main/controllers/mariadbdatabase_controller.go#L251