Hey all, I've updated the KIP with the changes I mentioned earlier. I have not yet removed the --feature-version flag from the upgrade tool.
Please take a look at the API to get the versions for a given metadata version. Right now I'm using ApiVersions request and specifying a metadata version. The supported versions are then supplied in the ApiVersions response. There were tradeoffs with this approach. It is a pretty minimal change, but reusing the API means that it could be confusing (ie, the ApiKeys will be supplied in the response but not needed.) I considered making a whole new API, but that didn't seem necessary for this use. Please please try to let me know in the next few days, I hope to start a vote soon. Thanks, Justine On Mon, Mar 18, 2024 at 9:17 AM Justine Olshan <jols...@confluent.io> wrote: > 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é >> >
