[
https://issues.apache.org/jira/browse/YARN-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15726911#comment-15726911
]
Wangda Tan commented on YARN-3409:
----------------------------------
Thanks [~naganarasimha...@apache.org], my responses:
bq. the above example x.y.z-build which you gave doesnt fit in long array right
? suppose we some how come with a pattern to match these stuff with a internal
structure, how many such patterns we need to support and how to verify patterns
against other patterns ?
This is what I want to avoid actually, we should only support limited version
format, for example a.b.c.d and a.b.c-d. In my mind, this is just a node
attribute instead of a new programming language, we should make this can be
easily used as much as we can. I would prefer not to add customer-defined types
here. (Extensibility in our internal code implementation is different, we
should make implementations to be easily changed, but not visible by user).
If user have different version format, (such as r0009 or ~a.b.c), they can
either reformat them or treat them as string.
bq. all these scenarios captured are of non consumeable resources types, hence
cannot be addressed as another resource type (so as to solve through resource
profiles).
No they're actually all consumable resources, for example, if an app want to
have more disk size or bandwidth, it should be a part of the resource request
(YARN-3926) instead of tell YARN "run me on a node with 12 disks". The 12 disks
means nothing to the app because node is a shared environment.
Similarly, network interface should be either constraint (like if the node
support multi-homing), or it is a resource (how many net interface you want)
MAX_MEM should not be part of client, this should be planned by scheduler: why
the app only need 2G mem but asked to run a node with 128G mem? This could lead
cluster fragmentation to worse.
bq. how to capture internal type as long/ string or any other custom type ?
We could have a preprocess stage to set long[] for a given constraint value
when adding the constraint.
bq. if its inherent logic and if it doesnt match what user intended then none
of the resource requests matches or lead to undesired allocations.
Like you mentioned in above comment, If comparison op applied on two object,
one is string and one is long[], it will never match. If we compare two long[]
but with different length, we can do padding on the shorter array.
bq. Agree that Boolean can be acheived with String itself and for DATE might
not be immediately required but consider for date different formats of parsing
to be supported.
That is what I want to avoid, user A want MM-DD-YY, user B want YYYY-MM-DD;
And same for version, so we could have a lot of customized type
implementations, and then we have to manage these implementations, it is very
nature for a user to add new type and remove old types. We may need to provide
API to do that, etc.
The simplest way is let user handling all these stuffs. String+regex itself
should be able to handle most of DATE related use cases.
bq. And also consider the scenario where in we want to schedule on the node
where load average for past (1/5/15) mins is less than a particular value?
IMHO, it is an abuse usage of node constraint, node constraint should be
targeted to static properties of a node, and all the dynamic stuffs shouldn't
visible by end user. Supporting stuffs like "on the node where load average for
past (1/5/15) mins" will be very hard to be optimized. It should be a pluggable
scheduling policy instead of a hard coded constraint.
bq. All these kinds non consumables resources are supported in one way or the
other in other schedulers
Could you add some references here? I checked a couple of schedulers but I
didn't find a popular scheduler support customized type.
bq. Well is it heavy in terms of implementation or usage? As we keep string as
the default type in usage front its pretty simple and implementation and
maintainence front i dont see too much of a problem other than changes which is
required on the existing labels.
Both, but the impact on the usage is more serious to me: It requires user to
specify type of label upfront, and all the constraint with the same name
enforced to have the same type, it creates new problems such as:
- Change type of constraint
- Remove/Add constraint (Remove constraint need to check if it is associate
with other node, etc.)
If it doesn't have type, we can simply remove constraint when ref# becomes 0.
And unavoidabily, if customized type is available to user, we have to maintain
the public constraint-type interface in the future.
bq. IMHO I would like it to be flexible enough for future scenarios too hence i
would still prefer for Constraint Type.
I didn't see a must-to-have future scenario requires this.
> 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,
> YARN-3409.WIP.001.patch
>
>
> 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
