[jira] [Updated] (AMBARI-18371) View migration removes current permissions
[ https://issues.apache.org/jira/browse/AMBARI-18371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] DIPAYAN BHOWMICK updated AMBARI-18371: -- Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk, branch-2.4, branch-2.5 > View migration removes current permissions > -- > > Key: AMBARI-18371 > URL: https://issues.apache.org/jira/browse/AMBARI-18371 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Ashwin Rajeev >Assignee: Ashwin Rajeev > Fix For: 2.4.2 > > Attachments: AMBARI-18371.trunk.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > When two versions of the same view exists, Ambari on startup tries to migrate > old data to the new view and deletes the current permissions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18639) Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
[
https://issues.apache.org/jira/browse/AMBARI-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593689#comment-15593689
]
Hudson commented on AMBARI-18639:
-
ABORTED: Integrated in Jenkins build Ambari-branch-2.5 #181 (See
[https://builds.apache.org/job/Ambari-branch-2.5/181/])
AMBARI-18639. Ambari UI does not allow to modify EMPTY threshold text of
(xiwang:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=ec5d70add9179e9eec567bf5deb2afd6cff4b65b])
* (edit) ambari-web/app/controllers/main/alerts/definition_configs_controller.js
> Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
> -
>
> Key: AMBARI-18639
> URL: https://issues.apache.org/jira/browse/AMBARI-18639
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.1, 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18639-2.5.patch, AMBARI-18639-2.5.patch,
> AMBARI-18639.patch
>
>
> Ambari UI does not allow to modify threshold of *'OK'* and *'WARNING'* in
> ResourceManager WEB UI alert.
> *Steps to reproduce:*
> 1. Remove threshold from WARNING/OK at alert of ResourceManager WEB UI
> 2. Save
> 3. Refresh Ambari UI and and the field is blank *- Expected*
> 4. Add any threshold string (may be the one that you removed) to WARNING/OK
> and then save
> 5. Refresh Ambari UI. _Here is the problem._ *It shows just blank.*
> 6. API /api/v1/clusters/young-hdp250/alert_definitions/44 shows blank too.
> - It's happening because the PUT call is sent empty.
> !RM Web UI- Alert Definitioni.jpg|thumbnail!
> {code}
> "critical" : {
> "text" : "Connection failed to {1} ({3})"
> },
> "ok" : {
> "text" : "HTTP {0} response in {2:.3f}s"
> },
> "warning" : {
> "text" : ""
> }
> {code}
> *Workaround:*
> Manual update using curl command works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18656) Generic and secure way to handle setting roles on imported or manaully created groups
Vishal Ghugare created AMBARI-18656: --- Summary: Generic and secure way to handle setting roles on imported or manaully created groups Key: AMBARI-18656 URL: https://issues.apache.org/jira/browse/AMBARI-18656 Project: Ambari Issue Type: Story Affects Versions: trunk Reporter: Vishal Ghugare Assignee: Vishal Ghugare Fix For: trunk -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18655) Metric level hadoop metrics2 filter is incompatible with AMS HadoopTimelineMetricsSink.
[
https://issues.apache.org/jira/browse/AMBARI-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593421#comment-15593421
]
Hudson commented on AMBARI-18655:
-
FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5839 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5839/])
AMBARI-18655 : Metric level hadoop metrics2 filter is incompatible with
(avijayan:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=dd0cc32b71988add58d6e796dc77722a937c28b1])
* (edit)
ambari-metrics/ambari-metrics-hadoop-sink/src/main/java/org/apache/hadoop/metrics2/sink/timeline/HadoopTimelineMetricsSink.java
> Metric level hadoop metrics2 filter is incompatible with AMS
> HadoopTimelineMetricsSink.
> ---
>
> Key: AMBARI-18655
> URL: https://issues.apache.org/jira/browse/AMBARI-18655
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Labels: ambari-metrics
> Fix For: 2.5.0
>
> Attachments: AMBARI-18655.patch
>
>
> {code}
> 2016-10-19 14:46:41,647 INFO [HBase-Metrics2-1]
> timeline.HadoopTimelineMetricsSink: Collector Uri:
> http://apappu-hdp-3.hdp.com:6188/ws/v1/timeline/metrics
> 2016-10-19 14:46:41,653 INFO [HBase-Metrics2-1] impl.MetricsSinkAdapter:
> Sink timeline started
> 2016-10-19 14:46:41,655 INFO [HBase-Metrics2-1] impl.MetricsSystemImpl:
> Scheduled snapshot period at 10 second(s).
> 2016-10-19 14:46:41,655 INFO [HBase-Metrics2-1] impl.MetricsSystemImpl:
> HBase metrics system started
> java.lang.ClassCastException:
> org.apache.hadoop.metrics2.impl.MetricsRecordFiltered$1 cannot be cast to
> java.util.Collection
> at
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:258)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> 2016-10-18 13:39:42,896 ERROR [timeline] impl.MetricsSinkAdapter: Got sink
> exception and over retry limit, suppressing further error messages
> java.lang.ClassCastException:
> org.apache.hadoop.metrics2.impl.MetricsRecordFiltered$1 cannot be cast to
> java.util.Collection
> at
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:258)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> Tue Oct 18 13:41:53 PDT 2016 Terminating regionserver
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18617) Adding custom property to hive-site adds it to other 'Custom' panels on hive
[
https://issues.apache.org/jira/browse/AMBARI-18617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593408#comment-15593408
]
Hadoop QA commented on AMBARI-18617:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834562/AMBARI-18617.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 2 new
or modified test files.
{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-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8954//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8954//console
This message is automatically generated.
> Adding custom property to hive-site adds it to other 'Custom' panels on hive
>
>
> Key: AMBARI-18617
> URL: https://issues.apache.org/jira/browse/AMBARI-18617
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.2
>Reporter: Dhanya Balasundaran
> Fix For: 2.4.2
>
> Attachments: AMBARI-18617.patch
>
>
> - Navigate through Ambari Install Wizard to reach Customize Services page
> - Choose Hive
> - Add a custom property to Custom-hive-site
> - Noticed that its getting added to Custom hivemetastore-site,
> Custom hiveserver2-interactive-site, Custom hiveserver2-site,
> Custom hivemetastore-site, Custom tez-interactive-site.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18655) Metric level hadoop metrics2 filter is incompatible with AMS HadoopTimelineMetricsSink.
[
https://issues.apache.org/jira/browse/AMBARI-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593360#comment-15593360
]
Aravindan Vijayan commented on AMBARI-18655:
{code}
[INFO] utility ... SUCCESS [1.079s]
[INFO] ambari-metrics SUCCESS [0.840s]
[INFO] Ambari Metrics Common . SUCCESS [2.664s]
[INFO] Ambari Metrics Hadoop Sink SUCCESS [5.313s]
[INFO] Ambari Metrics Flume Sink . SUCCESS [2.730s]
[INFO] Ambari Metrics Kafka Sink . SUCCESS [3.190s]
[INFO] Ambari Metrics Storm Sink . SUCCESS [1.711s]
[INFO] Ambari Metrics Storm Sink (Legacy) SUCCESS [1.982s]
[INFO] Ambari Metrics Collector .. SUCCESS [2:23.634s]
[INFO] Ambari Metrics Monitor SUCCESS [3.790s]
[INFO] Ambari Metrics Grafana SUCCESS [4.492s]
[INFO] Ambari Metrics Assembly ... SUCCESS [4.963s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 2:56.575s
[INFO] Finished at: Thu Oct 20 16:25:34 PDT 2016
[INFO] Final Memory: 77M/1293M
[INFO]
{code}
> Metric level hadoop metrics2 filter is incompatible with AMS
> HadoopTimelineMetricsSink.
> ---
>
> Key: AMBARI-18655
> URL: https://issues.apache.org/jira/browse/AMBARI-18655
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Labels: ambari-metrics
> Fix For: 2.5.0
>
> Attachments: AMBARI-18655.patch
>
>
> {code}
> 2016-10-19 14:46:41,647 INFO [HBase-Metrics2-1]
> timeline.HadoopTimelineMetricsSink: Collector Uri:
> http://apappu-hdp-3.hdp.com:6188/ws/v1/timeline/metrics
> 2016-10-19 14:46:41,653 INFO [HBase-Metrics2-1] impl.MetricsSinkAdapter:
> Sink timeline started
> 2016-10-19 14:46:41,655 INFO [HBase-Metrics2-1] impl.MetricsSystemImpl:
> Scheduled snapshot period at 10 second(s).
> 2016-10-19 14:46:41,655 INFO [HBase-Metrics2-1] impl.MetricsSystemImpl:
> HBase metrics system started
> java.lang.ClassCastException:
> org.apache.hadoop.metrics2.impl.MetricsRecordFiltered$1 cannot be cast to
> java.util.Collection
> at
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:258)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> 2016-10-18 13:39:42,896 ERROR [timeline] impl.MetricsSinkAdapter: Got sink
> exception and over retry limit, suppressing further error messages
> java.lang.ClassCastException:
> org.apache.hadoop.metrics2.impl.MetricsRecordFiltered$1 cannot be cast to
> java.util.Collection
> at
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:258)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> Tue Oct 18 13:41:53 PDT 2016 Terminating regionserver
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18635) Authorizations given to roles, should use generic role-based principals rather than hard-coded pseudo-role-based principals
[
https://issues.apache.org/jira/browse/AMBARI-18635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593289#comment-15593289
]
Hadoop QA commented on AMBARI-18635:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834531/AMBARI-18635_trunk_02.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 10 new
or modified test files.
{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-admin ambari-server:
org.apache.ambari.server.state.ServicePropertiesTest
org.apache.ambari.server.state.ConfigHelperTest
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8952//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8952//console
This message is automatically generated.
> Authorizations given to roles, should use generic role-based principals
> rather than hard-coded pseudo-role-based principals
> ---
>
> Key: AMBARI-18635
> URL: https://issues.apache.org/jira/browse/AMBARI-18635
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.4.2
>
> Attachments: AMBARI-18635_branch-2.4_01.patch,
> AMBARI-18635_branch-2.4_02.patch, AMBARI-18635_branch-2.5_01.patch,
> AMBARI-18635_branch-2.5_02.patch, AMBARI-18635_trunk_01.patch,
> AMBARI-18635_trunk_02.patch
>
>
> Authorizations given to roles, should use generic role-based principals
> rather than hard-coded resource types.
> Access to views can be assigned to all users with a given role. The
> implementation for this lead to the creation of hard-coded principals that
> represent the current set of roles. This is not dynamic enough for possibly
> future enhancements where new roles may be created by administrators.
> This needs to be changed such that rather that using the hard-coded
> pseudo-role-principals, the dynamically generated role-principals are to be
> used.
> The hard-coded pseudo-role-principals have the following
> {{adminprincipaltype}} values as opposed to "ROLE":
> * ALL.CLUSTER.ADMINISTRATOR
> * ALL.CLUSTER.OPERATOR
> * ALL.SERVICE.ADMINISTRATOR
> * ALL.SERVICE.OPERATOR
> * ALL.CLUSTER.USER
> These should be removed along with the associated {{adminprincipal}} records.
> Also, the FE should be updated to set permissions using the dynamic
> role-principals.
> Finally, code should be cleaned up to remove unneeded code in
> *
> org.apache.ambari.server.security.authorization.ClusterInheritedPermissionHelper
> *
> org.apache.ambari.server.controller.internal.GroupPrivilegeResourceProvider#getResources
> *
> org.apache.ambari.server.controller.internal.PrivilegeResourceProvider#toEntity
> *
> org.apache.ambari.server.controller.internal.UserPrivilegeResourceProvider#getResources
> *
> org.apache.ambari.server.security.authorization.AuthorizationHelper#isAuthorized
> * org.apache.ambari.server.view.ViewRegistry#addClusterInheritedPermissions
> * ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18655) Metric level hadoop metrics2 filter is incompatible with AMS HadoopTimelineMetricsSink.
[
https://issues.apache.org/jira/browse/AMBARI-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593291#comment-15593291
]
Hadoop QA commented on AMBARI-18655:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834557/AMBARI-18655.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8953//console
This message is automatically generated.
> Metric level hadoop metrics2 filter is incompatible with AMS
> HadoopTimelineMetricsSink.
> ---
>
> Key: AMBARI-18655
> URL: https://issues.apache.org/jira/browse/AMBARI-18655
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Labels: ambari-metrics
> Fix For: 2.5.0
>
> Attachments: AMBARI-18655.patch
>
>
> {code}
> 2016-10-19 14:46:41,647 INFO [HBase-Metrics2-1]
> timeline.HadoopTimelineMetricsSink: Collector Uri:
> http://apappu-hdp-3.hdp.com:6188/ws/v1/timeline/metrics
> 2016-10-19 14:46:41,653 INFO [HBase-Metrics2-1] impl.MetricsSinkAdapter:
> Sink timeline started
> 2016-10-19 14:46:41,655 INFO [HBase-Metrics2-1] impl.MetricsSystemImpl:
> Scheduled snapshot period at 10 second(s).
> 2016-10-19 14:46:41,655 INFO [HBase-Metrics2-1] impl.MetricsSystemImpl:
> HBase metrics system started
> java.lang.ClassCastException:
> org.apache.hadoop.metrics2.impl.MetricsRecordFiltered$1 cannot be cast to
> java.util.Collection
> at
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:258)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> 2016-10-18 13:39:42,896 ERROR [timeline] impl.MetricsSinkAdapter: Got sink
> exception and over retry limit, suppressing further error messages
> java.lang.ClassCastException:
> org.apache.hadoop.metrics2.impl.MetricsRecordFiltered$1 cannot be cast to
> java.util.Collection
> at
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:258)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> Tue Oct 18 13:41:53 PDT 2016 Terminating regionserver
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18617) Adding custom property to hive-site adds it to other 'Custom' panels on hive
[ https://issues.apache.org/jira/browse/AMBARI-18617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-18617: Status: Patch Available (was: Open) Verified patch manually on a cluster Verified that all ambari-web unit tests passes: 29243 tests complete (30 seconds) 154 tests pending > Adding custom property to hive-site adds it to other 'Custom' panels on hive > > > Key: AMBARI-18617 > URL: https://issues.apache.org/jira/browse/AMBARI-18617 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.2 >Reporter: Dhanya Balasundaran > Fix For: 2.4.2 > > Attachments: AMBARI-18617.patch > > > - Navigate through Ambari Install Wizard to reach Customize Services page > - Choose Hive > - Add a custom property to Custom-hive-site > - Noticed that its getting added to Custom hivemetastore-site, > Custom hiveserver2-interactive-site, Custom hiveserver2-site, > Custom hivemetastore-site, Custom tez-interactive-site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18617) Adding custom property to hive-site adds it to other 'Custom' panels on hive
[ https://issues.apache.org/jira/browse/AMBARI-18617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-18617: Attachment: AMBARI-18617.patch > Adding custom property to hive-site adds it to other 'Custom' panels on hive > > > Key: AMBARI-18617 > URL: https://issues.apache.org/jira/browse/AMBARI-18617 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.2 >Reporter: Dhanya Balasundaran > Fix For: 2.4.2 > > Attachments: AMBARI-18617.patch > > > - Navigate through Ambari Install Wizard to reach Customize Services page > - Choose Hive > - Add a custom property to Custom-hive-site > - Noticed that its getting added to Custom hivemetastore-site, > Custom hiveserver2-interactive-site, Custom hiveserver2-site, > Custom hivemetastore-site, Custom tez-interactive-site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18617) Adding custom property to hive-site adds it to other 'Custom' panels on hive
[ https://issues.apache.org/jira/browse/AMBARI-18617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-18617: Attachment: AMBARI-18617.patch > Adding custom property to hive-site adds it to other 'Custom' panels on hive > > > Key: AMBARI-18617 > URL: https://issues.apache.org/jira/browse/AMBARI-18617 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.2 >Reporter: Dhanya Balasundaran > Fix For: 2.4.2 > > Attachments: AMBARI-18617.patch > > > - Navigate through Ambari Install Wizard to reach Customize Services page > - Choose Hive > - Add a custom property to Custom-hive-site > - Noticed that its getting added to Custom hivemetastore-site, > Custom hiveserver2-interactive-site, Custom hiveserver2-site, > Custom hivemetastore-site, Custom tez-interactive-site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18639) Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
[
https://issues.apache.org/jira/browse/AMBARI-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593248#comment-15593248
]
Hudson commented on AMBARI-18639:
-
FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5838 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5838/])
AMBARI-18639. Ambari UI does not allow to modify EMPTY threshold text of
(xiwang:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=5256a78908ec9a635bf7e59480511d2ca0d33363])
* (edit) ambari-web/app/controllers/main/alerts/definition_configs_controller.js
> Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
> -
>
> Key: AMBARI-18639
> URL: https://issues.apache.org/jira/browse/AMBARI-18639
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.1, 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18639-2.5.patch, AMBARI-18639-2.5.patch,
> AMBARI-18639.patch
>
>
> Ambari UI does not allow to modify threshold of *'OK'* and *'WARNING'* in
> ResourceManager WEB UI alert.
> *Steps to reproduce:*
> 1. Remove threshold from WARNING/OK at alert of ResourceManager WEB UI
> 2. Save
> 3. Refresh Ambari UI and and the field is blank *- Expected*
> 4. Add any threshold string (may be the one that you removed) to WARNING/OK
> and then save
> 5. Refresh Ambari UI. _Here is the problem._ *It shows just blank.*
> 6. API /api/v1/clusters/young-hdp250/alert_definitions/44 shows blank too.
> - It's happening because the PUT call is sent empty.
> !RM Web UI- Alert Definitioni.jpg|thumbnail!
> {code}
> "critical" : {
> "text" : "Connection failed to {1} ({3})"
> },
> "ok" : {
> "text" : "HTTP {0} response in {2:.3f}s"
> },
> "warning" : {
> "text" : ""
> }
> {code}
> *Workaround:*
> Manual update using curl command works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18654) Implement instrumented Lock for profiling/logging
[
https://issues.apache.org/jira/browse/AMBARI-18654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593216#comment-15593216
]
Hadoop QA commented on AMBARI-18654:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834534/AMBARI-18654.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 3 new
or modified test files.
{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.state.cluster.AlertDataManagerTest
org.apache.ambari.server.state.ServicePropertiesTest
org.apache.ambari.server.state.cluster.ClustersDeadlockTest
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8951//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8951//console
This message is automatically generated.
> Implement instrumented Lock for profiling/logging
> -
>
> Key: AMBARI-18654
> URL: https://issues.apache.org/jira/browse/AMBARI-18654
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
>Priority: Minor
> Fix For: 3.0.0, 2.5.0
>
> Attachments: AMBARI-18654.patch
>
>
> As part of the reduced reliance on Java locks, we should allow for the lock
> implementation provided to business objects to be able to log information
> about their acquisition and release.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18655) Metric level hadoop metrics2 filter is incompatible with AMS HadoopTimelineMetricsSink.
[
https://issues.apache.org/jira/browse/AMBARI-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593179#comment-15593179
]
Siddharth Wagle commented on AMBARI-18655:
--
+1 LGTM
> Metric level hadoop metrics2 filter is incompatible with AMS
> HadoopTimelineMetricsSink.
> ---
>
> Key: AMBARI-18655
> URL: https://issues.apache.org/jira/browse/AMBARI-18655
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Labels: ambari-metrics
> Fix For: 2.5.0
>
> Attachments: AMBARI-18655.patch
>
>
> {code}
> 2016-10-19 14:46:41,647 INFO [HBase-Metrics2-1]
> timeline.HadoopTimelineMetricsSink: Collector Uri:
> http://apappu-hdp-3.hdp.com:6188/ws/v1/timeline/metrics
> 2016-10-19 14:46:41,653 INFO [HBase-Metrics2-1] impl.MetricsSinkAdapter:
> Sink timeline started
> 2016-10-19 14:46:41,655 INFO [HBase-Metrics2-1] impl.MetricsSystemImpl:
> Scheduled snapshot period at 10 second(s).
> 2016-10-19 14:46:41,655 INFO [HBase-Metrics2-1] impl.MetricsSystemImpl:
> HBase metrics system started
> java.lang.ClassCastException:
> org.apache.hadoop.metrics2.impl.MetricsRecordFiltered$1 cannot be cast to
> java.util.Collection
> at
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:258)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> 2016-10-18 13:39:42,896 ERROR [timeline] impl.MetricsSinkAdapter: Got sink
> exception and over retry limit, suppressing further error messages
> java.lang.ClassCastException:
> org.apache.hadoop.metrics2.impl.MetricsRecordFiltered$1 cannot be cast to
> java.util.Collection
> at
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:258)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> Tue Oct 18 13:41:53 PDT 2016 Terminating regionserver
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18655) Metric level hadoop metrics2 filter is incompatible with AMS HadoopTimelineMetricsSink.
[
https://issues.apache.org/jira/browse/AMBARI-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593172#comment-15593172
]
Aravindan Vijayan commented on AMBARI-18655:
As the exception trace points out, the Casting of Iterable to
Collection did not work if the instance of MetricsRecord that
was passed in to HadoopTimelineMetricsSink is MetricsRecordFiltered (as opposed
to MetricsRecordImpl when no filtering is configiured)
> Metric level hadoop metrics2 filter is incompatible with AMS
> HadoopTimelineMetricsSink.
> ---
>
> Key: AMBARI-18655
> URL: https://issues.apache.org/jira/browse/AMBARI-18655
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Labels: ambari-metrics
> Fix For: 2.5.0
>
> Attachments: AMBARI-18655.patch
>
>
> {code}
> 2016-10-19 14:46:41,647 INFO [HBase-Metrics2-1]
> timeline.HadoopTimelineMetricsSink: Collector Uri:
> http://apappu-hdp-3.hdp.com:6188/ws/v1/timeline/metrics
> 2016-10-19 14:46:41,653 INFO [HBase-Metrics2-1] impl.MetricsSinkAdapter:
> Sink timeline started
> 2016-10-19 14:46:41,655 INFO [HBase-Metrics2-1] impl.MetricsSystemImpl:
> Scheduled snapshot period at 10 second(s).
> 2016-10-19 14:46:41,655 INFO [HBase-Metrics2-1] impl.MetricsSystemImpl:
> HBase metrics system started
> java.lang.ClassCastException:
> org.apache.hadoop.metrics2.impl.MetricsRecordFiltered$1 cannot be cast to
> java.util.Collection
> at
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:258)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> 2016-10-18 13:39:42,896 ERROR [timeline] impl.MetricsSinkAdapter: Got sink
> exception and over retry limit, suppressing further error messages
> java.lang.ClassCastException:
> org.apache.hadoop.metrics2.impl.MetricsRecordFiltered$1 cannot be cast to
> java.util.Collection
> at
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:258)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> Tue Oct 18 13:41:53 PDT 2016 Terminating regionserver
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18655) Metric level hadoop metrics2 filter is incompatible with AMS HadoopTimelineMetricsSink.
[
https://issues.apache.org/jira/browse/AMBARI-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated AMBARI-18655:
---
Attachment: AMBARI-18655.patch
> Metric level hadoop metrics2 filter is incompatible with AMS
> HadoopTimelineMetricsSink.
> ---
>
> Key: AMBARI-18655
> URL: https://issues.apache.org/jira/browse/AMBARI-18655
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Labels: ambari-metrics
> Fix For: 2.5.0
>
> Attachments: AMBARI-18655.patch
>
>
> {code}
> 2016-10-19 14:46:41,647 INFO [HBase-Metrics2-1]
> timeline.HadoopTimelineMetricsSink: Collector Uri:
> http://apappu-hdp-3.hdp.com:6188/ws/v1/timeline/metrics
> 2016-10-19 14:46:41,653 INFO [HBase-Metrics2-1] impl.MetricsSinkAdapter:
> Sink timeline started
> 2016-10-19 14:46:41,655 INFO [HBase-Metrics2-1] impl.MetricsSystemImpl:
> Scheduled snapshot period at 10 second(s).
> 2016-10-19 14:46:41,655 INFO [HBase-Metrics2-1] impl.MetricsSystemImpl:
> HBase metrics system started
> java.lang.ClassCastException:
> org.apache.hadoop.metrics2.impl.MetricsRecordFiltered$1 cannot be cast to
> java.util.Collection
> at
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:258)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> 2016-10-18 13:39:42,896 ERROR [timeline] impl.MetricsSinkAdapter: Got sink
> exception and over retry limit, suppressing further error messages
> java.lang.ClassCastException:
> org.apache.hadoop.metrics2.impl.MetricsRecordFiltered$1 cannot be cast to
> java.util.Collection
> at
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:258)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> Tue Oct 18 13:41:53 PDT 2016 Terminating regionserver
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18655) Metric level hadoop metrics2 filter is incompatible with AMS HadoopTimelineMetricsSink.
Aravindan Vijayan created AMBARI-18655:
--
Summary: Metric level hadoop metrics2 filter is incompatible with
AMS HadoopTimelineMetricsSink.
Key: AMBARI-18655
URL: https://issues.apache.org/jira/browse/AMBARI-18655
Project: Ambari
Issue Type: Bug
Components: ambari-metrics
Affects Versions: 2.5.0
Reporter: Aravindan Vijayan
Assignee: Aravindan Vijayan
Priority: Critical
Fix For: 2.5.0
{code}
2016-10-19 14:46:41,647 INFO [HBase-Metrics2-1]
timeline.HadoopTimelineMetricsSink: Collector Uri:
http://apappu-hdp-3.hdp.com:6188/ws/v1/timeline/metrics
2016-10-19 14:46:41,653 INFO [HBase-Metrics2-1] impl.MetricsSinkAdapter: Sink
timeline started
2016-10-19 14:46:41,655 INFO [HBase-Metrics2-1] impl.MetricsSystemImpl:
Scheduled snapshot period at 10 second(s).
2016-10-19 14:46:41,655 INFO [HBase-Metrics2-1] impl.MetricsSystemImpl: HBase
metrics system started
java.lang.ClassCastException:
org.apache.hadoop.metrics2.impl.MetricsRecordFiltered$1 cannot be cast to
java.util.Collection
at
org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:258)
at
org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
at
org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
at
org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
at
org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
at
org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
2016-10-18 13:39:42,896 ERROR [timeline] impl.MetricsSinkAdapter: Got sink
exception and over retry limit, suppressing further error messages
java.lang.ClassCastException:
org.apache.hadoop.metrics2.impl.MetricsRecordFiltered$1 cannot be cast to
java.util.Collection
at
org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:258)
at
org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
at
org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
at
org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
at
org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
at
org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
Tue Oct 18 13:41:53 PDT 2016 Terminating regionserver
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMBARI-18593) Provide ability to use downsampling function on certain metrics like client side topN
[ https://issues.apache.org/jira/browse/AMBARI-18593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravindan Vijayan resolved AMBARI-18593. Resolution: Fixed Pushed to branch-2.5 and trunk. > Provide ability to use downsampling function on certain metrics like client > side topN > - > > Key: AMBARI-18593 > URL: https://issues.apache.org/jira/browse/AMBARI-18593 > Project: Ambari > Issue Type: Task > Components: ambari-metrics >Affects Versions: 2.5.0 >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18593.patch > > > HDFS exposes top user activity broken down by operations in jmx (nntop). > These metrics should be captured in AMS and exposed in Grafana's HDFS > dashboards. > Downsampling should likely be a function like MIN, MAX, AVG, SUM of > underlying timeseries specified from the client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18639) Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
[
https://issues.apache.org/jira/browse/AMBARI-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xi Wang updated AMBARI-18639:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
> -
>
> Key: AMBARI-18639
> URL: https://issues.apache.org/jira/browse/AMBARI-18639
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.1, 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18639-2.5.patch, AMBARI-18639-2.5.patch,
> AMBARI-18639.patch
>
>
> Ambari UI does not allow to modify threshold of *'OK'* and *'WARNING'* in
> ResourceManager WEB UI alert.
> *Steps to reproduce:*
> 1. Remove threshold from WARNING/OK at alert of ResourceManager WEB UI
> 2. Save
> 3. Refresh Ambari UI and and the field is blank *- Expected*
> 4. Add any threshold string (may be the one that you removed) to WARNING/OK
> and then save
> 5. Refresh Ambari UI. _Here is the problem._ *It shows just blank.*
> 6. API /api/v1/clusters/young-hdp250/alert_definitions/44 shows blank too.
> - It's happening because the PUT call is sent empty.
> !RM Web UI- Alert Definitioni.jpg|thumbnail!
> {code}
> "critical" : {
> "text" : "Connection failed to {1} ({3})"
> },
> "ok" : {
> "text" : "HTTP {0} response in {2:.3f}s"
> },
> "warning" : {
> "text" : ""
> }
> {code}
> *Workaround:*
> Manual update using curl command works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18639) Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
[
https://issues.apache.org/jira/browse/AMBARI-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593153#comment-15593153
]
Xi Wang commented on AMBARI-18639:
--
Commited to trunk, branch-2.4, branch-2.5 and trunk
> Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
> -
>
> Key: AMBARI-18639
> URL: https://issues.apache.org/jira/browse/AMBARI-18639
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.1, 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18639-2.5.patch, AMBARI-18639-2.5.patch,
> AMBARI-18639.patch
>
>
> Ambari UI does not allow to modify threshold of *'OK'* and *'WARNING'* in
> ResourceManager WEB UI alert.
> *Steps to reproduce:*
> 1. Remove threshold from WARNING/OK at alert of ResourceManager WEB UI
> 2. Save
> 3. Refresh Ambari UI and and the field is blank *- Expected*
> 4. Add any threshold string (may be the one that you removed) to WARNING/OK
> and then save
> 5. Refresh Ambari UI. _Here is the problem._ *It shows just blank.*
> 6. API /api/v1/clusters/young-hdp250/alert_definitions/44 shows blank too.
> - It's happening because the PUT call is sent empty.
> !RM Web UI- Alert Definitioni.jpg|thumbnail!
> {code}
> "critical" : {
> "text" : "Connection failed to {1} ({3})"
> },
> "ok" : {
> "text" : "HTTP {0} response in {2:.3f}s"
> },
> "warning" : {
> "text" : ""
> }
> {code}
> *Workaround:*
> Manual update using curl command works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18639) Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
[
https://issues.apache.org/jira/browse/AMBARI-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593150#comment-15593150
]
Xi Wang commented on AMBARI-18639:
--
29536 tests complete (25 seconds)
154 tests pending
> Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
> -
>
> Key: AMBARI-18639
> URL: https://issues.apache.org/jira/browse/AMBARI-18639
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.1, 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18639-2.5.patch, AMBARI-18639-2.5.patch,
> AMBARI-18639.patch
>
>
> Ambari UI does not allow to modify threshold of *'OK'* and *'WARNING'* in
> ResourceManager WEB UI alert.
> *Steps to reproduce:*
> 1. Remove threshold from WARNING/OK at alert of ResourceManager WEB UI
> 2. Save
> 3. Refresh Ambari UI and and the field is blank *- Expected*
> 4. Add any threshold string (may be the one that you removed) to WARNING/OK
> and then save
> 5. Refresh Ambari UI. _Here is the problem._ *It shows just blank.*
> 6. API /api/v1/clusters/young-hdp250/alert_definitions/44 shows blank too.
> - It's happening because the PUT call is sent empty.
> !RM Web UI- Alert Definitioni.jpg|thumbnail!
> {code}
> "critical" : {
> "text" : "Connection failed to {1} ({3})"
> },
> "ok" : {
> "text" : "HTTP {0} response in {2:.3f}s"
> },
> "warning" : {
> "text" : ""
> }
> {code}
> *Workaround:*
> Manual update using curl command works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18631) Incorporate database consistency check into main Ambari process
[
https://issues.apache.org/jira/browse/AMBARI-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593114#comment-15593114
]
Hadoop QA commented on AMBARI-18631:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834542/AMBARI-18631.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8950//console
This message is automatically generated.
> Incorporate database consistency check into main Ambari process
> ---
>
> Key: AMBARI-18631
> URL: https://issues.apache.org/jira/browse/AMBARI-18631
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
> Fix For: 2.5.0
>
> Attachments: AMBARI-18631.patch
>
>
> Currently the database consistency check runs as a separate process prior
> Ambari process. The database consistency checker load various modules needed
> for performing the validations. (e.g. load stack definitions to be able to
> compare service configs from stack with configs from db).
> Once database consistency checker completed Ambari server is started. Ambari
> server beside others loads the same modules as database consistency checker.
> This double initialisation adds time to the ambari server startup time which
> could be reduced if the database consistency check is moved into the ambari
> server process.
> Moreover the database consistency check may check at the beginning if the
> database is empty and perform the checks only if there is data in the
> database.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18593) Provide ability to use downsampling function on certain metrics like client side topN
[ https://issues.apache.org/jira/browse/AMBARI-18593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593102#comment-15593102 ] Hudson commented on AMBARI-18593: - FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #180 (See [https://builds.apache.org/job/Ambari-branch-2.5/180/]) AMBARI-18593 : Provide ability to use downsampling function on certain (avijayan: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=014f3f7f8473f688b3d8223e8b840de4bb739431]) * (edit) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/aggregators/v2/TimelineMetricClusterAggregator.java * (add) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/aggregators/TopNDownSampler.java * (add) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/aggregators/DownSamplerUtils.java * (edit) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/aggregators/AbstractTimelineAggregator.java * (add) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/aggregators/CustomDownSampler.java * (edit) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/PhoenixTransactSQL.java * (edit) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java * (edit) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/aggregators/v2/TimelineMetricHostAggregator.java * (add) ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/aggregators/DownSamplerTest.java * (edit) ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-site.xml > Provide ability to use downsampling function on certain metrics like client > side topN > - > > Key: AMBARI-18593 > URL: https://issues.apache.org/jira/browse/AMBARI-18593 > Project: Ambari > Issue Type: Task > Components: ambari-metrics >Affects Versions: 2.5.0 >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18593.patch > > > HDFS exposes top user activity broken down by operations in jmx (nntop). > These metrics should be captured in AMS and exposed in Grafana's HDFS > dashboards. > Downsampling should likely be a function like MIN, MAX, AVG, SUM of > underlying timeseries specified from the client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18593) Provide ability to use downsampling function on certain metrics like client side topN
[ https://issues.apache.org/jira/browse/AMBARI-18593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593106#comment-15593106 ] Hudson commented on AMBARI-18593: - FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5837 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5837/]) AMBARI-18593 : Provide ability to use downsampling function on certain (avijayan: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=03f7b909517a4939199078911603ff6b2e4c99c8]) * (edit) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/aggregators/AbstractTimelineAggregator.java * (add) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/aggregators/DownSamplerUtils.java * (edit) ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-site.xml * (add) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/aggregators/TopNDownSampler.java * (add) ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/aggregators/DownSamplerTest.java * (add) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/aggregators/CustomDownSampler.java * (edit) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/aggregators/v2/TimelineMetricHostAggregator.java * (edit) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java * (edit) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/PhoenixTransactSQL.java * (edit) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/aggregators/v2/TimelineMetricClusterAggregator.java > Provide ability to use downsampling function on certain metrics like client > side topN > - > > Key: AMBARI-18593 > URL: https://issues.apache.org/jira/browse/AMBARI-18593 > Project: Ambari > Issue Type: Task > Components: ambari-metrics >Affects Versions: 2.5.0 >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18593.patch > > > HDFS exposes top user activity broken down by operations in jmx (nntop). > These metrics should be captured in AMS and exposed in Grafana's HDFS > dashboards. > Downsampling should likely be a function like MIN, MAX, AVG, SUM of > underlying timeseries specified from the client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18601) Analyze and Optimize Ambari Server Unit Tests - - Group 4
[ https://issues.apache.org/jira/browse/AMBARI-18601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravindan Vijayan updated AMBARI-18601: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Analyze and Optimize Ambari Server Unit Tests - - Group 4 > - > > Key: AMBARI-18601 > URL: https://issues.apache.org/jira/browse/AMBARI-18601 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.5.0 >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan > Fix For: 2.5.0 > > Attachments: AMBARI-18601-1.patch, AMBARI-18601-2.patch > > > ||Test||Count||Time (s)|| > |org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.availability.MetricCollectorHAControllerTest > | |197.933| > |org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.discovery.TestMetadataManager| > |143.545| > |org.apache.ambari.server.upgrade.UpgradeCatalog220Test |27|60.285| > |org.apache.ambari.server.state.ConfigHelperTest|18|45.862| > |org.apache.ambari.server.orm.dao.ServiceConfigDAOTest|15|40.703| > |org.apache.ambari.server.state.ServiceComponentTest|9|31.207| > |org.apache.ambari.server.controller.metrics.timeline.AMSPropertyProviderTest|5|38.724| -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18615) Fix JSHint errors in Workflow Manager view
[ https://issues.apache.org/jira/browse/AMBARI-18615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15592941#comment-15592941 ] Sangeeta Ravindran commented on AMBARI-18615: - The failure is caused by an existing issue unrelated to this patch. Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.4:war (default-war) on project oozie-ui: The specified web.xml file '/home/jenkins/jenkins-slave/workspace/Ambari-trunk-test-patch/ambari/contrib/views/wfmanager/src/main/resources/ui/oozie-ambari-view/src/main/resources/WEB-INF/web.xml' does not exist -> [Help 1] > Fix JSHint errors in Workflow Manager view > -- > > Key: AMBARI-18615 > URL: https://issues.apache.org/jira/browse/AMBARI-18615 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.5.0 >Reporter: Sangeeta Ravindran >Assignee: Sangeeta Ravindran > Fix For: 2.5.0 > > Attachments: AMBARI-18615.patch > > > When you compile the Workflow Manager view, you see 94 JSHint errors. > app.js: line 18, col 1, 'import' is only available in ES6 (use 'esversion: > 6'). > app.js: line 19, col 1, 'import' is only available in ES6 (use 'esversion: > 6'). > app.js: line 20, col 1, 'import' is only available in ES6 (use 'esversion: > 6'). > app.js: line 21, col 1, 'import' is only available in ES6 (use 'esversion: > 6'). > app.js: line 23, col 1, 'let' is available in ES6 (use 'esversion: 6') or > Mozilla JS extensions (use moz). > app.js: line 30, col 3, 'object short notation' is available in ES6 (use > 'esversion: 6') or Mozilla JS extensions (use moz). > app.js: line 39, col 1, 'export' is only available in ES6 (use 'esversion: > 6'). > 7 errors > components/action-credential-config.js: line 18, col 1, 'import' is only > available in ES6 (use 'esversion: 6'). > components/action-credential-config.js: line 20, col 1, 'export' is only > available in ES6 (use 'esversion: 6'). > components/action-credential-config.js: line 24, col 38, 'arrow function > syntax (=>)' is only available in ES6 (use 'esversion: 6'). > components/action-credential-config.js: line 30, col 5, 'concise methods' is > available in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz). > components/action-credential-config.js: line 33, col 36, 'arrow function > syntax (=>)' is only available in ES6 (use 'esversion: 6'). > 5 errors > components/action-version-select.js: line 18, col 1, 'import' is only > available in ES6 (use 'esversion: 6'). > components/action-version-select.js: line 20, col 1, 'export' is only > available in ES6 (use 'esversion: 6'). > components/action-version-select.js: line 22, col 5, 'concise methods' is > available in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz). > 3 errors > components/archive-config.js: line 18, col 1, 'import' is only available in > ES6 (use 'esversion: 6'). > components/archive-config.js: line 19, col 1, 'import' is only available in > ES6 (use 'esversion: 6'). > components/archive-config.js: line 21, col 1, 'export' is only available in > ES6 (use 'esversion: 6'). > components/archive-config.js: line 29, col 5, 'concise methods' is available > in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz). > components/archive-config.js: line 33, col 5, 'concise methods' is available > in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz). > components/archive-config.js: line 36, col 5, 'concise methods' is available > in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz). > 6 errors > components/arg-config.js: line 18, col 1, 'import' is only available in ES6 > (use 'esversion: 6'). > components/arg-config.js: line 20, col 1, 'export' is only available in ES6 > (use 'esversion: 6'). > components/arg-config.js: line 33, col 3, 'concise methods' is available in > ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz). > components/arg-config.js: line 38, col 5, 'concise methods' is available in > ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz). > components/arg-config.js: line 41, col 5, 'concise methods' is available in > ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz). > 5 errors > components/bundle-job-details.js: line 18, col 1, 'import' is only available > in ES6 (use 'esversion: 6'). > components/bundle-job-details.js: line 20, col 1, 'export' is only available > in ES6 (use 'esversion: 6'). > components/bundle-job-details.js: line 22, col 5, 'concise methods' is > available in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz). > components/bundle-job-details.js: line 25, col 5, 'concise methods' is > available in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz). > components/bundle-job-details.js: line 28, col 5, 'concise methods' is > available in ES6 (use
[jira] [Updated] (AMBARI-18631) Incorporate database consistency check into main Ambari process
[ https://issues.apache.org/jira/browse/AMBARI-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaly Brodetskyi updated AMBARI-18631: --- Attachment: (was: AMBARI-18631.patch) > Incorporate database consistency check into main Ambari process > --- > > Key: AMBARI-18631 > URL: https://issues.apache.org/jira/browse/AMBARI-18631 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Vitaly Brodetskyi >Assignee: Vitaly Brodetskyi > Fix For: 2.5.0 > > Attachments: AMBARI-18631.patch > > > Currently the database consistency check runs as a separate process prior > Ambari process. The database consistency checker load various modules needed > for performing the validations. (e.g. load stack definitions to be able to > compare service configs from stack with configs from db). > Once database consistency checker completed Ambari server is started. Ambari > server beside others loads the same modules as database consistency checker. > This double initialisation adds time to the ambari server startup time which > could be reduced if the database consistency check is moved into the ambari > server process. > Moreover the database consistency check may check at the beginning if the > database is empty and perform the checks only if there is data in the > database. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18631) Incorporate database consistency check into main Ambari process
[ https://issues.apache.org/jira/browse/AMBARI-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaly Brodetskyi updated AMBARI-18631: --- Attachment: AMBARI-18631.patch > Incorporate database consistency check into main Ambari process > --- > > Key: AMBARI-18631 > URL: https://issues.apache.org/jira/browse/AMBARI-18631 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Vitaly Brodetskyi >Assignee: Vitaly Brodetskyi > Fix For: 2.5.0 > > Attachments: AMBARI-18631.patch > > > Currently the database consistency check runs as a separate process prior > Ambari process. The database consistency checker load various modules needed > for performing the validations. (e.g. load stack definitions to be able to > compare service configs from stack with configs from db). > Once database consistency checker completed Ambari server is started. Ambari > server beside others loads the same modules as database consistency checker. > This double initialisation adds time to the ambari server startup time which > could be reduced if the database consistency check is moved into the ambari > server process. > Moreover the database consistency check may check at the beginning if the > database is empty and perform the checks only if there is data in the > database. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18654) Implement instrumented Lock for profiling/logging
[ https://issues.apache.org/jira/browse/AMBARI-18654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doroszlai, Attila updated AMBARI-18654: --- Status: Patch Available (was: Open) > Implement instrumented Lock for profiling/logging > - > > Key: AMBARI-18654 > URL: https://issues.apache.org/jira/browse/AMBARI-18654 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Doroszlai, Attila >Assignee: Doroszlai, Attila >Priority: Minor > Fix For: 3.0.0, 2.5.0 > > Attachments: AMBARI-18654.patch > > > As part of the reduced reliance on Java locks, we should allow for the lock > implementation provided to business objects to be able to log information > about their acquisition and release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18654) Implement instrumented Lock for profiling/logging
[ https://issues.apache.org/jira/browse/AMBARI-18654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doroszlai, Attila updated AMBARI-18654: --- Attachment: AMBARI-18654.patch > Implement instrumented Lock for profiling/logging > - > > Key: AMBARI-18654 > URL: https://issues.apache.org/jira/browse/AMBARI-18654 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Doroszlai, Attila >Assignee: Doroszlai, Attila >Priority: Minor > Fix For: 3.0.0, 2.5.0 > > Attachments: AMBARI-18654.patch > > > As part of the reduced reliance on Java locks, we should allow for the lock > implementation provided to business objects to be able to log information > about their acquisition and release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18654) Implement instrumented Lock for profiling/logging
Doroszlai, Attila created AMBARI-18654: -- Summary: Implement instrumented Lock for profiling/logging Key: AMBARI-18654 URL: https://issues.apache.org/jira/browse/AMBARI-18654 Project: Ambari Issue Type: Task Components: ambari-server Reporter: Doroszlai, Attila Assignee: Doroszlai, Attila Priority: Minor Fix For: 3.0.0, 2.5.0 As part of the reduced reliance on Java locks, we should allow for the lock implementation provided to business objects to be able to log information about their acquisition and release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18635) Authorizations given to roles, should use generic role-based principals rather than hard-coded pseudo-role-based principals
[
https://issues.apache.org/jira/browse/AMBARI-18635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-18635:
--
Attachment: AMBARI-18635_trunk_02.patch
AMBARI-18635_branch-2.5_02.patch
AMBARI-18635_branch-2.4_02.patch
> Authorizations given to roles, should use generic role-based principals
> rather than hard-coded pseudo-role-based principals
> ---
>
> Key: AMBARI-18635
> URL: https://issues.apache.org/jira/browse/AMBARI-18635
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.4.2
>
> Attachments: AMBARI-18635_branch-2.4_01.patch,
> AMBARI-18635_branch-2.4_02.patch, AMBARI-18635_branch-2.5_01.patch,
> AMBARI-18635_branch-2.5_02.patch, AMBARI-18635_trunk_01.patch,
> AMBARI-18635_trunk_02.patch
>
>
> Authorizations given to roles, should use generic role-based principals
> rather than hard-coded resource types.
> Access to views can be assigned to all users with a given role. The
> implementation for this lead to the creation of hard-coded principals that
> represent the current set of roles. This is not dynamic enough for possibly
> future enhancements where new roles may be created by administrators.
> This needs to be changed such that rather that using the hard-coded
> pseudo-role-principals, the dynamically generated role-principals are to be
> used.
> The hard-coded pseudo-role-principals have the following
> {{adminprincipaltype}} values as opposed to "ROLE":
> * ALL.CLUSTER.ADMINISTRATOR
> * ALL.CLUSTER.OPERATOR
> * ALL.SERVICE.ADMINISTRATOR
> * ALL.SERVICE.OPERATOR
> * ALL.CLUSTER.USER
> These should be removed along with the associated {{adminprincipal}} records.
> Also, the FE should be updated to set permissions using the dynamic
> role-principals.
> Finally, code should be cleaned up to remove unneeded code in
> *
> org.apache.ambari.server.security.authorization.ClusterInheritedPermissionHelper
> *
> org.apache.ambari.server.controller.internal.GroupPrivilegeResourceProvider#getResources
> *
> org.apache.ambari.server.controller.internal.PrivilegeResourceProvider#toEntity
> *
> org.apache.ambari.server.controller.internal.UserPrivilegeResourceProvider#getResources
> *
> org.apache.ambari.server.security.authorization.AuthorizationHelper#isAuthorized
> * org.apache.ambari.server.view.ViewRegistry#addClusterInheritedPermissions
> * ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18615) Fix JSHint errors in Workflow Manager view
[
https://issues.apache.org/jira/browse/AMBARI-18615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15592820#comment-15592820
]
Hadoop QA commented on AMBARI-18615:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834484/AMBARI-18615.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/wfmanager/src/main/resources/ui contrib/views/wfmanager
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8949//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8949//console
This message is automatically generated.
> Fix JSHint errors in Workflow Manager view
> --
>
> Key: AMBARI-18615
> URL: https://issues.apache.org/jira/browse/AMBARI-18615
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: Sangeeta Ravindran
>Assignee: Sangeeta Ravindran
> Fix For: 2.5.0
>
> Attachments: AMBARI-18615.patch
>
>
> When you compile the Workflow Manager view, you see 94 JSHint errors.
> app.js: line 18, col 1, 'import' is only available in ES6 (use 'esversion:
> 6').
> app.js: line 19, col 1, 'import' is only available in ES6 (use 'esversion:
> 6').
> app.js: line 20, col 1, 'import' is only available in ES6 (use 'esversion:
> 6').
> app.js: line 21, col 1, 'import' is only available in ES6 (use 'esversion:
> 6').
> app.js: line 23, col 1, 'let' is available in ES6 (use 'esversion: 6') or
> Mozilla JS extensions (use moz).
> app.js: line 30, col 3, 'object short notation' is available in ES6 (use
> 'esversion: 6') or Mozilla JS extensions (use moz).
> app.js: line 39, col 1, 'export' is only available in ES6 (use 'esversion:
> 6').
> 7 errors
> components/action-credential-config.js: line 18, col 1, 'import' is only
> available in ES6 (use 'esversion: 6').
> components/action-credential-config.js: line 20, col 1, 'export' is only
> available in ES6 (use 'esversion: 6').
> components/action-credential-config.js: line 24, col 38, 'arrow function
> syntax (=>)' is only available in ES6 (use 'esversion: 6').
> components/action-credential-config.js: line 30, col 5, 'concise methods' is
> available in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz).
> components/action-credential-config.js: line 33, col 36, 'arrow function
> syntax (=>)' is only available in ES6 (use 'esversion: 6').
> 5 errors
> components/action-version-select.js: line 18, col 1, 'import' is only
> available in ES6 (use 'esversion: 6').
> components/action-version-select.js: line 20, col 1, 'export' is only
> available in ES6 (use 'esversion: 6').
> components/action-version-select.js: line 22, col 5, 'concise methods' is
> available in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz).
> 3 errors
> components/archive-config.js: line 18, col 1, 'import' is only available in
> ES6 (use 'esversion: 6').
> components/archive-config.js: line 19, col 1, 'import' is only available in
> ES6 (use 'esversion: 6').
> components/archive-config.js: line 21, col 1, 'export' is only available in
> ES6 (use 'esversion: 6').
> components/archive-config.js: line 29, col 5, 'concise methods' is available
> in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz).
> components/archive-config.js: line 33, col 5, 'concise methods' is available
> in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz).
> components/archive-config.js: line 36, col 5, 'concise methods' is available
> in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz).
> 6 errors
> components/arg-config.js: line 18, col 1, 'import' is only available in ES6
> (use 'esversion: 6').
> components/arg-config.js: line 20, col 1, 'export' is only available in ES6
> (use 'esversion: 6').
> components/arg-config.js: line 33, col 3, 'concise methods' is available in
> ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz).
> components/arg-config.js: line 38, col 5, 'concise methods' is available in
> ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz).
> components/arg-config.js: line 41, col
[jira] [Resolved] (AMBARI-17107) Ambari Alert for NameNode Last Checkpoint in NameNode HA
[
https://issues.apache.org/jira/browse/AMBARI-17107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya resolved AMBARI-17107.
Resolution: Duplicate
> Ambari Alert for NameNode Last Checkpoint in NameNode HA
>
>
> Key: AMBARI-17107
> URL: https://issues.apache.org/jira/browse/AMBARI-17107
> Project: Ambari
> Issue Type: Bug
> Components: alerts
>Affects Versions: 2.2.2
> Environment: Hortonworks HDP 2.4.2 with HDFS HA enabled.
>Reporter: Rahul Pathak
> Labels: easyfix
> Fix For: 2.4.0
>
>
> As can be seen in
> https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/alerts/alert_checkpoint_time.py
> At line
> {code}NN_HTTP_ADDRESS_KEY = '{{hdfs-site/dfs.namenode.http-address}}'{code}
> It will not work in case of HA enabled cluster.
> In case of HA this property will not exist and alert will fail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15873) Ambari-Server Unit Test failures in trunk
[
https://issues.apache.org/jira/browse/AMBARI-15873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-15873:
---
Labels: revert (was: reverted)
> Ambari-Server Unit Test failures in trunk
> -
>
> Key: AMBARI-15873
> URL: https://issues.apache.org/jira/browse/AMBARI-15873
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Blocker
> Labels: revert
> Fix For: 2.4.0
>
>
> Unit test failure in ambari-server in trunk
> https://builds.apache.org/job/Ambari-trunk-Commit/4650/console
> Results :
> Failed tests:
> UpgradeCatalog240Test.testExecuteDDLUpdates:227
> Unexpected method call DBAccessor.addColumn("viewinstanceentity",
> org.apache.ambari.server.orm.DBAccessor$DBColumnInfo@1a3492):
> DBAccessor.addColumn("host_role_command",
> capture(org.apache.ambari.server.orm.DBAccessor$DBColumnInfo@1fbce70)):
> expected: 1, actual: 1
> Tests run: 4225, Failures: 1, Errors: 0, Skipped: 32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (AMBARI-17133) Replace underscore character from Storm metrics sink
[ https://issues.apache.org/jira/browse/AMBARI-17133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya reopened AMBARI-17133: > Replace underscore character from Storm metrics sink > > > Key: AMBARI-17133 > URL: https://issues.apache.org/jira/browse/AMBARI-17133 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.4.0 >Reporter: Jungtaek Lim > Fix For: 2.4.0 > > > Since Ambari Metric Service uses "._" as separator for splitting metric and > functions, metric name shouldn't contain "._". > Storm built-in metrics have metric names starting on '__' and with > AMBARI-16946 metric name is placed after '.' which finally makes '._' which > makes parsing messed up. > We should remove '_' characters from metric name or replace them with '-' or > alike. > (Replacing is more safer way if we replace them with special character.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-14883) Express Upgrade - All Service Checks Failure - Queue State
[ https://issues.apache.org/jira/browse/AMBARI-14883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-14883: --- Assignee: Andrew Onischuk > Express Upgrade - All Service Checks Failure - Queue State > -- > > Key: AMBARI-14883 > URL: https://issues.apache.org/jira/browse/AMBARI-14883 > Project: Ambari > Issue Type: Bug > Components: ambari-upgrade >Affects Versions: 2.2.0 >Reporter: Matt Sharp >Assignee: Andrew Onischuk >Priority: Minor > Attachments: AMBARI-14883.patch > > > At the beginning of an Ambari 2.2.0 express upgrade, Ambari prompts you to > manually stop all Yarn queues. At the end of the upgrade it does not prompt > you to manually start all Yarn queues again. This results in the following > error during the All Service Checks phase: > org.apache.hadoop.security.AccessControlException: Queue default is STOPPED. > Cannot accept submission of application: application_1454357083355_0002 > A prompt either needs to be added to update the queue state, or ideally > handled by Ambari entirely (especially since the cluster is stopped with > express upgrade path). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-14590) Error getting timeline metrics
[ https://issues.apache.org/jira/browse/AMBARI-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya resolved AMBARI-14590. Resolution: Invalid > Error getting timeline metrics > -- > > Key: AMBARI-14590 > URL: https://issues.apache.org/jira/browse/AMBARI-14590 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.1.0 > Environment: openjdk version "1.8.0_45" > Red Hat Enterprise Linux Server release 6.5 >Reporter: Sadek > > Hi, > Both the Metrics Collector and Monitors are up and running but none of the > graphs are showing and ambari-server.log is filled with these errors: > ERROR [qtp-client-18] MetricsPropertyProvider:185 - Error getting timeline > metrics. > I do see these errors (for several metrcis) in console: > Metrics with name "mem_cached" not found to compute expression > I have connected to the local HBase instance on the collector node and I see > all tables there: > hbase(main):011:0> list > TABLE > > > METRIC_AGGREGATE > > > METRIC_AGGREGATE_DAILY > > > METRIC_AGGREGATE_HOURLY > > > METRIC_RECORD > > > METRIC_RECORD_DAILY > > > METRIC_RECORD_HOURLY > > > METRIC_RECORD_MINUTE > > > SYSTEM.CATALOG > > > SYSTEM.SEQUENCE > > > SYSTEM.STATS > > > 10 row(s) in 0.0090 seconds > Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-14721) yarn-site properties for Spark Shuffle Aux should be added unconditionally
[ https://issues.apache.org/jira/browse/AMBARI-14721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-14721: --- Attachment: AMBARI-14721.patch > yarn-site properties for Spark Shuffle Aux should be added unconditionally > -- > > Key: AMBARI-14721 > URL: https://issues.apache.org/jira/browse/AMBARI-14721 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: trunk, 2.2.1 >Reporter: Dmytro Grinenko >Assignee: Andrew Onischuk >Priority: Blocker > Fix For: 2.2.1 > > Attachments: AMBARI-14721.patch > > > The spark shuffle related configs should be added unconditionally in HDP-2.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-14590) Error getting timeline metrics
[ https://issues.apache.org/jira/browse/AMBARI-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya reopened AMBARI-14590: > Error getting timeline metrics > -- > > Key: AMBARI-14590 > URL: https://issues.apache.org/jira/browse/AMBARI-14590 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.1.0 > Environment: openjdk version "1.8.0_45" > Red Hat Enterprise Linux Server release 6.5 >Reporter: Sadek > > Hi, > Both the Metrics Collector and Monitors are up and running but none of the > graphs are showing and ambari-server.log is filled with these errors: > ERROR [qtp-client-18] MetricsPropertyProvider:185 - Error getting timeline > metrics. > I do see these errors (for several metrcis) in console: > Metrics with name "mem_cached" not found to compute expression > I have connected to the local HBase instance on the collector node and I see > all tables there: > hbase(main):011:0> list > TABLE > > > METRIC_AGGREGATE > > > METRIC_AGGREGATE_DAILY > > > METRIC_AGGREGATE_HOURLY > > > METRIC_RECORD > > > METRIC_RECORD_DAILY > > > METRIC_RECORD_HOURLY > > > METRIC_RECORD_MINUTE > > > SYSTEM.CATALOG > > > SYSTEM.SEQUENCE > > > SYSTEM.STATS > > > 10 row(s) in 0.0090 seconds > Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-14721) yarn-site properties for Spark Shuffle Aux should be added unconditionally
[ https://issues.apache.org/jira/browse/AMBARI-14721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-14721: --- Assignee: Andrew Onischuk > yarn-site properties for Spark Shuffle Aux should be added unconditionally > -- > > Key: AMBARI-14721 > URL: https://issues.apache.org/jira/browse/AMBARI-14721 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: trunk, 2.2.1 >Reporter: Dmytro Grinenko >Assignee: Andrew Onischuk >Priority: Blocker > Fix For: 2.2.1 > > Attachments: AMBARI-14721.patch > > > The spark shuffle related configs should be added unconditionally in HDP-2.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-17998) When I enable Kerberos,the Hive shell faild to access.
[ https://issues.apache.org/jira/browse/AMBARI-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya resolved AMBARI-17998. Resolution: Invalid > When I enable Kerberos,the Hive shell faild to access. > -- > > Key: AMBARI-17998 > URL: https://issues.apache.org/jira/browse/AMBARI-17998 > Project: Ambari > Issue Type: Bug > Components: security >Affects Versions: 2.2.2 > Environment: Centos6.7 >Reporter: niushuo > Fix For: 2.2.2 > > > When I enable Kerberos,the serverice of Hive was succeed to start.Bui when I > use the command "hive" to go in the Hive shell,it's show some error,show in > below, > 2016-08-02 21:39:26,620 ERROR [pool-5-thread-183]: server.TThreadPoolServer > (TThreadPoolServer.java:run(296)) - Error occurred during processing of > message. > java.lang.RuntimeException: org.apache.thrift.transport.TTransportException: > Peer indicated failure: GSS initiate failed > at > org.apache.thrift.transport.TSaslServerTransport$Factory.getTransport(TSaslServerTransport.java:219) > at > org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingTransportFactory$1.run(HadoopThriftAuthBridge.java:739) > at > org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingTransportFactory$1.run(HadoopThriftAuthBridge.java:736) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:356) > at > org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1637) > at > org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingTransportFactory.getTransport(HadoopThriftAuthBridge.java:736) > at > org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:268) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.apache.thrift.transport.TTransportException: Peer indicated > failure: GSS initiate failed > at > org.apache.thrift.transport.TSaslTransport.receiveSaslMessage(TSaslTransport.java:199) > at > org.apache.thrift.transport.TSaslServerTransport.handleSaslStartMessage(TSaslServerTransport.java:125) > at > org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:271) > at > org.apache.thrift.transport.TSaslServerTransport.open(TSaslServerTransport.java:41) > at > org.apache.thrift.transport.TSaslServerTransport$Factory.getTransport(TSaslServerTransport.java:216) > ... 10 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-17997) When i enable kerberos,MapReduce2 and Yarn both faied to start.
[
https://issues.apache.org/jira/browse/AMBARI-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya resolved AMBARI-17997.
Resolution: Invalid
> When i enable kerberos,MapReduce2 and Yarn both faied to start.
> ---
>
> Key: AMBARI-17997
> URL: https://issues.apache.org/jira/browse/AMBARI-17997
> Project: Ambari
> Issue Type: Bug
> Components: security
>Affects Versions: 2.2.2
> Environment: Centos6.7
>Reporter: niushuo
>
> No kerberos,the cluster was OK!But,When I enable kerberos,MapReduce2 and Yarn
> both faied to start.The log like this,how can I do to fix the problem?
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/historyserver.py",
> line 182, in
> HistoryServer().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 219, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/historyserver.py",
> line 92, in start
> self.configure(env) # FOR SECURITY
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/historyserver.py",
> line 55, in configure
> yarn(name="historyserver")
> File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py",
> line 89, in thunk
> return fn(*args, **kwargs)
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py",
> line 71, in yarn
> recursive_chmod=True
> File "/usr/lib/python2.6/site-packages/resource_management/core/base.py",
> line 154, in __init__
> self.env.run()
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 160, in run
> self.run_action(resource, action)
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 124, in run_action
> provider_action()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 463, in action_create_on_execute
> self.action_delayed("create")
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 460, in action_delayed
> self.get_hdfs_resource_executor().action_delayed(action_name, self)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 250, in action_delayed
> self._assert_valid()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 234, in _assert_valid
> self.target_status = self._get_file_status(target)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 295, in _get_file_status
> list_status = self.util.run_command(target, 'GETFILESTATUS',
> method='GET', ignore_status_codes=['404'], assertable_result=False)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 195, in run_command
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'curl -sS -L -w
> '%{http_code}' -X GET --negotiate -u :
> 'http://bigdata-32.bigdata:50070/webhdfs/v1/app-logs?op=GETFILESTATUS=hdfs''
> returned status_code=401.
>
>
>
> Error 401 Authentication required
>
> HTTP ERROR 401
> Problem accessing /webhdfs/v1/app-logs. Reason:
> Authentication requiredPowered by
> Jetty://
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (AMBARI-17997) When i enable kerberos,MapReduce2 and Yarn both faied to start.
[
https://issues.apache.org/jira/browse/AMBARI-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya reopened AMBARI-17997:
> When i enable kerberos,MapReduce2 and Yarn both faied to start.
> ---
>
> Key: AMBARI-17997
> URL: https://issues.apache.org/jira/browse/AMBARI-17997
> Project: Ambari
> Issue Type: Bug
> Components: security
>Affects Versions: 2.2.2
> Environment: Centos6.7
>Reporter: niushuo
>
> No kerberos,the cluster was OK!But,When I enable kerberos,MapReduce2 and Yarn
> both faied to start.The log like this,how can I do to fix the problem?
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/historyserver.py",
> line 182, in
> HistoryServer().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 219, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/historyserver.py",
> line 92, in start
> self.configure(env) # FOR SECURITY
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/historyserver.py",
> line 55, in configure
> yarn(name="historyserver")
> File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py",
> line 89, in thunk
> return fn(*args, **kwargs)
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py",
> line 71, in yarn
> recursive_chmod=True
> File "/usr/lib/python2.6/site-packages/resource_management/core/base.py",
> line 154, in __init__
> self.env.run()
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 160, in run
> self.run_action(resource, action)
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 124, in run_action
> provider_action()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 463, in action_create_on_execute
> self.action_delayed("create")
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 460, in action_delayed
> self.get_hdfs_resource_executor().action_delayed(action_name, self)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 250, in action_delayed
> self._assert_valid()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 234, in _assert_valid
> self.target_status = self._get_file_status(target)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 295, in _get_file_status
> list_status = self.util.run_command(target, 'GETFILESTATUS',
> method='GET', ignore_status_codes=['404'], assertable_result=False)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 195, in run_command
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'curl -sS -L -w
> '%{http_code}' -X GET --negotiate -u :
> 'http://bigdata-32.bigdata:50070/webhdfs/v1/app-logs?op=GETFILESTATUS=hdfs''
> returned status_code=401.
>
>
>
> Error 401 Authentication required
>
> HTTP ERROR 401
> Problem accessing /webhdfs/v1/app-logs. Reason:
> Authentication requiredPowered by
> Jetty://
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMBARI-15746) ambari-agent start failed
[ https://issues.apache.org/jira/browse/AMBARI-15746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya resolved AMBARI-15746. Resolution: Invalid > ambari-agent start failed > -- > > Key: AMBARI-15746 > URL: https://issues.apache.org/jira/browse/AMBARI-15746 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: RedHat Enterprise Linux 6.7 >Reporter: Adrian Blakey >Priority: Blocker > > The agent does not start. Looks like OpenSSL is missing - it isn't. > ambari-agent start > Verifying Python version compatibility... > Using python /usr/bin/python > Checking for previously running Ambari Agent... > /var/run/ambari-agent/ambari-agent.pid found with no process. Removing 7128... > Starting ambari-agent > Verifying ambari-agent process status... > ERROR: ambari-agent start failed. For more details, see > /var/log/ambari-agent/ambari-agent.out: > > Can't open library libX11.so.6: libssl.so: cannot open shared object file: No > such file or directory > > Agent out at: /var/log/ambari-agent/ambari-agent.out > Agent log at: /var/log/ambari-agent/ambari-agent.log > Red Hat Enterprise Linux Server release 6.7 (Santiago) > java version "1.8.0_77" > Java(TM) SE Runtime Environment (build 1.8.0_77-b03) > Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode) > Package openssl-1.0.1e-42.el6_7.2.x86_64 already installed and latest version > Package libXt-1.1.4-6.1.el6.x86_64 already installed and latest version > Package libX11-1.6.0-6.el6.x86_64 already installed and latest version -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-15746) ambari-agent start failed
[ https://issues.apache.org/jira/browse/AMBARI-15746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya reopened AMBARI-15746: > ambari-agent start failed > -- > > Key: AMBARI-15746 > URL: https://issues.apache.org/jira/browse/AMBARI-15746 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: RedHat Enterprise Linux 6.7 >Reporter: Adrian Blakey >Priority: Blocker > > The agent does not start. Looks like OpenSSL is missing - it isn't. > ambari-agent start > Verifying Python version compatibility... > Using python /usr/bin/python > Checking for previously running Ambari Agent... > /var/run/ambari-agent/ambari-agent.pid found with no process. Removing 7128... > Starting ambari-agent > Verifying ambari-agent process status... > ERROR: ambari-agent start failed. For more details, see > /var/log/ambari-agent/ambari-agent.out: > > Can't open library libX11.so.6: libssl.so: cannot open shared object file: No > such file or directory > > Agent out at: /var/log/ambari-agent/ambari-agent.out > Agent log at: /var/log/ambari-agent/ambari-agent.log > Red Hat Enterprise Linux Server release 6.7 (Santiago) > java version "1.8.0_77" > Java(TM) SE Runtime Environment (build 1.8.0_77-b03) > Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode) > Package openssl-1.0.1e-42.el6_7.2.x86_64 already installed and latest version > Package libXt-1.1.4-6.1.el6.x86_64 already installed and latest version > Package libX11-1.6.0-6.el6.x86_64 already installed and latest version -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-16178) 'llap' queue minimum recommended size is not persistent across HSI on and off.
[ https://issues.apache.org/jira/browse/AMBARI-16178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar resolved AMBARI-16178. -- Resolution: Fixed > 'llap' queue minimum recommended size is not persistent across HSI on and off. > -- > > Key: AMBARI-16178 > URL: https://issues.apache.org/jira/browse/AMBARI-16178 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > Attachments: AMBARI-16178.patch > > > - As we are recommending the minimum llap queue size require dto have a > meaningful run of LLAP, the minimum required llap queue size is not > persistent across HSI on and off. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-17107) Ambari Alert for NameNode Last Checkpoint in NameNode HA
[
https://issues.apache.org/jira/browse/AMBARI-17107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya reopened AMBARI-17107:
> Ambari Alert for NameNode Last Checkpoint in NameNode HA
>
>
> Key: AMBARI-17107
> URL: https://issues.apache.org/jira/browse/AMBARI-17107
> Project: Ambari
> Issue Type: Bug
> Components: alerts
>Affects Versions: 2.2.2
> Environment: Hortonworks HDP 2.4.2 with HDFS HA enabled.
>Reporter: Rahul Pathak
> Labels: easyfix
> Fix For: 2.4.0
>
>
> As can be seen in
> https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/alerts/alert_checkpoint_time.py
> At line
> {code}NN_HTTP_ADDRESS_KEY = '{{hdfs-site/dfs.namenode.http-address}}'{code}
> It will not work in case of HA enabled cluster.
> In case of HA this property will not exist and alert will fail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMBARI-14887) Atlas Integration : Fix Atlas-Kafka properties for Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-14887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya resolved AMBARI-14887.
Resolution: Duplicate
> Atlas Integration : Fix Atlas-Kafka properties for Blueprints
> -
>
> Key: AMBARI-14887
> URL: https://issues.apache.org/jira/browse/AMBARI-14887
> Project: Ambari
> Issue Type: Bug
>Reporter: Tom Beerbower
>Assignee: Tom Beerbower
>
> The mechanism of setting the topology related properties(kafka and zk) in the
> agent will result in issues with blueprint installs.
> Because each node in a blueprint provisioned cluster is provisioned
> independently of other nodes, the blueprint topology manager needs to block
> provisioning of all nodes until all hosts required for configuration topology
> resolution are known. This is determined in BlueprintConfigurationProcessor.
> Because these configurations are not registered with the blueprint
> configuration processor it is possible for the atlas host to be provisioned
> prior to the Kafka hosts being known which result in the failure of the agent
> to set these topology related properties.
> In BlueprintConfigurationProcessor you will need too register updaters for
> all of the topology related properties, in this case
> "atlas.kafka.bootstrap.servers" and "atlas.kafka.zookeeper.connect".
> For example:
> atlasPropsMap.put("atlas.kafka.bootstrap.servers", new
> MultipleHostTopologyUpdater("KAFKA_BROKER"));
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMBARI-17263) Fix for following for Hive Server Interactive : (1). Updates to 'llapstatus' command while querying LLAP app status. (2). Adding validation check for config 'hive.serv
[ https://issues.apache.org/jira/browse/AMBARI-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar resolved AMBARI-17263. -- Resolution: Fixed > Fix for following for Hive Server Interactive : (1). Updates to 'llapstatus' > command while querying LLAP app status. (2). Adding validation check for > config 'hive.server2.enable.doAs'. > - > > Key: AMBARI-17263 > URL: https://issues.apache.org/jira/browse/AMBARI-17263 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > Attachments: AMBARI-17263.patch > > > - Fix for following for Hive Server Interactive : > (1). 'llapstatus' command timeout of 0 while querying LLAP app status, update > retry wait time to 2 seconds and allowing retry on 'COMPLETE' state > (2). Add validation check for config 'hive.server2.enable.doAs'. the value > for config shows always stay false. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16178) 'llap' queue minimum recommended size is not persistent across HSI on and off.
[ https://issues.apache.org/jira/browse/AMBARI-16178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar updated AMBARI-16178: - Attachment: AMBARI-16178.patch > 'llap' queue minimum recommended size is not persistent across HSI on and off. > -- > > Key: AMBARI-16178 > URL: https://issues.apache.org/jira/browse/AMBARI-16178 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > Attachments: AMBARI-16178.patch > > > - As we are recommending the minimum llap queue size require dto have a > meaningful run of LLAP, the minimum required llap queue size is not > persistent across HSI on and off. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-16178) 'llap' queue minimum recommended size is not persistent across HSI on and off.
[ https://issues.apache.org/jira/browse/AMBARI-16178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar reopened AMBARI-16178: -- > 'llap' queue minimum recommended size is not persistent across HSI on and off. > -- > > Key: AMBARI-16178 > URL: https://issues.apache.org/jira/browse/AMBARI-16178 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > Attachments: AMBARI-16178.patch > > > - As we are recommending the minimum llap queue size require dto have a > meaningful run of LLAP, the minimum required llap queue size is not > persistent across HSI on and off. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-14887) Atlas Integration : Fix Atlas-Kafka properties for Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-14887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya reopened AMBARI-14887:
> Atlas Integration : Fix Atlas-Kafka properties for Blueprints
> -
>
> Key: AMBARI-14887
> URL: https://issues.apache.org/jira/browse/AMBARI-14887
> Project: Ambari
> Issue Type: Bug
>Reporter: Tom Beerbower
>Assignee: Tom Beerbower
>
> The mechanism of setting the topology related properties(kafka and zk) in the
> agent will result in issues with blueprint installs.
> Because each node in a blueprint provisioned cluster is provisioned
> independently of other nodes, the blueprint topology manager needs to block
> provisioning of all nodes until all hosts required for configuration topology
> resolution are known. This is determined in BlueprintConfigurationProcessor.
> Because these configurations are not registered with the blueprint
> configuration processor it is possible for the atlas host to be provisioned
> prior to the Kafka hosts being known which result in the failure of the agent
> to set these topology related properties.
> In BlueprintConfigurationProcessor you will need too register updaters for
> all of the topology related properties, in this case
> "atlas.kafka.bootstrap.servers" and "atlas.kafka.zookeeper.connect".
> For example:
> atlasPropsMap.put("atlas.kafka.bootstrap.servers", new
> MultipleHostTopologyUpdater("KAFKA_BROKER"));
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16089) Atlas Integration : set atlas.cluster.name in hive-site
[ https://issues.apache.org/jira/browse/AMBARI-16089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-16089: --- Attachment: AMBARI-16089.patch > Atlas Integration : set atlas.cluster.name in hive-site > --- > > Key: AMBARI-16089 > URL: https://issues.apache.org/jira/browse/AMBARI-16089 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > Attachments: AMBARI-16089.patch > > > After deploying Hive+Atlas via Ambari, the value of 'atlas.cluster.name‘ in > 'Advanced hive-site’ is ‘default’. This results in incorrect value in entity > notifications to Ranger. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17263) Fix for following for Hive Server Interactive : (1). Updates to 'llapstatus' command while querying LLAP app status. (2). Adding validation check for config 'hive.serve
[ https://issues.apache.org/jira/browse/AMBARI-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar updated AMBARI-17263: - Attachment: AMBARI-17263.patch > Fix for following for Hive Server Interactive : (1). Updates to 'llapstatus' > command while querying LLAP app status. (2). Adding validation check for > config 'hive.server2.enable.doAs'. > - > > Key: AMBARI-17263 > URL: https://issues.apache.org/jira/browse/AMBARI-17263 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > Attachments: AMBARI-17263.patch > > > - Fix for following for Hive Server Interactive : > (1). 'llapstatus' command timeout of 0 while querying LLAP app status, update > retry wait time to 2 seconds and allowing retry on 'COMPLETE' state > (2). Add validation check for config 'hive.server2.enable.doAs'. the value > for config shows always stay false. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-16090) Atlas Integration : add defult login method configuration
[
https://issues.apache.org/jira/browse/AMBARI-16090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya reopened AMBARI-16090:
> Atlas Integration : add defult login method configuration
> -
>
> Key: AMBARI-16090
> URL: https://issues.apache.org/jira/browse/AMBARI-16090
> Project: Ambari
> Issue Type: Bug
>Reporter: Tom Beerbower
>Assignee: Tom Beerbower
>
> To enable login to Atlas UI, following properties have to be manually added
> to ‘Custom application-properties’ in Atlas.
> {code}
> atlas.login.method=file
> atlas.login.credentials.file=/etc/atlas/conf/users-credentials.properties
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (AMBARI-17263) Fix for following for Hive Server Interactive : (1). Updates to 'llapstatus' command while querying LLAP app status. (2). Adding validation check for config 'hive.serv
[ https://issues.apache.org/jira/browse/AMBARI-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar reopened AMBARI-17263: -- > Fix for following for Hive Server Interactive : (1). Updates to 'llapstatus' > command while querying LLAP app status. (2). Adding validation check for > config 'hive.server2.enable.doAs'. > - > > Key: AMBARI-17263 > URL: https://issues.apache.org/jira/browse/AMBARI-17263 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > > - Fix for following for Hive Server Interactive : > (1). 'llapstatus' command timeout of 0 while querying LLAP app status, update > retry wait time to 2 seconds and allowing retry on 'COMPLETE' state > (2). Add validation check for config 'hive.server2.enable.doAs'. the value > for config shows always stay false. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15733) Atlas Integration : Support Atlas HA
[ https://issues.apache.org/jira/browse/AMBARI-15733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-15733: --- Attachment: AMBARI-15733.patch > Atlas Integration : Support Atlas HA > > > Key: AMBARI-15733 > URL: https://issues.apache.org/jira/browse/AMBARI-15733 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > Attachments: AMBARI-15733.patch > > > # set cardinality to 1+ in Atlas stack definition > # expose Atlas configuration to enable HA (atlas.server.ha.enabled) > # set Atlas configuration for server id list (atlas.server.ids) > # set Atlas configuration properties for hosts (atlas.server.host.id1, ...) > # expose Atlas host component ha_state property in Ambari REST API. > # Update Ambari quick link definition in Atlas stack definition to show > ha_state. (See Yarn RM quick links) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16263) Falcon server start fails
[
https://issues.apache.org/jira/browse/AMBARI-16263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-16263:
---
Attachment: AMBARI-16263-2.patch
> Falcon server start fails
> -
>
> Key: AMBARI-16263
> URL: https://issues.apache.org/jira/browse/AMBARI-16263
> Project: Ambari
> Issue Type: Bug
>Reporter: Tom Beerbower
>Assignee: Tom Beerbower
> Attachments: AMBARI-16263-2.patch
>
>
> Deployed HDP-2.5 and Falcon server failed to start.
> {code}
> cat /var/log/falcon/falcon.out.20160504002*
> Error: Could not find or load main class org.apache.falcon.FalconServer
> Error: Could not find or load main class org.apache.falcon.FalconServer
> Error: Could not find or load main class org.apache.falcon.FalconServer
> {code}
> The command to start, in Ambari is:
> {code}
> Execute['/usr/hdp/current/falcon-server/bin/falcon-start -port 15000']
> {'environment': {'HADOOP_HOME': '/usr/hdp/current/hadoop-client'}, 'path':
> ['/usr/hdp/current/hadoop-client/bin'], 'user': 'falcon'}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMBARI-15984) Atlas Integration : Expose Atlas audit configuration
[
https://issues.apache.org/jira/browse/AMBARI-15984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya resolved AMBARI-15984.
Resolution: Duplicate
> Atlas Integration : Expose Atlas audit configuration
>
>
> Key: AMBARI-15984
> URL: https://issues.apache.org/jira/browse/AMBARI-15984
> Project: Ambari
> Issue Type: Bug
>Reporter: Tom Beerbower
>Assignee: Tom Beerbower
>
> Need to expose the following configuration for Atlas in
> atlas-application.properties ...
> {code}
> atlas.audit.hbase.tablename=ATLAS_ENTITY_AUDIT_EVENTS
> atlas.audit.zookeeper.session.timeout.ms=1000
> atlas.audit.hbase.zookeeper.quorum=localhost:2181
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15818) Ambari should manage Atlas log4j.xml
[ https://issues.apache.org/jira/browse/AMBARI-15818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-15818: --- Attachment: AMBARI-15818.patch > Ambari should manage Atlas log4j.xml > > > Key: AMBARI-15818 > URL: https://issues.apache.org/jira/browse/AMBARI-15818 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > Fix For: 2.4.0 > > Attachments: AMBARI-15818.patch > > > Currently, Ambari does not provide a means of editing the Atlas log4j.xml > file which is problematic for users that want to make changes to the log > levels. Ambari/Atlas integration should allow for this file to be managed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15592758#comment-15592758
]
Hadoop QA commented on AMBARI-17041:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834482/AMBARI-17041-branch-2.5.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8948//console
This message is automatically generated.
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Fix For: 2.5.0
>
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-July22.patch,
> AMBARI-17041-branch-2.5.patch, AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk-fix-regression.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16464) Atlas Integration : Atlas fails to come up with solr as indexing search when the zookeeper quorum has more than one host
[
https://issues.apache.org/jira/browse/AMBARI-16464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-16464:
---
Attachment: AMBARI-16464.patch
> Atlas Integration : Atlas fails to come up with solr as indexing search when
> the zookeeper quorum has more than one host
>
>
> Key: AMBARI-16464
> URL: https://issues.apache.org/jira/browse/AMBARI-16464
> Project: Ambari
> Issue Type: Bug
>Reporter: Tom Beerbower
>Assignee: Tom Beerbower
> Attachments: AMBARI-16464.patch
>
>
> Atlas fails to communicate with solr when the zookeeper quorum has more than
> one host, as a result of this atlas fails to comeup.
> Actually the config parameter "atlas.graph.index.search.solr.zookeeper-url"
> value is set to "{{zookeeper_quorum}}/logsearch". Since there are more than
> one zookeeper servers deployed, this value evaluates to
> "[os-r6-apathan-atlas-erie-nosec-3.openstacklocal:2181,
> os-r6-apathan-atlas-erie-nosec-2.openstacklocal:2181/logsearch]" which seems
> to wrong.
> Below is the application log of atlas
> {noformat}
> 2016-05-05 18:32:42,394 DEBUG - [main:] ~ atlas.graph.index.search.directory
> = /var/lib/atlas/data/es (ApplicationProperties:86)
> 2016-05-05 18:32:42,394 DEBUG - [main:] ~
> atlas.graph.index.search.elasticsearch.client-only = false
> (ApplicationProperties:86)
> 2016-05-05 18:32:42,394 DEBUG - [main:] ~
> atlas.graph.index.search.elasticsearch.local-mode = true
> (ApplicationProperties:86)
> 2016-05-05 18:32:42,394 DEBUG - [main:] ~ atlas.graph.index.search.solr.mode
> = cloud (ApplicationProperties:86)
> 2016-05-05 18:32:42,395 DEBUG - [main:] ~
> atlas.graph.index.search.solr.zookeeper-url =
> [os-r6-apathan-atlas-erie-nosec-3.openstacklocal:2181,
> os-r6-apathan-atlas-erie-nosec-2.openstacklocal:2181/logsearch]
> (ApplicationProperties:86)
> 2016-05-05 18:32:42,395 DEBUG - [main:] ~ atlas.graph.storage.backend = hbase
> (ApplicationProperties:86)
> {noformat}
> The exception because of this
> {noformat}
> 2016-05-05 18:33:11,212 INFO - [main:] ~ Session: 0x25480887e74006a closed
> (ZooKeeper:684)
> 2016-05-05 18:33:11,215 WARN - [main:] ~ FAILED
> o.e.j.w.WebAppContext@65064ae0{/,file:/var/lib/atlas/server/webapp/atlas/,STARTING}{/var/lib/atlas/server/webapp/atlas}:
> java.lang.ExceptionInInitializerError (AbstractLifeCycle:212)
> java.lang.ExceptionInInitializerError
> at
> org.apache.atlas.repository.graph.DeleteHandler.(DeleteHandler.java:48)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at
> org.apache.atlas.ApplicationProperties.getClass(ApplicationProperties.java:99)
> at
> org.apache.atlas.RepositoryMetadataModule.getDeleteHandler(RepositoryMetadataModule.java:114)
> at
> org.apache.atlas.RepositoryMetadataModule.configure(RepositoryMetadataModule.java:90)
> at com.google.inject.AbstractModule.configure(AbstractModule.java:62)
> at
> com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:340)
> at com.google.inject.spi.Elements.getElements(Elements.java:110)
> at
> com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:138)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:104)
> at com.google.inject.Guice.createInjector(Guice.java:96)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62)
> at
> org.apache.atlas.web.listeners.GuiceServletConfig.getInjector(GuiceServletConfig.java:79)
> at
> com.google.inject.servlet.GuiceServletContextListener.contextInitialized(GuiceServletContextListener.java:47)
> at
> org.apache.atlas.web.listeners.GuiceServletConfig.contextInitialized(GuiceServletConfig.java:148)
> at
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444)
> at
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> at
>
[jira] [Updated] (AMBARI-16693) Atlas Server script error during upgrade.
[
https://issues.apache.org/jira/browse/AMBARI-16693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-16693:
---
Attachment: AMBARI-16693.patch
> Atlas Server script error during upgrade.
> -
>
> Key: AMBARI-16693
> URL: https://issues.apache.org/jira/browse/AMBARI-16693
> Project: Ambari
> Issue Type: Bug
>Reporter: Tom Beerbower
>Assignee: Tom Beerbower
> Attachments: AMBARI-16693.patch
>
>
> An error {{kafka_broker_hosts' was not found in configurations dictionary!}}
> is seen during upgrade ...
> {code}
> {
> "href" :
> "http://172.22.64.238:8080/api/v1/clusters/cl1/requests/59/tasks/597;,
> "Tasks" : {
> "attempt_cnt" : 1,
> "cluster_name" : "cl1",
> "command" : "STOP",
> "command_detail" : "ATLAS_SERVER STOP",
> "end_time" : 1463369271424,
> "error_log" : "/var/lib/ambari-agent/data/errors-597.txt",
> "exit_code" : 1,
> "host_name" : "os-r6-swuvps-upg-sanity-211-5.openstacklocal",
> "id" : 597,
> "output_log" : "/var/lib/ambari-agent/data/output-597.txt",
> "request_id" : 59,
> "role" : "ATLAS_SERVER",
> "stage_id" : 0,
> "start_time" : 1463369268252,
> "status" : "FAILED",
> "stderr" : "Traceback (most recent call last):\n File
> \"/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata_server.py\",
> line 165, in \nMetadataServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 254, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata_server.py\",
> line 82, in stop\nimport params\n File
> \"/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py\",
> line 139, in \nif not len(kafka_broker_hosts) == 0:\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/config_dictionary.py\",
> line 73, in __getattr__\nraise Fail(\"Configuration parameter '\" +
> self.name + \"' was not found in configurations
> dictionary!\")\nresource_management.core.exceptions.Fail: Configuration
> parameter 'kafka_broker_hosts' was not found in configurations dictionary!",
> "stdout" : "\n\nCommand failed after 1 tries\n",
> "structured_out" : { }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMBARI-16689) Atlas Integration : Set atlas.kafka.auto.commit.enable to false
[ https://issues.apache.org/jira/browse/AMBARI-16689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya resolved AMBARI-16689. Resolution: Duplicate > Atlas Integration : Set atlas.kafka.auto.commit.enable to false > --- > > Key: AMBARI-16689 > URL: https://issues.apache.org/jira/browse/AMBARI-16689 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > > As part of ATLAS-629, atlas-application.properties includes the following > property atlas.kafka.auto.commit.enable=false. Needs to be set as part of > Ambari installation as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-16689) Atlas Integration : Set atlas.kafka.auto.commit.enable to false
[ https://issues.apache.org/jira/browse/AMBARI-16689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya reopened AMBARI-16689: > Atlas Integration : Set atlas.kafka.auto.commit.enable to false > --- > > Key: AMBARI-16689 > URL: https://issues.apache.org/jira/browse/AMBARI-16689 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > > As part of ATLAS-629, atlas-application.properties includes the following > property atlas.kafka.auto.commit.enable=false. Needs to be set as part of > Ambari installation as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16690) Atlas Integration : Change default expanded web app directory
[ https://issues.apache.org/jira/browse/AMBARI-16690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-16690: --- Attachment: AMBARI-16689.patch > Atlas Integration : Change default expanded web app directory > - > > Key: AMBARI-16690 > URL: https://issues.apache.org/jira/browse/AMBARI-16690 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > Attachments: AMBARI-16689.patch > > > The Atlas web app is currently expanded to /var/lib/atlas. It should be in > /usr/hdp/.../atlas-server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16730) Atlas Integration : Rename atlas lineage configurations
[ https://issues.apache.org/jira/browse/AMBARI-16730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-16730: --- Attachment: AMBARI-16730.patch > Atlas Integration : Rename atlas lineage configurations > --- > > Key: AMBARI-16730 > URL: https://issues.apache.org/jira/browse/AMBARI-16730 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Tom Beerbower >Assignee: Tom Beerbower > Fix For: 2.4.0 > > Attachments: AMBARI-16730.patch > > > As part of ATLAS-713, the following changes are required in atlas > configuration that is set by Ambari: > # atlas.lineage.hive.table.schema.query.Table renamed to > atlas.lineage.schema.query.Table > # atlas.lineage.hive.table.schema.query.hive_table renamed to > atlas.lineage.schema.query.hive_table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16781) Atlas HA configuration Property Changed
[ https://issues.apache.org/jira/browse/AMBARI-16781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-16781: --- Attachment: AMBARI-16781-2.patch > Atlas HA configuration Property Changed > --- > > Key: AMBARI-16781 > URL: https://issues.apache.org/jira/browse/AMBARI-16781 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Erik Bergenholtz >Assignee: Tom Beerbower >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16781-2.patch > > > The Atlas HA properties to designate ha hosts has changed from: > atlas.server.host.id to atlas.server.address.id this causes Atlas to not be > able to start in HA mode. The following changes need to be made: > - resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py > - > resources/stacks/HDP/2.5/services/ATLAS/configuration/application-properties.xml -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17262) Atlas Integration : Remove {{atlas_conf_dir}} from HADOOP_CLASSPATH in hive-env.
[
https://issues.apache.org/jira/browse/AMBARI-17262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-17262:
---
Attachment: AMBARI-17262.patch
> Atlas Integration : Remove {{atlas_conf_dir}} from HADOOP_CLASSPATH in
> hive-env.
>
>
> Key: AMBARI-17262
> URL: https://issues.apache.org/jira/browse/AMBARI-17262
> Project: Ambari
> Issue Type: Bug
>Reporter: Tom Beerbower
>Assignee: Tom Beerbower
> Attachments: AMBARI-17262.patch
>
>
> In Hive configuration ‘Advanced hive-env’ :
> {code}
> export
> HADOOP_CLASSPATH={{atlas_conf_dir}}:{{atlas_home_dir}}/hook/hive:${HADOOP_CLASSPATH}
> {code}
> remove
> {code}
> {{atlas_conf_dir}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17273) With Atlas HA enabled, atlas instance fails to come up with "Unable to find IDs matching any local host and port binding among id1"
[
https://issues.apache.org/jira/browse/AMBARI-17273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-17273:
---
Attachment: AMBARI-17273.patch
> With Atlas HA enabled, atlas instance fails to come up with "Unable to find
> IDs matching any local host and port binding among id1"
> ---
>
> Key: AMBARI-17273
> URL: https://issues.apache.org/jira/browse/AMBARI-17273
> Project: Ambari
> Issue Type: Bug
>Reporter: Tom Beerbower
>Assignee: Tom Beerbower
> Attachments: AMBARI-17273.patch
>
>
> Atlas fails to come up with below error. This is because if ID information
> for all atlas instances is not generated and updated in
> atlas-application.properties.
> {noformat}
> 2016-06-14 10:48:23,249 WARN - [main:] ~ Failed startup of context
> o.e.j.w.WebAppContext@2ad31d76{/,file:/grid/0/hdp/2.5.0.0-723/atlas/server/webapp/atlas/,STARTING}{/usr/hdp/current/atlas-server/server/webapp/atlas}
> (WebAppContext:514)
> java.lang.RuntimeException: org.apache.atlas.AtlasException: Could not find
> server id for this instance. Unable to find IDs matching any local host and
> port binding among id1
> at org.apache.atlas.service.Services.start(Services.java:48)
> at
> org.apache.atlas.web.listeners.GuiceServletConfig.startServices(GuiceServletConfig.java:142)
> at
> org.apache.atlas.web.listeners.GuiceServletConfig.contextInitialized(GuiceServletConfig.java:136)
> at
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444)
> at
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
> at org.eclipse.jetty.server.Server.start(Server.java:387)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> at org.eclipse.jetty.server.Server.doStart(Server.java:354)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at
> org.apache.atlas.web.service.EmbeddedServer.start(EmbeddedServer.java:93)
> at org.apache.atlas.Atlas.main(Atlas.java:113)
> Caused by: org.apache.atlas.AtlasException: Could not find server id for this
> instance. Unable to find IDs matching any local host and port binding among
> id1
> at
> org.apache.atlas.ha.AtlasServerIdSelector.selectServerId(AtlasServerIdSelector.java:77)
> at
> org.apache.atlas.web.service.ActiveInstanceElectorService.start(ActiveInstanceElectorService.java:105)
> at org.apache.atlas.service.Services.start(Services.java:45)
> ... 19 more
> 2016-06-14 10:48:23,284 INFO - [main:] ~ Started
> ServerConnector@255af999{HTTP/1.1}{0.0.0.0:21000} (ServerConnector:266)
> {noformat}
> Atlas-application.properties not updated with all other instance information
> leading to atlas startup failure
> {noformat}
> [root@ayubTesting-3 ~]# cat /etc/atlas/conf/atlas-application.properties
> # Generated by Apache Ambari. Tue Jun 14 10:47:47 2016
> atlas.audit.hbase.tablename=ATLAS_ENTITY_AUDIT_EVENTS
> atlas.audit.hbase.zookeeper.quorum=ayubtesting-2.openstacklocal,ayubtesting-3.openstacklocal
> atlas.audit.zookeeper.session.timeout.ms=1000
> atlas.auth.policy.file=/etc/atlas/conf/policy-store.txt
> atlas.authentication.keytab=/etc/security/keytabs/atlas.service.keytab
> atlas.authentication.method=simple
> atlas.authentication.method.file=true
> atlas.authentication.method.file.filename=/etc/atlas/conf/users-credentials.properties
> atlas.authentication.method.kerberos=false
> atlas.authentication.method.ldap=false
> atlas.authentication.method.ldap.type=ldap
> atlas.authentication.method.ldap.url=
> atlas.authentication.principal=atlas
> atlas.authorizer.impl=simple
> atlas.cluster.name=cl1
> atlas.enableTLS=false
>
[jira] [Updated] (AMBARI-17144) Atlas Integration : Required changes for atlas-application.properties
[
https://issues.apache.org/jira/browse/AMBARI-17144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-17144:
---
Attachment: AMBARI-17144.patch
> Atlas Integration : Required changes for atlas-application.properties
> -
>
> Key: AMBARI-17144
> URL: https://issues.apache.org/jira/browse/AMBARI-17144
> Project: Ambari
> Issue Type: Bug
>Reporter: Tom Beerbower
>Assignee: Tom Beerbower
> Fix For: 2.4.0
>
> Attachments: AMBARI-17144.patch
>
>
> Changes in ATLAS-820 require following configurations to be present in
> atlas-application.properties:
> {code}
> atlas.authentication.method.kerberos=false
> atlas.authentication.method.file=true
> atlas.authentication.method.ldap=false
> atlas.authentication.method.file.filename={{atlas_login_credentials_file}}
> atlas.authentication.method.ldap.type=ldap|ad
> atlas.authentication.method.ldap.url=
> {code}
>
> When Kerberos is enabled, following configurations need to be set/added:
> {code}
> atlas.authentication.method.kerberos=true
> atlas.authentication.method.kerberos.keytab=/etc/security/keytabs/spnego.service.keytab
> atlas.authentication.method.kerberos.principal=HTTP/_h...@example.com
> atlas.authentication.method.kerberos.name.rules=
> atlas.kafka.sasl.kerberos.service.name=kafka
> atlas.kafka.security.protocol=SASL_PLAINTEXT
> atlas.jaas.KafkaClient.loginModuleName=com.sun.security.auth.module.Krb5LoginModule
> atlas.jaas.KafkaClient.loginModuleControlFlag=required
> atlas.jaas.KafkaClient.option.useKeyTab=true
> atlas.jaas.KafkaClient.option.storeKey=true
> atlas.jaas.KafkaClient.option.serviceName=kafka
> atlas.jaas.KafkaClient.option.keyTab={{atlas_keytab_path}}
> atlas.jaas.KafkaClient.option.principal={{atlas_jaas_principal}}
> {code}
> Following properties are no more used and need to be removed:
> {code}
> atlas.http.authentication.enabled
> atlas.http.authentication.kerberos.keytab
> atlas.http.authentication.type
> atlas.http.authentication.kerberos.principal
> atlas.http.authentication.kerberos.name.rules
> atlas.login.method=
> atlas.login.credentials.file=
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17274) As part of atlas startup,"/usr/lib/ambari-logsearch-solr-client/solrCloudCli.sh" script is executed by ambari, which fails with "java.io.FileNotFoundException"
[
https://issues.apache.org/jira/browse/AMBARI-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-17274:
---
Attachment: AMBARI-17274.patch
> As part of atlas
> startup,"/usr/lib/ambari-logsearch-solr-client/solrCloudCli.sh" script is
> executed by ambari, which fails with "java.io.FileNotFoundException"
> ---
>
> Key: AMBARI-17274
> URL: https://issues.apache.org/jira/browse/AMBARI-17274
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Tom Beerbower
>Assignee: Tom Beerbower
> Fix For: 2.4.0
>
> Attachments: AMBARI-17274.patch
>
>
> Below is the error log.
> {noformat}
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata_server.py",
> line 173, in
> MetadataServer().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 257, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata_server.py",
> line 69, in start
> self.configure(env)
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata_server.py",
> line 53, in configure
> metadata()
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata.py",
> line 101, in metadata
> upload_conf_set('basic_configs', random_num)
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata.py",
> line 122, in upload_conf_set
> user=params.metadata_user)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/functions/solr_cloud_util.py",
> line 49, in upload_configuration_to_zk
> user=user
> File "/usr/lib/python2.6/site-packages/resource_management/core/base.py",
> line 155, in __init__
> self.env.run()
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 160, in run
> self.run_action(resource, action)
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 124, in run_action
> provider_action()
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
> line 273, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 70, in inner
> result = function(command, **kwargs)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 92, in checked_call
> tries=tries, try_sleep=try_sleep)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
> 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
> JAVA_HOME=/usr/jdk64/jdk1.8.0_77 ;
> /usr/lib/ambari-logsearch-solr-client/solrCloudCli.sh -z
> os-d7-unsecure-atlas-3.openstacklocal:2181,os-d7-unsecure-atlas-1.openstacklocal:2181/ambari-solr
> --upload-config -d
> /usr/lib/ambari-logsearch-solr/server/solr/configsets/basic_configs/conf -cs
> basic_configs -rt 5 -i 10' returned 1. log4j:ERROR setFile(null,true) call
> failed.
> java.io.FileNotFoundException: (No such file or directory)
> at java.io.FileOutputStream.open0(Native Method)
> at java.io.FileOutputStream.open(FileOutputStream.java:270)
> at java.io.FileOutputStream.(FileOutputStream.java:213)
> at java.io.FileOutputStream.(FileOutputStream.java:133)
> at org.apache.log4j.FileAppender.setFile(FileAppender.java:294)
> at
> org.apache.log4j.RollingFileAppender.setFile(RollingFileAppender.java:207)
> at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165)
> at
> org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307)
> at
> org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172)
> at
> org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104)
> at
> org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842)
> at
> org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768)
> at
> org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:648)
> at
> org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:514)
> at
>
[jira] [Resolved] (AMBARI-17167) Atlas Integration : Excessive logs: default log level should be set to 'info'; currently it is 'debug'
[ https://issues.apache.org/jira/browse/AMBARI-17167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya resolved AMBARI-17167. Resolution: Duplicate > Atlas Integration : Excessive logs: default log level should be set to > 'info'; currently it is 'debug' > -- > > Key: AMBARI-17167 > URL: https://issues.apache.org/jira/browse/AMBARI-17167 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17166) Atlas Integration : HBase table name 'titan' to be configurable via Atlas properties
[ https://issues.apache.org/jira/browse/AMBARI-17166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-17166: --- Attachment: AMBARI-17166.patch > Atlas Integration : HBase table name 'titan' to be configurable via Atlas > properties > > > Key: AMBARI-17166 > URL: https://issues.apache.org/jira/browse/AMBARI-17166 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > Attachments: AMBARI-17166.patch > > > Currently Atlas Hbase table name is 'titan' and there is no option to > configure the table name. > We can add a property in Atlas advanced configuration on Ambari UI to specify > the table name. > The following property in atlas-application.properties allows us to configure > Hbase table name > atlas.graph.storage.hbase.table : "atlas_titan" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-17167) Atlas Integration : Excessive logs: default log level should be set to 'info'; currently it is 'debug'
[ https://issues.apache.org/jira/browse/AMBARI-17167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya reopened AMBARI-17167: > Atlas Integration : Excessive logs: default log level should be set to > 'info'; currently it is 'debug' > -- > > Key: AMBARI-17167 > URL: https://issues.apache.org/jira/browse/AMBARI-17167 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17203) Atlas Integration : ATLAS conf dir needs to be present in all ATLAS hook deployed hosts
[ https://issues.apache.org/jira/browse/AMBARI-17203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-17203: --- Attachment: AMBARI-17203.patch > Atlas Integration : ATLAS conf dir needs to be present in all ATLAS hook > deployed hosts > --- > > Key: AMBARI-17203 > URL: https://issues.apache.org/jira/browse/AMBARI-17203 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > Attachments: AMBARI-17203.patch > > > Atlas atlas-application.properties configuration is required by the Atlas > hooks (Falcon, Storm, Sqoop and Hive). > Currently the atlas configuration is not being pushed to all the hook hosts > which could lead to issues if any config is changed. The Atlas configuration > changes needs to be pushed to all dependent hosts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17031) Atlas Integration : Deploying HA Blueprint with Atlas does not work
[ https://issues.apache.org/jira/browse/AMBARI-17031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-17031: --- Attachment: AMBARI-17031-2.patch > Atlas Integration : Deploying HA Blueprint with Atlas does not work > --- > > Key: AMBARI-17031 > URL: https://issues.apache.org/jira/browse/AMBARI-17031 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > Attachments: AMBARI-17031-2.patch > > > When deploying a blueprint that specified ha enabled > (atlas.server.ha.enabled=true), the atlas.server.address.id1, > atlas.server.address.id2 (etc) needs to be replaced with the hostnames for > the host group. This does not occur today, instead the > atlas.server.address.id1 is tokenized with (for example): > atlas.server.host.id1: "server_hosts", which is not quite correct. I believe > the blueprint runtime generator needs to create the proper entries with a > different token that is replaced with each host where Atlas server is > deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15592728#comment-15592728
]
Keta Patel commented on AMBARI-17041:
-
The latest 2 patches:
*AMBARI-17041-branch-2.5.patch* is attached to push in the changes for this
Jira into branch-2.5
*AMBARI-17041-trunk-fix-regression.patch* is attached to fix the regression
introduced by Jira AMBARI-18308 into the trunk code.
The ambari-web test results are as follows:
branch-2.5:
29536 tests complete (40 seconds)
154 tests pending
trunk:
30368 tests complete (40 seconds)
151 tests pending
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Fix For: 2.5.0
>
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-July22.patch,
> AMBARI-17041-branch-2.5.patch, AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk-fix-regression.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17098) Atlas Integration : Ambari overwrites users-credentials.properties and policy-store.txt
[ https://issues.apache.org/jira/browse/AMBARI-17098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-17098: --- Attachment: AMBARI-17098.patch > Atlas Integration : Ambari overwrites users-credentials.properties and > policy-store.txt > --- > > Key: AMBARI-17098 > URL: https://issues.apache.org/jira/browse/AMBARI-17098 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > Attachments: AMBARI-17098.patch > > > The Atlas users-credentials.properties and policy-store.txt are managed by > Ambari but can not be changed. Ambari overwrites any changes when the Atlas > server is restarted. > Make the files un-managed by Ambari so that they can be edited and will pick > up the latest changes from the Atlas distro on installation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16932) Atlas server start failed after Ambari upgrade due to missing solrCloudCli.sh script
[
https://issues.apache.org/jira/browse/AMBARI-16932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-16932:
---
Attachment: AMBARI-16932.patch
> Atlas server start failed after Ambari upgrade due to missing solrCloudCli.sh
> script
>
>
> Key: AMBARI-16932
> URL: https://issues.apache.org/jira/browse/AMBARI-16932
> Project: Ambari
> Issue Type: Bug
>Reporter: Tom Beerbower
>Assignee: Tom Beerbower
> Attachments: AMBARI-16932.patch
>
>
> *Steps*
> # Deploy HDP-2.4.2.0 cluster with Ambari 2.2.2.0 (including Atlas)
> # Upgrade Ambari to 2.4.0.0
> # Stop and start all services
> *Result*
> Atlas Metadata server start fails with below error:
> {code}
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata_server.py",
> line 165, in
> MetadataServer().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 257, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata_server.py",
> line 67, in start
> self.configure(env)
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata_server.py",
> line 51, in configure
> metadata()
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata.py",
> line 113, in metadata
> upload_conf_set('basic_configs', random_num)
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata.py",
> line 135, in upload_conf_set
> group=params.user_group)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/functions/solr_cloud_util.py",
> line 48, in upload_configuration_to_zk
> group=group
> File "/usr/lib/python2.6/site-packages/resource_management/core/base.py",
> line 155, in __init__
> self.env.run()
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 160, in run
> self.run_action(resource, action)
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 124, in run_action
> provider_action()
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
> line 273, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 70, in inner
> result = function(command, **kwargs)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 92, in checked_call
> tries=tries, try_sleep=try_sleep)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
> 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
> JAVA_HOME=/usr/jdk64/jdk1.7.0_67 ;
> /usr/lib/ambari-logsearch-solr-client/solrCloudCli.sh -z
> os-r6-tgvuks-dgm10toeriedwngdha-r6-4.openstacklocal:2181,os-r6-tgvuks-dgm10toeriedwngdha-r6-3.openstacklocal:2181,os-r6-tgvuks-dgm10toeriedwngdha-r6-2.openstacklocal:2181None
> --upload-config -d
> /usr/lib/ambari-logsearch-solr/server/solr/configsets/basic_configs/conf -cs
> basic_configs -rt 5 -i 10' returned 127. -bash:
> /usr/lib/ambari-logsearch-solr-client/solrCloudCli.sh: No such file or
> directory
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17981) Integrate Druid With Ambari
[
https://issues.apache.org/jira/browse/AMBARI-17981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15592698#comment-15592698
]
Swapan Shridhar commented on AMBARI-17981:
--
*Commits:*
*trunk:*
{code}
commit 685e926db0d442411ab5bee50c1e189cfb0a261e
Author: Swapan Shridhar
Date: Thu Oct 20 12:04:24 2016 -0700
Integrate Druid with Ambari (Nishant Bangarwa, Slim Bouguerra via Swapan
Shridhar).
{code}
*branch-2.5:*
{code}
commit fca146a5d4284a8156ff3bcf468af7388a8283fe
Author: Swapan Shridhar
Date: Thu Oct 20 12:04:24 2016 -0700
Integrate Druid with Ambari (Nishant Bangarwa, Slim Bouguerra via Swapan
Shridhar).
{code}
> Integrate Druid With Ambari
> ---
>
> Key: AMBARI-17981
> URL: https://issues.apache.org/jira/browse/AMBARI-17981
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Reporter: Nishant Bangarwa
>Assignee: Swapan Shridhar
> Labels: features
> Fix For: 2.5.0
>
> Attachments: ambari-17981.patch
>
>
> This task includes adding support for druid cluster provisioning via Ambari.
> Details about Druid cluster design and different node types are present here
> -
> http://druid.io/docs/latest/design/design.html
> In general, Druid can be defined as a service in HDP which has following
> components -
> 1) Coordinator
> 2) Overlord
> 3) Historical
> 4) Broker
> 5) Middlemanager
>
> Druid also has external dependencies on following
> 1) Zookeeper - Ambari should be able to pass in zk configs to druid cluster
> 2) Deep storage - A distributed FS, can be one of HDFS/S3 or any other NFS.
> 3) Metadata Store - Mysql/Postgres. can be either provided by the user or a
> mysql instance provisioned by ambari itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17981) Integrate Druid With Ambari
[ https://issues.apache.org/jira/browse/AMBARI-17981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar updated AMBARI-17981: - Fix Version/s: 2.5.0 > Integrate Druid With Ambari > --- > > Key: AMBARI-17981 > URL: https://issues.apache.org/jira/browse/AMBARI-17981 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Nishant Bangarwa >Assignee: Swapan Shridhar > Labels: features > Fix For: 2.5.0 > > Attachments: ambari-17981.patch > > > This task includes adding support for druid cluster provisioning via Ambari. > Details about Druid cluster design and different node types are present here > - > http://druid.io/docs/latest/design/design.html > In general, Druid can be defined as a service in HDP which has following > components - > 1) Coordinator > 2) Overlord > 3) Historical > 4) Broker > 5) Middlemanager > > Druid also has external dependencies on following > 1) Zookeeper - Ambari should be able to pass in zk configs to druid cluster > 2) Deep storage - A distributed FS, can be one of HDFS/S3 or any other NFS. > 3) Metadata Store - Mysql/Postgres. can be either provided by the user or a > mysql instance provisioned by ambari itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-18645) Move ATLAS role command order to common-services/ATLAS
[ https://issues.apache.org/jira/browse/AMBARI-18645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Onischuk reopened AMBARI-18645: -- > Move ATLAS role command order to common-services/ATLAS > -- > > Key: AMBARI-18645 > URL: https://issues.apache.org/jira/browse/AMBARI-18645 > Project: Ambari > Issue Type: Bug >Reporter: Andrew Onischuk >Assignee: Andrew Onischuk > Fix For: 3.0.0 > > Attachments: AMBARI-18645.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18649) Add ability to configure sink configs for external AMS
[
https://issues.apache.org/jira/browse/AMBARI-18649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15592505#comment-15592505
]
Hadoop QA commented on AMBARI-18649:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834459/AMBARI-18649.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/8947//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8947//console
This message is automatically generated.
> Add ability to configure sink configs for external AMS
> --
>
> Key: AMBARI-18649
> URL: https://issues.apache.org/jira/browse/AMBARI-18649
> Project: Ambari
> Issue Type: Task
> Components: ambari-metrics, stacks
>Affects Versions: 2.5.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
> Fix For: 2.5.0
>
> Attachments: AMBARI-18649.patch
>
>
> Since hadoop-metrics2.properties is not configurable for a cluster we need to
> find how we could make this like any other config that can be changed to
> point to External AMS through a blueprint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18371) View migration removes current permissions
[ https://issues.apache.org/jira/browse/AMBARI-18371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15592461#comment-15592461 ] Hudson commented on AMBARI-18371: - FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #178 (See [https://builds.apache.org/job/Ambari-branch-2.5/178/]) AMBARI-18371. View migration removes current permissions. (Ashwin Rajeev (dipayan.bhowmick: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=4c17b5229c3da9f3f7c6d9627f2d43e4c464a229]) * (edit) ambari-server/src/main/java/org/apache/ambari/server/view/ViewRegistry.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/view/ViewDataMigrationUtilityTest.java > View migration removes current permissions > -- > > Key: AMBARI-18371 > URL: https://issues.apache.org/jira/browse/AMBARI-18371 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Ashwin Rajeev >Assignee: Ashwin Rajeev > Fix For: 2.4.2 > > Attachments: AMBARI-18371.trunk.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > When two versions of the same view exists, Ambari on startup tries to migrate > old data to the new view and deletes the current permissions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18653) Allow MASTER service install to be optional
[ https://issues.apache.org/jira/browse/AMBARI-18653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-18653: --- Fix Version/s: 2.5.0 > Allow MASTER service install to be optional > > > Key: AMBARI-18653 > URL: https://issues.apache.org/jira/browse/AMBARI-18653 > Project: Ambari > Issue Type: Improvement >Affects Versions: 2.4.0 >Reporter: David M. Lyle >Assignee: Jaimin D Jetly > Fix For: 2.5.0 > > > Hive has logic that allows the MySQL to be installed optionally. Please > relocate that logic so other Master services can be optional as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18653) Allow MASTER service install to be optional
[ https://issues.apache.org/jira/browse/AMBARI-18653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-18653: --- Assignee: Jaimin D Jetly > Allow MASTER service install to be optional > > > Key: AMBARI-18653 > URL: https://issues.apache.org/jira/browse/AMBARI-18653 > Project: Ambari > Issue Type: Improvement >Affects Versions: 2.4.0 >Reporter: David M. Lyle >Assignee: Jaimin D Jetly > > Hive has logic that allows the MySQL to be installed optionally. Please > relocate that logic so other Master services can be optional as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17867) Fix xml KERBEROS/1.10.3-10/configuration/kerberos-env.xml
[ https://issues.apache.org/jira/browse/AMBARI-17867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-17867: --- Attachment: rb50373.patch > Fix xml KERBEROS/1.10.3-10/configuration/kerberos-env.xml > - > > Key: AMBARI-17867 > URL: https://issues.apache.org/jira/browse/AMBARI-17867 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Ajit Kumar >Assignee: Ajit Kumar > Fix For: 2.4.0 > > Attachments: rb50373.patch > > > Fix KERBEROS/1.10.3-10/configuration/kerberos-env.xml which has bad xml > element "host" at line number 89. This is breaking build > https://builds.apache.org/job/Ambari-trunk-Commit/5372 > Unit test failing: > org.apache.ambari.server.state.ServicePropertiesTest.validatePropertySchemaOfServiceXMLs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18649) Add ability to configure sink configs for external AMS
[ https://issues.apache.org/jira/browse/AMBARI-18649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmytro Sen updated AMBARI-18649: Status: Patch Available (was: Open) > Add ability to configure sink configs for external AMS > -- > > Key: AMBARI-18649 > URL: https://issues.apache.org/jira/browse/AMBARI-18649 > Project: Ambari > Issue Type: Task > Components: ambari-metrics, stacks >Affects Versions: 2.5.0 >Reporter: Dmytro Sen >Assignee: Dmytro Sen > Fix For: 2.5.0 > > Attachments: AMBARI-18649.patch > > > Since hadoop-metrics2.properties is not configurable for a cluster we need to > find how we could make this like any other config that can be changed to > point to External AMS through a blueprint. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18371) View migration removes current permissions
[ https://issues.apache.org/jira/browse/AMBARI-18371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15592416#comment-15592416 ] Hudson commented on AMBARI-18371: - FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5834 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5834/]) AMBARI-18371. View migration removes current permissions. (Ashwin Rajeev (dipayan.bhowmick: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=1d5178ce727c02d1eb064e210e421ed54428448e]) * (edit) ambari-server/src/test/java/org/apache/ambari/server/view/ViewDataMigrationUtilityTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/view/ViewRegistry.java > View migration removes current permissions > -- > > Key: AMBARI-18371 > URL: https://issues.apache.org/jira/browse/AMBARI-18371 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Ashwin Rajeev >Assignee: Ashwin Rajeev > Fix For: 2.4.2 > > Attachments: AMBARI-18371.trunk.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > When two versions of the same view exists, Ambari on startup tries to migrate > old data to the new view and deletes the current permissions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16145) Add dryrun API for host delete
[
https://issues.apache.org/jira/browse/AMBARI-16145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-16145:
---
Attachment: rb46750.patch
> Add dryrun API for host delete
> ---
>
> Key: AMBARI-16145
> URL: https://issues.apache.org/jira/browse/AMBARI-16145
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Ajit Kumar
>Assignee: Ajit Kumar
> Fix For: 2.4.0
>
> Attachments: rb46750.patch
>
>
> Add dryrun API for host delete
> API should be take dry_run directive and check if requested host can be
> deleted w/o deleting the host and should return error if any, like host is
> not in delete friendly state.
> {code}
> curl -i -X DELETE -u admin:admin -H 'X-Requested-By:ambari'
> 'http://localhost:8080/api/v1/clusters/c1/hosts?dry_run=true/host_name=c6401.ambari.apache.org'
> {code}
> It should also support bulk delete format
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15847) Add api for bulk delete host
[ https://issues.apache.org/jira/browse/AMBARI-15847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-15847: --- Attachment: rb43927.patch > Add api for bulk delete host > > > Key: AMBARI-15847 > URL: https://issues.apache.org/jira/browse/AMBARI-15847 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Ajit Kumar >Assignee: Ajit Kumar > Fix For: 2.4.0 > > Attachments: rb43927.patch > > > Currently if anyone has to delete more than 1 host, a script is required to > call delete host api in a loop for each host. This api takes in query and > instead of failing fast on the first error, puts the best effort to delete > all requested hosts. Response should be json object which has deleted keys > and keys which failed to delete with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-17020) Use 'llapstatus' comand after starting llap to check its status before starting HiveServer2
[
https://issues.apache.org/jira/browse/AMBARI-17020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya resolved AMBARI-17020.
Resolution: Duplicate
> Use 'llapstatus' comand after starting llap to check its status before
> starting HiveServer2
> ---
>
> Key: AMBARI-17020
> URL: https://issues.apache.org/jira/browse/AMBARI-17020
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.4.0
>
>
> - Right now, after starting llap app, we wait for 30 secs before starting
> hive2/HiveServer2.
> - Need to have status check via 'llapstatus' command and start
> hive2/HiveServer2 only if llap app deployment was a success.
> eg: llapstatus command:
> {code}
> hive2/bin/hive --service llapstatus --name
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMBARI-16087) LLAP queue is not selected when enabling Hive Interactive Query during Install Wizard
[ https://issues.apache.org/jira/browse/AMBARI-16087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya resolved AMBARI-16087. Resolution: Duplicate > LLAP queue is not selected when enabling Hive Interactive Query during > Install Wizard > - > > Key: AMBARI-16087 > URL: https://issues.apache.org/jira/browse/AMBARI-16087 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-16079) Wait for fixed number of times if the launched LLAP app is in "LAUNCHING" state to go to "RUNNING_ALL" or "RUNNING_PARTIAL"
[ https://issues.apache.org/jira/browse/AMBARI-16079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya reopened AMBARI-16079: > Wait for fixed number of times if the launched LLAP app is in "LAUNCHING" > state to go to "RUNNING_ALL" or "RUNNING_PARTIAL" > --- > > Key: AMBARI-16079 > URL: https://issues.apache.org/jira/browse/AMBARI-16079 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > > - Wait for fixed number of times if the launched LLAP app is in "LAUNCHING" > state to go to "RUNNING_ALL" or "RUNNING_PARTIAL" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-16087) LLAP queue is not selected when enabling Hive Interactive Query during Install Wizard
[ https://issues.apache.org/jira/browse/AMBARI-16087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya reopened AMBARI-16087: > LLAP queue is not selected when enabling Hive Interactive Query during > Install Wizard > - > > Key: AMBARI-16087 > URL: https://issues.apache.org/jira/browse/AMBARI-16087 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-16079) Wait for fixed number of times if the launched LLAP app is in "LAUNCHING" state to go to "RUNNING_ALL" or "RUNNING_PARTIAL"
[ https://issues.apache.org/jira/browse/AMBARI-16079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya resolved AMBARI-16079. Resolution: Duplicate > Wait for fixed number of times if the launched LLAP app is in "LAUNCHING" > state to go to "RUNNING_ALL" or "RUNNING_PARTIAL" > --- > > Key: AMBARI-16079 > URL: https://issues.apache.org/jira/browse/AMBARI-16079 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > > - Wait for fixed number of times if the launched LLAP app is in "LAUNCHING" > state to go to "RUNNING_ALL" or "RUNNING_PARTIAL" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-16086) Hide 'llap' queue capacity slider when 'llap' queue is not being used for LLAP app
[ https://issues.apache.org/jira/browse/AMBARI-16086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya resolved AMBARI-16086. Resolution: Duplicate > Hide 'llap' queue capacity slider when 'llap' queue is not being used for > LLAP app > -- > > Key: AMBARI-16086 > URL: https://issues.apache.org/jira/browse/AMBARI-16086 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-16086) Hide 'llap' queue capacity slider when 'llap' queue is not being used for LLAP app
[ https://issues.apache.org/jira/browse/AMBARI-16086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya reopened AMBARI-16086: > Hide 'llap' queue capacity slider when 'llap' queue is not being used for > LLAP app > -- > > Key: AMBARI-16086 > URL: https://issues.apache.org/jira/browse/AMBARI-16086 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
