mattschumpert

@mmaslankaprv I heard this is a misunderstanding perhaps. Should this be closed?

I think it needs to be 'eager and best effort' for the reasons you mention but we should really ensure this logic is wired into every workflow (e.g. #6058). That...

btw, if you think about how we handled partition moves with the balancer in 22.2 (adding an extra replica while movement is in progress), this is along the same lines...

Yes I think that's sufficient and helpful, but A bonus would be to know the # of racks (AZs) currently down (how many racks fewer are available than the max...

Perhaps ideally we can just send a debug bundle with a nicely formatted trace when this happens (including an abort, e.g. OOM) cc @rkruze

@twmb is there a separate ticket for implementing the API itself?

Thanks. should there be 2 tickets and an epic (1 for API, 1 for RPK), or just use this one for both @twmb ?

@twmb really? the RPK side of this is not [documented](https://docs.redpanda.com/current/manage/cluster-maintenance/cluster-balancing/#partition-balancing-with-kafka-api) , nor in the RPK reference as far as I see. if it exists we should file a doc ticket

Understood, so _will_ be in 23.3, not discovered to be already there. @Feediver1 probably worth adding a section below [this](https://docs.redpanda.com/current/manage/cluster-maintenance/cluster-balancing/#partition-balancing-with-kafka-api) with 23.3 docs to indicate you can now do this...

Resolved by https://github.com/redpanda-data/core-internal/issues/35. I think this issue can be closed @jcsp ?