Re: [VOTE] 2.0.1 RC0

+1 -Ewen On Thu, Nov 1, 2018 at 10:10 AM Manikumar wrote: > We were waiting for the system test results. There were few failures: > KAFKA-7579, KAFKA-7559, KAFKA-7561 > they are not blockers for 2.0.1 release. We need more votes from > PMC/committers :) > > Thanks Stanislav! for the system tes

Re: [DISCUSS] KIP-158: Kafka Connect should allow source connectors to set topic-specific settings for new topics

re: AdminClient vs this proposal, one consideration is that AdminClient exposes a lot more surface area and probably a bunch of stuff we actually don't want Connectors to be able to do, such as deleting topics. You can always lock down by ACLs, but what the framework enables directly vs requiring t

Re: [DISCUSS] KIP-411: Add option to make Kafka Connect task client ID values unique

Hi Paul, Thanks for the KIP. A few comments. To me, biggest question here is if we can fix this behavior without adding a config. In particular, today, we don't even set the client.id for the producer and consumer at all, right? The *only* way it is set is if you include an override in the worker

Re: [DISCUSS] KIP-382: MirrorMaker 2.0

Hey Ryanne, Sorry, late to the game here. On the ACL management, can you explain how things are supposed to work when you need to migrate to the new cluster? Or is this purely for a mirroring but not DR and failover cases? In particular, the rules outlined state that only MM2 would be able to wri

Re: [DISCUSS] KIP-285: Connect Rest Extension Plugin

Hey, Sorry for the late follow up. I just had a couple of minor questions about details: * Some of the public API being added is under a runtime package. But that would be new for public API -- currently only things under the runtime package use that package name. I think changing the package nam

Re: [DISCUSS] KIP-305: Add Connect primitive number converters

Just a couple of minor points that don't really affect the implementation: * For nulls, let's just mention the underlying serializers already support this. I'm actually not sure why they should/need to, but given they do, let's just defer to that implementation. * I'm not sure where Float and Doub

Re: [VOTE] KIP-297: Externalizing Secrets for Connect Configurations

Thanks for addressing this Robert, it's a pretty common user need. First, +1 (binding) generally. Two very minor comments that I think could be clarified but wouldn't affect votes: * Let's list in the KIP what package the ConfigProvider, ConfigChangeCallback, ConfigData and ConfigTransformer int

Re: [DISCUSS] KIP-285: Connect Rest Extension Plugin

Yup, thanks for the changes. The 'health' package in particular feels like a nice fit given the way we expect it to be used. -Ewen On Wed, May 16, 2018 at 7:02 PM Randall Hauch wrote: > Looks good to me. Thanks for quickly making the changes! Great work! > > Best regards, > > Randall > > > On M

Re: [VOTE] KIP-285: Connect Rest Extension Plugin

+1 (binding) Thanks, Ewen On Thu, May 17, 2018 at 12:16 PM Ted Yu wrote: > +1 > Original message From: Gwen Shapira > Date: 5/17/18 12:02 PM (GMT-08:00) To: dev > Subject: Re: [VOTE] KIP-285: Connect Rest Extension Plugin > LGTM. +1. > > On Wed, May 16, 2018 at 8:19 PM, Mag

Re: [DISCUSS] KIP-298: Error Handling in Connect

A few more thoughts -- might not change things enough to affect a vote, but still some things to consider: * errors.retry.delay.max.ms -- this defines the max, but I'm not seeing where we define the actual behavior. Is this intentional, or should we just say that it is something like exponential,

Re: [DISCUSS] KIP-305: Add Connect primitive number converters

, so > I've kept all 5 converters in the KIP. > > Interestingly, perhaps the short and int converters (with the reduced > ranges) are not necessarily that useful for keys either. > > Regards, > > Randall > > On Thu, May 17, 2018 at 10:08 PM, Ewen Cheslack-Postava

Re: [DISCUSS] KIP-298: Error Handling in Connect

Arjun, Understood on retries vs tolerance -- though I suspect this will end up being a bit confusing to users as well. It's two levels of error handling which is what tripped me up. One last comment on KIP (which otherwise looks good): for the tolerance setting, do we want it to be an absolute va

Re: [VOTE] KIP-298: Error Handling in Connect kafka

