You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Kuhu Shukla (JIRA)" <ji...@apache.org> on 2019/04/16 20:36:00 UTC

[jira] [Commented] (YARN-9202) RM does not track nodes that are in the include list and never register

    [ 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: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org