tchughesiv commented on PR #345: URL: https://github.com/apache/incubator-kie-kogito-serverless-operator/pull/345#issuecomment-1898737011
> In my opinion, it would make more sense to have the cluster platform define the services and let the platforms inherit those. It's a one way relationship top to bottom and ensures that changes to the cluster platform CR alone trigger changes to the platforms, rather than both cluster platform CRs and platform CRs. @jordigilh I've also added these notes to the ADR, but here's why that approach sounds nice, but is problematic. - [Cluster-scoped CRDs](https://sdk.operatorframework.io/docs/building-operators/golang/crds-scope/) have no out-of-the-box way to define a namespace for a controller to execute against. It’s not their function and they should not be used that way. They are intended to be used at the cluster level only. - This is problematic and in order to deploy these services, we would have to rely on a `namespace` field somewhere within the `spec`. When a user inevitably changes this `spec.namespace` field, it will lead to orphaned supporting services (e.g. deployment, configmaps, services). This is because the operator will no longer know about the prior services and will move onto creating services in the newly defined location, which consumes additional resources and leads to confusion. - This is also problematic because cluster-scoped CRDs do not require a namespace to exist before creating them. So, a user could point to a non-existent namespace and reconciliation will not work until the user manually created the namespace. This is not an intuitive design and we don’t want the operator to be in the business of creating namespaces in a cluster. - Another major issue would be SonataFlowClusterPlatform services conflicting with SonataFlowPlatform or duplicate services existing in the same namespace. What if a user has already installed a SonataFlowPlatform in that namespace? There’s nothing stopping a user from also defining services in that same namespace. It would take a large effort in the code to maneuver this kind of setup, if it were even possible. - SonataFlowPlatform is a namespaced CRD and is already the single source of truth for supporting services at the namespace level, and it does very well. Why duplicate code or introduce potentially conflicting controllers? By simply adding a reference to an active SonataFlowPlatform, which is what this PR is doing, we avoid all of the above issues and we keep things simple. -- 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]