+1 binding. I had one last comment in the DISCUSS thread, but not really a blocker. -Ewen On Mon, May 21, 2018 at 9:48 AM Matthias J. Sax wrote: > +1 (binding) > > > > On 5/21/18 9:30 AM, Randall Hauch wrote: > > Thanks, Arjun. +1 (non-binding) > > > > Regards, > > Randall > > > > On Mon, May 2

Re: [DISCUSS] KIP-298: Error Handling in Connect

h to just be an enum. Not sure if anyone has use cases for larger positive values. -Ewen > > Best, > > > On Mon, May 21, 2018 at 11:28 AM, Ewen Cheslack-Postava > > wrote: > > > Arjun, > > > > Understood on retries vs tolerance -- though I suspect this wil

Re: [DISCUSS] KIP-304: Connect runtime mode improvements for container platforms

Hey all, I think think this is a great discussion, and is helping to clarify the real pain points as well as explore a few more options than just what was initially proposed. Stephane, I think why you're ending up in "grand redesign" state is because you're highlighting (and the KIP's motivation

Re: [DISCUSS] KIP-305: Add Connect primitive number converters

On Sat, May 19, 2018 at 6:20 AM Randall Hauch wrote: > Considering this KIP is straightforward, what do you think about kicking > off a vote? Or does it need more discussion time? > > Regards, > Randall > > > On May 18, 2018, at 4:30 PM, Ewen Cheslack-Postava > wrote: &

Re: [VOTE] KIP-305: Add Connect primitive number converters

+1 (binding) -Ewen On Tue, May 22, 2018 at 9:29 AM Ted Yu wrote: > +1 > > On Tue, May 22, 2018 at 9:19 AM, Randall Hauch wrote: > > > I'd like to start a vote of a very straightforward proposal for Connect > to > > add converters for the basic primitive number types: integer, short, > long, >

Re: [EXTERNAL] Kafka Connect: New Kafka Source Connector

Sorry for the delay, didn't see this until now. I've given you edit permissions on the wiki. -Ewen On Tue, May 15, 2018 at 2:21 PM McCaig, Rhys wrote: > Hi Team, > > Would someone be able to provide me with Confluence permission in order to > write a KIP for the below code. > > User: https://cw

Re: [VOTE] KIP-176: Remove deprecated new-consumer option for tools

+1 (binding) Just follow up on the existing version of the KIP, so nothing new here. Possibly a bit disruptive given how quick the 1.0 -> 2.0 jump happened, but it's the right time to remove it. -Ewen On Thu, May 24, 2018 at 8:13 AM Viktor Somogyi wrote: > +1 (non-binding) > > I like this KIP.

Re: [Vote] KIP-321: Update TopologyDescription to better represent Source and Sink Nodes

Generally +1 (binding) It would be helpful to just provide the full, updated interfaces in the KIP and mark things as new with comments if needed. I had to go back and read the discussion thread to make sure I was understanding the intent correctly. Damian -- if we make that Optional, shouldn't t

Re: [VOTE] KIP-243: Make ProducerConfig and ConsumerConfig constructors public

+1 (binding), though I still think the Map should be instead of . I also think its better to just expose the defaults as constants on the class. Apparently there was discussion of this before and the concern is that people write code that rely on the default configs and we might break their code

Re: [DISCUSS] KIP-208: Add SSL support to Kafka Connect REST interface

On Mon, Jan 8, 2018 at 11:39 AM, Randall Hauch wrote: > Nice feedback, Ewen. Thanks! > > On Thu, Jan 4, 2018 at 5:11 PM, Ewen Cheslack-Postava > wrote: > > > Hey Jakub, > > > > Sorry for not getting to this sooner. Overall the proposal looks good to > &g

Re: [VOTE] KIP-174 Deprecate and remove internal converter configs in WorkerConfig

+1 binding. Thanks for the KIP! -Ewen On Mon, Jan 8, 2018 at 8:34 AM, Ted Yu wrote: > +1 > > On Mon, Jan 8, 2018 at 4:27 AM, UMESH CHAUDHARY > wrote: > > > Hello All, > > Since there are no outstanding comments on this, so I'd like to start a > > vote. > > > > Please find the KIP here > >

Re: [DISCUSS] KIP-212: Enforce set of legal characters for connector names

think it would be good to add them here or in a subsequent KIP! -Ewen On Tue, Jan 9, 2018 at 1:30 PM, Colin McCabe wrote: > On Sat, Jan 6, 2018, at 16:00, Ewen Cheslack-Postava wrote: > > re: whitespace characters, I'm fine with the restriction since I don't > see > >

[DISCUSS] Release Plan for 1.0.1

Hi all, I'd like to start the process for doing a 1.0.1 bug fix release. 1.0.0 was released Nov 1, 2017, and about 2.5 mos have passed and 32 bug fixes have accumulated so far. A few of the more notable fixes that we've merged so far: https://issues.apache.org/jira/browse/KAFKA-6269 - KTable rest

Re: [DISCUSS] KIP-208: Add SSL support to Kafka Connect REST interface

rward to this feature. -Ewen > Thanks & regards > Jakub > > On Wed, Jan 10, 2018 at 10:39 AM, Jakub Scholz wrote: > > > I'm sorry guys, I'm a bit busy with something else this week. But I will > > get back to his till the end of the week. > > >

Re: [DISCUSS] KIP-212: Enforce set of legal characters for connector names

think there is a case to > > be made for disallowing all control characters (and their respective > > escape sequences where applicable) in connector names - perhaps with > > the possible exclusion of /n /r /t . > > +1 > > Colin > > > > > Thoughts? > > >

Re: [DISCUSS] KIP-242: Mask password fields in Kafka Connect REST response

there is no ConfDef that defines which fields are Passwords we can just > return the config as is. > > There is a PR for this KIP already. Comments/Discussions are welcome. > https://github.com/apache/kafka/pull/4269 > > On Tue, Jan 2, 2018 at 8:52 PM, Ewen Cheslack-Postava >

Re: [VOTE] KIP-145: Expose Record Headers in Kafka Connect

+1 (binding) Thanks for the work on this -- not a small upgrade to the Connect APIs! -Ewen On Fri, Jan 19, 2018 at 3:37 PM, Randall Hauch wrote: > Hi everyone, > > I'd like to start the voting on this KIP to add support for headers in > Connect.: > > *https://cwiki.apache.org/confluence/displa

Re: [DISCUSS] Release Plan for 1.0.1

> > > Could you include one more notable changes in 1.0.1: > > https://issues.apache.org/jira/browse/KAFKA-6398 ? > > > > My PR is ready for reviews and should be mergable at any time. > > > > > > Guozhang > > > > On Tue, Jan 16, 2018 at 10:54 AM, Ewen Ch

Re: [VOTE] KIP-212: Enforce set of legal characters for connector names

+1 (binding) On Tue, Jan 23, 2018 at 7:28 AM, Matt Farmer wrote: > +1 from me (non-binding) =) > > > On Jan 22, 2018, at 7:35 PM, Sönke Liebau > > > wrote: > > > > All, > > > > this KIP has been discussed for quite some time now and I believe we > > addressed all major concerns in the current

