[
https://issues.apache.org/jira/browse/FLINK-24125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Rohrmann updated FLINK-24125:
----------------------------------
Description:
The {{DeclarativeSlotPoolBridge}} bridges the old non-declarative slot
allocation protocol of the {{DefaultScheduler}} with the
{{DeclarativeSlotPool}}. It increases requirements when a slot is requested,
and reduces the requirements when the slot is freed.
To support this the {{DeclarativeSlotPool}} API was designed such that the
bridge is provided with the resource profile of freed slots, such that it can
subsequently reduce the requirements.
The main benefit of this is that the bridge does not have to do any resource
book-keeping; the downside is that this pushes {{DefaultScheduler}}
requirements into the declarative resource management stack.
We should rethink whether it wouldn't be worth to extend the book-keeping in
the bridge such that the pool does no longer have to deal with this.
One thing to investigate is whether this is easily possible, specifically
whether a simple book-keeping (let's say, a Map<SlotRequestId,
ResourceProfile>) would be sufficient or whether there are edge-cases this
couldn't support.
was:
The DeclarativeSlotPoolBridge bridges the old non-declarative slot allocation
protocol of the DefaultScheduler with the DeclarativeSlotPool. It increases
requirements when a slot is requested, and reduces the requirements when the
slot is freed.
To support this the DeclarativeSlotPool API was designed such that the bridge
is provided with the resource profile of freed slots, such that it can
subsequently reduce the requirements.
The main benefit of this is that the bridge does not have to do any resource
book-keeping; the downside is that this pushes DefaultScheduler requirements
into the declarative resource management stack.
We should rethink whether it wouldn't be worth to extend the book-keeping in
the bridge such that the pool does no longer have to deal with this.
One thing to investigate is whether this is easily possible, specifically
whether a simple book-keeping (let's say, a Map<SlotRequestId,
ResourceProfile>) would be sufficient or whether there are edge-cases this
couldn't support.
> Rethink relationship between DeclarativeSlotPool and *Bridge
> ------------------------------------------------------------
>
> Key: FLINK-24125
> URL: https://issues.apache.org/jira/browse/FLINK-24125
> Project: Flink
> Issue Type: Technical Debt
> Components: Runtime / Coordination
> Reporter: Chesnay Schepler
> Priority: Major
> Fix For: 1.15.0
>
>
> The {{DeclarativeSlotPoolBridge}} bridges the old non-declarative slot
> allocation protocol of the {{DefaultScheduler}} with the
> {{DeclarativeSlotPool}}. It increases requirements when a slot is requested,
> and reduces the requirements when the slot is freed.
> To support this the {{DeclarativeSlotPool}} API was designed such that the
> bridge is provided with the resource profile of freed slots, such that it can
> subsequently reduce the requirements.
> The main benefit of this is that the bridge does not have to do any resource
> book-keeping; the downside is that this pushes {{DefaultScheduler}}
> requirements into the declarative resource management stack.
> We should rethink whether it wouldn't be worth to extend the book-keeping in
> the bridge such that the pool does no longer have to deal with this.
> One thing to investigate is whether this is easily possible, specifically
> whether a simple book-keeping (let's say, a Map<SlotRequestId,
> ResourceProfile>) would be sufficient or whether there are edge-cases this
> couldn't support.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
