[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

with the following: > > 1. Protocol and Config changes > > 2. format of the data stored in ZK. > > 3. Changes to Java Clients/Usage of SASL SCRAM mechanism > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > > 48+Delegation+token+support+f

Re: Reg: ACLS

e). So Kerberos and SSL are not required (although commonly used). > > Ismael > > On Fri, Dec 9, 2016 at 6:59 PM, Ashish Singh wrote: > > > Hey, > > > > No it does not. Without kerberos or ssl, all requests will appear to come > > from anonymous user, and

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 here, Does Kafka support ACL's

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

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, 2016, at 10:40, Ash

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

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 wrote: > > &g

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

On Tue, Nov 29, 2016 at 4:11 PM, Colin McCabe 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 if the server supports its de

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

ntalapani > wrote: > > The only pending update for the KIP is to write up the protocol changes > like > > we've it KIP-4. I'll update the wiki. > > > > > > On Thu, Sep 15, 2016 at 4:27 PM Ashish Singh > wrote: > >> > >> I think we dec

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

KIPs. > > > > Thanks, > > > > Jun > > > > On Tue, Aug 23, 2016 at 1:22 PM, Ashish Singh > wrote: > > > >> Thanks Harsha! > >> > >> Jun, can we add KIP-48 to next KIP hangout's agenda. Also, we did not > >> actually

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: > > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+0.10.1. I

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 > > > > > wrote: > > > > > congrats jason! > > > > > > On Tue, Sep 6, 2016 at

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

> 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:03 PM, Ashish Singh