Re: [VOTE] KIP-206: Add support for UUID serialization and deserialization

+1 (binding) On Fri, Jan 26, 2018 at 9:16 AM, Colin McCabe wrote: > +1 (non-binding) > > > > On Fri, Jan 26, 2018, at 08:29, Ted Yu wrote: > > +1 > > > > On Fri, Jan 26, 2018 at 7:00 AM, Brandon Kirchner < > > brandon.kirch...@gmail.com> wrote: > > > > > Hi all, > > > > > > I would like to (re)s

[VOTE] 1.0.1 RC0

Hello Kafka users, developers and client-developers, Sorry for a bit of delay, but I've now prepared the first candidate for release of Apache Kafka 1.0.1. This is a bugfix release for the 1.0 branch that was first released with 1.0.0 about 3 months ago. We've fixed 46 significant issues since th

Re: [VOTE] 1.0.1 RC0

tent/groups/staging/org/ > apache/kafka/kafka-clients/ > > I don't see 1.0.1 version. > > Cheers > > On Mon, Feb 5, 2018 at 7:48 PM, Ewen Cheslack-Postava > wrote: > > > Hello Kafka users, developers and client-developers, > > > > Sorry for

Re: [VOTE] 1.0.1 RC0

. This requires "closing" two separate staging repos to get everything released. If things look good now, I can update the release script/instructions to make this clearer. -Ewen On Mon, Feb 5, 2018 at 9:59 PM, Ewen Cheslack-Postava wrote: > Not sure, seems to be variable. I "clo

Documentation build system

Hi all, I just wrote a note in https://issues.apache.org/jira/browse/KAFKA-2967 with a proposal for changing how docs are written. I want to move on this soon if possible and normally would just leave the discussion to the JIRA, but as I think this is something everyone has an opinion on and affec

