hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantinos Karanasos (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-6593) [API] Introduce Placement Constraint object
Date Wed, 17 May 2017 22:02:04 GMT

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

Konstantinos Karanasos commented on YARN-6593:

Thanks for the feedback, [~leftnoteasy].

Agreed with points (2), (3), (5), and (6) -- will fix them and update the patch.

Regarding the rest:
bq. PlacementConstraint should be parent class of CompoundPlacementConstraint/SimplePlacementConstraint.
Now it added one additional hierarchy to each node in the tree.
Can you explain a bit more what you mean here? 
My goal was to allow arbitrary nesting of compound placement constraints. Given that the protobuf
version that we use does not allow subclassing, don't think there is a cleaner way of achieving

bq. Suggest to follow what we defined in doc, add two separate classes TargetConstraint​/CardinalityConstraint​,
both extends PlacementConstraint. Limit to use 2 out of 3 fields is hard for app developer
to understand/use.
I added the ConstraintType to show the different types of simple placement constraints, namely
target and cardinality (again, given the lack of subclassing in protobuf). Moreover, I wanted
to allow later to add constraints that include all three fields, like we mention in the document
for cluster admin constraints.
I think we can restrict the use of the right fields at each time through the newInstance methods,
like I do currently in the patch.
But to make it more clear, how about we add a Builder that allows the creation only of targetConstraint()
and cardinalityConstraint()? This way we use a SimplePlacementConstraint, but allow creating
specific types of simple constraints.

bq. I suggest treat allocationTags as value, and key of allocationTags is always empty.
Yep, agreed with that. My question was more about how do we validate constraints. I think
we should create a validator class, so that we can parse the constraints and decide if they
are of the correct format. One example is to not allow a targetKey when you specify a constraint
with allocation tags. Another could be to allow ORDERED_OR expressions to be only on top of
the hierarchy, etc. Was discussing that yesterday with [~asuresh] too. Of course this is not
urgent, but would be good to have. Thoughts?

> [API] Introduce Placement Constraint object
> -------------------------------------------
>                 Key: YARN-6593
>                 URL: https://issues.apache.org/jira/browse/YARN-6593
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Konstantinos Karanasos
>            Assignee: Konstantinos Karanasos
>         Attachments: YARN-6593.001.patch
> This JIRA introduces an object for defining placement constraints.

This message was sent by Atlassian JIRA

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

View raw message