[jira] [Commented] (AMBARI-16946) Storm Metrics Sink has high chance to discard some datapoints
[ https://issues.apache.org/jira/browse/AMBARI-16946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306267#comment-15306267 ] Sriharsha Chintalapani commented on AMBARI-16946: - [~kabhwan] no lets create the patch against trunk > Storm Metrics Sink has high chance to discard some datapoints > - > > Key: AMBARI-16946 > URL: https://issues.apache.org/jira/browse/AMBARI-16946 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.4.0 >Reporter: Jungtaek Lim > Attachments: AMBARI-16946.patch > > > There's a mismatch between TimelineMetricsCache and Storm metrics unit, while > TimelineMetricsCache considers "metric name + timestamp" to be unique but > Storm is not. > For example, assume that bolt B has task T1, T2 and B has registered metrics > M1. It's possible for metrics sink to receive (T1, M1) and (T2, M1) with same > timestamp TS1 (in TaskInfo, not current time), and received later will be > discarded from TimelineMetricsCache. > If we want to have unique metric point of Storm, we should use "topology name > + component name + task id + metric name" to metric name so that "metric name > + timestamp" will be unique. > There're other issues I would like to address, too. > - Currently, hostname is written to hostname of the machine which runs > metrics sink. Since TaskInfo has hostname of the machine which runs task, > we're better to use this. > - Unit of timestamp of TaskInfo is second, while Storm Metrics Sink uses this > as millisecond, resulting in timestamp flaw, and malfunction of cache > eviction. It should be multiplied by 1000. > - 'component name' is not unique across the cluster, so it's not fit for app > id. 'topology name' is unique so proper value of app id is topology name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16947) Files View : Table row overlaps if group name is long
Pallav Kulshreshtha created AMBARI-16947: Summary: Files View : Table row overlaps if group name is long Key: AMBARI-16947 URL: https://issues.apache.org/jira/browse/AMBARI-16947 Project: Ambari Issue Type: Bug Components: ambari-views Affects Versions: 2.2.2 Reporter: Pallav Kulshreshtha Fix For: 2.4.0 Attachments: Screen Shot 2016-05-17 at 9.47.11 pm.png Table row overlaps if group name is too long. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16947) Files View : Table row overlaps if group name is long
[ https://issues.apache.org/jira/browse/AMBARI-16947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pallav Kulshreshtha updated AMBARI-16947: - Attachment: Screen Shot 2016-05-17 at 9.47.11 pm.png > Files View : Table row overlaps if group name is long > - > > Key: AMBARI-16947 > URL: https://issues.apache.org/jira/browse/AMBARI-16947 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.2 >Reporter: Pallav Kulshreshtha > Fix For: 2.4.0 > > Attachments: Screen Shot 2016-05-17 at 9.47.11 pm.png > > > Table row overlaps if group name is too long. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-16922) Remove LogSearch dependency for Ranger
[ https://issues.apache.org/jira/browse/AMBARI-16922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mugdha Varadkar reopened AMBARI-16922: -- > Remove LogSearch dependency for Ranger > -- > > Key: AMBARI-16922 > URL: https://issues.apache.org/jira/browse/AMBARI-16922 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Mugdha Varadkar >Assignee: Mugdha Varadkar >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16922.patch > > > Remove LogSearch dependency for Ranger -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16894) Default Ranger repos for some services are not getting created
[ https://issues.apache.org/jira/browse/AMBARI-16894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306331#comment-15306331 ] Hudson commented on AMBARI-16894: - FAILURE: Integrated in Ambari-trunk-Commit #4955 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4955/]) AMBARI-16894: Default Ranger repos for some services are not getting (gautam: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=008e4d1844f08373b5bf8ad58bf80d6613149b28]) * ambari-common/src/main/python/resource_management/libraries/functions/ranger_functions_v2.py > Default Ranger repos for some services are not getting created > -- > > Key: AMBARI-16894 > URL: https://issues.apache.org/jira/browse/AMBARI-16894 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Gautam Borad >Assignee: Gautam Borad > Fix For: 2.4.0 > > Attachments: AMBARI-16894.patch > > > Default repos for the following components HDFS, Yarn, Hive, Knox are not > getting created during Service restart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16946) Storm Metrics Sink has high chance to discard some datapoints
[
https://issues.apache.org/jira/browse/AMBARI-16946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306406#comment-15306406
]
Hadoop QA commented on AMBARI-16946:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12806944/AMBARI-16946-trunk-v2.patch
against trunk revision .
{color:red}-1 patch{color}. Top-level trunk compilation may be broken.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7050//console
This message is automatically generated.
> Storm Metrics Sink has high chance to discard some datapoints
> -
>
> Key: AMBARI-16946
> URL: https://issues.apache.org/jira/browse/AMBARI-16946
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Jungtaek Lim
> Attachments: AMBARI-16946-trunk-v2.patch
>
>
> There's a mismatch between TimelineMetricsCache and Storm metrics unit, while
> TimelineMetricsCache considers "metric name + timestamp" to be unique but
> Storm is not.
> For example, assume that bolt B has task T1, T2 and B has registered metrics
> M1. It's possible for metrics sink to receive (T1, M1) and (T2, M1) with same
> timestamp TS1 (in TaskInfo, not current time), and received later will be
> discarded from TimelineMetricsCache.
> If we want to have unique metric point of Storm, we should use "topology name
> + component name + task id + metric name" to metric name so that "metric name
> + timestamp" will be unique.
> There're other issues I would like to address, too.
> - Currently, hostname is written to hostname of the machine which runs
> metrics sink. Since TaskInfo has hostname of the machine which runs task,
> we're better to use this.
> - Unit of timestamp of TaskInfo is second, while Storm Metrics Sink uses this
> as millisecond, resulting in timestamp flaw, and malfunction of cache
> eviction. It should be multiplied by 1000.
> - 'component name' is not unique across the cluster, so it's not fit for app
> id. 'topology name' is unique so proper value of app id is topology name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16922) Remove LogSearch dependency for Ranger
[ https://issues.apache.org/jira/browse/AMBARI-16922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mugdha Varadkar updated AMBARI-16922: - Status: Patch Available (was: In Progress) > Remove LogSearch dependency for Ranger > -- > > Key: AMBARI-16922 > URL: https://issues.apache.org/jira/browse/AMBARI-16922 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Mugdha Varadkar >Assignee: Mugdha Varadkar >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16922.1.patch, AMBARI-16922.patch > > > Remove LogSearch dependency for Ranger -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16922) Remove LogSearch dependency for Ranger
[ https://issues.apache.org/jira/browse/AMBARI-16922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mugdha Varadkar updated AMBARI-16922: - Attachment: AMBARI-16922.1.patch > Remove LogSearch dependency for Ranger > -- > > Key: AMBARI-16922 > URL: https://issues.apache.org/jira/browse/AMBARI-16922 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Mugdha Varadkar >Assignee: Mugdha Varadkar >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16922.1.patch, AMBARI-16922.patch > > > Remove LogSearch dependency for Ranger -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16875) LDAP sync cannot handle if the member attribute value is not DN or id
[ https://issues.apache.org/jira/browse/AMBARI-16875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivér Szabó updated AMBARI-16875: -- Resolution: Fixed Status: Resolved (was: Patch Available) > LDAP sync cannot handle if the member attribute value is not DN or id > - > > Key: AMBARI-16875 > URL: https://issues.apache.org/jira/browse/AMBARI-16875 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Olivér Szabó >Assignee: Olivér Szabó >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16875.patch > > > in case of member attribute value looks like this: >
[jira] [Comment Edited] (AMBARI-16927) Canceling "Select HS2 Interactive" popup does not trigger recommendation call
[ https://issues.apache.org/jira/browse/AMBARI-16927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306433#comment-15306433 ] Andrii Babiichuk edited comment on AMBARI-16927 at 5/30/16 9:28 AM: committed to trunk and branch 2.4 was (Author: ababiichuk): committed to trunk and branch 2.1 > Canceling "Select HS2 Interactive" popup does not trigger recommendation call > - > > Key: AMBARI-16927 > URL: https://issues.apache.org/jira/browse/AMBARI-16927 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16927.patch > > > *STR:* > # Deploy a cluster with hive service > # Enable interactive query on hive service config page > # This will trigger recommendation API call > # This will aslo show "Select HiveServer2 Interactive" host popup > # Click on cancel button shown on this popup > # This will again disable interactive query > *Expected Result:* When "Enable interactive query" config is changed from yes > to no on lciking cancel button, recommendation API call should be again made > *Actual Result:* No recommendation call is made and so incorrect > recommendation remains and eventually gets saved by the user -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMBARI-16901) Add Service wizard: All kerberos related configurations shown on Configure Identities page should be made non-editable on configure services page
[ https://issues.apache.org/jira/browse/AMBARI-16901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306434#comment-15306434 ] Andrii Babiichuk edited comment on AMBARI-16901 at 5/30/16 9:28 AM: committed to trunk and branch 2.4 was (Author: ababiichuk): committed to trunk and branch 2.1 > Add Service wizard: All kerberos related configurations shown on Configure > Identities page should be made non-editable on configure services page > - > > Key: AMBARI-16901 > URL: https://issues.apache.org/jira/browse/AMBARI-16901 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.0.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16901.patch > > > If following conditions are met then config should be made non-editable on > configure->services page: > Cluster is kerberized > Kerberos is ambari managed meaning not manual > Config is stated as an identity in the kerberos descriptor posted to the > cluster (api/v1/clusters/c1/artifacts/kerberos_descriptor). Note that config > has to be an identity to be made non-editable. Note: Other configs mentioned > in the kerberos descriptor should not be made non-editable. Only configs > stated under identities array should be made non-editable. > Configs made non-editable due to satisfying above condition should have their > description appended with the text that "This config can be changed from > Kerberos page under Admin tab by privileged users." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16946) Storm Metrics Sink has high chance to discard some datapoints
[ https://issues.apache.org/jira/browse/AMBARI-16946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306440#comment-15306440 ] Jungtaek Lim commented on AMBARI-16946: --- https://builds.apache.org/job/Ambari-trunk-test-patch/7050/artifact/patch-work/trunkCompile.txt Seems like ambari-web is the reason to failure of build #7050. Just retriggered. > Storm Metrics Sink has high chance to discard some datapoints > - > > Key: AMBARI-16946 > URL: https://issues.apache.org/jira/browse/AMBARI-16946 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.4.0 >Reporter: Jungtaek Lim > Attachments: AMBARI-16946-trunk-v2.patch > > > There's a mismatch between TimelineMetricsCache and Storm metrics unit, while > TimelineMetricsCache considers "metric name + timestamp" to be unique but > Storm is not. > For example, assume that bolt B has task T1, T2 and B has registered metrics > M1. It's possible for metrics sink to receive (T1, M1) and (T2, M1) with same > timestamp TS1 (in TaskInfo, not current time), and received later will be > discarded from TimelineMetricsCache. > If we want to have unique metric point of Storm, we should use "topology name > + component name + task id + metric name" to metric name so that "metric name > + timestamp" will be unique. > There're other issues I would like to address, too. > - Currently, hostname is written to hostname of the machine which runs > metrics sink. Since TaskInfo has hostname of the machine which runs task, > we're better to use this. > - Unit of timestamp of TaskInfo is second, while Storm Metrics Sink uses this > as millisecond, resulting in timestamp flaw, and malfunction of cache > eviction. It should be multiplied by 1000. > - 'component name' is not unique across the cluster, so it's not fit for app > id. 'topology name' is unique so proper value of app id is topology name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16946) Storm Metrics Sink has high chance to discard some datapoints
[ https://issues.apache.org/jira/browse/AMBARI-16946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jungtaek Lim updated AMBARI-16946: -- Attachment: (was: AMBARI-16946.patch) > Storm Metrics Sink has high chance to discard some datapoints > - > > Key: AMBARI-16946 > URL: https://issues.apache.org/jira/browse/AMBARI-16946 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.4.0 >Reporter: Jungtaek Lim > Attachments: AMBARI-16946-trunk.patch > > > There's a mismatch between TimelineMetricsCache and Storm metrics unit, while > TimelineMetricsCache considers "metric name + timestamp" to be unique but > Storm is not. > For example, assume that bolt B has task T1, T2 and B has registered metrics > M1. It's possible for metrics sink to receive (T1, M1) and (T2, M1) with same > timestamp TS1 (in TaskInfo, not current time), and received later will be > discarded from TimelineMetricsCache. > If we want to have unique metric point of Storm, we should use "topology name > + component name + task id + metric name" to metric name so that "metric name > + timestamp" will be unique. > There're other issues I would like to address, too. > - Currently, hostname is written to hostname of the machine which runs > metrics sink. Since TaskInfo has hostname of the machine which runs task, > we're better to use this. > - Unit of timestamp of TaskInfo is second, while Storm Metrics Sink uses this > as millisecond, resulting in timestamp flaw, and malfunction of cache > eviction. It should be multiplied by 1000. > - 'component name' is not unique across the cluster, so it's not fit for app > id. 'topology name' is unique so proper value of app id is topology name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16946) Storm Metrics Sink has high chance to discard some datapoints
[ https://issues.apache.org/jira/browse/AMBARI-16946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jungtaek Lim updated AMBARI-16946: -- Attachment: AMBARI-16946-trunk-v2.patch Found minor bug by myself, attaching v2. > Storm Metrics Sink has high chance to discard some datapoints > - > > Key: AMBARI-16946 > URL: https://issues.apache.org/jira/browse/AMBARI-16946 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.4.0 >Reporter: Jungtaek Lim > Attachments: AMBARI-16946-trunk-v2.patch, AMBARI-16946-trunk.patch > > > There's a mismatch between TimelineMetricsCache and Storm metrics unit, while > TimelineMetricsCache considers "metric name + timestamp" to be unique but > Storm is not. > For example, assume that bolt B has task T1, T2 and B has registered metrics > M1. It's possible for metrics sink to receive (T1, M1) and (T2, M1) with same > timestamp TS1 (in TaskInfo, not current time), and received later will be > discarded from TimelineMetricsCache. > If we want to have unique metric point of Storm, we should use "topology name > + component name + task id + metric name" to metric name so that "metric name > + timestamp" will be unique. > There're other issues I would like to address, too. > - Currently, hostname is written to hostname of the machine which runs > metrics sink. Since TaskInfo has hostname of the machine which runs task, > we're better to use this. > - Unit of timestamp of TaskInfo is second, while Storm Metrics Sink uses this > as millisecond, resulting in timestamp flaw, and malfunction of cache > eviction. It should be multiplied by 1000. > - 'component name' is not unique across the cluster, so it's not fit for app > id. 'topology name' is unique so proper value of app id is topology name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16930) Message text is missing in EU wizard screens that require manual intervention
[ https://issues.apache.org/jira/browse/AMBARI-16930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Babiichuk updated AMBARI-16930: -- Resolution: Fixed Status: Resolved (was: Patch Available) committed to trunk and branch 2.1 > Message text is missing in EU wizard screens that require manual intervention > - > > Key: AMBARI-16930 > URL: https://issues.apache.org/jira/browse/AMBARI-16930 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16930.patch > > > *Steps* > # Install HDP 2.4.2.0 with Ambari 2.4.0.0 > # Start EU to 2.5.0.0 > Observed that in some of the screens that require manual intervention, the > message text is missing in the upper pane. This usually happens after hitting > 'Proceed' in the first message under an Upgrade Group. Subsequent messages do > not show up the text > Screenshots attached -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16901) Add Service wizard: All kerberos related configurations shown on Configure Identities page should be made non-editable on configure services page
[ https://issues.apache.org/jira/browse/AMBARI-16901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Babiichuk updated AMBARI-16901: -- Resolution: Fixed Status: Resolved (was: Patch Available) committed to trunk and branch 2.1 > Add Service wizard: All kerberos related configurations shown on Configure > Identities page should be made non-editable on configure services page > - > > Key: AMBARI-16901 > URL: https://issues.apache.org/jira/browse/AMBARI-16901 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.0.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16901.patch > > > If following conditions are met then config should be made non-editable on > configure->services page: > Cluster is kerberized > Kerberos is ambari managed meaning not manual > Config is stated as an identity in the kerberos descriptor posted to the > cluster (api/v1/clusters/c1/artifacts/kerberos_descriptor). Note that config > has to be an identity to be made non-editable. Note: Other configs mentioned > in the kerberos descriptor should not be made non-editable. Only configs > stated under identities array should be made non-editable. > Configs made non-editable due to satisfying above condition should have their > description appended with the text that "This config can be changed from > Kerberos page under Admin tab by privileged users." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMBARI-16930) Message text is missing in EU wizard screens that require manual intervention
[ https://issues.apache.org/jira/browse/AMBARI-16930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306432#comment-15306432 ] Andrii Babiichuk edited comment on AMBARI-16930 at 5/30/16 9:28 AM: committed to trunk and branch 2.4 was (Author: ababiichuk): committed to trunk and branch 2.1 > Message text is missing in EU wizard screens that require manual intervention > - > > Key: AMBARI-16930 > URL: https://issues.apache.org/jira/browse/AMBARI-16930 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16930.patch > > > *Steps* > # Install HDP 2.4.2.0 with Ambari 2.4.0.0 > # Start EU to 2.5.0.0 > Observed that in some of the screens that require manual intervention, the > message text is missing in the upper pane. This usually happens after hitting > 'Proceed' in the first message under an Upgrade Group. Subsequent messages do > not show up the text > Screenshots attached -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16921) Incorrect reading of 'yarn minimum container size' property from services as it may have changed in current Stack Advisor invocation
[ https://issues.apache.org/jira/browse/AMBARI-16921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Gergely updated AMBARI-16921: Resolution: Duplicate Status: Resolved (was: Patch Available) > Incorrect reading of 'yarn minimum container size' property from services as > it may have changed in current Stack Advisor invocation > > > Key: AMBARI-16921 > URL: https://issues.apache.org/jira/browse/AMBARI-16921 > Project: Ambari > Issue Type: Bug >Reporter: Daniel Gergely >Assignee: Swapan Shridhar >Priority: Blocker > Fix For: 2.4.0 > > > - idea is to take into account reading from configurations. If its not there > then rad from services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16925) Config pages are corrupted for services failed to install
[ https://issues.apache.org/jira/browse/AMBARI-16925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306360#comment-15306360 ] Oleg Nechiporenko commented on AMBARI-16925: Committed to trunk and 2.4.0 > Config pages are corrupted for services failed to install > - > > Key: AMBARI-16925 > URL: https://issues.apache.org/jira/browse/AMBARI-16925 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 > Environment: ambari-server version: ambari-server-2.4.0.0-611 > ambari-server --hash: 1feda434390324d06a1af922328b3d1b4c788305 > HDP Stack: 2.5 > HDP Version: 2.5.0.0-582 > Ambari DB: :PostgreSQL_External > Oozie/Hive DB: PostgreSQL_External/PostgreSQL_External > Security:yes > Security Type:AD/AD > Blueprints: true > Umask: > JDK: OracleJDK8 > HA: no > OS: SUSE Linux Enterprise Server 11 > Ambari User: root > Agents User: root > MOTD enabled: false > Customized service users: false > Is tmp exec: false >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko >Priority: Blocker > Fix For: 2.4.0 > > Attachments: AMBARI-16925.patch > > > Deploy of cluster via blueprints was failed on installing of components. > After that services failed to install have corrupted configs pages. This can > block user because there can be situation when it is not possible to install > service without configs changing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16946) Storm Metrics Sink has high chance to discard some datapoints
[ https://issues.apache.org/jira/browse/AMBARI-16946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jungtaek Lim updated AMBARI-16946: -- Attachment: (was: AMBARI-16946-trunk.patch) > Storm Metrics Sink has high chance to discard some datapoints > - > > Key: AMBARI-16946 > URL: https://issues.apache.org/jira/browse/AMBARI-16946 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.4.0 >Reporter: Jungtaek Lim > Attachments: AMBARI-16946-trunk-v2.patch > > > There's a mismatch between TimelineMetricsCache and Storm metrics unit, while > TimelineMetricsCache considers "metric name + timestamp" to be unique but > Storm is not. > For example, assume that bolt B has task T1, T2 and B has registered metrics > M1. It's possible for metrics sink to receive (T1, M1) and (T2, M1) with same > timestamp TS1 (in TaskInfo, not current time), and received later will be > discarded from TimelineMetricsCache. > If we want to have unique metric point of Storm, we should use "topology name > + component name + task id + metric name" to metric name so that "metric name > + timestamp" will be unique. > There're other issues I would like to address, too. > - Currently, hostname is written to hostname of the machine which runs > metrics sink. Since TaskInfo has hostname of the machine which runs task, > we're better to use this. > - Unit of timestamp of TaskInfo is second, while Storm Metrics Sink uses this > as millisecond, resulting in timestamp flaw, and malfunction of cache > eviction. It should be multiplied by 1000. > - 'component name' is not unique across the cluster, so it's not fit for app > id. 'topology name' is unique so proper value of app id is topology name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16948) Not able to save custom config in view config
Gaurav Nagar created AMBARI-16948: - Summary: Not able to save custom config in view config Key: AMBARI-16948 URL: https://issues.apache.org/jira/browse/AMBARI-16948 Project: Ambari Issue Type: Bug Components: ambari-views Affects Versions: 2.4.0 Reporter: Gaurav Nagar Assignee: Gaurav Nagar Fix For: 2.4.0 While creating/updating the existing view instance, custom section is not able the value. Steps: 1. Open existing File view instance. 2. Change cluster from Local to Custom. 3. Set value in WebHDFS FileSystem URI. There is error thrown in saving the config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16948) Not able to save custom config in view config
[ https://issues.apache.org/jira/browse/AMBARI-16948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Nagar updated AMBARI-16948: -- Attachment: AMBARI-16948_branch-2.4.patch > Not able to save custom config in view config > - > > Key: AMBARI-16948 > URL: https://issues.apache.org/jira/browse/AMBARI-16948 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.4.0 >Reporter: Gaurav Nagar >Assignee: Gaurav Nagar > Fix For: 2.4.0 > > Attachments: AMBARI-16948_branch-2.4.patch > > > While creating/updating the existing view instance, custom section is not > able the value. > Steps: > 1. Open existing File view instance. > 2. Change cluster from Local to Custom. > 3. Set value in WebHDFS FileSystem URI. > There is error thrown in saving the config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16948) Not able to save custom config in view config
[ https://issues.apache.org/jira/browse/AMBARI-16948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Nagar updated AMBARI-16948: -- Status: Patch Available (was: Open) > Not able to save custom config in view config > - > > Key: AMBARI-16948 > URL: https://issues.apache.org/jira/browse/AMBARI-16948 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.4.0 >Reporter: Gaurav Nagar >Assignee: Gaurav Nagar > Fix For: 2.4.0 > > Attachments: AMBARI-16948_branch-2.4.patch > > > While creating/updating the existing view instance, custom section is not > able the value. > Steps: > 1. Open existing File view instance. > 2. Change cluster from Local to Custom. > 3. Set value in WebHDFS FileSystem URI. > There is error thrown in saving the config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16875) LDAP sync cannot handle if the member attribute value is not DN or id
[
https://issues.apache.org/jira/browse/AMBARI-16875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306428#comment-15306428
]
Olivér Szabó commented on AMBARI-16875:
---
committed to branch-2.4:
{code:java}
commit 615133d75b3520a50b4a702bf4b8172d47b70fcc
Author: oleewere
Date: Fri May 27 21:54:29 2016 +0200
AMBARI-16875. LDAP sync cannot handle if the member attribute value is not
DN or id (oleewere)
{code}
> LDAP sync cannot handle if the member attribute value is not DN or id
> -
>
> Key: AMBARI-16875
> URL: https://issues.apache.org/jira/browse/AMBARI-16875
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16875.patch
>
>
> in case of member attribute value looks like this:
>
[jira] [Commented] (AMBARI-16946) Storm Metrics Sink has high chance to discard some datapoints
[
https://issues.apache.org/jira/browse/AMBARI-16946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306442#comment-15306442
]
Hadoop QA commented on AMBARI-16946:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12806944/AMBARI-16946-trunk-v2.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:red}-1 javac{color}. The applied patch generated 76 javac
compiler warnings (more than the trunk's current 74 warnings).
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-metrics/ambari-metrics-storm-sink.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7053//testReport/
Javac warnings:
https://builds.apache.org/job/Ambari-trunk-test-patch/7053//artifact/trunk/patchprocess/diffJavacWarnings.txt
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7053//console
This message is automatically generated.
> Storm Metrics Sink has high chance to discard some datapoints
> -
>
> Key: AMBARI-16946
> URL: https://issues.apache.org/jira/browse/AMBARI-16946
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Jungtaek Lim
> Attachments: AMBARI-16946-trunk-v2.patch
>
>
> There's a mismatch between TimelineMetricsCache and Storm metrics unit, while
> TimelineMetricsCache considers "metric name + timestamp" to be unique but
> Storm is not.
> For example, assume that bolt B has task T1, T2 and B has registered metrics
> M1. It's possible for metrics sink to receive (T1, M1) and (T2, M1) with same
> timestamp TS1 (in TaskInfo, not current time), and received later will be
> discarded from TimelineMetricsCache.
> If we want to have unique metric point of Storm, we should use "topology name
> + component name + task id + metric name" to metric name so that "metric name
> + timestamp" will be unique.
> There're other issues I would like to address, too.
> - Currently, hostname is written to hostname of the machine which runs
> metrics sink. Since TaskInfo has hostname of the machine which runs task,
> we're better to use this.
> - Unit of timestamp of TaskInfo is second, while Storm Metrics Sink uses this
> as millisecond, resulting in timestamp flaw, and malfunction of cache
> eviction. It should be multiplied by 1000.
> - 'component name' is not unique across the cluster, so it's not fit for app
> id. 'topology name' is unique so proper value of app id is topology name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16947) Files View : Table row overlaps if group name is long
[ https://issues.apache.org/jira/browse/AMBARI-16947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pallav Kulshreshtha updated AMBARI-16947: - Status: Patch Available (was: Open) > Files View : Table row overlaps if group name is long > - > > Key: AMBARI-16947 > URL: https://issues.apache.org/jira/browse/AMBARI-16947 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.2 >Reporter: Pallav Kulshreshtha > Fix For: 2.4.0 > > Attachments: AMBARI-16947_branch-2.4.patch, Screen Shot 2016-05-17 at > 9.47.11 pm.png > > > Table row overlaps if group name is too long. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16946) Storm Metrics Sink has high chance to discard some datapoints
[ https://issues.apache.org/jira/browse/AMBARI-16946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jungtaek Lim updated AMBARI-16946: -- Attachment: AMBARI-16946-trunk.patch Reattaching patch against latest trunk. > Storm Metrics Sink has high chance to discard some datapoints > - > > Key: AMBARI-16946 > URL: https://issues.apache.org/jira/browse/AMBARI-16946 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.4.0 >Reporter: Jungtaek Lim > Attachments: AMBARI-16946-trunk.patch > > > There's a mismatch between TimelineMetricsCache and Storm metrics unit, while > TimelineMetricsCache considers "metric name + timestamp" to be unique but > Storm is not. > For example, assume that bolt B has task T1, T2 and B has registered metrics > M1. It's possible for metrics sink to receive (T1, M1) and (T2, M1) with same > timestamp TS1 (in TaskInfo, not current time), and received later will be > discarded from TimelineMetricsCache. > If we want to have unique metric point of Storm, we should use "topology name > + component name + task id + metric name" to metric name so that "metric name > + timestamp" will be unique. > There're other issues I would like to address, too. > - Currently, hostname is written to hostname of the machine which runs > metrics sink. Since TaskInfo has hostname of the machine which runs task, > we're better to use this. > - Unit of timestamp of TaskInfo is second, while Storm Metrics Sink uses this > as millisecond, resulting in timestamp flaw, and malfunction of cache > eviction. It should be multiplied by 1000. > - 'component name' is not unique across the cluster, so it's not fit for app > id. 'topology name' is unique so proper value of app id is topology name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16922) Remove LogSearch dependency for Ranger
[
https://issues.apache.org/jira/browse/AMBARI-16922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306416#comment-15306416
]
Hadoop QA commented on AMBARI-16922:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12806942/AMBARI-16922.1.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7051//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7051//console
This message is automatically generated.
> Remove LogSearch dependency for Ranger
> --
>
> Key: AMBARI-16922
> URL: https://issues.apache.org/jira/browse/AMBARI-16922
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16922.1.patch, AMBARI-16922.patch
>
>
> Remove LogSearch dependency for Ranger
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16947) Files View : Table row overlaps if group name is long
[
https://issues.apache.org/jira/browse/AMBARI-16947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306424#comment-15306424
]
Hadoop QA commented on AMBARI-16947:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12806933/AMBARI-16947_branch-2.4.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The test build failed in
contrib/views/files
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7052//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7052//console
This message is automatically generated.
> Files View : Table row overlaps if group name is long
> -
>
> Key: AMBARI-16947
> URL: https://issues.apache.org/jira/browse/AMBARI-16947
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.2.2
>Reporter: Pallav Kulshreshtha
> Fix For: 2.4.0
>
> Attachments: AMBARI-16947_branch-2.4.patch, Screen Shot 2016-05-17 at
> 9.47.11 pm.png
>
>
> Table row overlaps if group name is too long.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16875) LDAP sync cannot handle if the member attribute value is not DN or id
[
https://issues.apache.org/jira/browse/AMBARI-16875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306423#comment-15306423
]
Olivér Szabó commented on AMBARI-16875:
---
committed to trunk:
{code:java}
commit d581b4e552ad47d3dc9e96ed9919e87d5ae9babe
Author: oleewere
Date: Fri May 27 21:54:29 2016 +0200
AMBARI-16875. LDAP sync cannot handle if the member attribute value is not
DN or id (oleewere)
{code}
> LDAP sync cannot handle if the member attribute value is not DN or id
> -
>
> Key: AMBARI-16875
> URL: https://issues.apache.org/jira/browse/AMBARI-16875
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16875.patch
>
>
> in case of member attribute value looks like this:
>
[jira] [Updated] (AMBARI-16947) Files View : Table row overlaps if group name is long
[ https://issues.apache.org/jira/browse/AMBARI-16947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pallav Kulshreshtha updated AMBARI-16947: - Attachment: AMBARI-16947_branch-2.4.patch > Files View : Table row overlaps if group name is long > - > > Key: AMBARI-16947 > URL: https://issues.apache.org/jira/browse/AMBARI-16947 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.2 >Reporter: Pallav Kulshreshtha > Fix For: 2.4.0 > > Attachments: AMBARI-16947_branch-2.4.patch, Screen Shot 2016-05-17 at > 9.47.11 pm.png > > > Table row overlaps if group name is too long. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16890) Updating Ambari configs changes for latest Ranger configs
[
https://issues.apache.org/jira/browse/AMBARI-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mugdha Varadkar updated AMBARI-16890:
-
Status: Patch Available (was: In Progress)
> Updating Ambari configs changes for latest Ranger configs
> -
>
> Key: AMBARI-16890
> URL: https://issues.apache.org/jira/browse/AMBARI-16890
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
> Fix For: 2.4.0
>
> Attachments: AMBARI-16890.1.patch, AMBARI-16890.2.patch,
> AMBARI-16890.patch
>
>
> Changes include:
> # Enable Ranger SSO property as a checkbox
> # Populate query param originalUrl
> # Adding below new properties to ranger-admin-site.xml:
> - ranger.kms.service.user.hdfs – default value "hdfs"
> - ranger.kms.service.user.hive – default value "hive"
> # Updating default value for below properties in latest stack:
> - ranger.ldap.ad.user.searchfilter {code}(sAMAccountName={0}){code}
> - ranger.ldap.user.searchfilter {code}(uid={0}){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16890) Updating Ambari configs changes for latest Ranger configs
[
https://issues.apache.org/jira/browse/AMBARI-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mugdha Varadkar updated AMBARI-16890:
-
Attachment: AMBARI-16890.2.patch
> Updating Ambari configs changes for latest Ranger configs
> -
>
> Key: AMBARI-16890
> URL: https://issues.apache.org/jira/browse/AMBARI-16890
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
> Fix For: 2.4.0
>
> Attachments: AMBARI-16890.1.patch, AMBARI-16890.2.patch,
> AMBARI-16890.patch
>
>
> Changes include:
> # Enable Ranger SSO property as a checkbox
> # Populate query param originalUrl
> # Adding below new properties to ranger-admin-site.xml:
> - ranger.kms.service.user.hdfs – default value "hdfs"
> - ranger.kms.service.user.hive – default value "hive"
> # Updating default value for below properties in latest stack:
> - ranger.ldap.ad.user.searchfilter {code}(sAMAccountName={0}){code}
> - ranger.ldap.user.searchfilter {code}(uid={0}){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16949) Metrics Collector API shows NPE if we use wildcard (%25 for '%') for metric name
[
https://issues.apache.org/jira/browse/AMBARI-16949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306476#comment-15306476
]
Jungtaek Lim commented on AMBARI-16949:
---
PhoenixHBaseAccessor.appendMetricFromResultSet() doesn't throw NPE but it
doesn't match proper functions when both wildcard and functions are used.
https://github.com/apache/ambari/blob/branch-2.2.2/ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java#L668-L693
I guess this is not expected behavior. What do others think?
> Metrics Collector API shows NPE if we use wildcard (%25 for '%') for metric
> name
>
>
> Key: AMBARI-16949
> URL: https://issues.apache.org/jira/browse/AMBARI-16949
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Jungtaek Lim
>
> When we request '/ws/v1/timeline/metrics' with metric name which contains %25
> (escaped '%'), response for the API is json describing there's NPE.
> And NPE is logged for ambari-metrics-collector log file.
> {code}
> 2016-05-30 09:15:05,061 WARN
> org.apache.hadoop.yarn.webapp.GenericExceptionHandler: INTERNAL_SERVER_ERROR
> java.lang.NullPointerException
> at
> org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.PhoenixHBaseAccessor.appendAggregateMetricFromResultSet(PhoenixHBaseAccessor.java:810)
> at
> org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.PhoenixHBaseAccessor.getAggregateMetricRecords(PhoenixHBaseAccessor.java:772)
> at
> org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.HBaseTimelineMetricStore.getTimelineMetrics(HBaseTimelineMetricStore.java:178)
> at
> org.apache.hadoop.yarn.server.applicationhistoryservice.webapp.TimelineWebServices.getTimelineMetrics(TimelineWebServices.java:372)
> at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
> {code}
> Reason of NPE:
> Metrics are properly fetched with wildcard. But when applying functions to
> result set, actual metric name is not exist from map of metric name to list
> of function.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16950) "DISCARD" button doesn't work on HIVE INTERACTIVE page.
[
https://issues.apache.org/jira/browse/AMBARI-16950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonenko Alexander updated AMBARI-16950:
-
Attachment: AMBARI-16950.patch
> "DISCARD" button doesn't work on HIVE INTERACTIVE page.
> ---
>
> Key: AMBARI-16950
> URL: https://issues.apache.org/jira/browse/AMBARI-16950
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-16950.patch, Screen Shot 2016-05-25 at 2.56.13
> PM.png, Screen Shot 2016-05-25 at 3.05.37 PM.png
>
>
> - Starting from this page. !Screen Shot 2016-05-25 at 2.56.13
> PM.png|thumbnail! , lets says if we modify any slider. Then instead of SAVE,
> lets click SUMMARY on top, to move away from this page. This dialog will
> show up. !Screen Shot 2016-05-25 at 3.05.37 PM.png|thumbnail! . Here,
> 'Discard' button wont work.
> {code}
> Ambari-2.4.0.0
> # ambari-server --hash
> 008c8219678493888bb8e0daee7beb668e7517e5
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16891) SSL support for Log Search Solr
[
https://issues.apache.org/jira/browse/AMBARI-16891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306482#comment-15306482
]
Olivér Szabó commented on AMBARI-16891:
---
committed to branch-2.4:
{code:java}
commit 74f930dfa1049e4c4f9f0044ea8abe9f7708842c
Author: Miklos Gergely
Date: Mon May 30 11:31:17 2016 +0200
AMBARI-16891. SSL support for Log Search Solr (Miklos Gergely via oleewere)
{code}
> SSL support for Log Search Solr
> ---
>
> Key: AMBARI-16891
> URL: https://issues.apache.org/jira/browse/AMBARI-16891
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-logsearch
>Affects Versions: 2.4.0
>Reporter: Miklos Gergely
>Assignee: Miklos Gergely
> Fix For: 2.4.0
>
> Attachments: AMBARI-16891.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16890) Updating Ambari configs changes for latest Ranger configs
[
https://issues.apache.org/jira/browse/AMBARI-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306461#comment-15306461
]
Hadoop QA commented on AMBARI-16890:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12806956/AMBARI-16890.2.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7054//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7054//console
This message is automatically generated.
> Updating Ambari configs changes for latest Ranger configs
> -
>
> Key: AMBARI-16890
> URL: https://issues.apache.org/jira/browse/AMBARI-16890
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
> Fix For: 2.4.0
>
> Attachments: AMBARI-16890.1.patch, AMBARI-16890.2.patch,
> AMBARI-16890.patch
>
>
> Changes include:
> # Enable Ranger SSO property as a checkbox
> # Populate query param originalUrl
> # Adding below new properties to ranger-admin-site.xml:
> - ranger.kms.service.user.hdfs – default value "hdfs"
> - ranger.kms.service.user.hive – default value "hive"
> # Updating default value for below properties in latest stack:
> - ranger.ldap.ad.user.searchfilter {code}(sAMAccountName={0}){code}
> - ranger.ldap.user.searchfilter {code}(uid={0}){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (AMBARI-16891) SSL support for Log Search Solr
[ https://issues.apache.org/jira/browse/AMBARI-16891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miklos Gergely updated AMBARI-16891: Comment: was deleted (was: This modification allows the operator to set up SSL connection between the clients ( Log Search Server, Log Feeders ) and the Solr server. The operator may specify the location of the trust stores and the key stores ( and also their types and their passwords ), and it is also the operator's responsibility to ensure those trust stores and key stores, containing the appropriate certificates and keys.) > SSL support for Log Search Solr > --- > > Key: AMBARI-16891 > URL: https://issues.apache.org/jira/browse/AMBARI-16891 > Project: Ambari > Issue Type: Improvement > Components: ambari-logsearch >Affects Versions: 2.4.0 >Reporter: Miklos Gergely >Assignee: Miklos Gergely > Fix For: 2.4.0 > > Attachments: AMBARI-16891.patch > > > This modification allows the operator to set up SSL connection between the > clients ( Log Search Server, Log Feeders ) and the Solr server. The operator > may specify the location of the trust stores and the key stores ( and also > their types and their passwords ), and it is also the operator's > responsibility to ensure those trust stores and key stores, containing the > appropriate certificates and keys. > The operator must create a key store and a trust store file before the SSL is > enabled on the Solr server host, and also on each client host, then set the > location, type and password of these stores on the advanced configuration > site of the Log Search service. The stores must be on the same path on each > host with the Logfeeder component on it. The location of the stores can be > set here on the Log Search / Configs / Advanced tab: > Solr server: Advanced logsearch-solr-env > Log Search server: Advanced logsearch-env > Logfeeders: Advanced logfeeder-env -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16941) Cluster install wizard hangs and cannot proceed if Knox is the only service selected for install
[ https://issues.apache.org/jira/browse/AMBARI-16941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-16941: - Resolution: Fixed Status: Resolved (was: Patch Available) committed to trunk and branch-2.4 > Cluster install wizard hangs and cannot proceed if Knox is the only service > selected for install > > > Key: AMBARI-16941 > URL: https://issues.apache.org/jira/browse/AMBARI-16941 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: trunk, 2.4.0 >Reporter: Sangeeta Ravindran >Assignee: Sangeeta Ravindran > Fix For: 2.4.0 > > Attachments: AMBARI-16941.patch > > > 1. Open Cluster Install Wizard and select Knox as the only service to install. > 2. On step6 of the wizard (Assign Slaves and Clients), you cannot click on > Next and proceed because of an error in the javascript code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16950) "DISCARD" button doesn't work on HIVE INTERACTIVE page.
[
https://issues.apache.org/jira/browse/AMBARI-16950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonenko Alexander updated AMBARI-16950:
-
Attachment: Screen Shot 2016-05-25 at 2.56.13 PM.png
Screen Shot 2016-05-25 at 3.05.37 PM.png
> "DISCARD" button doesn't work on HIVE INTERACTIVE page.
> ---
>
> Key: AMBARI-16950
> URL: https://issues.apache.org/jira/browse/AMBARI-16950
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: Screen Shot 2016-05-25 at 2.56.13 PM.png, Screen Shot
> 2016-05-25 at 3.05.37 PM.png
>
>
> - Starting from this page. !Screen Shot 2016-05-25 at 2.56.13
> PM.png|thumbnail! , lets says if we modify any slider. Then instead of SAVE,
> lets click SUMMARY on top, to move away from this page. This dialog will
> show up. !Screen Shot 2016-05-25 at 3.05.37 PM.png|thumbnail! . Here,
> 'Discard' button wont work.
> {code}
> Ambari-2.4.0.0
> # ambari-server --hash
> 008c8219678493888bb8e0daee7beb668e7517e5
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16948) Not able to save custom config in view config
[ https://issues.apache.org/jira/browse/AMBARI-16948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pallav Kulshreshtha updated AMBARI-16948: - Resolution: Fixed Status: Resolved (was: Patch Available) committed to trunk and branch-2.4 > Not able to save custom config in view config > - > > Key: AMBARI-16948 > URL: https://issues.apache.org/jira/browse/AMBARI-16948 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.4.0 >Reporter: Gaurav Nagar >Assignee: Gaurav Nagar > Fix For: 2.4.0 > > Attachments: AMBARI-16948_branch-2.4.patch > > > While creating/updating the existing view instance, custom section is not > able the value. > Steps: > 1. Open existing File view instance. > 2. Change cluster from Local to Custom. > 3. Set value in WebHDFS FileSystem URI. > There is error thrown in saving the config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16938) Deploy: UI: Hive_metastore not started
[
https://issues.apache.org/jira/browse/AMBARI-16938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaly Brodetskyi updated AMBARI-16938:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed to trunk and branch-2.4
> Deploy: UI: Hive_metastore not started
> --
>
> Key: AMBARI-16938
> URL: https://issues.apache.org/jira/browse/AMBARI-16938
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-16938.patch
>
>
> Deploy ambari cluster using UI with hive for existing mysql setup
> Actual: Hive metastore is failing to start due to unable to connect to DB.
> 2016-05-26 00:20:15,442 - Execute['/usr/jdk64/jdk1.8.0_77/bin/java -cp
> /usr/lib/ambari-agent/DBConnectionVerification.jar:/usr/hdp/current/hive-metastore/lib/mysql-connector-java.jar
> org.apache.ambari.server.DBConnectionVerification 'jdbc:mysql://host/hivedb'
> hiveuser PROTECTED com.mysql.jdbc.Driver']
> {'path': ['/usr/sbin:/sbin:/usr/local/bin:/bin:/usr/bin'], 'tries': 5,
> 'try_sleep': 10}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16950) "DISCARD" button doesn't work on HIVE INTERACTIVE page.
[
https://issues.apache.org/jira/browse/AMBARI-16950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonenko Alexander updated AMBARI-16950:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
committed to trunk and branch-2.4
> "DISCARD" button doesn't work on HIVE INTERACTIVE page.
> ---
>
> Key: AMBARI-16950
> URL: https://issues.apache.org/jira/browse/AMBARI-16950
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-16950.patch, Screen Shot 2016-05-25 at 2.56.13
> PM.png, Screen Shot 2016-05-25 at 3.05.37 PM.png
>
>
> - Starting from this page. !Screen Shot 2016-05-25 at 2.56.13
> PM.png|thumbnail! , lets says if we modify any slider. Then instead of SAVE,
> lets click SUMMARY on top, to move away from this page. This dialog will
> show up. !Screen Shot 2016-05-25 at 3.05.37 PM.png|thumbnail! . Here,
> 'Discard' button wont work.
> {code}
> Ambari-2.4.0.0
> # ambari-server --hash
> 008c8219678493888bb8e0daee7beb668e7517e5
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16289) Upgrade existing capacity scheduler view instance after the Remote Ambari Cluster changes
[ https://issues.apache.org/jira/browse/AMBARI-16289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pallav Kulshreshtha updated AMBARI-16289: - Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk and branch-2.4 > Upgrade existing capacity scheduler view instance after the Remote Ambari > Cluster changes > - > > Key: AMBARI-16289 > URL: https://issues.apache.org/jira/browse/AMBARI-16289 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Reporter: Gaurav Nagar >Assignee: Gaurav Nagar > Fix For: 2.4.0 > > Attachments: AMBARI-16289_branch-2.4.patch > > > With https://issues.apache.org/jira/browse/AMBARI-16274 . Capacity scheduler > instances which is configured as Custom won't work. > We need to provide proper upgrade for those instances, so instances will work > without any extra configuration after upgrade -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16925) Config pages are corrupted for services failed to install
[ https://issues.apache.org/jira/browse/AMBARI-16925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306449#comment-15306449 ] Hudson commented on AMBARI-16925: - SUCCESS: Integrated in Ambari-trunk-Commit #4956 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4956/]) AMBARI-16925. Config pages are corrupted for services failed to install. (onechiporenko: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=e12b8130def42684ae5bf84721b3e7fa8e7db644]) * ambari-web/app/models/configs/service_config_version.js * ambari-web/app/mixins/common/configs/configs_loader.js * ambari-web/app/controllers/main/service/info/configs.js * ambari-web/test/views/common/host_progress_popup_body_view_test.js * ambari-web/app/models/configs/config_group.js * ambari-web/test/models/configs/config_group_test.js * ambari-web/test/mixins/common/configs/enhanced_configs_test.js * ambari-web/app/mappers/configs/service_config_version_mapper.js * ambari-web/app/mappers/configs/config_groups_mapper.js * ambari-web/app/views/common/configs/config_history_flow.js > Config pages are corrupted for services failed to install > - > > Key: AMBARI-16925 > URL: https://issues.apache.org/jira/browse/AMBARI-16925 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 > Environment: ambari-server version: ambari-server-2.4.0.0-611 > ambari-server --hash: 1feda434390324d06a1af922328b3d1b4c788305 > HDP Stack: 2.5 > HDP Version: 2.5.0.0-582 > Ambari DB: :PostgreSQL_External > Oozie/Hive DB: PostgreSQL_External/PostgreSQL_External > Security:yes > Security Type:AD/AD > Blueprints: true > Umask: > JDK: OracleJDK8 > HA: no > OS: SUSE Linux Enterprise Server 11 > Ambari User: root > Agents User: root > MOTD enabled: false > Customized service users: false > Is tmp exec: false >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko >Priority: Blocker > Fix For: 2.4.0 > > Attachments: AMBARI-16925.patch > > > Deploy of cluster via blueprints was failed on installing of components. > After that services failed to install have corrupted configs pages. This can > block user because there can be situation when it is not possible to install > service without configs changing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16949) Metrics Collector API shows NPE if we use wildcard (%25 for '%') for metric name
[
https://issues.apache.org/jira/browse/AMBARI-16949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jungtaek Lim updated AMBARI-16949:
--
Description:
When we request '/ws/v1/timeline/metrics' with metric name which contains %25
(escaped '%'), response for the API is json describing there's NPE.
And NPE is logged for ambari-metrics-collector log file.
{code}
2016-05-30 09:15:05,061 WARN
org.apache.hadoop.yarn.webapp.GenericExceptionHandler: INTERNAL_SERVER_ERROR
java.lang.NullPointerException
at
org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.PhoenixHBaseAccessor.appendAggregateMetricFromResultSet(PhoenixHBaseAccessor.java:810)
at
org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.PhoenixHBaseAccessor.getAggregateMetricRecords(PhoenixHBaseAccessor.java:772)
at
org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.HBaseTimelineMetricStore.getTimelineMetrics(HBaseTimelineMetricStore.java:178)
at
org.apache.hadoop.yarn.server.applicationhistoryservice.webapp.TimelineWebServices.getTimelineMetrics(TimelineWebServices.java:372)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
{code}
Reason of NPE:
Metrics are properly fetched with wildcard. But when applying functions to
result set, actual metric name is not exist from map of metric name to list of
function.
was:
When we request '/ws/v1/timeline/metrics' with metric name which contains %25
(escaped '%'), response for the API is json describing there's NPE.
And NPE is logged for ambari-metrics-collector log file.
{code}
2016-05-30 09:15:05,061 WARN
org.apache.hadoop.yarn.webapp.GenericExceptionHandler: INTERNAL_SERVER_ERROR
java.lang.NullPointerException
at
org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.PhoenixHBaseAccessor.appendAggregateMetricFromResultSet(PhoenixHBaseAccessor.java:810)
at
org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.PhoenixHBaseAccessor.getAggregateMetricRecords(PhoenixHBaseAccessor.java:772)
at
org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.HBaseTimelineMetricStore.getTimelineMetrics(HBaseTimelineMetricStore.java:178)
at
org.apache.hadoop.yarn.server.applicationhistoryservice.webapp.TimelineWebServices.getTimelineMetrics(TimelineWebServices.java:372)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
{code}
> Metrics Collector API shows NPE if we use wildcard (%25 for '%') for metric
> name
>
>
> Key: AMBARI-16949
> URL: https://issues.apache.org/jira/browse/AMBARI-16949
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Jungtaek Lim
>
> When we request '/ws/v1/timeline/metrics' with metric name which contains %25
> (escaped '%'), response for the API is json describing there's NPE.
> And NPE is logged for ambari-metrics-collector log file.
> {code}
> 2016-05-30 09:15:05,061 WARN
> org.apache.hadoop.yarn.webapp.GenericExceptionHandler: INTERNAL_SERVER_ERROR
> java.lang.NullPointerException
> at
> org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.PhoenixHBaseAccessor.appendAggregateMetricFromResultSet(PhoenixHBaseAccessor.java:810)
> at
> org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.PhoenixHBaseAccessor.getAggregateMetricRecords(PhoenixHBaseAccessor.java:772)
> at
> org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.HBaseTimelineMetricStore.getTimelineMetrics(HBaseTimelineMetricStore.java:178)
> at
> org.apache.hadoop.yarn.server.applicationhistoryservice.webapp.TimelineWebServices.getTimelineMetrics(TimelineWebServices.java:372)
> at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
> {code}
> Reason of NPE:
> Metrics are properly fetched with wildcard. But when applying functions to
> result set, actual metric name is not exist from map of metric name to list
> of function.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-16950) "DISCARD" button doesn't work on HIVE INTERACTIVE page.
Antonenko Alexander created AMBARI-16950:
Summary: "DISCARD" button doesn't work on HIVE INTERACTIVE page.
Key: AMBARI-16950
URL: https://issues.apache.org/jira/browse/AMBARI-16950
Project: Ambari
Issue Type: Bug
Components: ambari-web
Affects Versions: 2.4.0
Reporter: Antonenko Alexander
Assignee: Antonenko Alexander
Fix For: 2.4.0
- Starting from this page. !Screen Shot 2016-05-25 at 2.56.13
PM.png|thumbnail! , lets says if we modify any slider. Then instead of SAVE,
lets click SUMMARY on top, to move away from this page. This dialog will show
up. !Screen Shot 2016-05-25 at 3.05.37 PM.png|thumbnail! . Here, 'Discard'
button wont work.
{code}
Ambari-2.4.0.0
# ambari-server --hash
008c8219678493888bb8e0daee7beb668e7517e5
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16020) Hive Metastore install failed since mysql-server not installed
[
https://issues.apache.org/jira/browse/AMBARI-16020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306473#comment-15306473
]
Andrii Tkach commented on AMBARI-16020:
---
committed to trunk and branch-2.4
> Hive Metastore install failed since mysql-server not installed
> --
>
> Key: AMBARI-16020
> URL: https://issues.apache.org/jira/browse/AMBARI-16020
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16020.patch, AMBARI-16020_2.patch
>
>
> STR:
> * Install Ambari 2.4.0.0-4686 on 3 hosts
> * Install HDP 2.5.0.0-58 with Hive Server on 1 host and Hive Metastore on the
> other
> * Select option to install Hive with "New MySQL" database
> Failed installing Hive Metastore since MySQL service was not installed.
> {code}
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 293, in _call
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'export
> HIVE_CONF_DIR=/usr/hdp/current/hive-metastore/conf/conf.server ;
> /usr/hdp/current/hive-metastore/bin/schematool -initSchema -dbType mysql
> -userName hive -passWord [PROTECTED]' returned 1. WARNING: Use "yarn jar" to
> launch YARN applications.
> Metastore connection URL:
> jdbc:mysql://c6405.ambari.apache.org/hive?createDatabaseIfNotExist=true
> Metastore Connection Driver : com.mysql.jdbc.Driver
> Metastore connection User: hive
> org.apache.hadoop.hive.metastore.HiveMetaException: Failed to get schema
> version.
> *** schemaTool failed ***
> {code}
> I had to run this manually,
> {code}
> yum install mysql-server -y
> service mysqld start
> mysql -u root -p (password is empty string)
> mysql> CREATE USER 'hive'@'%' IDENTIFIED BY 'admin';
> Query OK, 0 rows affected (0.00 sec)
> mysql> GRANT ALL PRIVILEGES ON *.* TO 'hive'@'%';
> Query OK, 0 rows affected (0.00 sec)
> mysql> GRANT ALL PRIVILEGES ON *.* TO 'hive'@'localhost';
> Query OK, 0 rows affected (0.00 sec)
> mysql> GRANT ALL PRIVILEGES ON *.* TO 'hive'@'c6405.ambari.apache.org';
> Query OK, 0 rows affected (0.00 sec)
> mysql> GRANT ALL PRIVILEGES ON *.* TO 'hive'@'c6405.ambari.apache.org'
> IDENTIFIED BY 'admin' WITH GRANT OPTION;
> Query OK, 0 rows affected (0.00 sec)
> mysql> flush privileges;
> Query OK, 0 rows affected (0.00 sec)
> {code}
> and then try the Start again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16891) SSL support for Log Search Solr
[ https://issues.apache.org/jira/browse/AMBARI-16891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivér Szabó updated AMBARI-16891: -- Resolution: Fixed Status: Resolved (was: Patch Available) > SSL support for Log Search Solr > --- > > Key: AMBARI-16891 > URL: https://issues.apache.org/jira/browse/AMBARI-16891 > Project: Ambari > Issue Type: Improvement > Components: ambari-logsearch >Affects Versions: 2.4.0 >Reporter: Miklos Gergely >Assignee: Miklos Gergely > Fix For: 2.4.0 > > Attachments: AMBARI-16891.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16941) Cluster install wizard hangs and cannot proceed if Knox is the only service selected for install
[ https://issues.apache.org/jira/browse/AMBARI-16941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-16941: - Fix Version/s: 2.4.0 > Cluster install wizard hangs and cannot proceed if Knox is the only service > selected for install > > > Key: AMBARI-16941 > URL: https://issues.apache.org/jira/browse/AMBARI-16941 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: trunk, 2.4.0 >Reporter: Sangeeta Ravindran >Assignee: Sangeeta Ravindran > Fix For: 2.4.0 > > Attachments: AMBARI-16941.patch > > > 1. Open Cluster Install Wizard and select Knox as the only service to install. > 2. On step6 of the wizard (Assign Slaves and Clients), you cannot click on > Next and proceed because of an error in the javascript code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16950) "DISCARD" button doesn't work on HIVE INTERACTIVE page.
[
https://issues.apache.org/jira/browse/AMBARI-16950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306513#comment-15306513
]
Aleksandr Kovalenko commented on AMBARI-16950:
--
+1 for the patch
> "DISCARD" button doesn't work on HIVE INTERACTIVE page.
> ---
>
> Key: AMBARI-16950
> URL: https://issues.apache.org/jira/browse/AMBARI-16950
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-16950.patch, Screen Shot 2016-05-25 at 2.56.13
> PM.png, Screen Shot 2016-05-25 at 3.05.37 PM.png
>
>
> - Starting from this page. !Screen Shot 2016-05-25 at 2.56.13
> PM.png|thumbnail! , lets says if we modify any slider. Then instead of SAVE,
> lets click SUMMARY on top, to move away from this page. This dialog will
> show up. !Screen Shot 2016-05-25 at 3.05.37 PM.png|thumbnail! . Here,
> 'Discard' button wont work.
> {code}
> Ambari-2.4.0.0
> # ambari-server --hash
> 008c8219678493888bb8e0daee7beb668e7517e5
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16891) SSL support for Log Search Solr
[ https://issues.apache.org/jira/browse/AMBARI-16891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miklos Gergely updated AMBARI-16891: Description: This modification allows the operator to set up SSL connection between the clients ( Log Search Server, Log Feeders ) and the Solr server. The operator may specify the location of the trust stores and the key stores ( and also their types and their passwords ), and it is also the operator's responsibility to ensure those trust stores and key stores, containing the appropriate certificates and keys. The operator must create a key store and a trust store file before the SSL is enabled on the Solr server host, and also on each client host, then set the location, type and password of these stores on the advanced configuration site of the Log Search service. The stores must be on the same path on each host with the Logfeeder component on it. The location of the stores can be set here on the Log Search / Configs / Advanced tab: Solr server: Advanced logsearch-solr-env Log Search server: Advanced logsearch-env Logfeeders: Advanced logfeeder-env > SSL support for Log Search Solr > --- > > Key: AMBARI-16891 > URL: https://issues.apache.org/jira/browse/AMBARI-16891 > Project: Ambari > Issue Type: Improvement > Components: ambari-logsearch >Affects Versions: 2.4.0 >Reporter: Miklos Gergely >Assignee: Miklos Gergely > Fix For: 2.4.0 > > Attachments: AMBARI-16891.patch > > > This modification allows the operator to set up SSL connection between the > clients ( Log Search Server, Log Feeders ) and the Solr server. The operator > may specify the location of the trust stores and the key stores ( and also > their types and their passwords ), and it is also the operator's > responsibility to ensure those trust stores and key stores, containing the > appropriate certificates and keys. > The operator must create a key store and a trust store file before the SSL is > enabled on the Solr server host, and also on each client host, then set the > location, type and password of these stores on the advanced configuration > site of the Log Search service. The stores must be on the same path on each > host with the Logfeeder component on it. The location of the stores can be > set here on the Log Search / Configs / Advanced tab: > Solr server: Advanced logsearch-solr-env > Log Search server: Advanced logsearch-env > Logfeeders: Advanced logfeeder-env -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16891) SSL support for Log Search Solr
[ https://issues.apache.org/jira/browse/AMBARI-16891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miklos Gergely updated AMBARI-16891: Description: This modification allows the operator to set up SSL connection between the clients ( Log Search Server, Log Feeders ) and the Solr server. The operator may specify the location of the trust stores and the key stores ( and also their types and their passwords ), and it is also the operator's responsibility to ensure those trust stores and key stores, containing the appropriate certificates and keys. The operator must create a key store and a trust store file before the SSL is enabled on the Solr server host, and also on each client host, then set the location, type and password of these stores on the advanced configuration site of the Log Search service. The stores must already contain the necessary certificatates, public and private keys before the SSL is turned on. The stores must be on the same path on each host with the Logfeeder component on it. The location of the stores can be set here on the Log Search / Configs / Advanced tab: Solr server: Advanced logsearch-solr-env Log Search server: Advanced logsearch-env Logfeeders: Advanced logfeeder-env was: This modification allows the operator to set up SSL connection between the clients ( Log Search Server, Log Feeders ) and the Solr server. The operator may specify the location of the trust stores and the key stores ( and also their types and their passwords ), and it is also the operator's responsibility to ensure those trust stores and key stores, containing the appropriate certificates and keys. The operator must create a key store and a trust store file before the SSL is enabled on the Solr server host, and also on each client host, then set the location, type and password of these stores on the advanced configuration site of the Log Search service. The stores must be on the same path on each host with the Logfeeder component on it. The location of the stores can be set here on the Log Search / Configs / Advanced tab: Solr server: Advanced logsearch-solr-env Log Search server: Advanced logsearch-env Logfeeders: Advanced logfeeder-env > SSL support for Log Search Solr > --- > > Key: AMBARI-16891 > URL: https://issues.apache.org/jira/browse/AMBARI-16891 > Project: Ambari > Issue Type: Improvement > Components: ambari-logsearch >Affects Versions: 2.4.0 >Reporter: Miklos Gergely >Assignee: Miklos Gergely > Fix For: 2.4.0 > > Attachments: AMBARI-16891.patch > > > This modification allows the operator to set up SSL connection between the > clients ( Log Search Server, Log Feeders ) and the Solr server. The operator > may specify the location of the trust stores and the key stores ( and also > their types and their passwords ), and it is also the operator's > responsibility to ensure those trust stores and key stores, containing the > appropriate certificates and keys. > The operator must create a key store and a trust store file before the SSL is > enabled on the Solr server host, and also on each client host, then set the > location, type and password of these stores on the advanced configuration > site of the Log Search service. The stores must already contain the necessary > certificatates, public and private keys before the SSL is turned on. The > stores must be on the same path on each host with the Logfeeder component on > it. The location of the stores can be set here on the Log Search / Configs / > Advanced tab: > Solr server: Advanced logsearch-solr-env > Log Search server: Advanced logsearch-env > Logfeeders: Advanced logfeeder-env -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16922) Remove LogSearch dependency for Ranger
[ https://issues.apache.org/jira/browse/AMBARI-16922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306546#comment-15306546 ] Hudson commented on AMBARI-16922: - FAILURE: Integrated in Ambari-trunk-Commit #4957 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4957/]) AMBARI-16922. Remove LogSearch dependency for Ranger - Fix variable name (gautam: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=8e835618b7ca2318f12b0aee9e1e73dd92b4feb0]) * ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py > Remove LogSearch dependency for Ranger > -- > > Key: AMBARI-16922 > URL: https://issues.apache.org/jira/browse/AMBARI-16922 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Mugdha Varadkar >Assignee: Mugdha Varadkar >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16922.1.patch, AMBARI-16922.patch > > > Remove LogSearch dependency for Ranger -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16875) LDAP sync cannot handle if the member attribute value is not DN or id
[ https://issues.apache.org/jira/browse/AMBARI-16875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306543#comment-15306543 ] Hudson commented on AMBARI-16875: - FAILURE: Integrated in Ambari-trunk-Commit #4957 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4957/]) AMBARI-16875. LDAP sync cannot handle if the member attribute value is (oleewere: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=d581b4e552ad47d3dc9e96ed9919e87d5ae9babe]) * ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java * ambari-server/src/main/java/org/apache/ambari/server/security/authorization/LdapServerProperties.java * ambari-server/src/main/java/org/apache/ambari/server/security/ldap/AmbariLdapDataPopulator.java * ambari-server/src/test/java/org/apache/ambari/server/security/ldap/AmbariLdapDataPopulatorTest.java > LDAP sync cannot handle if the member attribute value is not DN or id > - > > Key: AMBARI-16875 > URL: https://issues.apache.org/jira/browse/AMBARI-16875 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Olivér Szabó >Assignee: Olivér Szabó >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16875.patch > > > in case of member attribute value looks like this: >
[jira] [Commented] (AMBARI-16930) Message text is missing in EU wizard screens that require manual intervention
[ https://issues.apache.org/jira/browse/AMBARI-16930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306542#comment-15306542 ] Hudson commented on AMBARI-16930: - FAILURE: Integrated in Ambari-trunk-Commit #4957 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4957/]) AMBARI-16930 Message text is missing in EU wizard screens that require (ababiichuk: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=17f764c00c56c0e2ad12eb18ddb4af09511acbd7]) * ambari-web/app/controllers/main/admin/stack_and_upgrade_controller.js > Message text is missing in EU wizard screens that require manual intervention > - > > Key: AMBARI-16930 > URL: https://issues.apache.org/jira/browse/AMBARI-16930 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16930.patch > > > *Steps* > # Install HDP 2.4.2.0 with Ambari 2.4.0.0 > # Start EU to 2.5.0.0 > Observed that in some of the screens that require manual intervention, the > message text is missing in the upper pane. This usually happens after hitting > 'Proceed' in the first message under an Upgrade Group. Subsequent messages do > not show up the text > Screenshots attached -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16901) Add Service wizard: All kerberos related configurations shown on Configure Identities page should be made non-editable on configure services page
[ https://issues.apache.org/jira/browse/AMBARI-16901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306545#comment-15306545 ] Hudson commented on AMBARI-16901: - FAILURE: Integrated in Ambari-trunk-Commit #4957 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4957/]) AMBARI-16901 Add Service wizard: All kerberos related configurations (ababiichuk: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=853a0ec9d09cc7083dcfaa2a10d9512483fcba11]) * ambari-web/app/messages.js * ambari-web/app/controllers/wizard/step7_controller.js * ambari-web/app/controllers/main/service/info/configs.js * ambari-web/app/utils/config.js * ambari-web/app/mixins/wizard/addSecurityConfigs.js * ambari-web/test/utils/config_test.js * ambari-web/test/controllers/wizard/step7_test.js * ambari-web/app/models/configs/objects/service_config_property.js > Add Service wizard: All kerberos related configurations shown on Configure > Identities page should be made non-editable on configure services page > - > > Key: AMBARI-16901 > URL: https://issues.apache.org/jira/browse/AMBARI-16901 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.0.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16901.patch > > > If following conditions are met then config should be made non-editable on > configure->services page: > Cluster is kerberized > Kerberos is ambari managed meaning not manual > Config is stated as an identity in the kerberos descriptor posted to the > cluster (api/v1/clusters/c1/artifacts/kerberos_descriptor). Note that config > has to be an identity to be made non-editable. Note: Other configs mentioned > in the kerberos descriptor should not be made non-editable. Only configs > stated under identities array should be made non-editable. > Configs made non-editable due to satisfying above condition should have their > description appended with the text that "This config can be changed from > Kerberos page under Admin tab by privileged users." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16948) Not able to save custom config in view config
[
https://issues.apache.org/jira/browse/AMBARI-16948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306563#comment-15306563
]
Hadoop QA commented on AMBARI-16948:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12806953/AMBARI-16948_branch-2.4.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
ambari-server:
org.apache.ambari.server.controller.internal.HostResourceProviderTest
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7055//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7055//console
This message is automatically generated.
> Not able to save custom config in view config
> -
>
> Key: AMBARI-16948
> URL: https://issues.apache.org/jira/browse/AMBARI-16948
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.4.0
>Reporter: Gaurav Nagar
>Assignee: Gaurav Nagar
> Fix For: 2.4.0
>
> Attachments: AMBARI-16948_branch-2.4.patch
>
>
> While creating/updating the existing view instance, custom section is not
> able the value.
> Steps:
> 1. Open existing File view instance.
> 2. Change cluster from Local to Custom.
> 3. Set value in WebHDFS FileSystem URI.
> There is error thrown in saving the config.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16951) Update Log Search SOLR version to 5.5.1
[ https://issues.apache.org/jira/browse/AMBARI-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivér Szabó updated AMBARI-16951: -- Attachment: AMBARI-16951.patch > Update Log Search SOLR version to 5.5.1 > --- > > Key: AMBARI-16951 > URL: https://issues.apache.org/jira/browse/AMBARI-16951 > Project: Ambari > Issue Type: Bug > Components: ambari-logsearch >Affects Versions: 2.4.0 >Reporter: Olivér Szabó >Assignee: Olivér Szabó > Fix For: 2.4.0 > > Attachments: AMBARI-16951.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16922) Remove LogSearch dependency for Ranger
[ https://issues.apache.org/jira/browse/AMBARI-16922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mugdha Varadkar updated AMBARI-16922: - Resolution: Fixed Status: Resolved (was: Patch Available) [^AMBARI-16922.1.patch] committed to [trunk|https://github.com/apache/ambari/commit/8e835618b7ca2318f12b0aee9e1e73dd92b4feb0] and [branch-2.4|https://github.com/apache/ambari/commit/dea950c9e0e4b346ff1ee99e35069176b58d7e6a] > Remove LogSearch dependency for Ranger > -- > > Key: AMBARI-16922 > URL: https://issues.apache.org/jira/browse/AMBARI-16922 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Mugdha Varadkar >Assignee: Mugdha Varadkar >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16922.1.patch, AMBARI-16922.patch > > > Remove LogSearch dependency for Ranger -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16949) Metrics Collector API shows NPE if we use wildcard (%25 for '%') for metric name
Jungtaek Lim created AMBARI-16949:
-
Summary: Metrics Collector API shows NPE if we use wildcard (%25
for '%') for metric name
Key: AMBARI-16949
URL: https://issues.apache.org/jira/browse/AMBARI-16949
Project: Ambari
Issue Type: Bug
Components: ambari-metrics
Affects Versions: 2.4.0
Reporter: Jungtaek Lim
When we request '/ws/v1/timeline/metrics' with metric name which contains %25
(escaped '%'), response for the API is json describing there's NPE.
And NPE is logged for ambari-metrics-collector log file.
{code}
2016-05-30 09:15:05,061 WARN
org.apache.hadoop.yarn.webapp.GenericExceptionHandler: INTERNAL_SERVER_ERROR
java.lang.NullPointerException
at
org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.PhoenixHBaseAccessor.appendAggregateMetricFromResultSet(PhoenixHBaseAccessor.java:810)
at
org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.PhoenixHBaseAccessor.getAggregateMetricRecords(PhoenixHBaseAccessor.java:772)
at
org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.HBaseTimelineMetricStore.getTimelineMetrics(HBaseTimelineMetricStore.java:178)
at
org.apache.hadoop.yarn.server.applicationhistoryservice.webapp.TimelineWebServices.getTimelineMetrics(TimelineWebServices.java:372)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16950) "DISCARD" button doesn't work on HIVE INTERACTIVE page.
[
https://issues.apache.org/jira/browse/AMBARI-16950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306512#comment-15306512
]
Antonenko Alexander commented on AMBARI-16950:
--
27858 tests complete (26 seconds)
154 tests pending
rat check passed
> "DISCARD" button doesn't work on HIVE INTERACTIVE page.
> ---
>
> Key: AMBARI-16950
> URL: https://issues.apache.org/jira/browse/AMBARI-16950
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-16950.patch, Screen Shot 2016-05-25 at 2.56.13
> PM.png, Screen Shot 2016-05-25 at 3.05.37 PM.png
>
>
> - Starting from this page. !Screen Shot 2016-05-25 at 2.56.13
> PM.png|thumbnail! , lets says if we modify any slider. Then instead of SAVE,
> lets click SUMMARY on top, to move away from this page. This dialog will
> show up. !Screen Shot 2016-05-25 at 3.05.37 PM.png|thumbnail! . Here,
> 'Discard' button wont work.
> {code}
> Ambari-2.4.0.0
> # ambari-server --hash
> 008c8219678493888bb8e0daee7beb668e7517e5
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-16951) Update Log Search SOLR version to 5.5.1
Olivér Szabó created AMBARI-16951: - Summary: Update Log Search SOLR version to 5.5.1 Key: AMBARI-16951 URL: https://issues.apache.org/jira/browse/AMBARI-16951 Project: Ambari Issue Type: Bug Components: ambari-logsearch Affects Versions: 2.4.0 Reporter: Olivér Szabó Assignee: Olivér Szabó Fix For: 2.4.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16950) "DISCARD" button doesn't work on HIVE INTERACTIVE page.
[
https://issues.apache.org/jira/browse/AMBARI-16950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonenko Alexander updated AMBARI-16950:
-
Status: Patch Available (was: Open)
> "DISCARD" button doesn't work on HIVE INTERACTIVE page.
> ---
>
> Key: AMBARI-16950
> URL: https://issues.apache.org/jira/browse/AMBARI-16950
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-16950.patch, Screen Shot 2016-05-25 at 2.56.13
> PM.png, Screen Shot 2016-05-25 at 3.05.37 PM.png
>
>
> - Starting from this page. !Screen Shot 2016-05-25 at 2.56.13
> PM.png|thumbnail! , lets says if we modify any slider. Then instead of SAVE,
> lets click SUMMARY on top, to move away from this page. This dialog will
> show up. !Screen Shot 2016-05-25 at 3.05.37 PM.png|thumbnail! . Here,
> 'Discard' button wont work.
> {code}
> Ambari-2.4.0.0
> # ambari-server --hash
> 008c8219678493888bb8e0daee7beb668e7517e5
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16891) SSL support for Log Search Solr
[
https://issues.apache.org/jira/browse/AMBARI-16891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306479#comment-15306479
]
Olivér Szabó commented on AMBARI-16891:
---
committed to trunk:
{code:java}
commit 9b8ca7e9fe3f8afbadf0cf61b071218e39eb2e3f
Author: Miklos Gergely
Date: Mon May 30 11:31:17 2016 +0200
AMBARI-16891. SSL support for Log Search Solr (Miklos Gergely via oleewere)
{code}
> SSL support for Log Search Solr
> ---
>
> Key: AMBARI-16891
> URL: https://issues.apache.org/jira/browse/AMBARI-16891
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-logsearch
>Affects Versions: 2.4.0
>Reporter: Miklos Gergely
>Assignee: Miklos Gergely
> Fix For: 2.4.0
>
> Attachments: AMBARI-16891.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16736) Kerberos support for LogSearch Solr
[ https://issues.apache.org/jira/browse/AMBARI-16736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivér Szabó updated AMBARI-16736: -- Component/s: ambari-server ambari-logsearch > Kerberos support for LogSearch Solr > --- > > Key: AMBARI-16736 > URL: https://issues.apache.org/jira/browse/AMBARI-16736 > Project: Ambari > Issue Type: Bug > Components: ambari-logsearch, ambari-server >Affects Versions: 2.4.0 >Reporter: Olivér Szabó >Assignee: Olivér Szabó > Fix For: 2.4.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16952) Provide context for hdp-select failures during ambari component install
Laszlo Puskas created AMBARI-16952: -- Summary: Provide context for hdp-select failures during ambari component install Key: AMBARI-16952 URL: https://issues.apache.org/jira/browse/AMBARI-16952 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.2.1.1 Reporter: Laszlo Puskas Assignee: Laszlo Puskas Fix For: 2.4.0 In case hdp-select command fails during a service / component installation fails there's no contextual information about the cause of the failure. This issue is for logging information about the machine on which the hdp-select command fails. This solution wraps hdp-select command calls in a try/catch block and logs failure / hdp installationrelated information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16955) Allow setting log level, and java opts for hive interactive/llap
[ https://issues.apache.org/jira/browse/AMBARI-16955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Lysnichenko updated AMBARI-16955: Resolution: Fixed Status: Resolved (was: Patch Available) Committed a4b2285..f77b415 branch-2.4 -> branch-2.4 0926cdc..a79c98d trunk -> trunk > Allow setting log level, and java opts for hive interactive/llap > > > Key: AMBARI-16955 > URL: https://issues.apache.org/jira/browse/AMBARI-16955 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko > Fix For: 2.4.0 > > Attachments: AMBARI-16955.patch > > > Users should be able to control the log level for the daemons, and java args > for the daemon. > Both of these are likely to be text input boxes, which feed into hive > --service llap. There's no explicit ocnfiguration in hive-site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16953) Service name shown instead of Host name on popup
[ https://issues.apache.org/jira/browse/AMBARI-16953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Lysnichenko updated AMBARI-16953: Status: Patch Available (was: Open) > Service name shown instead of Host name on popup > > > Key: AMBARI-16953 > URL: https://issues.apache.org/jira/browse/AMBARI-16953 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko > Attachments: AMBARI-16953.patch > > > STR: > # Deploy ambari with HDP2.2 > # Register and install HDP2.5 > # Click "Upgrade" > # Look at the Rolling Upgrade checks > Result: Service name SECONDARY_NAMENODE shown instead of Host name on popup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16953) Service name shown instead of Host name on popup
[ https://issues.apache.org/jira/browse/AMBARI-16953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Lysnichenko updated AMBARI-16953: Component/s: ambari-server > Service name shown instead of Host name on popup > > > Key: AMBARI-16953 > URL: https://issues.apache.org/jira/browse/AMBARI-16953 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko > Attachments: AMBARI-16953.patch > > > STR: > # Deploy ambari with HDP2.2 > # Register and install HDP2.5 > # Click "Upgrade" > # Look at the Rolling Upgrade checks > Result: Service name SECONDARY_NAMENODE shown instead of Host name on popup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16953) Service name shown instead of Host name on popup
Dmitry Lysnichenko created AMBARI-16953: --- Summary: Service name shown instead of Host name on popup Key: AMBARI-16953 URL: https://issues.apache.org/jira/browse/AMBARI-16953 Project: Ambari Issue Type: Bug Reporter: Dmitry Lysnichenko Assignee: Dmitry Lysnichenko Attachments: AMBARI-16953.patch STR: # Deploy ambari with HDP2.2 # Register and install HDP2.5 # Click "Upgrade" # Look at the Rolling Upgrade checks Result: Service name SECONDARY_NAMENODE shown instead of Host name on popup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16953) Service name shown instead of Host name on popup
[ https://issues.apache.org/jira/browse/AMBARI-16953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Lysnichenko updated AMBARI-16953: Attachment: AMBARI-16953.patch > Service name shown instead of Host name on popup > > > Key: AMBARI-16953 > URL: https://issues.apache.org/jira/browse/AMBARI-16953 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko > Attachments: AMBARI-16953.patch > > > STR: > # Deploy ambari with HDP2.2 > # Register and install HDP2.5 > # Click "Upgrade" > # Look at the Rolling Upgrade checks > Result: Service name SECONDARY_NAMENODE shown instead of Host name on popup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16957) Zeppelin views : UI broken when service is not running
[ https://issues.apache.org/jira/browse/AMBARI-16957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Renjith Kamath updated AMBARI-16957: Fix Version/s: 2.4.0 Affects Version/s: 2.4.0 Status: Patch Available (was: Open) > Zeppelin views : UI broken when service is not running > -- > > Key: AMBARI-16957 > URL: https://issues.apache.org/jira/browse/AMBARI-16957 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Renjith Kamath > Fix For: 2.4.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16952) Provide context for hdp-select failures during ambari component install
[ https://issues.apache.org/jira/browse/AMBARI-16952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laszlo Puskas updated AMBARI-16952: --- Description: In case the *hdp-select* command fails during a service / component installation there's no contextual information about the cause of the failure. This issue is for logging information about the machine on which the hdp-select command fails. This solution wraps hdp-select command calls in a try/catch block and logs failure / hdp installationrelated information. was: In case the *hdp-select* command fails during a service / component installation fails there's no contextual information about the cause of the failure. This issue is for logging information about the machine on which the hdp-select command fails. This solution wraps hdp-select command calls in a try/catch block and logs failure / hdp installationrelated information. > Provide context for hdp-select failures during ambari component install > > > Key: AMBARI-16952 > URL: https://issues.apache.org/jira/browse/AMBARI-16952 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.1.1 >Reporter: Laszlo Puskas >Assignee: Laszlo Puskas > Labels: ambari > Fix For: 2.4.0 > > Original Estimate: 24h > Remaining Estimate: 24h > > In case the *hdp-select* command fails during a service / component > installation there's no contextual information about the cause of the failure. > This issue is for logging information about the machine on which the > hdp-select command fails. > This solution wraps hdp-select command calls in a try/catch block and logs > failure / hdp installationrelated information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16952) Provide context for hdp-select failures during ambari component install
[ https://issues.apache.org/jira/browse/AMBARI-16952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laszlo Puskas updated AMBARI-16952: --- Description: In case the *hdp-select* command fails during a service / component installation fails there's no contextual information about the cause of the failure. This issue is for logging information about the machine on which the hdp-select command fails. This solution wraps hdp-select command calls in a try/catch block and logs failure / hdp installationrelated information. was: In case hdp-select command fails during a service / component installation fails there's no contextual information about the cause of the failure. This issue is for logging information about the machine on which the hdp-select command fails. This solution wraps hdp-select command calls in a try/catch block and logs failure / hdp installationrelated information. > Provide context for hdp-select failures during ambari component install > > > Key: AMBARI-16952 > URL: https://issues.apache.org/jira/browse/AMBARI-16952 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.1.1 >Reporter: Laszlo Puskas >Assignee: Laszlo Puskas > Labels: ambari > Fix For: 2.4.0 > > Original Estimate: 24h > Remaining Estimate: 24h > > In case the *hdp-select* command fails during a service / component > installation fails there's no contextual information about the cause of the > failure. > This issue is for logging information about the machine on which the > hdp-select command fails. > This solution wraps hdp-select command calls in a try/catch block and logs > failure / hdp installationrelated information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16952) Provide context for hdp-select failures during ambari component install
[ https://issues.apache.org/jira/browse/AMBARI-16952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laszlo Puskas updated AMBARI-16952: --- Status: Patch Available (was: In Progress) > Provide context for hdp-select failures during ambari component install > > > Key: AMBARI-16952 > URL: https://issues.apache.org/jira/browse/AMBARI-16952 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.1.1 >Reporter: Laszlo Puskas >Assignee: Laszlo Puskas > Labels: ambari > Fix For: 2.4.0 > > Original Estimate: 24h > Remaining Estimate: 24h > > In case the *hdp-select* command fails during a service / component > installation there's no contextual information about the cause of the failure. > This issue is for logging information about the machine on which the > hdp-select command fails. > This solution wraps hdp-select command calls in a try/catch block and logs > failure / hdp installationrelated information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16957) Zeppelin Ambari view : UI broken when service is not running
[
https://issues.apache.org/jira/browse/AMBARI-16957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306726#comment-15306726
]
Hadoop QA commented on AMBARI-16957:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12806980/AMBARI-16957-trunk%2B2.4-v2.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
contrib/views/zeppelin.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7057//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7057//console
This message is automatically generated.
> Zeppelin Ambari view : UI broken when service is not running
>
>
> Key: AMBARI-16957
> URL: https://issues.apache.org/jira/browse/AMBARI-16957
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Renjith Kamath
> Fix For: 2.4.0
>
> Attachments: AMBARI-16957-trunk+2.4-v2.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16953) Service name shown instead of Host name on popup
[ https://issues.apache.org/jira/browse/AMBARI-16953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Lysnichenko updated AMBARI-16953: Affects Version/s: 2.4.0 > Service name shown instead of Host name on popup > > > Key: AMBARI-16953 > URL: https://issues.apache.org/jira/browse/AMBARI-16953 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko > Fix For: 2.4.0 > > Attachments: AMBARI-16953.patch > > > STR: > # Deploy ambari with HDP2.2 > # Register and install HDP2.5 > # Click "Upgrade" > # Look at the Rolling Upgrade checks > Result: Service name SECONDARY_NAMENODE shown instead of Host name on popup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16954) SERVICE_CHECK Upgrade pre-check does not throw error when its expected to
[
https://issues.apache.org/jira/browse/AMBARI-16954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Lysnichenko updated AMBARI-16954:
Status: Patch Available (was: Open)
> SERVICE_CHECK Upgrade pre-check does not throw error when its expected to
> -
>
> Key: AMBARI-16954
> URL: https://issues.apache.org/jira/browse/AMBARI-16954
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Attachments: AMBARI-16954.patch
>
>
> *Steps*
> # Deploy HDP-2.4.0.0 cluster with Ambari 2.2.2
> # Upgrade Ambari to 2.4.0.0
> # Register HDP-2.5.0.0 version and install the bits
> # Modify configs for some of the service like HDFS, ZK, YARN
> # Start EU
> *Result*:
> EU pre-check does *not* report below error for the three services whose
> config was modified in step 4
> "The following service configurations have been updated and their Service
> Checks should be run again:"
> Upon further investigation found that the pre-check does not work if a
> service check has never been run for a service at all AND reports success in
> such cases
> In other words, the comparison between last config modification time and last
> service check time succeeds if service check never ran at all and the output
> of below query returns empty:
> {code}
> SELECT start_time FROM host_role_command where role = 'HDFS_SERVICE_CHECK'
> AND status = 'COMPLETED' ORDER BY start_time DESC;
> {code}
> In this case when I manually ran a service check for HDFS and retried EU, the
> pre-check caught the mismatch and reported error
> *Note*: I believe we do run service check as part of cluster install, but
> looks like it does not get updated in the DB tables for all services.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16954) SERVICE_CHECK Upgrade pre-check does not throw error when its expected to
[
https://issues.apache.org/jira/browse/AMBARI-16954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Lysnichenko updated AMBARI-16954:
Attachment: AMBARI-16954.patch
> SERVICE_CHECK Upgrade pre-check does not throw error when its expected to
> -
>
> Key: AMBARI-16954
> URL: https://issues.apache.org/jira/browse/AMBARI-16954
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Attachments: AMBARI-16954.patch
>
>
> *Steps*
> # Deploy HDP-2.4.0.0 cluster with Ambari 2.2.2
> # Upgrade Ambari to 2.4.0.0
> # Register HDP-2.5.0.0 version and install the bits
> # Modify configs for some of the service like HDFS, ZK, YARN
> # Start EU
> *Result*:
> EU pre-check does *not* report below error for the three services whose
> config was modified in step 4
> "The following service configurations have been updated and their Service
> Checks should be run again:"
> Upon further investigation found that the pre-check does not work if a
> service check has never been run for a service at all AND reports success in
> such cases
> In other words, the comparison between last config modification time and last
> service check time succeeds if service check never ran at all and the output
> of below query returns empty:
> {code}
> SELECT start_time FROM host_role_command where role = 'HDFS_SERVICE_CHECK'
> AND status = 'COMPLETED' ORDER BY start_time DESC;
> {code}
> In this case when I manually ran a service check for HDFS and retried EU, the
> pre-check caught the mismatch and reported error
> *Note*: I believe we do run service check as part of cluster install, but
> looks like it does not get updated in the DB tables for all services.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-16954) SERVICE_CHECK Upgrade pre-check does not throw error when its expected to
Dmitry Lysnichenko created AMBARI-16954:
---
Summary: SERVICE_CHECK Upgrade pre-check does not throw error when
its expected to
Key: AMBARI-16954
URL: https://issues.apache.org/jira/browse/AMBARI-16954
Project: Ambari
Issue Type: Bug
Reporter: Dmitry Lysnichenko
Assignee: Dmitry Lysnichenko
Attachments: AMBARI-16954.patch
*Steps*
# Deploy HDP-2.4.0.0 cluster with Ambari 2.2.2
# Upgrade Ambari to 2.4.0.0
# Register HDP-2.5.0.0 version and install the bits
# Modify configs for some of the service like HDFS, ZK, YARN
# Start EU
*Result*:
EU pre-check does *not* report below error for the three services whose config
was modified in step 4
"The following service configurations have been updated and their Service
Checks should be run again:"
Upon further investigation found that the pre-check does not work if a service
check has never been run for a service at all AND reports success in such cases
In other words, the comparison between last config modification time and last
service check time succeeds if service check never ran at all and the output of
below query returns empty:
{code}
SELECT start_time FROM host_role_command where role = 'HDFS_SERVICE_CHECK' AND
status = 'COMPLETED' ORDER BY start_time DESC;
{code}
In this case when I manually ran a service check for HDFS and retried EU, the
pre-check caught the mismatch and reported error
*Note*: I believe we do run service check as part of cluster install, but looks
like it does not get updated in the DB tables for all services.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16955) Allow setting log level, and java opts for hive interactive/llap
[ https://issues.apache.org/jira/browse/AMBARI-16955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Lysnichenko updated AMBARI-16955: Affects Version/s: 2.4.0 > Allow setting log level, and java opts for hive interactive/llap > > > Key: AMBARI-16955 > URL: https://issues.apache.org/jira/browse/AMBARI-16955 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko > Fix For: 2.4.0 > > Attachments: AMBARI-16955.patch > > > Users should be able to control the log level for the daemons, and java args > for the daemon. > Both of these are likely to be text input boxes, which feed into hive > --service llap. There's no explicit ocnfiguration in hive-site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16955) Allow setting log level, and java opts for hive interactive/llap
[ https://issues.apache.org/jira/browse/AMBARI-16955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Lysnichenko updated AMBARI-16955: Fix Version/s: 2.4.0 > Allow setting log level, and java opts for hive interactive/llap > > > Key: AMBARI-16955 > URL: https://issues.apache.org/jira/browse/AMBARI-16955 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko > Fix For: 2.4.0 > > Attachments: AMBARI-16955.patch > > > Users should be able to control the log level for the daemons, and java args > for the daemon. > Both of these are likely to be text input boxes, which feed into hive > --service llap. There's no explicit ocnfiguration in hive-site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16955) Allow setting log level, and java opts for hive interactive/llap
[ https://issues.apache.org/jira/browse/AMBARI-16955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Lysnichenko updated AMBARI-16955: Component/s: ambari-server > Allow setting log level, and java opts for hive interactive/llap > > > Key: AMBARI-16955 > URL: https://issues.apache.org/jira/browse/AMBARI-16955 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko > Attachments: AMBARI-16955.patch > > > Users should be able to control the log level for the daemons, and java args > for the daemon. > Both of these are likely to be text input boxes, which feed into hive > --service llap. There's no explicit ocnfiguration in hive-site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16955) Allow setting log level, and java opts for hive interactive/llap
[ https://issues.apache.org/jira/browse/AMBARI-16955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Lysnichenko updated AMBARI-16955: Status: Patch Available (was: Open) > Allow setting log level, and java opts for hive interactive/llap > > > Key: AMBARI-16955 > URL: https://issues.apache.org/jira/browse/AMBARI-16955 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko > Attachments: AMBARI-16955.patch > > > Users should be able to control the log level for the daemons, and java args > for the daemon. > Both of these are likely to be text input boxes, which feed into hive > --service llap. There's no explicit ocnfiguration in hive-site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16957) Zeppelin views : UI broken when service is not running
[ https://issues.apache.org/jira/browse/AMBARI-16957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Renjith Kamath updated AMBARI-16957: Attachment: AMBARI-16957-trunk+2.4-v2.patch > Zeppelin views : UI broken when service is not running > -- > > Key: AMBARI-16957 > URL: https://issues.apache.org/jira/browse/AMBARI-16957 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Renjith Kamath > Fix For: 2.4.0 > > Attachments: AMBARI-16957-trunk+2.4-v2.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16957) Zeppelin Ambari view : UI broken when service is not running
[ https://issues.apache.org/jira/browse/AMBARI-16957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Renjith Kamath updated AMBARI-16957: Summary: Zeppelin Ambari view : UI broken when service is not running (was: Zeppelin views : UI broken when service is not running) > Zeppelin Ambari view : UI broken when service is not running > > > Key: AMBARI-16957 > URL: https://issues.apache.org/jira/browse/AMBARI-16957 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Renjith Kamath > Fix For: 2.4.0 > > Attachments: AMBARI-16957-trunk+2.4-v2.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16939) 'ambari-server upgrade' is failed : Error executing schema upgrade [upgrade from 2200 to 2400]
[
https://issues.apache.org/jira/browse/AMBARI-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balázs Bence Sári updated AMBARI-16939:
---
Attachment: patch2-24.diff
Patch for 2.4 branch
> 'ambari-server upgrade' is failed : Error executing schema upgrade [upgrade
> from 2200 to 2400]
> --
>
> Key: AMBARI-16939
> URL: https://issues.apache.org/jira/browse/AMBARI-16939
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Balázs Bence Sári
>Assignee: Balázs Bence Sári
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: patch2-24.diff, patch2-trunk.diff
>
>
> STR:
> 1) Install old version
> 2) Try to Make ambari only upgrade
> Cluster: 172.22.123.240
> All logs:
> http://qelog.hortonworks.com/log/os-u14-xvenls-upg-sanity-u-2200/test-logs/ambari-upgrade-2.2.0.0/
> Actual result:
> 'ambari-server upgrade' is failed : Error executing schema upgrade [upgrade
> from 2200 to 2400]
> {code}
> 2016-05-19 04:50:31,348 INFO
> com.hw.ambari.ui.util.cluster_managers.CommandExecutor.executeCommandSequence():
> Sending command []
> 2016-05-19 04:50:31,950 DEBUG
> com.hw.ambari.ui.util.cluster_managers.ProcessData.buildOutputAndErrorStreamData():
> stdin: is not a tty
> 2016-05-19 04:50:49,791 INFO
> com.hw.ambari.ui.util.cluster_managers.CommandExecutor.executeCommandSequence():
> [OUTPUT STREAM]
> Using python /usr/bin/python
> Upgrading ambari-server
> Updating properties in ambari.properties ...
> WARNING: Original file ambari-env.sh kept
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: No mpack replay logs found. Skipping replaying mpack commands
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> Fixing database objects owner
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> Ambari Server configured for MySQL. Confirm you have made a backup of the
> Ambari Server database [y/n] (y)? INFO: Loading properties from
> /etc/ambari-server/conf/ambari.properties
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> Upgrading database schema
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: AMBARI_SERVER_LIB is not set, using default /usr/lib/ambari-server
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: about to run command: /usr/lib/jvm/java-7-openjdk-amd64/bin/java -cp
> '/etc/ambari-server/conf:/usr/lib/ambari-server/*:/usr/share/java/mysql-connector-java.jar'
> org.apache.ambari.server.upgrade.SchemaUpgradeHelper >
> /var/log/ambari-server/ambari-server.out 2>&1
> INFO: Return code from schema upgrade command, retcode = 1
> Error output from schema upgrade command:
> Exception in thread "main" org.apache.ambari.server.AmbariException: Cannot
> add foreign key constraint
> at
> org.apache.ambari.server.upgrade.SchemaUpgradeHelper.executeUpgrade(SchemaUpgradeHelper.java:204)
> at
> org.apache.ambari.server.upgrade.SchemaUpgradeHelper.main(SchemaUpgradeHelper.java:302)
> Caused by: java.sql.SQLException: Cannot add foreign key constraint
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:959)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3870)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3806)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2470)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2617)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2546)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2504)
> at com.mysql.jdbc.StatementImpl.executeInternal(StatementImpl.java:840)
> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:740)
> at
> org.apache.ambari.server.orm.DBAccessorImpl.executeQuery(DBAccessorImpl.java:800)
> at
> org.apache.ambari.server.orm.DBAccessorImpl.addFKConstraint(DBAccessorImpl.java:470)
> at
> org.apache.ambari.server.orm.DBAccessorImpl.addFKConstraint(DBAccessorImpl.java:435)
> at
> org.apache.ambari.server.upgrade.UpgradeCatalog240.createServiceComponentHistoryTable(UpgradeCatalog240.java:1375)
> at
> org.apache.ambari.server.upgrade.UpgradeCatalog240.executeDDLUpdates(UpgradeCatalog240.java:239)
> at
>
[jira] [Updated] (AMBARI-14627) Ability to automate setup-security and setup-ldap/sync-ldap
[
https://issues.apache.org/jira/browse/AMBARI-14627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivér Szabó updated AMBARI-14627:
--
Description:
Currently the ambari-server setup-security command does not have any options
thus it's interactive. This makes it really hard to automate this process. For
kerberos 1 option should be enough for setting the master key.
Same for setup-ldap and sync-ldap
Example usage:
{code:java}
1.) LDAP setup:
ambari-server setup-ldap \
--ldap-url="ldap.apache.org389" \
--ldap-secondary-url="" \
--ldap-ssl="false" \
--ldap-user-class="person" \
--ldap-user-attr="sAMAccountName" \
--ldap-group-class="group" \
--ldap-group-attr="cn" \
--ldap-member-attr="member" \
--ldap-dn="distunguishedName" \
--ldap-base-dn="dc=ambari01,dc=local" \
--ldap-referral="" \
--ldap-bind-anonym=false \
--ldap-manager-dn="cn=hdfs,ou=ambari,dc=ambari01,dc=local" \
--ldap-manager-password="myldappassword" \
--ldap-save-settings \
--truststore-type="jks" \
--truststore-path="/var/lib/ambari-server/keys/jkskeystore.jks" \
--truststore-password="mypass"
2.) Ldap sync:
ambari-server sync-ldap --groups=groups.txt --ldap-sync-admin-name=admin
--ldap-sync-admin-password=admin
3.) Setup Https:
ambari-server setup-security \
--security-option=setup-https \
--api-ssl=true --client-api-ssl-port=8443 \
--import-cert-path=/var/lib/ambari-server/keys/my.crt \
--import-key-path=/var/lib/ambari-server/keys/my.key \
--pem-password=password
4.) Encrypt passwords:
ambari-server setup-security --security-option=encrypt-passwords
--master-key=masterkey --master-key-persist=true
5.) Setup Kerberos JAAS:
ambari-server setup-security --security-option=setup-kerberos-jaas
--jaas-principal="amb...@example.com"
--jaas-keytab="/etc/security/keytabs/ambari.keytab"
6.) Setup TrustStore:
ambari-server setup-security \
--security-option=setup-truststore \
--truststore-path=/var/lib/ambari-server/keys/keystore.p12 \
--truststore-type=pkcs12 \
--truststore-password=password \
--truststore-reconfigure
7.) Import certificate to TrustStore:
ambari-server setup-security \
--security-option=import-certificate \
--truststore-path=/var/lib/ambari-server/keys/keystore.p12 \
--truststore-type=pkcs12 \
--truststore-password=password \
--import-cert-path=/var/lib/ambari-server/my.crt \
--import-cert-alias=myalias \
--truststore-reconfigure
{code}
was:
Currently the ambari-server setup-security command does not have any options
thus it's interactive. This makes it really hard to automate this process. For
kerberos 1 option should be enough for setting the master key.
Same for setup-ldap and sync-ldap
Example usage:
{code:java}
1.) LDAP setup:
ambari-server setup-ldap \
--ldap-url="ldap.apache.org389" \
--ldap-secondary-url="" \
--ldap-ssl="false" \
--ldap-user-class="person" \
--ldap-user-attr="sAMAccountName" \
--ldap-group-class="group" \
--ldap-group-attr="cn" \
--ldap-member-attr="member" \
--ldap-dn="distunguishedName" \
--ldap-base-dn="dc=ambari01,dc=local" \
--ldap-referral="" \
--ldap-bind-anonym=false \
--ldap-manager-dn="cn=hdfs,ou=ambari,dc=ambari01,dc=local" \
--ldap-manager-password="myldappassword" \
--ldap-save-settings \
--truststore-type="jks" \
--truststore-path="/var/lib/ambari-server/keys/jkskeystore.jks" \
--truststore-password="mypass"
2.) Ldap sync:
ambari-server sync-ldap --groups=groups.txt --ldap-sync-admin-name=admin
--ldap-sync-admin-password=admin
3.) Setup Https:
ambari-server setup-security \
--security-option=setup-https \
--api-ssl=true --client-api-ssl-port=8443 \
--import-cert-path=/var/lib/ambari-server/keys/my.crt \
--import-key-path=/var/lib/ambari-server/keys/my.key \
--pem-password=password
4.) Encrypt passwords:
ambari-server setup-security --security-option=encrypt-password
--master-key=masterkey --master-key-persist=true
5.) Setup Kerberos JAAS:
ambari-server setup-security --security-option=setup-kerberos-jaas
--jaas-principal="amb...@example.com"
--jaas-keytab="/etc/security/keytabs/ambari.keytab"
6.) Setup TrustStore:
ambari-server setup-security \
--security-option=setup-truststore \
--truststore-path=/var/lib/ambari-server/keys/keystore.p12 \
--truststore-type=pkcs12 \
--truststore-password=password \
--truststore-reconfigure
7.) Import certificate to TrustStore:
ambari-server setup-security \
--security-option=import-certificate \
--truststore-path=/var/lib/ambari-server/keys/keystore.p12 \
--truststore-type=pkcs12 \
--truststore-password=password \
--import-cert-path=/var/lib/ambari-server/my.crt \
--import-cert-alias=myalias \
--truststore-reconfigure
{code}
> Ability to automate
[jira] [Commented] (AMBARI-16020) Hive Metastore install failed since mysql-server not installed
[
https://issues.apache.org/jira/browse/AMBARI-16020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306639#comment-15306639
]
Hudson commented on AMBARI-16020:
-
FAILURE: Integrated in Ambari-trunk-Commit #4958 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/4958/])
AMBARI-16020 Hive Metastore install failed since mysql-server not (atkach:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=38ad356227074686de80fe51b960cc6709ca12f3])
* ambari-web/app/controllers/wizard/step8_controller.js
* ambari-web/test/controllers/wizard/step8_test.js
* ambari-server/src/test/python/stacks/2.1/common/test_stack_advisor.py
* ambari-server/src/main/resources/stacks/HDP/2.1/services/stack_advisor.py
> Hive Metastore install failed since mysql-server not installed
> --
>
> Key: AMBARI-16020
> URL: https://issues.apache.org/jira/browse/AMBARI-16020
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16020.patch, AMBARI-16020_2.patch
>
>
> STR:
> * Install Ambari 2.4.0.0-4686 on 3 hosts
> * Install HDP 2.5.0.0-58 with Hive Server on 1 host and Hive Metastore on the
> other
> * Select option to install Hive with "New MySQL" database
> Failed installing Hive Metastore since MySQL service was not installed.
> {code}
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 293, in _call
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'export
> HIVE_CONF_DIR=/usr/hdp/current/hive-metastore/conf/conf.server ;
> /usr/hdp/current/hive-metastore/bin/schematool -initSchema -dbType mysql
> -userName hive -passWord [PROTECTED]' returned 1. WARNING: Use "yarn jar" to
> launch YARN applications.
> Metastore connection URL:
> jdbc:mysql://c6405.ambari.apache.org/hive?createDatabaseIfNotExist=true
> Metastore Connection Driver : com.mysql.jdbc.Driver
> Metastore connection User: hive
> org.apache.hadoop.hive.metastore.HiveMetaException: Failed to get schema
> version.
> *** schemaTool failed ***
> {code}
> I had to run this manually,
> {code}
> yum install mysql-server -y
> service mysqld start
> mysql -u root -p (password is empty string)
> mysql> CREATE USER 'hive'@'%' IDENTIFIED BY 'admin';
> Query OK, 0 rows affected (0.00 sec)
> mysql> GRANT ALL PRIVILEGES ON *.* TO 'hive'@'%';
> Query OK, 0 rows affected (0.00 sec)
> mysql> GRANT ALL PRIVILEGES ON *.* TO 'hive'@'localhost';
> Query OK, 0 rows affected (0.00 sec)
> mysql> GRANT ALL PRIVILEGES ON *.* TO 'hive'@'c6405.ambari.apache.org';
> Query OK, 0 rows affected (0.00 sec)
> mysql> GRANT ALL PRIVILEGES ON *.* TO 'hive'@'c6405.ambari.apache.org'
> IDENTIFIED BY 'admin' WITH GRANT OPTION;
> Query OK, 0 rows affected (0.00 sec)
> mysql> flush privileges;
> Query OK, 0 rows affected (0.00 sec)
> {code}
> and then try the Start again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16938) Deploy: UI: Hive_metastore not started
[
https://issues.apache.org/jira/browse/AMBARI-16938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306638#comment-15306638
]
Hudson commented on AMBARI-16938:
-
FAILURE: Integrated in Ambari-trunk-Commit #4958 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/4958/])
AMBARI-16938. Deploy: UI: Hive_metastore not started.(vbrodetskyi)
(vbrodetskyi:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=677302795a77c680c82933148b229a18bdc21316])
*
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hive_interactive.py
*
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hive.py
*
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
*
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hive_metastore.py
> Deploy: UI: Hive_metastore not started
> --
>
> Key: AMBARI-16938
> URL: https://issues.apache.org/jira/browse/AMBARI-16938
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-16938.patch
>
>
> Deploy ambari cluster using UI with hive for existing mysql setup
> Actual: Hive metastore is failing to start due to unable to connect to DB.
> 2016-05-26 00:20:15,442 - Execute['/usr/jdk64/jdk1.8.0_77/bin/java -cp
> /usr/lib/ambari-agent/DBConnectionVerification.jar:/usr/hdp/current/hive-metastore/lib/mysql-connector-java.jar
> org.apache.ambari.server.DBConnectionVerification 'jdbc:mysql://host/hivedb'
> hiveuser PROTECTED com.mysql.jdbc.Driver']
> {'path': ['/usr/sbin:/sbin:/usr/local/bin:/bin:/usr/bin'], 'tries': 5,
> 'try_sleep': 10}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-16955) Allow setting log level, and java opts for hive interactive/llap
Dmitry Lysnichenko created AMBARI-16955: --- Summary: Allow setting log level, and java opts for hive interactive/llap Key: AMBARI-16955 URL: https://issues.apache.org/jira/browse/AMBARI-16955 Project: Ambari Issue Type: Improvement Reporter: Dmitry Lysnichenko Assignee: Dmitry Lysnichenko Attachments: AMBARI-16955.patch Users should be able to control the log level for the daemons, and java args for the daemon. Both of these are likely to be text input boxes, which feed into hive --service llap. There's no explicit ocnfiguration in hive-site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16955) Allow setting log level, and java opts for hive interactive/llap
[ https://issues.apache.org/jira/browse/AMBARI-16955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Lysnichenko updated AMBARI-16955: Attachment: AMBARI-16955.patch > Allow setting log level, and java opts for hive interactive/llap > > > Key: AMBARI-16955 > URL: https://issues.apache.org/jira/browse/AMBARI-16955 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko > Attachments: AMBARI-16955.patch > > > Users should be able to control the log level for the daemons, and java args > for the daemon. > Both of these are likely to be text input boxes, which feed into hive > --service llap. There's no explicit ocnfiguration in hive-site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16956) Ensure smokeuser HDFS folder exists before running MR, YARN, PIG, OOZIE service checks
Sandor Magyari created AMBARI-16956:
---
Summary: Ensure smokeuser HDFS folder exists before running MR,
YARN, PIG, OOZIE service checks
Key: AMBARI-16956
URL: https://issues.apache.org/jira/browse/AMBARI-16956
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.2.0
Reporter: Sandor Magyari
Assignee: Sandor Magyari
Fix For: ambari-2.4.0
Modify service check scripts for YARN, MR, PIG, OOZIE, MAHOUT to ensure that
before running actual service checks using '/user/
{smokeuser}
' HDFS folder (YARN, MR, PIG, OOZIE, MAHOUT) create this resource if doesn't
already exists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16950) "DISCARD" button doesn't work on HIVE INTERACTIVE page.
[
https://issues.apache.org/jira/browse/AMBARI-16950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306748#comment-15306748
]
Hudson commented on AMBARI-16950:
-
SUCCESS: Integrated in Ambari-trunk-Commit #4959 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/4959/])
AMBARI-16950. "DISCARD" button doesn't work on HIVE INTERACTIVE page. (hiveww:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=0926cdc6d5f2c79e8249d009adb6c8b9e4b4bbed])
* ambari-web/app/routes/main.js
> "DISCARD" button doesn't work on HIVE INTERACTIVE page.
> ---
>
> Key: AMBARI-16950
> URL: https://issues.apache.org/jira/browse/AMBARI-16950
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-16950.patch, Screen Shot 2016-05-25 at 2.56.13
> PM.png, Screen Shot 2016-05-25 at 3.05.37 PM.png
>
>
> - Starting from this page. !Screen Shot 2016-05-25 at 2.56.13
> PM.png|thumbnail! , lets says if we modify any slider. Then instead of SAVE,
> lets click SUMMARY on top, to move away from this page. This dialog will
> show up. !Screen Shot 2016-05-25 at 3.05.37 PM.png|thumbnail! . Here,
> 'Discard' button wont work.
> {code}
> Ambari-2.4.0.0
> # ambari-server --hash
> 008c8219678493888bb8e0daee7beb668e7517e5
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16954) SERVICE_CHECK Upgrade pre-check does not throw error when its expected to
[
https://issues.apache.org/jira/browse/AMBARI-16954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Lysnichenko updated AMBARI-16954:
Affects Version/s: 2.4.0
> SERVICE_CHECK Upgrade pre-check does not throw error when its expected to
> -
>
> Key: AMBARI-16954
> URL: https://issues.apache.org/jira/browse/AMBARI-16954
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-16954.patch
>
>
> *Steps*
> # Deploy HDP-2.4.0.0 cluster with Ambari 2.2.2
> # Upgrade Ambari to 2.4.0.0
> # Register HDP-2.5.0.0 version and install the bits
> # Modify configs for some of the service like HDFS, ZK, YARN
> # Start EU
> *Result*:
> EU pre-check does *not* report below error for the three services whose
> config was modified in step 4
> "The following service configurations have been updated and their Service
> Checks should be run again:"
> Upon further investigation found that the pre-check does not work if a
> service check has never been run for a service at all AND reports success in
> such cases
> In other words, the comparison between last config modification time and last
> service check time succeeds if service check never ran at all and the output
> of below query returns empty:
> {code}
> SELECT start_time FROM host_role_command where role = 'HDFS_SERVICE_CHECK'
> AND status = 'COMPLETED' ORDER BY start_time DESC;
> {code}
> In this case when I manually ran a service check for HDFS and retried EU, the
> pre-check caught the mismatch and reported error
> *Note*: I believe we do run service check as part of cluster install, but
> looks like it does not get updated in the DB tables for all services.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16954) SERVICE_CHECK Upgrade pre-check does not throw error when its expected to
[
https://issues.apache.org/jira/browse/AMBARI-16954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Lysnichenko updated AMBARI-16954:
Fix Version/s: 2.4.0
> SERVICE_CHECK Upgrade pre-check does not throw error when its expected to
> -
>
> Key: AMBARI-16954
> URL: https://issues.apache.org/jira/browse/AMBARI-16954
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-16954.patch
>
>
> *Steps*
> # Deploy HDP-2.4.0.0 cluster with Ambari 2.2.2
> # Upgrade Ambari to 2.4.0.0
> # Register HDP-2.5.0.0 version and install the bits
> # Modify configs for some of the service like HDFS, ZK, YARN
> # Start EU
> *Result*:
> EU pre-check does *not* report below error for the three services whose
> config was modified in step 4
> "The following service configurations have been updated and their Service
> Checks should be run again:"
> Upon further investigation found that the pre-check does not work if a
> service check has never been run for a service at all AND reports success in
> such cases
> In other words, the comparison between last config modification time and last
> service check time succeeds if service check never ran at all and the output
> of below query returns empty:
> {code}
> SELECT start_time FROM host_role_command where role = 'HDFS_SERVICE_CHECK'
> AND status = 'COMPLETED' ORDER BY start_time DESC;
> {code}
> In this case when I manually ran a service check for HDFS and retried EU, the
> pre-check caught the mismatch and reported error
> *Note*: I believe we do run service check as part of cluster install, but
> looks like it does not get updated in the DB tables for all services.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16939) 'ambari-server upgrade' is failed : Error executing schema upgrade [upgrade from 2200 to 2400]
[
https://issues.apache.org/jira/browse/AMBARI-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306823#comment-15306823
]
Hudson commented on AMBARI-16939:
-
FAILURE: Integrated in Ambari-trunk-Commit #4961 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/4961/])
AMBARI-16939. 'ambari-server upgrade' is failed : Error executing schema
(smagyari:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=baa8ae9168d7bf14d37f157a6338f4e75aab15d0])
*
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java
> 'ambari-server upgrade' is failed : Error executing schema upgrade [upgrade
> from 2200 to 2400]
> --
>
> Key: AMBARI-16939
> URL: https://issues.apache.org/jira/browse/AMBARI-16939
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Balázs Bence Sári
>Assignee: Balázs Bence Sári
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: patch2-24.diff, patch2-trunk.diff
>
>
> STR:
> 1) Install old version
> 2) Try to Make ambari only upgrade
> Cluster: 172.22.123.240
> All logs:
> http://qelog.hortonworks.com/log/os-u14-xvenls-upg-sanity-u-2200/test-logs/ambari-upgrade-2.2.0.0/
> Actual result:
> 'ambari-server upgrade' is failed : Error executing schema upgrade [upgrade
> from 2200 to 2400]
> {code}
> 2016-05-19 04:50:31,348 INFO
> com.hw.ambari.ui.util.cluster_managers.CommandExecutor.executeCommandSequence():
> Sending command []
> 2016-05-19 04:50:31,950 DEBUG
> com.hw.ambari.ui.util.cluster_managers.ProcessData.buildOutputAndErrorStreamData():
> stdin: is not a tty
> 2016-05-19 04:50:49,791 INFO
> com.hw.ambari.ui.util.cluster_managers.CommandExecutor.executeCommandSequence():
> [OUTPUT STREAM]
> Using python /usr/bin/python
> Upgrading ambari-server
> Updating properties in ambari.properties ...
> WARNING: Original file ambari-env.sh kept
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: No mpack replay logs found. Skipping replaying mpack commands
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> Fixing database objects owner
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> Ambari Server configured for MySQL. Confirm you have made a backup of the
> Ambari Server database [y/n] (y)? INFO: Loading properties from
> /etc/ambari-server/conf/ambari.properties
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> Upgrading database schema
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: AMBARI_SERVER_LIB is not set, using default /usr/lib/ambari-server
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: about to run command: /usr/lib/jvm/java-7-openjdk-amd64/bin/java -cp
> '/etc/ambari-server/conf:/usr/lib/ambari-server/*:/usr/share/java/mysql-connector-java.jar'
> org.apache.ambari.server.upgrade.SchemaUpgradeHelper >
> /var/log/ambari-server/ambari-server.out 2>&1
> INFO: Return code from schema upgrade command, retcode = 1
> Error output from schema upgrade command:
> Exception in thread "main" org.apache.ambari.server.AmbariException: Cannot
> add foreign key constraint
> at
> org.apache.ambari.server.upgrade.SchemaUpgradeHelper.executeUpgrade(SchemaUpgradeHelper.java:204)
> at
> org.apache.ambari.server.upgrade.SchemaUpgradeHelper.main(SchemaUpgradeHelper.java:302)
> Caused by: java.sql.SQLException: Cannot add foreign key constraint
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:959)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3870)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3806)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2470)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2617)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2546)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2504)
> at com.mysql.jdbc.StatementImpl.executeInternal(StatementImpl.java:840)
> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:740)
> at
> org.apache.ambari.server.orm.DBAccessorImpl.executeQuery(DBAccessorImpl.java:800)
> at
> org.apache.ambari.server.orm.DBAccessorImpl.addFKConstraint(DBAccessorImpl.java:470)
> at
>
[jira] [Commented] (AMBARI-16821) Improve TimelineMetricsCache eviction/flush logic using a cache library
[ https://issues.apache.org/jira/browse/AMBARI-16821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306822#comment-15306822 ] Hudson commented on AMBARI-16821: - FAILURE: Integrated in Ambari-trunk-Commit #4961 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4961/]) AMBARI-16821 Improve TimelineMetricsCache eviction/flush logic using a (dsen: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=46b2fcdef0b0fa9d741951cbb6f9c97b53d09be4]) * ambari-metrics/ambari-metrics-hadoop-sink/src/test/java/org/apache/hadoop/metrics2/sink/timeline/HadoopTimelineMetricsSinkTest.java * ambari-metrics/ambari-metrics-common/pom.xml * ambari-metrics/ambari-metrics-common/src/test/java/org/apache/hadoop/metrics2/sink/timeline/cache/TimelineMetricsCacheTest.java * ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/cache/TimelineMetricsCache.java > Improve TimelineMetricsCache eviction/flush logic using a cache library > --- > > Key: AMBARI-16821 > URL: https://issues.apache.org/jira/browse/AMBARI-16821 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.2.2 >Reporter: Dmytro Sen >Assignee: Dmytro Sen > Fix For: 2.4.0 > > Attachments: AMBARI-16821_1.patch, AMBARI-16821_2.patch > > > The TimelineMetricsCache implementation in the metrics sink side is currently > a ConcurrentSkipListMap. It is better to use pre built cache libraries like > Guava that offer more support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16925) Config pages are corrupted for services failed to install
[ https://issues.apache.org/jira/browse/AMBARI-16925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Nechiporenko updated AMBARI-16925: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Config pages are corrupted for services failed to install > - > > Key: AMBARI-16925 > URL: https://issues.apache.org/jira/browse/AMBARI-16925 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 > Environment: ambari-server version: ambari-server-2.4.0.0-611 > ambari-server --hash: 1feda434390324d06a1af922328b3d1b4c788305 > HDP Stack: 2.5 > HDP Version: 2.5.0.0-582 > Ambari DB: :PostgreSQL_External > Oozie/Hive DB: PostgreSQL_External/PostgreSQL_External > Security:yes > Security Type:AD/AD > Blueprints: true > Umask: > JDK: OracleJDK8 > HA: no > OS: SUSE Linux Enterprise Server 11 > Ambari User: root > Agents User: root > MOTD enabled: false > Customized service users: false > Is tmp exec: false >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko >Priority: Blocker > Fix For: 2.4.0 > > Attachments: AMBARI-16925.patch > > > Deploy of cluster via blueprints was failed on installing of components. > After that services failed to install have corrupted configs pages. This can > block user because there can be situation when it is not possible to install > service without configs changing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
