[
https://issues.apache.org/jira/browse/YARN-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16304021#comment-16304021
]
Konstantinos Karanasos edited comment on YARN-7682 at 12/26/17 9:10 PM:
------------------------------------------------------------------------
Thanks for the initial patch [~pgaref]. Some comments:
* If we want to make the canAssign be part of the PCM, I think we should make
the tags manager be a field of the PCM rather than passing it as a parameter
(i.e., pass the tag manager during PCM's initialization). The way it is right
now it feels like a utility method that was pushed inside the PCM. If we do
this change, the tags manager will be a fundamental part of the PCM so it will
look better.
* Transformations for the non-composite placement constraints are already
there. What we can add later is transforming composite constraints to DNF, but
that should not be needed for the initial versions. We can assume the
constraint tree has depth=1 for now.
* That said, we should already support all simple constraints, like [~asuresh]
says. That is, affinity, anti-affinity, cardinality. If we just support the
Simple Constraint and transform all constraints to that (with the existing
transformations), we should be fine for most use cases. But only anti-affinity
seems too restrictive (and I dont see complexity increasing by adding the other
simple constraints).
* We can support composite constraints as a second step (including delayed or).
Let's get a first version with all simple constraints though.
* I would call the method
isSatisfiable/satisfyConstraints/canSatisfyConstraints or sth similar, given
that it checks for constraint satisfiability.
* What about rack scope, given YARN-7653 is there? The API should support it
(i.e., support different node groups), even if we dont support rack at the
first cut.
was (Author: kkaranasos):
Thanks for the initial patch [~pgaref]. Some comments:
* If we want to make the canAssign be part of the PCM, I think we should make
the tags manager be a field of the PCM rather than passing it as a parameter
(i.e., pass the tag manager during PCM's initialization). The way it is right
now it feels like a utility method that was pushed inside the PCM. If we do
this change, the tags manager will be a fundamental part of the PCM so it will
look better.
* Transformations for the non-composite placement constraints are already
there. What we can add later is transforming composite constraints to DNF, but
that should not be needed for the initial versions. We can assume the
constraint tree has depth=1 for now.
* That said, we should already support all simple constraints, like [~asuresh]
says. That is, affinity, anti-affinity, cardinality. If we just support the
Simple Constraint and transform all constraints to that (with the existing
transformations), we should be fine for most use cases. But only anti-affinity
seems too restrictive (and I dont see complexity increasing by adding the other
simple constraints).
* We can support composite constraints as a second step (including delayed or).
Let's get a first version with all simple constraints though.
* I would call the method
isSatisfiable/satisfyConstraints/canSatisfyConstraints or sth similar, given
that it checks for constraint satisfiability.
* What about rack scope, given YARN-7653 is there? The API should support it
(i.e.m support different node groups), even if we dont support rack at the
first cut.
> Expose canAssign method in the PlacementConstraintManager
> ---------------------------------------------------------
>
> Key: YARN-7682
> URL: https://issues.apache.org/jira/browse/YARN-7682
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Arun Suresh
> Assignee: Panagiotis Garefalakis
> Attachments: YARN-7682.wip.patch
>
>
> As per discussion in YARN-7613. Lets expose {{canAssign}} method in the
> PlacementConstraintManager that takes a sourceTags, applicationId,
> SchedulerNode and AllocationTagsManager and returns true if constraints are
> not violated by placing the container on the node.
> I prefer not passing in the SchedulingRequest, since it can have > 1
> numAllocations. We want this api to be called for single allocations.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
