Re: [DISCUSS] KIP-585: Conditional SMT

Hi Tom. Thanks for the KIP. I like how the proposal has ended up to be and I think it describes a practical approach. I have to say that, for a moment, earlier in the discussion I thought we were leaning a bit towards an unconventional mini assembly language based on java properties. The reliance

Re: [VOTE] KIP-577: Allow HTTP Response Headers Configured for Kafka Connect

Makes sense to allow users to comply with their requirements without taking on the maintenance cost of keeping up with new headers across different versions. Thanks for the KIP Jeff. +1 (binding) Konstantine On Tue, May 12, 2020 at 3:13 AM Manikumar wrote: > +1 (binding) > > Thanks for the KIP

Re: [VOTE] KIP-437: Custom replacement for MaskField SMT

I think this improvement makes total sense. It's interesting that it didn't accompany the initial version of this transformation. +1 (binding) Konstantine On Wed, May 6, 2020 at 2:03 PM Randall Hauch wrote: > Thanks for starting the vote, Yu. > > +1 (binding) > > Randall > > On Sat, Dec 21, 20

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Thanks for KIP Aakash. This proposal will address a significant gap in error handling for sink connectors, so I'd also like to see it implemented. Interesting discussion so far and I agree with a lot of what's been said. First of all I agree with Andrew. When I first read the KIP I also felt this

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

I was on the fence between the various overloading methods myself, liking `start(...)` the least. Initially, I thought we were interested in offering the ability to call the reporter out of band, outside `put`. But after your replies I understand you don't think that's the case, and I also agree t

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Small correction. I didn't mean to declare the new method `abstract`. I agree with Randall's suggestion to give it a default implementation that will call the old `put` and at the same time deprecate the old `put`. Konstantine On Fri, May 15, 2020 at 10:19 AM Konstantine Karantasis

Re: [VOTE] KIP 585: Filter and conditional SMTs

+1 (binding) Thanks Tom. Konstantine On Fri, May 15, 2020 at 5:03 AM Andrew Schofield wrote: > +1 (non-binding) > > Thanks for the KIP. This will be very useful. > > Andrew Schofield > > On 13/05/2020, 10:14, "Tom Bentley" wrote: > > Hi, > > I'd like to start a vote on KIP-585: Filte

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Thanks for the quick response Aakash. To your last point, modern APIs like this tend to be asynchronous (see admin, producer in Kafka) and such definition results in more expressive and well defined APIs. What you describe is easily an opt-in feature for the connector developer. At the same time,

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

; Overall, yes, the "public void > > errantRecordReporter(BiConsumer > > Throwable> reporter) {}" proposal in the original KIP is somewhat of a > > > mouthful, but are there are any simpler alternatives that do not > exclude > > > existing connectors, add

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

orker versions. there may be production deployments that > > >> need > > >> > one old and one new connector that now cannot work on any version > of a > > >> > single worker. Building connectors is complex, and it's kinda unfair > > to > &g

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

in a meaningful way in order to make the upgrade path easy to follow. Maybe you'd like to add a note to your compatibility section in this KIP as well. Regards, Konstantine On Sat, May 16, 2020 at 10:13 AM Aakash Shah wrote: > +1 > > On Sat, May 16, 2020 at 9:55 AM Konsta

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

ually super > clean and makes a lot of sense. Thanks, Andrew, for originally suggesting > it. I know we're all trying to improve the Connect API in a way that makes > sense, and deliberate and constructive discussion is a healthy thing. > Thanks again to everyone for participating! >

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Hi all, I'm on board with adding an interface in the Connect API as Arjun suggested. Slightly higher commitment and maintenance but it also gives us an easier path to future extensions in this scope (error handling). The usage is equivalent to adding just a new method with known types to `SinkTask

Re: [VOTE] KIP-597: MirrorMaker2 internal topics Formatters

Thanks Michael. I think it's useful to enable specialized message formatters by adding this interface to the public API. You have my vote: +1 (binding) Just a few optional comments below: 1. Would you mind adding the equivalent command line example in the places where you have an example output?

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Thanks for the detailed explanation Randall. I think it highlights nicely how the common practice of overlapping communication with computation (or other communication) in concurrent systems can be useful and practical in this case. I also agree with the amendment around `preCommit` and the guara

Re: [VOTE] KIP-610: Error Reporting in Sink Connectors

