Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Fri, 10 Apr 2015 01:00:16 +0000 (UTC)
From: "Jian He (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12782689.1426626406000.48382.1428627616505@Atlassian.JIRA>
In-Reply-To: <JIRA.12782689.1426626406000@Atlassian.JIRA>
References: <JIRA.12782689.1426626406000@Atlassian.JIRA>
 <JIRA.12782689.1426626406320@arcas>
Subject: [jira] [Commented] (YARN-3361) CapacityScheduler side changes to
 support non-exclusive node labels
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/YARN-3361?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D14488=
681#comment-14488681 ]=20

Jian He commented on YARN-3361:
-------------------------------

thanks for updating, looks good overall:
- fix SchedulingMode comments=20
- simplify a bit=EF=BC=8Cparametrize nodePartitionToLookAt into hasPendingR=
esourceRequest method
{code}
    if (schedulingMode =3D=3D SchedulingMode.RESPECT_PARTITION_EXCLUSIVITY)=
 {
      return hasPendingResourceRequest(rc, usage, nodePartitionToLookAt,
          cluster);
    } else if (schedulingMode =3D=3D SchedulingMode.IGNORE_PARTITION_EXCLUS=
IVITY) {
      return hasPendingResourceRequest(rc, usage, RMNodeLabelsManager.NO_LA=
BEL,
          cluster);
    }
{code}

- Below two checks in two places are duplicated ? the first check will prev=
ent the second check=E2=80=99s unreserve to execute?
         =20
{code}
          // Is the node-label-expression of this offswitch resource reques=
t
          // matches the node's label?
          // If not match, jump to next priority.
          if (!SchedulerUtils.checkResourceRequestMatchingNodePartition(
              anyRequest, node.getPartition(), schedulingMode)) {
            continue;
          }


    // check if the resource request can access the label
    if (!SchedulerUtils.checkNodeLabelExpression(node.getLabels(),
        request.getNodeLabelExpression(), schedulingMode)) {
      return Resources.none();
    }
{code}
- revert FicaSchedulerApp change
- remove minimumSchedulingOpportunityForNonExclusive variable,
- looks like for each partitioned request on partitioned node, we are check=
ing it twice. one on partitioned_scheduling, the other on non_partitioned_s=
cheduling; Probably we need a higher level mapping for resource requests: (=
partition -> all requests) to avoid double checking for partitioned request=
s.

> CapacityScheduler side changes to support non-exclusive node labels
> -------------------------------------------------------------------
>
>                 Key: YARN-3361
>                 URL: https://issues.apache.org/jira/browse/YARN-3361
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: capacityscheduler
>            Reporter: Wangda Tan
>            Assignee: Wangda Tan
>         Attachments: YARN-3361.1.patch, YARN-3361.2.patch, YARN-3361.3.pa=
tch, YARN-3361.4.patch, YARN-3361.5.patch
>
>
> According to design doc attached in YARN-3214, we need implement followin=
g logic in CapacityScheduler:
> 1) When allocate a resource request with no node-label specified, it shou=
ld get preferentially allocated to node without labels.
> 2) When there're some available resource in a node with label, they can b=
e used by applications with following order:
> - Applications under queues which can access the label and ask for same l=
abeled resource.=20
> - Applications under queues which can access the label and ask for non-la=
beled resource.
> - Applications under queues cannot access the label and ask for non-label=
ed resource.
> 3) Expose necessary information that can be used by preemption policy to =
make preemption decisions.


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