-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[tls] Reflect tls enabled and add func to create my.cnf client cfg #190
[tls] Reflect tls enabled and add func to create my.cnf client cfg #190
Conversation
[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:
Approvers can indicate their approval by writing |
The functionality is moved to the mariadb-operator in openstack-k8s-operators/mariadb-operator#190 Jira: OSPRH-4547
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
eedfb97
to
71d772e
Compare
/lgtm |
/hold |
/test mariadb-operator-build-deploy-kuttl |
/test mariadb-operator-build-deploy-kuttl |
1 similar comment
/test mariadb-operator-build-deploy-kuttl |
a0b2ebc
into
openstack-k8s-operators:main
moves requesting the DB before rendering the service configuration. The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
moves requesting the DB before rendering the service configuration. The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
moves requesting the DB before rendering the service configuration. The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
@@ -51,6 +51,9 @@ type MariaDBDatabaseStatus struct { | |||
Completed bool `json:"completed,omitempty"` | |||
// Map of hashes to track e.g. job status | |||
Hash map[string]string `json:"hash,omitempty"` | |||
|
|||
// Whether TLS is supported by the DB instance | |||
TLSSupport bool `json:"tlsSupport,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
moves requesting the DB before rendering the service configuration. The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
moves requesting the DB before rendering the service configuration. The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
moves requesting the DB before rendering the service configuration. The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Depends-On: openstack-k8s-operators/mariadb-operator#200 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
moves requesting the DB before rendering the service configuration. The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Depends-On: openstack-k8s-operators/mariadb-operator#200 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
moves requesting the DB before rendering the service configuration. The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Depends-On: openstack-k8s-operators/mariadb-operator#200 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
The my.cnf file gets added to the secret holding the service configs. The content of my.cnf is centrally managed in the mariadb-operator and retrieved calling db.GetDatabaseClientConfig(tlsCfg) Depends-On: openstack-k8s-operators/mariadb-operator#190 Depends-On: openstack-k8s-operators/mariadb-operator#191 Jira: OSPRH-4547
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