hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Junping Du (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3304) ResourceCalculatorProcessTree#getCpuUsagePercent default return value is inconsistent with other getters
Date Tue, 24 Mar 2015 11:59:54 GMT

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

Junping Du commented on YARN-3304:
----------------------------------

Thanks for comments, [~kasha]!
bq. 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.
Agree on the priority here. However, having consistent and reasonable return values doesn't
have to break compatibility (or consistent behaviors) - just like the way I proposed above,
we can consistently return resource value to 0 if they are unavailable and we have an additional
flag to mark if resource is available or not. 

bq. 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.
I agree both ways can work. However, I think adding a boolean method sounds better, at least
former. More important, it doesn't break any consistent behavior of previous releases. We
don't need to break it if we don't have to. Isn't it?

bq. 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. 
My idea is simple here: a fast-moving, regular and predictable release train could benefit
our community and ecosystem in many aspects. I also have other wish list that cannot catch
up 2.7. When this patch get in, I am not sure if YARN-3392 is still a blocker for 2.7 and
I would also prefer a fix rather than a pending JIRA there delay the release unnecessarily.
[~vinodkv], [~kasha] and [~adhoot], what do you think?

> 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
(v6.3.4#6332)

Mime
View raw message