Thanks Colin for the feedback. I'm discarding this KIP and I've closed both https://issues.apache.org/jira/browse/KAFKA-5214 and https://issues.apache.org/jira/browse/KAFKA-5723 with links to this discussion.
On Mon, Sep 23, 2019 at 7:18 PM Colin McCabe <cmcc...@apache.org> wrote: > > Hi Mickael, > > The brokerApiVersions command was added for administrators, as a debugging > tool. It wasn't added so that applications could hard-code version > dependencies. Hard-coding different application behaviors in different > versions was exactly what we were attempting to avoid. > > In the example, you gave, you are proposing that the client should look at > the broker API key versions and use that to infer whether > incrementalAlterConfigs exists. But this is brittle, and adds extra coupling > between the client and server that doesn't need to exist. For example, what > if we someday implement incrementalAlterConfigs with a different RPC than RPC > 44? > > This would not be that unreasonable. There are KIPs out there that propose > adding more efficient APIs for listing topics through adding additional API > keys, for example. Even incrementalAlterConfigs was originally proposed as > being a new AlterConfigs version (although this wasn't done, for reasons > which were good, in my opinion.) > > Considering how likely this API is to be misused, I think we should avoid > adding this for now. > > best, > Colin > > > On Fri, Sep 20, 2019, at 10:26, Mickael Maison wrote: > > Thank you Colin for the context. > > > > Before opening the KIP I had a quick look and found the JIRAs you > > linked but saw no traces of the concerns you mentioned. I also found > > the PR but could not find an associated KIP. > > > > The example I provided in the KIP > > (incrementalAlterConfigs/alterConfigs) is one of the cases which would > > benefit from this API. So I'm not sure I fully agree with the concerns > > expressed. The reasons we added the BrokerApiVersionsCommand tool a > > while back must also still be valid. What do you think? > > > > Thanks > > > > On Wed, Sep 18, 2019 at 8:44 PM Colin McCabe <cmcc...@apache.org> wrote: > > > > > > Hi Mickael, > > > > > > Just to give you the context, this is something that's been discussed > > > several times. > > > > > > Check out https://issues.apache.org/jira/browse/KAFKA-5214 and > > > https://issues.apache.org/jira/browse/KAFKA-5723 , as well as this pull > > > request: https://github.com/apache/kafka/pull/3012 > > > > > > I think there was some concern that having a public API that returned API > > > version information would encourage people to write code that only worked > > > against specific broker versions. I remember Ismael and Jay expressed > > > this concern, though I can't find the email threads now... > > > > > > best, > > > Colin > > > > > > > > > On Mon, Sep 16, 2019, at 02:39, Mickael Maison wrote: > > > > Hi all, > > > > > > > > I've created a KIP to add listApiVersions support to the AdminClient. > > > > This will allow us to update the BrokerApiVersionsCommand tool and > > > > more importantly allow users to detect API support and build flexible > > > > client applications: > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-522%3A+Update+BrokerApiVersionsCommand+to+use+AdminClient > > > > > > > > As always, feedback and comments are welcome! > > > > Thanks > > > > > >
