[Stretch Cluster] Add stretch cluster feature gate

[rohan-anil-kumar]

Type of change

• Introduced a 'UseStretchCluster' feature gate

Select the type of your PR

• Bugfix
• Enhancement / new feature
• Refactoring
• Documentation

Description

This PR enables a feature gate called UseStretchCluster to enable stretch cluster on the strimzi operator.

Checklist

Please go through this checklist and make sure all applicable tasks have been done

• Write tests
• Make sure all tests pass
• Update documentation
• Check RBAC rights for Kubernetes / OpenShift roles
• Try your changes from Pod inside your Kubernetes and OpenShift cluster, not just locally
• Reference relevant issue(s) and close them after merging
• Update CHANGELOG.md
• Supply screenshots for visual changes, such as Grafana dashboards

Signed-off-by: Rohan Anil Kumar [email protected]

[see-quick]

Hi, @rohan-anil-kumar — thanks a lot for your contribution and interest in working on this!

Just to give a bit of guidance: The proposal for the Stretch Cluster feature hasn’t been approved yet, so introducing a FEATURE_GATE at this stage (without any accompanying logic or PoC) might be a bit premature. Typically, we prefer to see some initial implementation or PoC along with the feature gate to better understand its purpose and how it fits into the broader design. Would you be open to first submitting a more comprehensive PR — perhaps with some basic logic or a minimal PoC — so we can better evaluate it?

[rohan-anil-kumar]

Hi @see-quick, thank you for taking the time to review this PR.
We’d like to clarify that we do have a working PoC for the Stretch Cluster feature. However, the PoC PR turned out to be quite large and difficult to review as a whole. During the recent community call, @ppatierno , @katheris , and others suggested breaking it down into smaller PRs to make the review process easier and more collaborative.
You can find the commits related to the PoC here:
aswinayyolath@6b2671d
aswinayyolath@37c91d3
aswinayyolath@b79389d
aswinayyolath@c4c7b49
aswinayyolath@c8c4cbe
aswinayyolath@f551542
aswinayyolath@afe8819
Additionally, there is a related PR raised by @aswinayyolath here:
#11335
The PoC has been documented in detail here:
https://aswinayyolath.github.io/stretch-kafka-docs/
We’ve incorporated feedback from the community to refine the design, and our goal is to contribute smaller, focused PRs that are easier to review and discuss. This will allow for earlier feedback and smoother collaboration as we work toward finalizing the Stretch Cluster feature.
Thanks again for your guidance and support!

[aswinayyolath]

Hi, @rohan-anil-kumar — thanks a lot for your contribution and interest in working on this!

Just to give a bit of guidance: The proposal for the Stretch Cluster feature hasn’t been approved yet, so introducing a FEATURE_GATE at this stage (without any accompanying logic or PoC) might be a bit premature. Typically, we prefer to see some initial implementation or PoC along with the feature gate to better understand its purpose and how it fits into the broader design. Would you be open to first submitting a more comprehensive PR — perhaps with some basic logic or a minimal PoC — so we can better evaluate it?

Thank you so much for the guidance and quick response!

[Frawless]

We can also create a branch and you can opening smaller PRs against the branch. It will be easier to review smaller changes and it will also does not "polute" main branch witch code parts that are kinda not used at all. Then, at some point, the branch will contain whole feature mostly reviewed and it could be merged. Like as we are doing with STs refactor - #11303 for reference.

[ppatierno]

So @aswinayyolath pinged me offline and I was ok with this approach but maybe what we can do is leveraging the @Frawless approach by going with simpler PRs but through a branch which is not the main.
We mentioned during the community call that it's better going through smaller PRs and I would stick with it instead of a bigger one but using a dedicated branch is a better solution (we can even merge stuff).
@katheris wdyt about that?

Of course the same apply to #11335 by @aswinayyolath

PS: @rohan-anil-kumar I see you tried to ping me and Kate but using wrong tags :-D. So you actually tagged other people.

[katheris]

Hi @rohan-anil-kumar and @aswinayyolath, I do think it's good for the implementation to be delivered in smaller PRs if we can break it down in a way that makes sense. However I have two concerns about this PR:

1. The proposal isn't approved yet, so rather than diverting review time to these draft PRs I think it would be better to focus on getting that approved first.
2. I think you've gone too granular with this PR. Adding a feature gate that does nothing to me is too small a change to add to main. Each PR really needs to do something a little more meaningful.

[aswinayyolath]

Thank you all for the detailed feedback and guidance — really appreciate the direction on how best to proceed 🙏

Just to confirm my understanding:

• A dedicated feature branch (e.g., stretch-cluster-dev) will be created in the Strimzi repo.
• We will raise smaller, logically scoped PRs against this feature branch rather than main.
• These PRs will include meaningful parts of the implementation (not just placeholders).
• Once the feature is complete and reviewed, the feature branch can be merged into main.

In the meantime, we’ll ensure the branch stays up-to-date with main and resolve any conflicts as needed.

Since contributors don’t have permission to create branches in the Strimzi repo, would it be possible for one of the maintainers to create the feature branch for us? We’re happy to start raising PRs against it right away.

Also we'll focus on getting the proposal aligned and approved first..

Thanks again for your support!

[scholzj]

I do not think there should be any merging into any Strimzi branches until the proposal is approved. Once it is approved, it is definitely possible. But keep in mind that there will be still one big PR that needs to be reviewed in order to merge the feature branch into the main branch.