+1 (binding) I like how the KIP looks now too. Quite active discussions within the past few days, which I found very useful. There's some room to allow in the future the connector developers to decide whether they want greater control over error reporting or they want the framework to keep provid

Re: [DISCUSS] KIP-158 UPDATED: Enable source connectors to create new topics with specific configs in Kafka Connect during runtime

"Optional.empty()" > if neither the specific group or "default" is set. > > Thanks, > Jose > > > On Thu, Dec 19, 2019 at 8:27 PM Tom Bentley wrote: > > > Thanks Konstantine, lgtm. > > > > On Thu, Dec 19, 2019 at 5:34 PM Ryanne Dol

Re: What happened to KIP-158?

Hi Tom. Good timing for your question. I'll be revisiting KIP-158 and I'll bring an updated proposal for discussion this quarter. As always, it'll be ideal to strike a good balance between flexibility and conciseness on what we expose to Connect's developers and operators. Stay tuned. Konstantine

Re: Connect port

Hi Paul, A Connect worker will bring up and listen to at least one port that is used by its REST API. This API is used externally to manage connectors and query their status, as well as internally between the Connect workers in order for them to form a cluster and share tasks (Connect workers form

[DISCUSS] KIP-158 UPDATED: Enable source connectors to create new topics with specific configs in Kafka Connect during runtime

I've taken a second look to KIP-158 after syncing with Randall Hauch, who was the original author of the proposal, and I have updated the KIP in place. The main new features of this updated KIP-158 is the introduction of groups of configs that can be composed and the ability to match topics to the

Re: [DISCUSS] KIP-158 UPDATED: Enable source connectors to create new topics with specific configs in Kafka Connect during runtime

replication factor based on the number of nodes, etc. > > My team leverages Connect's plug-ins in other places to enable seamless > integration with the rest of our platform. We would definitely use a topic > creation hook if one existed. In particular, we have a concept of &quo

Re: [DISCUSS] KIP-158 UPDATED: Enable source connectors to create new topics with specific configs in Kafka Connect during runtime

already exist or that the > broker will auto-create them when needed." I think this means it's > something which is checked when the connector is created/configured, rather > than at some point during runtime when an attempt to create a topic fails > due to authorizatio

[VOTE] On the new KIP-158: Kafka Connect allows source connectors to set topic settings when creating new topics

Hi everyone. I hope y'all had a nice break. The discussion on KIP-158 seems to have wrapped up since last year, so I'd like to open the vote on this KIP. A reminder that this is an updated KIP-158 (that had also been approved in its earlier version) and it seems to be a highly anticipated feature

[DISCUSS] KIP-558: Track the set of actively used topics by connectors in Kafka Connect

Hi all. I just posted KIP-558: Track the set of actively used topics by connectors in Kafka Connect Wiki link here: https://cwiki.apache.org/confluence/display/KAFKA/KIP-558%3A+Track+the+set+of+actively+used+topics+by+connectors+in+Kafka+Connect I think it's a nice extension to follow up on KIP-

Re: [DISCUSS] KIP-558: Track the set of actively used topics by connectors in Kafka Connect

sage records. Then the user resets the active > > > topics > > > >for connector A while the connector is still running? If the > > connector > > > >writes to no new topics, before the tasks are rebalanced then is > it > > > correct > &g

Re: [DISCUSS] KIP-558: Track the set of actively used topics by connectors in Kafka Connect

ds. Then the user resets the > active > > > > topics > > > > >for connector A while the connector is still running? If the > > > connector > > > > >writes to no new topics, before the tasks are rebalanced then is > >

Re: [DISCUSS] KIP-558: Track the set of actively used topics by connectors in Kafka Connect

. Cheers, Konstantine On Wed, Jan 15, 2020 at 2:41 PM Randall Hauch wrote: > On Wed, Jan 15, 2020 at 4:36 PM Randall Hauch wrote: > > > On Wed, Jan 15, 2020 at 2:05 PM Konstantine Karantasis < > > konstant...@confluent.io> wrote: > > > >> > >>

Re: [DISCUSS] KIP-558: Track the set of actively used topics by connectors in Kafka Connect

ing their first records ... these tasks will > > start > > > > > > inspecting > > > > > > >which is the Kafka topic of each of these records". IIUC, > the > > > > first > > > > > > "task" > > > > > > >men

Re: [DISCUSS] KIP-558: Track the set of actively used topics by connectors in Kafka Connect

t; > On Wed, Jan 15, 2020 at 2:05 PM Konstantine Karantasis < > konstant...@confluent.io> wrote: > > > Hi Randall, Tom and Almog. I'm excited to read your comments. I'll reply > in > > separate emails, in order. > > > > First, to Randall's com

Re: [VOTE] On the new KIP-158: Kafka Connect allows source connectors to set topic settings when creating new topics

, Jan 15, 2020 at 5:49 AM Gwen Shapira wrote: > +1 (binding) > Looks super useful. Thank you. > > > > > On Mon, Jan 13, 2020 at 8:16 AM Konstantine Karantasis > wrote: > > > > Hi everyone. > > > > I hope y'all had a nice break. The discussion o

Re: [DISCUSS] KIP-558: Track the set of actively used topics by connectors in Kafka Connect

n that all topics will be removed and then > the active topics list will be repopulated as records are consumed from new > topics? > The intention was to imply the former. But based on Randall's comment above, I'm changing the KIP to include a reset parameter in the PUT /connecto

Re: [DISCUSS] KIP-558: Track the set of actively used topics by connectors in Kafka Connect

the initial draft of the KIP I described how we could inspect the configuration of a sink connector for changes. Best, Konstantine Independent of your thoughts on the above, what will the default value for > the newly-proposed parameter be? If resets are performed by default, the &

Re: [DISCUSS] KIP-558: Track the set of actively used topics by connectors in Kafka Connect

, Jan 17, 2020 at 3:51 PM Konstantine Karantasis < konstant...@confluent.io> wrote: > > Thanks for the follow up Chris. Replies below: > > On Fri, Jan 17, 2020 at 3:07 PM Christopher Egerton > wrote: > >> Thanks, Konstantine. Just a few more questions: >> >> > &

[VOTE] KIP-558: Add Connect REST API endpoints to view the topics used by connectors in Kafka Connect

Hi all, I'd like to open the vote on KIP-558 that had a constructive flurry of discussions in the past few days, in order to give this KIP the opportunity to be voted on by the current KIP deadline (Wed, Jan 22, 2020), if - of course - there's agreement upon its final form. KIP link here: https:/

Re: [DISCUSS] KIP-558: Track the set of actively used topics by connectors in Kafka Connect

> > > > As soon as a worker detects the addition of a topic to a connector's set > of > > active topics, the worker will not post to the status.storage.topic > > additional update records for the connector and this newly-detected > active > > topic. > >

Re: [VOTE] KIP-558: Add Connect REST API endpoints to view the topics used by connectors in Kafka Connect

hanks from me! +1 (non-binding) > >> > >> On Tue, Jan 21, 2020 at 11:04 AM Randall Hauch > wrote: > >> > >>> Thanks again for the KIP and this improvement for Connect. > >>> > >>> +1 (binding) > >>> > >>> Ran

Re: [DISCUSS] Apache Kafka 2.5.0 release

Hi David, thanks for driving the release. Please also remove KIP-158 from the list of KIPs that you plan to include in 2.5 KIP-158 has been accepted, but the implementation is not yet final. It will be included in the release that follows 2.5. Regards, Konstantine On 1/30/20, Matthias J. Sax w

Re: [DISCUSS] KIP-568: Explicit rebalance triggering on the Consumer

Hi Sophie. Thanks for the KIP. I liked how focused the proposal is. Also, its motivation is clear after carefully reading the KIP and its references. Yet, I think it'd be a good idea to call out explicitly on the Rejected Alternatives section that an automatic and periodic triggering of rebalance

Re: [DISCUSS] KIP-568: Explicit rebalance triggering on the Consumer

e listener won't get called since partition > assignments > > might not change. > > If that is the case, do we want to possibly consider adding a method to > the > > `ConsumerRebalanceListener` for callbacks on `enforceRebalance` actions? > > > > Thanks, > > Bill &g

Re: [VOTE] KIP-568: Explicit rebalance triggering on the Consumer

The KIP reads quite well for me now and I think this feature will enable even more efficient load balancing for specific use cases. I'm also +1 (non-binding) - Konstantine On Tue, Feb 11, 2020 at 9:35 AM Navinder Brar wrote: > Thanks Sophie, much required. > +1 non-binding. > > > Sent from Yah

Re: [DISCUSS] Apache Kafka 2.5.0 release

sday, February 12th, is the code > > freeze for the 2.5.0 release. After this time we will only accept blocker > > bugs onto the release branch. > > > > Thanks! > > David > > > > On Fri, Jan 31, 2020 at 5:13 PM David Arthur wrote: > > > > >

Re: [ANNOUNCE] New committer: Konstantine Karantasis

> > > > > > > > > > > > > On Thu, Feb 27, 2020 at 7:46 AM Matthias J. Sax < > > > > mj...@apache.org> > > > > > > > > > wrote: > > > > > > > > > > > > > > > >

Re: [kafka-clients] Re: [VOTE] 2.5.0 RC1

Hi David, after some broader testing with Kafka Connect, we've discovered https://issues.apache.org/jira/browse/KAFKA-9712 and I'd like to raise this issue as a potential blocker for 2.5.0. It seems to be a regression after a recent essential upgrade of the reflections library. The jira contains a

Re: [kafka-clients] Re: [VOTE] 2.5.0 RC1

ine. After reviewing the Jira, It does seem like we should > include a fix for this in 2.5. > > -David > > On Fri, Mar 13, 2020 at 12:55 AM Konstantine Karantasis < > konstant...@confluent.io> wrote: > > > Hi David, > > > > after some broader testin

Re: contributor access

Just added you. Thanks for your interest to contribute to the Apache Kafka project Andras! Konstantine On Fri, Apr 22, 2022 at 7:25 AM András Csáki wrote: > Hi Kafka Devs, > > I'd like to start contributing to Apache Kafka, first with a fix for > KAFKA-13848

Re: Requesting review of a long pending Kafka Connect balanced task distribution PR

I'm on it Ramesh. Thanks for the contribution and the notification. Expect my second round of comments within the next few days. Konstantine On Tue, Jan 19, 2021 at 8:44 AM ramesh krishnan muthusamy < ramkrish1...@gmail.com> wrote: > Hi Team, > > This is a major fix required to use consumer incr

Re: [apache/kafka] KAFKA-10413 Allow even distribution of lost/new tasks when more than one worker

Added. Welcome Ramesh! - Konstantine On Tue, Feb 2, 2021 at 10:13 PM Luke Chen wrote: > Hi Committers, > please help Ramens add JIRA account: *ramkrish1489* into contribution list. > > Thanks. > Luke > > On Wed, Feb 3, 2021 at 2:10 PM Ramesh Krishnan > wrote: > > > Hi Luke, > > > > Please find

[DISCUSS] Apache Kafka 3.0.0 release

Hi all, Given that we seem to reach an agreement that the feature release after the upcoming 2.8.0 will be 3.0.0, I'd like to volunteer to be the release manager for the Apache Kafka 3.0.0 release. It's a major release, so I thought it'd be helpful to start planning a bit in advance. If there ar

Re: [DISCUSS] Apache Kafka 3.0.0 release

e 9th, 2021. Please let me know if you have any objections. Regards, Konstantine On Wed, Feb 24, 2021 at 9:45 AM Chia-Ping Tsai wrote: > Thanks for taking over this hard job! +1 > > On 2021/02/23 08:02:09, Konstantine Karantasis > wrote: > > Hi all, > > > > Given

Re: Request for JIRA permissions

Added. Welcome to the project Nick! Looking forward to your contributions. Konstantine On Mon, Mar 15, 2021 at 5:21 PM Nick Dekker wrote: > I would like to request JIRA issue editing permission, as I would like to > contribute to the Kafka project (PRs require issue status changes). My JIRA >

Re: [ANNOUNCE] New committer: Tom Bentley

Congratulations Tom! Well deserved. Konstantine On Mon, Mar 15, 2021 at 4:52 PM Luke Chen wrote: > Congratulations! > > Federico Valeri 於 2021年3月16日 週二 上午4:11 寫道： > > > Congrats, Tom! > > > > Well deserved. > > > > On Mon, Mar 15, 2021, 8:09 PM Paolo Patierno wrote: > > > > > Congratulations

Re: [ANNOUNCE] New Kafka PMC Member: Chia-Ping Tsai

Congratulations Chia-Ping! Konstantine On Mon, Mar 15, 2021 at 4:31 AM Rajini Sivaram wrote: > Congratulations, Chia-Ping, well deserved! > > Regards, > > Rajini > > On Mon, Mar 15, 2021 at 9:59 AM Bruno Cadonna > wrote: > > > Congrats, Chia-Ping! > > > > Best, > > Bruno > > > > On 15.03.21 09

Re: Request to Create KIP

Added. Thanks for your interest in Apache Kafka. Looking forward to your contributions! Konstantine On Mon, Mar 22, 2021 at 3:15 PM Soumyajit Sahu wrote: > Hello, > Please allow my wiki id (soumyajit-sahu) to create Kafka Improvement > Proposals. > > Thank you. > Regards > Soumyajit Sahu >

Re: Permission to Assign Jiras

Hi Ryan. I found your first and last name on jira and added you to the list of contributors for the Apache Kafka project. You should be able to assign tickets to yourself now. Welcome! Konstantine On Tue, Apr 6, 2021 at 2:20 PM Ryan Dielhenn wrote: > Hello, > > May I have permission to assign

Re: [DISCUSS] Apache Kafka 3.0.0 release

mprovement+Proposals Release Plan 3.0.0: https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.0.0 Regards, Konstantine On Wed, Mar 10, 2021 at 10:28 AM Konstantine Karantasis < konstant...@confluent.io> wrote: > > Thank you and hi again. > > I just publishe

Re: [DISCUSS] Apache Kafka 3.0.0 release

> KIP wiki and that their respective Jira tickets include 3.0.0 in the "Fix > > Version/s" label. > > > > Kafka Improvement Proposals: > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals > > > > Release Plan 3.0.0

Re: [DISCUSS] Apache Kafka 3.0.0 release

; > > now explains which modules will be migrated and why. > > > 2. KIP-719 document > > > < > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-719%3A+Add+Log4J2+Appender > > > > > > > now explains not only the log4j2-appende

[DISCUSS] Apache Kafka 3.0.0 release plan with new updated dates

Hi all, Please find below the updated release plan for the Apache Kafka 3.0.0 release. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=177046466 New suggested dates for the release are as follows: KIP Freeze is 09 June 2021 (same date as in the initial plan) Feature Freeze is 3

Re: [DISCUSS] Apache Kafka 3.0.0 release plan with new updated dates

gt; > >- KIP-725: Streamlining configurations for WindowedSerializer and >WindowedDeserializer >< > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=177047930 > > > > > Thanks! > -Sophie > > > On Wed, May 26, 2021 at 2:48 PM Konstantine Ka

Re: [DISCUSS] Apache Kafka 3.0.0 release plan with new updated dates

on the scheduling changes as well > > > > On Wed, May 26, 2021 at 4:00 PM David Arthur wrote: > > > > > The new schedule looks good to me, +1 > > > > > > On Wed, May 26, 2021 at 6:29 PM Ismael Juma wrote: > > > > > > > Than

Re: [DISCUSS] KIP-745: Connect API to restart connector and tasks

Thanks for the KIP Randall! Really happy to see this feature coming along finally. Will indeed resolve an unintuitive aspect of Connect's REST API. I'm in favor of the current approach overall. Just a few comments below that could use a brief discussion: 1) Is there a specific reason why you choo

