YARN-11964: Clamp negative available resources in AllocateResponse to zero#8523
Conversation
|
🎊 +1 overall
This message was automatically generated. |
|
@ryukobayashi, the |
|
@pan3793 Yes, I tried again as you suggested, but it failed. So, could you review this? |
|
🎊 +1 overall
This message was automatically generated. |
|
@ryukobayashi the mr failure is related to your change, try debugging locally. |
|
@ryukobayashi I’ll take a look at this PR today and share my feedback later. |
|
@pan3793 Thanks, I identified and fixed the parts where NPE was occurring. |
|
🎊 +1 overall
This message was automatically generated. |
|
@pan3793 @slfan1989 It seems the CI has passed, so could you please review it? |
slfan1989
left a comment
There was a problem hiding this comment.
Thanks for the update. Applying the clamp while constructing AllocateResponse is the correct scope and avoids changing the semantics of the general-purpose Resource conversion methods. The null handling also preserves the previous behavior, and the latest CI results are clean. +1.
A few non-blocking suggestions:
-
The PR description links #8519 as the revert, but that PR is unrelated. Please link the actual revert commit (
9c865dd01fb) instead. -
Since the latest change fixes a null
resourceLimitregression, it would be helpful to add a test that explicitly verifies the null path does not throw and preserves a null available-resource value.
|
@slfan1989 Thanks for your review. I've fixed both. |
|
🎊 +1 overall
This message was automatically generated. |
|
@ryukobayashi Thanks for the contribution! Merge into trunk. @pan3793 Thanks for the review! |
Description of PR
YARN RM can transiently report negative available resources (e.g. cluster_capacity - allocated goes negative due to overload or node failures).
DefaultAMSProcessornow appliesResources.componentwiseMaxwithResources.none()before setting available resources inAllocateResponse, ensuring the AM always receives a non-negative value.This is a re-implementation of YARN-11964 (reverted in 9c865dd). The previous fix applied the clamp inside
Resource.castToIntSafely(), which was too broad and caused a regression inTestRLESparseResourceAllocation. This fix applies the clamp at the correct layer — inDefaultAMSProcessorwhere theAllocateResponseis built.Contains content generated by Claude (Anthropic)
How was this patch tested?
TestDefaultAMSProcessor#testAvailableResourcesClampedToNonNegativewhich uses a custom scheduler that returns a negative resource limit and verifies theAllocateResponsealways contains non-negative available resources.TestApplicationMasterServiceCapacity,TestApplicationMasterServiceFair,TestApplicationMasterServiceInterceptor,TestRLESparseResourceAllocation.For code changes:
LICENSE,LICENSE-binary,NOTICE-binaryfiles?AI Tooling
https://www.apache.org/legal/generative-tooling.html