9, 4:37 PM Randall Hauch wrote:
> >
> > > +1 (binding)
> > >
> > > Great work, Konstantine.
> > >
> > > On Thu, Sep 19, 2019 at 11:50 AM Gwen Shapira
> wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > On Thu, S
gt; >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-444%3A+Augment+metrics+for+Kafka+Streams
> > > > > >>>> >>>>>
> > > > > >>>> >>>>
> > > > > >>>> >>>> - KIP-434: Ad
>
> 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 "topic
> profiles" that we could use here.
>
>
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
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.
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
Hi Manikumar,
let's add one more on the list that was voted on time and is
straightforward:
KIP-521:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-521%3A+Enable+redirection+of+Connect%27s+log4j+messages+to+a+file+by+default
with jira ticket:
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 authorization. It would be good to say so
> >
> > > > > > > > > > On Thu, Feb 27, 2020 at 7:46 AM Matthias J. Sax <
> > > > mj...@apache.org>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > >
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)
> >>>
> >>> Randall
>
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
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
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
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
uary 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:
> >
> > > Thanks!
> correct
> > > >that Connect would report no active topics? And after the tasks
> are
> > > >rebalance, will the worker record any topics used by connector A?
> > > >6. In the "Restaring" (misspelled) section: "Reconfiguring a
> sou
; connector
> > > > >writes to no new topics, before the tasks are rebalanced then is
> > it
> > > > correct
> > > > >that Connect would report no active topics? And after the tasks
> > are
> > > > >rebal
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:
> >
> >>
> >> 9. I assumed that partitioning is
ct 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
> first scenario I outlined would become possible; if not,
ive 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
/connectors/{name}/config endpoint
In this case, the reset will be a compl
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:
>>
>> > > 2. What is the motiva
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:
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
. IIUC,
> the
> > > > first
> > > > > > "task"
> > > > > > >mentioned is the connector's task, and the second is the
> > > worker's
> > > > > > task. Do
> > > > > > >we need to distinguish this more clearly
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 on KIP-158
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 comments, I'm replying
rker 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.
> >
> >
> > Otherwise, this KI
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
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
dwide,
> > > including
> > > > > Capital One, Goldman Sachs, ING, LinkedIn, Netflix, Pinterest,
> > > Rabobank,
> > > > > Target, The New York Times, Uber, Yelp, and Zalando, among others.
> > > > >
> > > > > A big thank you fo
Hi Sanjana and thanks for the KIP!
Sorry for the late response, but I still have a few questions that you
might find useful.
The KIP currently does not mention Kafka Connect at all. I have read
the discussion above where it'd been decided to leave Connect and Streams
out of the proposed changes,
Hi Sanjana.
Thanks for the KIP! Seems quite useful not to overwhelm the brokers with
the described requests from clients.
You have the votes already, and I'm also in favor overall, but I've made a
couple of questions (sorry for the delay) regarding Connect, which is also
using retry.backoff.ms
tually do need both configs, with retry.backkoff.ms <
> retry.backoff.max.ms. I will update the KIP to reflect that as well as
> incorporate the wording change you have suggested.
>
> Thanks,
> Sanjana
>
> On Mar 25, 2020, 10:50 AM -0700, Konstantine Karantasis <
> kon
n Mar 25, 2020, 10:52 AM -0700, Konstantine Karantasis <
> konstant...@confluent.io>, wrote:
> > Hi Sanjana.
> > Thanks for the KIP! Seems quite useful not to overwhelm the brokers with
> > the described requests from clients.
> >
> > You have the votes alrea
Thanks for the KIP Randall!
Automatic creation of internal Connect topics has been very useful since
KIP-154 and adapting the Connect workers to allow users to transparently
use broker defaults will be useful as well.
The KIP looks good.
Konstantine
On Sun, May 3, 2020 at 10:55 AM Christopher
I agree with the motivation of this KIP. I think it will enrich the
capabilities of source connectors in a quite meaningful way.
I'm +1 as well (binding).
P.S. Randall I like your idea of enabling connectors to run in old as well
as new workers after this KIP. However I think that such
sting
> 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!
>
> BTW, we've agreed upon a number of other changes, but I don't see any of
&g
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 Konstantine Karantasis <
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, adding operational burdens and yet provide a clean
> > > contract?
> > >
t
> > >> 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
> > >> > expect folks to make changes over aesthetic
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
This KIP falls in the category of necessary and straightforward KIPs.
Thanks for the nice write-up Randall.
+1 (binding)
Konstantine
On Mon, May 11, 2020 at 8:00 AM Randall Hauch wrote:
> Ping for reviewers.
>
> I guess I never voted, so +1 (binding).
>
> On Thu, May 7, 2020 at 4:13 PM
The proposal makes sense. Thanks for working on this Mario.
+1 (binding)
Konstantine
On Wed, May 6, 2020 at 1:59 PM Randall Hauch wrote:
> Thanks for putting this KIP together, Mario.
>
> +1 (binding)
>
> Randall
>
> On Mon, Apr 27, 2020 at 2:05 PM Mario Molina wrote:
>
> > Hi all,
> >
> >
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 <
konst
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
+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:
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
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,
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
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
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
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
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
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
+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
Congrats, David!
Konstantine
On Fri, Oct 16, 2020 at 3:36 PM Ismael Juma wrote:
> Congratulations David!
>
> Ismael
>
> On Fri, Oct 16, 2020 at 9:01 AM Gwen Shapira wrote:
>
> > The PMC for Apache Kafka has invited David Jacot as a committer, and
> > we are excited to say that he accepted!
>
Congratulations, Sophie!
Konstantine
On Mon, Oct 19, 2020 at 6:33 PM Luke Chen wrote:
> Congratulations, Sophie!
> You always provide good review comments for my PRs.
> Well deserved!
>
> Luke
>
> On Tue, Oct 20, 2020 at 9:23 AM Rankesh Kumar wrote:
>
> > Many congratulations, Sophie.
> >
> >
Congrats, Chia-Ping!
Konstantine
On Mon, Oct 19, 2020 at 6:23 PM Rankesh Kumar wrote:
> Many congratulations, Chia-Ping!
>
> Best regards,
> Rankesh
>
> > On 20-Oct-2020, at 6:45 AM, Luke Chen wrote:
> >
> > Congratulations! Chia-Ping大大!
> > Well deserved!
> >
> > Luke
> >
> > On Tue, Oct 20,
Hi Tess,
I've seen the issue and the PR.
I'll send a review soon.
Thanks for surfacing this issue!
Konstantine
On Wed, Aug 26, 2020 at 8:19 AM Tess D'erberwill
wrote:
> Hi, guys!
> Please, take a look at my ticket and PR:
> https://issues.apache.org/jira/browse/KAFKA-10426
>
> This is my
ra Rodoni, Andras Katona, Andrew Olson, Andy Coates,
> > > Aneel Nazareth, Anna Povzner, Antony Stubbs, Arjun Satish, Auston,
> > avalsa,
> > > Badai Aqrandista, belugabehr, Bill Bejeck, Bob Barrett, Boyang Chen,
> > Brian
> > > Bushree, Brian Byrne, Bruno Cadonna,
A bit late on this thread, but I've reviewed the KIP and I'm also +1.
Thanks Tom. Happy to see this improvement making it in.
Konstantine
On Thu, Aug 6, 2020 at 10:27 AM Tom Bentley wrote:
> With 3 binding +1 (Manikumar, Mickael and Rajini) and 2 non-binding +1
> (David and William) the vote
Congrats, John!
-Konstantine
On Mon, Aug 10, 2020 at 4:53 PM Gwen Shapira wrote:
> Congratulations, John!
>
> On Mon, Aug 10, 2020, 1:11 PM Jun Rao wrote:
>
> > Hi, Everyone,
> >
> > John Roesler has been a Kafka committer since Nov. 5, 2019. He has
> remained
> > active in the community
Congratulations Mickael!
-Konstantine
On Fri, Jul 31, 2020 at 2:27 PM Ning Zhang wrote:
> Congrats Mickael !
>
> On 2020/07/31 15:14:30, Jun Rao wrote:
> > Hi, Everyone,
> >
> > Mickael Maison has been a Kafka committer since Nov. 5, 2019. He has
> > remained active in the community since
Congrats, Boyang!
-Konstantine
On Mon, Jun 22, 2020 at 9:19 PM Navinder Brar
wrote:
> Many Congratulations Boyang. Very well deserved.
>
> Regards,Navinder
>
> On Tuesday, 23 June, 2020, 07:21:23 am IST, Matt Wang
> wrote:
>
> Congratulations, Boyang!
>
>
> --
>
> Best,
> Matt Wang
>
>
>
Congrats Xi!
-Konstantine
On Sat, Jun 27, 2020 at 7:13 PM Matt Wang wrote:
> Congratulations ~
>
>
> --
>
> Best,
> Matt Wang
>
>
> On 06/26/2020 23:06，David Jacot wrote：
> Congrats!
>
> On Thu, Jun 25, 2020 at 4:08 PM Hu Xi wrote:
>
> Thank you, everyone. It is my great honor to be a part of
+1 (binding)
On Fri, Jun 26, 2020 at 3:10 AM Benny Lee wrote:
>
>
>
> From: Tom Bentley
> Sent: Friday, 26 June 2020 7:45 PM
> To: dev@kafka.apache.org
> Subject: Re: [VOTE] KIP-629: Use racially neutral terms in our codebase
>
> +1 (non-binding)
>
> On Fri,
uot;
> 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 Dolan
> > wrote:
>
Added to both.
Thanks for joining Lev!
-Konstantine
On Thu, Dec 10, 2020 at 11:57 AM Lev Zemlyanov wrote:
> Hi,
>
> Please add me as a contributor in Kafka JIRA board and Confluence Wiki. My
> JIRA Id is levzemlyanov. My Confluence ID is lev.
>
> Thanks, Lev
>
>
Thanks for your interest Daniel.
Added.
-Konstantine
On Thu, Dec 10, 2020 at 2:34 PM Daniel Osvath wrote:
> Hi,
>
> Please add me as a contributor to the Kafka JIRA board and Confluence
> Wiki. My JIRA ID is dosvath. My Confluence ID is dosvath.
>
> Thanks,
>
> Daniel
>
>
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
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
+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
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
re 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 next Wedn
24 hour default of grace period in Streams
> Please could you include it?
>
> Voting has already concluded a long time ago
>
>
>
> On Mon, Jun 14, 2021 at 6:08 PM Konstantine Karantasis
> wrote:
>
> > Hi all.
> >
> > KIP Freeze for the next major release of A
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,
o
>
> 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 Konstantine Karantasis
> wrote:
>
eprecated, 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 good and I li
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:
>
>
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.
>
>
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,
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:
>
> > Thanks for th
+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
>
>
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
>
Kafka
> Streams
>
> will not be ready for 3.0, so you can remove it from the list.
>
> Best,
> Bruno
>
> On 15.06.21 07:33, Konstantine Karantasis wrote:
> > Done. Moved it into the table of Adopted KIPs targeting 3.0.0 and to the
> > release plan of course
Congratulations Konstantine!
> >>>>>>>
> >>>>>>> On Mon, Jun 21, 2021 at 9:37 AM Tom Bentley
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> Congratulations Konstantine!
> >>>>>>>>
&g
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)
> >
> >
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
iki 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:
> >
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:
t; +1 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:
> > >
> > > > Thanks Ko
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
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
+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
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
ains 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-appender plan but also upgr
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
t;
>- 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 Karantasis
&
the 4th of July holiday in the US, the 3.0 release branch will appear
sometime on Tuesday, July 6th.
Until then, please keep merging to trunk only the changes you intend to
include in Apache Kafka 3.0.
Regards,
Konstantine
On Wed, Jun 30, 2021 at 3:25 PM Konstantine Karantasis <
konst
t; > ready for review for 2 weeks, and I simply want to make sure there is
> > enough time to address any possible changes that might be requested.
> >
> > Thanks in advance and sorry for any inconvenience caused,
> > --
> > Josep
> > On Mon, Jun 21, 2021 at 11:54 PM
101 - 200 of 392 matches
Mail list logo
