Replies: 1 comment
-
This is currently not supported. And I guess the way you are doing it is the way I would point you to normally. I think this is would be a bit tricky to implement since the operator in general assumes no relationship between the clusters. And it would also need to separate what is happening -> since you would want it to for example fix both clusters at the same time if they both fail but not do something else. Another thing to check out is the maintenance window which should limit the operator from doing disruptive events on its own. However, the only event it covers right now is the certificate renewal. All other events are always triggered by some outside action (e.g. user changing some configuration, Kubernetes killing some pod etc.). |
Beta Was this translation helpful? Give feedback.
-
Hello!
First of all, I would like to say that this is a great project and we use it at our company!
In our currently use-case we have 2 kafka clusters (lets called main and secondary) that have a direct relationship between them: when the main is offline or with degraded performance, the secondary is used by clients as a failover.
With that said, we don't want both to be rolled at the same time in the upgrade of the strimzi operator, due to their behaviour and purpose.
It would be nice to have some kind of "strategy" configuration for the rollout of the strimzi operator, so that we can choose a more slow approach: rollout each kafka one by one, linearly.
Today the workaround is to manually annotate one cluster to disable reconciliation (https://strimzi.io/docs/operators/latest/deploying.html#proc-pausing-reconciliation-str) during the strimzi upgrade. And then re-enable it after the other kafka cluster were finished rolling.
This works, but its error prone (manual errors).
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions