the wiki. I think that we
> > >> can decouple the problem of "token distribution" from "shared secret
> > >> distribution" and use the controller as the only token generator to
> > >> solve the second issue, while still using ZK async to distr
meeting invite. We can discuss this in the meeting
> > tomorrow.
> >
> > Thanks,
> >
> > Jun
> >
> > On Thu, May 19, 2016 at 8:47 AM, Harsha wrote:
> >
> >> Hi All,
> >>Can we have a KIP meeting around this. The KIP is u
gt; https://tools.ietf.org/html/rfc7677 describes the protocol for
> > > > SCRAM-SHA-256.
> > > >
> > > > On Tue, May 24, 2016 at 2:37 AM, Jun Rao wrote:
> > > >
> > > > > Parth,
> > > > >
> > > > &
PM, Harsha wrote:
> >> > Jun & Ismael,
> >> > Unfortunately I couldn't attend the KIP
> meeting
> >> > when delegation tokens discussed. Appreciate
> if
> >> >
>> 1. Who / how are tokens renewed? By original requester only? or
> using
> > > >> Kerberos auth only?
> > > >> 2. Are tokens stored on each broker or in ZK?
> > > >> 3. How are tokens invalidated / expired?
> > > >> 4. Which e
ation Uis like
(Ranger-Argus not sure what are they calling it now).
On Wed, Mar 25, 2015 at 9:26 PM, Neha Narkhede
mailto:n...@confluent.io>> wrote:
Parth,
We can make some 15 mins or so to discuss this at the next KIP hangout.
Thanks,
Neha
On Wed, Mar 25, 2015 at 1:07 PM, Parth Brahm
EATION
Diff: https://reviews.apache.org/r/32460/diff/
Testing (updated)
---
unit tests added.
Thanks,
Parth Brahmbhatt
n
encoding/decoding used by kafka is already failing for me when I try to parse a
map that has an already json encoded string as value for some key.
Jun
On Sun, Mar 29, 2015 at 3:56 PM, Parth Brahmbhatt <
pbrahmbh...@hortonworks.com<mailto:pbrahmbh...@hortonworks.com>> wrote:
Hi Gw
ementation can be reused.
>>>
>>>23. Authorizer:
>>>23.1 Do cluster level operations go through authorize() too? If so, what
>>>will be the resource?
>>>23.2 I assume that the authorize() check will be called on every
>>>request.
>>>So,
mmands and TopicConfigCache.
Thanks,
Parth Brahmbhatt
a round trip to a DNS server, which is
insecure
anyway).
On 3/25/15, 1:07 PM, "Parth Brahmbhatt"
mailto:pbrahmbh...@hortonworks.com>>
wrote:
Hi all,
I have modified the KIP to reflect the recent change request from the
reviewers. I have been working on the code and I have the
ere isn’t a way to map
>>that to a hostname without a round trip to a DNS server, which is
>>insecure
>>anyway).
>>
>>
>>On 3/25/15, 1:07 PM, "Parth Brahmbhatt"
>>wrote:
>>
>>>Hi all,
>>>
>>>I have modified the KIP to re
gt;is today?
>
>Thanks.
>
>Tong
>
>Sent from my iPhone
>
>> On Apr 15, 2015, at 1:51 PM, Parth Brahmbhatt
> wrote:
>>
>> Hi Michael,
>>
>> There is code in kafka codebase that reads and interprets the topic
>config JSON which has acls, owner and lo
proposed broker configs, their types and names
* The Authorizer interface and the Acl structure
* The command line options being added, their name and types
* The new structure of topic config which is being stored in zookeeper
Thanks
Parth
On 4/15/15, 12:53 PM, "Parth Brahmbhatt"
wr
m a little confused: why would Kafka need to interpret the JSON? IIRC
>KIP-11 even says that the TopicConfigData will just store the JSON. I’m
>not really making a design recommendation here, just trying to understand
>what you’re proposing.
>
>On 4/15/15, 11:20 AM, "Parth Brahmbha
I was following the storm model but I think this is a reasonable change. I
recommend changing the API names to addAcls, removeAcls and getAcls.
Couple of points to ensure we are on same page:
* With this approach the kafka command line will not provide a way to add/edit
acls during topic creatio
AM, "Gwen Shapira" wrote:
>On Fri, Apr 17, 2015 at 9:31 AM, Parth Brahmbhatt
> wrote:
>> I was following the storm model but I think this is a reasonable
>>change. I recommend changing the API names to addAcls, removeAcls and
>>getAcls.
>
>And they p
)
>
>Or maybe including the json parsing code in TopicCommand is not so bad?
>
>
>
>On Fri, Apr 17, 2015 at 10:30 AM, Parth Brahmbhatt
> wrote:
>> * Yes, Acl pretty much captures everything. Originally I had resource as
>> part of Acls, we can go back to that.
>>
ith
>Ranger(Argus), does Hive do authorization through a separate CLI?
>
>Thanks,
>
>Jun
>
>
>On Fri, Apr 17, 2015 at 11:01 AM, Parth Brahmbhatt <
>pbrahmbh...@hortonworks.com> wrote:
>
>> We could do this but I think its too simplistic plus now we are adding
I looked into the consumer offset storage and it seems like for acl
storage we should not need something as complex. Consumer offset has
different throughput requirements which is why I think it made sense to
move away from zookeeper. Acls on the other hand seldom change and because
of the caching
arth,
>>
>>Sorry to chime in so late, but I’ve got a minor question on the KIP.
>>
>>Several methods take a parameter named “host” of type String. Is that
>>intended to be a hostname, or an IP address? If the former, I’m curious
>>as
>>to how that’s found (i
and rule2 denies user2. Does user3 have access? If not, does removing
>rule1
>enable user3 access?
>
>Thanks,
>
>Jun
>
>On Mon, Apr 20, 2015 at 1:34 PM, Parth Brahmbhatt <
>pbrahmbh...@hortonworks.com> wrote:
>
>>
>> Hi Joel,
>>
>> Thanks for th
hanks
>> Parth
>>
>> On 4/20/15, 12:03 PM, "Jun Rao" wrote:
>>
>> >Just a followup question. Suppose there are two rules. Rule1 allows
>>user1
>> >and rule2 denies user2. Does user3 have access? If not, does removing
>> >rule1
>
The iptables on unix supports the DENY operator, not that it should
matter. The deny operator can also be used to specify ³allow user1 to READ
from topic1 from all hosts but host1,host2². Again we could add a host
group semantic and extra complexity around that, not sure if its worth it.
In additio
Perhaps we can clarify
>>>the
>>> meaning of those rules in the wiki.
>>>
>>> Related to this, it seems that we need to support wildcard in
>>>cli/request
>>> protocol for topics?
>>>
>>> Jun
>>>
>>> On Mon, A
ki.
>
>Related to this, it seems that we need to support wildcard in cli/request
>protocol for topics?
>
>Jun
>
>On Mon, Apr 20, 2015 at 9:07 PM, Parth Brahmbhatt <
>pbrahmbh...@hortonworks.com> wrote:
>
>> The iptables on unix supports the DENY operator, not th
-a malicious person
>>can
>> cause data loss or duplicates for another consumer by committing offset.
>>
>> I think I favor (2) but it's worth it to think it through.
>>
>> -Jay
>>
>> On Tue, Apr 21, 2015 at 2:43 PM, Parth Brahmbhatt <
&g
2c768e762f61f92448c6a6
Diff: https://reviews.apache.org/r/33431/diff/
Testing
---
Thanks,
Parth Brahmbhatt
) are there configs for cluster level acl defaults? Or does it default
>to superusers on bringing up new cluster and you have to modify with cli.
>thanks,Tom
No defaults, the default is superusers will have full access. I don’t
think making assumptions about ones security requirement should
mailto:tgraves...@yahoo.com>>
Reply-To: Tom Graves mailto:tgraves...@yahoo.com>>
Date: Wednesday, April 22, 2015 at 11:02 AM
To: Parth Brahmbhatt
mailto:pbrahmbh...@hortonworks.com>>,
"dev@kafka.apache.org<mailto:dev@kafka.apache.org>"
mailto:dev@kafka.apache.o
class API will just
scan all topic acls and apply filtering logic.
Thanks
Parth
On 4/22/15, 11:08 AM, "Parth Brahmbhatt"
wrote:
>Please see all the available options here
>https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+I
>nterface#KIP-11-Authorizati
You are right , I forgot to mention the ―operation option in CLI , I just
added it. Sorry for about the confusion.
Thanks
Parth
On 4/22/15, 11:22 AM, "Parth Brahmbhatt"
wrote:
>Sorry I missed your last questions. I am +0 on adding ―host option for
>―list, we could add it for sy
y standardize on group
>authorization anyway, are we complicating that issue with the inclusion of
>hosts attached to users? Additionally I worry about the debt of big JSON
>configs in the first place, most non-developers find them non-intuitive
>already, so anything to ease this I think
Hi,
I would like to open KIP-11 for voting.
Thanks
Parth
On 4/22/15, 1:56 PM, "Parth Brahmbhatt"
wrote:
>Hi Jeff,
>
>Thanks a lot for the review. I think you have a valid point about acls
>being duplicated and the simplest solution would be to modify acls class
;* Can you clearly separate which parts are the API (common to every
>Authorizer) and which parts are DefaultAuthorizer implementation? It
>will make reviews and Authorizer implementations a bit easier to know
>exactly which is which.
>
>Gwen
>
>On Fri, Apr 24, 2015 at 9:28 AM, Parth
gt;Am I wrong? Or is it the KIP?
>
>On Fri, Apr 24, 2015 at 9:49 AM, Parth Brahmbhatt
> wrote:
>> Thanks for clarifying Gwen, KIP updated.
>>
>> I tried to make the distinction by creating a section for all public
>>APIs
>>
>>https://cwiki.apache.org
quot;],
>> "principals":["alice","kafka-devs"
>>
>>
>>
>>
>>
>> 3) The advantage of all of this is that it now provides more flexibility
>> for custom modules for both authentication and authorization movin
of it getting created?
>
>Its all small details, but it will be difficult to implement KIP-11
>without knowing the answers :)
>
>Gwen
>
>
>On Fri, Apr 24, 2015 at 9:58 AM, Parth Brahmbhatt
> wrote:
>> You are right, moved it to the default implementation section.
talking about same Groups :)
>
>I meant, Groups of consumers (which KIP-11 lists as a separate
>resource in the Privilege table)
>
>On Fri, Apr 24, 2015 at 11:31 AM, Parth Brahmbhatt
> wrote:
>> I see Groups as something we can add incrementally in the current model.
>>
it also be at
>topic level? For example, perhaps it's useful to allow only user X to
>create topic X.
>
>Thanks,
>
>Jun
>
>
>On Sun, Apr 26, 2015 at 12:36 AM, Gwen Shapira
>wrote:
>
>> Thanks for clarifying, Parth. I think you are taking the right app
confused with user group.
>
>101. Currently, create is only at the cluster level. Should it also be at
>topic level? For example, perhaps it's useful to allow only user X to
>create topic X.
>
>Thanks,
>
>Jun
>
>
>On Sun, Apr 26, 2015 at 12:36 AM, Gwen Shap
lso, with the current api, what would the admin do to replicate the acls
>from one cluster to another? Will she just list all acls from cli and
>reissue them to another cluster periodically?
>
>Thanks,
>
>Jun
>
>On Mon, Apr 27, 2015 at 10:56 AM, Parth Brahmbhatt <
>pbrahmbh
>> > > >* Acl storage is indexed by resource right now because that is the
>> > > primary lookup id for all authorize operations. Given acls are
>>cached
>> > > I don't see the need to optimized the storage layer any further for
>> > lo
I also wanted to send ping to all he committers. This voting thread has
been open for > 1 week and has 2 non-bindng +1s. I would appreciate if the
committers raised their concerns or casted their votes.
Thanks
Parth
On 4/30/15, 9:52 AM, "Parth Brahmbhatt"
wrote:
>Hi Joe, Thank
it - Many systems intentionally don't return AuthorizationException
>>when
>> READ privilege is missing, since this already gives too much information
>> (that the topic exists and that you don't have privileges on it).
>>Instead
>> they return a variant of
have clis so should be fine.
* If you are concerned about json parsing , given authorizer is going to
cache acls on its end this should be relatively infrequent.
Let me know if you were pointing at something completely different.
Thanks
Parth
On 4/30/15, 12:15PM, "Parth Brahmbhatt"
w
n how "Mirror maker will have to start using new acl
>management tool") and it not affect any other client. If you aren't
>changing the wire protocol then how do clients use it?
>
>~ Joe stein
>
>
>On Thu, Apr 30, 2015 at 3:15 PM, Parth Brahmbhatt <
>pbrahmbh
+1.
Thanks
Parth
On 5/1/15, 12:38 AM, "Ewen Cheslack-Postava" wrote:
>Also +1. There are some drawbacks to using Github for reviews, e.g. lots
>of
>emails for each review because they don't let you publish your entire
>review in one go like RB does, but it drastically lowers the barrier to
>co
GitHub user Parth-Brahmbhatt opened a pull request:
https://github.com/apache/kafka/pull/61
KAFKA-2169: Moving to zkClient 0.5 release.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/Parth-Brahmbhatt/kafka KAFKA-2169
861b7f644941f88ce04a4e95f6b28d18bf1db16d
Diff: https://reviews.apache.org/r/34047/diff/
Testing
---
Thanks,
Parth Brahmbhatt
/KafkaHealthcheck.scala
861b7f644941f88ce04a4e95f6b28d18bf1db16d
Diff: https://reviews.apache.org/r/34050/diff/
Testing
---
Thanks,
Parth Brahmbhatt
/KafkaController.scala
a6351163f5b6f080d6fa50bcc3533d445fcbc067
core/src/main/scala/kafka/server/KafkaHealthcheck.scala
861b7f644941f88ce04a4e95f6b28d18bf1db16d
Diff: https://reviews.apache.org/r/34050/diff/
Testing
---
Thanks,
Parth Brahmbhatt
ent134200>
Why would we want to do this? If the listeners are invoked twice as long as
both of them exit whichever one gets invoked first will just kill the process
and the other one will not be invoked. Why would we care which System.exit
kills the process?
- Parth Brahmbhatt
On May 11, 20
tps://reviews.apache.org/r/34050/#comment134408>
I don't understand why this needs to be done which is why I haven't
addressed it. Can you elloborate why would it matter which one of the 2 calls
exits the process?
- Parth Brahmbhatt
On May 11, 2015, 8:53 p.m., Parth
Hi,
Opening the voting thread for KIP-11.
Link to the KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+Interface
Link to Jira: https://issues.apache.org/jira/browse/KAFKA-1688
Thanks
Parth
38f4ec0bd1b388cc8fc04b38bbb2e7aaa1c3f43b
core/src/main/scala/kafka/controller/KafkaController.scala
a6351163f5b6f080d6fa50bcc3533d445fcbc067
core/src/main/scala/kafka/server/KafkaHealthcheck.scala
861b7f644941f88ce04a4e95f6b28d18bf1db16d
Diff: https://reviews.apache.org/r/34050/diff/
Testing
---
Thanks,
Parth
/server/KafkaConfigConfigDefTest.scala
8014a5a6c362785539f24eb03d77278434614fe6
Diff: https://reviews.apache.org/r/34492/diff/
Testing
---
Thanks,
Parth Brahmbhatt
/src/test/scala/unit/kafka/security/auth/SimpleAclAuthorizerTest.scala
PRE-CREATION
Diff: https://reviews.apache.org/r/34493/diff/
Testing
---
Thanks,
Parth Brahmbhatt
://reviews.apache.org/r/34494/diff/
Testing
---
Thanks,
Parth Brahmbhatt
This vote is now Closed with 4 binding +1s and 4 non binding +1s.
Thanks
Parth
On 5/20/15, 12:04 PM, "Joel Koshy" wrote:
>+1
>
>On Fri, May 15, 2015 at 04:18:49PM +0000, Parth Brahmbhatt wrote:
>> Hi,
>>
>> Opening the voting thread for KI
e status of the KIP in the
>wiki?
>
>Thanks,
>
>Jun
>
>On Wed, May 20, 2015 at 2:37 PM, Parth Brahmbhatt <
>pbrahmbh...@hortonworks.com> wrote:
>
>> This vote is now Closed with 4 binding +1s and 4 non binding +1s.
>>
>> Thanks
>> Parth
>&g
Hi,
Can someone please review the following CRs:
Public entities and interfaces with changes to KafkaAPI and KafkaServer:
https://reviews.apache.org/r/34492/diff/
Actual Implementation: https://reviews.apache.org/r/34493/diff/
CLI: https://reviews.apache.org/r/34494/diff/
Thanks
Parth
/ResourceTest.scala PRE-CREATION
core/src/test/scala/unit/kafka/server/KafkaConfigConfigDefTest.scala
8014a5a6c362785539f24eb03d77278434614fe6
Diff: https://reviews.apache.org/r/34492/diff/
Testing
---
Thanks,
Parth Brahmbhatt
PRE-CREATION
core/src/test/scala/unit/kafka/server/KafkaConfigConfigDefTest.scala
71f48c07723e334e6489efab500a43fa93a52d0c
Diff: https://reviews.apache.org/r/34492/diff/
Testing
---
Thanks,
Parth Brahmbhatt
kafka/security/auth/ResourceTest.scala
<https://reviews.apache.org/r/34492/#comment138523>
Same rationale as mentioned few times before for case senstivity.
- Parth Brahmbhatt
On June 3, 2015, 11:36 p.m., Parth Brahmbhatt wrote:
>
>
,
Parth Brahmbhatt
KAFKA-1805
Handling the case where al the fields in ProducerRecord can be null.
Diffs (updated)
-
clients/src/main/java/org/apache/kafka/clients/producer/ProducerRecord.java
065d4e6c6a4966ac216e98696782e2714044df29
Diff: https://reviews.apache.org/r/29468/diff/
Testing
---
Than
Testing
---
Thanks,
Parth Brahmbhatt
Testing
---
Thanks,
Parth Brahmbhatt
Testing
---
Thanks,
Parth Brahmbhatt
lients/src/test/java/org/apache/kafka/clients/producer/ProducerRecordTest.java
PRE-CREATION
Diff: https://reviews.apache.org/r/29468/diff/
Testing
---
Thanks,
Parth Brahmbhatt
view72032
---
On Feb. 11, 2015, 10:49 p.m., Parth Brahmbhatt wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://revie
a/org/apache/kafka/clients/producer/ProducerRecord.java
<https://reviews.apache.org/r/29468/#comment117967>
nulls are handled now.
- Parth Brahmbhatt
On Feb. 11, 2015, 10:53 p.m., Parth Brahmbhatt wrote:
>
> ---
> This is
org/apache/kafka/clients/producer/ProducerRecordTest.java
PRE-CREATION
Diff: https://reviews.apache.org/r/29468/diff/
Testing (updated)
---
Unit tests added.
Thanks,
Parth Brahmbhatt
s/producer/Producer.java
17fe541588d462c68c33f6209717cc4015e9b62f
clients/src/main/java/org/apache/kafka/clients/producer/internals/Sender.java
ed9c63a6679e3aaf83d19fde19268553a4c107c2
Diff: https://reviews.apache.org/r/29467/diff/
Testing
---
existing unit tests passed.
Thanks,
Parth Brahmbhatt
ducer.java
17fe541588d462c68c33f6209717cc4015e9b62f
clients/src/main/java/org/apache/kafka/clients/producer/internals/Sender.java
ed9c63a6679e3aaf83d19fde19268553a4c107c2
Diff: https://reviews.apache.org/r/29467/diff/
Testing
---
existing unit tests passed.
Thanks,
Parth Brahmbhatt
//reviews.apache.org/r/29467/diff/
Testing
---
existing unit tests passed.
Thanks,
Parth Brahmbhatt
afka/clients/producer/KafkaProducer.java
<https://reviews.apache.org/r/29467/#comment121525>
changed log level to suggested value.
- Parth Brahmbhatt
On March 2, 2015, 6:41 p.m., Parth Brahmbhatt wrote:
>
> ---
> This is an aut
rote:
> > clients/src/main/java/org/apache/kafka/clients/producer/KafkaProducer.java,
> > line 554
> > <https://reviews.apache.org/r/29467/diff/4/?file=882247#file882247line554>
> >
> > It's probably worth adding an
> > if(timeout > 0)
--
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29467/#review74897
-------
On March 2, 2015, 6:41 p.m., Parth Brahmbhatt wrote:
>
> --
Hi,
KIP-11 is open for discussion , I have updated the wiki with the design and
open questions.
Thanks
Parth
Forgot to add links to wiki and jira.
Link to wiki:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+Interface
Link to Jira: https://issues.apache.org/jira/browse/KAFKA-1688
Thanks
Parth
From: Parth Brahmbhatt
mailto:pbrahmbh...@hortonworks.com>>
Date: Thursday,
>Hi Parth,
>>Thanks for putting this together. Overall it looks good to
>>me. Although AdminUtils is a concern KIP-4 can probably fix
>>that part.
>>Thanks,
>>Harsha
>>
>>On Thu, Mar 5, 2015, at 10:39 AM, Parth Brahmbhatt w
for? And plan it as a future feature
>>request?
>>
>>Thanks
>>
>>Bosco
>>
>>
>>
>>On 3/6/15, 8:10 AM, "Harsha" wrote:
>>
>>>Hi Parth,
>>>Thanks for putting this together. Overall it looks good to
>>
/diff/
Testing
---
Thanks,
Parth Brahmbhatt
42c72198a0325e234cf1d428b687663099de884e
core/src/main/scala/kafka/consumer/ConsumerConfig.scala
9ebbee6c16dc83767297c729d2d74ebbd063a993
Diff: https://reviews.apache.org/r/32251/diff/
Testing
---
Thanks,
Parth Brahmbhatt
42c72198a0325e234cf1d428b687663099de884e
core/src/main/scala/kafka/consumer/ConsumerConfig.scala
9ebbee6c16dc83767297c729d2d74ebbd063a993
Diff: https://reviews.apache.org/r/32251/diff/
Testing
---
Thanks,
Parth Brahmbhatt
42c72198a0325e234cf1d428b687663099de884e
core/src/main/scala/kafka/consumer/ConsumerConfig.scala
9ebbee6c16dc83767297c729d2d74ebbd063a993
Diff: https://reviews.apache.org/r/32251/diff/
Testing
---
Thanks,
Parth Brahmbhatt
-------
On March 19, 2015, 7:19 p.m., Parth Brahmbhatt wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32251/
>
42c72198a0325e234cf1d428b687663099de884e
core/src/main/scala/kafka/consumer/ConsumerConfig.scala
9ebbee6c16dc83767297c729d2d74ebbd063a993
Diff: https://reviews.apache.org/r/32251/diff/
Testing
---
Thanks,
Parth Brahmbhatt
I can confirm that KAFKA-1688 will cover this use case. Please go over
https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+In
terface and let me know if you think there is a different use case being
covered by KIP-7.
Thanks
Parth
On 3/20/15, 9:26 AM, "Jun Rao" wrote:
>Yes,
I am not entirely sure what you mean by integrating KIP-7 work with
KAFKA-1688. Wouldn¹t the work done as part of KIP-7 become obsolete once
KAFKA-1688 is done? Multiple ways of controlling these authorization just
seems extra configuration that will confuse admins/users.
If timing is the only is
just need to wait
>until
>KIP-7 is done? If we add the small change now, we will have to worry about
>migrating existing users and deprecating some configs when KIP-7 is done.
>
>Thanks,
>
>Jun
>
>On Fri, Mar 20, 2015 at 10:36 AM, Parth Brahmbhatt <
>pbrahmbh...@
://reviews.apache.org/r/32460/diff/
Testing
---
Thanks,
Parth Brahmbhatt
>>the server side, can we de-scope it for? And plan it as a future feature
>>request?
>>
>>Thanks
>>
>>Bosco
>>
>>
>>
>>On 3/6/15, 8:10 AM, "Harsha" wrote:
>>
>>>Hi Parth,
>>>Thanks for puttin
+1
Thanks
Parth
On Wed, Mar 30, 2016 at 8:22 PM, Ewen Cheslack-Postava
wrote:
> +1
>
> -Ewen
>
> On Wed, Mar 30, 2016 at 7:20 PM, Gwen Shapira wrote:
>
> > So my +1 is back :)
> >
> > On Wed, Mar 30, 2016 at 4:51 PM, Ashish Singh
> wrote:
> >
> > > My bad, I moved the config option to rejecte
gt; >3. In catastrophic failures where all brokers go down, the
> > tokens will
> > > >> > >be lost even if servers are restarted as tokens are not
> > persisted
> > > >> > anywhere.
> > > >> > >If this happens, then the
, Apr 19, 2016, at 09:57 AM, parth brahmbhatt wrote:
> > Thanks for review Jitendra.
> >
> > I don't like the idea of infinite lifetime but I see the Streaming use
> > case. Even for Streaming use case I was hoping there will be some notion
> > of
> > maste
it Storm
> >> job as my user), we will need a producer for every job (we can't share
> >> them between multiple jobs running on same node), since we only
> >> authenticate when connecting. Is there a plan to change this for
> >> delegation tokens, in order to allow m
Acls will be written in zookeeper but you are using getAcl , what you need
is get /kafka-acl/Topic/permissiontopic
Thanks
Parth
On Thu, May 5, 2016 at 3:28 PM, BigData dev wrote:
> Hi,
> When I run the command
> /bin/kafka-acls.sh --topic permissiontopic --add --allow-host {host}
> --allow-p
1 - 100 of 407 matches
Mail list logo