Re: [VOTE] KIP-721: Enable connector log contexts in Connect Log4j configuration

I agree 3.0.0 is a good opportunity to enable this useful feature by default. +1 (binding) Konstantine On Fri, May 7, 2021 at 6:33 PM Dongjin Lee wrote: > +1 (Non-binding) > > Thanks, > Dongjin > > On Thu, May 6, 2021 at 3:19 AM Randall Hauch wrote: > > > I'd like to start a vote on KIP-721:

Re: [VOTE] KIP-722: Enable connector client overrides by default

Good to flip the switch on this useful feature with the opportunity of the major release here as well. I don't see any disadvantages in doing so. +1 (binding) Konstantine On Thu, May 6, 2021 at 6:07 AM Ryanne Dolan wrote: > +1 (non-binding) Thanks! > > Ryanne > > On Wed, May 5, 2021, 4:04 PM R

Re: [VOTE] KIP-738: Removal of Connect's internal converter properties

+1 (binding) but also with the note that we don't tend to require a KIP in order to remove configurations that have been deprecated in previous KIPs. A jira ticket with the right release as a target should suffice. In future KIPs adding a note that says that a feature is deprecated and may be rem

Re: [DISCUSS] KIP-494 Connect REST Endpoint for Transformations (SMTs) and other Plugins

