[
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 this.
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
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