[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 enab

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 discussion. > > >-

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

10 PM, Harsha Chintalapani 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 wrote: > > > Hello Harsha, > > > > Are you still working on thi

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 protocol. > > Thanks, > H

Re: [ANNOUNCE] New Kafka PMC member Gwen Shapira

Congrats Gwen! On Thursday, August 18, 2016, Grant Henke wrote: > Congratulations Gwen! > > > > On Thu, Aug 18, 2016 at 2:36 AM, Ismael Juma > wrote: > > > Congratulations Gwen! Great news. > > > > Ismael > > > > On 18 Aug 2016 2:44 am, "Jun Rao" > > wrote: > > > > > Hi, Everyone, > > > > > > G

Re: Review request for KAFKA-3600

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 wrote: > > Hello Dana, > > > > Thanks for the feedback. > > > > Kafka-3600 is not intended to address bac

Re: Review request for KAFKA-3600

ersion > necessary? 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 >

Re: Review request for KAFKA-3600

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 wrote: > > Hey Gwen, > > > > I think this was more than a verification

Re: Review request for KAFKA-3600

t 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 8:47 AM,

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 wrote: > Hey Guys, > > KAFKA-3600 <https://issues.apache.org/jira/browse/KAFKA-3600> was part of > KIP-35's

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 i

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

e 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 > wrote: > > > He

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 7. > --Vahid > > > > From:

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

nks for the proposal. +1 > > > >Jun > > > >On Mon, Apr 25, 2016 at 10:04 AM, Ashish Singh > wrote: > > > >> Hey Guys, > >> > >> I would like to re-initiate the voting process for KIP-50: Move > Authorizer > >> to o.a.k.common p

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 ( > https://issues.apache.org/jira

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 > and > > we are pleased to announce that he has accepted

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

this example. If we do need it, then > > we > > > > should define the state of 0.9.1 compared to 0.9.0 before we decide > to > > > > backport APIs. > > > > > > > > "11. The broker returns its full list of supported ApiKeys and > versions

[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

>> 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 implications in > >> practice. > >

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

rrorCode before ApiVersions, > right? > Yes. > > Thanks, > > Jun > > On Thu, Apr 21, 2016 at 4:48 PM, Ashish Singh wrote: > > > Hey Guys, > > > > I would like to re-initiate the voting process for *KIP-35: Retrieve > > protocol version*. >

[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 request/

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

Done. Thanks! On Thu, Apr 21, 2016 at 4:32 PM, Gwen Shapira 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 wrote: > > Hey Guys, > > > > KIP-35 > > < > https://cwiki.apa

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

> If authentication is not configured on the broker all sessions > are > > > > deemed > > > > > > authenticated by default. > > > > > > > > > > > > > > > > > > Re backwards compatibility: >

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

; practice. > > -Jay > > On Wed, Apr 20, 2016 at 4:17 PM, Gwen Shapira wrote: > > > But its just a compile-time dependency, right? > > Since the third-party-authorizer-implementation will be installed on a > > broker where the common classes will exist anyway. >

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

er. 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 wrote: > > > Jun/ Jay/ Gwen/ Harsha/ Ismael, > &g

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 wrote: > Hi Grant, > > On Tue, Apr 19,

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

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, 2016 at 9:48 AM, Ashish Singh

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

ve more time to review and discuss > > >> KIP-48. > > >> > > >> Ismael > > >> > > >> On Tue, Mar 8, 2016 at 12:55 AM, Gwen Shapira > wrote: > > >> > > >> > Hi Team, > > >> > > > >>

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: > Sending it again on the existi

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 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 what I have in mind. >

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 large number of clients that

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 :) > > > > I want to be able to at least get some of them in

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

: > 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 wrote: > > > Hello

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

st 0.10.0. > > Thanks > > Jun > > On Fri, Apr 8, 2016 at 9:04 AM, Ashish Singh wrote: > > > Thanks for the input Don. One of the possible paths for Option 2 is to > > completely drop Scala interface, would that be Ok with you folks? > > > > On Thursday

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

using constructs like Group$.MODULE$, which is not > intuitive in Java. > > Thanks > > Bosco > > > > > On 4/7/16, 4:30 PM, "Ashish Singh" > > wrote: > > >Harsha/ Don, > > > >Are you guys OK with option 2? I am not aware of all th

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

e new method and this won’t break the compilation of > > any external implementation. Else over the time it will be challenging > for > > anyone customizing the implementation to keep track of changes to the > > Interface. > > > > Thanks > > > > Bosco

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

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

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 authori

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

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 wrote: >

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 package

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 version. Otherwise, i

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 the specific API suppo

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 wrote: > E

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 of connection closures, the KIP recomm

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 Cheslack-Postava" wrote: > > >

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 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 wrote: > >> Ashish, >

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

emove/change an existing method. Grant, could you comment on the latter? > > Thanks, > > Jun > > On Sat, Apr 2, 2016 at 11:43 AM, Ashish Singh wrote: > > > Hello Jun, > > > > > > On Fri, Apr 1, 2016 at 9:57 PM, Jun Rao wrote: > > > > >

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

plementations 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 > wrote: > > > Hi

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

al? > Override of getSupportedPrincipalTypes in SimpleAclAuthorizer will have to return group as well. > > Ismael > > On Mon, Mar 28, 2016 at 9:28 PM, Ashish Singh wrote: > > > Hello Harsha, > > > > Pinging again. This is a minor KIP and it has been lying around

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

in the KIP). I agree it could be hard, but no one promised that > implementing a server that is backward and forward compatible is easy. > Everyone who votes on this KIP must be aware that whatever we do here is > here to stay. > > Which is exactly why this discussion is so important

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

n (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 difficult in Java. > > > > >

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

s 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 would resolve some of the uneasiness about

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 would like to start the voting process for the "KIP-4 Metadata

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

ded 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 wrote: > > > We have proposed and discussed majorly three approaches so far, there > were > > many minor versions with small variations. Com

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

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

[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 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 config is what you > sug

Re: [VOTE] 0.10.0.0 RC1

If it is possible, I am also in favor of having some time to include a few more KIPs in 0.10. On Wed, Mar 30, 2016 at 10:26 AM, Jason Gustafson wrote: > I think it would be nice to get a resolution on KIP-35 before the release. > We were reluctant to push it through when the timeline was tight (

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 wrote: > Hi Harsha, > > On Wed, Mar 9, 2016 at

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, Grant Henke wrote:

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 det

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

hat 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? > >> >> > >> >> The point of merging version

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 mailing list and in the KIP call, but th

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 wrote: > Hey Guys, > > I woul

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

lcome to pitch in. Does it help? > -Jay > > On Mon, Mar 14, 2016 at 3:54 PM, Ashish Singh wrote: > > Hey Guys, > > > > I would like to start voting process for *KIP-35: Retrieving protocol > > version*. The KIP is available here > > < > https://cwi

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

PM, Ashish Singh 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 wrote: > > > Yeah I think there are two possible approaches: > > 1. You get the versions in the meta

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

;> 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 are proposing merging with the > >> metadata request but not summarizing a

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

ing 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 wrote: > > Mag

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

t;> the >> > > >> >>implementation so we know it works--implementing server >> support >> > > >> without >> > > >> >>actually trying it is kind of risky. >> > > >&

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

quest in different cases > > > >> >>- Instructions on how to use this to implement a client > > > >> >> > > > >> >> This document is versioned with the protocol number and is the > > > source of > > > >> >> truth fo

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

IP-35 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 wrote: > > > Hi Jason, > > > > On Mon, Mar 14, 2016 at 4:04 PM, Jason Gustafson &g

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

onable to you? > > -Jason > > On Mon, Mar 14, 2016 at 3:34 PM, Ashish Singh wrote: > > > 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 d

[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 wrote: > > > On Mon, Mar 14, 2016 at 3:37 P

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

On Mon, Mar 14, 2016 at 3:37 PM, Ismael Juma wrote: > On Mon, Mar 14, 2016 at 10:35 PM, Ashish Singh > wrote: > > > > Also, I think it's a bit odd to say a `single null topic with size -1`. > > Do > > > we mean an array of topics with size

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

On Mon, Mar 14, 2016 at 7:05 AM, Ismael Juma wrote: > Hi Ashish, > > A few comments below. > > On Fri, Mar 11, 2016 at 9:59 PM, Ashish Singh wrote: > > > Sounds like we are mostly in agreement. Following are the key points. > > > >1. Every time a proto

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 the connection. > If > > > the broker

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

On Mon, Mar 14, 2016 at 9:37 AM, Gwen Shapira wrote: > On Mon, Mar 14, 2016 at 7:05 AM, Ismael Juma wrote: > > Hi Ashish, > > > > A few comments below. > > > > On Fri, Mar 11, 2016 at 9:59 PM, Ashish Singh > wrote: > > > >> Sounds like we ar

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 version changes, for any request/response, > > >>broker

[DISCUSS] KIP-35 - Retrieve protocol version

might > be > > >> > outdated ( = cant be trusted) > > >> > b) by the time the client connects to a given broker it might have > > >> upgraded > > >> > > > >> > This means that a client (that is interested in protocol versioning)

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 wrote: > > > On Fri, Mar 4, 2016 at 5:46 PM, Jay Kreps wrote: > >> Hey Ashish, >> >> Both good points. &g

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

pose 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 > wrote: > > > > > Thanks Gwen. > > > > > > @Parth, @Harsha ping

Re: [Discuss] Remove producer configs deprecated in 0.9

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 wrote: > > Hey Guys, > > > > Following producer configs were deprecated in 0.9, it might

[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

, Mar 7, 2016 at 5:15 PM, Ashish Singh 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 that > is > > not true. Created KAFKA-3348 and KA

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. 0.9.1.x

  1   2   3   4   >