[subscribe Request]

Hi Team, I would like to subscribe to Kafka dev group Thanks, Ashish Singh

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

en+support+for+Kafka > > > > > > Jun, Ashish, Gwen, > > > > Pl review the updated KIP. > > > > Thanks > > Manikumar > > > > > > On Thu, Sep 29, 2016 at 9:56 PM, Ashish Singh <asi...@cloudera.com> wrote: > > > > > Harsh

Re: Reg: ACLS

ms (PLAIN for > example). So Kerberos and SSL are not required (although commonly used). > > Ismael > > On Fri, Dec 9, 2016 at 6:59 PM, Ashish Singh <asi...@cloudera.com> wrote: > > > Hey, > > > > No it does not. Without kerberos or ssl, all requests will

Re: Reg: ACLS

Hey, No it does not. Without kerberos or ssl, all requests will appear to come from anonymous user, and as long as a user is not identified it is not possible to do authorization on. On Fri, Dec 9, 2016 at 10:40 AM, BigData dev wrote: > Hi All, > I have a question

Re: [DISCUSS] KIP-97: Improved Kafka Client RPC Compatibility Policy

ink we > > ought to maintain per-node version information. It would be good to get > > that in so that we can use it as a building block for the stuff > > described in this KIP. I'd be happy to review it. > > > > Colin > > > > > > On Wed, Nov 30, 20

Re: [DISCUSS] KIP-97: Improved Kafka Client RPC Compatibility Policy

mpatibility (if the vote for > this passes). Colin, maybe you can review the PR for KAFKA-3600 and see if > you can build on that? Ashish, it may be worth merging trunk into your > branch and fixing the conflicts. > > Ismael > > On Tue, Nov 29, 2016 at 7:39 PM, Ashish Singh &

Re: [DISCUSS] KIP-97: Improved Kafka Client RPC Compatibility Policy

On Tue, Nov 29, 2016 at 4:11 PM, Colin McCabe <co...@cmccabe.xyz> wrote: > On Tue, Nov 29, 2016, at 11:39, Ashish Singh wrote: > > Hello Colin, > > > > In the KIP you mentioned that currently the client uses supported api > > versions information to check i

Re: [DISCUSS] KIP-97: Improved Kafka Client RPC Compatibility Policy

Hello Colin, In the KIP you mentioned that currently the client uses supported api versions information to check if the server supports its desired versions. Not sure, if that is true. I had put together a PR for KAFKA-3600, to do that, but it never went in. Also, I could not find how you plan to

[Subscribe]

Please subscribe me to this group

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

to discuss KIP-48 and > other > > remaining KIPs. > > > > Thanks, > > > > Jun > > > > On Tue, Aug 23, 2016 at 1:22 PM, Ashish Singh <asi...@cloudera.com> > wrote: > > > >> Thanks Harsha! > >> > >&g

Re: [VOTE] 0.10.1 Release Plan

+1 (non-binding) On Tue, Sep 13, 2016 at 3:53 PM, Joel Koshy wrote: > +1 > > On Tue, Sep 13, 2016 at 2:40 PM, Jason Gustafson > wrote: > > > Hi All, > > > > I'd like to start a vote on the release plan documented here: > >

Re: [ANNOUNCE] New committer: Jason Gustafson

Congrats, Jason! On Tuesday, September 6, 2016, Jason Gustafson wrote: > Thanks all! > > On Tue, Sep 6, 2016 at 5:13 PM, Becket Qin > wrote: > > > Congrats, Jason! > > > > On Tue, Sep 6, 2016 at 5:09 PM, Onur Karaman >

Re: [DISCUSS] KIP-76: Enable getting password from executable rather than passing as plaintext in config files

includes a well thought out > API to integrate with external systems. Since we took this approach in > the past, I'm wondering why not follow the same and use an API to > integrate with credential stores rather than arbitrary executables. > > Gwen > > On Wed, Aug 24, 2016 at 12

