Hey folks,

I didn't have a strong preference for requesting the versions via the tool
only or getting it from the server. Colin seemed to suggest it was "for the
best" to request from the server to make the tool lightweight.
I guess the argument against that is having to build and support another
API.

It also seems like there may be some confusion -- partially on my part. For
the tools, I had a question about the feature upgrade tool. So it seems
like we already support multiple features via the `--feature` flag, we
simply rely on the server side to throw errors now?

Justine

On Fri, Mar 15, 2024 at 3:38 PM José Armando García Sancio
<jsan...@confluent.io.invalid> wrote:

> Hi Justine,
>
> Thanks for the update. Some comments below.
>
> On Wed, Mar 13, 2024 at 10:53 AM Justine Olshan
> <jols...@confluent.io.invalid> wrote:
> > 4. Include an API to list the features for a given metadata version
>
> I am not opposed to designing and implementing this. I am just
> wondering if this is strictly required?
>
> Would having auto-generated documentation address the issue of not
> knowing which feature versions are associated with a given release
> version?
>
> Does it need to be a Kafka API (RPC)? Or can this be strictly
> implemented in the tool? The latest tool, which is needed to parse
> release version to feature version, can print this mapping. Is this
> what you mean by API?
>
> > 5. I'm going back and forth on whether we should support the
> > --release-version flag still. If we do, we need to include validation so
> we
> > only upgrade on upgrade.
>
> I am not sure how this is different from supporting multiple --feature
> flags. The user can run an upgrade command where some of the features
> specified are greater than what the cluster has finalized and some of
> the features specified are less than what the cluster has finalized.
>
> In other words, the KRaft controller and kafka-storage tool are going
> to have to implement this validation even if you don't implement
> --release-version in the tools.
> Thanks,
> --
> -José
>

Reply via email to