Thanks Ziming, LGTM!
On Mon, Jan 15, 2024 at 12:00 AM ziming deng
wrote:
> Hello Luke,
>
> thank you for finding this error, I have rectified it, and I will start a
> vote process soon.
>
> --
> Best,
> Ziming
>
>
> > On Jan 12, 2024, at 16:32, Luke Chen wrote:
> >
> > Hi Ziming,
> >
> >
Hello Luke,
thank you for finding this error, I have rectified it, and I will start a vote
process soon.
--
Best,
Ziming
> On Jan 12, 2024, at 16:32, Luke Chen wrote:
>
> Hi Ziming,
>
> Thanks for the KIP!
> LGTM!
> Using incremental by defaul and fallback automatically if it's not
>
Hi Ziming,
Thanks for the KIP!
LGTM!
Using incremental by defaul and fallback automatically if it's not
supported is a good idea!
One minor comment:
1. so I'm inclined to move it to incrementalAlterConfigs and "provide a
flag" to still use alterConfigs for new client to interact with old
Thank you for your clarification, Chris,
I have spent some time to review KIP-894 and I think it's automatic way is
better and bring no side effect, and I will also adopt this way here.
As you mentioned, the changes in semantics is minor, the most important reason
for this change is fixing bug
Hi all,
Can we clarify any changes in the user-facing semantics for the CLI tool
that would come about as a result of this KIP? I think the debate over the
necessity of an opt-in flag, or waiting for 4.0.0, ultimately boils down to
this.
My understanding is that the only changes in semantics are
Hi Ismael,
I added this automatically approach to “Rejected alternatives” concerning that
we need to unify the semantics between alterConfigs and
incrementalAlterConfigs, so I choose to give this privilege to users.
After reviewing these code and doing some tests I found that they following the
Hi Ziming,
Why is the flag required at all? Can we use incremental and fallback
automatically if it's not supported by the broker? At this point, the vast
majority of clusters should support it.
Ismael
On Mon, Dec 18, 2023 at 7:58 PM ziming deng
wrote:
>
> Hello, I want to start a discussion
On Fri, Dec 29, 2023 at 8:49 AM ziming deng wrote:
>
> Hello all,
>
> We have 2 people prefer using "--enable-incremental" and it makes sense to
> move the incompatible process to 4.X, I changed the default way to still use
> `alterConfigs` and use `incrementalAlterConfigs` only when
>
Hello all,
We have 2 people prefer using "--enable-incremental" and it makes sense to move
the incompatible process to 4.X, I changed the default way to still use
`alterConfigs` and use `incrementalAlterConfigs` only when
"--enable-incremental" is specified.
I will initiate a vote process if
Hi Ziming,
Thanks for the KIP! The proposal LGTM.
I'm also inclined towards option 2 (i.e. add an explicit
--enable-incremental flag in 3.X version)
to avoid any incompatible change in v3.X. As mentioned in this thread, many
users might be
using external tools to do the topic rebalance and apply
Thank you for the summary, Ziming.
Personally, I would prefer the latter i.e. having the incompatible change
in 4.x instead of 3.x. This is because a major version upgrade goes through
additional scrutiny by the users and usually comes with inevitable code
changes required on the client. Hence,
Hello Divij Vaidya,
You are right that users should update existing scripts to add
‘—disable-incremental’, and you mentioned another upgrade path which is
similar, the summary of the 2 schemes are:
we change existing scripts to use `incrementalAlterConfigs` and add
"--disable-incremental"
Hi folks
Am I right in understanding that if a user is currently using this CLI to
update old versions (< 2.3.0), they will have to update their scripts and
operational tools when they upgrade ops tools / scripts from Kafka 3.6 to
3.8 (assuming this releases in 3.8)? In that case, may I suggest
+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, Николай Ижиков wrote:
>
>> In fact alterConfig and incrementalAlterConfig have different semantics, we
>> should pass all configs when using
> 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
> 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 wrote:
>
> HI Ziming, thanks for the KIP. Looks
Hello, thanks for mention this.
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
Hello.
Can we just forward all invocations of alterConfig to incrementalAlterConfig?
Transform parameters and call correct method.
> 19 дек. 2023 г., в 11:36, Federico Valeri написал(а):
>
> HI Ziming, thanks for the KIP. Looks good to me.
>
> Just on question: given that alterConfig is
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,
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 wrote:
>
> Thanks for the KIP. I think
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
wrote:
>
> Hello, I want to
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:
22 matches
Mail list logo