[DISCUSS] KIP-76: Enable getting password from executable rather than passing as plaintext in config files

Hey Guys, I’ve just posted KIP-76: Enable getting password from executable rather than passing as plaintext in config files . The proposal is to

Re: Kafka KIP meeting Aug 23 at 11:00am PST

KIP-48 delegation token : Ashish will ping Harsh to see if this is still active. Harsha just replied and he will be willing to join in next KIP call to discuss more about KIP-48. On Tue, Aug 23, 2016 at 1:22 PM, Jun Rao wrote: The following are the notes from today's KIP

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

, Harsha Chintalapani <ka...@harsha.io> wrote: > Ashish, > Yes we are working on it. Lets discuss in the next KIP meeting. > I'll join. > -Harsha > > On Tue, Aug 23, 2016 at 12:07 PM Ashish Singh <asi...@cloudera.com> wrote: > > > Hello Harsha, > >

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hello Harsha, Are you still working on this? Wondering if we can discuss this in next KIP meeting, if you can join. On Mon, Jul 18, 2016 at 9:51 AM, Harsha Chintalapani wrote: > Hi Grant, > We are working on it. Will add the details to KIP about the > request

Re: Review request for KAFKA-3600

t; would be a fantastic reviewer here) who understands and agrees with > the design improves the discussion a lot. > > Gwen > > On Mon, Aug 15, 2016 at 8:27 AM, Ashish Singh <asi...@cloudera.com> wrote: > > Hello Dana, > > > > Thanks for the feedback. > > >

Re: Review request for KAFKA-3600

ry? These aren't used in the kafka-python implementation, so > from my perspective the answer is no. But maybe the java community has > some interesting ideas for improvement where these are key > ingredients. In any case, I think it would probably help substantially > to get some agreeme

Re: Review request for KAFKA-3600

compatibility, which is why I responded as I did... > > Verification is good, but it looked like there was much complexity > added toward very little benefits. > > On Thu, Aug 11, 2016 at 3:37 PM, Ashish Singh <asi...@cloudera.com> wrote: > > Hey Gwen, > &

Re: Review request for KAFKA-3600

preciated, but I > think we need more than appreciation - adding complexity to already > complex clients need to have functional justification... > > Anyway, I was out of the loop for ages, so feel free to yell at me for > missing the obvious. > > Gwen > > On Tue, Aug 9, 2016 at

Re: Review request for KAFKA-3600

Provided wrong link to PR, here is the PR <https://github.com/apache/kafka/pull/1251> for KAFKA-3600. On Tue, Aug 9, 2016 at 9:45 AM, Ashish Singh <asi...@cloudera.com> wrote: > Hey Guys, > > KAFKA-3600 <https://issues.apache.org/jira/browse/KAFKA-3600> was part of

Review request for KAFKA-3600

Hey Guys, KAFKA-3600 was part of KIP-35's proposal. KAFKA-3307 , adding ApiVersionsRequest/Response, was committed to 0.10.0.0, but KAFKA-3600, enhancing java clients, is still under review. Here

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

t's weird to have a `server` package > in a `clients` jar, but that is just making explicit what is happening > either way (we are adding a server-only interface to the `clients` jar). > > Thoughts? > > Ismael > > On Fri, Apr 22, 2016 at 10:56 PM, Ashish Singh <asi..

Re: [VOTE] 0.10.0.0 RC6

+1, verified quickstart with source and binary release. On Saturday, May 21, 2016, Vahid S Hashemian wrote: > +1. I was able to successfully create a topic and run a producer and > consumer against it from the source on Ubuntu 15.04, Mac OS X Yosemite, > and Windows

Re: [VOTE] KIP-50: Move Authorizer to o.a.k.common package - Round 2

io> wrote: > > >Ashish, > > > >Thanks for the proposal. +1 > > > >Jun > > > >On Mon, Apr 25, 2016 at 10:04 AM, Ashish Singh <asi...@cloudera.com> > wrote: > > > >> Hey Guys, > >> > >> I would like to re-initi

