Hi Chris, thanks. This looks like a useful feature.

Due to the idempotent nature of PUT, I guess that the last_modified
timestamp won't change if the same request is repeated successively.
Should we add a unit test for that?

On Mon, Sep 4, 2023 at 6:17 AM Ashwin <apan...@confluent.io.invalid> wrote:
>
> Hi Chris,
>
> Thanks for thinking about this useful feature !
> I had a question regarding
>
> > Since cluster metadata is not required to handle these types of request,
> they will not be forwarded to the leader
>
> And later, we also mention about supporting more scope types in the future.
> Don't you foresee a future scope type which may require cluster metadata ?
> In that case, isn't it better to forward the requests to the leader in the
> initial implementation ?
>
> I would also recommend an additional system test for Standalone herder to
> ensure that the new scope parameter is honored and the response contains
> the last modified time.
>
> Thanks,
> Ashwin
>
> On Sat, Sep 2, 2023 at 5:12 AM Chris Egerton <chr...@aiven.io.invalid>
> wrote:
>
> > Hi all,
> >
> > Can't imagine a worse time to publish a new KIP (it's late on a Friday and
> > we're in the middle of the 3.6.0 release), but I wanted to put forth
> > KIP-976 for discussion:
> >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-976%3A+Cluster-wide+dynamic+log+adjustment+for+Kafka+Connect
> >
> > TL;DR: The API to dynamically adjust log levels at runtime with Connect is
> > great, and I'd like to augment it with support to adjust log levels for
> > every worker in the cluster (instead of just the worker that receives the
> > REST request).
> >
> > I look forward to everyone's thoughts, but expect that this will probably
> > take a bump or two once the dust has settled on 3.6.0. Huge thanks to
> > everyone that's contributed to that release so far, especially our release
> > manager Satish!
> >
> > Cheers,
> >
> > Chris
> >

Reply via email to