tchughesiv commented on issue #380: URL: https://github.com/apache/incubator-kie-kogito-serverless-operator/issues/380#issuecomment-1930700980
@masayag > Shouldn't the enabled services be determined by the platform configured in `platformRef`? What will be the use case to configure the persistence, DI, and JS and decide not to use them at the cluster-level? Yes and no. The purpose of the SonataFlowClusterPlatform when introduced with https://github.com/apache/incubator-kie-kogito-serverless-operator/pull/345 was to enable specific cluster-wide configs (in this case "supporting services") for **workflow** config consumption, It was NOT intended/designed for service config consumption (DI/JS). This means that service configs, e.g. pod resources & persistence, should only ever be affected by the active platform CR in their own namespace. Additionally, when we started this effort, the idea of a shareable persistence configuration at `platform.spec.persistence` wasn't yet a thing. That is a new feature whose PR is still outstanding https://github.com/apache/incubator-kie-kogito-serverless-operator/pull/372. So, 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 the new global persistence configs in https://github.com/apache/incubator-kie-kogito-serverless-operator/pull/372 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 the ones using them. That said, something like `platform.spec.build` configs might be a good cluster-level candidate at some point. The original discussion on this can be read here https://github.com/apache/incubator-kie-kogito-serverless-operator/pull/372#discussion_r1474153068 and is the reason we created this issue. @ricardozanini wanted to make it more clear (beyond api field descriptions) in the SonataFlowClusterPlatform which "capabilities" are being set cluster-wide, and that the workflows are the main consumers of these "capabilities". This seems like a good approach which would also allow users to customize "capabilities" if they so choose. It would also open the door for future cluster-wide "service" configs, which could be enabled separately w/ a `spec.serviceCapabilities`, for example. > > What about including persistence in that list (in addition to services and build)? For the naming, throwing out this options: > > ``` > spec: > supportedFeatures: > - services > - build > - persistence > ``` If we were to implement this design I think we should stick with `services` at first (since its already been implemented), but this design would allow us to support additional cluster-wide workflow-related configs in the future. > > or `workflowFeatures`, `workflowCapabilities` I think I like `workflowCapabilities` the best so far, but still not sure. -- 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]