Re: KAFKA-1981 Make log compaction point configurable

Hey Eric, One of the project committers should be able to grant permissions to you to create a KIP wiki, but the first question you will get is, what is your confluence id. On Wed, Apr 27, 2016 at 4:54 PM, Eric Wasserman wrote: > I was requested by Ismael Juma ( >

Re: [ANNOUNCE] New committer: Ismael Juma

Congrats Ismael, well deserved! On Monday, April 25, 2016, Guozhang Wang wrote: > Congrats Ismael! > > On Mon, Apr 25, 2016 at 10:52 PM, Neha Narkhede > wrote: > > > The PMC for Apache Kafka has invited Ismael Juma to join as a committer >

Re: [VOTE] KIP-35: Retrieve protocol version - Round 2

; > > > "11. The broker returns its full list of supported ApiKeys and > versions > > > > regardless of current authentication state (e.g., before SASL > > > > authentication). If this is considered to leak information SSL can be > > > use

[VOTE] KIP-50: Move Authorizer to o.a.k.common package - Round 2

Hey Guys, I would like to re-initiate the voting process for KIP-50: Move Authorizer to o.a.k.common package. KIP-50 is available here . Associated PR is available here

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

jar would make sense. But in > the > >> current approach I think the authorizer stuff would be most consistent > as a > >> public package in common. It is true that this means you build against > more > >> stuff then needed but I'm not sure this has any negative i

Re: [VOTE] KIP-35: Retrieve protocol version - Round 2

esponse, we should list ErrorCode before ApiVersions, > right? > Yes. > > Thanks, > > Jun > > On Thu, Apr 21, 2016 at 4:48 PM, Ashish Singh <asi...@cloudera.com> wrote: > > > Hey Guys, > > > > I would like to re-initiate the voting proc

[VOTE] KIP-35: Retrieve protocol version - Round 2

Hey Guys, I would like to re-initiate the voting process for *KIP-35: Retrieve protocol version*. KIP-35 can be accessed here . Following are a couple of related PRs. 1. KAFKA-3307: Add ApiVersion

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Done. Thanks! On Thu, Apr 21, 2016 at 4:32 PM, Gwen Shapira <g...@confluent.io> wrote: > Lets start a vote immediately? We are short of time toward the release. > > On Thu, Apr 21, 2016 at 2:57 PM, Ashish Singh <asi...@cloudera.com> wrote: > > Hey Guys, &

Re: [DISCUSS] KIP-35 - Retrieve protocol version

t;leak" information). > > > > > > If authentication is not configured on the broker all sessions > are > > > > deemed > > > > > > authenticated by default. > > > > > > > > > > > > > > > >

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

ications in > practice. > > -Jay > > On Wed, Apr 20, 2016 at 4:17 PM, Gwen Shapira <g...@confluent.io> wrote: > > > But its just a compile-time dependency, right? > > Since the third-party-authorizer-implementation will be installed on a > > broker where the commo

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

horizer. If we're moving away from this model we should probably rethink > things and be consistent with this, at the very least splitting up common > and clients. > > -Jay > > On Wed, Apr 20, 2016 at 1:04 PM, Ashish Singh <asi...@cloudera.com> wrote: > > > Jun/ Jay/ Gwen/ H

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

Jun/ Jay/ Gwen/ Harsha/ Ismael, As you guys have provided feedback on this earlier, could you review the KIP again? I have updated the PR <https://github.com/apache/kafka/pull/861> as well. On Wed, Apr 20, 2016 at 1:01 PM, Ashish Singh <asi...@cloudera.com> wrote: > Hi Grant, >

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

e/throw? This will help the server in KIP-4 provide meaningful error > codes. KAFKA-3507 <https://issues.apache.org/jira/browse/KAFKA-3507> is > tracking it right now. > That should be good to have. Will include that. Thanks. > > Thanks, > Grant > > > > On Tue, Apr 19,

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

> Hi Team, > > >> > > > >> > Since KIP-48 depends on KIP-43, which is already a bit of a risk for > > >> > the next release - any chance we can delay delegation tokens to > Kafka > > >> > 0.10.1? > > >> >

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Did not realize that you folks were not able to access the discuss thread. Harsha has explicitly added Jitendra and posted his comments, so we should be good to carry on the discussion there. Thanks Harsha! On Mon, Apr 18, 2016 at 11:23 AM, Jitendra Pandey wrote: >

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

d PR as well. ​ On Mon, Apr 11, 2016 at 7:36 PM, Ashish Singh <asi...@cloudera.com> wrote: > Yes, Jun. I would like to try get option 2 in, if possible in 0.10. I am > not asking for delaying 0.10 for it, but some reviews and early feedback > would be great. At this point this is

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Jitendra, Could you post your views on existing discuss thread for KIP-48, http://mail-archives.apache.org/mod_mbox/kafka-dev/201602.mbox/%3cd2f60a7c.61f2c%25pbrahmbh...@hortonworks.com%3E ? On Fri, Apr 15, 2016 at 3:11 PM, Jitendra Pandey wrote: > > The need for a

Re: [RELEASE] Anyone minds if we push the next RC another week away?

Good idea. Thanks! On Friday, April 15, 2016, Ismael Juma wrote: > +1 > > On Fri, Apr 15, 2016 at 4:28 AM, Gwen Shapira > wrote: > > > Hi Team, > > > > As we got more time, we merrily expended the scope of all our > > in-progress KIPs :) > >

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

