[jira] [Assigned] (YARN-8701) If the single parameter in Resources#createResourceWithSameValue is greater than Integer.MAX_VALUE, then the value of vcores will be -1
[
https://issues.apache.org/jira/browse/YARN-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sen Zhao reassigned YARN-8701:
--
Assignee: Sen Zhao
Attachment: YARN-8701.001.patch
> If the single parameter in Resources#createResourceWithSameValue is greater
> than Integer.MAX_VALUE, then the value of vcores will be -1
> ---
>
> Key: YARN-8701
> URL: https://issues.apache.org/jira/browse/YARN-8701
> Project: Hadoop YARN
> Issue Type: Bug
> Components: api
>Reporter: Sen Zhao
>Assignee: Sen Zhao
>Priority: Major
> Attachments: YARN-8701.001.patch
>
>
> If I configure *MaxResources* in fair-scheduler.xml, like this:
> {code}resource1=50{code}
> In the queue, the *MaxResources* value will change to
> {code}memory:CLUSTER_MEMORY, VCores:0,
> resource1:50{code}
> I think the value of VCores should be *CLUSTER_VCORES*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-8701) If the single parameter in Resources#createResourceWithSameValue is greater than Integer.MAX_VALUE, then the value of vcores will be -1
[
https://issues.apache.org/jira/browse/YARN-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sen Zhao updated YARN-8701:
---
Description:
If I configure *MaxResources* in fair-scheduler.xml, like this:
{code}resource1=50{code}
In the queue, the *MaxResources* value will change to
{code}Max Resources: {code}
I think the value of VCores should be *CLUSTER_VCORES*.
was:
If I configure *MaxResources* in fair-scheduler.xml, like this:
{code}resource1=50{code}
In the queue, the *MaxResources* value will change to
{code}memory:CLUSTER_MEMORY, VCores:0,
resource1:50{code}
I think the value of VCores should be *CLUSTER_VCORES*.
> If the single parameter in Resources#createResourceWithSameValue is greater
> than Integer.MAX_VALUE, then the value of vcores will be -1
> ---
>
> Key: YARN-8701
> URL: https://issues.apache.org/jira/browse/YARN-8701
> Project: Hadoop YARN
> Issue Type: Bug
> Components: api
>Reporter: Sen Zhao
>Assignee: Sen Zhao
>Priority: Major
> Attachments: YARN-8701.001.patch
>
>
> If I configure *MaxResources* in fair-scheduler.xml, like this:
> {code}resource1=50{code}
> In the queue, the *MaxResources* value will change to
> {code}Max Resources: {code}
> I think the value of VCores should be *CLUSTER_VCORES*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8701) If the single parameter in Resources#createResourceWithSameValue is greater than Integer.MAX_VALUE, then the value of vcores will be -1
[
https://issues.apache.org/jira/browse/YARN-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589909#comment-16589909
]
Sen Zhao commented on YARN-8701:
Hi, [~leftnoteasy],[~snemeth], could you give me some advice about this?
> If the single parameter in Resources#createResourceWithSameValue is greater
> than Integer.MAX_VALUE, then the value of vcores will be -1
> ---
>
> Key: YARN-8701
> URL: https://issues.apache.org/jira/browse/YARN-8701
> Project: Hadoop YARN
> Issue Type: Bug
> Components: api
>Reporter: Sen Zhao
>Assignee: Sen Zhao
>Priority: Major
> Attachments: YARN-8701.001.patch
>
>
> If I configure *MaxResources* in fair-scheduler.xml, like this:
> {code}resource1=50{code}
> In the queue, the *MaxResources* value will change to
> {code}Max Resources: {code}
> I think the value of VCores should be *CLUSTER_VCORES*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Created] (YARN-8738) FairScheduler configures maxResources or minReosurces as negative, the value parse to a positive number.
Sen Zhao created YARN-8738: -- Summary: FairScheduler configures maxResources or minReosurces as negative, the value parse to a positive number. Key: YARN-8738 URL: https://issues.apache.org/jira/browse/YARN-8738 Project: Hadoop YARN Issue Type: Bug Components: fairscheduler Affects Versions: 3.2.0 Reporter: Sen Zhao If maxResources or minResources is configured as a negative number, the value will be positive after parsing. If this is a problem, I will fix it. If not, the FairSchedulerConfiguration#parseNewStyleResource also have some problem. cc:[~templedf], [~leftnoteasy] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-8738) FairScheduler configures maxResources or minReosurces as negative, the value parse to a positive number.
[ https://issues.apache.org/jira/browse/YARN-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-8738: --- Description: If maxResources or minResources is configured as a negative number, the value will be positive after parsing. If this is a problem, I will fix it. If not, the FairSchedulerConfiguration#parseNewStyleResource parse negative number should be same with parseOldStyleResource . cc:[~templedf], [~leftnoteasy] was: If maxResources or minResources is configured as a negative number, the value will be positive after parsing. If this is a problem, I will fix it. If not, the FairSchedulerConfiguration#parseNewStyleResource also have some problem. cc:[~templedf], [~leftnoteasy] > FairScheduler configures maxResources or minReosurces as negative, the value > parse to a positive number. > > > Key: YARN-8738 > URL: https://issues.apache.org/jira/browse/YARN-8738 > Project: Hadoop YARN > Issue Type: Bug > Components: fairscheduler >Affects Versions: 3.2.0 >Reporter: Sen Zhao >Priority: Major > > If maxResources or minResources is configured as a negative number, the value > will be positive after parsing. > If this is a problem, I will fix it. If not, the > FairSchedulerConfiguration#parseNewStyleResource parse negative number should > be same with parseOldStyleResource . > cc:[~templedf], [~leftnoteasy] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-8024) LOG in class MaxRunningAppsEnforcer is initialized with a faulty class FairScheduler
[ https://issues.apache.org/jira/browse/YARN-8024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-8024: --- Attachment: YARN-8024.001.patch > LOG in class MaxRunningAppsEnforcer is initialized with a faulty class > FairScheduler > - > > Key: YARN-8024 > URL: https://issues.apache.org/jira/browse/YARN-8024 > Project: Hadoop YARN > Issue Type: Bug > Components: fairscheduler >Reporter: Yufei Gu >Priority: Major > Labels: newbie++ > Attachments: YARN-8024.001.patch > > > It should be initialized with class MaxRunningAppsEnforcer. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8024) LOG in class MaxRunningAppsEnforcer is initialized with a faulty class FairScheduler
[ https://issues.apache.org/jira/browse/YARN-8024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395443#comment-16395443 ] Sen Zhao commented on YARN-8024: I just submitted a patch. Please review it. Thanks, [~yufeigu] > LOG in class MaxRunningAppsEnforcer is initialized with a faulty class > FairScheduler > - > > Key: YARN-8024 > URL: https://issues.apache.org/jira/browse/YARN-8024 > Project: Hadoop YARN > Issue Type: Bug > Components: fairscheduler >Reporter: Yufei Gu >Assignee: Sen Zhao >Priority: Major > Labels: newbie++ > Attachments: YARN-8024.001.patch > > > It should be initialized with class MaxRunningAppsEnforcer. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-7966) Remove AllocationConfiguration#getQueueAcl and related unit test
[ https://issues.apache.org/jira/browse/YARN-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-7966: --- Attachment: YARN-7966.001.patch > Remove AllocationConfiguration#getQueueAcl and related unit test > > > Key: YARN-7966 > URL: https://issues.apache.org/jira/browse/YARN-7966 > Project: Hadoop YARN > Issue Type: Improvement > Components: fairscheduler >Affects Versions: 3.1.0 >Reporter: Yufei Gu >Priority: Minor > Labels: newbie++ > Attachments: YARN-7966.001.patch > > > AllocationConfiguration#getQueueAcl isn't needed any more after YARN-4997. We > should remove it and its related unit test. All its logic is reimplemented in > AllocationFileLoaderService#getDefaultPermissions. class > AllocationConfiguration doesn't have any API annotation, it is considered as > private. So it is OK to remove its public method. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7966) Remove AllocationConfiguration#getQueueAcl and related unit test
[ https://issues.apache.org/jira/browse/YARN-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16440395#comment-16440395 ] Sen Zhao commented on YARN-7966: I just submit a patch. Please review it. Thanks, [~yufeigu]. > Remove AllocationConfiguration#getQueueAcl and related unit test > > > Key: YARN-7966 > URL: https://issues.apache.org/jira/browse/YARN-7966 > Project: Hadoop YARN > Issue Type: Improvement > Components: fairscheduler >Affects Versions: 3.1.0 >Reporter: Yufei Gu >Assignee: Sen Zhao >Priority: Minor > Labels: newbie++ > Attachments: YARN-7966.001.patch > > > AllocationConfiguration#getQueueAcl isn't needed any more after YARN-4997. We > should remove it and its related unit test. All its logic is reimplemented in > AllocationFileLoaderService#getDefaultPermissions. class > AllocationConfiguration doesn't have any API annotation, it is considered as > private. So it is OK to remove its public method. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7966) Remove method AllocationConfiguration#getQueueAcl and related unit tests
[ https://issues.apache.org/jira/browse/YARN-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441941#comment-16441941 ] Sen Zhao commented on YARN-7966: Thanks [~yufeigu] for review. > Remove method AllocationConfiguration#getQueueAcl and related unit tests > > > Key: YARN-7966 > URL: https://issues.apache.org/jira/browse/YARN-7966 > Project: Hadoop YARN > Issue Type: Improvement > Components: fairscheduler >Affects Versions: 3.1.0 >Reporter: Yufei Gu >Assignee: Sen Zhao >Priority: Minor > Labels: newbie++ > Fix For: 3.2.0 > > Attachments: YARN-7966.001.patch, YARN-7966.002.patch > > > AllocationConfiguration#getQueueAcl isn't needed any more after YARN-4997. We > should remove it and its related unit test. All its logic is reimplemented in > AllocationFileLoaderService#getDefaultPermissions. class > AllocationConfiguration doesn't have any API annotation, it is considered as > private. So it is OK to remove its public method. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Assigned] (YARN-7966) Remove AllocationConfiguration#getQueueAcl and related unit test
[ https://issues.apache.org/jira/browse/YARN-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao reassigned YARN-7966: -- Assignee: Sen Zhao > Remove AllocationConfiguration#getQueueAcl and related unit test > > > Key: YARN-7966 > URL: https://issues.apache.org/jira/browse/YARN-7966 > Project: Hadoop YARN > Issue Type: Improvement > Components: fairscheduler >Affects Versions: 3.1.0 >Reporter: Yufei Gu >Assignee: Sen Zhao >Priority: Minor > Labels: newbie++ > Attachments: YARN-7966.001.patch > > > AllocationConfiguration#getQueueAcl isn't needed any more after YARN-4997. We > should remove it and its related unit test. All its logic is reimplemented in > AllocationFileLoaderService#getDefaultPermissions. class > AllocationConfiguration doesn't have any API annotation, it is considered as > private. So it is OK to remove its public method. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-7966) Remove AllocationConfiguration#getQueueAcl and related unit test
[ https://issues.apache.org/jira/browse/YARN-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-7966: --- Attachment: YARN-7966.002.patch > Remove AllocationConfiguration#getQueueAcl and related unit test > > > Key: YARN-7966 > URL: https://issues.apache.org/jira/browse/YARN-7966 > Project: Hadoop YARN > Issue Type: Improvement > Components: fairscheduler >Affects Versions: 3.1.0 >Reporter: Yufei Gu >Assignee: Sen Zhao >Priority: Minor > Labels: newbie++ > Attachments: YARN-7966.001.patch, YARN-7966.002.patch > > > AllocationConfiguration#getQueueAcl isn't needed any more after YARN-4997. We > should remove it and its related unit test. All its logic is reimplemented in > AllocationFileLoaderService#getDefaultPermissions. class > AllocationConfiguration doesn't have any API annotation, it is considered as > private. So it is OK to remove its public method. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7966) Remove AllocationConfiguration#getQueueAcl and related unit test
[ https://issues.apache.org/jira/browse/YARN-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441783#comment-16441783 ] Sen Zhao commented on YARN-7966: Submit patch 002 to remove unused imports. > Remove AllocationConfiguration#getQueueAcl and related unit test > > > Key: YARN-7966 > URL: https://issues.apache.org/jira/browse/YARN-7966 > Project: Hadoop YARN > Issue Type: Improvement > Components: fairscheduler >Affects Versions: 3.1.0 >Reporter: Yufei Gu >Assignee: Sen Zhao >Priority: Minor > Labels: newbie++ > Attachments: YARN-7966.001.patch, YARN-7966.002.patch > > > AllocationConfiguration#getQueueAcl isn't needed any more after YARN-4997. We > should remove it and its related unit test. All its logic is reimplemented in > AllocationFileLoaderService#getDefaultPermissions. class > AllocationConfiguration doesn't have any API annotation, it is considered as > private. So it is OK to remove its public method. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-8077) The vmemLimit parameter in ContainersMonitorImpl#isProcessTreeOverLimit is confusing
[ https://issues.apache.org/jira/browse/YARN-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-8077: --- Description: The parameter should be memLimit. It contains the meaning of vmemLimit and pmemLimit. was:Tht parameter should be memLimit. It contais the meaning of vmemLimit adn pmemLimit. > The vmemLimit parameter in ContainersMonitorImpl#isProcessTreeOverLimit is > confusing > > > Key: YARN-8077 > URL: https://issues.apache.org/jira/browse/YARN-8077 > Project: Hadoop YARN > Issue Type: Improvement > Components: nodemanager >Affects Versions: 3.0.0 >Reporter: Sen Zhao >Assignee: Sen Zhao >Priority: Trivial > Attachments: YARN-8077.001.patch > > > The parameter should be memLimit. It contains the meaning of vmemLimit and > pmemLimit. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Created] (YARN-8077) The vmemLimit parameter in ContainersMonitorImpl#isProcessTreeOverLimit is confusing
Sen Zhao created YARN-8077: -- Summary: The vmemLimit parameter in ContainersMonitorImpl#isProcessTreeOverLimit is confusing Key: YARN-8077 URL: https://issues.apache.org/jira/browse/YARN-8077 Project: Hadoop YARN Issue Type: Improvement Components: nodemanager Affects Versions: 3.0.0 Reporter: Sen Zhao Assignee: Sen Zhao Tht parameter should be memLimit. It contais the meaning of vmemLimit adn pmemLimit. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-8077) The vmemLimit parameter in ContainersMonitorImpl#isProcessTreeOverLimit is confusing
[ https://issues.apache.org/jira/browse/YARN-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-8077: --- Attachment: YARN-8077.001.patch > The vmemLimit parameter in ContainersMonitorImpl#isProcessTreeOverLimit is > confusing > > > Key: YARN-8077 > URL: https://issues.apache.org/jira/browse/YARN-8077 > Project: Hadoop YARN > Issue Type: Improvement > Components: nodemanager >Affects Versions: 3.0.0 >Reporter: Sen Zhao >Assignee: Sen Zhao >Priority: Trivial > Attachments: YARN-8077.001.patch > > > Tht parameter should be memLimit. It contais the meaning of vmemLimit adn > pmemLimit. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8077) The vmemLimit parameter in ContainersMonitorImpl#isProcessTreeOverLimit is confusing
[ https://issues.apache.org/jira/browse/YARN-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416547#comment-16416547 ] Sen Zhao commented on YARN-8077: Thanks for your review. [~miklos.szeg...@cloudera.com] > The vmemLimit parameter in ContainersMonitorImpl#isProcessTreeOverLimit is > confusing > > > Key: YARN-8077 > URL: https://issues.apache.org/jira/browse/YARN-8077 > Project: Hadoop YARN > Issue Type: Improvement > Components: nodemanager >Affects Versions: 3.0.0 >Reporter: Sen Zhao >Assignee: Sen Zhao >Priority: Trivial > Attachments: YARN-8077.001.patch > > > The parameter should be memLimit. It contains the meaning of vmemLimit and > pmemLimit. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-7736) Fix itemization in YARN federation document
[
https://issues.apache.org/jira/browse/YARN-7736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sen Zhao updated YARN-7736:
---
Attachment: YARN-7736.001.patch
> Fix itemization in YARN federation document
> ---
>
> Key: YARN-7736
> URL: https://issues.apache.org/jira/browse/YARN-7736
> Project: Hadoop YARN
> Issue Type: Bug
> Components: documentation
>Reporter: Akira Ajisaka
>Priority: Minor
> Labels: newbie
> Attachments: YARN-7736.001.patch
>
>
> https://hadoop.apache.org/docs/r3.0.0/hadoop-yarn/hadoop-yarn-site/Federation.html
> {noformat}
> Assumptions:
> * We assume reasonably good connectivity across sub-clusters (e.g., we are
> not looking to federate across DC yet, though future investigations of this
> are not excluded).
> * We rely on HDFS federation (or equivalently scalable DFS solutions) to take
> care of scalability of the store side.
> {noformat}
> Blank line should be inserted before itemization to render correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Assigned] (YARN-7995) Remove unnecessary boxings and unboxings from PlacementConstraintParser.java
[
https://issues.apache.org/jira/browse/YARN-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sen Zhao reassigned YARN-7995:
--
Assignee: Sen Zhao
> Remove unnecessary boxings and unboxings from PlacementConstraintParser.java
>
>
> Key: YARN-7995
> URL: https://issues.apache.org/jira/browse/YARN-7995
> Project: Hadoop YARN
> Issue Type: Bug
>Reporter: Akira Ajisaka
>Assignee: Sen Zhao
>Priority: Minor
> Labels: newbie
> Attachments: YARN-7995.001.patch
>
>
> {code}
> String maxCardinalityStr = resetElements.pop();
> Integer max = toInt(maxCardinalityStr);
> String minCardinalityStr = resetElements.pop();
> Integer min = toInt(minCardinalityStr);
> {code}
> {{toInt(String)}} does not return null, so {{Integer}} should be replaced
> with {{int}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-7995) Remove unnecessary boxings and unboxings from PlacementConstraintParser.java
[
https://issues.apache.org/jira/browse/YARN-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sen Zhao updated YARN-7995:
---
Attachment: YARN-7995.001.patch
> Remove unnecessary boxings and unboxings from PlacementConstraintParser.java
>
>
> Key: YARN-7995
> URL: https://issues.apache.org/jira/browse/YARN-7995
> Project: Hadoop YARN
> Issue Type: Bug
>Reporter: Akira Ajisaka
>Priority: Minor
> Labels: newbie
> Attachments: YARN-7995.001.patch
>
>
> {code}
> String maxCardinalityStr = resetElements.pop();
> Integer max = toInt(maxCardinalityStr);
> String minCardinalityStr = resetElements.pop();
> Integer min = toInt(minCardinalityStr);
> {code}
> {{toInt(String)}} does not return null, so {{Integer}} should be replaced
> with {{int}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Assigned] (YARN-7736) Fix itemization in YARN federation document
[
https://issues.apache.org/jira/browse/YARN-7736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sen Zhao reassigned YARN-7736:
--
Assignee: Sen Zhao
> Fix itemization in YARN federation document
> ---
>
> Key: YARN-7736
> URL: https://issues.apache.org/jira/browse/YARN-7736
> Project: Hadoop YARN
> Issue Type: Bug
> Components: documentation
>Reporter: Akira Ajisaka
>Assignee: Sen Zhao
>Priority: Minor
> Labels: newbie
> Attachments: YARN-7736.001.patch
>
>
> https://hadoop.apache.org/docs/r3.0.0/hadoop-yarn/hadoop-yarn-site/Federation.html
> {noformat}
> Assumptions:
> * We assume reasonably good connectivity across sub-clusters (e.g., we are
> not looking to federate across DC yet, though future investigations of this
> are not excluded).
> * We rely on HDFS federation (or equivalently scalable DFS solutions) to take
> care of scalability of the store side.
> {noformat}
> Blank line should be inserted before itemization to render correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7736) Fix itemization in YARN federation document
[
https://issues.apache.org/jira/browse/YARN-7736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385508#comment-16385508
]
Sen Zhao commented on YARN-7736:
Thanks for your reproting this. I just submitted a patch. Please review it.
[~ajisakaa]
> Fix itemization in YARN federation document
> ---
>
> Key: YARN-7736
> URL: https://issues.apache.org/jira/browse/YARN-7736
> Project: Hadoop YARN
> Issue Type: Bug
> Components: documentation
>Reporter: Akira Ajisaka
>Assignee: Sen Zhao
>Priority: Minor
> Labels: newbie
> Attachments: YARN-7736.001.patch
>
>
> https://hadoop.apache.org/docs/r3.0.0/hadoop-yarn/hadoop-yarn-site/Federation.html
> {noformat}
> Assumptions:
> * We assume reasonably good connectivity across sub-clusters (e.g., we are
> not looking to federate across DC yet, though future investigations of this
> are not excluded).
> * We rely on HDFS federation (or equivalently scalable DFS solutions) to take
> care of scalability of the store side.
> {noformat}
> Blank line should be inserted before itemization to render correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7995) Remove unnecessary boxings and unboxings from PlacementConstraintParser.java
[
https://issues.apache.org/jira/browse/YARN-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385470#comment-16385470
]
Sen Zhao commented on YARN-7995:
Please review it. Thanks![~ajisakaa]
> Remove unnecessary boxings and unboxings from PlacementConstraintParser.java
>
>
> Key: YARN-7995
> URL: https://issues.apache.org/jira/browse/YARN-7995
> Project: Hadoop YARN
> Issue Type: Bug
>Reporter: Akira Ajisaka
>Assignee: Sen Zhao
>Priority: Minor
> Labels: newbie
> Attachments: YARN-7995.001.patch
>
>
> {code}
> String maxCardinalityStr = resetElements.pop();
> Integer max = toInt(maxCardinalityStr);
> String minCardinalityStr = resetElements.pop();
> Integer min = toInt(minCardinalityStr);
> {code}
> {{toInt(String)}} does not return null, so {{Integer}} should be replaced
> with {{int}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8701) If the single parameter in Resources#createResourceWithSameValue is greater than Integer.MAX_VALUE, then the value of vcores will be -1
[
https://issues.apache.org/jira/browse/YARN-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676637#comment-16676637
]
Sen Zhao commented on YARN-8701:
Submit patch 002 to fix this. Thanks, [~snemeth]
> If the single parameter in Resources#createResourceWithSameValue is greater
> than Integer.MAX_VALUE, then the value of vcores will be -1
> ---
>
> Key: YARN-8701
> URL: https://issues.apache.org/jira/browse/YARN-8701
> Project: Hadoop YARN
> Issue Type: Bug
> Components: api
>Reporter: Sen Zhao
>Assignee: Sen Zhao
>Priority: Major
> Attachments: YARN-8701.001.patch, YARN-8701.002.patch
>
>
> If I configure *MaxResources* in fair-scheduler.xml, like this:
> {code}resource1=50{code}
> In the queue, the *MaxResources* value will change to
> {code}Max Resources: {code}
> I think the value of VCores should be *CLUSTER_VCORES*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-8701) If the single parameter in Resources#createResourceWithSameValue is greater than Integer.MAX_VALUE, then the value of vcores will be -1
[
https://issues.apache.org/jira/browse/YARN-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sen Zhao updated YARN-8701:
---
Attachment: YARN-8701.002.patch
> If the single parameter in Resources#createResourceWithSameValue is greater
> than Integer.MAX_VALUE, then the value of vcores will be -1
> ---
>
> Key: YARN-8701
> URL: https://issues.apache.org/jira/browse/YARN-8701
> Project: Hadoop YARN
> Issue Type: Bug
> Components: api
>Reporter: Sen Zhao
>Assignee: Sen Zhao
>Priority: Major
> Attachments: YARN-8701.001.patch, YARN-8701.002.patch
>
>
> If I configure *MaxResources* in fair-scheduler.xml, like this:
> {code}resource1=50{code}
> In the queue, the *MaxResources* value will change to
> {code}Max Resources: {code}
> I think the value of VCores should be *CLUSTER_VCORES*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8738) FairScheduler configures maxResources or minResources as negative, the value parse to a positive number.
[ https://issues.apache.org/jira/browse/YARN-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674580#comment-16674580 ] Sen Zhao commented on YARN-8738: [~snemeth]. Of course, you can do this. > FairScheduler configures maxResources or minResources as negative, the value > parse to a positive number. > > > Key: YARN-8738 > URL: https://issues.apache.org/jira/browse/YARN-8738 > Project: Hadoop YARN > Issue Type: Bug > Components: fairscheduler >Affects Versions: 3.2.0 >Reporter: Sen Zhao >Assignee: Szilard Nemeth >Priority: Major > > If maxResources or minResources is configured as a negative number, the value > will be positive after parsing. > If this is a problem, I will fix it. If not, the > FairSchedulerConfiguration#parseNewStyleResource parse negative number should > be same with parseOldStyleResource . > cc:[~templedf], [~leftnoteasy] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Created] (YARN-9216) The user and queue link address in the Timeline Server webapp are unknown
Sen Zhao created YARN-9216: -- Summary: The user and queue link address in the Timeline Server webapp are unknown Key: YARN-9216 URL: https://issues.apache.org/jira/browse/YARN-9216 Project: Hadoop YARN Issue Type: Bug Components: timelineserver, webapp Reporter: Sen Zhao Precondition: 1. ResourceManager HA is enable; 2. ResourceManager and Timeline Server are not on the same node. Appearance: The link address of the user and queue will return an unknown jump address. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9216) The user and queue link address in the Timeline Server webapp are unknown
[ https://issues.apache.org/jira/browse/YARN-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-9216: --- Attachment: screenshot-1.png > The user and queue link address in the Timeline Server webapp are unknown > - > > Key: YARN-9216 > URL: https://issues.apache.org/jira/browse/YARN-9216 > Project: Hadoop YARN > Issue Type: Bug > Components: timelineserver, webapp >Reporter: Sen Zhao >Priority: Major > Attachments: screenshot-1.png > > > Precondition: > 1. ResourceManager HA is enable; > 2. ResourceManager and Timeline Server are not on the same node. > Appearance: > The link address of the user and queue will return an unknown jump address. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9216) The user and queue link address in the Timeline Server webapp are unknown
[ https://issues.apache.org/jira/browse/YARN-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-9216: --- Description: Precondition: 1. ResourceManager HA is enable; 2. ResourceManager and Timeline Server are not on the same node. Appearance: The link address of the user and queue will return an unknown jump address. see was: Precondition: 1. ResourceManager HA is enable; 2. ResourceManager and Timeline Server are not on the same node. Appearance: The link address of the user and queue will return an unknown jump address. > The user and queue link address in the Timeline Server webapp are unknown > - > > Key: YARN-9216 > URL: https://issues.apache.org/jira/browse/YARN-9216 > Project: Hadoop YARN > Issue Type: Bug > Components: timelineserver, webapp >Reporter: Sen Zhao >Priority: Major > Attachments: screenshot-1.png > > > Precondition: > 1. ResourceManager HA is enable; > 2. ResourceManager and Timeline Server are not on the same node. > Appearance: > The link address of the user and queue will return an unknown jump address. > see -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9216) The user and queue link address in the Timeline Server webapp are unknown
[ https://issues.apache.org/jira/browse/YARN-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-9216: --- Description: Precondition: 1. ResourceManager HA is enable; 2. ResourceManager and Timeline Server are not on the same node. Appearance: The link address of the user and queue will return an unknown jump address. see [#screenshot-1.png]. was: Precondition: 1. ResourceManager HA is enable; 2. ResourceManager and Timeline Server are not on the same node. Appearance: The link address of the user and queue will return an unknown jump address. see > The user and queue link address in the Timeline Server webapp are unknown > - > > Key: YARN-9216 > URL: https://issues.apache.org/jira/browse/YARN-9216 > Project: Hadoop YARN > Issue Type: Bug > Components: timelineserver, webapp >Reporter: Sen Zhao >Priority: Major > Attachments: screenshot-1.png > > > Precondition: > 1. ResourceManager HA is enable; > 2. ResourceManager and Timeline Server are not on the same node. > Appearance: > The link address of the user and queue will return an unknown jump address. > see [#screenshot-1.png]. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9216) The user and queue link address in the Timeline Server webapp are unknown
[ https://issues.apache.org/jira/browse/YARN-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-9216: --- Description: Precondition: 1. ResourceManager HA is enable; 2. ResourceManager and Timeline Server are not on the same node. Appearance: The link address of the user and queue will return an unknown jump address. see screenshot-1.png. Reason: If ResourceManager and Timeline Server are not on the same node, the currentRMId will return null. was: Precondition: 1. ResourceManager HA is enable; 2. ResourceManager and Timeline Server are not on the same node. Appearance: The link address of the user and queue will return an unknown jump address. see [#screenshot-1.png]. > The user and queue link address in the Timeline Server webapp are unknown > - > > Key: YARN-9216 > URL: https://issues.apache.org/jira/browse/YARN-9216 > Project: Hadoop YARN > Issue Type: Bug > Components: timelineserver, webapp >Reporter: Sen Zhao >Priority: Major > Attachments: screenshot-1.png > > > Precondition: > 1. ResourceManager HA is enable; > 2. ResourceManager and Timeline Server are not on the same node. > Appearance: > The link address of the user and queue will return an unknown jump address. > see screenshot-1.png. > Reason: > If ResourceManager and Timeline Server are not on the same node, the > currentRMId will return null. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Assigned] (YARN-9216) The user and queue link address in the Timeline Server webapp are unknown
[ https://issues.apache.org/jira/browse/YARN-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao reassigned YARN-9216: -- Assignee: Sen Zhao Attachment: YARN-9216.001.patch I don't think the URL needs to be shown here. > The user and queue link address in the Timeline Server webapp are unknown > - > > Key: YARN-9216 > URL: https://issues.apache.org/jira/browse/YARN-9216 > Project: Hadoop YARN > Issue Type: Bug > Components: timelineserver, webapp >Reporter: Sen Zhao >Assignee: Sen Zhao >Priority: Major > Attachments: YARN-9216.001.patch, screenshot-1.png > > > Precondition: > 1. ResourceManager HA is enable; > 2. ResourceManager and Timeline Server are not on the same node. > Appearance: > The link address of the user and queue will return an unknown jump address. > see screenshot-1.png. > Reason: > If ResourceManager and Timeline Server are not on the same node, the > currentRMId will return null. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8701) If the single parameter in Resources#createResourceWithSameValue is greater than Integer.MAX_VALUE, then the value of vcores will be -1
[
https://issues.apache.org/jira/browse/YARN-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806423#comment-16806423
]
Sen Zhao commented on YARN-8701:
Upload a new patch 003 [~snemeth].
> If the single parameter in Resources#createResourceWithSameValue is greater
> than Integer.MAX_VALUE, then the value of vcores will be -1
> ---
>
> Key: YARN-8701
> URL: https://issues.apache.org/jira/browse/YARN-8701
> Project: Hadoop YARN
> Issue Type: Bug
> Components: api
>Reporter: Sen Zhao
>Assignee: Sen Zhao
>Priority: Major
> Attachments: YARN-8701.001.patch, YARN-8701.002.patch,
> YARN-8701.003.patch
>
>
> If I configure *MaxResources* in fair-scheduler.xml, like this:
> {code}resource1=50{code}
> In the queue, the *MaxResources* value will change to
> {code}Max Resources: {code}
> I think the value of VCores should be *CLUSTER_VCORES*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-8701) If the single parameter in Resources#createResourceWithSameValue is greater than Integer.MAX_VALUE, then the value of vcores will be -1
[
https://issues.apache.org/jira/browse/YARN-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sen Zhao updated YARN-8701:
---
Attachment: YARN-8701.003.patch
> If the single parameter in Resources#createResourceWithSameValue is greater
> than Integer.MAX_VALUE, then the value of vcores will be -1
> ---
>
> Key: YARN-8701
> URL: https://issues.apache.org/jira/browse/YARN-8701
> Project: Hadoop YARN
> Issue Type: Bug
> Components: api
>Reporter: Sen Zhao
>Assignee: Sen Zhao
>Priority: Major
> Attachments: YARN-8701.001.patch, YARN-8701.002.patch,
> YARN-8701.003.patch
>
>
> If I configure *MaxResources* in fair-scheduler.xml, like this:
> {code}resource1=50{code}
> In the queue, the *MaxResources* value will change to
> {code}Max Resources: {code}
> I think the value of VCores should be *CLUSTER_VCORES*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8701) If the single parameter in Resources#createResourceWithSameValue is greater than Integer.MAX_VALUE, then the value of vcores will be -1
[
https://issues.apache.org/jira/browse/YARN-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806489#comment-16806489
]
Sen Zhao commented on YARN-8701:
Patch 004 to fix checkstyle.
> If the single parameter in Resources#createResourceWithSameValue is greater
> than Integer.MAX_VALUE, then the value of vcores will be -1
> ---
>
> Key: YARN-8701
> URL: https://issues.apache.org/jira/browse/YARN-8701
> Project: Hadoop YARN
> Issue Type: Bug
> Components: api
>Reporter: Sen Zhao
>Assignee: Sen Zhao
>Priority: Major
> Attachments: YARN-8701.001.patch, YARN-8701.002.patch,
> YARN-8701.003.patch, YARN-8701.004.patch
>
>
> If I configure *MaxResources* in fair-scheduler.xml, like this:
> {code}resource1=50{code}
> In the queue, the *MaxResources* value will change to
> {code}Max Resources: {code}
> I think the value of VCores should be *CLUSTER_VCORES*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-8701) If the single parameter in Resources#createResourceWithSameValue is greater than Integer.MAX_VALUE, then the value of vcores will be -1
[
https://issues.apache.org/jira/browse/YARN-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sen Zhao updated YARN-8701:
---
Attachment: YARN-8701.004.patch
> If the single parameter in Resources#createResourceWithSameValue is greater
> than Integer.MAX_VALUE, then the value of vcores will be -1
> ---
>
> Key: YARN-8701
> URL: https://issues.apache.org/jira/browse/YARN-8701
> Project: Hadoop YARN
> Issue Type: Bug
> Components: api
>Reporter: Sen Zhao
>Assignee: Sen Zhao
>Priority: Major
> Attachments: YARN-8701.001.patch, YARN-8701.002.patch,
> YARN-8701.003.patch, YARN-8701.004.patch
>
>
> If I configure *MaxResources* in fair-scheduler.xml, like this:
> {code}resource1=50{code}
> In the queue, the *MaxResources* value will change to
> {code}Max Resources: {code}
> I think the value of VCores should be *CLUSTER_VCORES*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8662) Fair Scheduler stops scheduling when a queue is configured only CPU and memory
[
https://issues.apache.org/jira/browse/YARN-8662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779062#comment-16779062
]
Sen Zhao commented on YARN-8662:
HI, [~wilfreds]. If we upgrade a lower version of Hadoop to 3.x, the old
configuration that is used will cause this problem.
I agree with your idea of fix the docs. We should know how to config Fair
Scheduler when we use resource types.
Thanks [~adam.antal] to do this.
> Fair Scheduler stops scheduling when a queue is configured only CPU and memory
> --
>
> Key: YARN-8662
> URL: https://issues.apache.org/jira/browse/YARN-8662
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: fairscheduler
>Reporter: Sen Zhao
>Assignee: Sen Zhao
>Priority: Major
> Attachments: NonResourceToSchedule.png, YARN-8662.001.patch
>
>
> Add a new resource type in resource-types.xml, eg: resource1.
> In Fair scheduler when queue's MaxResources is configured like:
> {code}4096 mb, 4 vcores{code}
> When submit a application which need resource like:
> {code} 1536 mb, 1 vcores, 10 resource1{code}
> The application will be pending. Because there is no resource1 in this queue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-9216) The user and queue link address in the Timeline Server webapp are unknown
[ https://issues.apache.org/jira/browse/YARN-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16750642#comment-16750642 ] Sen Zhao commented on YARN-9216: Patch 002 to fix the new checkstyle. This issue doesn't need testcase. > The user and queue link address in the Timeline Server webapp are unknown > - > > Key: YARN-9216 > URL: https://issues.apache.org/jira/browse/YARN-9216 > Project: Hadoop YARN > Issue Type: Bug > Components: timelineserver, webapp >Reporter: Sen Zhao >Assignee: Sen Zhao >Priority: Major > Attachments: YARN-9216.001.patch, YARN-9216.002.patch, > screenshot-1.png > > > Precondition: > 1. ResourceManager HA is enable; > 2. ResourceManager and Timeline Server are not on the same node. > Appearance: > The link address of the user and queue will return an unknown jump address. > see screenshot-1.png. > Reason: > If ResourceManager and Timeline Server are not on the same node, the > currentRMId will return null. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9216) The user and queue link address in the Timeline Server webapp are unknown
[ https://issues.apache.org/jira/browse/YARN-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-9216: --- Attachment: YARN-9216.002.patch > The user and queue link address in the Timeline Server webapp are unknown > - > > Key: YARN-9216 > URL: https://issues.apache.org/jira/browse/YARN-9216 > Project: Hadoop YARN > Issue Type: Bug > Components: timelineserver, webapp >Reporter: Sen Zhao >Assignee: Sen Zhao >Priority: Major > Attachments: YARN-9216.001.patch, YARN-9216.002.patch, > screenshot-1.png > > > Precondition: > 1. ResourceManager HA is enable; > 2. ResourceManager and Timeline Server are not on the same node. > Appearance: > The link address of the user and queue will return an unknown jump address. > see screenshot-1.png. > Reason: > If ResourceManager and Timeline Server are not on the same node, the > currentRMId will return null. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9216) The user and queue link address in the Timeline Server webapp are unknown
[ https://issues.apache.org/jira/browse/YARN-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-9216: --- Description: Precondition: 1. ResourceManager HA is enable; 2. ResourceManager and Timeline Server are not on the same node. Appearance: The link address of the user and queue will return an unknown jump address. see screenshot-1.png. Reason: If ResourceManager and Timeline Server are not on the same node, the currentRMId will return null. was: Precondition: 1. ResourceManager HA is enable; 2. ResourceManager and Timeline Server are not on the same node. Appearance: The link address of the user and queue will return an unknown jump address. see !screenshot-1.png! . Reason: If ResourceManager and Timeline Server are not on the same node, the currentRMId will return null. > The user and queue link address in the Timeline Server webapp are unknown > - > > Key: YARN-9216 > URL: https://issues.apache.org/jira/browse/YARN-9216 > Project: Hadoop YARN > Issue Type: Bug > Components: timelineserver, webapp >Reporter: Sen Zhao >Assignee: Sen Zhao >Priority: Major > Attachments: YARN-9216.001.patch, YARN-9216.002.patch, > screenshot-1.png > > > Precondition: > 1. ResourceManager HA is enable; > 2. ResourceManager and Timeline Server are not on the same node. > Appearance: > The link address of the user and queue will return an unknown jump address. > see screenshot-1.png. > Reason: > If ResourceManager and Timeline Server are not on the same node, the > currentRMId will return null. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9216) The user and queue link address in the Timeline Server webapp are unknown
[ https://issues.apache.org/jira/browse/YARN-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-9216: --- Description: Precondition: 1. ResourceManager HA is enable; 2. ResourceManager and Timeline Server are not on the same node. Appearance: The link address of the user and queue will return an unknown jump address. see !screenshot-1.png! . Reason: If ResourceManager and Timeline Server are not on the same node, the currentRMId will return null. was: Precondition: 1. ResourceManager HA is enable; 2. ResourceManager and Timeline Server are not on the same node. Appearance: The link address of the user and queue will return an unknown jump address. see screenshot-1.png. Reason: If ResourceManager and Timeline Server are not on the same node, the currentRMId will return null. > The user and queue link address in the Timeline Server webapp are unknown > - > > Key: YARN-9216 > URL: https://issues.apache.org/jira/browse/YARN-9216 > Project: Hadoop YARN > Issue Type: Bug > Components: timelineserver, webapp >Reporter: Sen Zhao >Assignee: Sen Zhao >Priority: Major > Attachments: YARN-9216.001.patch, YARN-9216.002.patch, > screenshot-1.png > > > Precondition: > 1. ResourceManager HA is enable; > 2. ResourceManager and Timeline Server are not on the same node. > Appearance: > The link address of the user and queue will return an unknown jump address. > see !screenshot-1.png! . > Reason: > If ResourceManager and Timeline Server are not on the same node, the > currentRMId will return null. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-10048) NodeManager fails to start after mounting CGroup
[
https://issues.apache.org/jira/browse/YARN-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sen Zhao updated YARN-10048:
Description:
After manually mounting the Cgroup, the NodeManager fails to start.
If the cpu controller has multiple mount path, only the first mount path will
be returned. This will cause the return value to be not the actual cpu
controller mount path.
{code:java}
2019-12-19 14:46:08,200 INFO
org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.CGroupsHandlerImpl:
Mounting controller cpu at /opt/cgroup/cpu
2019-12-19 14:46:08,290 WARN
org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.privileged.PrivilegedOperationExecutor:
Shell execution returned exit code: 32. Privileged Execution Op
eration Stderr:
Feature disabled: mount cgroup
Stdout:
Full command array for failed execution:
[/opt/hadoop-yarn/bin/container-executor, --mount-cgroups,
yarn-NodeManager/hadoop-yarn, cpu,cpuacct=/opt/cgroup/cpu]
2019-12-19 14:46:08,290 ERROR
org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.CGroupsHandlerImpl:
Failed to mount controller: cpu
2019-12-19 14:46:08,291 ERROR
org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor: Failed to
bootstrap configured resource subsystems!
org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.ResourceHandlerException:
Failed to mount controller: cpu
at
org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.CGroupsHandlerImpl.mountCGroupController(CGroupsHandlerImpl.java:318)
at
org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.CGroupsHandlerImpl.initializeCGroupController(CGroupsHandlerImpl.java:365)
at
org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.CGroupsCpuResourceHandlerImpl.bootstrap(CGroupsCpuResourceHandlerImpl.java:98)
at
org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.CGroupsCpuResourceHandlerImpl.bootstrap(CGroupsCpuResourceHandlerImpl.java:87)
at
org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.ResourceHandlerChain.bootstrap(ResourceHandlerChain.java:58)
at
org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor.init(LinuxContainerExecutor.java:325)
at
org.apache.hadoop.yarn.server.nodemanager.NodeManager.serviceInit(NodeManager.java:403)
at
org.apache.hadoop.service.AbstractService.init(AbstractService.java:164)
at
org.apache.hadoop.yarn.server.nodemanager.NodeManager.initAndStartNodeManager(NodeManager.java:962)
at
org.apache.hadoop.yarn.server.nodemanager.NodeManager.main(NodeManager.java:1042)
{code}
was:
After manually mounting the Cgroup, the NodeManager fails to start.
If the cpu controller has multiple mount path, only the first mount path will
be returned. This will cause the return value to be not the actual cpu
controller mount path.
> NodeManager fails to start after mounting CGroup
>
>
> Key: YARN-10048
> URL: https://issues.apache.org/jira/browse/YARN-10048
> Project: Hadoop YARN
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Sen Zhao
>Assignee: Sen Zhao
>Priority: Major
> Attachments: YARN-10048.001.patch, YARN-10048.002.patch
>
>
> After manually mounting the Cgroup, the NodeManager fails to start.
> If the cpu controller has multiple mount path, only the first mount path will
> be returned. This will cause the return value to be not the actual cpu
> controller mount path.
> {code:java}
> 2019-12-19 14:46:08,200 INFO
> org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.CGroupsHandlerImpl:
> Mounting controller cpu at /opt/cgroup/cpu
> 2019-12-19 14:46:08,290 WARN
> org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.privileged.PrivilegedOperationExecutor:
> Shell execution returned exit code: 32. Privileged Execution Op
> eration Stderr:
> Feature disabled: mount cgroup
> Stdout:
> Full command array for failed execution:
> [/opt/hadoop-yarn/bin/container-executor, --mount-cgroups,
> yarn-NodeManager/hadoop-yarn, cpu,cpuacct=/opt/cgroup/cpu]
> 2019-12-19 14:46:08,290 ERROR
> org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.CGroupsHandlerImpl:
> Failed to mount controller: cpu
> 2019-12-19 14:46:08,291 ERROR
> org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor: Failed to
> bootstrap configured resource subsystems!
> org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.ResourceHandlerException:
> Failed to mount controller: cpu
> at
>
[jira] [Updated] (YARN-10048) NodeManager fails to start after mounting CGroup
[ https://issues.apache.org/jira/browse/YARN-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-10048: Issue Type: Bug (was: Improvement) > NodeManager fails to start after mounting CGroup > > > Key: YARN-10048 > URL: https://issues.apache.org/jira/browse/YARN-10048 > Project: Hadoop YARN > Issue Type: Bug >Affects Versions: 3.2.1 >Reporter: Sen Zhao >Assignee: Sen Zhao >Priority: Major > Attachments: YARN-10048.001.patch, YARN-10048.002.patch > > > After manually mounting the Cgroup, the NodeManager fails to start. > If the cpu controller has multiple mount path, only the first mount path will > be returned. This will cause the return value to be not the actual cpu > controller mount path. -- 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-10048) NodeManager fails to start after mounting CGroup
[ https://issues.apache.org/jira/browse/YARN-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-10048: Attachment: YARN-10048.002.patch > NodeManager fails to start after mounting CGroup > > > Key: YARN-10048 > URL: https://issues.apache.org/jira/browse/YARN-10048 > Project: Hadoop YARN > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Sen Zhao >Assignee: Sen Zhao >Priority: Major > Attachments: YARN-10048.001.patch, YARN-10048.002.patch > > > After manually mounting the Cgroup, the NodeManager fails to start. > If the cpu controller has multiple mount path, only the first mount path will > be returned. This will cause the return value to be not the actual cpu > controller mount path. -- 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-10048) NodeManager fails to start after mounting CGroup
[
https://issues.apache.org/jira/browse/YARN-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000626#comment-17000626
]
Sen Zhao commented on YARN-10048:
-
Hi, [~tangzhankun]. Right, if the cpu controller mounts multiple paths, it
will return the first path about parsedMtab.
eg:
{code:java}
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
none on /opt/cgroup/cpu type cgroup (rw,relatime,cpuacct,cpu)
{code}
Sometimes it will return */sys/fs/cgroup/cpu* instead of */opt/cgroup/cpu*
related to the configuration
> NodeManager fails to start after mounting CGroup
>
>
> Key: YARN-10048
> URL: https://issues.apache.org/jira/browse/YARN-10048
> Project: Hadoop YARN
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Sen Zhao
>Assignee: Sen Zhao
>Priority: Major
> Attachments: YARN-10048.001.patch, YARN-10048.002.patch
>
>
> After manually mounting the Cgroup, the NodeManager fails to start.
> If the cpu controller has multiple mount path, only the first mount path will
> be returned. This will cause the return value to be not the actual cpu
> controller mount path.
> {code:java}
> 2019-12-19 14:46:08,200 INFO
> org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.CGroupsHandlerImpl:
> Mounting controller cpu at /opt/cgroup/cpu
> 2019-12-19 14:46:08,290 WARN
> org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.privileged.PrivilegedOperationExecutor:
> Shell execution returned exit code: 32. Privileged Execution Op
> eration Stderr:
> Feature disabled: mount cgroup
> Stdout:
> Full command array for failed execution:
> [/opt/hadoop-yarn/bin/container-executor, --mount-cgroups,
> yarn-NodeManager/hadoop-yarn, cpu,cpuacct=/opt/cgroup/cpu]
> 2019-12-19 14:46:08,290 ERROR
> org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.CGroupsHandlerImpl:
> Failed to mount controller: cpu
> 2019-12-19 14:46:08,291 ERROR
> org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor: Failed to
> bootstrap configured resource subsystems!
> org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.ResourceHandlerException:
> Failed to mount controller: cpu
> at
> org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.CGroupsHandlerImpl.mountCGroupController(CGroupsHandlerImpl.java:318)
> at
> org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.CGroupsHandlerImpl.initializeCGroupController(CGroupsHandlerImpl.java:365)
> at
> org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.CGroupsCpuResourceHandlerImpl.bootstrap(CGroupsCpuResourceHandlerImpl.java:98)
> at
> org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.CGroupsCpuResourceHandlerImpl.bootstrap(CGroupsCpuResourceHandlerImpl.java:87)
> at
> org.apache.hadoop.yarn.server.nodemanager.containermanager.linux.resources.ResourceHandlerChain.bootstrap(ResourceHandlerChain.java:58)
> at
> org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor.init(LinuxContainerExecutor.java:325)
> at
> org.apache.hadoop.yarn.server.nodemanager.NodeManager.serviceInit(NodeManager.java:403)
> at
> org.apache.hadoop.service.AbstractService.init(AbstractService.java:164)
> at
> org.apache.hadoop.yarn.server.nodemanager.NodeManager.initAndStartNodeManager(NodeManager.java:962)
> at
> org.apache.hadoop.yarn.server.nodemanager.NodeManager.main(NodeManager.java:1042)
> {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] [Created] (YARN-10048) 挂载CGroup之后NodeManager启动失败
Sen Zhao created YARN-10048: --- Summary: 挂载CGroup之后NodeManager启动失败 Key: YARN-10048 URL: https://issues.apache.org/jira/browse/YARN-10048 Project: Hadoop YARN Issue Type: Improvement Affects Versions: 3.2.1 Reporter: Sen Zhao After manually mounting the Cgroup, the NodeManager fails to start. If the cpu controller has multiple mount path, only the first mount path will be returned. This will cause the return value to be not the actual cpu controller mount path. -- 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-10048) NodeManager fails to start after mounting CGroup
[ https://issues.apache.org/jira/browse/YARN-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-10048: Attachment: YARN-10048.001.patch Summary: NodeManager fails to start after mounting CGroup (was: 挂载CGroup之后NodeManager启动失败) > NodeManager fails to start after mounting CGroup > > > Key: YARN-10048 > URL: https://issues.apache.org/jira/browse/YARN-10048 > Project: Hadoop YARN > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Sen Zhao >Priority: Major > Attachments: YARN-10048.001.patch > > > After manually mounting the Cgroup, the NodeManager fails to start. > If the cpu controller has multiple mount path, only the first mount path will > be returned. This will cause the return value to be not the actual cpu > controller mount path. -- 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-10048) NodeManager fails to start after mounting CGroup
[ https://issues.apache.org/jira/browse/YARN-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao reassigned YARN-10048: --- Assignee: Sen Zhao > NodeManager fails to start after mounting CGroup > > > Key: YARN-10048 > URL: https://issues.apache.org/jira/browse/YARN-10048 > Project: Hadoop YARN > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Sen Zhao >Assignee: Sen Zhao >Priority: Major > Attachments: YARN-10048.001.patch > > > After manually mounting the Cgroup, the NodeManager fails to start. > If the cpu controller has multiple mount path, only the first mount path will > be returned. This will cause the return value to be not the actual cpu > controller mount path. -- 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-10213) Using curator-leader-elector, rm will always be in standby state at some times.
[ https://issues.apache.org/jira/browse/YARN-10213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17069343#comment-17069343 ] Sen Zhao commented on YARN-10213: - We should call *CuratorBasedElectorService.initAndStartLeaderLatch()* after rm transitions to standby. > Using curator-leader-elector, rm will always be in standby state at some > times. > --- > > Key: YARN-10213 > URL: https://issues.apache.org/jira/browse/YARN-10213 > Project: Hadoop YARN > Issue Type: Bug >Affects Versions: 3.2.1, 3.1.3 >Reporter: Sen Zhao >Priority: Major > > When we use cursor-leader-elector, > *CuratorBasedElectorService.initAndStartLeaderLatch()* > will initialize and start *leaderLatch* to elect the leader. > Now： > 1.ResourceManager will call > *CuratorBasedElectorService.initAndStartLeaderLatch()* in *serviceInit()*. > 2.ResourceManager will transition to standby in *serviceStart()*. > If *leaderLatch* succeeds in electing leader before rm transitions to > standby. ResourceManager will always be in standby state. -- 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-10213) Using curator-leader-elector, rm will always be in standby state at some times.
[ https://issues.apache.org/jira/browse/YARN-10213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao reassigned YARN-10213: --- Assignee: Sen Zhao > Using curator-leader-elector, rm will always be in standby state at some > times. > --- > > Key: YARN-10213 > URL: https://issues.apache.org/jira/browse/YARN-10213 > Project: Hadoop YARN > Issue Type: Bug >Affects Versions: 3.2.1, 3.1.3 >Reporter: Sen Zhao >Assignee: Sen Zhao >Priority: Major > Attachments: YARN-10213.001.patch > > > When we use cursor-leader-elector, > *CuratorBasedElectorService.initAndStartLeaderLatch()* > will initialize and start *leaderLatch* to elect the leader. > Now： > 1.ResourceManager will call > *CuratorBasedElectorService.initAndStartLeaderLatch()* in *serviceInit()*. > 2.ResourceManager will transition to standby in *serviceStart()*. > If *leaderLatch* succeeds in electing leader before rm transitions to > standby. ResourceManager will always be in standby state. -- 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-10213) Using curator-leader-elector, rm will always be in standby state at some times.
[ https://issues.apache.org/jira/browse/YARN-10213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-10213: Attachment: YARN-10213.001.patch > Using curator-leader-elector, rm will always be in standby state at some > times. > --- > > Key: YARN-10213 > URL: https://issues.apache.org/jira/browse/YARN-10213 > Project: Hadoop YARN > Issue Type: Bug >Affects Versions: 3.2.1, 3.1.3 >Reporter: Sen Zhao >Priority: Major > Attachments: YARN-10213.001.patch > > > When we use cursor-leader-elector, > *CuratorBasedElectorService.initAndStartLeaderLatch()* > will initialize and start *leaderLatch* to elect the leader. > Now： > 1.ResourceManager will call > *CuratorBasedElectorService.initAndStartLeaderLatch()* in *serviceInit()*. > 2.ResourceManager will transition to standby in *serviceStart()*. > If *leaderLatch* succeeds in electing leader before rm transitions to > standby. ResourceManager will always be in standby state. -- 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-10213) Using curator-leader-elector, rm will always be in standby state at some times.
Sen Zhao created YARN-10213: --- Summary: Using curator-leader-elector, rm will always be in standby state at some times. Key: YARN-10213 URL: https://issues.apache.org/jira/browse/YARN-10213 Project: Hadoop YARN Issue Type: Bug Affects Versions: 3.1.3, 3.2.1 Reporter: Sen Zhao When we use cursor-leader-elector, *CuratorBasedElectorService.initAndStartLeaderLatch()* will initialize and start *leaderLatch* to elect the leader. Now： 1.ResourceManager will call *CuratorBasedElectorService.initAndStartLeaderLatch()* in *serviceInit()*. 2.ResourceManager will transition to standby in *serviceStart()*. If *leaderLatch* succeeds in electing leader before rm transitions to standby. ResourceManager will always be in standby state. -- 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-10213) Using curator-leader-elector, rm will always be in standby state at some times.
[ https://issues.apache.org/jira/browse/YARN-10213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070810#comment-17070810 ] Sen Zhao commented on YARN-10213: - Patch002 add test. > Using curator-leader-elector, rm will always be in standby state at some > times. > --- > > Key: YARN-10213 > URL: https://issues.apache.org/jira/browse/YARN-10213 > Project: Hadoop YARN > Issue Type: Bug >Affects Versions: 3.2.1, 3.1.3 >Reporter: Sen Zhao >Assignee: Sen Zhao >Priority: Major > Attachments: YARN-10213.001.patch, YARN-10213.002.patch > > > When we use cursor-leader-elector, > *CuratorBasedElectorService.initAndStartLeaderLatch()* > will initialize and start *leaderLatch* to elect the leader. > Now： > 1.ResourceManager will call > *CuratorBasedElectorService.initAndStartLeaderLatch()* in *serviceInit()*. > 2.ResourceManager will transition to standby in *serviceStart()*. > If *leaderLatch* succeeds in electing leader before rm transitions to > standby. ResourceManager will always be in standby state. -- 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-10213) Using curator-leader-elector, rm will always be in standby state at some times.
[ https://issues.apache.org/jira/browse/YARN-10213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sen Zhao updated YARN-10213: Attachment: YARN-10213.002.patch > Using curator-leader-elector, rm will always be in standby state at some > times. > --- > > Key: YARN-10213 > URL: https://issues.apache.org/jira/browse/YARN-10213 > Project: Hadoop YARN > Issue Type: Bug >Affects Versions: 3.2.1, 3.1.3 >Reporter: Sen Zhao >Assignee: Sen Zhao >Priority: Major > Attachments: YARN-10213.001.patch, YARN-10213.002.patch > > > When we use cursor-leader-elector, > *CuratorBasedElectorService.initAndStartLeaderLatch()* > will initialize and start *leaderLatch* to elect the leader. > Now： > 1.ResourceManager will call > *CuratorBasedElectorService.initAndStartLeaderLatch()* in *serviceInit()*. > 2.ResourceManager will transition to standby in *serviceStart()*. > If *leaderLatch* succeeds in electing leader before rm transitions to > standby. ResourceManager will always be in standby state. -- 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-10202) Fix documentation about NodeAttributes.
[
https://issues.apache.org/jira/browse/YARN-10202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sen Zhao updated YARN-10202:
Description:
{noformat:title=NodeAttributes.md}
The above SchedulingRequest requests for 1 container on nodes that must satisfy
following constraints:
1. Node attribute *`rm.yarn.io/python`* doesn't exist on the node or it exist
but its value is not equal to 3
2. Node attribute *`rm.yarn.io/java`* must exist on the node and its value is
equal to 1.8
{noformat}
should be
{noformat}
The above SchedulingRequest requests for 1 container on nodes that must satisfy
following constraints:
1. Node attribute *`rm.yarn.io/python`* doesn't exist on the node or it exist
but its value is not equal to 3
2. Node attribute *`rm.yarn.io/java`* must exist on the node and its value is
equal to 1.8
{noformat}
was:
{noformat:title=NodeAttributes.md}
The above SchedulingRequest requests for 1 container on nodes that must satisfy
following constraints:
1. Node attribute *`rm.yarn.io/python`* doesn't exist on the node or it exist
but its value is not equal to 3
2. Node attribute *`rm.yarn.io/java`* must exist on the node and its value is
equal to 1.8
{noformat}
should be
{noformat}
The above SchedulingRequest requests for 1 container on nodes that must satisfy
following constraints:
1. Node attribute *`rm.yarn.io/python`* doesn't exist on the node or it exist
but its value is not equal to 3
2. Node attribute *`rm.yarn.io/java`* must exist on the node and its value is
equal to 1.8
> Fix documentation about NodeAttributes.
> ---
>
> Key: YARN-10202
> URL: https://issues.apache.org/jira/browse/YARN-10202
> Project: Hadoop YARN
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Sen Zhao
>Assignee: Sen Zhao
>Priority: Minor
>
> {noformat:title=NodeAttributes.md}
> The above SchedulingRequest requests for 1 container on nodes that must
> satisfy following constraints:
> 1. Node attribute *`rm.yarn.io/python`* doesn't exist on the node or it exist
> but its value is not equal to 3
> 2. Node attribute *`rm.yarn.io/java`* must exist on the node and its value is
> equal to 1.8
> {noformat}
> should be
> {noformat}
> The above SchedulingRequest requests for 1 container on nodes that must
> satisfy following constraints:
> 1. Node attribute *`rm.yarn.io/python`* doesn't exist on the node or it exist
> but its value is not equal to 3
> 2. Node attribute *`rm.yarn.io/java`* must exist on the node and its value is
> equal to 1.8
> {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-10202) Fix documentation about NodeAttributes.
[
https://issues.apache.org/jira/browse/YARN-10202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sen Zhao updated YARN-10202:
Attachment: YARN-10202.001.patch
> Fix documentation about NodeAttributes.
> ---
>
> Key: YARN-10202
> URL: https://issues.apache.org/jira/browse/YARN-10202
> Project: Hadoop YARN
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Sen Zhao
>Assignee: Sen Zhao
>Priority: Minor
> Attachments: YARN-10202.001.patch
>
>
> {noformat:title=NodeAttributes.md}
> The above SchedulingRequest requests for 1 container on nodes that must
> satisfy following constraints:
> 1. Node attribute *`rm.yarn.io/python`* doesn't exist on the node or it exist
> but its value is not equal to 3
> 2. Node attribute *`rm.yarn.io/java`* must exist on the node and its value is
> equal to 1.8
> {noformat}
> should be
> {noformat}
> The above SchedulingRequest requests for 1 container on nodes that must
> satisfy following constraints:
> 1. Node attribute *`rm.yarn.io/python`* doesn't exist on the node or it exist
> but its value is not equal to 3
> 2. Node attribute *`rm.yarn.io/java`* must exist on the node and its value is
> equal to 1.8
> {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] [Created] (YARN-10202) Fix documentation about NodeAttributes.
Sen Zhao created YARN-10202:
---
Summary: Fix documentation about NodeAttributes.
Key: YARN-10202
URL: https://issues.apache.org/jira/browse/YARN-10202
Project: Hadoop YARN
Issue Type: Improvement
Affects Versions: 3.2.1
Reporter: Sen Zhao
Assignee: Sen Zhao
{noformat:title=NodeAttributes.md}
The above SchedulingRequest requests for 1 container on nodes that must satisfy
following constraints:
1. Node attribute *`rm.yarn.io/python`* doesn't exist on the node or it exist
but its value is not equal to 3
2. Node attribute *`rm.yarn.io/java`* must exist on the node and its value is
equal to 1.8
{noformat}
should be
{noformat}
The above SchedulingRequest requests for 1 container on nodes that must satisfy
following constraints:
1. Node attribute *`rm.yarn.io/python`* doesn't exist on the node or it exist
but its value is not equal to 3
2. Node attribute *`rm.yarn.io/java`* must exist on the node and its value is
equal to 1.8
--
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
