Hi Jincheng,
+1 I would be for a 1.8.2 release such that we can fix the problems with
the nested closure cleaner which currently block 1.8.1 users with Beam:
https://issues.apache.org/jira/browse/FLINK-13367
Thanks,
Max
On 30.08.19 11:25, jincheng sun wrote:
Hi Flink devs,
It has been near
I'm also late to the party here :) When I saw the first draft, I was
thinking how exactly the design doc would tie in with Beam. Thanks for
the update.
A couple of comments with this regard:
Flink has provided a distributed cache mechanism and allows users to upload their files using
"regist
+1 (binding)
On 25.10.19 14:31, Congxian Qiu wrote:
+1 (non-biding)
Best,
Congxian
Terry Wang 于2019年10月24日周四 上午11:15写道：
+1 (non-biding)
Best,
Terry Wang
2019年10月24日 10:31，Jingsong Li 写道：
+1 (non-binding)
Best,
Jingsong Lee
On Wed, Oct 23, 2019 at 9:02 PM Yu Li wrote:
+1 (non-bin
.
Thanks again for your feedback, and it is valuable for find out the
final
best architecture.
Feel free to correct me if there is anything incorrect.
Best,
Jincheng
Maximilian Michels 于2019年10月16日周三 下午4:23写道：
I'm also late to the party here :) When I saw the first draft, I
was
think
+1
On Mon, Jul 17, 2023 at 10:45 AM Chesnay Schepler wrote:
>
> +1
>
> On 16/07/2023 08:10, Mohan, Deepthi wrote:
> > @Chesnay
> >
> > Thank you for your feedback.
> >
> > An important takeaway from the previous discussion [1] and your feedback
> > was to keep the design and text/diagram changes
+1
On Tue, Jul 18, 2023 at 12:29 PM Gyula Fóra wrote:
>
> +1
>
> On Tue, 18 Jul 2023 at 12:12, Xintong Song wrote:
>
> > +1
> >
> > Best,
> >
> > Xintong
> >
> >
> >
> > On Tue, Jul 18, 2023 at 4:25 PM Chesnay Schepler
> > wrote:
> >
> > > The endpoint hasn't been working for years and was only
Hi Chesnay,
+1 Sounds good to me!
-Max
On Tue, Jul 18, 2023 at 10:59 AM Chesnay Schepler wrote:
>
> MetricGroup#getAllVariables returns all variables associated with the
> metric, for example:
>
> | = abcde|
> | = ||0|
>
> The keys are surrounded by brackets for no particular reason.
>
> In vir
Hi Daren,
The behavior is consistent with the regular FlinkDeployment where the
cleanup will also cancel any running jobs. Are you intending to
recover jobs from another session cluster?
-Max
On Mon, Jul 17, 2023 at 4:48 PM Wong, Daren
wrote:
>
> Hi devs,
>
> I would like to enquire about the c
+1 (binding)
1. Downloaded the source and helm archives, checksums, and signatures
2. Verified the signatures and checksums
3. Extract and inspect the source code for binaries
4. Compiled and tested the source code via mvn verify
5. Verified license files / headers
6. Deployed helm chart to test c
Hi Rui,
Thanks for the proposal. I think it makes a lot of sense to decouple
the autoscaler from Kubernetes-related dependencies. A couple of notes
when I read the proposal:
1. You propose AutoScalerEventHandler, AutoScalerStateStore,
AutoScalerStateStoreFactory, and AutoScalerEventHandler.
Autos
d release helm chart, docker image
> - Verified doc build, links
> - Ran basic stateful example, upgrade, savepoint. Checked logs, no errors
>
> Gyula
>
> On Mon, Jul 31, 2023 at 2:24 PM Maximilian Michels wrote:
>
> > +1 (binding)
> >
> > 1. Downloaded th
Congrats, well done, and welcome to the PMC Matthias!
-Max
On Tue, Aug 8, 2023 at 8:36 AM yh z wrote:
>
> Congratulations, Matthias!
>
> Best,
> Yunhong Zheng (Swuferhong)
>
> Ryan Skraba 于2023年8月7日周一 21:39写道：
>
> > Congratulations Matthias -- very well-deserved, the community is lucky to
> > h
+1 (binding)
-Max
On Tue, Aug 8, 2023 at 10:56 AM Etienne Chauchot wrote:
>
> Hi all,
>
> As part of Flink bylaws, binding votes for FLIP changes are active
> committer votes.
>
> Up to now, we have only 2 binding votes. Can one of the committers/PMC
> members vote on this FLIP ?
>
> Thanks
>
>
+1 (binding)
1. Downloaded the archives, checksums, and signatures
2. Verified the signatures and checksums
3. Extract and inspect the source code for binaries
4. Compiled and tested the source code via mvn verify
5. Verified license files / headers
6. Deployed helm chart to test cluster
7. Ran ex
Hi Gyula,
+1 The proposed changes make sense and are in line with what is
available for other metrics, e.g. number of records processed.
-Max
On Tue, Sep 5, 2023 at 2:43 PM Gyula Fóra wrote:
>
> Hi Devs,
>
> I would like to start a discussion on FLIP-361: Improve GC Metrics [1].
>
> The current
gt; handlerScalingFailure/handlerScalingReport (one of the
>> handles the event of scale failure, and the other handles
>> the event of scale success).
>>
>>
>>
>> --
>>
>> Best,
>> Matt Wang
>>
>>
>> Replied Message
>
Sep 5, 2023 at 8:13 AM Gyula Fóra wrote:
> >
> > > Hi All!
> > >
> > > @Maximilian Michels has raised the question of Flink
> > > version support in the operator before the last release. I would like to
> > > open this discussion pu
aise a pull request
> > (PR) for YARN as well.
> >
> > Our initial approach was to create a decoupled interface as part of
> > FLIP-334 and then implement it for YARN in the subsequent phase.
> > However, if you recommend combining both phases, we can certainly consi
+1 (binding)
On Wed, Sep 13, 2023 at 12:28 PM Gyula Fóra wrote:
>
> +1 (binding)
>
> Gyula
>
> On Wed, 13 Sep 2023 at 09:33, Matt Wang wrote:
>
> > Thank you for driving this FLIP,
> >
> > +1 (non-binding)
> >
> >
> > --
> >
> > Best,
> > Matt Wang
> >
> >
> > Replied Message
> > | Fro
+1 (binding)
On Thu, Sep 14, 2023 at 4:26 AM Venkatakrishnan Sowrirajan
wrote:
>
> +1 (non-binding)
>
> On Wed, Sep 13, 2023, 6:55 PM Matt Wang wrote:
>
> > +1 (non-binding)
> >
> >
> > Thanks for driving this FLIP
> >
> >
> >
> >
> > --
> >
> > Best,
> > Matt Wang
> >
> >
> > Replied Messa
Hey Rui,
+1 for making exponential backoff the default. I agree with Konstantin
that retrying forever is a good default for exponential backoff
because oftentimes the issue will resolve eventually. The purpose of
exponential backoff is precisely to continue to retry without causing
too much load.
+1 (binding)
1. Downloaded the archives, checksums, and signatures
2. Verified the signatures and checksums ( gpg --recv-keys
B2D64016B940A7E0B9B72E0D7D0528B28037D8BC )
3. Extract and inspect the source code for binaries
4. Compiled and tested the source code via mvn verify
5. Verified license fil
Have a great time off, Etienne!
On Thu, Oct 26, 2023 at 3:38 PM Etienne Chauchot wrote:
>
> Hi,
>
> FYI, I'll be off and unresponsive for a week starting tomorrow evening.
> For ongoing work, please ping me before tomorrow evening or within a week
>
> Best
>
> Etienne
+1 for targeting the release as soon as possible. Given the effort
that Rui has undergone to decouple the autoscaling implementation, it
makes sense to also include an alternative implementation with the
release. In the long run, I wonder whether the standalone
implementation should even be part of
Hi Mason,
Thank you for the proposal. This is a highly requested feature to make
the source scaling of Flink Autoscaling generic across all sources.
The current implementation handles every source individually, and if
we don't find any backlog metrics, we default to using busy time only.
At this p
Hi Stephan,
This is excited! Thanks for sharing. The inter-process communication
code looks like the most natural choice as a common ground. To go
further, there are indeed some challenges to solve.
=> Biggest question is whether the language-independent DAG is expressive
enough to capture
Apart from a technical explanation, the initial suggestion does not propose how
the repository should be split up. The only meaningful split I see is for the
connectors.
This discussion dates back a few years:
https://lists.apache.org/thread.html/4ee502667a5801d23d76a01406e747e1a934417dc67ef7d2
I'm a bit late to the discussion here. Three suggestions:
1) Procedure for "insufficient active binding voters to reach 2/3 majority
> 1. Wait until the minimum length of the voting passes.
> 2. Publicly reach out to the remaining binding voters in the voting mail
> thread for at least 2
t; expect an important action like this to require a 2/3 majority.
>>
>> Personally I think consensus is good enough here. PMC members can cast a
>> veto if they disagree about the removal. In some sense, it is more
>> difficult than with 2/3 majority to remove a committer / PMC
+1 It's good that we formalize this.
On 13.08.19 10:41, Fabian Hueske wrote:
> +1 for the proposed bylaws.
> Thanks for pushing this Becket!
>
> Cheers, Fabian
>
> Am Mo., 12. Aug. 2019 um 16:31 Uhr schrieb Robert Metzger <
> rmetz...@apache.org>:
>
> > I changed the permissions of the page.
> >
>
>>
> >> > How well has the adaptive scheduler been tested in production? If we
> >> are intending to use it for rescale operations, I'm a bit concerned
> >> those jobs might show different behavior due to the scheduling than jobs
> >> started with
Hi David,
This is awesome! Great writeup and demo. This is pretty much what we
need for the autoscaler as part of the Flink Kubernetes operator [1].
Scaling Flink jobs effectively is hard but fortunately we have solved
the issue as part of the Flink Kubernetes operator. The only critical
piece we
ulfil the new resource requirements. So this may not be
100% what we need but it could be extended to do what we want.
-Max
[1] https://github.com/apache/flink/pull/21908#discussion_r1104792362
On Mon, Feb 13, 2023 at 7:16 PM Maximilian Michels wrote:
>
> Hi David,
>
> This is aweso
+1
On Wed, Feb 15, 2023 at 12:32 PM Danny Cranmer wrote:
>
> Hi all,
>
> I would like to discuss creating a new 1.15 patch release (1.15.4). The
> last 1.15 release is over three months old, and since then, 43 tickets have
> been closed [1], of which 13 are blocker/critical [2]. Given that Flink
ded, restart the job
C) Less resources available than required => Acquire new task
managers, wait for them to register, cancel and restart the job
I'm open to helping out with the implementation.
-Max
On Mon, Feb 13, 2023 at 7:45 PM Maximilian Michels wrote:
>
> Based on furthe
+1 (binding)
1. Downloaded the archives, checksums, and signatures
2. Verified the signatures and checksums
3. Extract and inspect the source code for binaries
4. Compiled and tested the source code via mvn verify
5. Verified license files / headers
6. Deployed helm chart to test cluster
7. Ran ex
Hi Samrat,
The autoscaling module is now pluggable but it is still tightly
coupled with Kubernetes. It will take additional work for the logic to
work independently of the cluster manager.
-Max
On Thu, Feb 16, 2023 at 11:14 AM Samrat Deb wrote:
>
> Oh! yesterday it got merged.
> Apologies , I m
7;t have the bigger picture of other
> tasks of other jobs running on those TMs. This will most likely be a topic
> for another FLIP.
>
> WDYT? If there are no other questions or concerns, I'd like to start the vote
> on Wednesday.
>
> Best,
> D.
>
> On Wed, Feb
> > On Thu, Feb 16, 2023 at 3:12 PM Samrat Deb <
> > decordea...@gmail.com>
> > wrote:
> >
> > Hi Shammon,
> >
> > Thank you for your input, completely aligned with you.
> >
> > We are fine with either of the options ,
> >
> > but IM
-0 for a redesign. I might be the only one but I like the current
simple design. I find it quite elegant. Apache projects do not tend to
have fancy websites. That's ok. If you consider the AWS pages, they
are far from being modern or beautiful.
A redesign often is appealing but it can take a huge
Congrats Rui! Well done!!
-Max
On Tue, Feb 21, 2023 at 10:09 AM Roman Khachatryan wrote:
>
> Congratulations Rui!
>
> Regards,
> Roman
>
>
> On Mon, Feb 20, 2023 at 5:58 PM Anton Kalashnikov
> wrote:
>
> > Congrats Rui!
> >
> > --
> > Best regards,
> > Anton Kalashnikov
> >
> > On 20.02.23 17:5
+1
On Tue, Feb 21, 2023 at 11:07 AM Martijn Visser
wrote:
>
> Hi all,
>
> +1 for this change. I see it as the responsibility of the community to make
> one more bugfix release available which for me is clear from the proposed
> text.
>
> Best regards,
>
> Martijn
>
> On Tue, Feb 21, 2023 at 10:08
Congrats! Great work. This was a long time in the making!
-Max
On Thu, Feb 23, 2023 at 3:28 PM Martijn Visser wrote:
>
> Hi everyone,
>
> The project website at https://flink.apache.org is now powered by Hugo [1]
> which is the same system as the documentation.
>
> The theme is the same as the d
7;d also be against creating a "committee" at this time,
> because that just makes it imo more likely that this will be handled as
> an all-or-nothing/waterfall kind of thing.
>
> On 21/02/2023 11:31, Maximilian Michels wrote:
> > -0 for a redesign. I might
!
> >> -John
> >>
> >> On Mon, Feb 20, 2023, at 07:34, Matthias Pohl wrote:
> >> > Thanks for your clarifications, David. I don't have any additional major
> >> > points to add. One thing about the FLIP: The RPC layer API for updating
> >
escaling behaviour and
> > the desired parallelism declaration is important.
> >
> > Having the ability to specify min parallelism might be useful in
> > environments with multiple jobs: Scheduler will then have an option to stop
> > the less suitable job.
> &g
+1 on the proposal.
I'm wondering about the scale down behavior of the unified
implementation. Does the new unified implementation prioritize
releasing entire task managers in favor of evenly spreading out task
managers? Consider a scale down from parallelism 15 to parallelism 10
where each task m
+1 (binding)
On Mon, Mar 13, 2023 at 11:33 AM Etienne Chauchot wrote:
>
> +1 (not binding)
>
> Etienne
>
> Le 11/03/2023 à 07:37, Yangze Guo a écrit :
> > +1 (binding)
> >
> > Zhanghao Chen 于 2023年3月10日周五 下午5:07写道：
> >
> >> Thanks Weihua. +1 (non-binding)
> >>
> >> Best,
> >> Zhanghao Chen
> >>
Thanks for driving the release Gordon!
-Max
On Fri, Apr 21, 2023 at 12:33 AM Tzu-Li (Gordon) Tai
wrote:
>
> We have unanimously approved this release.
>
> There are 6 approving votes, 3 of which are binding:
>
> * Alexander Sorokoumov
> * Martijn Visser (binding)
> * Tzu-Li (Gordon) Tai (binding
+1
On Tue, Apr 25, 2023 at 5:24 PM David Morávek wrote:
>
> Hi Eric,
>
> this sounds reasonable, there are definitely cases where you need to limit
> sink parallelism for example not to overload the storage or limit the
> number of output files
>
> +1
>
> Best,
> D.
>
> On Sun, Apr 23, 2023 at 1:
If we ban Mockito imports, I can still write tests using the full
qualifiers, right?
For example:
org.mockito.Mockito.when(somethingThatShouldHappen).thenReturn(somethingThatNeverActuallyHappens)
Just kidding, +1 on the proposal.
-Max
On Wed, Apr 26, 2023 at 9:02 AM Panagiotis Garefalakis
Thanks for starting the discussion, Jark and Xingtong!
Flink 2.0 is long overdue. In the past, the expectations for such a
release were unreasonably high. I think everybody had a different
understanding of what exactly the criteria were. This led to releasing
18 minor releases for the current majo
+1 (binding)
1. Downloaded the archives, checksums, and signatures
2. Verified the signatures and checksums
3. Extract and inspect the source code for binaries
4. Verified license files / headers
5. Compiled and tested the source code via mvn verify
6. Deployed helm chart to test cluster
7. Ran ex
Niceee. Thanks for managing the release, Gyula!
-Max
On Wed, May 17, 2023 at 8:25 PM Márton Balassi wrote:
>
> Thanks, awesome! :-)
>
> On Wed, May 17, 2023 at 2:24 PM Gyula Fóra wrote:
>>
>> The Apache Flink community is very happy to announce the release of Apache
>> Flink Kubernetes Operato
+1 (binding)
1. Downloaded the archives, checksums, and signatures
2. Verified the signatures and checksums
3. Extract and inspect the source code for binaries
4. Compiled and tested the source code via mvn verify
5. Verified license files / headers
6. Deployed helm chart to test cluster
7. Build
Thanks for reviving the efforts here Matthias! +1 for the transition
to GitHub Actions.
As for ASF Infra Jenkins, it works fine. Jenkins is extremely
feature-rich. Not sure about the spare capacity though. I know that
for Apache Beam, Google donated a bunch of servers to get additional
build capac
+1 (binding)
-Max
On Thu, Nov 30, 2023 at 9:15 AM Rui Fan <1996fan...@gmail.com> wrote:
>
> +1(binding)
>
> Best,
> Rui
>
> On Mon, Nov 13, 2023 at 11:01 AM Rui Fan <1996fan...@gmail.com> wrote:
>
> > Hi everyone,
> >
> > Thank you to everyone for the feedback on FLIP-364: Improve the
> > restart
Thank you Rui for driving this!
On Thu, Nov 30, 2023 at 3:01 AM Rui Fan <1996fan...@gmail.com> wrote:
>
> The Apache Flink community is very happy to announce the release of
> Apache Flink 1.16.3, which is the
> third bugfix release for the Apache Flink 1.16 series.
>
>
>
> Apache Flink® is an ope
Hey Rui,
+1 for changing the default restart strategy to exponential-delay.
This is something all users eventually run into. They end up changing
the restart strategy to exponential-delay. I think the current
defaults are quite balanced. Restarts happen quickly enough unless
there are consecutive
;
> Looking forward to your feedback, thanks~
>
> [1] https://github.com/apache/flink/pull/23247#discussion_r1422626734
> [2]
> https://github.com/apache/flink/assets/38427477/642c57e0-b415-4326-af05-8b506c5fbb3a
> [3] https://issues.apache.org/jira/browse/FLINK-33736
>
> Bes
+1 (binding)
On Tue, Dec 12, 2023 at 2:23 PM Peter Huang wrote:
>
> +1 Non-binding
>
>
> Peter Huang
>
> Őrhidi Mátyás 于2023年12月12日 周二下午9:14写道：
>
> > +1
> > Matyas
> >
> > On Mon, Dec 11, 2023 at 10:26 PM Gyula Fóra wrote:
> >
> > > +1
> > >
> > > Gyula
> > >
> > > On Mon, Dec 11, 2023 at 1:26 P
Hi Rui,
+1 for removing the @Deprecated annotation from `getString(String key,
String defaultValue)`. I would remove the other typed variants with
default values but I'm ok with keeping them if they are still used.
-Max
On Wed, Dec 13, 2023 at 4:59 AM Rui Fan <1996fan...@gmail.com> wrote:
>
> Hi
> Anyone for pushing my pub key to apache dist ?
Done.
On Thu, Dec 21, 2023 at 2:36 PM Etienne Chauchot wrote:
>
> Hello,
>
> All the ongoing PRs on this repo were merged. But, I'd like to leave
> some more days until feature freeze in case someone had a feature ready
> to integrate.
>
> Let' pu
Happy New Year everyone,
I'd like to start the year off by announcing Alexander Fedulov as a
new Flink committer.
Alex has been active in the Flink community since 2019. He has
contributed more than 100 commits to Flink, its Kubernetes operator,
and various connectors [1][2].
Especially notewort
x27;s unexpected IIUC.
>> Would you like to fix it?
>>
>> Feel free to create a FLINK JIRA to fix it if you would like to, and I'm
>> happy to
>> review!
>>
>> And cc @Maximilian Michels
>>
>> Best,
>> Rui
>>
&g
+1 (binding)
On Wed, Jan 10, 2024 at 11:22 AM Martijn Visser
wrote:
>
> +1 (binding)
>
> On Wed, Jan 10, 2024 at 4:43 AM Xingbo Huang wrote:
> >
> > +1 (binding)
> >
> > Best,
> > Xingbo
> >
> > Dian Fu 于2024年1月10日周三 11:35写道：
> >
> > > +1 (binding)
> > >
> > > Regards,
> > > Dian
> > >
> > > On
+1 (binding)
On Fri, Jan 26, 2024 at 6:03 AM Rui Fan <1996fan...@gmail.com> wrote:
>
> +1(binding)
>
> Best,
> Rui
>
> On Fri, Jan 26, 2024 at 11:55 AM Xuyang wrote:
>
> > +1 (non-binding)
> >
> >
> > --
> >
> > Best！
> > Xuyang
> >
> >
> >
> >
> >
> > 在 2024-01-26 10:12:34，"Hang Ruan" 写
- Inspected the source for licenses and corresponding headers
- Checksums and signature OK
+1 (binding)
On Tue, Jan 23, 2024 at 4:08 PM Etienne Chauchot wrote:
>
> Hi everyone,
>
> Please review and vote on the release candidate #1 for the version
> 1.1.0, as follows:
>
> [ ] +1, Approve the rel
+1 (binding)
- Inspected source release (checked license, headers, no binaries)
- Verified checksums and signature
Cheers,
Max
On Sun, Feb 4, 2024 at 5:41 AM Qingsheng Ren wrote:
>
> Thanks for driving this, Martijn!
>
> +1 (binding)
>
> - Verified checksum and signature
> - Verified no binarie
fixes and improvements to both the operator and the
> > autoscaler logic.
> >
> > There are a few outstanding PRs currently, including some larger features
> > for the Autoscaler (JDBC event handler, Heap tuning), we have to make a
> > decision regarding those as well
committers (or other
>> contributors) in the operator release process so that we have some fresh
>> eyes on the process.
>> Would anyone be interested in volunteering to help with the next release?
>>
>> Cheers,
>> Gyula
>>
>> On Tue, Feb 6, 2024 at 4:
SCUSS]` thread and FLIP doc. Please let me know if there are any
> > > concerns.
> > >
> > > Best,
> > > Mason
> > >
> > > On Mon, Jan 29, 2024 at 5:32 AM Thomas Weise wrote:
> > >
> > >> +1 (binding)
> > I can volunteer to be a release manager. I haven't done it for
> > Apache/Flink or the operator before so I may be a good candidate.
> >
> > Ryan van Huuksloot
> > Sr. Production Engineer | Streaming Platform
> > [image: Shopify]
> > <http
I'm a bit torn on this idea. On the one hand, it makes sense to thank
sponsors and entities who have supported Flink in the past. On other
hand, this list is bound to be incomplete and maybe also biased, even
if not intended to be so. I think the power of open-source comes from
the unconditional do
+1 (binding)
Max
On Thu, Feb 29, 2024 at 4:24 AM Hang Ruan wrote:
>
> +1 (non-binding)
>
> Best,
> Hang
>
> weijie guo 于2024年2月29日周四 09:55写道：
>
> > +1 (binding)
> >
> > Best regards,
> >
> > Weijie
> >
> >
> > Feng Jin 于2024年2月29日周四 09:37写道：
> >
> > > +1 (non-binding)
> > >
> > > Best,
> > >
The FLIP mentions: "The contents described in this FLIP are all new
APIs and do not involve compatibility issues."
In this thread it looks like the plan is to remove the old state
declaration API. I think we should consider keeping the old APIs to
avoid breaking too many jobs. The new APIs will st
thank working
> > > > > hours or contributions from individual volunteers which I think
> > > > > is recognized in other ways
> > > > > (e.g., credit of committer and PMC member).
> > > > >
> > > > > Best,
> > > > &g
Hi Kevin,
Theoretically, as long as you move over all k8s resources, failover
should work fine on the Flink and Flink Operator side. The tricky part
is the handover. You will need to backup all resources from the old
cluster, shutdown the old cluster, then re-create them on the new
cluster. The op
Hey everyone,
I don't see any immediate blockers, so I'm going to start the release process.
Thanks,
Max
On Tue, Feb 20, 2024 at 8:55 PM Maximilian Michels wrote:
>
> Hey Rui, hey Ryan,
>
> Good points. Non-committers can't directly release but they can assist
>
Hi everyone,
Please review and vote on the release candidate #1 for the version
1.8.0 of the Apache Flink Kubernetes Operator, as follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)
**Release Overview**
As an overview, the release consists
.memory.tuning.enabled: "true"
> > - Download Autoscaler standalone: wget
> >
> > https://repository.apache.org/content/repositories/orgapacheflink-1710/org/apache/flink/flink-autoscaler-standalone/1.8.0/flink-autoscaler-standalone-1.8.0.jar
> > - Ran Autoscaler standalone
./flink-autoscaler-standalone/dependency-reduced-pom.xml though
> > > - Verified that chart and appVersion matches the target release (91d67d9)
> > > - Verified that Helm chart can be installed from the local Helm folder
> > > without overriding any parameters
&
The vote is now closed.
I'm happy to announce that we have unanimously approved this release.
There are 6 approving votes, 3 of which are binding:
* Gyula Fora (binding)
* Marton Balassi (binding)
* Maximilian Michels (binding)
* Rui Fan (non-binding)
* Alexander Fedulov (non-binding)
*
The Apache Flink community is very happy to announce the release of
the Apache Flink Kubernetes Operator version 1.8.0.
The Flink Kubernetes Operator allows users to manage their Apache
Flink applications on Kubernetes through all aspects of their
lifecycle.
Release highlights:
- Flink Autotuning
Hey Mason,
I just had a look at the FLIP. If I understand correctly, you are
proposing a very sophisticated way to read from multiple Kafka clusters
/ topics.
I'm wondering whether we can share some of the code of the existing
KafkaSource. I suppose you don't want to modify KafkaSource itsel
+1 (binding) because the source release looks good.
I've verified the following:
1. Downloaded, compiled, and verified the signature of the source release
staged at
https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-1.2.0-rc2/
2. Verified licenses (Not a blocker: the LICENSE f
Turns out the issue with the Helm installation was that I was using
cert-manager 1.9.1 instead of the recommended version 1.8.2. The operator
now deploys cleanly in my local environment.
On Thu, Oct 6, 2022 at 12:34 PM Maximilian Michels wrote:
> +1 (binding) because the source release lo
We've been looking into ways to support programmatic rescaling of job
vertices. This feature is typically required for any type of Flink
autoscaler which does not merely set the default parallelism but adjusts
the parallelisms on a JobVertex level.
We've had an initial discussion here:
https://iss
that the Rescale API will work also without
> the adaptive scheduler (for instance when we are running Flink with the
> Kubernetes Native Integration or in other cases where the adaptive
> scheduler is not supported).
>
> What do you think?
>
> Cheers
> Gyula
>
>
>
&
Congratulations Danny! Well deserved :)
-Max
On Thu, Oct 13, 2022 at 2:40 PM Yang Wang wrote:
> Congratulations Danny!
>
> Best,
> Yang
>
> Hang Ruan 于2022年10月13日周四 10:58写道：
>
> > Congratulations Danny!
> >
> > Best,
> > Hang
> >
> > Yun Gao 于2022年10月13日周四 10:56写道：
> >
> > > Congratulations D
+1
On Thu, Oct 13, 2022 at 12:00 PM Konstantin Knauf wrote:
> +1
>
> Am Do., 13. Okt. 2022 um 10:56 Uhr schrieb Niels Basjes :
>
> > +1
> >
> > On Wed, Oct 12, 2022 at 11:00 PM Martijn Visser <
> martijnvis...@apache.org>
> > wrote:
> >
> > > Hi everyone,
> > >
> > > I would like to open a vote
;> set in the job/configuration.
>>
>> I think it would be fine if a new/revised rescale API were only
>> available in the Adaptive Scheduler (without reactive mode!) for starters.
>> We'd require way more stuff to make this useful for batch workloads.
>>
>>
+1 (binding)
On Mon, Oct 17, 2022 at 6:41 AM Márton Balassi
wrote:
> +1 (binding)
>
> On Mon, Oct 17, 2022 at 3:39 PM Martijn Visser
> wrote:
>
> > Hi everyone,
> >
> > I'm hereby opening a vote for FLIP-265 Deprecate and remove Scala API
> > support. The related discussion can be found here [1
+1 (binding)
On Mon, Oct 24, 2022 at 5:14 PM Xinbin Huang wrote:
> +1 (non-binding)
>
> On Mon, Oct 24, 2022 at 2:54 PM Shqiprim Bunjaku <
> shqiprimbunj...@gmail.com>
> wrote:
>
> > +1 (non-binding)
> >
> > On Mon, Oct 24, 2022 at 8:46 PM Steven Wu wrote:
> >
> > > +1 (non-binding)
> > >
> > >
Thanks for the proposal, Gang! This is indeed somewhat of a bigger change.
The coordinator for sources, as part of FLIP-27, was specifically added to
synchronize the global watermark and to assign splits dynamically. However,
it practically allows arbitrary RPC calls between the task and the job
ma
As far as I know the original authors are not working on this
implementation anymore. Other folks might be able to provide more context.
Instead of rewriting your code to be a native Flink job, would it be an
option for your team to pick up the pull request to port statefun to Flink
1.15?
-Max
O
in Flip 264 to understand. I can add a little bit more
> about how to use the coordinator context in Flip 264 if you think that will
> be helpful.
>
> Thanks!
> Gang
>
>
>
> On Wed, Oct 26, 2022 at 7:25 AM Maximilian Michels wrote:
>
>> Thanks for the proposal, Gang!
t; more details about how to use CoordinatorContextBase and how to define
> ShufflingCoordinator.
>
> Let me know if that cannot solve your concern.
>
> Thanks
> Gang
>
> On Thu, Oct 27, 2022 at 1:31 PM Maximilian Michels wrote:
>
>> Hey Gang,
>>
>> What I'm
n body of the proposal, I add another appendix part just now
> with
> > > more details about how to use CoordinatorContextBase and how to define
> > > ShufflingCoordinator.
> > >
> > > Let me know if that cannot solve your concern.
> > >
> > > T
iotr and Maximilian.
>>>
>>> OperatorCoordinator is marked as @Internal intentionally considering
>>> some existing issues, like consistency between non-source operator and
>>> coordinator on checkpoint. I'm wondering if it is useful to expose a public
>&g
1 - 100 of 820 matches
Mail list logo