t;j...@confluent.io> wrote: > Ashish, > > So, you want to take a shot at option 2 for 0.10.0? That's fine with me > too. I am just not sure if we have enough time to think through the > changes. > > Thanks, > > Jun > > On Mon, Apr 11, 2016 at 6:05 PM, Ashish Singh <a

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

zer > api post 0.10.0. > > Thanks > > Jun > > On Fri, Apr 8, 2016 at 9:04 AM, Ashish Singh <asi...@cloudera.com> wrote: > > > Thanks for the input Don. One of the possible paths for Option 2 is to > > completely drop Scala interface, would that be

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

; the nested constants using constructs like Group$.MODULE$, which is not > intuitive in Java. > > Thanks > > Bosco > > > > > On 4/7/16, 4:30 PM, "Ashish Singh" <asi...@cloudera.com <javascript:;>> > wrote: > > >Harsha/ Don, > >

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

not changing any of the zookeeper > data format for acls right? > > Thanks, > Harsha > > On Thu, Apr 7, 2016, at 11:25 AM, Gwen Shapira wrote: > > Can you guys go into details on what will happen during a rolling upgrade > > exactly? > > > > Gwen >

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

Do you suggest otherwise? > -Harsha > > On Thu, Apr 7, 2016, at 10:52 AM, Ashish Singh wrote: > > We might want to take a call here. Following are the options. > > > >1. Let KIP-50 be the way it is, i.e., just add getDescription() to > >existing scala

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

ing on it. If we go with option 2 and commit on getting this in ASAP, preferably in 0.10, there will be fewer implementations that will be affected. *Another thing to notice is that scala authorizer interface is not annotated as unstable.* ​ On Wed, Apr 6, 2016 at 9:41 AM, Ashish Singh <asi...@cloude

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

