[jira] [Commented] (YARN-10988) Spark application stuck at ACCEPTED state at spark-submit
[ https://issues.apache.org/jira/browse/YARN-10988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433127#comment-17433127 ] unical1988 commented on YARN-10988: --- OK sorry i thought it was a bug, because i set right the config. ??you probably don't have enough capacity for the #of cores your job wants.?? could you develop ? what's the property involved ? also is it OK to start dfs the way i do ? > Spark application stuck at ACCEPTED state at spark-submit > - > > Key: YARN-10988 > URL: https://issues.apache.org/jira/browse/YARN-10988 > Project: Hadoop YARN > Issue Type: Bug > Components: applications >Affects Versions: 3.2.1 >Reporter: unical1988 >Priority: Major > > Hello, > > I have configured & set Hadoop Cluster over 2 nodes and launch it along with > Yarn like so : > > *_On the master node :_* > * hdfs namenode -regular > * yarn resourcemanager > > *_On the slave node :_* > * hdfs datanode -regular > * yarn nodemanager > And it shows through UI that there has been a connection established between > the two machines that form the cluster. > To note that *_start-dfs_* on the master node started both namenode and > datanode even after setting *_slaves_* and *_hosts_* files. > Now i submit an application (simple _hello world_) to _Yarn_ : through this > command : > *Spark-submit --class "main" --master yarn pathToJar* > > But i get the error > 15/08/29 12:07:58 INFO Client: ApplicationManager is waiting for the > ResourceManager > client token: N/A diagnostics: N/A > ApplicationMaster host: N/A > ApplicationMaster RPC port: -1 > queue: root.hdfs > start time: 1440864477580 > final status: UNDEFINED tracking URL: > http://chd2.moneyball.guru:8088/proxy/application_1440861466017_0007/ user: > hdfs 15/08/29 12:07:59 INFO Client: Application report for > application_1440861466017_0007 (state: ACCEPTED) 15/08/29 12:08:00 INFO > Client: Application report for application_1440861466017_0007 (state: > ACCEPTED) 15/08/29 12:08:01 INFO Client: Application report for > application_1440861466017_0007 (state: ACCEPTED)... > > What am i missing in my configuration ? > > -- 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-10988) Spark application stuck at ACCEPTED state at spark-submit
[ https://issues.apache.org/jira/browse/YARN-10988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433097#comment-17433097 ] Steve Loughran commented on YARN-10988: --- * jIRA is for bug reports, not support issues. sorry * you probably don't have enough capacity for the #of cores your job wants. > Spark application stuck at ACCEPTED state at spark-submit > - > > Key: YARN-10988 > URL: https://issues.apache.org/jira/browse/YARN-10988 > Project: Hadoop YARN > Issue Type: Bug > Components: applications >Affects Versions: 3.2.1 >Reporter: unical1988 >Priority: Major > > Hello, > > I have configured & set Hadoop Cluster over 2 nodes and launch it along with > Yarn like so : > > *_On the master node :_* > * hdfs namenode -regular > * yarn resourcemanager > > *_On the slave node :_* > * hdfs datanode -regular > * yarn nodemanager > And it shows through UI that there has been a connection established between > the two machines that form the cluster. > To note that *_start-dfs_* on the master node started both namenode and > datanode even after setting *_slaves_* and *_hosts_* files. > Now i submit an application (simple _hello world_) to _Yarn_ : through this > command : > *Spark-submit --class "main" --master yarn pathToJar* > > But i get the error > 15/08/29 12:07:58 INFO Client: ApplicationManager is waiting for the > ResourceManager > client token: N/A diagnostics: N/A > ApplicationMaster host: N/A > ApplicationMaster RPC port: -1 > queue: root.hdfs > start time: 1440864477580 > final status: UNDEFINED tracking URL: > http://chd2.moneyball.guru:8088/proxy/application_1440861466017_0007/ user: > hdfs 15/08/29 12:07:59 INFO Client: Application report for > application_1440861466017_0007 (state: ACCEPTED) 15/08/29 12:08:00 INFO > Client: Application report for application_1440861466017_0007 (state: > ACCEPTED) 15/08/29 12:08:01 INFO Client: Application report for > application_1440861466017_0007 (state: ACCEPTED)... > > What am i missing in my configuration ? > > -- 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] [Resolved] (YARN-10988) Spark application stuck at ACCEPTED state at spark-submit
[ https://issues.apache.org/jira/browse/YARN-10988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Loughran resolved YARN-10988. --- Resolution: Invalid > Spark application stuck at ACCEPTED state at spark-submit > - > > Key: YARN-10988 > URL: https://issues.apache.org/jira/browse/YARN-10988 > Project: Hadoop YARN > Issue Type: Bug > Components: applications >Affects Versions: 3.2.1 >Reporter: unical1988 >Priority: Major > > Hello, > > I have configured & set Hadoop Cluster over 2 nodes and launch it along with > Yarn like so : > > *_On the master node :_* > * hdfs namenode -regular > * yarn resourcemanager > > *_On the slave node :_* > * hdfs datanode -regular > * yarn nodemanager > And it shows through UI that there has been a connection established between > the two machines that form the cluster. > To note that *_start-dfs_* on the master node started both namenode and > datanode even after setting *_slaves_* and *_hosts_* files. > Now i submit an application (simple _hello world_) to _Yarn_ : through this > command : > *Spark-submit --class "main" --master yarn pathToJar* > > But i get the error > 15/08/29 12:07:58 INFO Client: ApplicationManager is waiting for the > ResourceManager > client token: N/A diagnostics: N/A > ApplicationMaster host: N/A > ApplicationMaster RPC port: -1 > queue: root.hdfs > start time: 1440864477580 > final status: UNDEFINED tracking URL: > http://chd2.moneyball.guru:8088/proxy/application_1440861466017_0007/ user: > hdfs 15/08/29 12:07:59 INFO Client: Application report for > application_1440861466017_0007 (state: ACCEPTED) 15/08/29 12:08:00 INFO > Client: Application report for application_1440861466017_0007 (state: > ACCEPTED) 15/08/29 12:08:01 INFO Client: Application report for > application_1440861466017_0007 (state: ACCEPTED)... > > What am i missing in my configuration ? > > -- 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-1115) Provide optional means for a scheduler to check real user ACLs
[ https://issues.apache.org/jira/browse/YARN-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433076#comment-17433076 ] Ahmed Hussein commented on YARN-1115: - Thanks [~epayne] for working on the fix and providing the patches for the affected branches. I committed the patches to all the branches and marked the jira as fixed. > Provide optional means for a scheduler to check real user ACLs > -- > > Key: YARN-1115 > URL: https://issues.apache.org/jira/browse/YARN-1115 > Project: Hadoop YARN > Issue Type: Improvement > Components: capacity scheduler, scheduler >Affects Versions: 2.8.5 >Reporter: Eric Payne >Priority: Major > Fix For: 3.4.0, 2.10.2, 3.3.2, 3.2.4 > > Attachments: YARN-1115.001.patch, YARN-1115.002.patch, > YARN-1115.003.patch, YARN-1115.004.patch, YARN-1115.branch-2.10.004.patch, > YARN-1115.branch-3.2.004.patch, YARN-1115.branch-3.3.004.patch > > > In the framework for secure implementation using UserGroupInformation.doAs > (https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Superusers.html), > a trusted superuser can submit jobs on behalf of another user in a secure > way. In this framework, the superuser is referred to as the real user and the > proxied user is referred to as the effective user. > Currently when a job is submitted as an effective user, the ACLs for the > effective user are checked against the queue on which the job is to be run. > Depending on an optional configuration, the scheduler should also check the > ACLs of the real user if the configuration to do so is set. > For example, suppose my superuser name is super, and super is configured to > securely proxy as joe. Also suppose there is a Hadoop queue named ops which > only allows ACLs for super, not for joe. > When super proxies to joe in order to submit a job to the ops queue, it will > fail because joe, as the effective user, does not have ACLs on the ops queue. > In many cases this is what you want, in order to protect queues that joe > should not be using. > However, there are times when super may need to proxy to many users, and the > client running as super just wants to use the ops queue because the ops queue > is already dedicated to the client's purpose, and, to keep the ops queue > dedicated to that purpose, super doesn't want to open up ACLs to joe in > general on the ops queue. Without this functionality, in this case, the > client running as super needs to figure out which queue each user has ACLs > opened up for, and then coordinate with other tasks using those queues. -- 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-1115) Provide optional means for a scheduler to check real user ACLs
[ https://issues.apache.org/jira/browse/YARN-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ahmed Hussein updated YARN-1115: Fix Version/s: 2.10.2 > Provide optional means for a scheduler to check real user ACLs > -- > > Key: YARN-1115 > URL: https://issues.apache.org/jira/browse/YARN-1115 > Project: Hadoop YARN > Issue Type: Improvement > Components: capacity scheduler, scheduler >Affects Versions: 2.8.5 >Reporter: Eric Payne >Priority: Major > Fix For: 3.4.0, 2.10.2, 3.3.2, 3.2.4 > > Attachments: YARN-1115.001.patch, YARN-1115.002.patch, > YARN-1115.003.patch, YARN-1115.004.patch, YARN-1115.branch-2.10.004.patch, > YARN-1115.branch-3.2.004.patch, YARN-1115.branch-3.3.004.patch > > > In the framework for secure implementation using UserGroupInformation.doAs > (https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Superusers.html), > a trusted superuser can submit jobs on behalf of another user in a secure > way. In this framework, the superuser is referred to as the real user and the > proxied user is referred to as the effective user. > Currently when a job is submitted as an effective user, the ACLs for the > effective user are checked against the queue on which the job is to be run. > Depending on an optional configuration, the scheduler should also check the > ACLs of the real user if the configuration to do so is set. > For example, suppose my superuser name is super, and super is configured to > securely proxy as joe. Also suppose there is a Hadoop queue named ops which > only allows ACLs for super, not for joe. > When super proxies to joe in order to submit a job to the ops queue, it will > fail because joe, as the effective user, does not have ACLs on the ops queue. > In many cases this is what you want, in order to protect queues that joe > should not be using. > However, there are times when super may need to proxy to many users, and the > client running as super just wants to use the ops queue because the ops queue > is already dedicated to the client's purpose, and, to keep the ops queue > dedicated to that purpose, super doesn't want to open up ACLs to joe in > general on the ops queue. Without this functionality, in this case, the > client running as super needs to figure out which queue each user has ACLs > opened up for, and then coordinate with other tasks using those queues. -- 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-1115) Provide optional means for a scheduler to check real user ACLs
[ https://issues.apache.org/jira/browse/YARN-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ahmed Hussein updated YARN-1115: Fix Version/s: 3.2.4 > Provide optional means for a scheduler to check real user ACLs > -- > > Key: YARN-1115 > URL: https://issues.apache.org/jira/browse/YARN-1115 > Project: Hadoop YARN > Issue Type: Improvement > Components: capacity scheduler, scheduler >Affects Versions: 2.8.5 >Reporter: Eric Payne >Priority: Major > Fix For: 3.4.0, 3.3.2, 3.2.4 > > Attachments: YARN-1115.001.patch, YARN-1115.002.patch, > YARN-1115.003.patch, YARN-1115.004.patch, YARN-1115.branch-2.10.004.patch, > YARN-1115.branch-3.2.004.patch, YARN-1115.branch-3.3.004.patch > > > In the framework for secure implementation using UserGroupInformation.doAs > (https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Superusers.html), > a trusted superuser can submit jobs on behalf of another user in a secure > way. In this framework, the superuser is referred to as the real user and the > proxied user is referred to as the effective user. > Currently when a job is submitted as an effective user, the ACLs for the > effective user are checked against the queue on which the job is to be run. > Depending on an optional configuration, the scheduler should also check the > ACLs of the real user if the configuration to do so is set. > For example, suppose my superuser name is super, and super is configured to > securely proxy as joe. Also suppose there is a Hadoop queue named ops which > only allows ACLs for super, not for joe. > When super proxies to joe in order to submit a job to the ops queue, it will > fail because joe, as the effective user, does not have ACLs on the ops queue. > In many cases this is what you want, in order to protect queues that joe > should not be using. > However, there are times when super may need to proxy to many users, and the > client running as super just wants to use the ops queue because the ops queue > is already dedicated to the client's purpose, and, to keep the ops queue > dedicated to that purpose, super doesn't want to open up ACLs to joe in > general on the ops queue. Without this functionality, in this case, the > client running as super needs to figure out which queue each user has ACLs > opened up for, and then coordinate with other tasks using those queues. -- 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] [Resolved] (YARN-10930) Introduce universal configured capacity vector
[ https://issues.apache.org/jira/browse/YARN-10930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Szilard Nemeth resolved YARN-10930. --- Hadoop Flags: Reviewed Resolution: Fixed > Introduce universal configured capacity vector > -- > > Key: YARN-10930 > URL: https://issues.apache.org/jira/browse/YARN-10930 > Project: Hadoop YARN > Issue Type: Sub-task > Components: capacity scheduler >Reporter: Andras Gyori >Assignee: Andras Gyori >Priority: Major > Labels: pull-request-available > Fix For: 3.4.0 > > Attachments: capacity_scheduler_queue_capacity.html > > Time Spent: 6h 10m > Remaining Estimate: 0h > > The proposal is to introduce a capacity resource vector that is universally > parsed for every queue. CapacityResourceVector is a way to unite the current > capacity modes (weight, percentage, absolute), while maintaining flexibility > and extendability. > CapacityResourceVector is a good fit for the existing capacity configs, for > example: > * percentage mode: root.example.capacity 50 is a syntactic sugar for > [memory=50%, vcores=50%, ] > * absolute mode: root.example.capacity [memory=1024, vcores=2] is a natural > fit for the vector, there is no need for additional settings > CapacityResourceVector will be used in a future refactor, to unify the > resource calculation and lift the limitation imposed on the queue hierarchy > capacity settings (eg. can not use both absolute resource and percentage in > the same hierarchy etc...) -- 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-10930) Introduce universal configured capacity vector
[ https://issues.apache.org/jira/browse/YARN-10930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Szilard Nemeth updated YARN-10930: -- Fix Version/s: 3.4.0 > Introduce universal configured capacity vector > -- > > Key: YARN-10930 > URL: https://issues.apache.org/jira/browse/YARN-10930 > Project: Hadoop YARN > Issue Type: Sub-task > Components: capacity scheduler >Reporter: Andras Gyori >Assignee: Andras Gyori >Priority: Major > Labels: pull-request-available > Fix For: 3.4.0 > > Attachments: capacity_scheduler_queue_capacity.html > > Time Spent: 6h 10m > Remaining Estimate: 0h > > The proposal is to introduce a capacity resource vector that is universally > parsed for every queue. CapacityResourceVector is a way to unite the current > capacity modes (weight, percentage, absolute), while maintaining flexibility > and extendability. > CapacityResourceVector is a good fit for the existing capacity configs, for > example: > * percentage mode: root.example.capacity 50 is a syntactic sugar for > [memory=50%, vcores=50%, ] > * absolute mode: root.example.capacity [memory=1024, vcores=2] is a natural > fit for the vector, there is no need for additional settings > CapacityResourceVector will be used in a future refactor, to unify the > resource calculation and lift the limitation imposed on the queue hierarchy > capacity settings (eg. can not use both absolute resource and percentage in > the same hierarchy etc...) -- 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-10988) Spark application stuck at ACCEPTED state at spark-submit
unical1988 created YARN-10988: - Summary: Spark application stuck at ACCEPTED state at spark-submit Key: YARN-10988 URL: https://issues.apache.org/jira/browse/YARN-10988 Project: Hadoop YARN Issue Type: Bug Components: applications Affects Versions: 3.2.1 Reporter: unical1988 Hello, I have configured & set Hadoop Cluster over 2 nodes and launch it along with Yarn like so : *_On the master node :_* * hdfs namenode -regular * yarn resourcemanager *_On the slave node :_* * hdfs datanode -regular * yarn nodemanager And it shows through UI that there has been a connection established between the two machines that form the cluster. To note that *_start-dfs_* on the master node started both namenode and datanode even after setting *_slaves_* and *_hosts_* files. Now i submit an application (simple _hello world_) to _Yarn_ : through this command : *Spark-submit --class "main" --master yarn pathToJar* But i get the error 15/08/29 12:07:58 INFO Client: ApplicationManager is waiting for the ResourceManager client token: N/A diagnostics: N/A ApplicationMaster host: N/A ApplicationMaster RPC port: -1 queue: root.hdfs start time: 1440864477580 final status: UNDEFINED tracking URL: http://chd2.moneyball.guru:8088/proxy/application_1440861466017_0007/ user: hdfs 15/08/29 12:07:59 INFO Client: Application report for application_1440861466017_0007 (state: ACCEPTED) 15/08/29 12:08:00 INFO Client: Application report for application_1440861466017_0007 (state: ACCEPTED) 15/08/29 12:08:01 INFO Client: Application report for application_1440861466017_0007 (state: ACCEPTED)... What am i missing in my configuration ? -- 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-10951) CapacityScheduler: Move all fields and initializer code that belongs to async scheduling to a new class
[ https://issues.apache.org/jira/browse/YARN-10951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Szilard Nemeth reassigned YARN-10951: - Assignee: jackwangcs (was: Szilard Nemeth) > CapacityScheduler: Move all fields and initializer code that belongs to async > scheduling to a new class > --- > > Key: YARN-10951 > URL: https://issues.apache.org/jira/browse/YARN-10951 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Szilard Nemeth >Assignee: jackwangcs >Priority: Minor > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > There are certain if-statements that control whether to initialize some > async-scheduling related fields, based on the value of field called > 'scheduleAsynchronously'. > We could move these fields to a separate class for clarity. -- 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-10951) CapacityScheduler: Move all fields and initializer code that belongs to async scheduling to a new class
[ https://issues.apache.org/jira/browse/YARN-10951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433023#comment-17433023 ] Szilard Nemeth commented on YARN-10951: --- Hi [~jackwangcs], Do you have time to work on this in the foreseeable future? If not, I would take this over. > CapacityScheduler: Move all fields and initializer code that belongs to async > scheduling to a new class > --- > > Key: YARN-10951 > URL: https://issues.apache.org/jira/browse/YARN-10951 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Szilard Nemeth >Assignee: jackwangcs >Priority: Minor > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > There are certain if-statements that control whether to initialize some > async-scheduling related fields, based on the value of field called > 'scheduleAsynchronously'. > We could move these fields to a separate class for clarity. -- 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-10909) AbstractCSQueue: Check for methods added to test code but not annotated with VisibleForTesting
[ https://issues.apache.org/jira/browse/YARN-10909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Szilard Nemeth reassigned YARN-10909: - Assignee: Szilard Nemeth (was: jackwangcs) > AbstractCSQueue: Check for methods added to test code but not annotated with > VisibleForTesting > -- > > Key: YARN-10909 > URL: https://issues.apache.org/jira/browse/YARN-10909 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Szilard Nemeth >Assignee: Szilard Nemeth >Priority: Minor > Labels: newbie, pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > For example, AbstractCSQueue#setMaxCapacity(float) is only used for testing, > but not annotated. There can be other methods in this class like this. -- 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-10951) CapacityScheduler: Move all fields and initializer code that belongs to async scheduling to a new class
[ https://issues.apache.org/jira/browse/YARN-10951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Szilard Nemeth reassigned YARN-10951: - Assignee: Szilard Nemeth (was: jackwangcs) > CapacityScheduler: Move all fields and initializer code that belongs to async > scheduling to a new class > --- > > Key: YARN-10951 > URL: https://issues.apache.org/jira/browse/YARN-10951 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Szilard Nemeth >Assignee: Szilard Nemeth >Priority: Minor > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > There are certain if-statements that control whether to initialize some > async-scheduling related fields, based on the value of field called > 'scheduleAsynchronously'. > We could move these fields to a separate class for clarity. -- 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-10929) Refrain from creating new Configuration object in AbstractManagedParentQueue#initializeLeafQueueConfigs
[ https://issues.apache.org/jira/browse/YARN-10929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Szilard Nemeth reassigned YARN-10929: - Assignee: Szilard Nemeth (was: jackwangcs) > Refrain from creating new Configuration object in > AbstractManagedParentQueue#initializeLeafQueueConfigs > --- > > Key: YARN-10929 > URL: https://issues.apache.org/jira/browse/YARN-10929 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Szilard Nemeth >Assignee: Szilard Nemeth >Priority: Minor > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > AbstractManagedParentQueue#initializeLeafQueueConfigs creates a new > CapacitySchedulerConfiguration with templated configs only. We should stop > doing this. > Also, there is a sorting of config keys in this method, but in the end the > configs are added to the Configuration object which is an enhanced Map. -- 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-10948) Rename SchedulerQueue#activeQueue to activateQueue
[ https://issues.apache.org/jira/browse/YARN-10948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Szilard Nemeth updated YARN-10948: -- Fix Version/s: 3.4.0 > Rename SchedulerQueue#activeQueue to activateQueue > -- > > Key: YARN-10948 > URL: https://issues.apache.org/jira/browse/YARN-10948 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Szilard Nemeth >Assignee: Adam Antal >Priority: Minor > Labels: pull-request-available > Fix For: 3.4.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- 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-10632) Make maximum depth allowed to be configurable
[ https://issues.apache.org/jira/browse/YARN-10632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17432958#comment-17432958 ] Andras Gyori commented on YARN-10632: - [~zhuqi] may I assign this issue to myself? > Make maximum depth allowed to be configurable > - > > Key: YARN-10632 > URL: https://issues.apache.org/jira/browse/YARN-10632 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Qi Zhu >Assignee: Qi Zhu >Priority: Major > Attachments: YARN-10632.001.patch, YARN-10632.002.patch, > YARN-10632.003.patch, YARN-10632.004.patch > > > Now the max depth allowed are fixed to 2. But i think this should be > configurable. -- 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-10757) jsonschema2pojo-maven-plugin version is not defined
[
https://issues.apache.org/jira/browse/YARN-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Domok reassigned YARN-10757:
--
Assignee: Tamas Domok
> jsonschema2pojo-maven-plugin version is not defined
> ---
>
> Key: YARN-10757
> URL: https://issues.apache.org/jira/browse/YARN-10757
> Project: Hadoop YARN
> Issue Type: Bug
> Components: build
>Reporter: Akira Ajisaka
>Assignee: Tamas Domok
>Priority: Major
> Labels: newbie, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The below maven plugin version is not defined.
> {noformat}
> $ mvn install
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for org.apache.hadoop:hadoop-yarn-server-resourcemanager:jar:3.4.0-SNAPSHOT
> [WARNING] 'build.plugins.plugin.version' for
> org.jsonschema2pojo:jsonschema2pojo-maven-plugin is missing. @ line 448,
> column 15
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> {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] [Updated] (YARN-10757) jsonschema2pojo-maven-plugin version is not defined
[
https://issues.apache.org/jira/browse/YARN-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated YARN-10757:
--
Labels: newbie pull-request-available (was: newbie)
> jsonschema2pojo-maven-plugin version is not defined
> ---
>
> Key: YARN-10757
> URL: https://issues.apache.org/jira/browse/YARN-10757
> Project: Hadoop YARN
> Issue Type: Bug
> Components: build
>Reporter: Akira Ajisaka
>Priority: Major
> Labels: newbie, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The below maven plugin version is not defined.
> {noformat}
> $ mvn install
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for org.apache.hadoop:hadoop-yarn-server-resourcemanager:jar:3.4.0-SNAPSHOT
> [WARNING] 'build.plugins.plugin.version' for
> org.jsonschema2pojo:jsonschema2pojo-maven-plugin is missing. @ line 448,
> column 15
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> {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
