Hi all,
We have completed the implementation of the KIP. During the implementation
of the second part, we have reworked the metrics. We have ended up with
only one metric which represents the number of connections using a given
client software name and version. We have made it per selector as it
s
+1
On Mon, Oct 14, 2019 at 3:47 PM David Jacot wrote:
> Hi all,
>
> Jun,
> The new fields are not flexible fields while the request and response are
> flexible versions. It does not cost us because the version of the request
> is bumped anyway to enable the flexible versions. The rationale behin
Hi all,
Jun,
The new fields are not flexible fields while the request and response are
flexible versions. It does not cost us because the version of the request
is bumped anyway to enable the flexible versions. The rationale behind this
choice is that it forces the clients to provide the informati
+1 (binding). Thanks for the KIP this is going to be super useful.
Thanks,
Harsha
On Fri, Oct 11, 2019 at 2:57 PM Guozhang Wang wrote:
> Hi David,
>
> Thanks for the KIP. I know I'm late on voting here but I'd be +1 on this
> too!
>
> Just a quick clarification on the tag "name=Connections" of
Hi David,
Thanks for the KIP. I know I'm late on voting here but I'd be +1 on this
too!
Just a quick clarification on the tag "name=Connections" of the third
metric, what would be the format of "Connections" here? Would that be the
connection listener name?
Guozhang
On Fri, Oct 11, 2019 at 1:
Hi, David,
Thanks for the KIP. Just a minor comment below.
100. It seems that the new flexible fields need tag numbers. Could you add
them to the wiki?
Jun
On Mon, Sep 23, 2019 at 11:37 AM Jason Gustafson wrote:
> Thanks David for the clarification. That sounds good.
>
> On Mon, Sep 23, 2019
Thanks David for the clarification. That sounds good.
On Mon, Sep 23, 2019 at 12:35 AM David Jacot wrote:
> Hi all,
>
> The vote has passed with +3 binding votes (Colin McCabe, Gwen Shapira,
> Jason Gustafson) and +3 non binding votes (Mickael Maison, Konstantine
> Karantasis, Kevin Lu). \o/
>
>
Hi all,
The vote has passed with +3 binding votes (Colin McCabe, Gwen Shapira,
Jason Gustafson) and +3 non binding votes (Mickael Maison, Konstantine
Karantasis, Kevin Lu). \o/
Thanks to everyone that reviewed and helped improve this proposal, and
huge thanks to Colin for his great feedback.
Bes
Hi Jason,
The response will be a flexible version but the response header won't be
(only for the api versions response). I have forgotten to change this point
in the KIP. I will make this point clearer.
I didn't know that INVALID_REQUEST already exists. Yes, it makes sense to
reuse it then.
Best
+1 (non-binding)
Definitely needed this before as it would have saved me some time from
trying to guess a client's version from api version/source code. Thanks for
the KIP!
Regards,
Kevin
On Fri, Sep 20, 2019 at 4:29 PM Jason Gustafson wrote:
> +1 from me. This is a clever solution. Kind of a
+1 from me. This is a clever solution. Kind of a pity we couldn't work
flexible version support into the response, but I understand why it is
difficult.
One minor nitpick: the INVALID_REQUEST error already exists. Are you
intending to reuse it?
Thanks,
Jason
On Fri, Sep 20, 2019 at 3:50 PM Konst
Quite useful KIP from an operational standpoint and I also like it in its
most recent revised form.
+1 (non-binding).
Konstantine
On Fri, Sep 20, 2019 at 9:55 AM Gwen Shapira wrote:
> +1 (binding)
>
> Thanks for the KIP, David and for the help with the design, Colin. I
> think it looks great
+1 (binding)
Thanks for the KIP, David and for the help with the design, Colin. I
think it looks great now.
On Fri, Sep 20, 2019 at 9:42 AM Colin McCabe wrote:
>
> On Fri, Sep 20, 2019, at 01:45, David Jacot wrote:
> > > Thanks for the clarification. The proposed behavior sounds reasonable.
> >
On Fri, Sep 20, 2019, at 01:45, David Jacot wrote:
> > Thanks for the clarification. The proposed behavior sounds reasonable.
> > Can you add a note about the implementation on the client? The client
> > needs to be prepared to handle > a response that doesn't include the
> > versions, as well, s
> Thanks for the clarification. The proposed behavior sounds reasonable.
Can you add a note about the implementation on the client? The client
needs to be prepared to handle > a response that doesn't include the
versions, as well, since v1 did not.
I have added a note about the implementation in
On Wed, Sep 18, 2019, at 23:44, David Jacot wrote:
> Hi Colin,
>
> Thank you for your feedback! Please find my comments/answers below:
>
> *> Nitpick: in the intro paragraph, "Operators of Apache Kafka clusters
> have literally no information about the clients connected to their
> clusters" seems
Hi all,
I have updated the KIP to incorporate Colin's feedback.
Best,
David
On Thu, Sep 19, 2019 at 8:44 AM David Jacot wrote:
> Hi Colin,
>
> Thank you for your feedback! Please find my comments/answers below:
>
> *> Nitpick: in the intro paragraph, "Operators of Apache Kafka clusters
> have
Hi Colin,
Thank you for your feedback! Please find my comments/answers below:
*> Nitpick: in the intro paragraph, "Operators of Apache Kafka clusters
have literally no information about the clients connected to their
clusters" seems a bit too strong. We have some information, right? For
example
That's fair. We could use the existing error code in the response and pass
back something like INVALID_REQUEST.
I'm not sure if we want to add an error string field just for this (although
they're a good idea in general...)
best,
Colin
On Wed, Sep 18, 2019, at 12:31, Magnus Edenhill wrote:
>
> I think we should force client software names and versions to follow a
regular expression and disconnect if they do not.
Disconnecting is not really a great error propagation method since it
leaves the client oblivious to what went wrong.
Instead suggest we return an ApiVersionResponse with an e
Hi David,
Thanks for the KIP!
Nitpick: in the intro paragraph, "Operators of Apache Kafka clusters have
literally no information about the clients connected to their clusters" seems a
bit too strong. We have some information, right? For example, the client ID,
where clients are connecting fr
+1 (non binding)
Thanks for the KIP!
On Mon, Sep 16, 2019 at 12:07 PM David Jacot wrote:
>
> Hi all,
>
> I would like to start a vote on KIP-511:
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-511%3A+Collect+and+Expose+Client%27s+Name+and+Version+in+the+Brokers
>
> Best,
> David
Hi all,
I would like to start a vote on KIP-511:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-511%3A+Collect+and+Expose+Client%27s+Name+and+Version+in+the+Brokers
Best,
David
23 matches
Mail list logo