I see value in minimizing breaking changes and I do not oppose the idea of increasing scope of KIP-50 to move auth interface to java. As authorizer implementations do not really need to depend on Kafka core, I would suggest that we keep authorizer interface and its components in a separate

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Fri, Apr 1, 2016 at 1:32 AM, Ismael Juma wrote: > Two more things: > > 3. We talk about backporting of new request versions to stable branches in > the KIP. In practice, we can't do that until the Java client is changed so > that it doesn't blindly use the latest protocol

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Ismael, thanks for the review. On Fri, Apr 1, 2016 at 1:22 AM, Ismael Juma wrote: > A couple of questions: > > 1. The KIP says "Specific version may be deprecated through protocol > documentation but must still be supported (although it is fair to return an > error code if

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Magnus, it is proposed to be changed in version 1, https://cwiki.apache.org/confluence/display/KAFKA/KIP-4+-+Command+line+and+centralized+administrative+operations#KIP-4-Commandlineandcentralizedadministrativeoperations-MetadataSchema . On Tue, Apr 5, 2016 at 10:23 AM, Magnus Edenhill

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Sounds fair. I am OK with putting down, permanent support of ApiVersion api versions, as a limitation in KIP. On Tue, Apr 5, 2016 at 9:23 AM, Ewen Cheslack-Postava wrote: > On Mon, Apr 4, 2016 at 11:24 AM, Gwen Shapira wrote: > > > > > > > > > >In case

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Null array sounds good to me as well. On Tue, Apr 5, 2016 at 10:06 AM, Ismael Juma wrote: > Yeah, we should use nullable arrays (which have been introduced in > KIP-4-Metadata) instead of empty list to indicate all versions. > > Ismael > On 5 Apr 2016 18:01, "Ewen

Re: [VOTE] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

Jun, KIP-50 is now updated. Mind taking a look. On Mon, Apr 4, 2016 at 10:40 PM, Ashish Singh <asi...@cloudera.com> wrote: > Jun, > > Your suggested approach works, will update the KIP and re-initiate voting. > Thanks! > > On Sun, Apr 3, 2016 at 8:37 AM, Jun Rao &

Re: [VOTE] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

hard to > remove/change an existing method. Grant, could you comment on the latter? > > Thanks, > > Jun > > On Sat, Apr 2, 2016 at 11:43 AM, Ashish Singh <asi...@cloudera.com> wrote: > > > Hello Jun, > > > > > > On Fri, Apr 1, 2016

Re: [VOTE] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

or authorizer implementations to provide more implementation specific info, including supported principal types and more. However, do you think other two reasons I mentioned can convince you for current proposal? > > Jun > > On Wed, Mar 30, 2016 at 11:02 AM, Ashish Singh <asi...@cloude

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

this proposal? > Override of getSupportedPrincipalTypes in SimpleAclAuthorizer will have to return group as well. > > Ismael > > On Mon, Mar 28, 2016 at 9:28 PM, Ashish Singh <asi...@cloudera.com> wrote: > > > Hello Harsha, > > > > Pinging again. This is a

Re: [DISCUSS] KIP-35 - Retrieve protocol version

so important. > > Gwen > > On Fri, Apr 1, 2016 at 1:52 PM, Ashish Singh <asi...@cloudera.com> wrote: > > > Never ever changing the version of VersionReq/resp will be ideal, but it > is > > hard to guarantee that we will never need a change. We should definitely > &g

Re: [DISCUSS] KIP-35 - Retrieve protocol version

se we believe it will require a lot of discussion (read: will be > > > really hard to get right). > > > > > > Maybe it is a hint that this protocol is too difficult for clients to > > > implement? > > > I can't see why is it easy in C and Python and super

Re: [DISCUSS] KIP-35 - Retrieve protocol version

> > > exception if they are not. This gives us the capability going forward > to > > > detect when the client is talking to an older broker, which we don't > have > > > right now. This check should be straightforward, so we could do it now, > > > which wou

Re: [VOTE] KIP-4 Metadata Schema

+1 (non-binding) On Fri, Apr 1, 2016 at 10:16 AM, Gwen Shapira wrote: > +1 > > On Fri, Apr 1, 2016 at 10:12 AM, Jason Gustafson > wrote: > > > +1 (non-binding) > > > > On Fri, Apr 1, 2016 at 8:19 AM, Grant Henke wrote: > > > > > I

Re: [DISCUSS] KIP-35 - Retrieve protocol version