Re: [VOTE] 1.0.1 RC0

rom source and running the quickstart were successful on Ubuntu > and Windows 10. > > Thanks for running the release. > --Vahid > > > > From: Ewen Cheslack-Postava > To: dev@kafka.apache.org, us...@kafka.apache.org, > kafka-clie...@googlegroups.com > Dat

[VOTE] 1.0.1 RC1

che.org/10/documentation.html * Protocol: http://kafka.apache.org/10/protocol.html Thanks, Ewen Cheslack-Postava

Re: [VOTE] 1.0.1 RC1

And of course I'm +1 since I've already done normal release validation before posting this. -Ewen On Mon, Feb 12, 2018 at 10:15 AM, Ewen Cheslack-Postava wrote: > Hello Kafka users, developers and client-developers, > > This is the second candidate for release of Apache Ka

Re: [VOTE] 1.0.1 RC1

; >> > > <https://github.com/apache/kafka/tree/1.0.1-rc1> tag > >> > > - Ran through quickstart of core/streams > >> > > > >> > > Thanks, > >> > > Satish. > >> > > > >> > > > >> > > On

[VOTE] 1.0.1 RC2

com/apache/kafka/tree/1.0.1-rc2 * Documentation: http://kafka.apache.org/10/documentation.html * Protocol: http://kafka.apache.org/10/protocol.html /** Thanks, Ewen Cheslack-Postava

Re: Question about developer documentation

The web page is more about general project info and might be of interest to people beyond just developers. But I agree the wiki landing page could use some updating. Even more than just the developer section as we're missing several releases, the oldest ones are listed at the top, etc. -Ewen On F

Re: Kafka 0.11.0.1 and filebeat 6.1 compatibility

filebeat is implemented using sarama last I checked, so presumably they are on a version that doesn't know about Kafka 0.11.0.1 and therefore it doesn't know which API versions to use. Not sure if they support leaving it blank or exactly how the sarama config works, but as far as I know sarama has

Re: [VOTE] 1.0.1 RC2

gt; > +1 (non-binding) ... I used the Scala 2.12 binaries and run my tests > with > > > producers / consumers. > > > > > > On Thu, Feb 22, 2018 at 1:06 AM, Ewen Cheslack-Postava < > > e...@confluent.io> > > > wrote: > > > > &g

Re: [DISCUSS] KIP-186: Increase offsets retention default to 7 days

t; > I agree with Jason here, but maybe itself deserves a separate KIP > >> > discussion. > >> > > >> > > >> > > > >> > > -Jason > >> > > > >> > > On Wed, Aug 9, 2017 at 5:24 AM, Sönke Liebau < > >> > > so

[VOTE] KIP-186: Increase offsets retention default to 7 days

I'd like to kick off voting for KIP-186: https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days This is the trivial fix that people in the DISCUSS thread were in favor of. There are some ideas for further refinements, but I think we can follow up

[ANNOUNCE] Apache Kafka 1.0.1 Released

Comar, Ewen Cheslack-Postava, Filipe Agapito, fredfp, Guozhang Wang, huxihx, Ismael Juma, Jason Gustafson, Jeremy Custenborder, Jiangjie (Becket) Qin, Joel Hamill, Konstantine Karantasis, lisa2lisa, Logan Buckley, Manjula K, Matthias J. Sax, Nick Chiu, parafiend, Rajini Sivaram, Randall Hauch, R

Re: Exposing additional metadata in Kafka Connect schema parameters

I can only speak to my view on it, but I view logical types as truly generic. The point is that they can be handled as the underlying type safely, processed as such as needed, but if the logical type is properly preserved they can properly translate through as the more "complicated" type. To me, t

Re: [VOTE] KIP-186: Increase offsets retention default to 7 days

t; > > On Mar 7, 2018, at 1:20 PM, Jay Kreps wrote: > > > > > > +1 > > > > > > I think we can improve this in the future, but this simple change will > > > avoid a lot of pain. Thanks for reviving it Ewen. > > > > > > -Jay > > >

Re: Seeking Feedback on Kafka Connect Issues

Responses inline. On Mon, Mar 19, 2018 at 3:02 PM, Matt Farmer wrote: > Hi everyone, > > We’ve been experimenting recently with some limited use of Kafka Connect > and are hoping to expand to wider use cases soon. However, we had some > internal issues that gave us a well-timed preview of error

