Hi David, In the original scheme of KIP-1011, we were going to maintain a deprecation period before 4.X, which means we won’t fail directly before 4.X, this is consistent with what we have done in KIP-894, currently the PR is not landed onto release-3.9, so there would be no deprecation period if we fail directly on a `UnsupportedVersionException`, even though the likelihood of it is low, it’s still worth considering it.
Luke also think the deprecation period is necessary giving that 4.0 will not remove `alterConfigs`, so I’m willing to maintain compatibility to the next period, for example 4.2, I will try to drive this smooth upgrade process. How do you think about it? Best, Ziming > On Nov 14, 2024, at 16:41, David Jacot <dja...@confluent.io.INVALID> wrote: > > Hi Ziming, > > I am not sure to understand the concern. What's wrong with keeping the > original plan? If I understood it correctly, the plan was to fail > directly if the incrementalAlterConfigs API is not available in 4.x > versions. The new API was introduced in AK 2.3. The likelihood of using the > updated tool with such an old cluster is pretty low in my opinion. > > alterConfigs was deprecated in AK 2.3. It would be great if we could > finally remove it. > > Best, > DJ > > On Thu, Nov 14, 2024 at 7:46 AM Luke Chen <show...@gmail.com > <mailto:show...@gmail.com>> wrote: > >> Hi Ziming, >> >> We should go through the depreciation period before removing/failing it. >> I remember the `alterConfigs` will still exist in v4.0.0, right? If so, I >> think we should go with option (1). >> >> Thanks. >> Luke >> >> On Thu, Nov 14, 2024 at 2:38 PM ziming deng <dengziming1...@gmail.com> >> wrote: >> >>> Hi Kafka devs, I have initiated KIP-1011 in which we have concluded that >>> we will replace deprecated `alterConfigs` with `incrementalAlterConfigs` in >>> command line tool `CommandConfig`. In the design, if the server doesn’t >>> support `incrementalAlterConfigs`, we would fallback to `alterConfigs` >>> for pre-4.0 client and directly fail for a post-4.0 client. >>> >>> The KIP-1011 document link: >>> KIP-1011: Use incrementalAlterConfigs when updating broker configs by >>> kafka-configs.sh - Apache Kafka - Apache Software Foundation >>> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh> >>> cwiki.apache.org <http://cwiki.apache.org/> >>> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh> >>> [image: favicon.ico] >>> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh> >>> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh> >>> >>> >>> I implemented it here: >>> KAFKA-16181: Use incrementalAlterConfigs when updating broker configs by >>> kafka-configs.sh by dengziming · Pull Request #15304 · apache/kafka >>> <https://github.com/apache/kafka/pull/15304> >>> github.com <http://github.com/> <https://github.com/apache/kafka/pull/15304> >>> [image: apple-touch-icon-180x180-a80b8e11abe2.png] >>> <https://github.com/apache/kafka/pull/15304> >>> <https://github.com/apache/kafka/pull/15304> >>> >>> >>> And I’m sorry that I failed to push forward the PR timely due to my >>> personal reason, and now we are preparing releasing 4.0 in which >>> `alterConfigs` >>> is supposed to be removed, so what’s the best way to improvised this KIP, >>> here are 2 ideas: >>> 1. Postponing removing `alterConfigs` until the new major release. >>> 2. Directly remove `alterConfigs` and use `incrementalAlterConfigs` in ` >>> CommandConfig`. >>> >>> Do you have some ideas, I’m looking forward to your points. >>> >>> --- >>> Best, >>> Ziming
