Hi Mickael,

Thanks for the KIP!
It's indeed a pain point for the Kafka admins.

I have some comments:
1. Typo in motivation section: When administrators [when to] remove brokers
from a cluster,....
2. If different `replica.placer.class.name` configs are set in all
controllers, I think only the config for  "active controller" will take
effect, right?
3. Could you explain more about how the proposal fixes some scenarios you
listed, ex: the new added broker case. How could we know the broker is new
added? I guess it's by checking the broker load via some metrics
dynamically, right?


Thank you.
Luke

On Fri, Mar 18, 2022 at 10:30 AM Ryanne Dolan <ryannedo...@gmail.com> wrote:

> Thanks Mickael, this makes sense to me! I've been wanting something like
> this in order to decommission a broker without new partitions getting
> accidentally assigned to it.
>
> Ryanne
>
> On Thu, Mar 17, 2022, 5:56 AM Mickael Maison <mickael.mai...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I'd like to start a new discussion on KIP-660. I originally wrote this
> > KIP in 2020 and the initial discussion
> > (https://lists.apache.org/thread/xn7xyb74nyt281brto4x28r9rzxm4lp9)
> > raised some concerns especially around KRaft (which did not exist at
> > that time) and scalability.
> >
> > Since then, we got a new KRaft controller so I've been able to revisit
> > this KIP. I kept the KIP number as it's essentially the same idea, but
> > the proposal is significantly different:
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-660%3A+Pluggable+ReplicaPlacer
> >
> > Please take a look and let me know if you have any feedback.
> >
> > Thanks,
> > Mickael
> >
>

Reply via email to