[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[ https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347118#comment-16347118 ] Hudson commented on YARN-7783: -- SUCCESS: Integrated in Jenkins build Hadoop-trunk-Commit #13589 (See [https://builds.apache.org/job/Hadoop-trunk-Commit/13589/]) YARN-7783. Add validation step to ensure constraints are not violated (arun suresh: rev a4c539fcdba817e313b2375abf2c4c9a1d13a4fd) * (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/constraint/algorithm/DefaultPlacementAlgorithm.java * (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/constraint/TestPlacementProcessor.java > Add validation step to ensure constraints are not violated due to order in > which a request is processed > --- > > Key: YARN-7783 > URL: https://issues.apache.org/jira/browse/YARN-7783 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Arun Suresh >Assignee: Arun Suresh >Priority: Blocker > Fix For: YARN-6592 > > Attachments: YARN-7783-YARN-6592.001.patch, > YARN-7783-YARN-6592.002.patch, YARN-7783-YARN-6592.003.patch, > YARN-7783-YARN-6592.004.patch > > > When the algorithm has placed a container on a node, allocation tags are > added to the node if the constraint is satisfied, But depending on the order > in which the algorithm sees the request, it is possible that a constraint > that happen to be valid during placement of an earlier-seen request, might > not be valid after all subsequent requests have been placed. > For eg: > Assume nodes n1, n2, n3, n4 and n5 > Consider the 2 constraints: > # *foo* -> anti-affinity with *foo* > # *bar* -> anti-affinity with *foo* > And 2 requests > # req1: NumAllocations = 4, allocTags = [foo] > # req2: NumAllocations = 1, allocTags = [bar] > If *req1* is seen first, the algorithm can place the 4 containers in n1, n2, > n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the > *foo* tag and will place it on n5. But if *req2* is seen first, then *bar* > tag will be placed on any node, since no node will at that point have *foo*, > and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*, > the algorithm can end up placing *foo* on a node with *bar* violating the > second constraint. > To prevent the above, we need a validation step: after the placements for a > batch of requests are made, then for each req, we remove its tags from the > node and try to see of constraints are still satisfied if the tag were to be > added back on the node. > When applied to the example above, after the algorithm has run through *req2* > and then *req1*, we remove the *bar* tag from the node and try to add it back > on the node. This time, constraint satisfaction will fail, since there is now > a *foo* tag on the node and *bar* cannot be added. The algorithm will then > retry placing *req2* on another node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[ https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336832#comment-16336832 ] Weiwei Yang commented on YARN-7783: --- Hi [~asuresh] It makes sense to me, +1 to get the short term solution in and lets do not block the merge. At the same time, I have opened YARN-7800 and loop you guys in to seek for an optimal solution. Thanks. > Add validation step to ensure constraints are not violated due to order in > which a request is processed > --- > > Key: YARN-7783 > URL: https://issues.apache.org/jira/browse/YARN-7783 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Arun Suresh >Assignee: Arun Suresh >Priority: Blocker > Attachments: YARN-7783-YARN-6592.001.patch, > YARN-7783-YARN-6592.002.patch, YARN-7783-YARN-6592.003.patch, > YARN-7783-YARN-6592.004.patch > > > When the algorithm has placed a container on a node, allocation tags are > added to the node if the constraint is satisfied, But depending on the order > in which the algorithm sees the request, it is possible that a constraint > that happen to be valid during placement of an earlier-seen request, might > not be valid after all subsequent requests have been placed. > For eg: > Assume nodes n1, n2, n3, n4 and n5 > Consider the 2 constraints: > # *foo* -> anti-affinity with *foo* > # *bar* -> anti-affinity with *foo* > And 2 requests > # req1: NumAllocations = 4, allocTags = [foo] > # req2: NumAllocations = 1, allocTags = [bar] > If *req1* is seen first, the algorithm can place the 4 containers in n1, n2, > n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the > *foo* tag and will place it on n5. But if *req2* is seen first, then *bar* > tag will be placed on any node, since no node will at that point have *foo*, > and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*, > the algorithm can end up placing *foo* on a node with *bar* violating the > second constraint. > To prevent the above, we need a validation step: after the placements for a > batch of requests are made, then for each req, we remove its tags from the > node and try to see of constraints are still satisfied if the tag were to be > added back on the node. > When applied to the example above, after the algorithm has run through *req2* > and then *req1*, we remove the *bar* tag from the node and try to add it back > on the node. This time, constraint satisfaction will fail, since there is now > a *foo* tag on the node and *bar* cannot be added. The algorithm will then > retry placing *req2* on another node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[ https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336820#comment-16336820 ] Arun Suresh commented on YARN-7783: --- [~cheersyang], w.r.t your idea of binding node constraints - I like the idea. Do open a JIRA and we can iterate - but lets do that after merge. We should do it in conjunction with YARN-6621, where we validate at constraint registration time. bq. One more concern is, when there is a lot of allocate calls, we might get too much sync'd on AllocationTagsManager, as it's been accessed more than once So prior to the patch, the ATM is called in the doPlacement method: worst case is O(n) where n = num(nodes). This patch adds the validate method which makes 2 extra calls to the ATM - but the validate method gets called for every *placed* request in the previous round, which is probably an order of magnitude less than the number of nodes in a large cluster - So I don't expect a big increment in the access to the ATM. But you are right, we should do a more disciplined testing. So, if you are fine with this in the short term, can I get a +1 so we can commit this ? > Add validation step to ensure constraints are not violated due to order in > which a request is processed > --- > > Key: YARN-7783 > URL: https://issues.apache.org/jira/browse/YARN-7783 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Arun Suresh >Assignee: Arun Suresh >Priority: Blocker > Attachments: YARN-7783-YARN-6592.001.patch, > YARN-7783-YARN-6592.002.patch, YARN-7783-YARN-6592.003.patch, > YARN-7783-YARN-6592.004.patch > > > When the algorithm has placed a container on a node, allocation tags are > added to the node if the constraint is satisfied, But depending on the order > in which the algorithm sees the request, it is possible that a constraint > that happen to be valid during placement of an earlier-seen request, might > not be valid after all subsequent requests have been placed. > For eg: > Assume nodes n1, n2, n3, n4 and n5 > Consider the 2 constraints: > # *foo* -> anti-affinity with *foo* > # *bar* -> anti-affinity with *foo* > And 2 requests > # req1: NumAllocations = 4, allocTags = [foo] > # req2: NumAllocations = 1, allocTags = [bar] > If *req1* is seen first, the algorithm can place the 4 containers in n1, n2, > n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the > *foo* tag and will place it on n5. But if *req2* is seen first, then *bar* > tag will be placed on any node, since no node will at that point have *foo*, > and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*, > the algorithm can end up placing *foo* on a node with *bar* violating the > second constraint. > To prevent the above, we need a validation step: after the placements for a > batch of requests are made, then for each req, we remove its tags from the > node and try to see of constraints are still satisfied if the tag were to be > added back on the node. > When applied to the example above, after the algorithm has run through *req2* > and then *req1*, we remove the *bar* tag from the node and try to add it back > on the node. This time, constraint satisfaction will fail, since there is now > a *foo* tag on the node and *bar* cannot be added. The algorithm will then > retry placing *req2* on another node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[
https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336765#comment-16336765
]
Weiwei Yang commented on YARN-7783:
---
Hi [~asuresh]
What I suggested was to bind some enforcement constraint to a node when a
container is placed, for the request "foo" max cardinality of 3 with "bar", if
there is a foo container allocated on a node, then this node will have
this node at most have 3 "bar" tags
we don't need to make any reverse implication. But I agree both this and the
idea [~kkaranasos] mentioned are non-trivial.
{quote}Can you provide an example / counter-example where the validation scheme
proposed in this patch will not work ?
{quote}
I tried but I don't think I can at this point.
I am fine if this is a short-term solution. One more concern is, when there is
a lot of allocate calls, we might get too much sync'd on
\{{AllocationTagsManager}}, as it's been accessed more than once. We may get
into that part (perf) later, and get functionality work first.
Thanks
> Add validation step to ensure constraints are not violated due to order in
> which a request is processed
> ---
>
> Key: YARN-7783
> URL: https://issues.apache.org/jira/browse/YARN-7783
> Project: Hadoop YARN
> Issue Type: Sub-task
>Reporter: Arun Suresh
>Assignee: Arun Suresh
>Priority: Blocker
> Attachments: YARN-7783-YARN-6592.001.patch,
> YARN-7783-YARN-6592.002.patch, YARN-7783-YARN-6592.003.patch,
> YARN-7783-YARN-6592.004.patch
>
>
> When the algorithm has placed a container on a node, allocation tags are
> added to the node if the constraint is satisfied, But depending on the order
> in which the algorithm sees the request, it is possible that a constraint
> that happen to be valid during placement of an earlier-seen request, might
> not be valid after all subsequent requests have been placed.
> For eg:
> Assume nodes n1, n2, n3, n4 and n5
> Consider the 2 constraints:
> # *foo* -> anti-affinity with *foo*
> # *bar* -> anti-affinity with *foo*
> And 2 requests
> # req1: NumAllocations = 4, allocTags = [foo]
> # req2: NumAllocations = 1, allocTags = [bar]
> If *req1* is seen first, the algorithm can place the 4 containers in n1, n2,
> n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the
> *foo* tag and will place it on n5. But if *req2* is seen first, then *bar*
> tag will be placed on any node, since no node will at that point have *foo*,
> and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*,
> the algorithm can end up placing *foo* on a node with *bar* violating the
> second constraint.
> To prevent the above, we need a validation step: after the placements for a
> batch of requests are made, then for each req, we remove its tags from the
> node and try to see of constraints are still satisfied if the tag were to be
> added back on the node.
> When applied to the example above, after the algorithm has run through *req2*
> and then *req1*, we remove the *bar* tag from the node and try to add it back
> on the node. This time, constraint satisfaction will fail, since there is now
> a *foo* tag on the node and *bar* cannot be added. The algorithm will then
> retry placing *req2* on another node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[ https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336695#comment-16336695 ] Arun Suresh commented on YARN-7783: --- Yes, [~kkaranasos] also suggested validating implied constraints, at the time of placement. But inferring the reverse cardinality constraint is not straight forward. "foo" max cardinality of 3 with "bar" does not imply "bar" max cardinality of 3 with "foo" - Also it would be pretty non-trivial to implement. bq. The problem here is a circular dependency, Can you provide an example / counter-example where the validation scheme proposed in this patch will not work ? Like I said, I am open to a better approach, but for the short term: This patch handles most common cases, and given that - even though it will not give optimal placements, it DOES guarantee constraints are NOT violated (which, without this patch does not happen - which would be a bad first time user experience). And if it cant place, it will notify the AM by rejecting the request. Thoughts ? > Add validation step to ensure constraints are not violated due to order in > which a request is processed > --- > > Key: YARN-7783 > URL: https://issues.apache.org/jira/browse/YARN-7783 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Arun Suresh >Assignee: Arun Suresh >Priority: Blocker > Attachments: YARN-7783-YARN-6592.001.patch, > YARN-7783-YARN-6592.002.patch, YARN-7783-YARN-6592.003.patch, > YARN-7783-YARN-6592.004.patch > > > When the algorithm has placed a container on a node, allocation tags are > added to the node if the constraint is satisfied, But depending on the order > in which the algorithm sees the request, it is possible that a constraint > that happen to be valid during placement of an earlier-seen request, might > not be valid after all subsequent requests have been placed. > For eg: > Assume nodes n1, n2, n3, n4 and n5 > Consider the 2 constraints: > # *foo* -> anti-affinity with *foo* > # *bar* -> anti-affinity with *foo* > And 2 requests > # req1: NumAllocations = 4, allocTags = [foo] > # req2: NumAllocations = 1, allocTags = [bar] > If *req1* is seen first, the algorithm can place the 4 containers in n1, n2, > n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the > *foo* tag and will place it on n5. But if *req2* is seen first, then *bar* > tag will be placed on any node, since no node will at that point have *foo*, > and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*, > the algorithm can end up placing *foo* on a node with *bar* violating the > second constraint. > To prevent the above, we need a validation step: after the placements for a > batch of requests are made, then for each req, we remove its tags from the > node and try to see of constraints are still satisfied if the tag were to be > added back on the node. > When applied to the example above, after the algorithm has run through *req2* > and then *req1*, we remove the *bar* tag from the node and try to add it back > on the node. This time, constraint satisfaction will fail, since there is now > a *foo* tag on the node and *bar* cannot be added. The algorithm will then > retry placing *req2* on another node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[ https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336636#comment-16336636 ] Weiwei Yang commented on YARN-7783: --- Hi [~asuresh] I am +0 on the patch. It resolves the issue that you mentioned in the comment, but not seems to be general enough to me. The problem here is a circular dependency, Like in your example 1) "foo", anti-affinity with "foo" +Implies node constraint:+ on each node, it cannot have more than 1 foo tags 2) "bar", anti-affinity with "foo" +Implies node constraint:+ on each node, it cannot have both "bar" and "foo" tags I don't think we need an extra validation phase here, instead we could optimize the place logic. By that I mean when allocate a container to a node, we also bind a *node constraint* to this node. Then if the algorithm wants to place any new container to this node, except for checking if it satisfies the placement constraint, it also check if it satisfies the node constraint. Back to your example * req2 is placed on any of nodes, e.g n2, +a node constraint[1] is added to n2 that constrains this node cannot have both "bar" and "foo" tags+ * when the algorithm wants to place req1 on n2, it checks if its placement constraint is satisfied. It should be as there is no foo container on this node yet. * Then the algorithm checks if the node constraint is satisfied. It is not because it violate node constraint [1]. Would that work? > Add validation step to ensure constraints are not violated due to order in > which a request is processed > --- > > Key: YARN-7783 > URL: https://issues.apache.org/jira/browse/YARN-7783 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Arun Suresh >Assignee: Arun Suresh >Priority: Blocker > Attachments: YARN-7783-YARN-6592.001.patch, > YARN-7783-YARN-6592.002.patch, YARN-7783-YARN-6592.003.patch, > YARN-7783-YARN-6592.004.patch > > > When the algorithm has placed a container on a node, allocation tags are > added to the node if the constraint is satisfied, But depending on the order > in which the algorithm sees the request, it is possible that a constraint > that happen to be valid during placement of an earlier-seen request, might > not be valid after all subsequent requests have been placed. > For eg: > Assume nodes n1, n2, n3, n4 and n5 > Consider the 2 constraints: > # *foo* -> anti-affinity with *foo* > # *bar* -> anti-affinity with *foo* > And 2 requests > # req1: NumAllocations = 4, allocTags = [foo] > # req2: NumAllocations = 1, allocTags = [bar] > If *req1* is seen first, the algorithm can place the 4 containers in n1, n2, > n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the > *foo* tag and will place it on n5. But if *req2* is seen first, then *bar* > tag will be placed on any node, since no node will at that point have *foo*, > and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*, > the algorithm can end up placing *foo* on a node with *bar* violating the > second constraint. > To prevent the above, we need a validation step: after the placements for a > batch of requests are made, then for each req, we remove its tags from the > node and try to see of constraints are still satisfied if the tag were to be > added back on the node. > When applied to the example above, after the algorithm has run through *req2* > and then *req1*, we remove the *bar* tag from the node and try to add it back > on the node. This time, constraint satisfaction will fail, since there is now > a *foo* tag on the node and *bar* cannot be added. The algorithm will then > retry placing *req2* on another node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[ https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335971#comment-16335971 ] Arun Suresh commented on YARN-7783: --- The test failure is unrelated. [~kkaranasos] / [~cheersyang] - can we get this in ? > Add validation step to ensure constraints are not violated due to order in > which a request is processed > --- > > Key: YARN-7783 > URL: https://issues.apache.org/jira/browse/YARN-7783 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Arun Suresh >Assignee: Arun Suresh >Priority: Blocker > Attachments: YARN-7783-YARN-6592.001.patch, > YARN-7783-YARN-6592.002.patch, YARN-7783-YARN-6592.003.patch, > YARN-7783-YARN-6592.004.patch > > > When the algorithm has placed a container on a node, allocation tags are > added to the node if the constraint is satisfied, But depending on the order > in which the algorithm sees the request, it is possible that a constraint > that happen to be valid during placement of an earlier-seen request, might > not be valid after all subsequent requests have been placed. > For eg: > Assume nodes n1, n2, n3, n4 and n5 > Consider the 2 constraints: > # *foo* -> anti-affinity with *foo* > # *bar* -> anti-affinity with *foo* > And 2 requests > # req1: NumAllocations = 4, allocTags = [foo] > # req2: NumAllocations = 1, allocTags = [bar] > If *req1* is seen first, the algorithm can place the 4 containers in n1, n2, > n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the > *foo* tag and will place it on n5. But if *req2* is seen first, then *bar* > tag will be placed on any node, since no node will at that point have *foo*, > and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*, > the algorithm can end up placing *foo* on a node with *bar* violating the > second constraint. > To prevent the above, we need a validation step: after the placements for a > batch of requests are made, then for each req, we remove its tags from the > node and try to see of constraints are still satisfied if the tag were to be > added back on the node. > When applied to the example above, after the algorithm has run through *req2* > and then *req1*, we remove the *bar* tag from the node and try to add it back > on the node. This time, constraint satisfaction will fail, since there is now > a *foo* tag on the node and *bar* cannot be added. The algorithm will then > retry placing *req2* on another node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[
https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335622#comment-16335622
]
genericqa commented on YARN-7783:
-
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
43s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} YARN-6592 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 17m
37s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
36s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
28s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
39s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
9m 55s{color} | {color:green} branch has no errors when building and testing
our client artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
6s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
24s{color} | {color:green} YARN-6592 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
10m 7s{color} | {color:green} patch has no errors when building and testing
our client artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 73m 57s{color}
| {color:red} hadoop-yarn-server-resourcemanager in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}119m 26s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.yarn.server.resourcemanager.scheduler.fair.TestContinuousScheduling |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:5b98639 |
| JIRA Issue | YARN-7783 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12907257/YARN-7783-YARN-6592.004.patch
|
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit shadedclient findbugs checkstyle |
| uname | Linux c52d2d24c78f 4.4.0-89-generic #112-Ubuntu SMP Mon Jul 31
19:38:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/patchprocess/precommit/personality/provided.sh |
| git revision | YARN-6592 / 904e023 |
| maven | version: Apache Maven 3.3.9 |
| Default Java | 1.8.0_151 |
| findbugs | v3.1.0-RC1 |
| unit |
https://builds.apache.org/job/PreCommit-YARN-Build/19392/artifact/out/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-YARN-Build/19392/testReport/ |
| Max. process+thread count | 839 (vs. ulimit of 5000) |
| modules | C:
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager
U:
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[ https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335507#comment-16335507 ] Weiwei Yang commented on YARN-7783: --- [~asuresh] yeah, that addressed my concern, thanks for getting it done. > Add validation step to ensure constraints are not violated due to order in > which a request is processed > --- > > Key: YARN-7783 > URL: https://issues.apache.org/jira/browse/YARN-7783 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Arun Suresh >Assignee: Arun Suresh >Priority: Blocker > Attachments: YARN-7783-YARN-6592.001.patch, > YARN-7783-YARN-6592.002.patch, YARN-7783-YARN-6592.003.patch, > YARN-7783-YARN-6592.004.patch > > > When the algorithm has placed a container on a node, allocation tags are > added to the node if the constraint is satisfied, But depending on the order > in which the algorithm sees the request, it is possible that a constraint > that happen to be valid during placement of an earlier-seen request, might > not be valid after all subsequent requests have been placed. > For eg: > Assume nodes n1, n2, n3, n4 and n5 > Consider the 2 constraints: > # *foo* -> anti-affinity with *foo* > # *bar* -> anti-affinity with *foo* > And 2 requests > # req1: NumAllocations = 4, allocTags = [foo] > # req2: NumAllocations = 1, allocTags = [bar] > If *req1* is seen first, the algorithm can place the 4 containers in n1, n2, > n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the > *foo* tag and will place it on n5. But if *req2* is seen first, then *bar* > tag will be placed on any node, since no node will at that point have *foo*, > and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*, > the algorithm can end up placing *foo* on a node with *bar* violating the > second constraint. > To prevent the above, we need a validation step: after the placements for a > batch of requests are made, then for each req, we remove its tags from the > node and try to see of constraints are still satisfied if the tag were to be > added back on the node. > When applied to the example above, after the algorithm has run through *req2* > and then *req1*, we remove the *bar* tag from the node and try to add it back > on the node. This time, constraint satisfaction will fail, since there is now > a *foo* tag on the node and *bar* cannot be added. The algorithm will then > retry placing *req2* on another node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[ https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335501#comment-16335501 ] Arun Suresh commented on YARN-7783: --- Uploaded patch after rebasing. [~cheersyang], so after YARN-7788, each algorithm instance will have a single instance of EphemeralATM (I've renamed this to LocalATM, since its not ephemeral anymore) - I am guessing thats what you meant. > Add validation step to ensure constraints are not violated due to order in > which a request is processed > --- > > Key: YARN-7783 > URL: https://issues.apache.org/jira/browse/YARN-7783 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Arun Suresh >Assignee: Arun Suresh >Priority: Blocker > Attachments: YARN-7783-YARN-6592.001.patch, > YARN-7783-YARN-6592.002.patch, YARN-7783-YARN-6592.003.patch, > YARN-7783-YARN-6592.004.patch > > > When the algorithm has placed a container on a node, allocation tags are > added to the node if the constraint is satisfied, But depending on the order > in which the algorithm sees the request, it is possible that a constraint > that happen to be valid during placement of an earlier-seen request, might > not be valid after all subsequent requests have been placed. > For eg: > Assume nodes n1, n2, n3, n4 and n5 > Consider the 2 constraints: > # *foo* -> anti-affinity with *foo* > # *bar* -> anti-affinity with *foo* > And 2 requests > # req1: NumAllocations = 4, allocTags = [foo] > # req2: NumAllocations = 1, allocTags = [bar] > If *req1* is seen first, the algorithm can place the 4 containers in n1, n2, > n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the > *foo* tag and will place it on n5. But if *req2* is seen first, then *bar* > tag will be placed on any node, since no node will at that point have *foo*, > and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*, > the algorithm can end up placing *foo* on a node with *bar* violating the > second constraint. > To prevent the above, we need a validation step: after the placements for a > batch of requests are made, then for each req, we remove its tags from the > node and try to see of constraints are still satisfied if the tag were to be > added back on the node. > When applied to the example above, after the algorithm has run through *req2* > and then *req1*, we remove the *bar* tag from the node and try to add it back > on the node. This time, constraint satisfaction will fail, since there is now > a *foo* tag on the node and *bar* cannot be added. The algorithm will then > retry placing *req2* on another node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[
https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335381#comment-16335381
]
Weiwei Yang commented on YARN-7783:
---
Thanks [~asuresh], as this is not going to fix inter-app issues, I am fine with
the approach. However, for long term, should we have a centralized
{{EpehmeralAlloactionTagsManager}} that manages all temporary allocation tags
together?
> Add validation step to ensure constraints are not violated due to order in
> which a request is processed
> ---
>
> Key: YARN-7783
> URL: https://issues.apache.org/jira/browse/YARN-7783
> Project: Hadoop YARN
> Issue Type: Sub-task
>Reporter: Arun Suresh
>Assignee: Arun Suresh
>Priority: Blocker
> Attachments: YARN-7783-YARN-6592.001.patch,
> YARN-7783-YARN-6592.002.patch, YARN-7783-YARN-6592.003.patch
>
>
> When the algorithm has placed a container on a node, allocation tags are
> added to the node if the constraint is satisfied, But depending on the order
> in which the algorithm sees the request, it is possible that a constraint
> that happen to be valid during placement of an earlier-seen request, might
> not be valid after all subsequent requests have been placed.
> For eg:
> Assume nodes n1, n2, n3, n4 and n5
> Consider the 2 constraints:
> # *foo* -> anti-affinity with *foo*
> # *bar* -> anti-affinity with *foo*
> And 2 requests
> # req1: NumAllocations = 4, allocTags = [foo]
> # req2: NumAllocations = 1, allocTags = [bar]
> If *req1* is seen first, the algorithm can place the 4 containers in n1, n2,
> n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the
> *foo* tag and will place it on n5. But if *req2* is seen first, then *bar*
> tag will be placed on any node, since no node will at that point have *foo*,
> and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*,
> the algorithm can end up placing *foo* on a node with *bar* violating the
> second constraint.
> To prevent the above, we need a validation step: after the placements for a
> batch of requests are made, then for each req, we remove its tags from the
> node and try to see of constraints are still satisfied if the tag were to be
> added back on the node.
> When applied to the example above, after the algorithm has run through *req2*
> and then *req1*, we remove the *bar* tag from the node and try to add it back
> on the node. This time, constraint satisfaction will fail, since there is now
> a *foo* tag on the node and *bar* cannot be added. The algorithm will then
> retry placing *req2* on another node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[ https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334836#comment-16334836 ] Arun Suresh commented on YARN-7783: --- The failure was due to its dependence on YARN-7788 (it needs to go in first) > Add validation step to ensure constraints are not violated due to order in > which a request is processed > --- > > Key: YARN-7783 > URL: https://issues.apache.org/jira/browse/YARN-7783 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Arun Suresh >Assignee: Arun Suresh >Priority: Blocker > Attachments: YARN-7783-YARN-6592.001.patch, > YARN-7783-YARN-6592.002.patch, YARN-7783-YARN-6592.003.patch > > > When the algorithm has placed a container on a node, allocation tags are > added to the node if the constraint is satisfied, But depending on the order > in which the algorithm sees the request, it is possible that a constraint > that happen to be valid during placement of an earlier-seen request, might > not be valid after all subsequent requests have been placed. > For eg: > Assume nodes n1, n2, n3, n4 and n5 > Consider the 2 constraints: > # *foo* -> anti-affinity with *foo* > # *bar* -> anti-affinity with *foo* > And 2 requests > # req1: NumAllocations = 4, allocTags = [foo] > # req2: NumAllocations = 1, allocTags = [bar] > If *req1* is seen first, the algorithm can place the 4 containers in n1, n2, > n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the > *foo* tag and will place it on n5. But if *req2* is seen first, then *bar* > tag will be placed on any node, since no node will at that point have *foo*, > and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*, > the algorithm can end up placing *foo* on a node with *bar* violating the > second constraint. > To prevent the above, we need a validation step: after the placements for a > batch of requests are made, then for each req, we remove its tags from the > node and try to see of constraints are still satisfied if the tag were to be > added back on the node. > When applied to the example above, after the algorithm has run through *req2* > and then *req1*, we remove the *bar* tag from the node and try to add it back > on the node. This time, constraint satisfaction will fail, since there is now > a *foo* tag on the node and *bar* cannot be added. The algorithm will then > retry placing *req2* on another node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[
https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334826#comment-16334826
]
genericqa commented on YARN-7783:
-
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 6s{color}
| {color:red} YARN-7783 does not apply to YARN-6592. Rebase required? Wrong
Branch? See https://wiki.apache.org/hadoop/HowToContribute for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | YARN-7783 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12907177/YARN-7783-YARN-6592.003.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-YARN-Build/19374/console |
| Powered by | Apache Yetus 0.8.0-SNAPSHOT http://yetus.apache.org |
This message was automatically generated.
> Add validation step to ensure constraints are not violated due to order in
> which a request is processed
> ---
>
> Key: YARN-7783
> URL: https://issues.apache.org/jira/browse/YARN-7783
> Project: Hadoop YARN
> Issue Type: Sub-task
>Reporter: Arun Suresh
>Assignee: Arun Suresh
>Priority: Blocker
> Attachments: YARN-7783-YARN-6592.001.patch,
> YARN-7783-YARN-6592.002.patch, YARN-7783-YARN-6592.003.patch
>
>
> When the algorithm has placed a container on a node, allocation tags are
> added to the node if the constraint is satisfied, But depending on the order
> in which the algorithm sees the request, it is possible that a constraint
> that happen to be valid during placement of an earlier-seen request, might
> not be valid after all subsequent requests have been placed.
> For eg:
> Assume nodes n1, n2, n3, n4 and n5
> Consider the 2 constraints:
> # *foo* -> anti-affinity with *foo*
> # *bar* -> anti-affinity with *foo*
> And 2 requests
> # req1: NumAllocations = 4, allocTags = [foo]
> # req2: NumAllocations = 1, allocTags = [bar]
> If *req1* is seen first, the algorithm can place the 4 containers in n1, n2,
> n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the
> *foo* tag and will place it on n5. But if *req2* is seen first, then *bar*
> tag will be placed on any node, since no node will at that point have *foo*,
> and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*,
> the algorithm can end up placing *foo* on a node with *bar* violating the
> second constraint.
> To prevent the above, we need a validation step: after the placements for a
> batch of requests are made, then for each req, we remove its tags from the
> node and try to see of constraints are still satisfied if the tag were to be
> added back on the node.
> When applied to the example above, after the algorithm has run through *req2*
> and then *req1*, we remove the *bar* tag from the node and try to add it back
> on the node. This time, constraint satisfaction will fail, since there is now
> a *foo* tag on the node and *bar* cannot be added. The algorithm will then
> retry placing *req2* on another node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[ https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334822#comment-16334822 ] Arun Suresh commented on YARN-7783: --- Split the refoctoring into YARN-7788 for easier review. The actual patch is now pretty small > Add validation step to ensure constraints are not violated due to order in > which a request is processed > --- > > Key: YARN-7783 > URL: https://issues.apache.org/jira/browse/YARN-7783 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Arun Suresh >Assignee: Arun Suresh >Priority: Blocker > Attachments: YARN-7783-YARN-6592.001.patch, > YARN-7783-YARN-6592.002.patch, YARN-7783-YARN-6592.003.patch > > > When the algorithm has placed a container on a node, allocation tags are > added to the node if the constraint is satisfied, But depending on the order > in which the algorithm sees the request, it is possible that a constraint > that happen to be valid during placement of an earlier-seen request, might > not be valid after all subsequent requests have been placed. > For eg: > Assume nodes n1, n2, n3, n4 and n5 > Consider the 2 constraints: > # *foo* -> anti-affinity with *foo* > # *bar* -> anti-affinity with *foo* > And 2 requests > # req1: NumAllocations = 4, allocTags = [foo] > # req2: NumAllocations = 1, allocTags = [bar] > If *req1* is seen first, the algorithm can place the 4 containers in n1, n2, > n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the > *foo* tag and will place it on n5. But if *req2* is seen first, then *bar* > tag will be placed on any node, since no node will at that point have *foo*, > and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*, > the algorithm can end up placing *foo* on a node with *bar* violating the > second constraint. > To prevent the above, we need a validation step: after the placements for a > batch of requests are made, then for each req, we remove its tags from the > node and try to see of constraints are still satisfied if the tag were to be > added back on the node. > When applied to the example above, after the algorithm has run through *req2* > and then *req1*, we remove the *bar* tag from the node and try to add it back > on the node. This time, constraint satisfaction will fail, since there is now > a *foo* tag on the node and *bar* cannot be added. The algorithm will then > retry placing *req2* on another node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[
https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334511#comment-16334511
]
Arun Suresh commented on YARN-7783:
---
[~cheersyang], thanks for the review. This patch was not meant to fix the
INTER-app placement issues. it is for ensuring that INTRA-app placement in the
context of a batch of requests do not violate constraints.
The {{EphemeralTagsManager}} is just a refactoring of the existing TagsManger
to abstract out all functionality of adding/removing temp tags into a new class.
> Add validation step to ensure constraints are not violated due to order in
> which a request is processed
> ---
>
> Key: YARN-7783
> URL: https://issues.apache.org/jira/browse/YARN-7783
> Project: Hadoop YARN
> Issue Type: Sub-task
>Reporter: Arun Suresh
>Assignee: Arun Suresh
>Priority: Blocker
> Attachments: YARN-7783-YARN-6592.001.patch,
> YARN-7783-YARN-6592.002.patch
>
>
> When the algorithm has placed a container on a node, allocation tags are
> added to the node if the constraint is satisfied, But depending on the order
> in which the algorithm sees the request, it is possible that a constraint
> that happen to be valid during placement of an earlier-seen request, might
> not be valid after all subsequent requests have been placed.
> For eg:
> Assume nodes n1, n2, n3, n4 and n5
> Consider the 2 constraints:
> # *foo* -> anti-affinity with *foo*
> # *bar* -> anti-affinity with *foo*
> And 2 requests
> # req1: NumAllocations = 4, allocTags = [foo]
> # req2: NumAllocations = 1, allocTags = [bar]
> If *req1* is seen first, the algorithm can place the 4 containers in n1, n2,
> n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the
> *foo* tag and will place it on n5. But if *req2* is seen first, then *bar*
> tag will be placed on any node, since no node will at that point have *foo*,
> and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*,
> the algorithm can end up placing *foo* on a node with *bar* violating the
> second constraint.
> To prevent the above, we need a validation step: after the placements for a
> batch of requests are made, then for each req, we remove its tags from the
> node and try to see of constraints are still satisfied if the tag were to be
> added back on the node.
> When applied to the example above, after the algorithm has run through *req2*
> and then *req1*, we remove the *bar* tag from the node and try to add it back
> on the node. This time, constraint satisfaction will fail, since there is now
> a *foo* tag on the node and *bar* cannot be added. The algorithm will then
> retry placing *req2* on another node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[
https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334181#comment-16334181
]
Weiwei Yang commented on YARN-7783:
---
Hi [~asuresh]
I am wondering why you decided to instantiate one
\{{EphemeralAllocationTagsManager}} per run of the algorithm, that limits the
\{{EphemeralAllocationTagsManager}} to be only able to see the tags of giving
\{{BatchedRequests}} belongs to one same application, right? How this approach
works for inter apps?
> Add validation step to ensure constraints are not violated due to order in
> which a request is processed
> ---
>
> Key: YARN-7783
> URL: https://issues.apache.org/jira/browse/YARN-7783
> Project: Hadoop YARN
> Issue Type: Sub-task
>Reporter: Arun Suresh
>Assignee: Arun Suresh
>Priority: Blocker
> Attachments: YARN-7783-YARN-6592.001.patch,
> YARN-7783-YARN-6592.002.patch
>
>
> When the algorithm has placed a container on a node, allocation tags are
> added to the node if the constraint is satisfied, But depending on the order
> in which the algorithm sees the request, it is possible that a constraint
> that happen to be valid during placement of an earlier-seen request, might
> not be valid after all subsequent requests have been placed.
> For eg:
> Assume nodes n1, n2, n3, n4 and n5
> Consider the 2 constraints:
> # *foo* -> anti-affinity with *foo*
> # *bar* -> anti-affinity with *foo*
> And 2 requests
> # req1: NumAllocations = 4, allocTags = [foo]
> # req2: NumAllocations = 1, allocTags = [bar]
> If *req1* is seen first, the algorithm can place the 4 containers in n1, n2,
> n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the
> *foo* tag and will place it on n5. But if *req2* is seen first, then *bar*
> tag will be placed on any node, since no node will at that point have *foo*,
> and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*,
> the algorithm can end up placing *foo* on a node with *bar* violating the
> second constraint.
> To prevent the above, we need a validation step: after the placements for a
> batch of requests are made, then for each req, we remove its tags from the
> node and try to see of constraints are still satisfied if the tag were to be
> added back on the node.
> When applied to the example above, after the algorithm has run through *req2*
> and then *req1*, we remove the *bar* tag from the node and try to add it back
> on the node. This time, constraint satisfaction will fail, since there is now
> a *foo* tag on the node and *bar* cannot be added. The algorithm will then
> retry placing *req2* on another node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[
https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334044#comment-16334044
]
genericqa commented on YARN-7783:
-
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} YARN-6592 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 15m
26s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
38s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
26s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
40s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
10m 31s{color} | {color:green} branch has no errors when building and testing
our client artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
59s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
22s{color} | {color:green} YARN-6592 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
20s{color} | {color:green}
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager:
The patch generated 0 new + 1 unchanged - 3 fixed = 1 total (was 4) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
9m 48s{color} | {color:green} patch has no errors when building and testing our
client artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
24s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 65m
23s{color} | {color:green} hadoop-yarn-server-resourcemanager in the patch
passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}108m 11s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:5b98639 |
| JIRA Issue | YARN-7783 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12907048/YARN-7783-YARN-6592.002.patch
|
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit shadedclient findbugs checkstyle |
| uname | Linux 4ce62291ea67 4.4.0-64-generic #85-Ubuntu SMP Mon Feb 20
11:50:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/patchprocess/precommit/personality/provided.sh |
| git revision | YARN-6592 / 1612832 |
| maven | version: Apache Maven 3.3.9 |
| Default Java | 1.8.0_151 |
| findbugs | v3.1.0-RC1 |
| Test Results |
https://builds.apache.org/job/PreCommit-YARN-Build/19365/testReport/ |
| Max. process+thread count | 896 (vs. ulimit of 5000) |
| modules | C:
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager
U:
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager
|
| Console output |
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[ https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333937#comment-16333937 ] Arun Suresh commented on YARN-7783: --- [~leftnoteasy], to alleviate your concerns, I have moved all the add/remove/cleanup temp containers/tags methods to a another class, which is used only by the algorithm. The EpehmeralAlloactionTagsManager is a delegating TagsManager - that is instantiated once per run of the algorithm, and manages all temporary tags which are created and removed during the algorithms run. It will also cleanup the tags from the underlying ATM after it is done. Please do take a look [~cheersyang] / [~kkaranasos] as well. I agree with [~kkaranasos] that fixing / validating the constraints at register time via (YARN-6621) should be our long term solution, but in any case, this validation phase of the algorithm loop is also needed - and YARN-6621 is a far more complex undertaking. > Add validation step to ensure constraints are not violated due to order in > which a request is processed > --- > > Key: YARN-7783 > URL: https://issues.apache.org/jira/browse/YARN-7783 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Arun Suresh >Assignee: Arun Suresh >Priority: Blocker > Attachments: YARN-7783-YARN-6592.001.patch, > YARN-7783-YARN-6592.002.patch > > > When the algorithm has placed a container on a node, allocation tags are > added to the node if the constraint is satisfied, But depending on the order > in which the algorithm sees the request, it is possible that a constraint > that happen to be valid during placement of an earlier-seen request, might > not be valid after all subsequent requests have been placed. > For eg: > Assume nodes n1, n2, n3, n4 and n5 > Consider the 2 constraints: > # *foo* -> anti-affinity with *foo* > # *bar* -> anti-affinity with *foo* > And 2 requests > # req1: NumAllocations = 4, allocTags = [foo] > # req2: NumAllocations = 1, allocTags = [bar] > If *req1* is seen first, the algorithm can place the 4 containers in n1, n2, > n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the > *foo* tag and will place it on n5. But if *req2* is seen first, then *bar* > tag will be placed on any node, since no node will at that point have *foo*, > and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*, > the algorithm can end up placing *foo* on a node with *bar* violating the > second constraint. > To prevent the above, we need a validation step: after the placements for a > batch of requests are made, then for each req, we remove its tags from the > node and try to see of constraints are still satisfied if the tag were to be > added back on the node. > When applied to the example above, after the algorithm has run through *req2* > and then *req1*, we remove the *bar* tag from the node and try to add it back > on the node. This time, constraint satisfaction will fail, since there is now > a *foo* tag on the node and *bar* cannot be added. The algorithm will then > retry placing *req2* on another node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[ https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333859#comment-16333859 ] Arun Suresh commented on YARN-7783: --- bq. this change looks pretty intrusive. Changes like temp tag for the internal algorithm (including AppPlacementAllocator should not be a part of AllocationTagsManager. Hmm.. could you clarify why you find this intrusive. This patch just modifies the *addTempContainer* method and the *appTempMappings* field, which is not even used by the AppPlacementAllocator in the first place - so should not affect its code paths in any way. :) bq. This is bad for inter-application affinity. Intra-application is better since it's easier to control requests within the same app. A simpler way to fix this problem is restricting anti-affinity only to its own allocation tags For inter-app, it is definitely bad. But the example I specified in the description is for INTRA-app, though. Without a fix, we have to state that the feature only works if source and target tags are the same - which I think is a bit too naive / restrictive, since our goal is "rich constraint placement" :). I would still consider this a blocker. > Add validation step to ensure constraints are not violated due to order in > which a request is processed > --- > > Key: YARN-7783 > URL: https://issues.apache.org/jira/browse/YARN-7783 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Arun Suresh >Assignee: Arun Suresh >Priority: Blocker > Attachments: YARN-7783-YARN-6592.001.patch > > > When the algorithm has placed a container on a node, allocation tags are > added to the node if the constraint is satisfied, But depending on the order > in which the algorithm sees the request, it is possible that a constraint > that happen to be valid during placement of an earlier-seen request, might > not be valid after all subsequent requests have been placed. > For eg: > Assume nodes n1, n2, n3, n4 and n5 > Consider the 2 constraints: > # *foo* -> anti-affinity with *foo* > # *bar* -> anti-affinity with *foo* > And 2 requests > # req1: NumAllocations = 4, allocTags = [foo] > # req2: NumAllocations = 1, allocTags = [bar] > If *req1* is seen first, the algorithm can place the 4 containers in n1, n2, > n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the > *foo* tag and will place it on n5. But if *req2* is seen first, then *bar* > tag will be placed on any node, since no node will at that point have *foo*, > and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*, > the algorithm can end up placing *foo* on a node with *bar* violating the > second constraint. > To prevent the above, we need a validation step: after the placements for a > batch of requests are made, then for each req, we remove its tags from the > node and try to see of constraints are still satisfied if the tag were to be > added back on the node. > When applied to the example above, after the algorithm has run through *req2* > and then *req1*, we remove the *bar* tag from the node and try to add it back > on the node. This time, constraint satisfaction will fail, since there is now > a *foo* tag on the node and *bar* cannot be added. The algorithm will then > retry placing *req2* on another node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[ https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333846#comment-16333846 ] Wangda Tan commented on YARN-7783: -- [~asuresh] , I think this is a known issue and we knew this from the beginning. This is bad for inter-application affinity. Intra-application is better since it's easier to control requests within the same app. A simpler way to fix this problem is restricting anti-affinity only to its own allocation tags. To me, this is acceptable since we're implementing a subset of PlacementConstraint in any case. Just looked at the patch, I'm a little worried about the change, this change looks pretty intrusive. Changes like temp tag for the internal algorithm (including AppPlacementAllocator should not be a part of AllocationTagsManager. AllocationTagsManager should restrict to allocated containers. > Add validation step to ensure constraints are not violated due to order in > which a request is processed > --- > > Key: YARN-7783 > URL: https://issues.apache.org/jira/browse/YARN-7783 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Arun Suresh >Assignee: Arun Suresh >Priority: Blocker > Attachments: YARN-7783-YARN-6592.001.patch > > > When the algorithm has placed a container on a node, allocation tags are > added to the node if the constraint is satisfied, But depending on the order > in which the algorithm sees the request, it is possible that a constraint > that happen to be valid during placement of an earlier-seen request, might > not be valid after all subsequent requests have been placed. > For eg: > Assume nodes n1, n2, n3, n4 and n5 > Consider the 2 constraints: > # *foo* -> anti-affinity with *foo* > # *bar* -> anti-affinity with *foo* > And 2 requests > # req1: NumAllocations = 4, allocTags = [foo] > # req2: NumAllocations = 1, allocTags = [bar] > If *req1* is seen first, the algorithm can place the 4 containers in n1, n2, > n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the > *foo* tag and will place it on n5. But if *req2* is seen first, then *bar* > tag will be placed on any node, since no node will at that point have *foo*, > and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*, > the algorithm can end up placing *foo* on a node with *bar* violating the > second constraint. > To prevent the above, we need a validation step: after the placements for a > batch of requests are made, then for each req, we remove its tags from the > node and try to see of constraints are still satisfied if the tag were to be > added back on the node. > When applied to the example above, after the algorithm has run through *req2* > and then *req1*, we remove the *bar* tag from the node and try to add it back > on the node. This time, constraint satisfaction will fail, since there is now > a *foo* tag on the node and *bar* cannot be added. The algorithm will then > retry placing *req2* on another node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[
https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333490#comment-16333490
]
genericqa commented on YARN-7783:
-
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} YARN-6592 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 15m
22s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
38s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
26s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
40s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
10m 27s{color} | {color:green} branch has no errors when building and testing
our client artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
1s{color} | {color:green} YARN-6592 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
25s{color} | {color:green} YARN-6592 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s{color} | {color:green}
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager:
The patch generated 0 new + 1 unchanged - 3 fixed = 1 total (was 4) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
10m 23s{color} | {color:green} patch has no errors when building and testing
our client artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
23s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 66m
52s{color} | {color:green} hadoop-yarn-server-resourcemanager in the patch
passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
22s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}110m 27s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:5b98639 |
| JIRA Issue | YARN-7783 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12906992/YARN-7783-YARN-6592.001.patch
|
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit shadedclient findbugs checkstyle |
| uname | Linux e3bb4b6d13d3 4.4.0-64-generic #85-Ubuntu SMP Mon Feb 20
11:50:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/patchprocess/precommit/personality/provided.sh |
| git revision | YARN-6592 / 6853e20 |
| maven | version: Apache Maven 3.3.9 |
| Default Java | 1.8.0_151 |
| findbugs | v3.1.0-RC1 |
| Test Results |
https://builds.apache.org/job/PreCommit-YARN-Build/19362/testReport/ |
| Max. process+thread count | 821 (vs. ulimit of 5000) |
| modules | C:
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager
U:
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager
|
| Console output |
[jira] [Commented] (YARN-7783) Add validation step to ensure constraints are not violated due to order in which a request is processed
[ https://issues.apache.org/jira/browse/YARN-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333453#comment-16333453 ] Arun Suresh commented on YARN-7783: --- Attached patch to add a validation step in the algorithm - and included a test-case that would fail without the validation step. Additionally: * I optimized the main loop of the algorithm to reduce object creation. * Optimized the allocationTagManager#addTempContainer: Since we are adding tags, we don't really need to create a fake container. > Add validation step to ensure constraints are not violated due to order in > which a request is processed > --- > > Key: YARN-7783 > URL: https://issues.apache.org/jira/browse/YARN-7783 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Arun Suresh >Assignee: Arun Suresh >Priority: Blocker > Attachments: YARN-7783-YARN-6592.001.patch > > > When the algorithm has placed a container on a node, allocation tags are > added to the node if the constraint is satisfied, But depending on the order > in which the algorithm sees the request, it is possible that a constraint > that happen to be valid during placement of an earlier-seen request, might > not be valid after all subsequent requests have been placed. > For eg: > Assume nodes n1, n2, n3, n4 and n5 > Consider the 2 constraints: > # *foo* -> anti-affinity with *foo* > # *bar* -> anti-affinity with *foo* > And 2 requests > # req1: NumAllocations = 4, allocTags = [foo] > # req2: NumAllocations = 1, allocTags = [bar] > If *req1* is seen first, the algorithm can place the 4 containers in n1, n2, > n3 and n4. And when it gets to *req2*, it will see that 4 nodes have the > *foo* tag and will place it on n5. But if *req2* is seen first, then *bar* > tag will be placed on any node, since no node will at that point have *foo*, > and then when it gets to *req1*, since *foo* has no anti-affinity with *bar*, > the algorithm can end up placing *foo* on a node with *bar* violating the > second constraint. > To prevent the above, we need a validation step: after the placements for a > batch of requests are made, then for each req, we remove its tags from the > node and try to see of constraints are still satisfied if the tag were to be > added back on the node. > When applied to the example above, after the algorithm has run through *req2* > and then *req1*, we remove the *bar* tag from the node and try to add it back > on the node. This time, constraint satisfaction will fail, since there is now > a *foo* tag on the node and *bar* cannot be added. The algorithm will then > retry placing *req2* on another node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
