Karthik Kambatla commented on YARN-3304:

bq. That's an incompatible change which sounds not necessary for now.
In previous releases, we have never called these APIs Public even if they were 
intended to be sub-classed. In my mind, this is the last opportunity to decide 
on what the API should do? I think consistent and reasonable return values 
should be given a higher priority over compatibility. 

bq. May be we don't have to leverage "-1" in resource usage to distinguish 
unavailable case? e.g. we can have some boolean value to identify the resource 
is available or not which sounds more correct than using odd value like Karthik 
Kambatla mentioned before.

I am okay with adding boolean methods to capture unavailability, but that seems 
a little overboard. Using -1 in the ResourceCalculatorProcessTree is okay by 
me. My concern was with logging this -1 value in the metrics. In either case, I 
would like for the container usage metrics to see if the usage is available 
before logging the same.

bq. So I propose to go patch here (after fixing a minor test failure) in 2.7 
given this is a blocker and we can fix YARN-3392 later in 2.8. Thoughts?
Since it is not too much work or risk, I would prefer we fix both in 2.7. This 
is solely wearing my Apache hat on. My Cloudera hat doesn't really mind it 
being in 2.8 vs 2.7. 

> ResourceCalculatorProcessTree#getCpuUsagePercent default return value is 
> inconsistent with other getters
> --------------------------------------------------------------------------------------------------------
>                 Key: YARN-3304
>                 URL: https://issues.apache.org/jira/browse/YARN-3304
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: nodemanager
>            Reporter: Junping Du
>            Assignee: Karthik Kambatla
>            Priority: Blocker
>         Attachments: YARN-3304-v2.patch, YARN-3304.patch
> Per discussions in YARN-3296, getCpuUsagePercent() will return -1 for 
> unavailable case while other resource metrics are return 0 in the same case 
> which sounds inconsistent.

This message was sent by Atlassian JIRA

Reply via email to