YARN-11970: Clearing the node with port zero as well when unassign a node from label - #8635
YARN-11970: Clearing the node with port zero as well when unassign a node from label#8635Hean-Chhinling wants to merge 8 commits into
Conversation
|
💔 -1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
|
🎊 +1 overall
This message was automatically generated. |
| const nodeToLabelsReplacement = [{ nodeId, labels }]; | ||
|
|
||
| if (!labelName) { | ||
| const [host, port] = nodeId.split(':'); |
There was a problem hiding this comment.
In the future, if YARN fully supports IPv6, this code could become a problem.
Could you please make it compatible with IPv6 literals?
There was a problem hiding this comment.
Thank for the review, @K0K0V0K.
I have added to check the lastIndex instead to support Ipv6 as well.
|
💔 -1 overall
This message was automatically generated. |
|
🎊 +1 overall
This message was automatically generated. |
|
Hello @K0K0V0K, And @brumi1024 could I ask for your review as well? |
slfan1989
left a comment
There was a problem hiding this comment.
host:0 is a host-wide wildcard mapping in CommonNodeLabelsManager, rather than merely a duplicate entry for the selected NodeManager. Replacing it with an empty label set updates every NM on that host.
YARN also allows the wildcard and an explicit NM assignment to differ, for example:
host:0 -> p1
host:8041 -> p2
host:8042 -> p1
With the current check, unassigning host:8041 also sends host:0 -> [], which removes p1 from the host and affects the other NM even though the user only changed host:8041.
Could we distinguish whether the wildcard mapping actually represents the assignment being removed and preserve it when other or different host-level assignments exist? Please add regression coverage for a different wildcard label and for multiple NMs on the same host.
…me host use it before removing the wildcard NM
|
Thank you so much @slfan1989 for the review! I have updated the code in my latest commit to check whether there is other NM on the same host and whether the label is the same before removing. I have tested locally and written unit tests for it. Please let me know what do you think! |
|
🎊 +1 overall
This message was automatically generated. |
Description of PR
yarn rmadmin -addToClusterNodeLabels "label3"yarn rmadmin -replaceLabelsOnNode "nodeId,label3"From
{rm_host}/ws/v1/cluster/get-node-to-labelsTherefore, YARN Capacity Scheduler UI should check and clear port zero as well.
Otherwise, the label could not be removed via the UI.
How was this patch tested?
Tested locally:
I could remove the label as expected.
For code changes:
LICENSE,LICENSE-binary,NOTICE-binaryfiles?AI Tooling
If an AI tool was used:
where is the name of the AI tool used.
https://www.apache.org/legal/generative-tooling.html