PM Zhanghao Chen <
zhanghao.c...@outlook.com>
wrote:
Thanks for driving this topic. I think this FLIP could help clean up
the
codebase to make it easier to maintain. +1 on it.
Best,
Zhanghao Chen
________________
From: Weihua Hu
Sent: Monday, February 27, 2023 20:40
T
>>>> their functionality matches and where they differ might help
> understand
> >>> the
> >>>> consequences of the changes proposed in FLIP-298.
> >>>>
> >>>> Best,
> >>>> Matthias
> >>>>
> >
.com>
wrote:
Thanks for driving this topic. I think this FLIP could help clean up
the
codebase to make it easier to maintain. +1 on it.
Best,
Zhanghao Chen
________
From: Weihua Hu
Sent: Monday, February 27, 2023 20:40
To: dev
Subject: [DISCUSS] FLIP-298: Unifying the I
gt; > > >> > > > > >> Best,
> > > > > > >> > > > > >>
> > > > > > >> > > > > >> Xintong
> > > > > > >> > > > > >>
> > > > > > >>
unifying
> > > > > >> > > > > >> > DeclarativeSlotManager and FineGrainedSlotManager is
> > > > > >> valuable.
> > > > > >> > > > > >> >
> > > > > >> > > > > >> > I agree wi
FineGrainedSlotManager
> > > > >> > > > is
> > > > >> > > > > a
> > > > >> > > > > >> > good idea. Or you can add some test information to
> the
> > > > >> > > > >
; >> it is
> > > >> > > > > >> difficult
> > > >> > > > > >> > to migrate step-by-step. You can list the relationship
> > > >> between
> > > >> > > them
> > > >> > > > in
> > > >&g
gt; >> > > > > >> > way, we can gradually construct test cases for
> > >> > > > FineGrainedSlotManager
> > >> > > > > >> > during the development process.
> > >> > > > > >> >
> >
; > test,
> >> > > > > >> > > to update the DeclarativeSlotManager to just delegate to
> >> the
> >> > > > > >> > > FineGrainedSlotManager. If the full test suite still
> >> passes,
> >> > you
> >> > > > > can be
> >> > >
; all
>> > > > test
>> > > > > >> > > scenarios are present for the FGSM.
>> > > > > >> > >
>> > > > > >> > > 4. In addition to changing the default, would it make
>> sense to
>> > > > log a
>
> scenarios are present for the FGSM.
> > > > > >> > >
> > > > > >> > > 4. In addition to changing the default, would it make sense
> to
> > > > log a
> > > > > >> > > deprecation warning o
a proper test coverage analysis? That's not
> > > > mentioned
> > > > >> in
> > > > >> > > the
> > > > >> > > > current version of the FLIP. I'm bringing this up because we
> > ran
> > > > into
>
> > that
> > > >> > > by
> > > >> > > > removing the legacy code we decrease test coverage because
> > certain
> > > >> > > > test cases that were covered for the legacy classes might not
> be
> > > >> > > > necessarily c
> by
> > >> > > > removing the legacy code we decrease test coverage because
> certain
> > >> > > > test cases that were covered for the legacy classes might not be
> > >> > > > necessarily covered in the new implementation, yet (see
> > FLINK-30338
eSlotManager and FineGrainedSlotManager feel quite
> big
> >> in
> >> > > > terms of lines of code. Without knowing whether it's actually a
> >> > > reasonable
> >> > > > thing to do: Instead of just adding more features to the
&g
r he can add some insights here.
>> > > >
>> > > > 3. For me personally, having a more detailed summary comparing the
>> > > > subcomponents of both SlotManager implementations with where
>> > > > their functionality matches and where
> wondering whether he can add some insights here.
> > > >
> > > > 3. For me personally, having a more detailed summary comparing the
> > > > subcomponents of both SlotManager implementations with where
> > > > their functionality matches
IP-298.
> > >
> > > Best,
> > > Matthias
> > >
> > > [1]
> > >
> >
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-285%3A+Refactoring+LeaderElection+to+make+Flink+support+multi-component+leader+election+out-of-the-box
> > > [2] https://issues.apa
election+out-of-the-box
> > [2] https://issues.apache.org/jira/browse/FLINK-30338
> > [3]
> >
> https://github.com/apache/flink/blob/f611ea8cb5deddb42429df2c99f0c68d7382e9bd/flink-runtime/src/main/java/org/apache/flink/runtime/resourcemanager/slotmanager/TaskExecutorManager.java#L66-L68
nager |
>> 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.
;
>
> --
>
> Best,
> Matt Wang
>
>
> Replied Message
> | From | David Morávek |
> | Date | 02/27/2023 22:45 |
> | To | |
> | Subject | Re: [DISCUSS] FLIP-298: Unifying the Implementation of
> SlotManager |
> Hi Weihua, I still need to dig into the details, bu
This is a good proposal for me, it will make the code of the SlotManager more
clear.
--
Best,
Matt Wang
Replied Message
| From | David Morávek |
| Date | 02/27/2023 22:45 |
| To | |
| Subject | Re: [DISCUSS] FLIP-298: Unifying the Implementation of SlotManager |
Hi Weihua, I
+1 on it.
>
> Best,
> Zhanghao Chen
>
> From: Weihua Hu
> Sent: Monday, February 27, 2023 20:40
> To: dev
> Subject: [DISCUSS] FLIP-298: Unifying the Implementation of SlotManager
>
> Hi everyone,
>
> I would like to be
Thanks for driving this topic. I think this FLIP could help clean up the
codebase to make it easier to maintain. +1 on it.
Best,
Zhanghao Chen
From: Weihua Hu
Sent: Monday, February 27, 2023 20:40
To: dev
Subject: [DISCUSS] FLIP-298: Unifying the Implementation
Hi everyone,
I would like to begin a discussion on FLIP-298: Unifying the Implementation
of SlotManager[1]. There are currently two types of SlotManager in Flink:
DeclarativeSlotManager and FineGrainedSlotManager. FineGrainedSlotManager
should behave as DeclarativeSlotManager if the user does not
25 matches
Mail list logo