e depended on other clients to test for us. Does that make sense or > not? > > -Jason > > On Thu, Mar 17, 2016 at 4:06 PM, Ashish Singh <asi...@cloudera.com> wrote: > > > We have proposed and discussed majorly three approaches so far, there > were > > many

Re: [VOTE] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

g. > > Gwen > > On Wed, Mar 30, 2016 at 4:34 PM, Gwen Shapira <g...@confluent.io> wrote: > > > +1. > > > > It's a small change and I can see how this will help improve usability > for > > some of the authorizers. > > > > Gwen > >

[VOTE] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

Hi Guys, I would like to open the vote for KIP-50. KIP: https://cwiki.apache.org/confluence/display/KAFKA/KIP-50+-+Enhance+Authorizer+interface+to+be+aware+of+supported+Principal+Types Discuss thread: here

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

I am going to initiate a vote thread for this. On Mon, Mar 28, 2016 at 1:28 PM, Ashish Singh <asi...@cloudera.com> wrote: > Hello Harsha, > > Pinging again. This is a minor KIP and it has been lying around for quite > some time. If providing supported principal types via a

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

Hello Harsha, Pinging again. This is a minor KIP and it has been lying around for quite some time. If providing supported principal types via a config is what you suggest, I am fine with it. On Wed, Mar 9, 2016 at 12:32 PM, Ashish Singh <asi...@cloudera.com> wrote: > Hi Harsha, > &

Re: [VOTE] KIP-51 - List Connectors REST API

+1 (non-binding) On Wed, Mar 23, 2016 at 10:00 AM, Gwen Shapira wrote: > Very large +1 on re-evaluating the KIP process. > > I was hoping we can do a meta-kip meeting after the release (Maybe even > in-person at Kafka Summit?) to discuss. > > On Tue, Mar 22, 2016 at 7:59 PM,

Re: [DISCUSS] KIP-35 - Retrieve protocol version

We have proposed and discussed majorly three approaches so far, there were many minor versions with small variations. Comparing them really requires a side by side proposal and their pros/cons, and I agree with others that this has been lacking in the KIP. We just updated the KIP with following

Re: [DISCUSS] KIP-35 - Retrieve protocol version

the > >> >> proposal is that every single time the client establishes a > connection > >> >> it would then need to issue a metadata request on that connection to > >> >> check supported versions. Is that correct? > >> >> > >> >&

Re: [VOTE] KIP-45: Standardize KafkaConsumer API to use Collection

+1 (non-binding) On Wed, Mar 16, 2016 at 1:40 PM, Ismael Juma wrote: > +1 (non-binding) > > Ismael > > On Tue, Mar 15, 2016 at 9:18 PM, Jason Gustafson > wrote: > > > I'd like to open the vote for KIP-45. We've discussed several > alternatives > > on the

Re: [VOTE] KIP-35: Retrieving protocol version

As the KIP has been modified since we started this vote, the vote is restarted from now. The updated KIP is available at https://cwiki.apache.org/confluence/display/KAFKA/KIP-35+-+Retrieving+protocol+version . On Mon, Mar 14, 2016 at 3:54 PM, Ashish Singh <asi...@cloudera.com> wrote: >

Re: [VOTE] KIP-35: Retrieving protocol version

people are welcome to pitch in. Does it help? > -Jay > > On Mon, Mar 14, 2016 at 3:54 PM, Ashish Singh <asi...@cloudera.com> wrote: > > Hey Guys, > > > > I would like to start voting process for *KIP-35: Retrieving protocol > > version*. The KIP is available h

Re: [DISCUSS] KIP-35 - Retrieve protocol version

PM, Ashish Singh <asi...@cloudera.com> wrote: > I do not have a preference for 1 or 2. 1 basically makes us view supported > versions for all brokers > > On Tuesday, March 15, 2016, Jay Kreps <j...@confluent.io> wrote: > > > Yeah I think there are two possible approa

