hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wangda Tan (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (YARN-3361) CapacityScheduler side changes to support non-exclusive node labels
Date Wed, 08 Apr 2015 17:33:12 GMT

     [ https://issues.apache.org/jira/browse/YARN-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Wangda Tan updated YARN-3361:
-----------------------------
    Attachment: YARN-3361.3.patch

Thanks for your comments, [~vinodkv]/[~jianhe]:

* Main code comments from Vinod: *

bq. checkNodeLabelExpression: NPEs on labelExpression can happen?
No, I removed checkings

bq. FiCaSchedulerNode: exclusive, setters, getters -> exclusivePartition
They're not used by anybody, removed

bq. ExclusiveType renames
Done

bq. AbstractCSQueue:
1. Change to nodePartitionToLookAt: Done
2. Now all queues checks needResources
3. Renamed to hasPendingResourceRequest as suggested by Jian

bq. checkResourceRequestMatchingNodeLabel can be moved into the application?
Moved to SchedulerUtils

bq. checkResourceRequestMatchingNodeLabel nodeLabelToLookAt arg is not used anywhere else.
Done (merged it in SchedulerUtils.checkResourceRequestMatchingNodePartition)

bq. addNonExclusiveSchedulingOpportunity
Renamed to reset/addMissedNonPartitionedRequestSchedulingOpportunity

bq. It seems like we are not putting absolute max-capacities on the individual queues when
not-respecting-partitions. Describe why? Similarly, describe as to why user-limit-factor is
ignored in the not-respecting-paritions mode.
Done

* Test code comments from Vinod: *
bq. testNonExclusiveNodeLabelsAllocationIgnoreAppSubmitOrder
Done

bq. testNonExclusiveNodeLabelsAllocationIgnorePriority
Rename to testPreferenceOfNeedyPrioritiesUnderSameAppTowardsNodePartitions
bq. Actually, now that I rename it that way, this may not be the right behavior. Not respecting
priorities within an app can result in scheduling deadlocks:
This will not lead deadlock, because we separately count resource usage under each partition,
priority=1 goes first on partition=y before priority=0 all satisifed only because priority=1
is the lowest priority asks for partition=y.

bq. testLabeledResourceRequestsGetPreferrenceInHierarchyOfQueue
Renamed to testPreferenceOfQueuesTowardsNodePartitions

bq. testNonLabeledQueueUsesLabeledResource
Done

bq. Let's move all these node-label related tests into their own test-case.
Moved to TestNodeLabelContainerAllocation

Add more tests:
1. Added testAMContainerAllocationWillAlwaysBeExclusive to make sure AM will be always excluisve.
2. Added testQueueMaxCapacitiesWillNotBeHonoredWhenNotRespectingExclusivity to make sure max-capacities
on individual queues ignored when doing ignore exclusivity allocation

* Main code comments from Jian: *
bq. Merge queue#needResource and application#needResource
Done, now moved common implementation to SchedulerUtils.hasPendingResourceRequest

bq. Merge queue#needResource and application#needResource
Done

bq. Some methods like canAssignToThisQueue where both nodeLabels and exclusiveType are passed,
it may be simplified by passing the current partitionToAllocate to simplify the internal if/else
check.
Actually, it will not simplify logic too much, I checked there're only few places can leverage
nodePartitionToLookAt, I perfer to keep semantics of SchedulingMode

bq. The following may be incorrect, as the current request may be not the AM container request,
though null == rmAppAttempt.getMasterContainer()
I understand masterContainer could be async initialized in RMApp, but the interval could be
ignored, doing the null check here can make sure AM container isn't get allocated.

bq. below if/else can be avoided if passing the nodePartition into queueCapacities.getAbsoluteCapacity(nodePartition),
Done

bq. the second limit won’t be hit?
Yeah, it will not be hit, but set it to be "maxUserLimit" will enhance readability.

bq. nonExclusiveSchedulingOpportunities#setCount -> add(Priority)
Done

Attached new patch (ver.3)

> CapacityScheduler side changes to support non-exclusive node labels
> -------------------------------------------------------------------
>
>                 Key: YARN-3361
>                 URL: https://issues.apache.org/jira/browse/YARN-3361
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: capacityscheduler
>            Reporter: Wangda Tan
>            Assignee: Wangda Tan
>         Attachments: YARN-3361.1.patch, YARN-3361.2.patch, YARN-3361.3.patch
>
>
> According to design doc attached in YARN-3214, we need implement following logic in CapacityScheduler:
> 1) When allocate a resource request with no node-label specified, it should get preferentially
allocated to node without labels.
> 2) When there're some available resource in a node with label, they can be used by applications
with following order:
> - Applications under queues which can access the label and ask for same labeled resource.

> - Applications under queues which can access the label and ask for non-labeled resource.
> - Applications under queues cannot access the label and ask for non-labeled resource.
> 3) Expose necessary information that can be used by preemption policy to make preemption
decisions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message