Re: [DISCUSS] KIP-522: Update BrokerApiVersionsCommand to use AdminClient

[Mickael Maison <mi...@gmail.com>]

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 <cm...@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 <cm...@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
> > > >
> >