Re: [DISCUSS] KIP-242: Mask password fields in Kafka Connect REST response

t by default > > nothing will change? > > > > Randall > > > > On Tue, Jan 16, 2018 at 11:18 PM, Ewen Cheslack-Postava < > e...@confluent.io> > > wrote: > > > >> Vincent, > >> > >> I think with the addition of a configurat

Re: Kafka Connect task re-balance repeatedly

The log is showing that the Connect worker is trying to make sure it has read the entire log and gets to offset 119, but some other worker says it has read to offset 169. The two are in inconsistent states, so the one that seems to be behind will not start work with potentially outdated configurati

Re: [DISCUSSION] KIP-266: Add TimeoutException to KafkaConsumer#position()

Regarding the flexibility question, has someone tried to dig up the discussion of the new consumer APIs when they were being written? I vaguely recall these exact questions about using APIs vs configs and flexibility vs bloating the API surface area having already been discussed. (Not that we shoul

Re: [VOTE] KIP-272: Add API version tag to broker's RequestsPerSec metric

+1 (binding) The incompatibility is unfortunate, but seems unlikely to cause a problem in practice. Let's just make sure there's a note in the upgrade notes about the incompatibility when we have a PR for this. -Ewen On Fri, Mar 30, 2018 at 10:22 AM, Jun Rao wrote: > Hi, Allen, > > Thanks for

Re: [DISCUSS] KIP-276: Add StreamsConfig prefix for different consumers

I think this model is more confusing than it needs to be. We end up with 4 prefixes despite only have 3 types of consumers. We have prefixes for: "base", "main", "global", and "restore". However, we only instantiate consumers of type "main", "global", and "restore". Until now, we've only had two

Re: [DISCUSS] KIP-276: Add StreamsConfig prefix for different consumers

ld need some additional overrides for > > different types of consumers, and they would go ahead and learn about the > > other three prefixes and set them there. > > > > > > I agree that four prefixes would be more confusing, but if we think use > > case 1)'s

Re: [DISCUSS] add connect-related packages to "What is considered a "major change" that needs a KIP?"

First, I agree, updating that list would be a good idea. It's likely it will always be a little divergent from any new additions -- the last update was probably when the KIP page was originally created, before either Connect or Streams existed. However, note that we also document the exact set of

Re: Apache Kafka project charter

Hey all, Sorry I haven't been closely following the threads on this, but I think I can provide a bit more color. Jakub, re: general policy, I'll take the blame that the relevant "rejected alternatives" section in the KIP https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851767#KI

Re: Anyone interested in helping out a little brother Apache project with their Kafka integration?

Chris, Can you point at the starting point for your Connector? Happy to do a quick review of code. I'll admit, I'm a bit confused by the PLC4X positioning -- it seems to claim to be universal IoT protocol, but then I see, e.g., nothing about MQTT on the front page, a protocol that Kafka Connect a

Re: [DISCUSS] KIP-190: Handle client-ids consistently between clients and brokers

Hi all, In working on the patch for KIP-196: Add metrics to Kafka Connect framework, we realized that we have worker and connector/task IDs that are to be included in metrics and those don't currently have constraints on naming. I'd prefer to avoid adding naming restrictions or mangling names unne

Re: [DISCUSS] KIP-190: Handle client-ids consistently between clients and brokers

a bug fix that now just fixes support for certain client IDs and only affects JMX metric names because of JMX limitations). -Ewen > > > > > On Fri, Sep 22, 2017 at 8:53 PM, Ewen Cheslack-Postava > wrote: > > Hi all, > > > > In working on the patch for KIP-196: Add

Re: [DISCUSS] KIP-190: Handle client-ids consistently between clients and brokers

ics use the actual > values. If so, yes that's an option. > > On Mon, Sep 25, 2017 at 5:58 PM, Ewen Cheslack-Postava > wrote: > > On Mon, Sep 25, 2017 at 3:35 AM, Mickael Maison < > mickael.mai...@gmail.com> > > wrote: > > > >> Hi Ewen, > >&g

Re: [DISCUSS] KIP-215: Add topic regex support for Connect sinks

It's fine to be more detailed, but ConfigException is already implied for all other config issues as well. Default could be either null or just empty string. re: alternatives, if you wanted to be slightly more detailed (though still a bit vague) re: supported syntax, you could just say that while