Hi Cyrus. The proposal looks good and I like the API spec definition the way it's presented. Having said that, a few examples that would list the request type and body, the returned status and the json response would be nice too, following the tradition of other KIPs. See https://cwiki.apache.or

[DISCUSS] KIP-145: Classloading Isolation in Connect

Hi everyone, we aim to address dependency conflicts in Kafka Connect soon by applying class loading isolation. Feel free to take a look at KIP-145 here: https://cwiki.apache.org/confluence/display/KAFKA/KIP-145+Classloading+Isolation+in+Connect which describes minimal required changes in the p

[DISCUSS] KIP-146: Classloading Isolation in Connect

* Because of KIP number collision, please disregard my previous KIP announcement and use this thread for discussion instead * Hi everyone, we aim to address dependency conflicts in Kafka Connect soon by applying class loading isolation. Feel free to take a look at KIP-146 here: *https://cwiki.

Re: [DISCUSS] KIP-146: Classloading Isolation in Connect

t; > > > So it looks like this is mostly for upgrade purpose? Because the initial > > upgrade will not have the module.path set and therefore classpath > isolation > > will simply not work by default? > > > > In that case, why don't we simply use the existe

Re: [DISCUSS] KIP-145: Classloading Isolation in Connect

17 at 10:20 AM, Colin McCabe wrote: > +1 (non-binding) > > This would be a nice improvement. > > C. > > On Fri, Apr 28, 2017, at 11:03, Konstantine Karantasis wrote: > > Hi everyone, > > > > we aim to address dependency conflicts in Kafka Connect

