Can the Discussion Thread link be filled out ?
Cheers
On Wed, Sep 27, 2017 at 2:03 AM, Mickael Maison
wrote:
> I don't know the history either, I quickly scanned the KIP-55 threads
> and couldn't see it being discussed.
>
> Anyway, your suggestion sounds good to me, are you planning to do that
I don't know the history either, I quickly scanned the KIP-55 threads
and couldn't see it being discussed.
Anyway, your suggestion sounds good to me, are you planning to do that
as part of KIP-196 or should I create a new JIRA ?
On Wed, Sep 27, 2017 at 3:20 AM, Ewen Cheslack-Postava
wrote:
> It'
It's a fair point that it would undo that sanitization. It's possible that
for compatibility reasons, doing so would require a bit more work and care
(e.g. supporting both sanitized and unsanitized for awhile so users have a
chance to migrate). But I guess my point is that I view the location where
Hi Ewen,
By consistency, I meant having all fields sanitized the same way we
were previously doing for user principal.
But re-reading your previous email, I'm guessing you meant to also
remove the current user principal sanitization from the metrics (only
use that internally for ZK) and have all
On Mon, Sep 25, 2017 at 3:35 AM, Mickael Maison
wrote:
> Hi Ewen,
>
> I understand your point of view and ideally we'd have one convention
> for handling all user provided strings. This KIP reused the
> sanitization mechanism we had in place for user principals.
>
> I think both ways have pros an
Hi Ewen,
I understand your point of view and ideally we'd have one convention
for handling all user provided strings. This KIP reused the
sanitization mechanism we had in place for user principals.
I think both ways have pros and cons but what I like about early
sanitization (as is currently) is
Hi all,
In working on the patch for KIP-196: Add metrics to Kafka Connect
framework, we realized that we have worker and connector/task IDs that are
to be included in metrics and those don't currently have constraints on
naming. I'd prefer to avoid adding naming restrictions or mangling names
unne
Hi Mickael,
I was just wondering why the restriction was imposed for Java clients the
first place, do you know?
Cheers,
Tom
On 14 September 2017 at 09:16, Ismael Juma wrote:
> Thanks for the KIP Mickael. I suggest starting a vote.
>
> Ismael
>
> On Mon, Aug 21, 2017 at 2:51 PM, Mickael Maison
Thanks for the KIP Mickael. I suggest starting a vote.
Ismael
On Mon, Aug 21, 2017 at 2:51 PM, Mickael Maison
wrote:
> Hi all,
>
> I have created a KIP to cleanup the way client-ids are handled by
> brokers and clients.
>
> Currently the Java clients have some restrictions on the client-ids
> t
OK. LGTM then :)
On Wed, Sep 13, 2017 at 12:38 PM Mickael Maison
wrote:
> Yes exactly !
> I've updated the KIP to make it more explicit.
>
> Also I noticed my initial email didn't contain the link to the KIP, so
> here it is:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-190%3A+Handl
Yes exactly !
I've updated the KIP to make it more explicit.
Also I noticed my initial email didn't contain the link to the KIP, so
here it is:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-190%3A+Handle+client-ids+consistently+between+clients+and+brokers
On Tue, Sep 12, 2017 at 7:23 PM,
If I understand you correctly, you are saying:
1. KIP-190 will not affect anyone who doesn't use special characters in
their client IDs
2. Those who have special characters in client IDs already have tons of
metrics issues and won't be inconvenienced by a KIP that fixes them.
Did I get it right?
Hi Gwen, thanks for taking a look at the KIP.
I understand your concern trying to make the transition as smooth as
possible. However there are several issues with the way client-ids
with special characters are handled:
Client-ids that contain invalid ObjectName characters (colon, equals,
etc) curr
Thanks for bumping this. I do have a concern:
This proposal changes the names of existing metrics - as such, it will
require all owners of monitoring systems to update their dashboards. It
will also complicate monitoring of multiple clusters with different
versions and require some modifications t
Even though it's pretty non controversial, I was expecting a few comments.
I'll wait until next week for comments then I'll start the vote.
Thanks
On Mon, Aug 21, 2017 at 6:51 AM, Mickael Maison
wrote:
> Hi all,
>
> I have created a KIP to cleanup the way client-ids are handled by
> brokers and
Hi all,
I have created a KIP to cleanup the way client-ids are handled by
brokers and clients.
Currently the Java clients have some restrictions on the client-ids
that are not enforced by the brokers. Using 3rd party clients,
client-ids containing any characters can be used causing some strange
b
16 matches
Mail list logo