Re: Permission to create a KIP

Not sure if someone added you and just forgot to reply, but it looks like you already have permissions on the wiki. Just follow the process described here: https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals -Ewen On Thu, Oct 26, 2017 at 8:40 AM, Elizabeth Bennett < eliz

Re: [DISCUSS] KIP-215: Add topic regex support for Connect sinks

> > One additional change I might make to the KIP is that 'topics.regex' > might > > be a better choice for config name than 'topics.pattern'. That would be > in > > keeping with RegexRouter that has a 'regex' configuration option rather > >

Re: [VOTE] KIP-215: Add topic regex support for Connect sinks

+1 binding Thanks Jeff! On Wed, Nov 1, 2017 at 5:21 PM, Randall Hauch wrote: > +1 (non-binding) > > Thanks for pushing this through. Great work! > > Randall Hauch > > On Wed, Nov 1, 2017 at 9:40 AM, Jeff Klukas wrote: > > > I haven't heard any additional concerns over the proposal, so I'd like

Re: [VOTE] KIP-215: Add topic regex support for Connect sinks

t; > +1. Thanks for the KIP! > > > > On Fri, Nov 3, 2017 at 2:15 PM, Guozhang Wang > wrote: > > > > > +1 binding > > > > > > On Fri, Nov 3, 2017 at 1:25 PM, Ewen Cheslack-Postava < > e...@confluent.io > > > > > > wrote: &

Re: [VOTE] KIP-218: Make KafkaFuture.Function java 8 lambda compatible

+1 (binding) -Ewen On Mon, Dec 11, 2017 at 12:40 PM, Gwen Shapira wrote: > +1 (binding) - nice API improvement, thanks for driving it! > > On Mon, Dec 11, 2017 at 11:52 AM Xavier Léauté > wrote: > > > Thanks Steven, I believe I addressed all the comments. If the it looks > good > > to you let'

[DISCUSS] KIP-238: Expose Kafka cluster ID in Connect REST API

I'd like to start discussion on a simple KIP to expose Kafka cluster ID info in the Connect REST API: https://cwiki.apache.org/confluence/display/KAFKA/KIP-238%3A+Expose+Kafka+cluster+ID+in+Connect+REST+API Hopefully straightforward, though there are some details on how this affects startup behav

Re: [DISCUSS] KIP-238: Expose Kafka cluster ID in Connect REST API

afkaClusterId() is called synchronously. Have you > considered making the call asynchronous (normally the GET / request comes > sometime after worker start) ? > > Thanks > > On Mon, Dec 11, 2017 at 3:40 PM, Ewen Cheslack-Postava > wrote: > > > I'd like to start di

Re: [DISCUSS] KIP-234: add support for getting topic defaults from AdminClient

I think the key point is when the kafka admin and user creating topics differ. I think a more realistic example of Dan's point (2) is for retention. I know that realistically, admins aren't just going to randomly drop the broker defaults from 1w to 1d without warning anyone (they'd likely be fired.

Re: [DISCUSS] KIP-238: Expose Kafka cluster ID in Connect REST API

which it is useful for since it doesn't require any other external services to be running just to give a response) can just interpret connection refused or timeouts as an unhealthy state, as they should anyway. -Ewen > > Gwen > > > On Mon, Dec 11, 2017 at 3:42 PM Ewen Chesla

Re: [DISCUSS] KIP-238: Expose Kafka cluster ID in Connect REST API

ded. We haven't been explicit about this before, but unless someone objects, I don't think it is unreasonable. Happy to update the KIP w/ these details if someone feels they would be valuable. -Ewen On Mon, Dec 11, 2017 at 8:21 PM, Ewen Cheslack-Postava wrote: > > On Mon, Dec 11,

Re: [DISCUSS] KIP-234: add support for getting topic defaults from AdminClient

seems like > returning a NewTopic could make sense because the ConfigResource for a > TOPIC type does not let me encode `numPartitions` > > thanks > dan > > On Mon, Dec 11, 2017 at 7:22 PM, Colin McCabe wrote: > > > Hi Dan, > > > > The KIP looks good ove

[VOTE] KIP-238: Expose Kafka cluster ID in Connect REST API

Discussion seems to have tapered off, so I'd like to start the vote on https://cwiki.apache.org/confluence/display/KAFKA/KIP-238%3A+Expose+Kafka+cluster+ID+in+Connect+REST+API Obviously +1 (binding) from me :) -Ewen

Re: [VOTE] KIP-238: Expose Kafka cluster ID in Connect REST API

binding). Thanks! > > > On Fri, Dec 15, 2017 at 10:55 AM Ted Yu wrote: > > > > > > > +1 > > > > > > > > On Fri, Dec 15, 2017 at 10:49 AM, Ewen Cheslack-Postava < > > > e...@confluent.io > > > > > > > > >