Re: [DISCUSS] KIP-146: Classloading Isolation in Connect

Thanks Ewen. I'm replying inline as well. On Tue, May 2, 2017 at 11:24 AM, Ewen Cheslack-Postava wrote: > Thanks for the KIP. > > A few responses inline, followed by additional comments. > > On Mon, May 1, 2017 at 9:50 PM, Konstantine Karantasis < > konstant...@confl

Re: [DISCUSS] KIP-146: Classloading Isolation in Connect

nk Transformations will, on average, have the fewest > extra dependencies. Connectors have the most, followed by Converters, then > Transformations. But I think Konstantine has mentioned these in the KIP -- > if it could be clearer in the proposed changes, perhaps you could suggest

Re: [DISCUSS] KIP 151 - Expose Connector type in REST API

Thank you for the KIP. It's a nice improvement. Two small suggestions: 1) Let's not use all caps to describe the type of the connector. "Source" and "Sink" seem more appropriate (but even all lower case would be better). 2) It's been discussed in other contexts recently, but I believe finally exp

Re: [DISCUSS] KIP 151 - Expose Connector type in REST API

Nice. Thanks! -Konstantine On Sat, May 6, 2017 at 10:43 PM, dan wrote: > thanks for the feedback, it all sounds good. i have made the changes to the > pr and the kip. > > dan > > On Fri, May 5, 2017 at 9:29 AM, Konstantine Karantasis < > konstant...@confluent.io> wro

