+1 (binding)
My only suggestion would be to move Catalog changes into a separate
interface to allow us to begin with lower stability guarantees. Existing
Catalogs would be able to opt-in by implementing it. It's a minor thing
though, overall the FLIP is solid and the direction is pretty exciting.
Hi Yuepeng,
Thanks for the FLIP! There was already quite a discussion on FLIP-210
[1][2], that has proposed more or less the same thing. FLIP was marked as
out of scope for Flink because underlying technologies already address it.
Are you aware of the effort? If yes, what has changed since then?
Congrats, Alex!
Best,
D.
On Fri, Jan 5, 2024 at 7:25 AM Sergey Nuyanzin wrote:
> Congratulations, Alex!
>
> On Fri, Jan 5, 2024, 05:12 Lincoln Lee wrote:
>
> > Congratulations, Alex!
> >
> > Best,
> > Lincoln Lee
> >
> >
> > Alexander Fedulov 于2024年1月4日周四 19:08写道：
> >
> > > Thanks, everyone!
Hi Zhanghao,
Thanks for the FLIP. What you're proposing makes a lot of sense +1
Have you thought about how this works with unaligned checkpoints in case
you go from unchained to chained? I think it should be fine because this
scenario should only apply to forward/rebalance scenarios where we, as
+1 (binding)
Best,
D.
On Wed, Nov 22, 2023 at 11:21 AM Roman Khachatryan wrote:
> +1 (binding)
>
> Regards,
> Roman
>
> On Wed, Nov 22, 2023, 7:08 AM Zakelly Lan wrote:
>
> > +1(non-binding)
> >
> > Best,
> > Zakelly
> >
> > On Wed, Nov 22, 2023 at 3:04 PM Hangxiang Yu
> wrote:
> >
> > > +1
The paper looks interesting, but it might not manifest the described
benefit for practical reasons:
1. It forces you to remember all keys in the broadcasted (partitioned is
impossible without timeouts, etc.) operator state. Forever. This itself is
a blocker for a bunch of pipelines. The primary
Hi Danny,
> My current proposal is that the REST API should not leave the Flink
cluster
in an inconsistent state.
Regarding consistency, Flink only cares about individual jobs, but I can
see your point.
For streaming, this is probably something we could address by book-keeping
jobs submitted by
pache/flink/blob/d78d52b27af2550f50b44349d3ec6dc84b966a8a/flink-core/src/main/java/org/apache/flink/core/fs/FileSystem.java#L695
>
> [2]
> https://github.com/apache/flink/blob/d78d52b27af2550f50b44349d3ec6dc84b966a8a/flink-core/src/main/java/org/apache/flink/core/fs/FileSystem.java#L706
for user cases submitting lots of short-lived jobs concurrently, but we
> don't want to configure a large spare resource since this might double the
> total resource usage and lead to resource waste.
>
> Looking forward to hearing from you.
>
> Regards,
> Xiangyu
>
> [1] h
Hi Maomao,
I wonder whether it would make sense to take a stab at consolidating the S3
filesystems instead and introduce a native one. The whole Hadoop wrapper
around the S3 client exists for legacy reasons, and it adds complexity and
probably an unnecessary performance penalty.
If you take a
H Xiangyui,
The sentiment of the FLIP makes sense, but I keep wondering whether this is
the best way to think about the problem. I assume that "interactive session
cluster" users always want to keep some spare resources around (up to a
configured threshold) to reduce cold start instead of
Hello Yuepeng,
The FLIP reads sane; nice work! To re-phrase my understanding:
The problem you're trying to solve only exists in complex graphs with
different per-vertex parallelism. If the parallelism is set globally
(assuming the pipeline has roughly even data skew), the algorithm could
make
+1 since there is an alternative, more complete implementation available
Best,
D.
On Sat, Sep 2, 2023 at 12:07 AM David Anderson wrote:
> +1
>
> Keeping the legacy implementation in place is confusing and encourages
> adoption of something that really shouldn't be used.
>
> Thanks for driving
Hi Tawfik,
It's exciting to see any ongoing research that tries to push Flink forward!
The get the discussion started, can you please your paper with the
community? Assessing the proposal without further context is tough.
Best,
D.
On Mon, Sep 4, 2023 at 4:42 PM Tawfek Yasser Tawfek
wrote:
>
AFAIK Apache Beam also used acummulators for metric collection, which is
indeed a major use case.
I’m not convinced that MetricGroup is fuĺly replacing what acummulators
have to offer though; OperatorCoordinators might be able to rplace
remaining capabilities, but this need bit more thoughts, the
ut you shouldn't do that in the first place.
That sounds great; let's go ahead and outline this in the FLIP.
Best,
D.
On Tue, Jul 4, 2023 at 12:30 PM Etienne Chauchot
wrote:
> Hi all,
>
> Thanks David for your feedback. My comments are inline
>
> Le 04/07/2023 à 09:16,
I've left some comments on the PR.
On Tue, Jul 4, 2023 at 9:20 AM Martijn Visser
wrote:
> Hi Hong,
>
> Given that this changes the REST API, which is a public interface, I'm
> wondering if this shouldn't first have had a (small) FLIP if I follow the
> guidelines from the overview page [1].
>
>
:11 AM David Morávek wrote:
> The FLIP reads sane to me. I'm unsure about the default values, though; 5
> minutes of wait time between rescales feels rather strict, and we should
> rethink it to provide a better out-of-the-box experience.
>
> I'd focus on newcomers trying AS /
The FLIP reads sane to me. I'm unsure about the default values, though; 5
minutes of wait time between rescales feels rather strict, and we should
rethink it to provide a better out-of-the-box experience.
I'd focus on newcomers trying AS / Reactive Mode out. They will struggle if
they add new
at 8:49 AM David Morávek wrote:
> The vote closes within 6 hours and, as for now, there was no vote. This
>> is a very short FLIP, that takes a few minutes to read.
>>
>
> Maybe because there should have been a dedicated voting thread (marked as
> [VOTE]), this one was h
>
> The vote closes within 6 hours and, as for now, there was no vote. This
> is a very short FLIP, that takes a few minutes to read.
>
Maybe because there should have been a dedicated voting thread (marked as
[VOTE]), this one was hidden and hard to notice.
We should restart the vote with
Hi Hong,
Thanks for starting the discussion.
seems to be using the cached version of the entire Execution graph (stale
> data), when it could just use the CheckpointStatsCache directly
CheckpointStatsCache is also populated using the "cached execution graph,"
so there is nothing to gain from
Hi,
Thanks for the FLIP! Data lineage is an important problem to tackle.
Can you please expand on how this is planned to be wired into the
JobManager? As I understand, the listeners will be configured globally (per
cluster), so this won't introduce a new code path for running per-job /
in the video!
> >
> > Couple other things to consider:
> >
> >
> > * Confirming new parallelism before actually doing it, e.g. having a
> > “Deploy/Commit/Save” button
> > * Allow users to enter parallelism without having to
> > increment/decremen
Hi Everyone,
In FLINK-31471, we've introduced new "in-place rescaling features" to the
Web UI that show up when the scheduler supports FLIP-291 REST endpoints.
I expect this to be a significant feature for user education (they have an
easy way to try out how rescaling behaves, especially in
> > > >>>>>
> > > >>>>> Can we also prevent Junit4 usage in new code by this way？Because
> > > >>>> currently
> > > >>>>> we are aiming to migrate our codebase to JUnit 5.
> > > >>>>&g
Hi,
Great to see this topic moving forward; I agree it's long overdue.
I keep thinking about 2.0 as a chance to eliminate things that didn't work,
make the feature set denser, and fix rough edges and APIs that hold us back.
Some items in the doc (Key Features section) don't tick these boxes for
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:09 PM Weihua Hu wrote:
> Hi, Eric
>
> Thanks for bringing this discussion.
>
Hi Everyone,
A long time ago, the community decided not to use Mockito-based tests
because those are hard to maintain. This is already baked in our Code Style
and Quality Guide [1].
Because we still have Mockito imported into the code base, it's very easy
for newcomers to unconsciously introduce
Congratulations, Qingsheng, well deserved!
Best,
D.
On Fri 21. 4. 2023 at 16:41, Feng Jin wrote:
> Congratulations, Qingsheng
>
>
>
> Best,
> Feng Jin
>
> On Fri, Apr 21, 2023 at 8:39 PM Mang Zhang wrote:
>
> > Congratulations, Qingsheng.
> >
> >
> >
> >
> >
> > --
> >
> > Best regards,
Congratulations, Leonard, well deserved!
Best,
D.
On Fri 21. 4. 2023 at 16:40, Feng Jin wrote:
> Congratulations, Leonard
>
>
>
> Best,
> Feng Jin
>
> On Fri, Apr 21, 2023 at 8:38 PM Mang Zhang wrote:
>
> > Congratulations, Leonard.
> >
> >
> > --
> >
> > Best regards,
> > Mang Zhang
> >
:
>
> > +1 to what David wrote. I think we need to update the FLIP and extend the
> > voting?
> >
> > Piotrek
> >
> > śr., 19 kwi 2023 o 09:06 David Morávek napisał(a):
> >
> >> Hi Panos,
> >>
> >> It seems that most recent dis
Hi Panos,
It seems that most recent discussions (e.g. changing the semantics of the
config option) are not reflected in the FLIP. Can you please double-check
that this is the correct version?
Best,
D.
On Mon, Apr 17, 2023 at 9:24 AM Panagiotis Garefalakis
wrote:
> Hello everyone,
>
> I want
cc dev@f.a.o
On Sun, Apr 16, 2023 at 11:42 AM David Morávek wrote:
> Hi Alexey,
>
> I'm a bit skeptical because, looking at the project, I see a couple of red
> flags:
>
> - The project is inactive. The last release and commit are both from the
> last May.
> - The proj
u want to reuse
> some
> > > other
> > > >> classifier) is the only one I can think of where we actually need
> > > >> classifiers depending on each other. Supporting such a use case
> right
> > > from
> > > &g
ion
> details,
> > > > and
> > > > > > not
> > > > > > > > all FailureListeners need to handle them, we shouldn't put
> them
> > > in
> > > > > the
> > > > > > > > interface. Minor: The c
se previous state (tags/labels) to make decisions:
> e.g., wont assign *UNKNOWN* failureType when we have already seen *USER *or
> the other way around -- when we have seen *UNKNOWN* remove in favor of
> *USER*
>
>
> Cheers,
> Panagiotis
>
> On Sun, Mar 19, 2023 at 10:
Hi Panagiotis,
This is an excellent proposal and something everyone trying to provide
"Flink as a service" needs to solve at some point. I have a couple of
questions:
If I understand the proposal correctly, this is just about adding tags to
the Throwable by running a tuple of (Throwable,
> Although YARN serves as the platform for Flink, does YARN also operate on
K8s?
YARN is an alternative to k8s and Flink should make no assumptions about
how it's deployed, even though some companies might deploy it as an overlay
RM on top of k8s (I doubt that, but I guess they might do it for
+1 (binding)
Best,
D.
On Fri, Mar 10, 2023 at 4:49 AM Yuxin Tan wrote:
> Thanks, Weihua!
> +1 (non-binding)
>
> Best,
> Yuxin
>
>
> weijie guo 于2023年3月10日周五 11:29写道：
>
> > +1 (binding)
> >
> > Best regards,
> >
> > Weijie
> >
> >
> > Shammon FY 于2023年3月10日周五 11:02写道：
> >
> > > Thanks weihua,
Hi Surendra,
Since you're mentioning docker, I assume you're deploying your application
to k8s. Is that correct?
For handcrafted Kubernetes deployments, you can simply download the jar
into the user lib folder in an init container [1]. You can usually reuse
existing docker images to download the
I'm happy to announce that we have unanimously approved this FLIP.
There are 8 approving votes, 3 of which are binding:
* John Roesler
* Konstantin Knauf (binding)
* Zhanghao Chen
* ConradJam
* Feng Xiangyu
* Gyula Fóra (binding)
* Roman Khachatryan (binding)
* Shammon FY
There are no
Thanks, everyone, I'm closing this vote now. I'll follow up with the result
in a separate email.
On Wed, Mar 1, 2023 at 10:01 AM Shammon FY wrote:
> +1 (non-binding)
>
> Best,
> Shammon
>
>
> On Wed, Mar 1, 2023 at 4:51 PM Roman Khachatryan wrote:
>
> > +1 (binding)
> >
> > Thanks David, and
Hi Everyone,
I want to start the vote on FLIP-291: Externalized Declarative Resource
Management [1]. The FLIP was discussed in this thread [2].
The goal of the FLIP is to enable external declaration of the resource
requirements of a running job.
The vote will last for at least 72 hours (Friday,
t;>
>> [1] However, there might be costs involved with executing the
>> rescaling, e.g. for using external storage like s3, especially without
>> local recovery.
>> [2]
>> https://github.com/dmvk/flink/commit/5e7edcb77d8522c367bc6977f80173b14dc03ce9
>>
>
state.
We're still planning to dig deeper in this direction with other efforts,
but this is already good enough and should allow us to move the FLIP
forward.
WDYT? Unless there are any objectives against the above, I'd like to
proceed to a vote.
Best,
D.
On Thu, Feb 23, 2023 at 5:39 PM David
Hi Weihua, I still need to dig into the details, but the overall sentiment
of this change sounds reasonable.
Best,
D.
On Mon, Feb 27, 2023 at 2:26 PM Zhanghao Chen
wrote:
> Thanks for driving this topic. I think this FLIP could help clean up the
> codebase to make it easier to maintain. +1 on
I think this makes sense, +1 from my side; as I wrote on the ticket, I'm
not aware of any other usages apart from the kinesis connector, and we
already have more feature complete API that can replace the functionality
there.
Best,
D.
On Mon, Feb 27, 2023 at 2:44 PM Zhanghao Chen
wrote:
> Hi
Congratulations Anton, well deserved!
Best,
d.
On Wed, Feb 22, 2023 at 5:01 AM Jane Chan wrote:
> Congratulations, Anton!
>
> Best regards,
> Jane
>
> On Wed, Feb 22, 2023 at 11:22 AM Yun Tang wrote:
>
> > Congratulations, Anton!
> >
> > Best
> > Yun Tang
> >
gt; would be to drop as many task managers during the restart such that
> >> NUM_REQUIRED_SLOTS >= NUM_AVAILABLE_SLOTS stays true. We can look into
> >> this independently of the FLIP.
> >>
> >> Feel free to start the vote.
> >>
> >> -
-main/docs/custom-resource/autoscaler/
> > > [2] https://lists.apache.org/thread/2f7dgr88xtbmsohtr0f6wmsvw8sw04f5
> > >
> > > On Mon, Feb 13, 2023 at 1:16 PM feng xiangyu
> wrote:
> > > >
> > > > Hi David,
> > > >
> > > > Thanks
ich may take a long time.
> > 2. After providing the REST API, users can just send a request to the job
> > via REST API quickly after updating the config file.
> > The configuration in the running job and config file should be the same.
> > What do you think of this?
> >
&
> > > >- when the number of "slots" is insufficient, can we can stop
> users
> > > >rescaling or throw something to tell user "less avaliable slots to
> > > > upgrade,
> > > >please checkout your alivalbe slots" ? Or we c
Thanks for the detailed FLIP, Matthias; this will simplify the HA code-base
significantly.
+1 (binding)
Best,
D.
On Tue, Jan 31, 2023 at 5:22 AM Yang Wang wrote:
> +1 (Binding)
>
> Best,
> Yang
>
> ConradJam 于2023年1月31日周二 12:09写道：
>
> > +1 non-binding
> >
> > Matthias Pohl 于2023年1月25日周三
Hi everyone,
This FLIP [1] introduces a new REST API for declaring resource requirements
for the Adaptive Scheduler. There seems to be a clear need for this API
based on the discussion on the "Reworking the Rescale API" [2] thread.
Before we get started, this work is heavily based on the
It makes sense to give the whole "scheduler ecosystem," not just the
adaptive scheduler, a little bit more structure in the docs. We already
have 4 different schedulers (Default, Adaptive, AdaptiveBatch,
AdaptiveBatchSpeculative), and it becomes quite confusing since the details
are scattered
eant as a better version of the default scheduler for
> streaming jobs.
>
> On 26/01/2023 19:06, David Morávek wrote:
> > Hi Gyula,
> >
> >
> >> can you please explain why the AdaptiveScheduler is not the default
> >> scheduler?
> >
> > T
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
Hi Shammon,
I'm starting to see what you're trying to achieve, and it's really
exciting. I share Piotr's concerns about e2e latency and disability to use
unaligned checkpoints.
I have a couple of questions that are not clear to me from going over the
FLIP:
1) Global Checkpoint Commit
Are you
Hi Dong,
> Adding regarding the effort to add back the per-component election
capability: given that the implementation already follows per-process
election, and given that there will likely be a lot of extra
design/implementation/test effort needed to achieve the use-cases described
above, maybe
+1; anything below 2.10.x seems to be EOL
Best,
D.
On Mon, Oct 17, 2022 at 10:48 AM Márton Balassi
wrote:
> Hi Martjin,
>
> +1 for 2.10.2. Do you expect to have bandwidth in the near term to
> implement the bump?
>
> On Wed, Oct 5, 2022 at 5:00 PM Gabor Somogyi
> wrote:
>
> > Hi Martin,
> >
>
Hi Zheng,
Thanks for the write-up! I tend to agree with Chesnay that this introduces
additional complexity to an already complex deployment model.
One of the main focuses in this area is to reduce feature sparsity and to
have fewer high-quality options. Example efforts are deprecation (and
+1 (binding)
On Thu, May 26, 2022 at 11:55 AM Dawid Wysakowicz
wrote:
> +1 (binding)
>
> On Thu, 26 May 2022, 11:21 Piotr Nowojski, wrote:
>
> > Yes, it will be a good improvement :)
> >
> > +1 (binding)
> >
> > Piotrek
> >
> > czw., 26 maj 2022 o 10:26 Anton Kalashnikov
> > napisał(a):
> >
>
Hi Zain,
you can find a link to web-ui either in the CLI output after the job
submission or in the YARN ResourceManager web ui [1]. With YARN Flink needs
to choose the application master port at random (could be somehow
controlled by setting _yarn.application-master.port_) as there might be
Hi Talat,
This is definitely an interesting and rather complex topic.
Few unstructured thoughts / notes / questions:
- The main struggle has always been that it's hard to come up with a
generic one-size-fits-it-all metrics for autoscaling.
- Flink doesn't have knowledge of the external
Nice! Congrats Yang, well deserved! ;)
On Fri 6. 5. 2022 at 17:53, Peter Huang wrote:
> Congrats, Yang!
>
>
>
> Best Regards
> Peter Huang
>
> On Fri, May 6, 2022 at 8:46 AM Yu Li wrote:
>
> > Congrats and welcome, Yang!
> >
> > Best Regards,
> > Yu
> >
> >
> > On Fri, 6 May 2022 at 14:48,
Thanks Konstantin and Chesnay for starting the discussion and volunteering.
The timeline proposal sounds reasonable :+1:
Best,
D.
On Tue, Apr 26, 2022 at 1:37 PM Martijn Visser
wrote:
> Hi everyone,
>
> Thanks for starting this discussion. I would also volunteer to help out as
> a release
mporalValueState just a special case of b.III? So if a
>> user
>> of the state wants that, then they can leverage a simple API vs. if you
>> want
>> fancier duplicate handling, you'd just go with TemporalListState and
>> implement
>> the logic you want?
&
binary keys...
>
>
> 2) Duplicates
>
> Isn't allowing a TemporalValueState just a special case of b.III? So if a
> user
> of the state wants that, then they can leverage a simple API vs. if you
> want
> fancier duplicate handling, you'd just go with TemporalListState and
>
might need to avoid to write the
> length in the serialized bytes.
> On the other hand, changelog logger would record operation per key one by
> one in the logs. We need to consider how to distinguish each key in the
> combined serialized byte arrays.
>
> Best
> Yun Tang
>
David Morávek
wrote:
> Hi David,
>
> It seems to me that at least with the heap-based state backend, readRange
>> is going to have to do a lot of unnecessary work to implement this
>> isEmpty() operation, since it have will to consider the entire range from
>> MIN_VA
Hi David,
It seems to me that at least with the heap-based state backend, readRange
> is going to have to do a lot of unnecessary work to implement this
> isEmpty() operation, since it have will to consider the entire range from
> MIN_VALUE to MAX_VALUE. (Maybe we should add an explicit isEmpty
Hi David,
I really like the proposal. This has so much potential for various
optimizations, especially for temporal joins. My only concern is that the
interfaces seems unnecessarily complicated.
My feeling would be that we only need a single, simple interface that would
fit it all (the same way
t., 4 mar 2022 o 16:04 Aitozi napisał(a):
> > > > >
> > > > > > Congratulations David!
> > > > > >
> > > > > > Ingo Bürk 于2022年3月4日周五 22:56写道：
> > > > > >
> > > > > > > Congrats, David!
> > > > &
Congratulations Martijn, well deserved!
Best,
D.
On Fri, Mar 4, 2022 at 7:25 AM Jiangang Liu
wrote:
> Congratulations Martijn!
>
> Best
> Liu Jiangang
>
> Lijie Wang 于2022年3月4日周五 14:00写道：
>
> > Congratulations Martijn!
> >
> > Best,
> > Lijie
> >
> > Jingsong Li 于2022年3月4日周五 13:42写道：
> >
> >
Hi Jark, can you please elaborate about the current need of the per-job
mode for interactive clients (eg. Zeppelin that you've mentioned)? Aren't
these a natural fit for the session cluster?
D.
On Fri, Feb 11, 2022 at 3:25 PM Jark Wu wrote:
> Hi Konstantin,
>
> I'm not very familiar with the
integrate it, user will benefit a lot.
>
> On 2022/01/26 18:56:17 David Morávek wrote:
> > I'd second to Alex's concerns. Is there a reason why you can't use the
> > async-profiler directly? In what kind of environment are your Flink
> > clusters running (YARN / k8s / ...)?
> >
&g
Network partitions are trickier than simply crashing process. For example
these can be asymmetric -> as a TM you're still able to talk to the JM, but
you're not able to talk to other TMs.
In general this could be achieved by manipulating iptables on the host
machine (considering we spawn all the
Thanks Gabor for driving this, I think the change is going to be really
valuable for some of the enterprise users.
Best,
D.
On Tue, Feb 8, 2022 at 8:33 AM Gabor Somogyi
wrote:
> Hi devs,
>
> FLIP-211 [1] Has been accepted.
> There were 3 binding votes and 2 non-binding in favor.
> None
There is a really strong tendency to push many things out of Flink lately
and keep the main building blocks only. However I really think that this
belongs between the minimal building blocks that Flink should provide out
of the box. It's also very likely that security topics will start getting
here.
>
> [1] https://lists.apache.org/thread/cvwknd5fhohj0wfv8mfwn70jwpjvxrjj
>
> On Mon, Jan 24, 2022 at 11:07 AM David Morávek
> wrote:
>
>> Hi Gabor,
>>
>> Thanks for driving this. This is headed in a right direction, but I feel
>> that the FLIP still
+1 (non-binding)
D.
On Fri 28. 1. 2022 at 17:53, Till Rohrmann wrote:
> +1 (binding)
>
> Cheers,
> Till
>
> On Fri, Jan 28, 2022 at 4:57 PM Gabor Somogyi
> wrote:
>
> > +1 (non-binding)
> >
> > We're intended to make tests when FLINK-24897
> >
t you mean "we can't
> register the TM without
> providing it with token" but in unsecure configuration registration must
> happen w/o tokens.
> All in all the newly added tokens field must be somehow optional.
>
> G
>
>
> On Fri, Jan 28, 2022 at 2:22 PM Da
Thanks Biao and Ferenc for taking care of this, it's really helpful.
D.
On Fri, Jan 28, 2022 at 1:59 PM Ferenc Csaky
wrote:
> Hi Konstantin,
>
> We at Cloudera will also help out with this. AFAIK there was a
> conversation about this in the past anyways. I will talk this through with
> the
de parts are not touching existing DTs within the JVM
>
> I would like to emphasize I'm not against to add it just want to see what
> kind of problems are we facing.
> It would ease to catch bugs earlier and help in the maintenance.
>
> All in all I would buy the idea to ad
it to all currently connected
TMs
3) When a TM gets out of sync, DTM would reconcile it's state
WDYT?
Best,
D.
On Wed, Jan 26, 2022 at 9:03 PM David Morávek wrote:
> Thanks the update, I'll go over it tomorrow.
>
> On Wed, Jan 26, 2022 at 5:33 PM Gabor Somogyi
> wrote:
official security doc
> > area as caveat.
> >
> > > If we split the FLIP into two parts / sections that I've suggested, I
> > don't
> > really think that you need to explicitly test for each deployment
> scenario
> > / cluster framework, because the DTM pa
gt; Best,
> Alexander Fedulov
>
> On Wed, Jan 26, 2022 at 1:59 PM 李森 wrote:
>
> > This is an expected feature, as we also experienced browser crashes on
> > existing operator-level flame graphs
> >
> > Best,
> > Echo Lee
> >
> > > 在 2022年1月24日，下
+1, especially for the reasons Yuan has mentioned
D.
On Wed, Jan 26, 2022 at 9:15 AM Yu Li wrote:
> +1 to extend the feature freeze date to Feb. 14th, which might be a good
> Valentine's Day present for all Flink developers as well (smile).
>
> Best Regards,
> Yu
>
>
> On Wed, 26 Jan 2022 at
Thanks for driving this Martijn, +1 for the release
Also big thanks to Konstantin for volunteering
Best,
D.
On Mon, Jan 24, 2022 at 3:24 PM Till Rohrmann wrote:
> +1 for the 1.13.6 release and thanks for volunteering Konstantin.
>
> Cheers,
> Till
>
> On Mon, Jan 24, 2022 at 2:57 PM
nism already covers TM failure scenarios
On Mon, Jan 24, 2022 at 3:03 PM David Morávek wrote:
> Could you point to a code where you think it could be added exactly? A
>> helping hand is welcome here
>>
>
> I think you can take a look at _ResourceManagerPartitionTracker_ [1] which
gt; DT reaches it's max lifetime then log aggregation stops. I've had several
> deep-dive rounds with the YARN guys at Spark years because wanted to fill
> this gap. They can't provide us any way to re-inject the newly obtained DT
> so at the end I gave up this.
>
> BR,
> G
>
&g
+1 (non-binding)
Best,
D.
On Mon, Jan 24, 2022 at 10:54 AM Dawid Wysakowicz
wrote:
> +1 (binding)
>
> Best,
>
> Dawid
>
> On 24/01/2022 09:56, Piotr Nowojski wrote:
> > Hi,
> >
> > As there seems to be no further questions about the FLIP-203 [1] I would
> > propose to start a voting thread for
That's a great news Chesnay, thanks for driving this! This should unblock
some ongoing Flink efforts +1
Best,
D.
On Mon, Jan 24, 2022 at 10:58 AM Chesnay Schepler
wrote:
> Hello everyone,
>
> we got a new flink-shaded release, with several nifty things:
>
> * updated version for ASM,
Hi Jacky,
The link seems to be broken, here is the correct one [1].
[1]
https://cwiki.apache.org/confluence/display/FLINK/FLIP-213%3A+TaskManager%27s+Flame+Graphs
Best,
D.
On Mon, Jan 24, 2022 at 9:48 AM Jacky Lau <281293...@qq.com.invalid> wrote:
> Hi All,
> I would like to start the
Hi Gabor,
Thanks for driving this. This is headed in a right direction, but I feel
that the FLIP still might need bit more work.
-1 (non-binding) until the discussion thread is resolved [1].
[1] https://lists.apache.org/thread/cvwknd5fhohj0wfv8mfwn70jwpjvxrjj
Best,
D.
On Mon, Jan 24, 2022
in the proper time
> when needed. YARN log aggregation is a totally different feature, where
> YARN does the renewal. Log aggregation was an example why the code can't be
> 100% reusable for all resource managers. Reading the linked Spark readme
> could be useful.
>
> G
>
&g
not work by dropping that code. Just
> to be crystal clear, the actual implementation contains this fir exactly
> this reason.
>
> G
>
> On Fri, 21 Jan 2022, 20:12 David Morávek, wrote:
>
> > Hi Gabor,
> >
> > 1. One thing is important, token management is pla
yi
wrote:
> Oh and one more thing. I'm planning to add this feature in small chunk of
> PRs because security is super hairy area. That way reviewers can be more
> easily obtains the concept.
>
> On Fri, 21 Jan 2022, 18:03 David Morávek, wrote:
>
> > Hi Gabor,
> >
>
Hi Gabor,
thanks for drafting the FLIP, I think having a solid Kerberos support is
crucial for many enterprise deployments.
I have multiple questions regarding the implementation (note that I have
very limited knowledge of Kerberos):
1) If I understand it correctly, we'll only obtain tokens in
1 - 100 of 195 matches
Mail list logo