Re: [DISCUSS] KIP-228 Negative record timestamp support

I think the trivial change of just recognizing using -1 was a mistake for a sentinel value and special casing it while allowing other negative values through is the most practical, reasonable change. Realistically, the scope of impact for that -1 is pretty tiny, as has been pointed out. A single m

Re: [DISCUSS] KIP 145 - Expose Record Headers in Kafka Connect

t;> > INT32 to STRUCT, BYTE_ARRAY to anything, etc.), so these can > throw a > > >>>> > `DataException`. > > >>>> > > > >>>> > I've refined this approach over the last few months, and have a PR > > >>

Re: [VOTE] KIP-239 Add queryableStoreName() to GlobalKTable

+1 binding The idea seems reasonable. Looking at it implementation-wise, seems there is a bit of awkwardness because GlobalKTableImpl uses a KTableValueGetterSupplier which seems to possibly have multiple stores, but maybe using the more specific KTableSourceValueGetterSupplier implementation inst

Re: [VOTE] KIP-233: Simplify StreamsBuilder#addGlobalStore

+1 binding, seems like a nice simplification. Regarding the source and processor name, do they actually need to be unique or could they use the same value? Since these use incrementing integers, it could be nice for debuggability/understanding to have them use the same name if possible instead of

Re: [DISCUSS] KIP-228 Negative record timestamp support

> enable negative timestamps if there are records with -1 in them already > -- otherwise, semantics break down -- but this would be a config error > we cannot prevent. However, I would expect that mostly newly created > topics would enable this config anyway. > > > -Matthi

Re: [DISCUSS] KIP-228 Negative record timestamp support

"unknown" and all timestamps > >> would be valid. Old producers, can't write to those topics if they are > >> configured with CREATE_TIME though; APPEND_TIME would still work for > >> older producers but with APPEND_TIME no negative timestamps are possible >

Re: [DISCUSS] KIP-242: Mask password fields in Kafka Connect REST response

