Hi, Thanks for the KIP. Have we considered using incremental alter configs by default and fallback to the legacy one if the former is unavailable?
The config could have 3 possible values: requested, required, never. The default would be requested. In 4.0, this could would be removed and it would effectively be required. Ismael On Sat, Jan 7, 2023, 10:03 AM John Roesler <vvcep...@apache.org> wrote: > Hi Tina, > > Thanks for the KIP! > > I hope someone with prior MM or Kafka config experience is able to chime > in here; I have neither. > > I took a look at your KIP, and it makes sense to me. I also think your > migration plan is a good one. > > One suggestion: I'm not sure how concerned you are about people's ability > to migrate, but if you want to make it as smooth as possible, you could add > one more step. In the 4.0 release, while removing > `use.incremental.alter.configs`, you can also add > `use.legacy.alter.configs` to give users a path to continue using the old > behavior even after the default changes. > > Clearly, this will prolong the deprecation period, with implications on > code maintenance, so there is some downside. But generally, I've found > going above and beyond to support smooth upgrades for users to be well > worth it in the long run. > > Thanks again, > -John > > > On Fri, Jan 6, 2023, at 05:49, Gantigmaa Selenge wrote: > > Hi everyone, > > > > I would like to start a discussion on the MirrorMaker update that > > proposes > > replacing the deprecated alterConfigs API with the > > incrementalAlterConfigs > > API for syncing topic configurations. Please take a look at the proposal > > here: > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-894%3A+Use+incrementalAlterConfigs+API+for+syncing+topic+configurations > > > > > > Regards, > > Tina >
