KIP is updated now:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-935%3A+Extend+AlterConfigPolicy+with+existing+configurations
Looking forward to your feedback,
Many thanks,
Jorge.
On Tue, 25 Jul 2023 at 16:59, Jorge Esteban Quilcate Otoya <
quilcate.jo...@gmail.com> wrote:
> Hi Colin,
Hi Colin, sorry for the belated follow up.
If I understand correctly, on your latest reply proposed to have a new API.
>From the proposed alternatives, I lean towards the first alternative
proposed with 2 config maps, old (before-alter) and new (after-alter).
Deleting a config is effectively retur
Thanks Colin! You're right. I started this KIP only thinking on the latest
incremental API, and haven't thought much on the legacy one.
After taking a another look at both APIs, I can see some inconsistencies on
how the policies are applied in each case. I have added a section "Current
workflow" [
Hi Jorge,
I appreciate you trying to solve the issue. However, from the perspective of
someone using the plugin API, it's quite messy: what is the difference between
"proposed" and "resulting"? They sound the same.
I think there are two APIs that make sense:
1. A (prev, next) based one where y
Thanks Colin! You're right. I have added some notes about this to the KIP,
and clarify how this KIP is related to legacy and incremental alter config
APIs.
Let me know if there's any gaps on the current proposal.
Many thanks,
Jorge.
On Mon, 12 Jun 2023 at 11:04, Colin McCabe wrote:
> See KAFKA
See KAFKA-14195. Some deletions are not handled correctly. And this cannot be
fixed without a kip because of backwards compatibility.
Colin
On Wed, Jun 7, 2023, at 17:07, Jorge Esteban Quilcate Otoya wrote:
> Thank Colin.
>
> I've took a closer look on how configs are passed to the policy when
Thank Colin.
I've took a closer look on how configs are passed to the policy when delete
configs are requested, and either null (KRaft) or empty values
(ZkAdminManager) are passed:
- ZkAdminManager passes empty values:
- Config Entries definition:
https://github.com/apache/kafka/blob/513e1c641d6
On Tue, Jun 6, 2023, at 06:57, Jorge Esteban Quilcate Otoya wrote:
> Thanks Colin.
>
>> I would suggest renaming the "configs" parameter to "proposedConfigs," in
> both the new and old RequestMetadata constructors, to make things clearer.
> This would be a binary and API-compatible change in Java.
Thanks Colin.
> I would suggest renaming the "configs" parameter to "proposedConfigs," in
both the new and old RequestMetadata constructors, to make things clearer.
This would be a binary and API-compatible change in Java.
Sure, fully agree. KIP is updated with this suggestion.
> We should also
Hi Jorge,
This is a good KIP which addresses a real gap we have today.
I would suggest renaming the "configs" parameter to "proposedConfigs," in both
the new and old RequestMetadata constructors, to make things clearer. This
would be a binary and API-compatible change in Java. We should also cl
Hello!
This proposal will address problems with configuration dependencies which I
run into very frequently, so I am fully supporting the development of this
feature!
Best,
Christo
On Mon, 22 May 2023 at 17:18, Jorge Esteban Quilcate Otoya <
quilcate.jo...@gmail.com> wrote:
> Hi everyone,
>
> I
Hi everyone,
I'd like to start a discussion for KIP-935 <
https://cwiki.apache.org/confluence/display/KAFKA/KIP-935%3A+Extend+AlterConfigPolicy+with+existing+configurations>
which proposes extend AlterConfigPolicy with existing configuration to
enable more complex policies.
There have been relate
12 matches
Mail list logo
