[jira] [Assigned] (YARN-10680) Revisit try blocks without catch blocks but having finally blocks
[ https://issues.apache.org/jira/browse/YARN-10680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti reassigned YARN-10680: -- Assignee: Susheel Gupta (was: Rudolf Reti) > Revisit try blocks without catch blocks but having finally blocks > - > > Key: YARN-10680 > URL: https://issues.apache.org/jira/browse/YARN-10680 > Project: Hadoop YARN > Issue Type: Bug >Reporter: Szilard Nemeth >Assignee: Susheel Gupta >Priority: Minor > Labels: newbie, trivial > > This jira is to revisit all try blocks without catch blocks but having > finally blocks in SLS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Assigned] (YARN-8262) get_executable in container-executor should provide meaningful error codes
[ https://issues.apache.org/jira/browse/YARN-8262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti reassigned YARN-8262: - Assignee: Susheel Gupta > get_executable in container-executor should provide meaningful error codes > -- > > Key: YARN-8262 > URL: https://issues.apache.org/jira/browse/YARN-8262 > Project: Hadoop YARN > Issue Type: Bug >Reporter: Miklos Szegedi >Assignee: Susheel Gupta >Priority: Minor > Labels: newbie, trivial > > Currently it calls exit(-1) that makes it difficult to debug without stderr. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Assigned] (YARN-6169) container-executor message on empty configuration file can be improved
[
https://issues.apache.org/jira/browse/YARN-6169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti reassigned YARN-6169:
-
Assignee: Riya Khandelwal (was: Chetna Chaudhari)
> container-executor message on empty configuration file can be improved
> --
>
> Key: YARN-6169
> URL: https://issues.apache.org/jira/browse/YARN-6169
> Project: Hadoop YARN
> Issue Type: Improvement
>Reporter: Miklos Szegedi
>Assignee: Riya Khandelwal
>Priority: Trivial
> Labels: newbie, trivial
>
> If the configuration file is empty, we get the following error message:
> {{Invalid configuration provided in /root/etc/hadoop/container-executor.cfg}}
> This is does not provide enough details to figure out what is the issue at
> the first glance. We should use something like 'Empty configuration file
> provided...'
> {code}
> if (cfg->size == 0) {
> fprintf(ERRORFILE, "Invalid configuration provided in %s\n", file_name);
> exit(INVALID_CONFIG_FILE);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Assigned] (YARN-6766) *AppsBlock classes need a printOrNA() helper method
[
https://issues.apache.org/jira/browse/YARN-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti reassigned YARN-6766:
-
Assignee: Riya Khandelwal
> *AppsBlock classes need a printOrNA() helper method
> ---
>
> Key: YARN-6766
> URL: https://issues.apache.org/jira/browse/YARN-6766
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: webapp
>Affects Versions: 2.8.1, 3.0.0-alpha3
>Reporter: Daniel Templeton
>Assignee: Riya Khandelwal
>Priority: Minor
> Labels: newbie, trivial
>
> The various {{*AppsBlock}} classes are riddled with statements like:
> {code}.append(appInfo.getReservedVCores() == -1 ? "N/A" :
> String.valueOf(appInfo.getReservedVCores())){code}
> The code would be much cleaner if there were a utility method for that
> operation, e.g.:
> {code}.append(printData(appInfo.getReservedCores())){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Assigned] (YARN-6766) *AppsBlock classes need a printOrNA() helper method
[
https://issues.apache.org/jira/browse/YARN-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti reassigned YARN-6766:
-
Assignee: (was: HondaWei)
> *AppsBlock classes need a printOrNA() helper method
> ---
>
> Key: YARN-6766
> URL: https://issues.apache.org/jira/browse/YARN-6766
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: webapp
>Affects Versions: 2.8.1, 3.0.0-alpha3
>Reporter: Daniel Templeton
>Priority: Minor
> Labels: newbie, trivial
>
> The various {{*AppsBlock}} classes are riddled with statements like:
> {code}.append(appInfo.getReservedVCores() == -1 ? "N/A" :
> String.valueOf(appInfo.getReservedVCores())){code}
> The code would be much cleaner if there were a utility method for that
> operation, e.g.:
> {code}.append(printData(appInfo.getReservedCores())){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Assigned] (YARN-10680) Revisit try blocks without catch blocks but having finally blocks
[ https://issues.apache.org/jira/browse/YARN-10680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti reassigned YARN-10680: -- Assignee: Rudolf Reti > Revisit try blocks without catch blocks but having finally blocks > - > > Key: YARN-10680 > URL: https://issues.apache.org/jira/browse/YARN-10680 > Project: Hadoop YARN > Issue Type: Bug >Reporter: Szilard Nemeth >Assignee: Rudolf Reti >Priority: Minor > Labels: newbie, trivial > > This jira is to revisit all try blocks without catch blocks but having > finally blocks in SLS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-6525) Linux container executor should not propagate application errors
[ https://issues.apache.org/jira/browse/YARN-6525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-6525: -- Labels: newbie (was: newbie trivial) > Linux container executor should not propagate application errors > > > Key: YARN-6525 > URL: https://issues.apache.org/jira/browse/YARN-6525 > Project: Hadoop YARN > Issue Type: Bug >Affects Versions: 3.0.0-alpha2 >Reporter: Miklos Szegedi >Priority: Major > Labels: newbie > > wait_and_get_exit_code currently returns the application error code as LCE > error code. This may overlap with LCE errors. Instead LCE should return a > fixed application failed error code. I should print the application error > into the logs. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9688) Variable description error of method in stateMachine class
[
https://issues.apache.org/jira/browse/YARN-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti updated YARN-9688:
--
Labels: Newbie (was: Newbie trivial)
> Variable description error of method in stateMachine class
> ---
>
> Key: YARN-9688
> URL: https://issues.apache.org/jira/browse/YARN-9688
> Project: Hadoop YARN
> Issue Type: Bug
>Reporter: runzhou wu
>Assignee: runzhou wu
>Priority: Trivial
> Labels: Newbie
> Attachments: YARN-9688.001.patch
>
>
> StateMachineFactory class
> /**
> * Effect a transition due to the effecting stimulus.
> * @param {color:#FF}state{color} current state
> * @param eventType trigger to initiate the transition
> * @param {color:#FF}cause{color} causal eventType context
> * @return transitioned state
> */
> private STATE doTransition
> (OPERAND operand, STATE oldState, EVENTTYPE eventType, EVENT event)
> throws InvalidStateTransitionException {
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-5030) Revisit o.a.h.y.s.rm.scheduler.ResourceUsage
[ https://issues.apache.org/jira/browse/YARN-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-5030: -- Labels: newbie++ trivial (was: newbie++) > Revisit o.a.h.y.s.rm.scheduler.ResourceUsage > > > Key: YARN-5030 > URL: https://issues.apache.org/jira/browse/YARN-5030 > Project: Hadoop YARN > Issue Type: Sub-task > Components: scheduler >Reporter: Karthik Kambatla >Assignee: Ray Chiang >Priority: Major > Labels: newbie++, trivial > > YARN-3092 introduced ResourceUsage class to track a number of things around > resources. The naming is a little ambiguous and hence less conducive to being > used elsewhere. > # UsageByLabel doesn't need to be label specific. A more descriptive name > (TenantResourceTracker) might be more apt - since the class tracks more than > just usage. > # Accordingly, ResourceUsage itself can be renamed to more descriptive (and > less ambiguous) to LabelWiseTenantResourceTracker or some such. > # TenantResourceTracker (previously UsageByLabel) should probably be a class > on its own, and the private ResourceType should be part of it instead of the > mapping against labels. > # Ideally, would like for the names to say allocation to capture allocation > instead of usage. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-5811) ConfigurationProvider must implement Closeable interface
[ https://issues.apache.org/jira/browse/YARN-5811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-5811: -- Labels: newbie (was: newbie trivial) > ConfigurationProvider must implement Closeable interface > > > Key: YARN-5811 > URL: https://issues.apache.org/jira/browse/YARN-5811 > Project: Hadoop YARN > Issue Type: Improvement > Components: yarn >Reporter: Denis Bolshakov >Priority: Minor > Labels: newbie > Attachments: YARN-5811.1.patch, YARN-5811.3.patch, YARN-5811.5.patch, > YARN-5811.6.patch > > > ConfigurationProvider declares close method, it would be so nice if the class > implements Closeable interface allowing to use `try with resources` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-6169) container-executor message on empty configuration file can be improved
[
https://issues.apache.org/jira/browse/YARN-6169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti updated YARN-6169:
--
Labels: newbie trivial (was: newbie)
> container-executor message on empty configuration file can be improved
> --
>
> Key: YARN-6169
> URL: https://issues.apache.org/jira/browse/YARN-6169
> Project: Hadoop YARN
> Issue Type: Improvement
>Reporter: Miklos Szegedi
>Assignee: Chetna Chaudhari
>Priority: Trivial
> Labels: newbie, trivial
>
> If the configuration file is empty, we get the following error message:
> {{Invalid configuration provided in /root/etc/hadoop/container-executor.cfg}}
> This is does not provide enough details to figure out what is the issue at
> the first glance. We should use something like 'Empty configuration file
> provided...'
> {code}
> if (cfg->size == 0) {
> fprintf(ERRORFILE, "Invalid configuration provided in %s\n", file_name);
> exit(INVALID_CONFIG_FILE);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-6371) NodeHealthCheckerService member vars should be final
[
https://issues.apache.org/jira/browse/YARN-6371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti updated YARN-6371:
--
Labels: newbie trivial (was: newbie)
> NodeHealthCheckerService member vars should be final
>
>
> Key: YARN-6371
> URL: https://issues.apache.org/jira/browse/YARN-6371
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: nodemanager
>Affects Versions: 3.0.0-alpha2
>Reporter: Daniel Templeton
>Assignee: Zola Petkovic
>Priority: Trivial
> Labels: newbie, trivial
>
> {code}
> private NodeHealthScriptRunner nodeHealthScriptRunner;
> private LocalDirsHandlerService dirsHandler;
> {code}
> They can both be final.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-6416) SIGNAL_CMD argument number is wrong
[
https://issues.apache.org/jira/browse/YARN-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti updated YARN-6416:
--
Labels: newbie trivial (was: newbie)
> SIGNAL_CMD argument number is wrong
> ---
>
> Key: YARN-6416
> URL: https://issues.apache.org/jira/browse/YARN-6416
> Project: Hadoop YARN
> Issue Type: Bug
>Reporter: Miklos Szegedi
>Assignee: Vidura Bhathiya Mudalige
>Priority: Minor
> Labels: newbie, trivial
>
> Yarn application signal command has two arguments, so the number below should
> be 2 I think.
> {code}
> opts.getOption(SIGNAL_CMD).setArgs(3);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-6442) Inaccurate javadoc in NodeManagerHardwareUtils.getContainerMemoryMB
[
https://issues.apache.org/jira/browse/YARN-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti updated YARN-6442:
--
Labels: newbie trivial (was: newbie)
> Inaccurate javadoc in NodeManagerHardwareUtils.getContainerMemoryMB
> ---
>
> Key: YARN-6442
> URL: https://issues.apache.org/jira/browse/YARN-6442
> Project: Hadoop YARN
> Issue Type: Bug
>Reporter: Miklos Szegedi
>Assignee: Siddharth Ahuja
>Priority: Minor
> Labels: newbie, trivial
>
> NodeManagerHardwareUtils.getContainerMemoryMB has the following javadoc:
> {code}
> "If the OS has a
>* ResourceCalculatorPlugin implemented, the calculation is 0.8 * (RAM - 2 *
>* JVM-memory) i.e. use 80% of the memory after accounting for memory used
> by
>* the DataNode and the NodeManager. If the number is less than 1GB, log a
>* warning message."
> {code}
> I think the accurate expression is 0.8*(RAM-2*JVM)-systemreserved. I also do
> not see the 1GB cap in the code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-6766) *AppsBlock classes need a printOrNA() helper method
[
https://issues.apache.org/jira/browse/YARN-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti updated YARN-6766:
--
Labels: newbie trivial (was: newbie)
> *AppsBlock classes need a printOrNA() helper method
> ---
>
> Key: YARN-6766
> URL: https://issues.apache.org/jira/browse/YARN-6766
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: webapp
>Affects Versions: 2.8.1, 3.0.0-alpha3
>Reporter: Daniel Templeton
>Assignee: HondaWei
>Priority: Minor
> Labels: newbie, trivial
>
> The various {{*AppsBlock}} classes are riddled with statements like:
> {code}.append(appInfo.getReservedVCores() == -1 ? "N/A" :
> String.valueOf(appInfo.getReservedVCores())){code}
> The code would be much cleaner if there were a utility method for that
> operation, e.g.:
> {code}.append(printData(appInfo.getReservedCores())){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-7101) Dedupe getNodePath implementation in ZKRMStateStore to use ZKCuratorManager
[
https://issues.apache.org/jira/browse/YARN-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti updated YARN-7101:
--
Labels: newbie trivial (was: newbie)
> Dedupe getNodePath implementation in ZKRMStateStore to use ZKCuratorManager
> ---
>
> Key: YARN-7101
> URL: https://issues.apache.org/jira/browse/YARN-7101
> Project: Hadoop YARN
> Issue Type: Improvement
>Reporter: Jonathan Hung
>Assignee: Jonathan Hung
>Priority: Major
> Labels: newbie, trivial
>
> ZKRMStateStore implements getNodePath like this: {noformat}
> @VisibleForTesting
> String getNodePath(String root, String nodeName) {
> return (root + "/" + nodeName);
> }{noformat}
> In HADOOP-14741 ZKCuratorManager adds the same implementation.
> We should dedupe this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9352) Multiple versions of createSchedulingRequest in FairSchedulerTestBase could be cleaned up
[ https://issues.apache.org/jira/browse/YARN-9352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-9352: -- Labels: newbie newbie++ trivial (was: newbie newbie++) > Multiple versions of createSchedulingRequest in FairSchedulerTestBase could > be cleaned up > - > > Key: YARN-9352 > URL: https://issues.apache.org/jira/browse/YARN-9352 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Szilard Nemeth >Assignee: Siddharth Ahuja >Priority: Minor > Labels: newbie, newbie++, trivial > > createSchedulingRequest in FairSchedulerTestBase is overloaded many times. > This could be more cleaner is we introduced a builder instead of calling > various forms of this method. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9688) Variable description error of method in stateMachine class
[
https://issues.apache.org/jira/browse/YARN-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti updated YARN-9688:
--
Labels: Newbie trivial (was: Newbie)
> Variable description error of method in stateMachine class
> ---
>
> Key: YARN-9688
> URL: https://issues.apache.org/jira/browse/YARN-9688
> Project: Hadoop YARN
> Issue Type: Bug
>Reporter: runzhou wu
>Assignee: runzhou wu
>Priority: Trivial
> Labels: Newbie, trivial
> Attachments: YARN-9688.001.patch
>
>
> StateMachineFactory class
> /**
> * Effect a transition due to the effecting stimulus.
> * @param {color:#FF}state{color} current state
> * @param eventType trigger to initiate the transition
> * @param {color:#FF}cause{color} causal eventType context
> * @return transitioned state
> */
> private STATE doTransition
> (OPERAND operand, STATE oldState, EVENTTYPE eventType, EVENT event)
> throws InvalidStateTransitionException {
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-4944) Handle lack of ResourceCalculatorPlugin gracefully
[ https://issues.apache.org/jira/browse/YARN-4944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-4944: -- Labels: newbie++ trivial (was: newbie++) > Handle lack of ResourceCalculatorPlugin gracefully > -- > > Key: YARN-4944 > URL: https://issues.apache.org/jira/browse/YARN-4944 > Project: Hadoop YARN > Issue Type: Improvement > Components: nodemanager >Affects Versions: 2.8.0 >Reporter: Karthik Kambatla >Priority: Major > Labels: newbie++, trivial > > On some systems (e.g. mac), the NM might not be able to instantiate a > ResourceCalculatorPlugin and leads to logging a bunch of error messages. We > could improve the way we handle this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-6474) CGroupsHandlerImpl.java has a few checkstyle issues left to be fixed after YARN-5301
[ https://issues.apache.org/jira/browse/YARN-6474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-6474: -- Labels: newbie trivial (was: newbie) > CGroupsHandlerImpl.java has a few checkstyle issues left to be fixed after > YARN-5301 > > > Key: YARN-6474 > URL: https://issues.apache.org/jira/browse/YARN-6474 > Project: Hadoop YARN > Issue Type: Bug >Reporter: Miklos Szegedi >Priority: Minor > Labels: newbie, trivial > > The main issue is throw inside finally -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-6525) Linux container executor should not propagate application errors
[ https://issues.apache.org/jira/browse/YARN-6525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-6525: -- Labels: newbie trivial (was: newbie) > Linux container executor should not propagate application errors > > > Key: YARN-6525 > URL: https://issues.apache.org/jira/browse/YARN-6525 > Project: Hadoop YARN > Issue Type: Bug >Affects Versions: 3.0.0-alpha2 >Reporter: Miklos Szegedi >Priority: Major > Labels: newbie, trivial > > wait_and_get_exit_code currently returns the application error code as LCE > error code. This may overlap with LCE errors. Instead LCE should return a > fixed application failed error code. I should print the application error > into the logs. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-8262) get_executable in container-executor should provide meaningful error codes
[ https://issues.apache.org/jira/browse/YARN-8262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-8262: -- Labels: newbie trivial (was: newbie) > get_executable in container-executor should provide meaningful error codes > -- > > Key: YARN-8262 > URL: https://issues.apache.org/jira/browse/YARN-8262 > Project: Hadoop YARN > Issue Type: Bug >Reporter: Miklos Szegedi >Priority: Minor > Labels: newbie, trivial > > Currently it calls exit(-1) that makes it difficult to debug without stderr. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-10680) Revisit try blocks without catch blocks but having finally blocks
[ https://issues.apache.org/jira/browse/YARN-10680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-10680: --- Labels: newbie trivial (was: newbie) > Revisit try blocks without catch blocks but having finally blocks > - > > Key: YARN-10680 > URL: https://issues.apache.org/jira/browse/YARN-10680 > Project: Hadoop YARN > Issue Type: Bug >Reporter: Szilard Nemeth >Priority: Minor > Labels: newbie, trivial > > This jira is to revisit all try blocks without catch blocks but having > finally blocks in SLS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-5810) RM Loglevel setting shouldn't return a valid value for a non-existing class
[ https://issues.apache.org/jira/browse/YARN-5810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-5810: -- Labels: log-level newbie trivial (was: log-level newbie) > RM Loglevel setting shouldn't return a valid value for a non-existing class > --- > > Key: YARN-5810 > URL: https://issues.apache.org/jira/browse/YARN-5810 > Project: Hadoop YARN > Issue Type: Bug > Components: resourcemanager >Affects Versions: 3.0.0-alpha1 >Reporter: Yufei Gu >Priority: Major > Labels: log-level, newbie, trivial > > The WebUI of RM Loglevel setting should not return a valid value, like INFO > for an non-existing class. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-5811) ConfigurationProvider must implement Closeable interface
[ https://issues.apache.org/jira/browse/YARN-5811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-5811: -- Labels: newbie trivial (was: newbie) > ConfigurationProvider must implement Closeable interface > > > Key: YARN-5811 > URL: https://issues.apache.org/jira/browse/YARN-5811 > Project: Hadoop YARN > Issue Type: Improvement > Components: yarn >Reporter: Denis Bolshakov >Priority: Minor > Labels: newbie, trivial > Attachments: YARN-5811.1.patch, YARN-5811.3.patch, YARN-5811.5.patch, > YARN-5811.6.patch > > > ConfigurationProvider declares close method, it would be so nice if the class > implements Closeable interface allowing to use `try with resources` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10505) Extend the maximum-capacity property to support Fair Scheduler migration
[
https://issues.apache.org/jira/browse/YARN-10505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17397393#comment-17397393
]
Rudolf Reti commented on YARN-10505:
[~epayne] You're right, we must make sure we keep BWC. Having said that, the
statement you cited refers to FS and is there to refine the scope from an
FS->CS migration point of view.
> Extend the maximum-capacity property to support Fair Scheduler migration
>
>
> Key: YARN-10505
> URL: https://issues.apache.org/jira/browse/YARN-10505
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: capacity scheduler
>Reporter: Benjamin Teke
>Assignee: Benjamin Teke
>Priority: Major
>
> Currently Fair Scheduler supports the following 3 kinds of settings:
> * Single percentage (relative to parent) i.e. "X%"
> * A set of percentages (relative to parent) i.e. "X% cpu, Y% memory"
> * Absolute resources i.e. "X mb, Y vcores"
> Please note, that the new, recommended format does not support the single
> percentage mode, only the last 2, like: “vcores=X, memory-mb=Y” or
> “vcores=X%, memory-mb=Y%” respectively.
> Tasks to accomplish:
> # It is recommended that all three formats are supported for
> maximum-capacity in CS after introducing weight mode.
> # Also we want to introduce the percentage modes relative to the cluster,
> not the parent, i.e The property root.users.maximum-capacity will mean one of
> the following things:
> ## Either Parent Percentage: maximum capacity relative to its parent. If
> it’s set to 50, then it means that the capacity is capped with respect to the
> parent. This can be covered by the current format, no change there.
> ## Or Cluster Percentage: maximum capacity expressed as a percentage of the
> overall cluster capacity. This case is the new scenario, for example:
> {{yarn.scheduler.capacity.root.users.max-capacity = c:50%}}
> {{yarn.scheduler.capacity.root.users.max-capacity = c:50%, c:30%}}
--
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-10758) Mixed mode: Allow relative and absolute mode in the same queue hierarchy
[
https://issues.apache.org/jira/browse/YARN-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti updated YARN-10758:
---
Description:
Fair Scheduler supports mixed mode for shares (FS equivalent of capacity). An
example scenario of such configuration:
{noformat}
root.a.capacity [memory-mb=7268, vcores=8]{noformat}
{noformat}
root.a.a1.capacity 50{noformat}
{noformat}
root.a.a2.capacity 50{noformat}
This above scenario is not supported in CS today because despite CS already
permits using weight mode and relative/percentage mode in the same hierarchy
the absolute mode and relative mode is mutually exclusive.
This improvement is a natural extension of CS to lift this limitation.
was:
Fair Scheduler supports mixed mode for capacity. An example scenario of such
configuration:
{noformat}
root.a.capacity [memory-mb=7268, vcores=8]{noformat}
{noformat}
root.a.a1.capacity 50{noformat}
{noformat}
root.a.a2.capacity 50{noformat}
Capacity Scheduler already permits using weight mode and relative/percentage
mode in the same hierarchy, however, the absolute mode and relative mode is
mutually exclusive. This improvement is a natural extension of CS to lift this
limitation.
> Mixed mode: Allow relative and absolute mode in the same queue hierarchy
>
>
> Key: YARN-10758
> URL: https://issues.apache.org/jira/browse/YARN-10758
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: capacity scheduler
>Reporter: Andras Gyori
>Assignee: Andras Gyori
>Priority: Major
>
> Fair Scheduler supports mixed mode for shares (FS equivalent of capacity). An
> example scenario of such configuration:
> {noformat}
> root.a.capacity [memory-mb=7268, vcores=8]{noformat}
> {noformat}
> root.a.a1.capacity 50{noformat}
> {noformat}
> root.a.a2.capacity 50{noformat}
> This above scenario is not supported in CS today because despite CS already
> permits using weight mode and relative/percentage mode in the same hierarchy
> the absolute mode and relative mode is mutually exclusive.
> This improvement is a natural extension of CS to lift this limitation.
--
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-10758) Mixed mode: Allow relative and absolute mode in the same queue hierarchy
[
https://issues.apache.org/jira/browse/YARN-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti updated YARN-10758:
---
Description:
Fair Scheduler supports mixed mode for capacity. An example scenario of such
configuration:
{noformat}
root.a.capacity [memory-mb=7268, vcores=8]{noformat}
{noformat}
root.a.a1.capacity 50{noformat}
{noformat}
root.a.a2.capacity 50{noformat}
Capacity Scheduler already permits using weight mode and relative/percentage
mode in the same hierarchy, however, the absolute mode and relative mode is
mutually exclusive. This improvement is a natural extension of CS to lift this
limitation.
was:
Fair Scheduler supports mixed mode for maximum capacity. An example scenario of
such configuration:
{noformat}
root.a.capacity [memory-mb=7268, vcores=8]{noformat}
{noformat}
root.a.a1.capacity 50{noformat}
{noformat}
root.a.a2.capacity 50{noformat}
Capacity Scheduler already permits using weight mode and relative/percentage
mode in the same hierarchy, however, the absolute mode and relative mode is
mutually exclusive. This improvement is a natural extension of CS to lift this
limitation.
> Mixed mode: Allow relative and absolute mode in the same queue hierarchy
>
>
> Key: YARN-10758
> URL: https://issues.apache.org/jira/browse/YARN-10758
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: capacity scheduler
>Reporter: Andras Gyori
>Assignee: Andras Gyori
>Priority: Major
>
> Fair Scheduler supports mixed mode for capacity. An example scenario of such
> configuration:
> {noformat}
> root.a.capacity [memory-mb=7268, vcores=8]{noformat}
> {noformat}
> root.a.a1.capacity 50{noformat}
> {noformat}
> root.a.a2.capacity 50{noformat}
> Capacity Scheduler already permits using weight mode and relative/percentage
> mode in the same hierarchy, however, the absolute mode and relative mode is
> mutually exclusive. This improvement is a natural extension of CS to lift
> this limitation.
--
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-10505) Extend the maximum-capacity property to support Fair Scheduler migration
[
https://issues.apache.org/jira/browse/YARN-10505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti updated YARN-10505:
---
Description:
Currently Fair Scheduler supports the following 3 kinds of settings:
* Single percentage (relative to parent) i.e. "X%"
* A set of percentages (relative to parent) i.e. "X% cpu, Y% memory"
* Absolute resources i.e. "X mb, Y vcores"
Please note, that the new, recommended format does not support the single
percentage mode, only the last 2, like: “vcores=X, memory-mb=Y” or “vcores=X%,
memory-mb=Y%” respectively.
Tasks to accomplish:
# It is recommended that all three formats are supported for maximum-capacity
in CS after introducing weight mode.
# Also we want to introduce the percentage modes relative to the cluster, not
the parent, i.e The property root.users.maximum-capacity will mean one of the
following things:
## Either Parent Percentage: maximum capacity relative to its parent. If it’s
set to 50, then it means that the capacity is capped with respect to the
parent. This can be covered by the current format, no change there.
## Or Cluster Percentage: maximum capacity expressed as a percentage of the
overall cluster capacity. This case is the new scenario, for example:
{{yarn.scheduler.capacity.root.users.max-capacity = c:50%}}
{{yarn.scheduler.capacity.root.users.max-capacity = c:50%, c:30%}}
was:
Currently Fair Scheduler supports the following 3 kinds of settings:
* Single percentage (relative to parent) i.e. "X%"
* A set of percentages (relative to parent) i.e. "X% cpu, Y% memory"
* Absolute resources i.e. "X mb, Y vcores"
Please note, that the new, recommended format does not support the single
percentage mode, only the last 2, like: “vcores=X, memory-mb=Y” or “vcores=X%,
memory-mb=Y%” respectively.
Tasks to accomplish:
# It is recommended that all three formats are supported for maximum-capacity
in CS after introducing weight mode.
# Also we want to introduce the percentage modes relative to the cluster, not
the parent, i.e The property root.users.maximum-capacity will mean one of the
following things:
## Either Parent Percentage: maximum capacity relative to its parent. If it’s
set to 50, then it means that the capacity is capped with respect to the parent.
## Or Cluster Percentage: maximum capacity expressed as a percentage of the
overall cluster capacity.
> Extend the maximum-capacity property to support Fair Scheduler migration
>
>
> Key: YARN-10505
> URL: https://issues.apache.org/jira/browse/YARN-10505
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: capacity scheduler
>Reporter: Benjamin Teke
>Assignee: Benjamin Teke
>Priority: Major
>
> Currently Fair Scheduler supports the following 3 kinds of settings:
> * Single percentage (relative to parent) i.e. "X%"
> * A set of percentages (relative to parent) i.e. "X% cpu, Y% memory"
> * Absolute resources i.e. "X mb, Y vcores"
> Please note, that the new, recommended format does not support the single
> percentage mode, only the last 2, like: “vcores=X, memory-mb=Y” or
> “vcores=X%, memory-mb=Y%” respectively.
> Tasks to accomplish:
> # It is recommended that all three formats are supported for
> maximum-capacity in CS after introducing weight mode.
> # Also we want to introduce the percentage modes relative to the cluster,
> not the parent, i.e The property root.users.maximum-capacity will mean one of
> the following things:
> ## Either Parent Percentage: maximum capacity relative to its parent. If
> it’s set to 50, then it means that the capacity is capped with respect to the
> parent. This can be covered by the current format, no change there.
> ## Or Cluster Percentage: maximum capacity expressed as a percentage of the
> overall cluster capacity. This case is the new scenario, for example:
> {{yarn.scheduler.capacity.root.users.max-capacity = c:50%}}
> {{yarn.scheduler.capacity.root.users.max-capacity = c:50%, c:30%}}
--
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-10505) Extend the maximum-capacity property to support Fair Scheduler migration
[ https://issues.apache.org/jira/browse/YARN-10505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-10505: --- Summary: Extend the maximum-capacity property to support Fair Scheduler migration (was: Extend the capacity and maximum-capacity property to support Fair Scheduler migration) > Extend the maximum-capacity property to support Fair Scheduler migration > > > Key: YARN-10505 > URL: https://issues.apache.org/jira/browse/YARN-10505 > Project: Hadoop YARN > Issue Type: Sub-task > Components: capacity scheduler >Reporter: Benjamin Teke >Assignee: Benjamin Teke >Priority: Major > > Currently Fair Scheduler supports the following 3 kinds of settings: > * Single percentage (relative to parent) i.e. "X%" > * A set of percentages (relative to parent) i.e. "X% cpu, Y% memory" > * Absolute resources i.e. "X mb, Y vcores" > Please note, that the new, recommended format does not support the single > percentage mode, only the last 2, like: “vcores=X, memory-mb=Y” or > “vcores=X%, memory-mb=Y%” respectively. > Tasks to accomplish: > # It is recommended that all three formats are supported for > maximum-capacity in CS after introducing weight mode. > # Also we want to introduce the percentage modes relative to the cluster, > not the parent, i.e The property root.users.maximum-capacity will mean one of > the following things: > ## Either Parent Percentage: maximum capacity relative to its parent. If > it’s set to 50, then it means that the capacity is capped with respect to the > parent. > ## Or Cluster Percentage: maximum capacity expressed as a percentage of the > overall cluster capacity. -- 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-10505) Extend the capacity and maximum-capacity property to support Fair Scheduler migration
[ https://issues.apache.org/jira/browse/YARN-10505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-10505: --- Component/s: capacity scheduler > Extend the capacity and maximum-capacity property to support Fair Scheduler > migration > - > > Key: YARN-10505 > URL: https://issues.apache.org/jira/browse/YARN-10505 > Project: Hadoop YARN > Issue Type: Sub-task > Components: capacity scheduler >Reporter: Benjamin Teke >Assignee: Benjamin Teke >Priority: Major > > Currently Fair Scheduler supports the following 3 kinds of settings: > * Single percentage (relative to parent) i.e. "X%" > * A set of percentages (relative to parent) i.e. "X% cpu, Y% memory" > * Absolute resources i.e. "X mb, Y vcores" > Please note, that the new, recommended format does not support the single > percentage mode, only the last 2, like: “vcores=X, memory-mb=Y” or > “vcores=X%, memory-mb=Y%” respectively. > Tasks to accomplish: > # It is recommended that all three formats are supported for > maximum-capacity in CS after introducing weight mode. > # Also we want to introduce the percentage modes relative to the cluster, > not the parent, i.e The property root.users.maximum-capacity will mean one of > the following things: > ## Either Parent Percentage: maximum capacity relative to its parent. If > it’s set to 50, then it means that the capacity is capped with respect to the > parent. > ## Or Cluster Percentage: maximum capacity expressed as a percentage of the > overall cluster capacity. -- 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-10505) Extend the capacity and maximum-capacity property to support Fair Scheduler migration
[ https://issues.apache.org/jira/browse/YARN-10505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-10505: --- Description: Currently Fair Scheduler supports the following 3 kinds of settings: * Single percentage (relative to parent) i.e. "X%" * A set of percentages (relative to parent) i.e. "X% cpu, Y% memory" * Absolute resources i.e. "X mb, Y vcores" Please note, that the new, recommended format does not support the single percentage mode, only the last 2, like: “vcores=X, memory-mb=Y” or “vcores=X%, memory-mb=Y%” respectively. Tasks to accomplish: # It is recommended that all three formats are supported for maximum-capacity in CS after introducing weight mode. # Also we want to introduce the percentage modes relative to the cluster, not the parent, i.e The property root.users.maximum-capacity will mean one of the following things: ## Either Parent Percentage: maximum capacity relative to its parent. If it’s set to 50, then it means that the capacity is capped with respect to the parent. ## Or Cluster Percentage: maximum capacity expressed as a percentage of the overall cluster capacity. was: The property root.users.maximum-capacity could mean the following things: * Parent Percentage: maximum capacity relative to its parent. If it’s set to 50, then it means that the capacity is capped with respect to the parent. * Cluster Percentage: maximum capacity expressed as a percentage of the overall cluster capacity. Note that Fair Scheduler supports the following settings: * Single percentage (cluster) * Two percentages (cluster) * Absolute resources It is recommended that all three formats are supported for maximum-capacity after introducing weight mode. > Extend the capacity and maximum-capacity property to support Fair Scheduler > migration > - > > Key: YARN-10505 > URL: https://issues.apache.org/jira/browse/YARN-10505 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Benjamin Teke >Assignee: Benjamin Teke >Priority: Major > > Currently Fair Scheduler supports the following 3 kinds of settings: > * Single percentage (relative to parent) i.e. "X%" > * A set of percentages (relative to parent) i.e. "X% cpu, Y% memory" > * Absolute resources i.e. "X mb, Y vcores" > Please note, that the new, recommended format does not support the single > percentage mode, only the last 2, like: “vcores=X, memory-mb=Y” or > “vcores=X%, memory-mb=Y%” respectively. > Tasks to accomplish: > # It is recommended that all three formats are supported for > maximum-capacity in CS after introducing weight mode. > # Also we want to introduce the percentage modes relative to the cluster, > not the parent, i.e The property root.users.maximum-capacity will mean one of > the following things: > ## Either Parent Percentage: maximum capacity relative to its parent. If > it’s set to 50, then it means that the capacity is capped with respect to the > parent. > ## Or Cluster Percentage: maximum capacity expressed as a percentage of the > overall cluster capacity. -- 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-10505) Extend the capacity and maximum-capacity property to support Fair Scheduler migration
[ https://issues.apache.org/jira/browse/YARN-10505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudolf Reti updated YARN-10505: --- Summary: Extend the capacity and maximum-capacity property to support Fair Scheduler migration (was: Extend the maximum-capacity property to support Fair Scheduler migration) > Extend the capacity and maximum-capacity property to support Fair Scheduler > migration > - > > Key: YARN-10505 > URL: https://issues.apache.org/jira/browse/YARN-10505 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Benjamin Teke >Assignee: Benjamin Teke >Priority: Major > > The property root.users.maximum-capacity could mean the following things: > * Parent Percentage: maximum capacity relative to its parent. If it’s set to > 50, then it means that the capacity is capped with respect to the parent. > * Cluster Percentage: maximum capacity expressed as a percentage of the > overall cluster capacity. > > Note that Fair Scheduler supports the following settings: > * Single percentage (cluster) > * Two percentages (cluster) > * Absolute resources > > It is recommended that all three formats are supported for maximum-capacity > after introducing weight mode. -- 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-6221) Entities missing from ATS when summary log file info got returned to the ATS before the domain log
[
https://issues.apache.org/jira/browse/YARN-6221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti reassigned YARN-6221:
-
Assignee: Xiaomin Zhang (was: Li Lu)
> Entities missing from ATS when summary log file info got returned to the ATS
> before the domain log
> --
>
> Key: YARN-6221
> URL: https://issues.apache.org/jira/browse/YARN-6221
> Project: Hadoop YARN
> Issue Type: Bug
> Components: yarn
>Reporter: Sushmitha Sreenivasan
>Assignee: Xiaomin Zhang
>Priority: Critical
>
> Events data missing for the following entities:
> curl -k --negotiate -u:
> http://:8188/ws/v1/timeline/TEZ_APPLICATION_ATTEMPT/tez_appattempt_1487706062210_0012_01
> {"events":[],"entitytype":"TEZ_APPLICATION_ATTEMPT","entity":"tez_appattempt_1487706062210_0012_01","starttime":1487711606077,"domain":"Tez_ATS_application_1487706062210_0012","relatedentities":{"TEZ_DAG_ID":["dag_1487706062210_0012_2","dag_1487706062210_0012_1"]},"primaryfilters":{},"otherinfo":{}}
> {code:title=Timeline Server log entry}
> WARN timeline.TimelineDataManager
> (TimelineDataManager.java:doPostEntities(366)) - Skip the timeline entity: {
> id: tez_application_1487706062210_0012, type: TEZ_APPLICATION }
> org.apache.hadoop.yarn.exceptions.YarnException: Domain information of the
> timeline entity { id: tez_application_1487706062210_0012, type:
> TEZ_APPLICATION } doesn't exist.
> at
> org.apache.hadoop.yarn.server.timeline.security.TimelineACLsManager.checkAccess(TimelineACLsManager.java:122)
> at
> org.apache.hadoop.yarn.server.timeline.TimelineDataManager.doPostEntities(TimelineDataManager.java:356)
> at
> org.apache.hadoop.yarn.server.timeline.TimelineDataManager.postEntities(TimelineDataManager.java:316)
> at
> org.apache.hadoop.yarn.server.timeline.EntityLogInfo.doParse(LogInfo.java:204)
> at
> org.apache.hadoop.yarn.server.timeline.LogInfo.parsePath(LogInfo.java:156)
> at
> org.apache.hadoop.yarn.server.timeline.LogInfo.parseForStore(LogInfo.java:113)
> at
> org.apache.hadoop.yarn.server.timeline.EntityGroupFSTimelineStore$AppLogs.parseSummaryLogs(EntityGroupFSTimelineStore.java:682)
> at
> org.apache.hadoop.yarn.server.timeline.EntityGroupFSTimelineStore$AppLogs.parseSummaryLogs(EntityGroupFSTimelineStore.java:657)
> at
> org.apache.hadoop.yarn.server.timeline.EntityGroupFSTimelineStore$ActiveLogParser.run(EntityGroupFSTimelineStore.java:870)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
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-10355) Refactor NM ContainerLaunch.java#orderEnvByDependencies
[
https://issues.apache.org/jira/browse/YARN-10355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Reti reassigned YARN-10355:
--
Assignee: Tamas Domok
> Refactor NM ContainerLaunch.java#orderEnvByDependencies
> ---
>
> Key: YARN-10355
> URL: https://issues.apache.org/jira/browse/YARN-10355
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: yarn
>Reporter: Benjamin Teke
>Assignee: Tamas Domok
>Priority: Minor
>
> The
> {{org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch#orderEnvByDependencies}}
> and it's helper method \{{getEnvDependencies }}(together with the overrides)
> is hard to read. Some improvements could be made:
> * use Pattern matching in the overrides of getEnvDependencies instead of
> iterating through the environmental variable strings char by char
> * the unit tests contains a lot of repeated code and generally the test
> methods are long - they could be separated into different setup/helper and
> assertion methods
--
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-10580) Fix some issues in TestRMWebServicesCapacitySchedDynamicConfig
[
https://issues.apache.org/jira/browse/YARN-10580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379091#comment-17379091
]
Rudolf Reti commented on YARN-10580:
[~akumar] Are you looking into this one, or can we nick it?
> Fix some issues in TestRMWebServicesCapacitySchedDynamicConfig
> --
>
> Key: YARN-10580
> URL: https://issues.apache.org/jira/browse/YARN-10580
> Project: Hadoop YARN
> Issue Type: Improvement
>Reporter: Szilard Nemeth
>Assignee: Ankit Kumar
>Priority: Minor
> Labels: newbie, newbie++
>
> YARN-10512 introduced some changes that could be fixed, [~pbacsko]
> highlighted those issues with this comment.
> Pasting the contents of the comment as a reference
> #1 In TestRMWebServicesCapacitySchedDynamicConfig:
> {noformat}
> config.set(YarnConfiguration.SCHEDULER_CONFIGURATION_STORE_CLASS,
> YarnConfiguration.MEMORY_CONFIGURATION_STORE);
> {noformat}
> This call is repeated multiple times, this could be set somewhere else.
>
> #2 In TestRMWebServicesCapacitySchedDynamicConfig:
> {noformat}
> validateSchedulerInfo(json, "weight", "root.default", "root.test1",
> "root.test2");
> {noformat}
> "root.default", "root.test1" and "root.test2" are the same in all cases, you
> might want to drop them
>
> #3 In TestRMWebServicesCapacitySchedDynamicConfig
> {noformat}
> @Before
> @Override
> public void setUp() throws Exception {
> super.setUp();
> }
> {noformat}
> This method does nothing, can be removed.
--
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-10652) Capacity Scheduler fails to handle user weights for a user that has a "." (dot) in it
[
https://issues.apache.org/jira/browse/YARN-10652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17291563#comment-17291563
]
Rudolf Reti commented on YARN-10652:
[~pbacsko] & [~shuzirra] Can you please check this from a Placement point of
view? Won't the DOT in the username break that as DOT is used as a delimiter
there?
> Capacity Scheduler fails to handle user weights for a user that has a "."
> (dot) in it
> -
>
> Key: YARN-10652
> URL: https://issues.apache.org/jira/browse/YARN-10652
> Project: Hadoop YARN
> Issue Type: Bug
> Components: capacity scheduler
>Affects Versions: 3.3.0
>Reporter: Siddharth Ahuja
>Assignee: Siddharth Ahuja
>Priority: Major
> Attachments: Correct user weight of 0.76 picked up for the user with
> a dot after the patch.png, Incorrect default user weight of 1.0 being picked
> for the user with a dot before the patch.png, YARN-10652.001.patch
>
>
> AD usernames can have a "." (dot) in them i.e. they can be of the format ->
> {{firstname.lastname}}. However, if you specify a username with this format
> against the Capacity Scheduler setting ->
> {{yarn.scheduler.capacity.root.default.user-settings.firstname.lastname.weight}},
> it fails to be applied and is instead assigned the default of 1.0f weight.
> This renders the user weight feature (being used as a means of setting user
> priorities for a queue) unusable for such users.
> This limitation comes from [1]. From [1], only word characters (A word
> character: [a-zA-Z_0-9]) (see [2]) are permissible at the moment which is no
> good for AD names that contain a "." (dot).
> Similar discussion has been had in a few HADOOP jiras e.g. HADOOP-7050 and
> HADOOP-15395 and the outcome was to use non-whitespace characters i.e.
> instead of {{\w+}}, use {{\S+}}.
> We could go down similar path and unblock this feature for the AD usernames
> with a "." (dot) in them.
> [1]
> https://github.com/apache/hadoop/blob/trunk/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/CapacitySchedulerConfiguration.java#L1953
> [2]
> https://docs.oracle.com/javase/tutorial/essential/regex/pre_char_classes.html
--
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-10575) Hadoop
[ https://issues.apache.org/jira/browse/YARN-10575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267088#comment-17267088 ] Rudolf Reti commented on YARN-10575: 42 > Hadoop > -- > > Key: YARN-10575 > URL: https://issues.apache.org/jira/browse/YARN-10575 > Project: Hadoop YARN > Issue Type: Bug >Reporter: Pushpalatha S K >Priority: Major > -- 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-7200) SLS generates a realtimetrack.json file but that file is missing the closing ']'
[
https://issues.apache.org/jira/browse/YARN-7200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213278#comment-17213278
]
Rudolf Reti commented on YARN-7200:
---
Thanks [~akshink]. Good first step. Let's jump on the thorough test next.
> SLS generates a realtimetrack.json file but that file is missing the closing
> ']'
>
>
> Key: YARN-7200
> URL: https://issues.apache.org/jira/browse/YARN-7200
> Project: Hadoop YARN
> Issue Type: Bug
> Components: scheduler-load-simulator
>Reporter: Grant Sohn
>Assignee: Agshin Kazimli
>Priority: Minor
> Labels: newbie, newbie++
> Attachments: realtimetrack.json
>
>
> File
> hadoop-tools/hadoop-sls/src/main/java/org/apache/hadoop/yarn/sls/scheduler/SchedulerMetrics.java
> shows:
> {noformat}
> void tearDown() throws Exception {
> if (metricsLogBW != null) {
> metricsLogBW.write("]");
> metricsLogBW.close();
> }
>
> {noformat}
> So the exit logic is flawed.
--
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
