tchughesiv commented on code in PR #372:
URL:
https://github.com/apache/incubator-kie-kogito-serverless-operator/pull/372#discussion_r1474622026
##########
controllers/platform/services/services.go:
##########
@@ -138,11 +138,23 @@ func (d DataIndexHandler) MergePodSpec(podSpec
corev1.PodSpec) (corev1.PodSpec,
return *c, err
}
+// hasPostgreSQLConfigured returns true when either the SonataFlow Platform
PostgreSQL CR's structure or the one in the Data Index service specification is
not nil
+func (d DataIndexHandler) hasPostgreSQLConfigured() bool {
+ return (d.platform.Spec.Services.DataIndex.Persistence != nil &&
d.platform.Spec.Services.DataIndex.Persistence.PostgreSql != nil) ||
Review Comment:
No. The purpose of the SonataFlowClusterPlatform is to set cluster-wide
configs for **workflow** consumption, NOT for service consumption. This means
service configs, e.g. persistence, should only ever be affected by the active
platform CR in its own namespace.
To take things a step further, it's important to be *very* careful about
what other platform configs are enabled cluster-wide for workflow consumption
in the future. For example, In my opinion these new global persistence configs
should NOT be enabled cluster-wide for workflows. It would result in a major
security risk for users if our operator is providing creds and connectivity
information haphazardly to every namespace in the cluster. Persistence should
only be set at the namespace level which ensures that only those who should
have the creds are using them.
That said, something like `platform.spec.builds` configs might be a good
candidate at some point.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