Re: [DISCUSS] KIP-146: Classloading Isolation in Connect

anilla > lightweight connect. Anyway, discussions for later. > > > > On 4/5/17, 4:17 am, "Konstantine Karantasis" > wrote: > > Thank you Stephane, > > your comments bring interesting and useful subjects to the discussion. > I'm > addin

Re: [DISCUSS] KIP-146: Classloading Isolation in Connect

th the built-in ones? > > On Sat, Apr 29, 2017 at 9:16 AM, Konstantine Karantasis < > konstant...@confluent.io> wrote: > > > * Because of KIP number collision, please disregard my previous KIP > > announcement and use this thread for discussion instead * > >

Re: [DISCUSS] KIP-146: Classloading Isolation in Connect

e same API. That would allow a clear audit of where the > code is being loaded. :-) > > Mathieu > > > On Sat, Apr 29, 2017 at 10:16 AM, Konstantine Karantasis < > konstant...@confluent.io> wrote: > > > * Because of KIP number collision, please disregard my previo

Re: [DISCUSS] KIP-146: Classloading Isolation in Connect

ally allow this nice feature to be included in the 0.11.0.0 Apache Kafka release. I appreciate your feedback. Let me know if you agree. -Konstantine On Mon, May 8, 2017 at 9:34 AM, Konstantine Karantasis < konstant...@confluent.io> wrote: > Hi Mathieu, > > I believe you are refer

Re: [DISCUSS] KIP-146: Classloading Isolation in Connect

at 9:47 AM, Konstantine Karantasis < konstant...@confluent.io> wrote: > Dear all, > > KIP-146 has been updated to incorporate the changes that were suggested > during the discussion so far. You may find the updated version here: > > https://cwiki.apache.org/confluence/displ

[VOTE] KIP-146: Classloading Isolation in Connect

