Hi, community,
The design for the ‘FLIP-487: Show history of rescales in Web UI for
AdaptiveScheduler’ [1] based on the latest proposal of FLIP-495 [2] has been
completed.
Looking forward to your suggestions and feedback!
Any input is greatly appreciated!
Best regards,
Yuepeng Pan
[1]
https
Hi, community,
FYI: The proposal change about REST API and backend is extracted into
FLIP-495[1][2].
[1]
https://cwiki.apache.org/confluence/display/FLINK/%5BWIP%5D+FLIP-495%3A+Support+AdaptiveScheduler+record+and+query+the+rescale+history
[2] https://lists.apache.org/thread/t3r9wdd5gpbqnvzw35
Hi, community,
It has been a few days since this FLIP/Email-threads split proposal was shared,
and we haven’t received any additional relevant suggestions or comments so far.
We would like to wait another 1-2 days for more feedback.
If no significantly different opinions are expressed by then,
Thanks Peter for the comments.
> Beside this, should we create new metrics for internal rescale to
> distinguish the metrics for internal restart?
> Created a jira for this https://issues.apache.org/jira/browse/FLINK-36871.
This will make sense to me.
I'm just wondering, how should the relations
Thanks for the proposal. It is a very useful feature for the observability
of autoscaling. . Echo to Eric. We need to add some content about where to
store
the rescale events. We may consider using the same mechanism of how
exception history is stored.
Beside this, should we create new metrics for
Thanks Eric for the comments !
Sorry for some confusion in your reading. As you see, there are some things
that are still in discussion, so I haven't updated some of the current
documentation or wiki.
> How/Where would we store the history of these scaling events?
Please let me try to clarify
Hi Yuepeng Pan,
This would be a very useful feature to have in OSS. One question I have
that wasn't outlined in the FLIP or I may have missed it was -
How/Where would we store the history of these scaling events? Is there an
existing pattern for storing such information in other parts of Flink th
Thanks Rui for the comments!
> I have a minor question for this: could we discuss 2 FLIPs together?
> I'm afraid the rest endpoints doesn't work as expected when we discuss
> WebUI change in the future.
> Clarification: Organize related designs in different FLIP wikis and
> discuss them in diffe
> I have a minor question for this: could we discuss 2 FLIPs together?
Clarification: Organize related designs in different FLIP wikis and
discuss them in different discussions. Together just means that
two FLIPs can be carried out at the same time.
After the design and discussion of both FLIPs a
Thanks Yuepeng for driving this proposal!
It's definitely a great addition for Adaptive Scheduler.
I see FLIP-487 has 2 docs, one is official wiki[1], one is google doc[2].
It's better to only use one doc to ensure the consistency, I prefer
to only use FLIP-487 official wiki due to you have the wi
Thanks Matthias a lot for the comments and guidance.
>Can we reorganize the draft? Right now, we have some (for RescaleEvent,
>Required/AcquiredParallelism) schema defined in the "Proposed Changes" section
>and some other schema under "Public Interfaces". It would be nice to have this
>more
Hi Yuepeng,
thanks for the proposal. Having a way to see the history of rescales is a
nice feature, I guess. I went over the draft and have a few questions:
Can we reorganize the draft? Right now, we have some (for RescaleEvent,
Required/AcquiredParallelism) schema defined in the "Proposed Changes
+1, I think this feature is very useful for adaptive scheduler.
Yuepeng Pan 于2024年11月22日周五 18:38写道：
> Hi community,
>
>
>
>
> Currently, the Adaptive Scheduler already supports the REST API
>
> to manually adjust[1] the parallelism of jobs, which enhances the
>
> functionality of the Adaptive Sc
13 matches
Mail list logo
