+1 (non-binding)
* Verified versions in the poms
* Built from source
* Verified checksums and signatures
* Started basic workloads with kubernetes operator
* Verified NOTICE and LICENSE files
G
On Thu, Jan 26, 2023 at 2:28 PM Dawid Wysakowicz
wrote:
> +1 (binding)
>
>- verified checksums
Biao Liu created FLINK-30799:
Summary: Make SinkFunction support speculative execution for batch
jobs
Key: FLINK-30799
URL: https://issues.apache.org/jira/browse/FLINK-30799
Project: Flink
Biao Liu created FLINK-30798:
Summary: Make OutputFormat support speculative execution for batch
jobs
Key: FLINK-30798
URL: https://issues.apache.org/jira/browse/FLINK-30798
Project: Flink
Martijn Visser created FLINK-30797:
--
Summary: Bump json5 from 1.0.1 to 1.0.2 in
Key: FLINK-30797
URL: https://issues.apache.org/jira/browse/FLINK-30797
Project: Flink
Issue Type: Technical
+1 (non-binding)
* verified hashes and signatures
* verified versions in pom files
* verified LICENSE and NOTICE files
* compared sources against git tag
* built from sources
On Thu, Jan 26, 2023 at 3:08 PM Konstantin Knauf wrote:
> +1 (binding)
>
> * checked Maven and source artifact
Hi Gyula,
> can you please explain why the AdaptiveScheduler is not the default
> scheduler?
There are still some smaller bits missing. As far as I know, the missing
parts are:
1) Local recovery (reusing the already downloaded state files after restart
/ rescale)
2) Support for fine-grained
Chesnay,
Seems like you are suggesting that the Adaptive scheduler does everything
the standard scheduler does and more.
I am clearly not an expert on this topic but can you please explain why the
AdaptiveScheduler is not the default scheduler?
If it can do everything, why do we even have 2
There's the default and reactive mode; nothing else.
At it's core they are the same thing; reactive mode just cranks up the
desired parallelism to infinity and enforces certain assumptions (e.g.,
no active resource management).
The advantage is that the adaptive scheduler can run jobs while
Hi all,
As discussed in the discussion thread [1], I would like to propose we
externalize flink-avro-glue-schema-registry and flink-json-glue-schema-registry
formats to the flink-connector-aws repository [2].
Motivation:
1. We can unify and upgrade the AWS SDK versions more easily.
2. We can
Thanks for the explanation. If not for the "reactive mode", what is
the advantage of the adaptive scheduler? What other modes does it
support?
>Apart from implementing the same interface the implementations of the adaptive
>and default schedulers are separate.
Last time I looked they
On 26/01/2023 16:18, Maximilian Michels wrote:
I see slightly different goals for the standard and the adaptive
scheduler. The adaptive scheduler's goal is to adapt the Flink job
according to the available resources.
This is really a misconception that we just have to stomp out.
This
Thanks for the replies! I don't mind which scheduler handles the
implementation, as long as autoscaling via the Flink operator works
with it.
I see slightly different goals for the standard and the adaptive
scheduler. The adaptive scheduler's goal is to adapt the Flink job
according to the
If the adaptive scheduler would support all execution modes like Native
Applications, Sessions etc including active resource management then I
think we could use that all the time. I would love to use one scheduler
instead of having 2 options.
Currently however there is a huge gap in
Hi Gyula,
if the adaptive scheduler supported active resource managers, would there
be any other blocker to migrate to it? I don't know much about the
implementation-side here, but conceptually once we have session mode
support and each Jobs in a session clusters declaris their desired
Hi Martijn,
I was working on FLINK-30623[1], it has been merged today.
And the performance of Unaligned checkpoint[2][3] has been
recovered.
[1] https://issues.apache.org/jira/browse/FLINK-30623
[2]
http://codespeed.dak8s.net:8000/timeline/#/?exe=1=checkpointSingleInput.UNALIGNED=on=on=off=2=200
+1 (binding)
* checked Maven and source artifact signatures and checksums - OK
* no binaries or packaged dependencies - OK
* checked website changes - Approved.
Am Fr., 20. Jan. 2023 um 15:39 Uhr schrieb Martijn Visser <
martijnvis...@apache.org>:
> Hi everyone,
> Please review and vote on the
Hi Konstantin!
I think the Adaptive Scheduler still will not support Kubernetes Native
integration and can only be used in standalone mode. This means that the
operator needs to manage all resources externally, and compute exactly how
much new slots are needed during rescaling etc.
I think
Hi Max,
it seems to me we are now running in some of the potential duplication of
efforts across the standard and adaptive scheduler that Chesnay had
mentioned on the original ticket. The issue of having to do a full restart
of the Job for rescaling as well as waiting for resources to be
Chesnay Schepler created FLINK-30796:
Summary: Make Slf4jReporter less noisy when no/few metrics exist
Key: FLINK-30796
URL: https://issues.apache.org/jira/browse/FLINK-30796
Project: Flink
+1 (binding)
* verified checksums & signatures
* checked differences of pom.xml and NOTICE files with 1.16.0 release.
looks good
* checked source release contains no binaries
* built from sources
* run StateMachineExample on a local cluster
* checked the web PR
Best,
Dawid
On
JinxinTang created FLINK-30795:
--
Summary: StreamingWithStateTestBase of win not correct
Key: FLINK-30795
URL: https://issues.apache.org/jira/browse/FLINK-30795
Project: Flink
Issue Type: Bug
Hi Lijie,
> In summary, I would prefer to extend the "revert regression commits" to
31st.
Sounds good to me.
Thanks,
Martijn
Op do 26 jan. 2023 om 12:48 schreef Lijie Wang :
> Hi Martijn,
>
> Thanks for your detailed explanation. Honestly, the FLINK-30624 is unlikely
> to be completed before
Thanks, Martijn.
+1 (binding)
- Verified checksums and signatures for binaries & sources - OK
- checked pom changes for newly introduced dependencies - OK
- went over flink-web PR - Looks good except for Matthias' remarks
Am Do., 26. Jan. 2023 um 12:34 Uhr schrieb Sergey Nuyanzin <
Hi Martijn,
Thanks for your detailed explanation. Honestly, the FLINK-30624 is unlikely
to be completed before the 26th, but it 's likely to be completed before
the 31st. Considering that there will be a period of time between feature
freeze and release, I think we have enough time to see if it
Thanks Martijn.
+1 (non-binding)
- Verified checksums and signatures
- Built from sources
- Compared downloaded with mentioned git tag
- Verified version in poms
- Ran several queries in batch and streaming (standalone cluster)
- Verified NOTICE and LICENSE files
On Mon, Jan 23, 2023 at 2:06 PM
Hey ConradJam,
Thank you for your thoughtful response. It would be great to start writing
a FLIP for the Rescale API. If you want to take a stab, please go ahead,
I'd be happy to review. I'm sure Gyula or others will also chime in.
I want to answer your question so we are aligned:
● Does
+1
On 25/01/2023 10:33, Matthias Pohl wrote:
Hi everyone,
After the discussion thread [1] on FLIP-285 [2] didn't bring up any new
items, I want to start voting on FLIP-285. This FLIP will not only align
the leader election code base again through FLINK-26522 [3]. I also plan to
improve the test
Hi everyone,
I have come across the below issue, while experimenting with the Confluent
registry and avro-confluent, debezium-avro-confluent formats. Please let me
know your thoughts on it. Should this issue be addressed?
Thanks in advance,
Fruzsina
The use case
Create a new topic on
Martijn Visser created FLINK-30794:
--
Summary: Disable dependency convergence check for night connector
builds
Key: FLINK-30794
URL: https://issues.apache.org/jira/browse/FLINK-30794
Project: Flink
Hi Lijie,
You're right, that's not clearly phrased. Ideally we would like to get it
fixed before the 26th, because that gives us a couple of days to monitor
the benchmarks to see if the regression is actually fixed. If a contributor
is actively working on a ticket, we could consider delaying the
30 matches
Mail list logo
