Hi, sorry I am coming in late to chime back in on this thread and haven't
been able to make the KIP hangouts the last few weeks. Sorry if any of this
was brought up already or I missed it.
I read through the KIP and the thread(s) and a couple of things jumped out.
- Can we break out the open
[
https://issues.apache.org/jira/browse/KAFKA-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiasheng Wang updated KAFKA-2158:
-
Status: Patch Available (was: Open)
Close all fetchers in AbstractFetcherManager without
[
https://issues.apache.org/jira/browse/KAFKA-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiasheng Wang updated KAFKA-2158:
-
Status: Open (was: Patch Available)
Close all fetchers in AbstractFetcherManager without
Jiasheng Wang created KAFKA-2158:
Summary: Close all fetchers in AbstractFetcherManager without
blocking
Key: KAFKA-2158
URL: https://issues.apache.org/jira/browse/KAFKA-2158
Project: Kafka
[
https://issues.apache.org/jira/browse/KAFKA-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiasheng Wang updated KAFKA-2158:
-
Affects Version/s: 0.8.2.0
Status: Patch Available (was: Open)
Close all
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33719/
---
Review request for kafka.
Bugs: KAFKA-2158
[
https://issues.apache.org/jira/browse/KAFKA-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiasheng Wang updated KAFKA-2158:
-
Attachment: KAFKA-2158.patch
Close all fetchers in AbstractFetcherManager without blocking
Hi all,
Kafka currently uses a combination of Review Board and JIRA for
contributions and code review. In my opinion, this makes contribution and
code review a bit harder than it has to be.
I think the approach used by Spark would improve the current situation:
Generally, Spark uses JIRA to
- created KAFKA-2159:
Summary: offsets.topic.segment.bytes and
offsets.topic.retention.minutes are ignored
Key: KAFKA-2159
URL: https://issues.apache.org/jira/browse/KAFKA-2159
Project: Kafka
Issue
Joe,
Could you elaborate on why we should not store JSON in ZK? So far, all
existing ZK data are in JSON.
Thanks,
Jun
On Thu, Apr 30, 2015 at 2:06 AM, Joe Stein joe.st...@stealth.ly wrote:
Hi, sorry I am coming in late to chime back in on this thread and haven't
been able to make the KIP
The following is a description of some of my concerns on allowing the same
topic multiple times in AlterTopicRequest.
ATP has an array of entries, each corresponding to a topic. We allow
multiple changes to a topic in a single entry. Those changes may fail to
apply independently (e.g., the config
[
https://issues.apache.org/jira/browse/KAFKA-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521229#comment-14521229
]
Andras Sereny commented on KAFKA-2156:
--
What is KM?
Possibility to plug in custom
[
https://issues.apache.org/jira/browse/KAFKA-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521518#comment-14521518
]
Rafał Boniecki commented on KAFKA-2159:
---
Possible reasons:
[
https://issues.apache.org/jira/browse/KAFKA-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521596#comment-14521596
]
John Humphreys commented on KAFKA-824:
--
Has any progress been made on this, or do any
Guozhang Wang created KAFKA-2160:
Summary: DelayedOperationPurgatory should remove the pair in
watchersForKey with empty watchers list
Key: KAFKA-2160
URL: https://issues.apache.org/jira/browse/KAFKA-2160
[
https://issues.apache.org/jira/browse/KAFKA-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ewen Cheslack-Postava updated KAFKA-2123:
-
Status: Patch Available (was: In Progress)
Make new consumer offset commit API
[
https://issues.apache.org/jira/browse/KAFKA-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ewen Cheslack-Postava updated KAFKA-2123:
-
Attachment: KAFKA-2123_2015-04-30_11:23:05.patch
Make new consumer offset commit
[
https://issues.apache.org/jira/browse/KAFKA-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521992#comment-14521992
]
Ewen Cheslack-Postava commented on KAFKA-2123:
--
Updated reviewboard
[
https://issues.apache.org/jira/browse/KAFKA-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522016#comment-14522016
]
Ewen Cheslack-Postava commented on KAFKA-2123:
--
This version is now ready for
* Regarding additional authorizers:
Prasad, who is a PMC on Apache Sentry reviewed the design and confirmed
Sentry can integrate with the current APIs. Dapeng Sun, a committer on
Sentry had some concerns about the IP privileges and how we prioritize
privileges - but nothing that prevents Sentry
Gwen regarding additional authorizers
I think having these in the system tests duals as both good confidence in
language independency of the changes. It also makes sure that when we
release that we don't go breaking Sentry or Ranger or anyone else that
wants to integrate.
Gwen Regarding
[
https://issues.apache.org/jira/browse/KAFKA-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ewen Cheslack-Postava updated KAFKA-2161:
-
Status: Patch Available (was: Open)
Fix a few copyrights
[
https://issues.apache.org/jira/browse/KAFKA-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ewen Cheslack-Postava updated KAFKA-2161:
-
Attachment: KAFKA-2161.patch
Fix a few copyrights
Ewen Cheslack-Postava created KAFKA-2161:
Summary: Fix a few copyrights
Key: KAFKA-2161
URL: https://issues.apache.org/jira/browse/KAFKA-2161
Project: Kafka
Issue Type: Bug
Jun Could you elaborate on why we should not store JSON in ZK? So far,
all existing ZK data are in JSON.
If I have 1,000,000 users in LDAP and 150 get access to Kafka topics
through this mechanism then I have to go and parse and push all of my
changes into zookeeper for it to take affect?
GitHub user pedersen opened a pull request:
https://github.com/apache/kafka/pull/59
Adding ability to provide a prefix for the destination topic name. This ...
...can be used to allow two clusters to mirror to each other without
causing a loop.
You can merge this pull request into
[
https://issues.apache.org/jira/browse/KAFKA-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish K Singh updated KAFKA-2132:
--
Attachment: KAFKA-2132_2015-04-30_12:22:02.patch
Move Log4J appender to clients module
[
https://issues.apache.org/jira/browse/KAFKA-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522273#comment-14522273
]
Aditya Auradkar commented on KAFKA-2161:
+1 on using Rat. It doesn't seem to have
[
https://issues.apache.org/jira/browse/KAFKA-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guozhang Wang updated KAFKA-2160:
-
Status: Patch Available (was: Open)
DelayedOperationPurgatory should remove the pair in
[
https://issues.apache.org/jira/browse/KAFKA-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522033#comment-14522033
]
Ewen Cheslack-Postava commented on KAFKA-2161:
--
Created reviewboard
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33729/
---
Review request for kafka.
Bugs: KAFKA-2161
[
https://issues.apache.org/jira/browse/KAFKA-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522757#comment-14522757
]
Dong Lin commented on KAFKA-2084:
-
Here is my 2 cents. I vote for your 2nd approach:
I think this will help a lot in contributions. Some of my local changes
that I want to contribute back have been pending because I sometimes
switch machines and I then have to go through setting up the Ruby/python
and other stuff for the current review process. Using just github is
going to
Ok, I read through it all again a few times. I get the provider broker
piece now.
The configurations are still confusing if there are 2 or 3 and they should
be called out more specifically than as a change to a class. Configs are a
public interface we should be a bit more explicit.
Was there any
If you have bucket A and Bucket B and in Bucket A there are patients with
Disease X and Bucket B patients without Disease X.
Now you try to access Alice from bucket A and you get a 403 and then
from Bucket B you get a 404.
What does that tell you now about Alice? Yup, she has Disease X.
[
https://issues.apache.org/jira/browse/KAFKA-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwen Shapira updated KAFKA-1928:
Attachment: KAFKA-1928_2015-04-30_17:48:33.patch
Move kafka.network over to using the network
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33065/
---
(Updated May 1, 2015, 12:48 a.m.)
Review request for kafka.
Bugs: KAFKA-1928
Joe, these are good use cases, however in the firt phase the granularity
is at the Topic (your e.g. bucket) level and not what you are accessing
within the Topic. So in your use case, if you don’t have access to “Bucket
A”, then you won’t know who is in it, so you won’t know “Alice” or anyone
who
Thanks a bunch for taking this up, Ismael!
+1, I think it will be much more convenient to sunset RB and move to
github. Especially looking forward to the CIs on PRs and also the merge
script.
Alas, my wonderful patch-review script will be retired :-)
On Thu, Apr 30, 2015 at 6:12 AM, Ismael Juma
Just went through this thread. I'm on-board with this as well.
@Gwen - yes at LinkedIn we do need to support both
authenticated/unauthenticated users on the same Kafka cluster because
we cannot switch all clients simultaneously. I would be surprised if
this is unique to LinkedIn. Also, I think
Gwen,
Thanks for the clarification.
My objection is, we should not do it just because of the reason that
databases have always done it this way. May be there is a history
there that might have forced a choice like that. That has led to
other DBs to comply with it. Kafka is a different system.
Sriharsha Chintalapani created KAFKA-2162:
-
Summary: Kafka Auditing functionality
Key: KAFKA-2162
URL: https://issues.apache.org/jira/browse/KAFKA-2162
Project: Kafka
Issue Type: Bug
I think Kafka's behavior should be driven by what users want. My only
indication to what they may want is what we were forced to fix in similar
cases. This is why I am advocating this behavior.
I agree that this is a minor point that should not be blocking the vote. I
already gave my non-binding
Gwen regarding additional authorizers
I think having these in the system tests duals as both good confidence in
language independency of the changes. It also makes sure that when we
release that we don't go breaking Sentry or Ranger or anyone else that
wants to integate.
As much I would like
Comment on AuthorizationException. I think the intent of exception should be to
capture why a request is rejected. It is important from API perspective to be
specific to aid debugging. Having a generic or obfuscated exception is not very
useful. Does someone on getting an exception reach out to
That makes sense. Then, would it be better to have a KafkaClosable
interface that doesn't throw exception? This way, we don't need to override
close in every implementing class.
Thanks,
Jun
On Wed, Apr 29, 2015 at 10:36 AM, Steven Wu stevenz...@gmail.com wrote:
Jun,
we still get the benefit
Joe, thanks for the clarification.
Regarding audits, sorry I might be misunderstanding your email. Currently, if
Kafka does not support audits, I think audits should be considered as a
separate effort. Here are the reasons:
- Audit, whether authorization is available or not, should record
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33614/
---
(Updated April 30, 2015, 10:53 p.m.)
Review request for kafka.
Bugs:
Ah, I'm not talking about security by obscurity.
At least in the database world, if you don't have SELECT on a table, you
won't even see it when saying show tables because the very fact that the
table exists is privileged. In that case, a denied SELECT attempt will
return table does not exist,
[
https://issues.apache.org/jira/browse/KAFKA-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522427#comment-14522427
]
Ashish K Singh commented on KAFKA-2132:
---
Updated reviewboard
I kind of thought of the authorization module as something that happens in
handle(request: RequestChannel.Reuqest) in the request.requestId match
If the request doesn't do what it is allowed too it should stop right
there. That what it is allowed to-do is a true/false callback to the
class loaded
[
https://issues.apache.org/jira/browse/KAFKA-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522384#comment-14522384
]
Guozhang Wang commented on KAFKA-2160:
--
Updated reviewboard
On April 30, 2015, 10:45 p.m., Onur Karaman wrote:
core/src/main/scala/kafka/server/DelayedOperation.scala, line 224
https://reviews.apache.org/r/33731/diff/2/?file=946502#file946502line224
We can put the key inside Watchers and just use the watchersForKey
that's already in the
Hey Jun,
I think the Closable interface is what we've used elsewhere and what the
rest of the java world uses. I don't think it is too hard for us to add the
override in our interface--implementors of the interface don't need to do
it.
-Jay
On Thu, Apr 30, 2015 at 4:02 PM, Jun Rao
1. I have deep concerns about managing configuration in ZooKeeper.
First, Producers and Consumers shouldn't depend on ZK at all, this seems
to add back a dependency we are trying to get away from.
The KIP probably needs to be clarified here - I don't think Aditya was
referring to
On Thu, Apr 30, 2015 at 4:39 PM, Parth Brahmbhatt
pbrahmbh...@hortonworks.com wrote:
Hi Joe,
Let me clarify on authZException. The caller gets a 403 regardless of
existence of the topic, even if the topic does not exist you always get
403. This will fall under the case wherewe do not find
[
https://issues.apache.org/jira/browse/KAFKA-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521670#comment-14521670
]
Evan Huus commented on KAFKA-2147:
--
When I enable TRACE request logging on a single node
[
https://issues.apache.org/jira/browse/KAFKA-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521655#comment-14521655
]
Lior Gonnen commented on KAFKA-2152:
Thanks Gwen. This was very helpful.
Console
[
https://issues.apache.org/jira/browse/KAFKA-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521670#comment-14521670
]
Evan Huus edited comment on KAFKA-2147 at 4/30/15 4:13 PM:
---
When
59 matches
Mail list logo
