[
https://issues.apache.org/jira/browse/YARN-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15719686#comment-15719686
]
Varun Saxena commented on YARN-3409:
------------------------------------
Thanks [~kkaranasos], [~leftnoteasy] and [~devaraj.k] for the feedback.
bq. On a similar note, can these ContraintNodeLabels be added/removed
dynamically? For example, when a container starts its execution, it might
contain some attributes (to be added – I know such attributes cannot be
specified at the moment). Those attributes will then be added to the node's
labels, for the time the container is running. This can be useful for
(anti-)affinity constraints. For instance, a task can add the label
"HBase-master", and then another resource request can have a constraint of the
form "don't put me at a node with an HBase-master label". What do you think ?
I think this is a very good suggestion and although the current design does not
capture it, we should add support for adding/removing constraint node labels
dynamically.
Wangda,
For 1, I would prefer choice b as well i.e. have a separate field. Also,
current node label is more like a resource pool/partition for me. As you said,
we may need to deprecate nodeLabelExpression. I guess we may have to rename it
with a more suitable name then.
For 2, we can use the same object or an extension of it internally to minimise
code changes.
But constraints will also have types. Say, boolean or string or numerical(long,
int, etc.). Matching of constraints will also be based on type.
To me, they are distinct enough in behaviour and the way they are defined. So,
I would personally prefer to have separate external interfaces for them.
Thoughts ?
> Add constraint node labels
> --------------------------
>
> Key: YARN-3409
> URL: https://issues.apache.org/jira/browse/YARN-3409
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: api, capacityscheduler, client
> Reporter: Wangda Tan
> Assignee: Naganarasimha G R
> Attachments: Constraint-Node-Labels-Requirements-Design-doc_v1.pdf
>
>
> Specify only one label for each node (IAW, partition a cluster) is a way to
> determinate how resources of a special set of nodes could be shared by a
> group of entities (like teams, departments, etc.). Partitions of a cluster
> has following characteristics:
> - Cluster divided to several disjoint sub clusters.
> - ACL/priority can apply on partition (Only market team / marke team has
> priority to use the partition).
> - Percentage of capacities can apply on partition (Market team has 40%
> minimum capacity and Dev team has 60% of minimum capacity of the partition).
> Constraints are orthogonal to partition, they’re describing attributes of
> node’s hardware/software just for affinity. Some example of constraints:
> - glibc version
> - JDK version
> - Type of CPU (x86_64/i686)
> - Type of OS (windows, linux, etc.)
> With this, application can be able to ask for resource has (glibc.version >=
> 2.20 && JDK.version >= 8u20 && x86_64).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