Hi all, Given that the comments during the discussion seem to have been addressed, I'm pleased to bring KIP-146: Classloading Isolation in Connect https://cwiki.apache.org/confluence/display/KAFKA/KIP-146+-+Classloading+Isolation+in+Connect up for voting. Again, this KIP aims to bring the highly

[VOTE] KIP-146: Isolation of dependencies and classes in Kafka Connect (restarted voting thread)

** Restarting the voting thread here, with a different title to avoid collapsing this thread's messages with the discussion thread's messages in mail clients. Apologies for the inconvenience. ** Hi all, Given that the comments during the discussion seem to have been addressed, I'm pleased to bri

Re: [VOTE] KIP-146: Classloading Isolation in Connect

: > +1 > > On Mon, May 8, 2017 at 11:04 AM, Konstantine Karantasis < > konstant...@confluent.io> wrote: > > > Hi all, > > > > Given that the comments during the discussion seem to have been > addressed, > > I'm pleased to bring > &g

Re: [VOTE] KIP-154 Add Kafka Connect configuration properties for creating internal topics

+1 (non binding) On Mon, May 8, 2017 at 1:33 PM, Stephane Maarek < steph...@simplemachines.com.au> wrote: > +1 (non binding) > > > > On 9/5/17, 5:51 am, "Randall Hauch" wrote: > > Hi, everyone. > > Given the simple and non-controversial nature of the KIP, I would like > to > start th

Re: [DISCUSS] KIP-154 Add Kafka Connect configuration properties for creating internal topics

Thanks a lot for the KIP Randall. This improvement should simplify both regular deployments and testing! A minor comment. Maybe it would be nice to add a note about why there's no need for the property: config.storage.partitions I'm mentioning this for the sake of completeness, in case someone not

Re: [VOTE] KIP-151: Expose Connector type in REST API (first attempt :)

+1 (non-binding) On Mon, May 8, 2017 at 3:39 PM, dan wrote: > i'd like to begin voting on > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > 151+Expose+Connector+type+in+REST+API > > discussion should remain on > http://mail-archives.apache.org/mod_mbox/kafka-dev/201705. > mbox/%3CCAFJy-

Re: [VOTE] KIP-146: Isolation of dependencies and classes in Kafka Connect (restarted voting thread)

es, it is an error). What we are proposing > is > > > quite different and perhaps it may make sense to use a different name > to > > > avoid confusion. > > > > > > Ismael > > > > > > [1] https://www.infoq.com/articles/Latest-Project- > Jigsaw-Us

Re: [VOTE] KIP-146: Isolation of dependencies and classes in Kafka Connect (restarted voting thread)