Vincent, Thanks for the KIP. This is definitely an issue we know is a problem for some users. I think the major problem with the KIP as-is is that it makes it impossible to get the original value back out of the API. This KIP probably ties in significantly with ideas for securing the REST API (SS

Re: [VOTE] KIP-237: More Controller Health Metrics

Dong, Seems like a reasonable addition. +1 (binding) from me. There were some final naming issues in the DISCUSS thread that didn't get follow up. I'm fine with either version of the naming as these are details I think mostly advanced users will be monitoring and both naming arguments are reasona

Re: [VOTE] KIP-243: Make ProducerConfig and ConsumerConfig constructors public

Builders have historically seen some resistance in the project (by some notable original authors...) but they've been increasingly making their way in -- SchemaBuilder in Connect, I believe some small streams APIs, AdminClient stuff. The general trend seems to be towards more fluent APIs. Regardin

Re: [DISCUSS] KIP-231: Improve the Required ACL of ListGroups API

Late to the game here, but I'm +1 on this. Some of the ConsumerGroup permissions are weird, but this KIP brings the describe ACLs into better alignment with everything else and makes things more functional for clients with more locked down permissions. -Ewen On Fri, Dec 15, 2017 at 12:57 PM, Vahi

Re: [VOTE] KIP-231: Improve the Required ACL of ListGroups API

+1 (binding) Thanks for the KIP Vahid, nice improvement! -Ewen On Tue, Dec 19, 2017 at 11:30 AM, Vahid S Hashemian < vahidhashem...@us.ibm.com> wrote: > I believe the concerns on this KIP have been addressed so far. > Therefore, I'd like to start a vote. > > https://cwiki.apache.org/confluence/

Re: [VOTE] KIP-239 Add queryableStoreName() to GlobalKTable

Supplier. Hence, your requirement > is satisfied. > > Since this is the vote thread, if you have further comments, please comment > on the pull request. > > On Tue, Jan 2, 2018 at 6:38 PM, Ewen Cheslack-Postava > wrote: > > > +1 binding > > > > The idea s

Re: [DISCUSS] KIP-208: Add SSL support to Kafka Connect REST interface

Hey Jakub, Sorry for not getting to this sooner. Overall the proposal looks good to me, I just had a couple of questions. 1. For the configs/overrides, does this happen on a per-setting basis or if one override is included do we not use any of the original settings? I suspect that if you need to

Re: [VOTE] KIP-208: Add SSL support to Kafka Connect REST interface

Jakub, I left a few comments in the discuss thread, but I'll also reply here just to bump the VOTE thread's visibility. I would like to resolve the few comments I left, but I am effectively +1 on this, the comments I left were mainly details. Committers that could help with the necessary votes wo

Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter configs in WorkerConfig

> I just edited the KIP to reflect the changes. > > Regards, > Umesh > > On Wed, 9 Aug 2017 at 11:00 Ewen Cheslack-Postava > wrote: > >> Great, looking good. I'd probably be a bit more concrete about the >> Proposed Changes (e.g., "will log an warn

Re: [DISCUSS] KIP-212: Enforce set of legal characters for connector names

Very late to the game here, but a few thoughts: 1. Regarding whether KIP is necessary, I don't mind doing it for documentation sake, but I would classify any mishandling of connector names here as a bug. Which doesn't require a KIP to fix. 2. For support of characters, Kafka has some history of j

Re: [DISCUSS] KIP-212: Enforce set of legal characters for connector names

th this behavior? I agree that technically we > can (and currently do) support whitespace-only names, but users have > reported this as problematic, and it also would be confusing for most user > interfaces. > > Best regards, > > Randall > > On Thu, Jan 4, 2018 at 1

Re: [EXTERNAL] [VOTE] KIP-158: Kafka Connect should allow source connectors to set topic-specific settings for new topics

+1 (binding) My only final comment would be that the topic.creation.enable setting could potentially be left out. We're still backwards compatible with what we promised before (or at least compatibility is debatable). You could enforce not being able to create topics with ACLs anyway, so avoiding

Re: [VOTE] KIP-421: Support resolving externalized secrets in AbstractConfig

> It allows _all_ existing clients of the class, e.g. those in Apache Kafka or in applications written by other people that use the class, to get this functionality for free, i.e. without any code changes. (I realize this is probably where the 'unexpected effects' comes from). > Personally, I thi

Re: [DISCUSS] KIP-415: Incremental Cooperative Rebalancing in Kafka Connect

I was going to make a related comment about connect.protocol. Even if we have the config, we should default it to compatible given v0 state is small and we believe v1 is better and people should migrate to it. While I like getting rid of configs, not sure whether we should remove it here. If we th

Re: [VOTE] KIP-415: Incremental Cooperative Rebalancing in Kafka Connect

+1 (binding) -Ewen On Wed, Mar 13, 2019 at 2:04 PM Randall Hauch wrote: > Excellent work, Konstantine! > > +1 (binding) > > On Mon, Mar 11, 2019 at 8:05 PM Konstantine Karantasis < > konstant...@confluent.io> wrote: > > > Thanks Jason! > > That makes perfect sense. The change is reflected in th

Re: [VOTE] 2.2.0 RC2

+1 -Ewen On Thu, Mar 21, 2019 at 10:33 AM Harsha wrote: > +1 (non-bidning) > - Download artifacts, setup 3 node cluster > - Ran producer/consumer clients > > Thanks, > Harsha > > On Thu, Mar 21, 2019, at 5:54 AM, Andrew Schofield wrote: > > +1 (non-binding) > > > > - Downloaded the artifacts >

Re: [DISCUSS] KIP-172 Add regular-expression topic support for sink connector

Kenji, This looks great. I'd probably make a couple of minor changes for clarity: 1. In public interfaces section, I'd either round it out with client configuration via REST proxy or just simplify to "Adds an optional field to sink connector configuration" 2. Maybe clarify that if you specify bot

Re: [DISCUSS] 2017 October release planning and release version

Did we deprecate anything in 0.11.0? The one concern with bumping major versions in consecutive releases is that you may not give people the room for transition if you deprecate and then immediately remove in the next release. -Ewen On Thu, Jul 20, 2017 at 4:51 AM, Damian Guy wrote: > +1 on 1.0

  1   2   3   4   5   6   7   8   9   10   >