[
https://issues.apache.org/jira/browse/YARN-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haibo Chen updated YARN-6831:
-----------------------------
Description:
While reviewing YARN-6706, Karthik pointed out a few issues for improvment in
ContainerScheduler
#Make ResourceUtilizationTracker pluggable. That way, we could use a different
tracker when oversubscription is enabled.
#ContainerScheduler
##Why do we need maxOppQueueLength given queuingLimit?
##Is there value in splitting runningContainers into runningGuaranteed and
runningOpportunistic?
##getOpportunisticContainersStatus method implementation feels awkward. How
about capturing the state in the field here, and have metrics etc. pull from
here?
##startContainersFromQueue: Local variable resourcesAvailable is unnecessary
#OpportunisticContainersStatus
##Let us clearly differentiate between allocated, used and utilized. Maybe, we
should rename current Used methods to Allocated?
##I prefer either full name Opportunistic (in method) or Opp (shortest name
that makes sense). Opport is neither short nor fully descriptive.
##Have we considered folding ContainerQueuingLimit class into this?
We decided to move the issues into this follow up jira to keep YARN-6706 moving
forward to unblock oversubscription work.
was:
While reviewing YARN-6706, Karthik pointed out a few issues for improvment in
ContainerScheduler
"
#Make ResourceUtilizationTracker pluggable. That way, we could use a different
tracker when oversubscription is enabled.
#ContainerScheduler
##Why do we need maxOppQueueLength given queuingLimit?
##Is there value in splitting runningContainers into runningGuaranteed and
runningOpportunistic?
##getOpportunisticContainersStatus method implementation feels awkward. How
about capturing the state in the field here, and have metrics etc. pull from
here?
##startContainersFromQueue: Local variable resourcesAvailable is unnecessary
#OpportunisticContainersStatus
##Let us clearly differentiate between allocated, used and utilized. Maybe, we
should rename current Used methods to Allocated?
##I prefer either full name Opportunistic (in method) or Opp (shortest name
that makes sense). Opport is neither short nor fully descriptive.
##Have we considered folding ContainerQueuingLimit class into this?
"
We decided to move the issues into this follow up jira to keep YARN-6706 moving
forward to unblock oversubscription work.
> Miscellaneous refactoring changes of ContainScheduler
> ------------------------------------------------------
>
> Key: YARN-6831
> URL: https://issues.apache.org/jira/browse/YARN-6831
> Project: Hadoop YARN
> Issue Type: Bug
> Components: nodemanager
> Reporter: Haibo Chen
> Assignee: Haibo Chen
>
> While reviewing YARN-6706, Karthik pointed out a few issues for improvment in
> ContainerScheduler
> #Make ResourceUtilizationTracker pluggable. That way, we could use a
> different tracker when oversubscription is enabled.
> #ContainerScheduler
> ##Why do we need maxOppQueueLength given queuingLimit?
> ##Is there value in splitting runningContainers into runningGuaranteed and
> runningOpportunistic?
> ##getOpportunisticContainersStatus method implementation feels awkward. How
> about capturing the state in the field here, and have metrics etc. pull from
> here?
> ##startContainersFromQueue: Local variable resourcesAvailable is unnecessary
> #OpportunisticContainersStatus
> ##Let us clearly differentiate between allocated, used and utilized. Maybe,
> we should rename current Used methods to Allocated?
> ##I prefer either full name Opportunistic (in method) or Opp (shortest name
> that makes sense). Opport is neither short nor fully descriptive.
> ##Have we considered folding ContainerQueuingLimit class into this?
> We decided to move the issues into this follow up jira to keep YARN-6706
> moving forward to unblock oversubscription work.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]