Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 9 Dec 2016 19:30:59 +0000 (UTC)
From: "Wangda Tan (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12662451.1375899092000.485649.1481311859610@Atlassian.JIRA>
In-Reply-To: <JIRA.12662451.1375899092000@Atlassian.JIRA>
References: <JIRA.12662451.1375899092000@Atlassian.JIRA> <JIRA.12662451.1375899092724@arcas>
Subject: [jira] [Commented] (YARN-1042) add ability to specify
 affinity/anti-affinity in container requests
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 09 Dec 2016 19:31:01 -0000


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

Wangda Tan commented on YARN-1042:
----------------------------------

Thanks [~kkaranasos] for these suggestions.

I agree to merge the implementation in scheduler to support affinity and anti-affinity, we should not have duplicated code to support both of (anti-)affinity.

However, personally I'm not in favor of min-cardinality / max-cardinality, two reasons:
1) Comparing to affinity-to / anti-affinity-to, it is not straightforward enough to a normal YARN user. (of course, it is easy for a PhD :p)
2) We have to tradeoff between syntax flexibility and feature availability. Users will be happy if YARN allow them to specify as many constraints as they want, but they will be soon frustrated if we cannot give them in time. For example, user can specify allocate min=10/max=10 MPI tasks each host, but in reality, it could be quite hard in a busy cluster. And it gonna be hard for YARN to optimize such constraints, for example, how to preempt containers to satisfy min=max=10 cardinality.

I have a simpler suggestion to handle most possible use cases as the first step. Which is:
- Extend existing ResourceRequest, by adding a new {{placementConstraintExpression}}
- Simple anti-affinity (min=max=1)
- Simple affinity (min=2,max=infinity)
- Within app and between app
- Once tags are allowed to specified in ResourceRequest, we can support (anti-)affinity for tags

The API could looks like:
- {{affinity-to app=app_1234_0002}}
- {{anti-affinity-to app=app_1234_0002}}
- {{anti-affinity-to tag="Hbase-master"}}
- {{anti-affinity-to app=app_1234_0002,tag="HBase-master"}}

And more rich syntax (like affinity to rack / cluster, etc.) we can think more when doing YARN-4902.

> add ability to specify affinity/anti-affinity in container requests
> -------------------------------------------------------------------
>
>                 Key: YARN-1042
>                 URL: https://issues.apache.org/jira/browse/YARN-1042
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: resourcemanager
>    Affects Versions: 3.0.0-alpha1
>            Reporter: Steve Loughran
>            Assignee: Wangda Tan
>         Attachments: YARN-1042-demo.patch, YARN-1042-design-doc.pdf, YARN-1042-global-scheduling.poc.1.patch, YARN-1042.001.patch, YARN-1042.002.patch
>
>
> container requests to the AM should be able to request anti-affinity to ensure that things like Region Servers don't come up on the same failure zones. 
> Similarly, you may be able to want to specify affinity to same host or rack without specifying which specific host/rack. Example: bringing up a small giraph cluster in a large YARN cluster would benefit from having the processes in the same rack purely for bandwidth reasons.


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

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org