Hello community! As anticipated in our community call today, referring to FIP-41 [1], I would like to discuss the positioning of the new repository for the operator.
Rationale: The operator lives in its own dedicated repository rather than as an in-tree module, mirroring the Apache Flink Kubernetes Operator precedent, which itself lives outside the core apache/flink repository. This gives the operator its own release cadence and issue tracker, letting it iterate on Kubernetes API versions and its own CRD independently of Fluss core's release cycle. The operator's Helm chart is packaged and released alongside it, from that same repository. Discussion point: I would favor creating the repository as an *Apache Fluss sub-project*, following the same rules and conventions imposed by the main project and following the Flink example. This would increase the quality and trust in such an important piece of infrastructure for production workloads. If everyone agrees, I can start the bureaucracy and organize contributions in the coming months. [1] https://cwiki.apache.org/confluence/spaces/FLUSS/pages/421957775/FIP-41+Fluss+Kubernetes+Operator -- Lorenzo Affetti Team Leader of Stream Storage [email protected] www.ververica.com ------------------------------ <https://www.stream-forward.org/> <https://www.ververica.com/> Ververica GmbH | Herzogspitalstrasse 24 | 80331 München | Germany Follow us: <https://www.linkedin.com/company/ververica/posts/?feedView=all> <https://www.youtube.com/@ververica> <https://open.spotify.com/show/2XME9h8iBOyr6YupqM99ir?si=87b064644add42a1> Available on: <https://aws.amazon.com/marketplace/pp/prodview-luvmqd6leha4i> <https://marketplace.microsoft.com/en-us/product/saas/ververica.vvc_managed?tab=Overview> Pflichtangaben/Mandatory Information <https://www.ververica.com/mandatory-information>
