Hi David, Thank you very much for pointing out this, we didn’t mention the deprecation period for this change, since the `incrementalAlterConfigs` api can achieve all the capabilities of `alterConfigs` api (though it’s a best-effort approach, currently it’s 100% achievable in practice), which means switch directly to `incrementalAlterConfigs` won't bring any problems.
For KIP-1011, it’s main focus is to resolve the bug of KAFKA-13788 <https://issues.apache.org/jira/browse/KAFKA-13788> , there will always be a compatibility-break upgrade even without KIP-1011, so we shouldn’t care too much about it, failing to land KIP-1011 on release-3.8 means we didn’t fix the bug promptly rather than we didn’t maintain good compatibility for `ConfigCommand`, we can directly use `incrementalAlterConfigs` since we are already on release-4.0. Luke, do you have any new ideas concerning this description. -- Best, Ziming > On Nov 15, 2024, at 18:47, David Jacot <dja...@confluent.io.INVALID> wrote: > > Hi Ziming, > > I just read the KIP again and I don't see any deprecation period mentioned > in the KIP. Where is it? I only see that we wanted to have a failback prior > to 4.0 and we wanted to remove it in 4.0. However, I don't see anything > mentioning that we would actually warn the user about it. > > Best, > DJ > > On Thu, Nov 14, 2024 at 1:40 PM ziming deng <dengziming1...@gmail.com > <mailto:dengziming1...@gmail.com>> > wrote: > >> 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> <mailto: >> 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 >>>> <mailto: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/> <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/> <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
