+1 for adding them to rejected alternatives, These kafka-ui tools should also evolve with the iterations of Kafka.
> On Dec 21, 2023, at 16:58, Николай Ижиков <nizhi...@apache.org> wrote: > >> In fact alterConfig and incrementalAlterConfig have different semantics, we >> should pass all configs when using alterConfig and we can update config >> incrementally using incrementalAlterConfigs, and is’t not worth doing so >> since alterConfig has been deprecated for a long time. > > There can be third-party tools like `kafka-ui` or similar that suffer from > the same bug as you fixing. > If we fix `alterConfig` itself then we fix all tools, scripts that still > using alterConfig. > > Anyway, let’s add to the «Rejected alternatives» section reasons - why we > keep buggy method as is and fixing only tools. > >> I think your suggestion is nice, it should be marked as deprecated and will >> be removed together with `AdminClient.alterConfigs()` > > Is it OK to introduce option that is deprecated from the beginning? > > >> 21 дек. 2023 г., в 06:03, ziming deng <dengziming1...@gmail.com >> <mailto:dengziming1...@gmail.com>> написал(а): >> >>> shouldn't we also introduce --disable-incremental as deprecated? >> >> I think your suggestion is nice, it should be marked as deprecated and will >> be removed together with `AdminClient.alterConfigs()` >> >> >>> On Dec 19, 2023, at 16:36, Federico Valeri <fedeval...@gmail.com> wrote: >>> >>> HI Ziming, thanks for the KIP. Looks good to me. >>> >>> Just on question: given that alterConfig is deprecated, shouldn't we >>> also introduce --disable-incremental as deprecated? That way we would >>> get rid of both in Kafka 4.0. Also see: >>> https://issues.apache.org/jira/browse/KAFKA-14705. >>> >>> On Tue, Dec 19, 2023 at 9:05 AM ziming deng <dengziming1...@gmail.com >>> <mailto:dengziming1...@gmail.com><mailto:dengziming1...@gmail.com>> wrote: >>>> >>>> Thank you for mention this Ismael, >>>> >>>> I added this to the motivation section, and I think we can still update >>>> configs in this case by passing all sensitive configs, which is weird and >>>> not friendly. >>>> >>>> -- >>>> Best, >>>> Ziming >>>> >>>>> On Dec 19, 2023, at 14:24, Ismael Juma <m...@ismaeljuma.com >>>>> <mailto:m...@ismaeljuma.com>> wrote: >>>>> >>>>> Thanks for the KIP. I think one of the main benefits of the change isn't >>>>> listed: sensitive configs make it impossible to make updates with the >>>>> current cli tool because sensitive config values are never returned. >>>>> >>>>> Ismael >>>>> >>>>> On Mon, Dec 18, 2023 at 7:58 PM ziming deng <dengziming1...@gmail.com >>>>> <mailto:dengziming1...@gmail.com><mailto:dengziming1...@gmail.com> >>>>> <mailto:dengziming1...@gmail.com>> wrote: >>>>>> >>>>>> Hello, I want to start a discussion on KIP-1011, to make the broker >>>>>> config change path unified with that of user/topic/client-metrics and >>>>>> avoid some bugs. >>>>>> >>>>>> Here is the link: >>>>>> >>>>>> KIP-1011: Use incrementalAlterConfigs when updating broker configs by >>>>>> kafka-configs.sh - Apache Kafka - Apache Software Foundation >>>>>> 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>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> >>>>>> >>>>>> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh> >>>>>> >>>>>> Best, >>>>>> Ziming.
