hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Subru Krishnan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3800) Simplify inmemory state for ReservationAllocation
Date Wed, 24 Jun 2015 00:02:17 GMT

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

Subru Krishnan commented on YARN-3800:

Thanks [~adhoot] for the updated patch. Overall it looks good, a few minor nits:
   * Can we rename _ReservationUtil_ to _ReservationSystemUtil_ to avoid confusion.
   * In _TestInMemoryPlan_, can we use *allocations* instead of *allocs* to minimize the diff.
   * In _TestInMemoryReservationAllocation_, we can continue using the previous constructor
for non-gang allocations as the flag is required only for gang.
   * There is a redundant format change in _TestInMemoryReservationAllocation_ :
bq. -    Assert.assertEquals(allocations, rAllocation.getAllocationRequests());
+    Assert.assertEquals(allocations,
+        rAllocation.getAllocationRequests());

> Simplify inmemory state for ReservationAllocation
> -------------------------------------------------
>                 Key: YARN-3800
>                 URL: https://issues.apache.org/jira/browse/YARN-3800
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: capacityscheduler, fairscheduler, resourcemanager
>            Reporter: Anubhav Dhoot
>            Assignee: Anubhav Dhoot
>         Attachments: YARN-3800.001.patch, YARN-3800.002.patch, YARN-3800.002.patch, YARN-3800.003.patch
> Instead of storing the ReservationRequest we store the Resource for allocations, as thats
the only thing we need. Ultimately we convert everything to resources anyway

This message was sent by Atlassian JIRA

View raw message