Re: [DISCUSS] KIP-35 - Retrieve protocol version

ng request=>do work sending=>await response=>do work reading > >> response adding to the state machine around this is not as simple as > >> it seems...you can see the code in the java client around this). > >> > >> It sounds like in this proposal you a

Re: [DISCUSS] KIP-35 - Retrieve protocol version

ate request as having to send a separate request will need clients to wait for two network cycles instead of one. > > It would really be good if the KIP can summarize the whole interaction > and how clients will work. > > -Jay > > On Tue, Mar 15, 2016 at 3:24 PM, Ashish Singh &l

Re: [DISCUSS] KIP-35 - Retrieve protocol version

n that we should really look at the >> details >> > of >> > > >> the >> > > >> >>implementation so we know it works--implementing server >> support >> > > >> without >> > > >> >>actu

Re: [DISCUSS] KIP-35 - Retrieve protocol version

t;>- The semantics of each request in different cases > > > >> >>- Instructions on how to use this to implement a client > > > >> >> > > > >> >> This document is versioned with the protocol number and is the > > &

Re: [DISCUSS] KIP-35 - Retrieve protocol version

out of 0.10 release scope. If testing is the only concern, would librdkafka validation be good enough? > -Jason > > > > On Mon, Mar 14, 2016 at 4:20 PM, Ashish Singh <asi...@cloudera.com> wrote: > > > Hi Jason, > > > > On Mon, Mar 14, 2016 at 4:04 P

Re: [DISCUSS] KIP-35 - Retrieve protocol version

s. Does this sound reasonable to you? > > -Jason > > On Mon, Mar 14, 2016 at 3:34 PM, Ashish Singh <asi...@cloudera.com> wrote: > > > On Mon, Mar 14, 2016 at 2:12 PM, Ismael Juma <ism...@juma.me.uk> wrote: > > > > > On Mon, Mar 14, 2016 at 8:45 PM,

[VOTE] KIP-35: Retrieving protocol version

Hey Guys, I would like to start voting process for *KIP-35: Retrieving protocol version*. The KIP is available here . Here

Re: [DISCUSS] KIP-35 - Retrieve protocol version

I have updated the KIP based on the discussions so far. Will initiate a VOTE thread soon. There are some minor details that are still under discussion, but nothing major to stop us from voting. On Mon, Mar 14, 2016 at 3:39 PM, Ashish Singh <asi...@cloudera.com> wrote: > > > On Mo

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Mon, Mar 14, 2016 at 3:37 PM, Ismael Juma <ism...@juma.me.uk> wrote: > On Mon, Mar 14, 2016 at 10:35 PM, Ashish Singh <asi...@cloudera.com> > wrote: > > > > Also, I think it's a bit odd to say a `single null topic with size -1`. > > Do > >

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Mon, Mar 14, 2016 at 2:12 PM, Ismael Juma wrote: > On Mon, Mar 14, 2016 at 8:45 PM, Gwen Shapira wrote: > > > > > I don't see how it helps. If the client is communicating with a broker > > that > > > does not support KIP-35, that broker will simply close

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Mon, Mar 14, 2016 at 9:37 AM, Gwen Shapira <g...@confluent.io> wrote: > On Mon, Mar 14, 2016 at 7:05 AM, Ismael Juma <ism...@juma.me.uk> wrote: > > Hi Ashish, > > > > A few comments below. > > > > On Fri, Mar 11, 2016 at 9:59 PM, Ashish Singh <as

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Hello Gwen/ Ismael, On Mon, Mar 14, 2016 at 9:55 AM, Ismael Juma wrote: > Hi Gwen, > > On Mon, Mar 14, 2016 at 4:37 PM, Gwen Shapira wrote: > > > On Mon, Mar 14, 2016 at 7:05 AM, Ismael Juma wrote:> > > >>1. Every time a protocol

[DISCUSS] KIP-35 - Retrieve protocol version

