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 clarify that if configurations are being proposed for
deletion, they won't appear in proposedConfigs.
Great catch. Wasn't aware of this, but I think it's valuable for the API to
also include the list of configurations to be deleted.
For this, I have extended the `RequestMetadata` type with a list of
proposed configs to delete:
```
class RequestMetadata {
private final ConfigResource resource;
private final Map<String, String> proposedConfigs;
private final List<String> proposedConfigsToDelete;
private final Map<String, String> existingConfigs;
```
Looking forward to your feedback.
Cheers,
Jorge.
On Fri, 2 Jun 2023 at 22:42, Colin McCabe <cmcc...@apache.org> wrote:
> 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
> clarify that if configurations are being proposed for deletion, they won't
> appear in proposedConfigs.
>
> best,
> Colin
>
>
> On Tue, May 23, 2023, at 03:03, Christo Lolov wrote:
> > 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'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 related KIPs in the past that haven't been accepted and
> >> seem retired/abandoned as outlined in the motivation.
> >> The scope of this KIP intends to be more specific to get most of the
> >> benefits from previous discussions; and if previous KIPs are
> resurrected,
> >> should still be possible to do it if this one is adopted.
> >>
> >> Looking forward to your feedback!
> >>
> >> Thanks,
> >> Jorge.
> >>
>
