[
https://issues.apache.org/jira/browse/YARN-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16819467#comment-16819467
]
Kuhu Shukla commented on YARN-9202:
-----------------------------------
I do not think we can get away with creating new RMNodeImpl objects since
anything that has not registered may not have valid values for cmPort and
NmVersion and other fields that are populated through the constructor only upon
registration. Even for the case where we could just have the REST APIs return
state in new state, the issue is that none of the lists that the webservice has
access to have nodes in new state. [~eepayne], appreciate thoughts on how to
move forward on this given this inherent design of RMNodeImpl. I could expose
some fields and add setters to get over this issue but I am not sure if that is
the right way to proceed.
> RM does not track nodes that are in the include list and never register
> -----------------------------------------------------------------------
>
> Key: YARN-9202
> URL: https://issues.apache.org/jira/browse/YARN-9202
> Project: Hadoop YARN
> Issue Type: Bug
> Affects Versions: 2.9.2, 3.0.3, 2.8.5
> Reporter: Kuhu Shukla
> Assignee: Kuhu Shukla
> Priority: Major
> Attachments: YARN-9202.001.patch
>
>
> The RM state machine decides to put new or running nodes in inactive state
> only past the point of either registration or being in the exclude list. This
> does not cover the case where a node is the in the include list but never
> registers and since all state changes are based on these NodeState
> transitions, having NEW nodes be listed as inactive first may help. This
> would change the semantics of how inactiveNodes are looked at today. Another
> state addition might help this case too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
