[jira] [Created] (YARN-10662) [JDK 11] TestTimelineReaderWebServicesHBaseStorage fails
Akira Ajisaka created YARN-10662:
Summary: [JDK 11] TestTimelineReaderWebServicesHBaseStorage fails
Key: YARN-10662
URL: https://issues.apache.org/jira/browse/YARN-10662
Project: Hadoop YARN
Issue Type: Bug
Components: test
Reporter: Akira Ajisaka
[https://ci-hadoop.apache.org/job/hadoop-qbt-trunk-java11-linux-x86_64/131/artifact/out/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-timelineservice-hbase-tests.txt]
{noformat}
[INFO] Running
org.apache.hadoop.yarn.server.timelineservice.reader.TestTimelineReaderWebServicesHBaseStorage
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.515 s
<<< FAILURE! - in
org.apache.hadoop.yarn.server.timelineservice.reader.TestTimelineReaderWebServicesHBaseStorage
[ERROR]
org.apache.hadoop.yarn.server.timelineservice.reader.TestTimelineReaderWebServicesHBaseStorage
Time elapsed: 1.514 s <<< ERROR!
java.lang.ExceptionInInitializerError
at
org.apache.hadoop.yarn.server.timelineservice.reader.TestTimelineReaderWebServicesHBaseStorage.setupBeforeClass(TestTimelineReaderWebServicesHBaseStorage.java:84)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
Caused by: java.lang.RuntimeException: java.io.IOException: Can not attach to
current VM
at
mockit.internal.startup.AgentLoader.attachToRunningVM(AgentLoader.java:150)
at mockit.internal.startup.AgentLoader.loadAgent(AgentLoader.java:60)
at
mockit.internal.startup.Startup.verifyInitialization(Startup.java:169)
at mockit.MockUp.(MockUp.java:94)
... 19 more
Caused by: java.io.IOException: Can not attach to current VM
at
jdk.attach/sun.tools.attach.HotSpotVirtualMachine.(HotSpotVirtualMachine.java:75)
at
jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:56)
at
jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
at
jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
at
mockit.internal.startup.AgentLoader.attachToRunningVM(AgentLoader.java:144)
... 22 more
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] TestTimelineReaderWebServicesHBaseStorage.setupBeforeClass:84
ExceptionInInitializer
[INFO]
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-9615) Add dispatcher metrics to RM
[ https://issues.apache.org/jira/browse/YARN-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293457#comment-17293457 ] Qi Zhu commented on YARN-9615: -- [~pbacsko] [~gandras] [~jhung] [~iwasakims] Updated a patch for review, added a unit test also.:D > Add dispatcher metrics to RM > > > Key: YARN-9615 > URL: https://issues.apache.org/jira/browse/YARN-9615 > Project: Hadoop YARN > Issue Type: Task >Reporter: Jonathan Hung >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-9615.001.patch, YARN-9615.002.patch, > YARN-9615.003.patch, YARN-9615.004.patch, YARN-9615.poc.patch, > screenshot-1.png > > > It'd be good to have counts/processing times for each event type in RM async > dispatcher and scheduler async dispatcher. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9615) Add dispatcher metrics to RM
[ https://issues.apache.org/jira/browse/YARN-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qi Zhu updated YARN-9615: - Attachment: YARN-9615.004.patch > Add dispatcher metrics to RM > > > Key: YARN-9615 > URL: https://issues.apache.org/jira/browse/YARN-9615 > Project: Hadoop YARN > Issue Type: Task >Reporter: Jonathan Hung >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-9615.001.patch, YARN-9615.002.patch, > YARN-9615.003.patch, YARN-9615.004.patch, YARN-9615.poc.patch, > screenshot-1.png > > > It'd be good to have counts/processing times for each event type in RM async > dispatcher and scheduler async dispatcher. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10623) Capacity scheduler should support refresh queue automatically by a thread policy.
[
https://issues.apache.org/jira/browse/YARN-10623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293414#comment-17293414
]
Hadoop QA commented on YARN-10623:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Logfile || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
44s{color} | {color:blue}{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} || ||
| {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m
1s{color} | {color:green}{color} | {color:green} No case conflicting files
found. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} The patch does not contain any
@author tags. {color} |
| {color:green}+1{color} | {color:green} {color} | {color:green} 0m 0s{color}
| {color:green}test4tests{color} | {color:green} The patch appears to include 1
new or modified test files. {color} |
|| || || || {color:brown} trunk Compile Tests {color} || ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
43s{color} | {color:blue}{color} | {color:blue} Maven dependency ordering for
branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 23m
14s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 10m
53s{color} | {color:green}{color} | {color:green} trunk passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m
24s{color} | {color:green}{color} | {color:green} trunk passed with JDK Private
Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
55s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m
5s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
19m 37s{color} | {color:green}{color} | {color:green} branch has no errors when
building and testing our client artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
44s{color} | {color:green}{color} | {color:green} trunk passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
58s{color} | {color:green}{color} | {color:green} trunk passed with JDK Private
Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:blue}0{color} | {color:blue} spotbugs {color} | {color:blue} 1m
57s{color} | {color:blue}{color} | {color:blue} Used deprecated FindBugs
config; considering switching to SpotBugs. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
55s{color} | {color:green}{color} | {color:green} trunk passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} || ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
24s{color} | {color:blue}{color} | {color:blue} Maven dependency ordering for
patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
28s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
22s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m
22s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
40s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m
40s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
36s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
54s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} The patch has no whitespace
issues. {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
13m 24s{color} | {color:green}{color} | {color:green} patch has no errors when
building and testing our client artifacts. {color} |
|
[jira] [Commented] (YARN-10623) Capacity scheduler should support refresh queue automatically by a thread policy.
[
https://issues.apache.org/jira/browse/YARN-10623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293400#comment-17293400
]
Hadoop QA commented on YARN-10623:
--
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Logfile || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
12s{color} | {color:blue}{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} || ||
| {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} No case conflicting files
found. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} The patch does not contain any
@author tags. {color} |
| {color:green}+1{color} | {color:green} {color} | {color:green} 0m 0s{color}
| {color:green}test4tests{color} | {color:green} The patch appears to include 1
new or modified test files. {color} |
|| || || || {color:brown} trunk Compile Tests {color} || ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
39s{color} | {color:blue}{color} | {color:blue} Maven dependency ordering for
branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 23m
9s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 10m
52s{color} | {color:green}{color} | {color:green} trunk passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
23s{color} | {color:green}{color} | {color:green} trunk passed with JDK Private
Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
39s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m
2s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
19m 26s{color} | {color:green}{color} | {color:green} branch has no errors when
building and testing our client artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
30s{color} | {color:green}{color} | {color:green} trunk passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
49s{color} | {color:green}{color} | {color:green} trunk passed with JDK Private
Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:blue}0{color} | {color:blue} spotbugs {color} | {color:blue} 2m
4s{color} | {color:blue}{color} | {color:blue} Used deprecated FindBugs config;
considering switching to SpotBugs. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
2s{color} | {color:green}{color} | {color:green} trunk passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} || ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
23s{color} | {color:blue}{color} | {color:blue} Maven dependency ordering for
patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
31s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m
27s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 9m
27s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
34s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m
34s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
38s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
51s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} The patch has no whitespace
issues. {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
15m 47s{color} | {color:green}{color} | {color:green} patch has no errors when
building and testing our client artifacts. {color} |
|
[jira] [Assigned] (YARN-10661) Add option to scale down specific containers in flex API
[
https://issues.apache.org/jira/browse/YARN-10661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Surendra Singh Lilhore reassigned YARN-10661:
-
Assignee: Abhinaba Sarkar
> Add option to scale down specific containers in flex API
>
>
> Key: YARN-10661
> URL: https://issues.apache.org/jira/browse/YARN-10661
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: yarn
>Reporter: Abhinaba Sarkar
>Assignee: Abhinaba Sarkar
>Priority: Major
>
> We can flex the number of containers in yarn-service. But currently we do not
> have option to specify which containers are to be scaled down. This is useful
> in scaling down Hive LLAP clusters. For example -
> {code:java}
> 2021-02-22 12:52:58,983 [IPC Server handler 0 on 24799] INFO
> service.ClientAMService - Flexing component llap to 42021-02-22 12:52:58,983
> [Component dispatcher] INFO component.Component - [FLEX DOWN COMPONENT
> llap]: scaling down from 6 to 42021-02-22 12:52:58,984 [Component
> dispatcher] INFO instance.ComponentInstance - [COMPINSTANCE llap-5 :
> container_e02_1613896771789_0071_01_07]: Flexed down by user,
> destroying.2021-02-22 12:52:58,987 [Component dispatcher] INFO
> instance.ComponentInstance - [COMPINSTANCE llap-4 :
> container_e02_1613896771789_0071_01_06]: Flexed down by user, destroying.
> {code}
> Last added containers are first ones to be destroyed. This might not be the
> most optimal approach as we would like the least loaded(in terms of
> executors) containers to be destroyed first.
> To enable this, we propose an option to add the list of containers that can
> be scaled down by flexing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10661) Add option to scale down specific containers in flex API
[
https://issues.apache.org/jira/browse/YARN-10661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293377#comment-17293377
]
Surendra Singh Lilhore commented on YARN-10661:
---
[~abhinaba.sarkar], Added you as a contributor.
> Add option to scale down specific containers in flex API
>
>
> Key: YARN-10661
> URL: https://issues.apache.org/jira/browse/YARN-10661
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: yarn
>Reporter: Abhinaba Sarkar
>Assignee: Abhinaba Sarkar
>Priority: Major
>
> We can flex the number of containers in yarn-service. But currently we do not
> have option to specify which containers are to be scaled down. This is useful
> in scaling down Hive LLAP clusters. For example -
> {code:java}
> 2021-02-22 12:52:58,983 [IPC Server handler 0 on 24799] INFO
> service.ClientAMService - Flexing component llap to 42021-02-22 12:52:58,983
> [Component dispatcher] INFO component.Component - [FLEX DOWN COMPONENT
> llap]: scaling down from 6 to 42021-02-22 12:52:58,984 [Component
> dispatcher] INFO instance.ComponentInstance - [COMPINSTANCE llap-5 :
> container_e02_1613896771789_0071_01_07]: Flexed down by user,
> destroying.2021-02-22 12:52:58,987 [Component dispatcher] INFO
> instance.ComponentInstance - [COMPINSTANCE llap-4 :
> container_e02_1613896771789_0071_01_06]: Flexed down by user, destroying.
> {code}
> Last added containers are first ones to be destroyed. This might not be the
> most optimal approach as we would like the least loaded(in terms of
> executors) containers to be destroyed first.
> To enable this, we propose an option to add the list of containers that can
> be scaled down by flexing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10532) Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is not being used
[
https://issues.apache.org/jira/browse/YARN-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293351#comment-17293351
]
Hadoop QA commented on YARN-10532:
--
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Logfile || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
21s{color} | {color:blue}{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} || ||
| {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m
1s{color} | {color:green}{color} | {color:green} No case conflicting files
found. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} The patch does not contain any
@author tags. {color} |
| {color:green}+1{color} | {color:green} {color} | {color:green} 0m 0s{color}
| {color:green}test4tests{color} | {color:green} The patch appears to include 3
new or modified test files. {color} |
|| || || || {color:brown} trunk Compile Tests {color} || ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 22m
44s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
6s{color} | {color:green}{color} | {color:green} trunk passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
56s{color} | {color:green}{color} | {color:green} trunk passed with JDK Private
Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
51s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
2s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
17m 36s{color} | {color:green}{color} | {color:green} branch has no errors when
building and testing our client artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
40s{color} | {color:green}{color} | {color:green} trunk passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green}{color} | {color:green} trunk passed with JDK Private
Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:blue}0{color} | {color:blue} spotbugs {color} | {color:blue} 2m
3s{color} | {color:blue}{color} | {color:blue} Used deprecated FindBugs config;
considering switching to SpotBugs. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
59s{color} | {color:green}{color} | {color:green} trunk passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} || ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
57s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
3s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
3s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
54s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
54s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
49s{color} | {color:green}{color} | {color:green}
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager:
The patch generated 0 new + 278 unchanged - 1 fixed = 278 total (was 279)
{color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
58s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} The patch has no whitespace
issues. {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
15m 23s{color} | {color:green}{color} | {color:green} patch has no errors when
building and testing our client artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
44s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04
[jira] [Updated] (YARN-10661) Add option to scale down specific containers in flex API
[
https://issues.apache.org/jira/browse/YARN-10661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinaba Sarkar updated YARN-10661:
---
Description:
We can flex the number of containers in yarn-service. But currently we do not
have option to specify which containers are to be scaled down. This is useful
in scaling down Hive LLAP clusters. For example -
{code:java}
2021-02-22 12:52:58,983 [IPC Server handler 0 on 24799] INFO
service.ClientAMService - Flexing component llap to 42021-02-22 12:52:58,983
[Component dispatcher] INFO component.Component - [FLEX DOWN COMPONENT llap]:
scaling down from 6 to 42021-02-22 12:52:58,984 [Component dispatcher] INFO
instance.ComponentInstance - [COMPINSTANCE llap-5 :
container_e02_1613896771789_0071_01_07]: Flexed down by user,
destroying.2021-02-22 12:52:58,987 [Component dispatcher] INFO
instance.ComponentInstance - [COMPINSTANCE llap-4 :
container_e02_1613896771789_0071_01_06]: Flexed down by user, destroying.
{code}
Last added containers are first ones to be destroyed. This might not be the
most optimal approach as we would like the least loaded(in terms of executors)
containers to be destroyed first.
To enable this, we propose an option to add the list of containers that can be
scaled down by flexing.
was:
We can flex the number of containers in yarn-service. But currently we do not
have option to specify which containers are to be scaled down. This is useful
in scaling down Hive LLAP clusters. For example -
{code:java}
2021-02-22 12:52:58,983 [IPC Server handler 0 on 24799] INFO
service.ClientAMService - Flexing component llap to 42021-02-22 12:52:58,983
[Component dispatcher] INFO component.Component - [FLEX DOWN COMPONENT llap]:
scaling down from 6 to 42021-02-22 12:52:58,984 [Component dispatcher] INFO
instance.ComponentInstance - [COMPINSTANCE llap-5 :
container_e02_1613896771789_0071_01_07]: Flexed down by user,
destroying.2021-02-22 12:52:58,987 [Component dispatcher] INFO
instance.ComponentInstance - [COMPINSTANCE llap-4 :
container_e02_1613896771789_0071_01_06]: Flexed down by user, destroying.
{code}
Last added containers are first ones to be destroyed. This might not be the
most optimal approach as we would like the least loaded(in terms of executors)
containers to be destroyed first. We propose an option to add the list of
containers that can be scaled down by flexing.
> Add option to scale down specific containers in flex API
>
>
> Key: YARN-10661
> URL: https://issues.apache.org/jira/browse/YARN-10661
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: yarn
>Reporter: Abhinaba Sarkar
>Priority: Major
>
> We can flex the number of containers in yarn-service. But currently we do not
> have option to specify which containers are to be scaled down. This is useful
> in scaling down Hive LLAP clusters. For example -
> {code:java}
> 2021-02-22 12:52:58,983 [IPC Server handler 0 on 24799] INFO
> service.ClientAMService - Flexing component llap to 42021-02-22 12:52:58,983
> [Component dispatcher] INFO component.Component - [FLEX DOWN COMPONENT
> llap]: scaling down from 6 to 42021-02-22 12:52:58,984 [Component
> dispatcher] INFO instance.ComponentInstance - [COMPINSTANCE llap-5 :
> container_e02_1613896771789_0071_01_07]: Flexed down by user,
> destroying.2021-02-22 12:52:58,987 [Component dispatcher] INFO
> instance.ComponentInstance - [COMPINSTANCE llap-4 :
> container_e02_1613896771789_0071_01_06]: Flexed down by user, destroying.
> {code}
> Last added containers are first ones to be destroyed. This might not be the
> most optimal approach as we would like the least loaded(in terms of
> executors) containers to be destroyed first.
> To enable this, we propose an option to add the list of containers that can
> be scaled down by flexing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10661) Add option to scale down specific containers in flex API
[
https://issues.apache.org/jira/browse/YARN-10661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293349#comment-17293349
]
Abhinaba Sarkar commented on YARN-10661:
Working on it. Please assign to me
> Add option to scale down specific containers in flex API
>
>
> Key: YARN-10661
> URL: https://issues.apache.org/jira/browse/YARN-10661
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: yarn
>Reporter: Abhinaba Sarkar
>Priority: Major
>
> We can flex the number of containers in yarn-service. But currently we do not
> have option to specify which containers are to be scaled down. This is useful
> in scaling down Hive LLAP clusters. For example -
> {code:java}
> 2021-02-22 12:52:58,983 [IPC Server handler 0 on 24799] INFO
> service.ClientAMService - Flexing component llap to 42021-02-22 12:52:58,983
> [Component dispatcher] INFO component.Component - [FLEX DOWN COMPONENT
> llap]: scaling down from 6 to 42021-02-22 12:52:58,984 [Component
> dispatcher] INFO instance.ComponentInstance - [COMPINSTANCE llap-5 :
> container_e02_1613896771789_0071_01_07]: Flexed down by user,
> destroying.2021-02-22 12:52:58,987 [Component dispatcher] INFO
> instance.ComponentInstance - [COMPINSTANCE llap-4 :
> container_e02_1613896771789_0071_01_06]: Flexed down by user, destroying.
> {code}
> Last added containers are first ones to be destroyed. This might not be the
> most optimal approach as we would like the least loaded(in terms of
> executors) containers to be destroyed first. We propose an option to add the
> list of containers that can be scaled down by flexing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Created] (YARN-10661) Add option to scale down specific containers in flex API
Abhinaba Sarkar created YARN-10661:
--
Summary: Add option to scale down specific containers in flex API
Key: YARN-10661
URL: https://issues.apache.org/jira/browse/YARN-10661
Project: Hadoop YARN
Issue Type: Improvement
Components: yarn
Reporter: Abhinaba Sarkar
We can flex the number of containers in yarn-service. But currently we do not
have option to specify which containers are to be scaled down. This is useful
in scaling down Hive LLAP clusters. For example -
{code:java}
2021-02-22 12:52:58,983 [IPC Server handler 0 on 24799] INFO
service.ClientAMService - Flexing component llap to 42021-02-22 12:52:58,983
[Component dispatcher] INFO component.Component - [FLEX DOWN COMPONENT llap]:
scaling down from 6 to 42021-02-22 12:52:58,984 [Component dispatcher] INFO
instance.ComponentInstance - [COMPINSTANCE llap-5 :
container_e02_1613896771789_0071_01_07]: Flexed down by user,
destroying.2021-02-22 12:52:58,987 [Component dispatcher] INFO
instance.ComponentInstance - [COMPINSTANCE llap-4 :
container_e02_1613896771789_0071_01_06]: Flexed down by user, destroying.
{code}
Last added containers are first ones to be destroyed. This might not be the
most optimal approach as we would like the least loaded(in terms of executors)
containers to be destroyed first. We propose an option to add the list of
containers that can be scaled down by flexing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (YARN-10640) Adjust the queue Configured capacity to Configured weight number for weight mode in UI.
[ https://issues.apache.org/jira/browse/YARN-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293326#comment-17293326 ] Qi Zhu edited comment on YARN-10640 at 3/2/21, 3:34 AM: [~pbacsko] [~gandras] [~bteke] Now i have painless added a configure weights. And check in my local cluster, it will be safe.:D Thanks !image-2021-03-02-11-34-26-062.png|width=554,height=363! was (Author: zhuqi): [~pbacsko] [~gandras] [~bteke] Now i have painless added a configure weights. And check in my local cluster, it will be safe.:D Thanks > Adjust the queue Configured capacity to Configured weight number for weight > mode in UI. > > > Key: YARN-10640 > URL: https://issues.apache.org/jira/browse/YARN-10640 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Qi Zhu >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10640.001.patch, YARN-10640.002.patch, > YARN-10640.003.patch, image-2021-02-20-11-21-50-306.png, > image-2021-02-20-14-18-56-261.png, image-2021-02-20-14-19-30-767.png, > image-2021-03-02-11-34-26-062.png > > > In weight mode: > Both the weight mode static queue and the dynamic queue will show the > Configured Capacity to 0. I think this should change to Configured Weight if > we use weight mode, this will be helpful. > Such as in dynamic weight mode queue: > !image-2021-02-20-11-21-50-306.png|width=528,height=374! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10640) Adjust the queue Configured capacity to Configured weight number for weight mode in UI.
[ https://issues.apache.org/jira/browse/YARN-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293326#comment-17293326 ] Qi Zhu commented on YARN-10640: --- [~pbacsko] [~gandras] [~bteke] Now i have painless added a configure weights. And check in my local cluster, it will be safe.:D Thanks > Adjust the queue Configured capacity to Configured weight number for weight > mode in UI. > > > Key: YARN-10640 > URL: https://issues.apache.org/jira/browse/YARN-10640 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Qi Zhu >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10640.001.patch, YARN-10640.002.patch, > YARN-10640.003.patch, image-2021-02-20-11-21-50-306.png, > image-2021-02-20-14-18-56-261.png, image-2021-02-20-14-19-30-767.png > > > In weight mode: > Both the weight mode static queue and the dynamic queue will show the > Configured Capacity to 0. I think this should change to Configured Weight if > we use weight mode, this will be helpful. > Such as in dynamic weight mode queue: > !image-2021-02-20-11-21-50-306.png|width=528,height=374! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-10640) Adjust the queue Configured capacity to Configured weight number for weight mode in UI.
[ https://issues.apache.org/jira/browse/YARN-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qi Zhu updated YARN-10640: -- Attachment: YARN-10640.003.patch > Adjust the queue Configured capacity to Configured weight number for weight > mode in UI. > > > Key: YARN-10640 > URL: https://issues.apache.org/jira/browse/YARN-10640 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Qi Zhu >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10640.001.patch, YARN-10640.002.patch, > YARN-10640.003.patch, image-2021-02-20-11-21-50-306.png, > image-2021-02-20-14-18-56-261.png, image-2021-02-20-14-19-30-767.png > > > In weight mode: > Both the weight mode static queue and the dynamic queue will show the > Configured Capacity to 0. I think this should change to Configured Weight if > we use weight mode, this will be helpful. > Such as in dynamic weight mode queue: > !image-2021-02-20-11-21-50-306.png|width=528,height=374! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-10623) Capacity scheduler should support refresh queue automatically by a thread policy.
[ https://issues.apache.org/jira/browse/YARN-10623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qi Zhu updated YARN-10623: -- Attachment: YARN-10623.010.patch > Capacity scheduler should support refresh queue automatically by a thread > policy. > - > > Key: YARN-10623 > URL: https://issues.apache.org/jira/browse/YARN-10623 > Project: Hadoop YARN > Issue Type: Improvement > Components: capacity scheduler >Reporter: Qi Zhu >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10623.001.patch, YARN-10623.002.patch, > YARN-10623.003.patch, YARN-10623.004.patch, YARN-10623.005.patch, > YARN-10623.006.patch, YARN-10623.007.patch, YARN-10623.008.patch, > YARN-10623.009.patch, YARN-10623.010.patch > > > In fair scheduler, it is supported that refresh queue related conf > automatically by a thread to reload, but in capacity scheduler we only > support to refresh queue related changes by refreshQueues, it is needed for > our cluster to realize queue manage. > cc [~wangda] [~ztang] [~pbacsko] [~snemeth] [~gandras] [~bteke] [~shuzirra] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10623) Capacity scheduler should support refresh queue automatically by a thread policy.
[ https://issues.apache.org/jira/browse/YARN-10623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293304#comment-17293304 ] Qi Zhu commented on YARN-10623: --- Thanks a lot [~pbacsko] for patient review, fixed it in latest patch.:D > Capacity scheduler should support refresh queue automatically by a thread > policy. > - > > Key: YARN-10623 > URL: https://issues.apache.org/jira/browse/YARN-10623 > Project: Hadoop YARN > Issue Type: Improvement > Components: capacity scheduler >Reporter: Qi Zhu >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10623.001.patch, YARN-10623.002.patch, > YARN-10623.003.patch, YARN-10623.004.patch, YARN-10623.005.patch, > YARN-10623.006.patch, YARN-10623.007.patch, YARN-10623.008.patch, > YARN-10623.009.patch > > > In fair scheduler, it is supported that refresh queue related conf > automatically by a thread to reload, but in capacity scheduler we only > support to refresh queue related changes by refreshQueues, it is needed for > our cluster to realize queue manage. > cc [~wangda] [~ztang] [~pbacsko] [~snemeth] [~gandras] [~bteke] [~shuzirra] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-10623) Capacity scheduler should support refresh queue automatically by a thread policy.
[ https://issues.apache.org/jira/browse/YARN-10623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qi Zhu updated YARN-10623: -- Attachment: YARN-10623.009.patch > Capacity scheduler should support refresh queue automatically by a thread > policy. > - > > Key: YARN-10623 > URL: https://issues.apache.org/jira/browse/YARN-10623 > Project: Hadoop YARN > Issue Type: Improvement > Components: capacity scheduler >Reporter: Qi Zhu >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10623.001.patch, YARN-10623.002.patch, > YARN-10623.003.patch, YARN-10623.004.patch, YARN-10623.005.patch, > YARN-10623.006.patch, YARN-10623.007.patch, YARN-10623.008.patch, > YARN-10623.009.patch > > > In fair scheduler, it is supported that refresh queue related conf > automatically by a thread to reload, but in capacity scheduler we only > support to refresh queue related changes by refreshQueues, it is needed for > our cluster to realize queue manage. > cc [~wangda] [~ztang] [~pbacsko] [~snemeth] [~gandras] [~bteke] [~shuzirra] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10658) CapacityScheduler QueueInfo getQueueName should change to queue path to avoid ambiguous QueueName.
[ https://issues.apache.org/jira/browse/YARN-10658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293303#comment-17293303 ] Qi Zhu commented on YARN-10658: --- Thanks [~pbacsko] for quick reply. QueueInfo is a report of the runtime information of the queue, it will be used in YarnCLI, not in the UI. I think it should be consistent with FS. And also it will cause the bug, when two queue have same name in CS queue now.:D > CapacityScheduler QueueInfo getQueueName should change to queue path to avoid > ambiguous QueueName. > -- > > Key: YARN-10658 > URL: https://issues.apache.org/jira/browse/YARN-10658 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Qi Zhu >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10658.001.patch > > > After the leaf queue can use same name, QueueInfo class getQueueName method > should change to queue path to avoid ambiguous QueueName, and make it > consistent with fairscheduler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-10532) Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is not being used
[ https://issues.apache.org/jira/browse/YARN-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qi Zhu updated YARN-10532: -- Attachment: YARN-10532.026.patch > Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is > not being used > > > Key: YARN-10532 > URL: https://issues.apache.org/jira/browse/YARN-10532 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Wangda Tan >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10532.001.patch, YARN-10532.002.patch, > YARN-10532.003.patch, YARN-10532.004.patch, YARN-10532.005.patch, > YARN-10532.006.patch, YARN-10532.007.patch, YARN-10532.008.patch, > YARN-10532.009.patch, YARN-10532.010.patch, YARN-10532.011.patch, > YARN-10532.012.patch, YARN-10532.013.patch, YARN-10532.014.patch, > YARN-10532.015.patch, YARN-10532.016.patch, YARN-10532.017.patch, > YARN-10532.018.patch, YARN-10532.019.patch, YARN-10532.020.patch, > YARN-10532.021.patch, YARN-10532.022.patch, YARN-10532.023.patch, > YARN-10532.024.patch, YARN-10532.025.patch, YARN-10532.026.patch, > image-2021-02-12-21-32-02-267.png > > > It's better if we can delete auto-created queues when they are not in use for > a period of time (like 5 mins). It will be helpful when we have a large > number of auto-created queues (e.g. from 500 users), but only a small subset > of queues are actively used. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10532) Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is not being used
[ https://issues.apache.org/jira/browse/YARN-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293299#comment-17293299 ] Qi Zhu commented on YARN-10532: --- Thanks [~bteke] for final check. [~pbacsko] I have fixed it in latest patch. Thanks again for all work in this jira. :D > Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is > not being used > > > Key: YARN-10532 > URL: https://issues.apache.org/jira/browse/YARN-10532 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Wangda Tan >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10532.001.patch, YARN-10532.002.patch, > YARN-10532.003.patch, YARN-10532.004.patch, YARN-10532.005.patch, > YARN-10532.006.patch, YARN-10532.007.patch, YARN-10532.008.patch, > YARN-10532.009.patch, YARN-10532.010.patch, YARN-10532.011.patch, > YARN-10532.012.patch, YARN-10532.013.patch, YARN-10532.014.patch, > YARN-10532.015.patch, YARN-10532.016.patch, YARN-10532.017.patch, > YARN-10532.018.patch, YARN-10532.019.patch, YARN-10532.020.patch, > YARN-10532.021.patch, YARN-10532.022.patch, YARN-10532.023.patch, > YARN-10532.024.patch, YARN-10532.025.patch, YARN-10532.026.patch, > image-2021-02-12-21-32-02-267.png > > > It's better if we can delete auto-created queues when they are not in use for > a period of time (like 5 mins). It will be helpful when we have a large > number of auto-created queues (e.g. from 500 users), but only a small subset > of queues are actively used. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10588) Percentage of queue and cluster is zero in WebUI
[
https://issues.apache.org/jira/browse/YARN-10588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293221#comment-17293221
]
Eric Payne commented on YARN-10588:
---
[~BilwaST], sorry for the delay in replying.
bq. Changing {{DominantResourceCalculator#isInvalidDivisor}} to
{{DominantResourceCalculator#isAllInvalidDivisor}} would solve problem. What do
you think?
I verified that {{isAllInvalidDivisor}} is only true if all resources are 0.
So, I agree that you could just replace with that.
[~Jim_Brennan], do you agree?
> Percentage of queue and cluster is zero in WebUI
> -
>
> Key: YARN-10588
> URL: https://issues.apache.org/jira/browse/YARN-10588
> Project: Hadoop YARN
> Issue Type: Bug
>Reporter: Bilwa S T
>Assignee: Bilwa S T
>Priority: Major
> Attachments: YARN-10588.001.patch, YARN-10588.002.patch,
> YARN-10588.003.patch
>
>
> Steps to reproduce:
> Configure below property in resource-types.xml
> {code:java}
>
> yarn.resource-types
> yarn.io/gpu
> {code}
> Submit a job
> In UI you can see % Of Queue and % Of Cluster is zero for the submitted
> application
>
> This is because in SchedulerApplicationAttempt has below check for
> calculating queueUsagePerc and clusterUsagePerc
> {code:java}
> if (!calc.isInvalidDivisor(cluster)) {
> float queueCapacityPerc = queue.getQueueInfo(false, false)
> .getCapacity();
> queueUsagePerc = calc.divide(cluster, usedResourceClone,
> Resources.multiply(cluster, queueCapacityPerc)) * 100;
> if (Float.isNaN(queueUsagePerc) || Float.isInfinite(queueUsagePerc)) {
> queueUsagePerc = 0.0f;
> }
> clusterUsagePerc =
> calc.divide(cluster, usedResourceClone, cluster) * 100;
> }
> {code}
> calc.isInvalidDivisor(cluster) always returns true as gpu resource is 0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10501) Can't remove all node labels after add node label without nodemanager port
[
https://issues.apache.org/jira/browse/YARN-10501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293211#comment-17293211
]
Eric Badger commented on YARN-10501:
Yea, go ahead and make the fixes from YARN-10653 and YARN-10647 and put them in
this patch. Then I'll add a comment to the other JIRAs when I update their fix
versions that this patch implemented the requisite changes
> Can't remove all node labels after add node label without nodemanager port
> --
>
> Key: YARN-10501
> URL: https://issues.apache.org/jira/browse/YARN-10501
> Project: Hadoop YARN
> Issue Type: Bug
> Components: yarn
>Affects Versions: 3.4.0
>Reporter: caozhiqiang
>Assignee: caozhiqiang
>Priority: Critical
> Fix For: 3.4.0, 3.3.1, 3.1.5, 3.2.3
>
> Attachments: YARN-10501-branch-2.10.1.001.patch,
> YARN-10501.002.patch, YARN-10501.003.patch, YARN-10501.004.patch
>
>
> When add a label to nodes without nodemanager port or use WILDCARD_PORT (0)
> port, it can't remove all label info in these nodes
> Reproduce process:
> {code:java}
> 1.yarn rmadmin -addToClusterNodeLabels "cpunode(exclusive=true)"
> 2.yarn rmadmin -replaceLabelsOnNode "server001=cpunode"
> 3.curl http://RM_IP:8088/ws/v1/cluster/label-mappings
> {"labelsToNodes":{"entry":{"key":{"name":"cpunode","exclusivity":"true"},"value":{"nodes":["server001:0","server001:45454"],"partitionInfo":{"resourceAvailable":{"memory":"510","vCores":"1","resourceInformations":{"resourceInformation":[{"attributes":null,"maximumAllocation":"9223372036854775807","minimumAllocation":"0","name":"memory-mb","resourceType":"COUNTABLE","units":"Mi","value":"510"},{"attributes":null,"maximumAllocation":"9223372036854775807","minimumAllocation":"0","name":"vcores","resourceType":"COUNTABLE","units":"","value":"1"}]}}}
> 4.yarn rmadmin -replaceLabelsOnNode "server001"
> 5.curl http://RM_IP:8088/ws/v1/cluster/label-mappings
> {"labelsToNodes":{"entry":{"key":{"name":"cpunode","exclusivity":"true"},"value":{"nodes":"server001:45454","partitionInfo":{"resourceAvailable":{"memory":"0","vCores":"0","resourceInformations":{"resourceInformation":[{"attributes":null,"maximumAllocation":"9223372036854775807","minimumAllocation":"0","name":"memory-mb","resourceType":"COUNTABLE","units":"Mi","value":"0"},{"attributes":null,"maximumAllocation":"9223372036854775807","minimumAllocation":"0","name":"vcores","resourceType":"COUNTABLE","units":"","value":"0"}]}}}
> {code}
> You can see after the 4 process to remove nodemanager labels, the label info
> is still in the node info.
> {code:java}
> 641 case REPLACE:
> 642 replaceNodeForLabels(nodeId, host.labels, labels);
> 643 replaceLabelsForNode(nodeId, host.labels, labels);
> 644 host.labels.clear();
> 645 host.labels.addAll(labels);
> 646 for (Node node : host.nms.values()) {
> 647 replaceNodeForLabels(node.nodeId, node.labels, labels);
> 649 node.labels = null;
> 650 }
> 651 break;{code}
> The cause is in 647 line, when add labels to node without port, the 0 port
> and the real nm port with be both add to node info, and when remove labels,
> the parameter node.labels in 647 line is null, so it will not remove the old
> label.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10655) Limit queue creation depth relative to its first static parent
[
https://issues.apache.org/jira/browse/YARN-10655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293128#comment-17293128
]
Peter Bacsko commented on YARN-10655:
-
I can't really comment on the changes because I'm very unfamiliar with the
newly introduced class.
The test method can be simplified:
{noformat}
try {
createQueue("root.a.a-auto.a2-auto.a3-auto");
Assert.fail("Queue creation should not succeed because the
distance " +
"from the first static parent is above limit");
} catch (SchedulerDynamicEditException ignored) {
}
{noformat}
Instead of the try-catch block, just use {{@Test(expected =
SchedulerDynamicEditException.class)}} and remove the assertion.
> Limit queue creation depth relative to its first static parent
> --
>
> Key: YARN-10655
> URL: https://issues.apache.org/jira/browse/YARN-10655
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: yarn
>Reporter: Andras Gyori
>Assignee: Andras Gyori
>Priority: Major
> Attachments: YARN-10655.001.patch
>
>
> YARN-10506 introduced a limit on the maximum depth of auto queue creation.
> This, however, only limits the levels of queue path relative to its first
> existing parent queue. It poses an unnecessary limitation on users, while
> providing no real safety net over rogue users (especially when YARN-10632
> makes this limit configurable), because it could be incrementally
> circumvented by creating a new queue under an existing dynamic parent queue.
> By bounding this limit to the first static parent queue in the hierarchy, we
> could have a safer alternative.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10655) Limit queue creation depth relative to its first static parent
[
https://issues.apache.org/jira/browse/YARN-10655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293123#comment-17293123
]
Hadoop QA commented on YARN-10655:
--
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Logfile || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
18s{color} | {color:blue}{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} || ||
| {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} No case conflicting files
found. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} The patch does not contain any
@author tags. {color} |
| {color:green}+1{color} | {color:green} {color} | {color:green} 0m 0s{color}
| {color:green}test4tests{color} | {color:green} The patch appears to include 1
new or modified test files. {color} |
|| || || || {color:brown} trunk Compile Tests {color} || ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 22m
34s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
1s{color} | {color:green}{color} | {color:green} trunk passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
51s{color} | {color:green}{color} | {color:green} trunk passed with JDK Private
Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
44s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
54s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
17m 7s{color} | {color:green}{color} | {color:green} branch has no errors when
building and testing our client artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
42s{color} | {color:green}{color} | {color:green} trunk passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
38s{color} | {color:green}{color} | {color:green} trunk passed with JDK Private
Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:blue}0{color} | {color:blue} spotbugs {color} | {color:blue} 2m
13s{color} | {color:blue}{color} | {color:blue} Used deprecated FindBugs
config; considering switching to SpotBugs. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
9s{color} | {color:green}{color} | {color:green} trunk passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} || ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
26s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
54s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
54s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
44s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
44s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
40s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
49s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} The patch has no whitespace
issues. {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
14m 54s{color} | {color:green}{color} | {color:green} patch has no errors when
building and testing our client artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
38s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green}{color} | {color:green} the
[jira] [Commented] (YARN-10623) Capacity scheduler should support refresh queue automatically by a thread policy.
[
https://issues.apache.org/jira/browse/YARN-10623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293122#comment-17293122
]
Peter Bacsko commented on YARN-10623:
-
[~zhuqi] thanks, I can see one thing: {{GenericTestUtils.waitFor()}} can be
simplified with lambdas, you don't need to use anonymous inner classes. So that
can be simplified, and remove the imported Supplier interface.
> Capacity scheduler should support refresh queue automatically by a thread
> policy.
> -
>
> Key: YARN-10623
> URL: https://issues.apache.org/jira/browse/YARN-10623
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: capacity scheduler
>Reporter: Qi Zhu
>Assignee: Qi Zhu
>Priority: Major
> Attachments: YARN-10623.001.patch, YARN-10623.002.patch,
> YARN-10623.003.patch, YARN-10623.004.patch, YARN-10623.005.patch,
> YARN-10623.006.patch, YARN-10623.007.patch, YARN-10623.008.patch
>
>
> In fair scheduler, it is supported that refresh queue related conf
> automatically by a thread to reload, but in capacity scheduler we only
> support to refresh queue related changes by refreshQueues, it is needed for
> our cluster to realize queue manage.
> cc [~wangda] [~ztang] [~pbacsko] [~snemeth] [~gandras] [~bteke] [~shuzirra]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (YARN-10532) Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is not being used
[ https://issues.apache.org/jira/browse/YARN-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293113#comment-17293113 ] Peter Bacsko edited comment on YARN-10532 at 3/1/21, 7:16 PM: -- [~zhuqi] please fix the things that [~bteke] mentioned and I think I'll commit this patch to trunk. Also pay attention to the remaining checkstyle issues. was (Author: pbacsko): [~zhuqi] please fix the things that [~bteke] mentioned and I think I'll commit this patch to trunk. > Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is > not being used > > > Key: YARN-10532 > URL: https://issues.apache.org/jira/browse/YARN-10532 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Wangda Tan >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10532.001.patch, YARN-10532.002.patch, > YARN-10532.003.patch, YARN-10532.004.patch, YARN-10532.005.patch, > YARN-10532.006.patch, YARN-10532.007.patch, YARN-10532.008.patch, > YARN-10532.009.patch, YARN-10532.010.patch, YARN-10532.011.patch, > YARN-10532.012.patch, YARN-10532.013.patch, YARN-10532.014.patch, > YARN-10532.015.patch, YARN-10532.016.patch, YARN-10532.017.patch, > YARN-10532.018.patch, YARN-10532.019.patch, YARN-10532.020.patch, > YARN-10532.021.patch, YARN-10532.022.patch, YARN-10532.023.patch, > YARN-10532.024.patch, YARN-10532.025.patch, image-2021-02-12-21-32-02-267.png > > > It's better if we can delete auto-created queues when they are not in use for > a period of time (like 5 mins). It will be helpful when we have a large > number of auto-created queues (e.g. from 500 users), but only a small subset > of queues are actively used. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10532) Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is not being used
[ https://issues.apache.org/jira/browse/YARN-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293113#comment-17293113 ] Peter Bacsko commented on YARN-10532: - [~zhuqi] please fix the things that [~bteke] mentioned and I think I'll commit this patch to trunk. > Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is > not being used > > > Key: YARN-10532 > URL: https://issues.apache.org/jira/browse/YARN-10532 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Wangda Tan >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10532.001.patch, YARN-10532.002.patch, > YARN-10532.003.patch, YARN-10532.004.patch, YARN-10532.005.patch, > YARN-10532.006.patch, YARN-10532.007.patch, YARN-10532.008.patch, > YARN-10532.009.patch, YARN-10532.010.patch, YARN-10532.011.patch, > YARN-10532.012.patch, YARN-10532.013.patch, YARN-10532.014.patch, > YARN-10532.015.patch, YARN-10532.016.patch, YARN-10532.017.patch, > YARN-10532.018.patch, YARN-10532.019.patch, YARN-10532.020.patch, > YARN-10532.021.patch, YARN-10532.022.patch, YARN-10532.023.patch, > YARN-10532.024.patch, YARN-10532.025.patch, image-2021-02-12-21-32-02-267.png > > > It's better if we can delete auto-created queues when they are not in use for > a period of time (like 5 mins). It will be helpful when we have a large > number of auto-created queues (e.g. from 500 users), but only a small subset > of queues are actively used. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10658) CapacityScheduler QueueInfo getQueueName should change to queue path to avoid ambiguous QueueName.
[ https://issues.apache.org/jira/browse/YARN-10658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293110#comment-17293110 ] Peter Bacsko commented on YARN-10658: - Thanks [~zhuqi] for the patch. How is this QueueInfo class used? If we set the full path instead of the short name, what changes? Are the UI or public interfaces affected in any way? > CapacityScheduler QueueInfo getQueueName should change to queue path to avoid > ambiguous QueueName. > -- > > Key: YARN-10658 > URL: https://issues.apache.org/jira/browse/YARN-10658 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Qi Zhu >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10658.001.patch > > > After the leaf queue can use same name, QueueInfo class getQueueName method > should change to queue path to avoid ambiguous QueueName, and make it > consistent with fairscheduler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10532) Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is not being used
[
https://issues.apache.org/jira/browse/YARN-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293075#comment-17293075
]
Hadoop QA commented on YARN-10532:
--
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Logfile || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
9s{color} | {color:blue}{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} || ||
| {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} No case conflicting files
found. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} The patch does not contain any
@author tags. {color} |
| {color:green}+1{color} | {color:green} {color} | {color:green} 0m 0s{color}
| {color:green}test4tests{color} | {color:green} The patch appears to include 3
new or modified test files. {color} |
|| || || || {color:brown} trunk Compile Tests {color} || ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 22m
4s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
59s{color} | {color:green}{color} | {color:green} trunk passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
49s{color} | {color:green}{color} | {color:green} trunk passed with JDK Private
Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
48s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
53s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
16m 49s{color} | {color:green}{color} | {color:green} branch has no errors when
building and testing our client artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
40s{color} | {color:green}{color} | {color:green} trunk passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
37s{color} | {color:green}{color} | {color:green} trunk passed with JDK Private
Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:blue}0{color} | {color:blue} spotbugs {color} | {color:blue} 1m
49s{color} | {color:blue}{color} | {color:blue} Used deprecated FindBugs
config; considering switching to SpotBugs. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
47s{color} | {color:green}{color} | {color:green} trunk passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} || ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
49s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
54s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
54s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
44s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
44s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange}
0m 43s{color} |
{color:orange}https://ci-hadoop.apache.org/job/PreCommit-YARN-Build/696/artifact/out/diff-checkstyle-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt{color}
| {color:orange}
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager:
The patch generated 8 new + 278 unchanged - 1 fixed = 286 total (was 279)
{color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
50s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} The patch has no whitespace
issues. {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
14m 43s{color} | {color:green}{color} | {color:green} patch has no errors when
building and testing our client artifacts. {color} |
|
[jira] [Commented] (YARN-10532) Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is not being used
[ https://issues.apache.org/jira/browse/YARN-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293008#comment-17293008 ] Benjamin Teke commented on YARN-10532: -- [~zhuqi], Thanks for the patch. Generally looks good to me, but the latest patch has a whitespace error in TestAutoCreatedQueueDeletionPolicy.java, the CI will most likely complain about that. Otherwise if you upload a new patch, can you please also remove the unused Supplier imports (where applicable, TestAutoCreatedQueueDeletionPolicy and TestCapacitySchedulerNewQueueAutoCreation have it) and close the mockRM in TestSchedulingMonitor.testRMUpdateAutoCreatedQueueDeletionPolicy? Thanks! > Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is > not being used > > > Key: YARN-10532 > URL: https://issues.apache.org/jira/browse/YARN-10532 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Wangda Tan >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10532.001.patch, YARN-10532.002.patch, > YARN-10532.003.patch, YARN-10532.004.patch, YARN-10532.005.patch, > YARN-10532.006.patch, YARN-10532.007.patch, YARN-10532.008.patch, > YARN-10532.009.patch, YARN-10532.010.patch, YARN-10532.011.patch, > YARN-10532.012.patch, YARN-10532.013.patch, YARN-10532.014.patch, > YARN-10532.015.patch, YARN-10532.016.patch, YARN-10532.017.patch, > YARN-10532.018.patch, YARN-10532.019.patch, YARN-10532.020.patch, > YARN-10532.021.patch, YARN-10532.022.patch, YARN-10532.023.patch, > YARN-10532.024.patch, YARN-10532.025.patch, image-2021-02-12-21-32-02-267.png > > > It's better if we can delete auto-created queues when they are not in use for > a period of time (like 5 mins). It will be helpful when we have a large > number of auto-created queues (e.g. from 500 users), but only a small subset > of queues are actively used. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (YARN-10532) Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is not being used
[
https://issues.apache.org/jira/browse/YARN-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292953#comment-17292953
]
Qi Zhu edited comment on YARN-10532 at 3/1/21, 3:29 PM:
Thanks a lot [~gandras] for final check.
The yarn.scheduler.capacity is actually in the property, this is queue level
setting for disabled auto deletion, the default is true and reasonable:
{code:java}
@Private
public boolean isAutoExpiredDeletionEnabled(String queuePath) {
boolean isAutoExpiredDeletionEnabled = getBoolean(
getQueuePrefix(queuePath) +
AUTO_CREATE_CHILD_QUEUE_AUTO_REMOVAL_ENABLE,
DEFAULT_AUTO_CREATE_CHILD_QUEUE_AUTO_REMOVAL_ENABLE);
return isAutoExpiredDeletionEnabled;
}
public static String getQueuePrefix(String queue) {
String queueName = PREFIX + queue + DOT;
return queueName;
}
@Private
public static final String PREFIX = "yarn.scheduler.capacity.";
{code}
Other things are fixed in latest patch.
[~pbacsko]
If you any other advice?
Thanks.
was (Author: zhuqi):
Thanks a lot [~gandras] for final check.
The yarn.scheduler.capacity is actually in the property, this is queue level
setting for disabled auto deletion:
{code:java}
@Private
public boolean isAutoExpiredDeletionEnabled(String queuePath) {
boolean isAutoExpiredDeletionEnabled = getBoolean(
getQueuePrefix(queuePath) +
AUTO_CREATE_CHILD_QUEUE_AUTO_REMOVAL_ENABLE,
DEFAULT_AUTO_CREATE_CHILD_QUEUE_AUTO_REMOVAL_ENABLE);
return isAutoExpiredDeletionEnabled;
}
public static String getQueuePrefix(String queue) {
String queueName = PREFIX + queue + DOT;
return queueName;
}
@Private
public static final String PREFIX = "yarn.scheduler.capacity.";
{code}
Other things are fixed in latest patch.
[~pbacsko]
If you any other advice?
Thanks.
> Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is
> not being used
>
>
> Key: YARN-10532
> URL: https://issues.apache.org/jira/browse/YARN-10532
> Project: Hadoop YARN
> Issue Type: Sub-task
>Reporter: Wangda Tan
>Assignee: Qi Zhu
>Priority: Major
> Attachments: YARN-10532.001.patch, YARN-10532.002.patch,
> YARN-10532.003.patch, YARN-10532.004.patch, YARN-10532.005.patch,
> YARN-10532.006.patch, YARN-10532.007.patch, YARN-10532.008.patch,
> YARN-10532.009.patch, YARN-10532.010.patch, YARN-10532.011.patch,
> YARN-10532.012.patch, YARN-10532.013.patch, YARN-10532.014.patch,
> YARN-10532.015.patch, YARN-10532.016.patch, YARN-10532.017.patch,
> YARN-10532.018.patch, YARN-10532.019.patch, YARN-10532.020.patch,
> YARN-10532.021.patch, YARN-10532.022.patch, YARN-10532.023.patch,
> YARN-10532.024.patch, YARN-10532.025.patch, image-2021-02-12-21-32-02-267.png
>
>
> It's better if we can delete auto-created queues when they are not in use for
> a period of time (like 5 mins). It will be helpful when we have a large
> number of auto-created queues (e.g. from 500 users), but only a small subset
> of queues are actively used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (YARN-10532) Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is not being used
[
https://issues.apache.org/jira/browse/YARN-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292953#comment-17292953
]
Qi Zhu edited comment on YARN-10532 at 3/1/21, 3:28 PM:
Thanks a lot [~gandras] for final check.
The yarn.scheduler.capacity is actually in the property, this is queue level
setting for disabled auto deletion:
{code:java}
@Private
public boolean isAutoExpiredDeletionEnabled(String queuePath) {
boolean isAutoExpiredDeletionEnabled = getBoolean(
getQueuePrefix(queuePath) +
AUTO_CREATE_CHILD_QUEUE_AUTO_REMOVAL_ENABLE,
DEFAULT_AUTO_CREATE_CHILD_QUEUE_AUTO_REMOVAL_ENABLE);
return isAutoExpiredDeletionEnabled;
}
public static String getQueuePrefix(String queue) {
String queueName = PREFIX + queue + DOT;
return queueName;
}
@Private
public static final String PREFIX = "yarn.scheduler.capacity.";
{code}
Other things are fixed in latest patch.
[~pbacsko]
If you any other advice?
Thanks.
was (Author: zhuqi):
Thanks a lot [~gandras] for final check.
The yarn.scheduler.capacity in the property is actually in the property, this
is queue level setting for disabled auto deletion:
{code:java}
@Private
public boolean isAutoExpiredDeletionEnabled(String queuePath) {
boolean isAutoExpiredDeletionEnabled = getBoolean(
getQueuePrefix(queuePath) +
AUTO_CREATE_CHILD_QUEUE_AUTO_REMOVAL_ENABLE,
DEFAULT_AUTO_CREATE_CHILD_QUEUE_AUTO_REMOVAL_ENABLE);
return isAutoExpiredDeletionEnabled;
}
public static String getQueuePrefix(String queue) {
String queueName = PREFIX + queue + DOT;
return queueName;
}
@Private
public static final String PREFIX = "yarn.scheduler.capacity.";
{code}
Other things are fixed in latest patch.
[~pbacsko]
If you any other advice?
Thanks.
> Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is
> not being used
>
>
> Key: YARN-10532
> URL: https://issues.apache.org/jira/browse/YARN-10532
> Project: Hadoop YARN
> Issue Type: Sub-task
>Reporter: Wangda Tan
>Assignee: Qi Zhu
>Priority: Major
> Attachments: YARN-10532.001.patch, YARN-10532.002.patch,
> YARN-10532.003.patch, YARN-10532.004.patch, YARN-10532.005.patch,
> YARN-10532.006.patch, YARN-10532.007.patch, YARN-10532.008.patch,
> YARN-10532.009.patch, YARN-10532.010.patch, YARN-10532.011.patch,
> YARN-10532.012.patch, YARN-10532.013.patch, YARN-10532.014.patch,
> YARN-10532.015.patch, YARN-10532.016.patch, YARN-10532.017.patch,
> YARN-10532.018.patch, YARN-10532.019.patch, YARN-10532.020.patch,
> YARN-10532.021.patch, YARN-10532.022.patch, YARN-10532.023.patch,
> YARN-10532.024.patch, YARN-10532.025.patch, image-2021-02-12-21-32-02-267.png
>
>
> It's better if we can delete auto-created queues when they are not in use for
> a period of time (like 5 mins). It will be helpful when we have a large
> number of auto-created queues (e.g. from 500 users), but only a small subset
> of queues are actively used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10532) Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is not being used
[
https://issues.apache.org/jira/browse/YARN-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292953#comment-17292953
]
Qi Zhu commented on YARN-10532:
---
Thanks a lot [~gandras] for final check.
The yarn.scheduler.capacity in the property is actually in the property, this
is queue level setting for disabled auto deletion:
{code:java}
@Private
public boolean isAutoExpiredDeletionEnabled(String queuePath) {
boolean isAutoExpiredDeletionEnabled = getBoolean(
getQueuePrefix(queuePath) +
AUTO_CREATE_CHILD_QUEUE_AUTO_REMOVAL_ENABLE,
DEFAULT_AUTO_CREATE_CHILD_QUEUE_AUTO_REMOVAL_ENABLE);
return isAutoExpiredDeletionEnabled;
}
public static String getQueuePrefix(String queue) {
String queueName = PREFIX + queue + DOT;
return queueName;
}
@Private
public static final String PREFIX = "yarn.scheduler.capacity.";
{code}
Other things are fixed in latest patch.
[~pbacsko]
If you any other advice?
Thanks.
> Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is
> not being used
>
>
> Key: YARN-10532
> URL: https://issues.apache.org/jira/browse/YARN-10532
> Project: Hadoop YARN
> Issue Type: Sub-task
>Reporter: Wangda Tan
>Assignee: Qi Zhu
>Priority: Major
> Attachments: YARN-10532.001.patch, YARN-10532.002.patch,
> YARN-10532.003.patch, YARN-10532.004.patch, YARN-10532.005.patch,
> YARN-10532.006.patch, YARN-10532.007.patch, YARN-10532.008.patch,
> YARN-10532.009.patch, YARN-10532.010.patch, YARN-10532.011.patch,
> YARN-10532.012.patch, YARN-10532.013.patch, YARN-10532.014.patch,
> YARN-10532.015.patch, YARN-10532.016.patch, YARN-10532.017.patch,
> YARN-10532.018.patch, YARN-10532.019.patch, YARN-10532.020.patch,
> YARN-10532.021.patch, YARN-10532.022.patch, YARN-10532.023.patch,
> YARN-10532.024.patch, YARN-10532.025.patch, image-2021-02-12-21-32-02-267.png
>
>
> It's better if we can delete auto-created queues when they are not in use for
> a period of time (like 5 mins). It will be helpful when we have a large
> number of auto-created queues (e.g. from 500 users), but only a small subset
> of queues are actively used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-10532) Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is not being used
[ https://issues.apache.org/jira/browse/YARN-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qi Zhu updated YARN-10532: -- Attachment: YARN-10532.025.patch > Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is > not being used > > > Key: YARN-10532 > URL: https://issues.apache.org/jira/browse/YARN-10532 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Wangda Tan >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10532.001.patch, YARN-10532.002.patch, > YARN-10532.003.patch, YARN-10532.004.patch, YARN-10532.005.patch, > YARN-10532.006.patch, YARN-10532.007.patch, YARN-10532.008.patch, > YARN-10532.009.patch, YARN-10532.010.patch, YARN-10532.011.patch, > YARN-10532.012.patch, YARN-10532.013.patch, YARN-10532.014.patch, > YARN-10532.015.patch, YARN-10532.016.patch, YARN-10532.017.patch, > YARN-10532.018.patch, YARN-10532.019.patch, YARN-10532.020.patch, > YARN-10532.021.patch, YARN-10532.022.patch, YARN-10532.023.patch, > YARN-10532.024.patch, YARN-10532.025.patch, image-2021-02-12-21-32-02-267.png > > > It's better if we can delete auto-created queues when they are not in use for > a period of time (like 5 mins). It will be helpful when we have a large > number of auto-created queues (e.g. from 500 users), but only a small subset > of queues are actively used. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10532) Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is not being used
[
https://issues.apache.org/jira/browse/YARN-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292912#comment-17292912
]
Andras Gyori commented on YARN-10532:
-
Hi [~zhuqi]. I have some final addition on the contribution (sorry for delaying
the commit). One major thing is:
* The auto queue removal switch is flawed. I am convinced that one would
expect to have yarn.scheduler.capacity in the property, but this is not the
case:
{code:java}
@Private
public static final String AUTO_CREATE_CHILD_QUEUE_AUTO_REMOVAL_ENABLE =
AUTO_QUEUE_CREATION_V2_PREFIX + "queue-auto-removal.enable";
{code}
There are some minor format issues in TestCapacitySchedulerNewQueueAutoCreation:
* There are still a lot of places where new Supplier is still used,
but sometimes it is replaced by a lambda. This is not consistent
* assertTrue(getNumApplications() == 0) asserts could be simplified to an
equals assert
Apart from those issues, the patch looks good to me.
> Capacity Scheduler Auto Queue Creation: Allow auto delete queue when queue is
> not being used
>
>
> Key: YARN-10532
> URL: https://issues.apache.org/jira/browse/YARN-10532
> Project: Hadoop YARN
> Issue Type: Sub-task
>Reporter: Wangda Tan
>Assignee: Qi Zhu
>Priority: Major
> Attachments: YARN-10532.001.patch, YARN-10532.002.patch,
> YARN-10532.003.patch, YARN-10532.004.patch, YARN-10532.005.patch,
> YARN-10532.006.patch, YARN-10532.007.patch, YARN-10532.008.patch,
> YARN-10532.009.patch, YARN-10532.010.patch, YARN-10532.011.patch,
> YARN-10532.012.patch, YARN-10532.013.patch, YARN-10532.014.patch,
> YARN-10532.015.patch, YARN-10532.016.patch, YARN-10532.017.patch,
> YARN-10532.018.patch, YARN-10532.019.patch, YARN-10532.020.patch,
> YARN-10532.021.patch, YARN-10532.022.patch, YARN-10532.023.patch,
> YARN-10532.024.patch, image-2021-02-12-21-32-02-267.png
>
>
> It's better if we can delete auto-created queues when they are not in use for
> a period of time (like 5 mins). It will be helpful when we have a large
> number of auto-created queues (e.g. from 500 users), but only a small subset
> of queues are actively used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10640) Adjust the queue Configured capacity to Configured weight number for weight mode in UI.
[ https://issues.apache.org/jira/browse/YARN-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292896#comment-17292896 ] Qi Zhu commented on YARN-10640: --- [~gandras] Thanks for your reply, i agree with you that the Configured Capacity is an absolute minimum resource only used in absolute mode, so it will be 0 in other mode, so the safe choice is that we can painless add a configure weights field. > Adjust the queue Configured capacity to Configured weight number for weight > mode in UI. > > > Key: YARN-10640 > URL: https://issues.apache.org/jira/browse/YARN-10640 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Qi Zhu >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10640.001.patch, YARN-10640.002.patch, > image-2021-02-20-11-21-50-306.png, image-2021-02-20-14-18-56-261.png, > image-2021-02-20-14-19-30-767.png > > > In weight mode: > Both the weight mode static queue and the dynamic queue will show the > Configured Capacity to 0. I think this should change to Configured Weight if > we use weight mode, this will be helpful. > Such as in dynamic weight mode queue: > !image-2021-02-20-11-21-50-306.png|width=528,height=374! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10640) Adjust the queue Configured capacity to Configured weight number for weight mode in UI.
[ https://issues.apache.org/jira/browse/YARN-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292891#comment-17292891 ] Andras Gyori commented on YARN-10640: - [~pbacsko] [~zhuqi] I have managed to track down the source of Configured Capacity, and it seems, that this is not the actual capacity we set for queues, therefore I am not convinced it is even related to weight mode at all. This property is accessed through CapacitySchedulerConfiguration#getMinimumResourceRequirement and it is an absolute minimum resource. I doubt that this should be replaced by weight. > Adjust the queue Configured capacity to Configured weight number for weight > mode in UI. > > > Key: YARN-10640 > URL: https://issues.apache.org/jira/browse/YARN-10640 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Qi Zhu >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10640.001.patch, YARN-10640.002.patch, > image-2021-02-20-11-21-50-306.png, image-2021-02-20-14-18-56-261.png, > image-2021-02-20-14-19-30-767.png > > > In weight mode: > Both the weight mode static queue and the dynamic queue will show the > Configured Capacity to 0. I think this should change to Configured Weight if > we use weight mode, this will be helpful. > Such as in dynamic weight mode queue: > !image-2021-02-20-11-21-50-306.png|width=528,height=374! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10639) Queueinfo related capacity, should adjusted to weight mode.
[
https://issues.apache.org/jira/browse/YARN-10639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292873#comment-17292873
]
Andras Gyori commented on YARN-10639:
-
I think this would come as an inconsistency. The REST API has a corresponding
weight field, in which the capacity is 0. I think we should follow this way
instead, but I see the point of [~zhuqi]. My suggestion is to wait with this
issue, or find a way to introduce weight property.
> Queueinfo related capacity, should adjusted to weight mode.
> ---
>
> Key: YARN-10639
> URL: https://issues.apache.org/jira/browse/YARN-10639
> Project: Hadoop YARN
> Issue Type: Sub-task
>Reporter: Qi Zhu
>Assignee: Qi Zhu
>Priority: Major
> Attachments: YARN-10639.001.patch, YARN-10639.002.patch
>
>
> {color:#172b4d}The class QueueInfo capacity field should consider the weight
> mode.{color}
> {color:#172b4d}Now when client use getQueueInfo to get queue capacity in
> weight mode, i always return 0, it is wrong.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-10660) YARN Web UI have problem when show node partitions resource
[
https://issues.apache.org/jira/browse/YARN-10660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tuyu updated YARN-10660:
Fix Version/s: 3.1.0
3.1.1
3.2.2
Affects Version/s: 3.1.0
3.1.1
3.2.2
> YARN Web UI have problem when show node partitions resource
> ---
>
> Key: YARN-10660
> URL: https://issues.apache.org/jira/browse/YARN-10660
> Project: Hadoop YARN
> Issue Type: Bug
> Components: webapp
>Affects Versions: 3.1.0, 3.1.1, 3.2.1, 3.2.2
>Reporter: tuyu
>Priority: Minor
> Fix For: 3.1.0, 3.1.1, 3.2.1, 3.2.2
>
> Attachments: 2021-03-01 19-56-02 的屏幕截图.png, YARN-10660.patch
>
>
> when enable yarn label function, Yarn UI will show queue resource base on
> partitions,but there have some problem when click expand button. The url will
> increase very long, like this
> {code:java}
> 127.0.0.1:20701/cluster/scheduler?openQueues=Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96
> {code}
> The root cause is
> {code:java}
>origin url is:
> Partition:
>htmlencode is:
> Partition: DEFAULT_PARTITION memory:491520, vCores:96
> SchedulerPageUtil have some javascript code
> storeExpandedQueue
> tmpCurrentParam = tmpCurrentParam.split('&');",
>the Partition: DEFAULT_PARTITION memory:491520, vCores:96
> will split and len > 1, the problem logic is here, if click expand button
> close, the function will clear params, but it the split array is not match
> orgin url
> {code}
> when click expand button close, lt;DEFAULT_PARTITION memory:491520,
> vCores:96 will append, if click expand multi times, the length will
> increase too long
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-10660) YARN Web UI have problem when show node partitions resource
[
https://issues.apache.org/jira/browse/YARN-10660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tuyu updated YARN-10660:
Target Version/s: 3.3.1, 3.2.3 (was: 3.2.3)
> YARN Web UI have problem when show node partitions resource
> ---
>
> Key: YARN-10660
> URL: https://issues.apache.org/jira/browse/YARN-10660
> Project: Hadoop YARN
> Issue Type: Bug
> Components: webapp
>Affects Versions: 3.2.1
>Reporter: tuyu
>Priority: Minor
> Fix For: 3.2.1
>
> Attachments: 2021-03-01 19-56-02 的屏幕截图.png, YARN-10660.patch
>
>
> when enable yarn label function, Yarn UI will show queue resource base on
> partitions,but there have some problem when click expand button. The url will
> increase very long, like this
> {code:java}
> 127.0.0.1:20701/cluster/scheduler?openQueues=Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96
> {code}
> The root cause is
> {code:java}
>origin url is:
> Partition:
>htmlencode is:
> Partition: DEFAULT_PARTITION memory:491520, vCores:96
> SchedulerPageUtil have some javascript code
> storeExpandedQueue
> tmpCurrentParam = tmpCurrentParam.split('&');",
>the Partition: DEFAULT_PARTITION memory:491520, vCores:96
> will split and len > 1, the problem logic is here, if click expand button
> close, the function will clear params, but it the split array is not match
> orgin url
> {code}
> when click expand button close, lt;DEFAULT_PARTITION memory:491520,
> vCores:96 will append, if click expand multi times, the length will
> increase too long
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-10660) YARN Web UI have problem when show node partitions resource
[
https://issues.apache.org/jira/browse/YARN-10660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tuyu updated YARN-10660:
Attachment: 2021-03-01 19-56-02 的屏幕截图.png
> YARN Web UI have problem when show node partitions resource
> ---
>
> Key: YARN-10660
> URL: https://issues.apache.org/jira/browse/YARN-10660
> Project: Hadoop YARN
> Issue Type: Bug
> Components: webapp
>Affects Versions: 3.2.1
>Reporter: tuyu
>Priority: Minor
> Fix For: 3.2.1
>
> Attachments: 2021-03-01 19-56-02 的屏幕截图.png, YARN-10660.patch
>
>
> when enable yarn label function, Yarn UI will show queue resource base on
> partitions,but there have some problem when click expand button. The url will
> increase very long, like this
> {code:java}
> 127.0.0.1:20701/cluster/scheduler?openQueues=Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96
> {code}
> The root cause is
> {code:java}
>origin url is:
> Partition:
>htmlencode is:
> Partition: DEFAULT_PARTITION memory:491520, vCores:96
> SchedulerPageUtil have some javascript code
> storeExpandedQueue
> tmpCurrentParam = tmpCurrentParam.split('&');",
>the Partition: DEFAULT_PARTITION memory:491520, vCores:96
> will split and len > 1, the problem logic is here, if click expand button
> close, the function will clear params, but it the split array is not match
> orgin url
> {code}
> when click expand button close, lt;DEFAULT_PARTITION memory:491520,
> vCores:96 will append, if click expand multi times, the length will
> increase too long
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Created] (YARN-10660) YARN Web UI have problem when show node partitions resource
tuyu created YARN-10660:
---
Summary: YARN Web UI have problem when show node partitions
resource
Key: YARN-10660
URL: https://issues.apache.org/jira/browse/YARN-10660
Project: Hadoop YARN
Issue Type: Bug
Components: webapp
Affects Versions: 3.2.1
Reporter: tuyu
Fix For: 3.2.1
when enable yarn label function, Yarn UI will show queue resource base on
partitions,but there have some problem when click expand button. The url will
increase very long, like this
{code:java}
127.0.0.1:20701/cluster/scheduler?openQueues=Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20#Partition:%20DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96DEFAULT_PARTITION%20memory:491520,%20vCores:96
{code}
The root cause is
{code:java}
origin url is:
Partition:
htmlencode is:
Partition: DEFAULT_PARTITION memory:491520, vCores:96
SchedulerPageUtil have some javascript code
storeExpandedQueue
tmpCurrentParam = tmpCurrentParam.split('&');",
the Partition: DEFAULT_PARTITION memory:491520, vCores:96
will split and len > 1, the problem logic is here, if click expand button
close, the function will clear params, but it the split array is not match
orgin url
{code}
when click expand button close, lt;DEFAULT_PARTITION memory:491520,
vCores:96 will append, if click expand multi times, the length will
increase too long
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Assigned] (YARN-10659) Improve CS MappingRule %secondary_group evaluation
[ https://issues.apache.org/jira/browse/YARN-10659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gergely Pollak reassigned YARN-10659: - Assignee: Gergely Pollak > Improve CS MappingRule %secondary_group evaluation > -- > > Key: YARN-10659 > URL: https://issues.apache.org/jira/browse/YARN-10659 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Gergely Pollak >Assignee: Gergely Pollak >Priority: Major > > Since the leaf queue names are not unique, there are a lot of use cases where > %secondary_group evaluation fail, or behave inconsistently. > We should extend it's behavior, when it's under a defined parent, > %secondary_group evaluation should only check for queue existence under that > queue. Egy root.group.%secondary_group, should only evaluate to groups which > exist under root.group, while the legacy %secondary_group.%user should still > look for groups by their leaf name globally. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Created] (YARN-10659) Improve CS MappingRule %secondary_group evaluation
Gergely Pollak created YARN-10659: - Summary: Improve CS MappingRule %secondary_group evaluation Key: YARN-10659 URL: https://issues.apache.org/jira/browse/YARN-10659 Project: Hadoop YARN Issue Type: Sub-task Reporter: Gergely Pollak Since the leaf queue names are not unique, there are a lot of use cases where %secondary_group evaluation fail, or behave inconsistently. We should extend it's behavior, when it's under a defined parent, %secondary_group evaluation should only check for queue existence under that queue. Egy root.group.%secondary_group, should only evaluate to groups which exist under root.group, while the legacy %secondary_group.%user should still look for groups by their leaf name globally. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Assigned] (YARN-10654) Dots '.' in CSMappingRule path variables should be replaced
[ https://issues.apache.org/jira/browse/YARN-10654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gergely Pollak reassigned YARN-10654: - Assignee: Gergely Pollak > Dots '.' in CSMappingRule path variables should be replaced > --- > > Key: YARN-10654 > URL: https://issues.apache.org/jira/browse/YARN-10654 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Gergely Pollak >Assignee: Gergely Pollak >Priority: Major > > Dots are used as separators, so we should escape them somehow in the > variables when substituting them. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10640) Adjust the queue Configured capacity to Configured weight number for weight mode in UI.
[ https://issues.apache.org/jira/browse/YARN-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292830#comment-17292830 ] Andras Gyori commented on YARN-10640: - I will check it out, but my first impression is that the configured capacity != calculated capacity. I think we return 0 capacity for all the queue, that has weight set. The calculated capacity is returned as the normalizedWeight attribute. This change is the same as YARN-10513, but for UIv1. > Adjust the queue Configured capacity to Configured weight number for weight > mode in UI. > > > Key: YARN-10640 > URL: https://issues.apache.org/jira/browse/YARN-10640 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Qi Zhu >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10640.001.patch, YARN-10640.002.patch, > image-2021-02-20-11-21-50-306.png, image-2021-02-20-14-18-56-261.png, > image-2021-02-20-14-19-30-767.png > > > In weight mode: > Both the weight mode static queue and the dynamic queue will show the > Configured Capacity to 0. I think this should change to Configured Weight if > we use weight mode, this will be helpful. > Such as in dynamic weight mode queue: > !image-2021-02-20-11-21-50-306.png|width=528,height=374! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10658) CapacityScheduler QueueInfo getQueueName should change to queue path to avoid ambiguous QueueName.
[
https://issues.apache.org/jira/browse/YARN-10658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292740#comment-17292740
]
Hadoop QA commented on YARN-10658:
--
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Logfile || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
23s{color} | {color:blue}{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} || ||
| {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} No case conflicting files
found. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} The patch does not contain any
@author tags. {color} |
| {color:green}+1{color} | {color:green} {color} | {color:green} 0m 0s{color}
| {color:green}test4tests{color} | {color:green} The patch appears to include 2
new or modified test files. {color} |
|| || || || {color:brown} trunk Compile Tests {color} || ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 23m
9s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
1s{color} | {color:green}{color} | {color:green} trunk passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
52s{color} | {color:green}{color} | {color:green} trunk passed with JDK Private
Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
49s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
54s{color} | {color:green}{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
16m 42s{color} | {color:green}{color} | {color:green} branch has no errors when
building and testing our client artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
40s{color} | {color:green}{color} | {color:green} trunk passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green}{color} | {color:green} trunk passed with JDK Private
Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:blue}0{color} | {color:blue} spotbugs {color} | {color:blue} 1m
49s{color} | {color:blue}{color} | {color:blue} Used deprecated FindBugs
config; considering switching to SpotBugs. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
47s{color} | {color:green}{color} | {color:green} trunk passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} || ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
48s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
53s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
53s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
44s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
44s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
42s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
48s{color} | {color:green}{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green}{color} | {color:green} The patch has no whitespace
issues. {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
14m 32s{color} | {color:green}{color} | {color:green} patch has no errors when
building and testing our client artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
37s{color} | {color:green}{color} | {color:green} the patch passed with JDK
Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
34s{color} | {color:green}{color} | {color:green} the
