[ 
https://issues.apache.org/jira/browse/YARN-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15796153#comment-15796153
 ] 

Wangda Tan commented on YARN-6022:
----------------------------------

[~kasha] / [~asuresh], 

Missed your last comment somehow, apologize for the last reply. Since this is 
not included by branch-2.8, so we should have enough time to change it.

I want to revert the change because two part:
1) It makes a stable API inherit from an unstable API, which is very confusing. 
Even if we don't want user to use the AbstractRR, but it is unavoidable. 
According to API definition, user should write code like:
{code}
AbstractResourceRequest r = new ResourceRequest(...);
r.setCapability(..._
{code}

Apparently we don't want user to do things like this because AbstractRR could 
be changed. 

2) Most importantly, it is not necessary. YARN-5774 only requires scheduler 
returns normalized resource instead of update resource inside a given resource 
request. To me, we should avoid changing user-facing API because of internal 
implementation, this change is completely avoidable. I suggest to keep the 
original API. 

Thoughts?

> Revert changes of AbstractResourceRequest
> -----------------------------------------
>
>                 Key: YARN-6022
>                 URL: https://issues.apache.org/jira/browse/YARN-6022
>             Project: Hadoop YARN
>          Issue Type: Bug
>            Reporter: Wangda Tan
>            Priority: Blocker
>
> YARN-5774 added AbstractResourceRequest to make easier internal scheduler 
> change, this is not a correct approach: For example, with this change, we 
> need to make AbstractResourceRequest to be public/stable. And end users can 
> use it like:
> {code}
> AbstractResourceRequest request = ...
> request.setCapability(...)
> {code}
> But AbstractResourceRequest should not be visible by application at all. 
> We need to revert it from branch-2.8 / branch-2 / trunk. 



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

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to