gt; > a) the information is cached by the responding broker so it might > be > > >> > outdated ( = cant be trusted) > > >> > b) by the time the client connects to a given broker it might have > > >> upgraded > > >> > >

Re: [DISCUSS] KIP-35 - Retrieve protocol version

@Magnus, Does the latest suggestion sound OK to you. I am planning to update PR based on latest suggestion. On Mon, Mar 7, 2016 at 10:58 AM, Ashish Singh <asi...@cloudera.com> wrote: > > > On Fri, Mar 4, 2016 at 5:46 PM, Jay Kreps <j...@confluent.io> wrote: > >&g

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

purpose of validation, right? > > -Harsha > > On Mon, Mar 7, 2016, at 04:33 PM, Ashish Singh wrote: > > + Parth, Harsha > > > > On Mon, Mar 7, 2016 at 4:32 PM, Ashish Singh <asi...@cloudera.com> > wrote: > > > > > Thanks Gwen. > >

Re: [Discuss] Remove producer configs deprecated in 0.9

> never see 0.9 and therefore never see the deprecation notice. > > I don't think this allows us to remove them at this release. > > On Tue, Mar 8, 2016 at 3:59 PM, Ashish Singh <asi...@cloudera.com> wrote: > > Hey Guys, > > > > Following producer config

[Discuss] Remove producer configs deprecated in 0.9

Hey Guys, Following producer configs were deprecated in 0.9, it might be a good idea to remove them in 0.10. - block.on.buffer.full - metadata.fetch.timeout.ms - timeout.ms Does this sound OK? KAFKA-3353 is tracking this. -- Regards, Ashish

Re: [VOTE] Release plan - Kafka 0.10.0

mplete? > > On Mon, Mar 7, 2016 at 5:15 PM, Ashish Singh <asi...@cloudera.com> wrote: > > +1 (non-binding) > > > > My understanding is that we decided to support upgrading from 08.2.x to > > 0.10.0.0 as well, due to short release cycle. Please correct me if tha

Re: [VOTE] Release plan - Kafka 0.10.0

+1 (non-binding) My understanding is that we decided to support upgrading from 08.2.x to 0.10.0.0 as well, due to short release cycle. Please correct me if that is not true. Created KAFKA-3348 and KAFKA-3349 to add tests for making sure following paths work fine. 1. 0.8.2.x -> 0.10.0.0 2.

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

+ Parth, Harsha On Mon, Mar 7, 2016 at 4:32 PM, Ashish Singh <asi...@cloudera.com> wrote: > Thanks Gwen. > > @Parth, @Harsha pinging you guys for your feedback. Based on discussion on > JIRA, we have following open questions. > >1. > >How to allow an author

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

ould be good to have feedback from > Harsha and Parth. If you can get their "sounds good", we can probably > get it through fairly soon and in time for 0.10.0. > > Gwen > > On Wed, Mar 2, 2016 at 9:47 AM, Ashish Singh <asi...@cloudera.com> wrote: > > Her

Re: KIP call to discuss some of the outstanding KIPs

. > > Gwen > > > On Mon, Mar 7, 2016 at 11:58 AM, Ashish Singh <asi...@cloudera.com> wrote: > > Hello Jun, > > > > Could we have a KIP call tomorrow to discuss some of the outstanding > KIPs. > > As 0.10 code freeze date, as per current suggest

KIP call to discuss some of the outstanding KIPs

Hello Jun, Could we have a KIP call tomorrow to discuss some of the outstanding KIPs. As 0.10 code freeze date, as per current suggestion, is fast approaching, it will really help out with moving forward with following KIPs. * KIP-4: Command line and centralized operations * KIP-35: Retrieve

Re: [DISCUSS] KIP-35 - Retrieve protocol version

ated and removed your highest version then you are > screwed and you're going to get an error no matter what, right? Basically > there is nothing dynamic you can do in that case. > Sure, this should be expected. Just wanted to make sure deprecation is still on the table. > > -Jay &

  1   2   3   4   >