gin.path` sounds good to me. > > In any case, I will leave it to you all to decide. :) > > Ismael > > On Wed, May 10, 2017 at 8:11 PM, Konstantine Karantasis < > konstant...@confluent.io> wrote: > > > Thank you Ismael for your vote as well as your comment. &

Re: [VOTE] KIP-146: Isolation of dependencies and classes in Kafka Connect (restarted voting thread)

9:54 PM, Konstantine Karantasis < konstant...@confluent.io> wrote: > The KIP description has been updated to reflect the use of the term > plugin.path instead. > > -Konstantine > > > > > On Wed, May 10, 2017 at 2:10 PM, Ismael Juma wrote: > >> Konstan

Re: [DISCUSS] KIP-745: Connect API to restart connector and tasks

Thanks Randall. I reply inline as well. On Sat, Jun 5, 2021 at 1:57 PM Randall Hauch wrote: > Thanks for the review and feedback, Konstantine. I think I've addressed all > of your concerns below. > > On Fri, Jun 4, 2021 at 7:55 PM Konstantine Karantasis > wrote: >

Re: [DISCUSS] KIP-494 Connect REST Endpoint for Transformations (SMTs) and other Plugins

deprecated, though I don't anticipate the need to > > remove it will arise any time soon! > > > > Cyrus > > > > On Fri, Jun 4, 2021 at 7:35 PM Konstantine Karantasis > > wrote: > > > >> Hi Cyrus. > >> > >> The proposal looks goo

Re: [VOTE] KIP-745: Connect API to restart connector and tasks

Thanks Randall. +1 (binding) Konstantine On Mon, Jun 7, 2021 at 12:47 PM Randall Hauch wrote: > Hello all, > > I would like to start a vote on KIP-745: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-745%3A+Connect+API+to+restart+connector+and+tasks > > +1 (binding) from myself. > >

Re: [VOTE] KIP-750: Drop support for Java 8 in Kafka 4.0 (deprecate in 3.0)

Thanks for the KIP Ismael. I agree that giving an early enough deprecation notice for an upcoming change like this one and doing so in a major release is best in this case. +1 (binding) Konstantine On Mon, Jun 7, 2021 at 7:30 AM Ryanne Dolan wrote: > +1 (non-binding) > > Ryanne > > On Mon, Jun

Re: [VOTE] KIP-751: Drop support for Scala 2.12 in Kafka 4.0 (deprecate in 3.0)

+1 (binding) Konstantine On Mon, Jun 7, 2021 at 6:51 AM Josep Prat wrote: > Hi Ismael, > > Good KIP, it's a +1 (non binding) from my side. > > Best, > > ——— > Josep Prat > > Aiven Deutschland GmbH > > Immanuelkirchstraße 26, 10405 Berlin > > Amtsgericht Charlottenburg, HRB 209739 B > > Geschäft

Re: [DISCUSS] KIP-494 Connect REST Endpoint for Transformations (SMTs) and other Plugins

n make the KIP text clearer? Or do you disagree this is the right > move tactically? I thought my text was sufficient: "it will be redundant to > this new, more generally useful endpoint." > > On Mon, Jun 7, 2021 at 12:56 PM Konstantine Karantasis > wrote: > > >

Re: [DISCUSS] KIP-726: Make the CooperativeStickyAssignor as the default assignor

Thanks for the KIP Luke. Looks good overall. Just a few minor suggestions: 1. How about replacing "Note that this change will also propagate to Connect." with -> "Note that this change will also automatically be inherited by sink connectors, like any other application that uses Kafka consumers, a

Re: [DISCUSS] KIP-494 Connect REST Endpoint for Transformations (SMTs) and other Plugins

o move > the PUT endpoint to > > PUT /plugins/connector/{connector-type}/config/validate > > so we don't have to return 400s for all the other types for which > validation is not supported. > > Does that sound good to you? > > > On Mon, Jun 7, 2021 at 4:49 PM Kons

Re: [VOTE] KIP-726: Make the "cooperative-sticky, range" as the default assignor

Thanks for the KIP Luke. +1 (binding) Konstantine On Wed, Jun 9, 2021 at 6:36 AM Luke Chen wrote: > Hi all, > Bump this thread to see if there's anyone wants to vote or have questions. > > Thank you. > Luke > > Sophie Blee-Goldman 於 2021年6月8日 週二 上午4:40 > 寫道： > > > +1 (binding) > > > > Thanks

Re: [VOTE] KIP-390: Support Compression Level (rebooted)

Makes sense. Looks like a good improvement. Thanks for including the evaluation in the proposal Dongjin. +1 (binding) Konstantine On Wed, Jun 9, 2021 at 6:59 PM Dongjin Lee wrote: > Thanks Ismel, Tom and Ryanne, > > I am now updating the KIP about the further works. Sure, You won't be > disapp

Re: [VOTE] KIP-719: Add Log4J2 Appender

+1 (binding) Konstantine On Fri, Jun 11, 2021 at 7:57 AM Boojapho O wrote: > +1 (non-binding) > > On 2021/06/09 15:31:13, Dongjin Lee wrote: > > Bumping up the voting thread. > > > > Please note that today is the KIP freeze day. > > > > Thanks, > > Dongjin > > > > On Mon, Jun 7, 2021 at 9:28 P

Re: [VOTE] KIP-716: Allow configuring the location of the offset-syncs topic with MirrorMaker2

Providing this flexibility makes sense. Thanks Mickael. +1 (binding) Konstantine On Fri, Jun 11, 2021 at 1:31 AM Tom Bentley wrote: > Hi Mickael, > > Thanks for the KIP, +1 (binding). > > Cheers, > > Tom > > On Tue, Apr 13, 2021 at 4:56 PM Mickael Maison > wrote: > > > Hi, > > > > It has been

Re: [DISCUSS] Apache Kafka 3.0.0 release plan with new updated dates

for Feature Freeze. The next milestone for the Apache Kafka 3.0 release is Feature Freeze on June 30th, 2021. Best regards, Konstantine On Fri, Jun 4, 2021 at 3:47 PM Konstantine Karantasis < konstant...@confluent.io> wrote: > > Hi all, > > Just a quick reminder that KIP Freeze is

<    1   2   3   4   >