Hi Viktor, As far as I know, we haven't make ReplicaPlacer a public interface, and we have no plan to make it public. I think you can submit a discussion or create a JIRA ticket directly without KIP if you have ideas on improving it, right?
-- Best, Ziming > On Nov 29, 2022, at 21:52, Viktor Somogyi-Vass > <viktor.somo...@cloudera.com.INVALID> wrote: > > Hi All, > > I'd like to bump this. I've also updated the KIP to incorporate the new > KRaft changes (ReplicaPlacer). Luckily my proposals were quite similar to > that, so mostly I've made some minor rewording, naming changes, etc. > > Again, the brief summary of the KIP: > - expose replica placement strategies with a new config > - create an admin API and protocol to expose replica placement > functionality (mainly for the reassignment tool) > - create a new multi-level rack awareness strategy which improves > availability on stretch clusters > > I'm happy for any feedback. > > Best, > Viktor > > On Fri, Oct 28, 2022 at 4:14 PM Viktor Somogyi-Vass < > viktor.somo...@cloudera.com> wrote: > >> Hey all, >> >> I'd like to propose a new broker side replica assignment strategy and an >> interface that generalizes replica assignment on brokers and makes them >> pluggable. >> >> Briefly, the motivation for the new replica assignment strategy is that >> more and more of our customers would want to run their clusters in a >> stretched environment, where for instance a cluster is running over >> multiple regions (and multiple racks inside a region). Since this seems >> like a more common need, we'd like to contribute back our implementation >> and also make a generalized interface, so that new strategies that people >> may come up with could be served better. >> >> I welcome any feedback on this KIP. >> >> The link: >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-879%3A+Multi-level+Rack+Awareness >> >> Best to all, >> Viktor >>
