[jira] [Updated] (AMBARI-18337) Syntax Error in Ambari HAWQ Unit test with Python 2.6

2016-09-07 Thread Masahiro Tanaka (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Masahiro Tanaka updated AMBARI-18337:
-
Description: 
With Python 2.6, {code} {"A", "B"}  {code} syntax isn't allowed.

Ref. https://docs.python.org/2/library/stdtypes.html#set-types-set-frozenset

{code}
As of Python 2.7, non-empty sets (not frozensets) can be created by placing a 
comma-separated list of elements within braces, for example: {'jack', 
'sjoerd'}, in addition to the set constructor.
{code}

Error

{code}
Traceback (most recent call last):
  File "unitTests.py", line 129, in stack_test_executor
modules]
  File "/usr/lib64/python2.6/unittest.py", line 575, in loadTestsFromName
module = __import__('.'.join(parts_copy))
  File 
"/tmp/ambari/ambari-server/src/test/python/common-services/HAWQ/test_service_advisor.py",
 li
ne 646
self.assertFalse({'HAWQMASTER', 'HAWQSTANDBY'}.issubset(hostComponents))
  ^
SyntaxError: invalid syntax
{code}

  was:
With Python 2.6, {code} {"A", "B"}  {code} syntax isn't allowed.

Ref. https://docs.python.org/2/library/stdtypes.html#set-types-set-frozenset

{code}
As of Python 2.7, non-empty sets (not frozensets) can be created by placing a 
comma-separated list of elements within braces, for example: {'jack', 
'sjoerd'}, in addition to the set constructor.
{code}


> Syntax Error in Ambari HAWQ Unit test with Python 2.6
> -
>
> Key: AMBARI-18337
> URL: https://issues.apache.org/jira/browse/AMBARI-18337
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
> Environment: CentOS6, Python 2.6
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
>
> With Python 2.6, {code} {"A", "B"}  {code} syntax isn't allowed.
> Ref. https://docs.python.org/2/library/stdtypes.html#set-types-set-frozenset
> {code}
> As of Python 2.7, non-empty sets (not frozensets) can be created by placing a 
> comma-separated list of elements within braces, for example: {'jack', 
> 'sjoerd'}, in addition to the set constructor.
> {code}
> Error
> {code}
> Traceback (most recent call last):
>   File "unitTests.py", line 129, in stack_test_executor
> modules]
>   File "/usr/lib64/python2.6/unittest.py", line 575, in loadTestsFromName
> module = __import__('.'.join(parts_copy))
>   File 
> "/tmp/ambari/ambari-server/src/test/python/common-services/HAWQ/test_service_advisor.py",
>  li
> ne 646
> self.assertFalse({'HAWQMASTER', 'HAWQSTANDBY'}.issubset(hostComponents))
>   ^
> SyntaxError: invalid syntax
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (AMBARI-18337) Syntax Error in Ambari HAWQ Unit test with Python 2.6

2016-09-07 Thread Masahiro Tanaka (JIRA)
Masahiro Tanaka created AMBARI-18337:


 Summary: Syntax Error in Ambari HAWQ Unit test with Python 2.6
 Key: AMBARI-18337
 URL: https://issues.apache.org/jira/browse/AMBARI-18337
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: trunk
 Environment: CentOS6, Python 2.6
Reporter: Masahiro Tanaka
Assignee: Masahiro Tanaka


With Python 2.6, {code} {"A", "B"}  {code} syntax isn't allowed.

Ref. https://docs.python.org/2/library/stdtypes.html#set-types-set-frozenset

{code}
As of Python 2.7, non-empty sets (not frozensets) can be created by placing a 
comma-separated list of elements within braces, for example: {'jack', 
'sjoerd'}, in addition to the set constructor.
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-15901) Ambari Metrics System Distributed mode - multiple Collectors

2016-09-07 Thread Siddharth Wagle (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-15901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Siddharth Wagle updated AMBARI-15901:
-
Fix Version/s: (was: 3.0.0)

> Ambari Metrics System Distributed mode - multiple Collectors
> 
>
> Key: AMBARI-15901
> URL: https://issues.apache.org/jira/browse/AMBARI-15901
> Project: Ambari
>  Issue Type: Epic
>  Components: ambari-metrics
>Affects Versions: 2.0.0
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
>Priority: Critical
> Attachments: Metrics-HA-Arch.png
>
>
> UX:
> - Configure AMS in distributed mode, write to distributed FS supported by 
> HBase, example: HDFS / WASB, etc
> - Add a new Metrics Collector by navigating to a host and selecting the 
> component from dropdown
> - Same can be achieved by adding a Collector from INSTALL wizard or from a 
> blueprint
> - No additional configuration is required



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-17898) Add Kerberos HTTP SPNEGO authentication support to Ambari Metrics Monitor

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-17898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15472391#comment-15472391
 ] 

Hadoop QA commented on AMBARI-17898:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827453/AMBARI-17898.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/8607//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8607//console

This message is automatically generated.

> Add Kerberos HTTP SPNEGO authentication support to Ambari Metrics Monitor
> -
>
> Key: AMBARI-17898
> URL: https://issues.apache.org/jira/browse/AMBARI-17898
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-metrics
>Affects Versions: 2.2.0
>Reporter: Qin Liu
>Assignee: Qin Liu
> Fix For: trunk
>
> Attachments: AMBARI-17898.patch
>
>
> This is a subtask of AMBARI-14384 "Ambari Metrics doesn't use SPNEGO to 
> authenticate".
> In a Kerberos enabled cluster with SPNEGO enabled on Hadoop APIs, Ambari 
> Metrics Collector web-console will be Kerberos HTTP SPNEGO enabled too. But 
> Ambari Metrics Monitor, a client of Ambari Metrics Collector, currently does 
> not support Kerberos HTTP SPNEGO authentication.  
> /var/log/ambari-metrics-monitor/ambari-metrics-monitor.out:
> 2015-12-15 13:26:30,663 [INFO] emitter.py:101 - server: 
> http://metrics-collector:6188/ws/v1/timeline/metrics
> 2015-12-15 13:26:30,671 [WARNING] emitter.py:84 - Error sending metrics to 
> server. HTTP Error 401: Authentication required
> 2015-12-15 13:26:30,671 [WARNING] emitter.py:90 - Retrying after 5 ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18335) After upgrading cluster from HDP-2.4.x to HDP-2.5.x and added atlas service - missing kafka security properties

2016-09-07 Thread Robert Levas (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Levas updated AMBARI-18335:
--
Status: Patch Available  (was: In Progress)

> After upgrading cluster from HDP-2.4.x to HDP-2.5.x and added atlas service - 
> missing kafka security properties
> ---
>
> Key: AMBARI-18335
> URL: https://issues.apache.org/jira/browse/AMBARI-18335
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>  Labels: kerberos_descriptor, upgrade
> Fix For: 2.4.1
>
> Attachments: AMBARI-18335_branch-2.4_01.patch, 
> AMBARI-18335_trunk_01.patch
>
>
> Steps to repro:
> * Install Ambari 2.2.2
> * Install HDP-2.4.x cluster with Atlas
> * Stop Atlas
> * Upgrade Ambari to 2.4
> * Delete Atlas service
> * Upgrade the cluster to HDP-2.5.x cluster
> * Add Atlas service.
> *Below config properties are missing from atlas-applicataion.properties file 
> for Atlas, Storm, Falcon, Hive services.*
> #atlas.jaas.KafkaClient.option.keyTab = 
> /etc/security/keytabs/atlas.service.keytab
> #atlas.jaas.KafkaClient.option.principal = atlas/_h...@example.com
> From HDP 2.4 to 2.5, the kerberos.json file for Atlas changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18335) After upgrading cluster from HDP-2.4.x to HDP-2.5.x and added atlas service - missing kafka security properties

2016-09-07 Thread Robert Levas (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Levas updated AMBARI-18335:
--
Attachment: AMBARI-18335_trunk_01.patch
AMBARI-18335_branch-2.4_01.patch

> After upgrading cluster from HDP-2.4.x to HDP-2.5.x and added atlas service - 
> missing kafka security properties
> ---
>
> Key: AMBARI-18335
> URL: https://issues.apache.org/jira/browse/AMBARI-18335
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>  Labels: kerberos_descriptor, upgrade
> Fix For: 2.4.1
>
> Attachments: AMBARI-18335_branch-2.4_01.patch, 
> AMBARI-18335_trunk_01.patch
>
>
> Steps to repro:
> * Install Ambari 2.2.2
> * Install HDP-2.4.x cluster with Atlas
> * Stop Atlas
> * Upgrade Ambari to 2.4
> * Delete Atlas service
> * Upgrade the cluster to HDP-2.5.x cluster
> * Add Atlas service.
> *Below config properties are missing from atlas-applicataion.properties file 
> for Atlas, Storm, Falcon, Hive services.*
> #atlas.jaas.KafkaClient.option.keyTab = 
> /etc/security/keytabs/atlas.service.keytab
> #atlas.jaas.KafkaClient.option.principal = atlas/_h...@example.com
> From HDP 2.4 to 2.5, the kerberos.json file for Atlas changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-17458) Add support for distributed collector to Ambari REST API

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-17458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15472357#comment-15472357
 ] 

Hadoop QA commented on AMBARI-17458:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827458/AMBARI-17458.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 core tests{color}.  The patch failed these unit tests in 
ambari-server:

  
org.apache.ambari.server.controller.metrics.timeline.AMSPropertyProviderTest
  
org.apache.ambari.server.controller.internal.StackDefinedPropertyProviderTest
  
org.apache.ambari.server.controller.metrics.RestMetricsPropertyProviderTest
  
org.apache.ambari.server.controller.metrics.timeline.AMSReportPropertyProviderTest

Test results: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8606//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8606//console

This message is automatically generated.

> Add support for distributed collector to Ambari REST API
> 
>
> Key: AMBARI-17458
> URL: https://issues.apache.org/jira/browse/AMBARI-17458
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Siddharth Wagle
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-17458.patch
>
>
> _Tasks_:
> - Add a Zookeeper watcher for the AMS znode
> - Find available collectors and round-robin the READ calls from 
> AMSPropertyProvider
> - Tolerate failure by switching to available collector



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18309) Add check to DB conistency checker for duplicate hostcomponentstate

2016-09-07 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15472345#comment-15472345
 ] 

Hudson commented on AMBARI-18309:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5635 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5635/])
AMBARI-18309. Add check to DB conistency checker for duplicate (vbrodetskyi: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=6180afee4680cba15fbfcd0d0e7d15cdbb3b1852])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/checks/DatabaseConsistencyCheckHelper.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/checks/DatabaseConsistencyChecker.java
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/checks/DatabaseConsistencyCheckHelperTest.java


> Add check to DB conistency checker for duplicate hostcomponentstate
> ---
>
> Key: AMBARI-18309
> URL: https://issues.apache.org/jira/browse/AMBARI-18309
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
> Fix For: 3.0.0
>
> Attachments: AMBARI-18309.patch
>
>
> Add db consistency check for hostcomponent tables, for each component we 
> should have only one state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18336) RAT check failure

2016-09-07 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15472164#comment-15472164
 ] 

Hudson commented on AMBARI-18336:
-

SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #5 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/5/])
AMBARI-18336. RAT check failure (smohanty) (smohanty: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=41707af24ce1470418dbd6be3798e0f8919e7208])
* (edit) 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/templates/atlas_kafka_acl.sh.j2


> RAT check failure
> -
>
> Key: AMBARI-18336
> URL: https://issues.apache.org/jira/browse/AMBARI-18336
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.1
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
>Priority: Critical
> Fix For: 2.4.1
>
> Attachments: AMBARI-18336.patch
>
>
> 1 Unknown Licenses
> ***
> Unapproved licenses:
>   
> ../ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/templates/atlas_kafka_acl.sh.j2
> ***



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18336) RAT check failure

2016-09-07 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15472117#comment-15472117
 ] 

Hudson commented on AMBARI-18336:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5634 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5634/])
AMBARI-18336. RAT check failure (smohanty) (smohanty: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=4d285cdddf3080718b48bcb35bfcdc41e7c664bf])
* (edit) 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/templates/atlas_kafka_acl.sh.j2


> RAT check failure
> -
>
> Key: AMBARI-18336
> URL: https://issues.apache.org/jira/browse/AMBARI-18336
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.1
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
>Priority: Critical
> Fix For: 2.4.1
>
> Attachments: AMBARI-18336.patch
>
>
> 1 Unknown Licenses
> ***
> Unapproved licenses:
>   
> ../ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/templates/atlas_kafka_acl.sh.j2
> ***



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18296) Database Consistency Check Fails With NPE With Missing Service From Stack

2016-09-07 Thread Sumit Mohanty (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sumit Mohanty updated AMBARI-18296:
---
Fix Version/s: 2.5.0

> Database Consistency Check Fails With NPE With Missing Service From Stack
> -
>
> Key: AMBARI-18296
> URL: https://issues.apache.org/jira/browse/AMBARI-18296
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: trunk, 2.4.1, 2.5.0, 2.4.2
>
> Attachments: AMBARI-18296.patch
>
>
> The database consistency checker can fail if a service configuration exists 
> for a service which is no longer on the current stack:
> {code}
> 2016-08-31 21:52:28,082 INFO - *** Check database 
> started *** 2016-08-31 21:52:31,647 INFO - 
> Checking for configs not mapped to any cluster 2016-08-31 21:52:31,653 INFO - 
> Checking for configs selected more than once 2016-08-31 21:52:31,655 INFO - 
> Checking for hosts without state 2016-08-31 21:52:31,657 INFO - Checking host 
> component states count equals host component desired states count 2016-08-31 
> 21:52:31,660 INFO - Checking services and their configs 2016-08-31 
> 21:52:33,669 ERROR - Unexpected error, database check failed 
> java.lang.NullPointerException at 
> org.apache.ambari.server.checks.DatabaseConsistencyCheckHelper.checkServiceConfigs(DatabaseConsistencyCheckHelper.java:543)
>  at 
> org.apache.ambari.server.checks.DatabaseConsistencyChecker.main(DatabaseConsistencyChecker.java:115)
> {code}
> It seems like what happens is this query returns a service which is not 
> defined in the current stack:
> {code}
> SELECT
>   c.cluster_name,
>   cs.service_name,
>   cc.type_name,
>   sc.version
> FROM clusterservices cs
> JOIN serviceconfig sc
>   ON cs.service_name = sc.service_name
>   AND cs.cluster_id = sc.cluster_id
> JOIN serviceconfigmapping scm
>   ON sc.service_config_id = scm.service_config_id
> JOIN clusterconfig cc
>   ON scm.config_id = cc.config_id
>   AND sc.cluster_id = cc.cluster_id
> JOIN clusters c
>   ON cc.cluster_id = c.cluster_id
>   AND sc.stack_id = c.desired_stack_id
> WHERE sc.group_id IS NULL
> AND sc.service_config_id = (SELECT
>   MAX(service_config_id)
> FROM serviceconfig sc2
> WHERE sc2.service_name = sc.service_name
> AND sc2.cluster_id = sc.cluster_id)
> GROUP BY c.cluster_name,
>  cs.service_name,
>  cc.type_name,
>  sc.version
> {code}
> Problem area of code:
> {code:title=serviceInfo is null}
> for (String serviceName : serviceNames) {
>   ServiceInfo serviceInfo = serviceInfoMap.get(serviceName);
>   Set configTypes = 
> serviceInfo.getConfigTypeAttributes().keySet();
>   for (String configType : configTypes) {
> stackServiceConfigs.put(serviceName, configType);
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18296) Database Consistency Check Fails With NPE With Missing Service From Stack

2016-09-07 Thread Sumit Mohanty (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sumit Mohanty updated AMBARI-18296:
---
Fix Version/s: 2.4.2
   2.4.1

> Database Consistency Check Fails With NPE With Missing Service From Stack
> -
>
> Key: AMBARI-18296
> URL: https://issues.apache.org/jira/browse/AMBARI-18296
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: trunk, 2.4.1, 2.4.2
>
> Attachments: AMBARI-18296.patch
>
>
> The database consistency checker can fail if a service configuration exists 
> for a service which is no longer on the current stack:
> {code}
> 2016-08-31 21:52:28,082 INFO - *** Check database 
> started *** 2016-08-31 21:52:31,647 INFO - 
> Checking for configs not mapped to any cluster 2016-08-31 21:52:31,653 INFO - 
> Checking for configs selected more than once 2016-08-31 21:52:31,655 INFO - 
> Checking for hosts without state 2016-08-31 21:52:31,657 INFO - Checking host 
> component states count equals host component desired states count 2016-08-31 
> 21:52:31,660 INFO - Checking services and their configs 2016-08-31 
> 21:52:33,669 ERROR - Unexpected error, database check failed 
> java.lang.NullPointerException at 
> org.apache.ambari.server.checks.DatabaseConsistencyCheckHelper.checkServiceConfigs(DatabaseConsistencyCheckHelper.java:543)
>  at 
> org.apache.ambari.server.checks.DatabaseConsistencyChecker.main(DatabaseConsistencyChecker.java:115)
> {code}
> It seems like what happens is this query returns a service which is not 
> defined in the current stack:
> {code}
> SELECT
>   c.cluster_name,
>   cs.service_name,
>   cc.type_name,
>   sc.version
> FROM clusterservices cs
> JOIN serviceconfig sc
>   ON cs.service_name = sc.service_name
>   AND cs.cluster_id = sc.cluster_id
> JOIN serviceconfigmapping scm
>   ON sc.service_config_id = scm.service_config_id
> JOIN clusterconfig cc
>   ON scm.config_id = cc.config_id
>   AND sc.cluster_id = cc.cluster_id
> JOIN clusters c
>   ON cc.cluster_id = c.cluster_id
>   AND sc.stack_id = c.desired_stack_id
> WHERE sc.group_id IS NULL
> AND sc.service_config_id = (SELECT
>   MAX(service_config_id)
> FROM serviceconfig sc2
> WHERE sc2.service_name = sc.service_name
> AND sc2.cluster_id = sc.cluster_id)
> GROUP BY c.cluster_name,
>  cs.service_name,
>  cc.type_name,
>  sc.version
> {code}
> Problem area of code:
> {code:title=serviceInfo is null}
> for (String serviceName : serviceNames) {
>   ServiceInfo serviceInfo = serviceInfoMap.get(serviceName);
>   Set configTypes = 
> serviceInfo.getConfigTypeAttributes().keySet();
>   for (String configType : configTypes) {
> stackServiceConfigs.put(serviceName, configType);
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (AMBARI-18329) Remove Ubuntu16 from HDP-2.5 repoinfo as there are no repo available for the stack

2016-09-07 Thread Sumit Mohanty (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sumit Mohanty resolved AMBARI-18329.

Resolution: Fixed

> Remove Ubuntu16 from HDP-2.5 repoinfo as there are no repo available for the 
> stack
> --
>
> Key: AMBARI-18329
> URL: https://issues.apache.org/jira/browse/AMBARI-18329
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.0
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
>Priority: Critical
> Fix For: 2.4.1
>
> Attachments: AMBARI-18329.patch
>
>
> There are no ubuntu16 repos available for HDP-2.5 stack. The repo details in 
> the repoinfo.xml file should be removed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18309) Add check to DB conistency checker for duplicate hostcomponentstate

2016-09-07 Thread Vitaly Brodetskyi (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitaly Brodetskyi updated AMBARI-18309:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to trunk

> Add check to DB conistency checker for duplicate hostcomponentstate
> ---
>
> Key: AMBARI-18309
> URL: https://issues.apache.org/jira/browse/AMBARI-18309
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
> Fix For: 3.0.0
>
> Attachments: AMBARI-18309.patch
>
>
> Add db consistency check for hostcomponent tables, for each component we 
> should have only one state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-17458) Add support for distributed collector to Ambari REST API

2016-09-07 Thread Aravindan Vijayan (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-17458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aravindan Vijayan updated AMBARI-17458:
---
Affects Version/s: (was: 2.5.0)
   3.0.0

> Add support for distributed collector to Ambari REST API
> 
>
> Key: AMBARI-17458
> URL: https://issues.apache.org/jira/browse/AMBARI-17458
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Siddharth Wagle
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-17458.patch
>
>
> _Tasks_:
> - Add a Zookeeper watcher for the AMS znode
> - Find available collectors and round-robin the READ calls from 
> AMSPropertyProvider
> - Tolerate failure by switching to available collector



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-17458) Add support for distributed collector to Ambari REST API

2016-09-07 Thread Aravindan Vijayan (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-17458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aravindan Vijayan updated AMBARI-17458:
---
Attachment: AMBARI-17458.patch

> Add support for distributed collector to Ambari REST API
> 
>
> Key: AMBARI-17458
> URL: https://issues.apache.org/jira/browse/AMBARI-17458
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Siddharth Wagle
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-17458.patch
>
>
> _Tasks_:
> - Add a Zookeeper watcher for the AMS znode
> - Find available collectors and round-robin the READ calls from 
> AMSPropertyProvider
> - Tolerate failure by switching to available collector



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-17458) Add support for distributed collector to Ambari REST API

2016-09-07 Thread Aravindan Vijayan (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-17458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aravindan Vijayan updated AMBARI-17458:
---
Fix Version/s: (was: 2.5.0)
   3.0.0

> Add support for distributed collector to Ambari REST API
> 
>
> Key: AMBARI-17458
> URL: https://issues.apache.org/jira/browse/AMBARI-17458
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Siddharth Wagle
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-17458.patch
>
>
> _Tasks_:
> - Add a Zookeeper watcher for the AMS znode
> - Find available collectors and round-robin the READ calls from 
> AMSPropertyProvider
> - Tolerate failure by switching to available collector



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-17458) Add support for distributed collector to Ambari REST API

2016-09-07 Thread Aravindan Vijayan (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-17458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aravindan Vijayan updated AMBARI-17458:
---
Status: Patch Available  (was: Open)

> Add support for distributed collector to Ambari REST API
> 
>
> Key: AMBARI-17458
> URL: https://issues.apache.org/jira/browse/AMBARI-17458
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Siddharth Wagle
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-17458.patch
>
>
> _Tasks_:
> - Add a Zookeeper watcher for the AMS znode
> - Find available collectors and round-robin the READ calls from 
> AMSPropertyProvider
> - Tolerate failure by switching to available collector



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18191) "Restart all required" services operation failed at Metrics Collector since HDFS was not yet up

2016-09-07 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471931#comment-15471931
 ] 

Hudson commented on AMBARI-18191:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #4 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/4/])
AMBARI-18191. Restart all required services operation failed at Metrics 
(swagle: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=6ec16941565debd031eefffad8c8160a7b4d7e59])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/metadata/RoleCommandOrder.java
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/metadata/RoleCommandOrderTest.java


> "Restart all required" services operation failed at Metrics Collector since 
> HDFS was not yet up
> ---
>
> Key: AMBARI-18191
> URL: https://issues.apache.org/jira/browse/AMBARI-18191
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Sunitha
>Assignee: Siddharth Wagle
>Priority: Blocker
> Fix For: trunk
>
> Attachments: AMBARI-18191.patch
>
>
> ambari-server --hash
> 4017036da951a10f519a578de934308cf866ba50
> *Steps*
> # Deploy HDP-2.3.6 cluster with Ambari 2.2.2.0 (AMS is configured in 
> distributed mode)
> # Upgrade Ambari to 2.4.0.0 and let it complete
> # Open Ambari web UI and hit "Restart all required" under Actions menu
> *Result*
> The operation fails while trying to restart Metrics Collector as it tried to 
> make a WebHDFS call while HDFS was not started:
> {code}
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_collector.py",
>  line 148, in 
> AmsCollector().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 280, in execute
> method(env)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 725, in restart
> self.start(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_collector.py",
>  line 46, in start
> self.configure(env, action = 'start') # for security
>   File 
> "/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_collector.py",
>  line 41, in configure
> hbase('master', action)
>   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/AMBARI_METRICS/0.1.0/package/scripts/hbase.py",
>  line 213, in hbase
> dfs_type=params.dfs_type
>   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/libraries/providers/hdfs_resource.py",
>  line 459, in action_create_on_execute
> self.action_delayed("create")
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
>  line 456, 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 256, in action_delayed
> self._set_mode(self.target_status)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
>  line 363, in _set_mode
> self.util.run_command(self.main_resource.resource.target, 
> 'SETPERMISSION', method='PUT', permission=self.mode, assertable_result=False)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
>  line 179, in run_command
> _, out, err = get_user_call_output(cmd, user=self.run_user, 
> logoutput=self.logoutput, quiet=False)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/functions/get_user_call_output.py",
>  line 61, in get_user_call_output
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'curl -sS -L -w 
> '%{http_code}' -X PUT --negotiate -u : 
> 'http://vsharma-eu-mt-5.openstacklocal:50070/webhdfs/v1/user/ams/hbase?op=SETPERMISSION=hdfs=775'
>  1>/tmp/tmp8twcZt 2>/tmp/tmpLPih9a' returned 7. curl: (7) couldn't connect to 
> host
> 401
> {code}
> Afterwards, restarted HDFS individually first and then hit "Restart all 
> Required" - 

[jira] [Updated] (AMBARI-18317) ambari-agent script does not check for unset variables. (Leading to chown root:root /)

2016-09-07 Thread Jeff Sposetti (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Sposetti updated AMBARI-18317:
---
Fix Version/s: (was: 2.4.0)
   2.4.2

> ambari-agent script does not check for unset variables. (Leading to chown 
> root:root /)
> --
>
> Key: AMBARI-18317
> URL: https://issues.apache.org/jira/browse/AMBARI-18317
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: 2.4.0
> Environment: Ubuntu 14.04
> Hortonworks provided package: ambari-agent 4.2.0.1-1
>Reporter: Ryan Walder
> Fix For: 2.4.2
>
>
> Using the following config (unchanged from a previous install, so missing 
> options relevant to 2.4.0.1) with ambari-agent 2.4.0.1 causes the 
> ambari-agent script to chown the entire filesystem as root.
> {noformat}
> [logging]
> syslog_enabled=0
> [agent]
> ping_port=8670
> data_cleanup_max_size_MB=100
> prefix=/var/lib/ambari-agent/data
> cache_dir=/var/lib/ambari-agent/cache
> tolerate_download_failures=true
> parallel_execution=0
> data_cleanup_interval=86400
> tolerate_download_failuresf=false
> data_cleanup_max_age=2592000
> loglevel=INFO
> run_as_user=root
> [server]
> secured_url_port=8441
> hostname=cs-vagrant-hadoop-ambarimaster-01.gel.zone
> url_port=8440
> [services]
> pidLookupPath=/var/run/
> [heartbeat]
> dirs=/etc/hadoop,/etc/hadoop/conf,/etc/hbase,/etc/hcatalog,/etc/hive,/etc/oozie,/etc/sqoop,/etc/ganglia,/var/run/hadoop,/var/run/zookeeper,/var/run/hbase,/var/run/templeton,/var/run/oozie,/var/log/hadoop,/var/log/zookeeper,/var/log/hbase,/var/run/templeton,/var/log/hive
> log_lines_count=300
> state_interval=6
> [security]
> server_crt=ca.crt
> keysdir=/var/lib/ambari-agent/keys
> passphrase_env_var_name=AMBARI_PASSPHRASE
> ryanwalder@ryanwlaptop:~$ vi old 
> ryanwalder@ryanwlaptop:~$ vi old 
> ryanwalder@ryanwlaptop:~$ vi old 
> ryanwalder@ryanwlaptop:~$ cat old 
> [logging]
> syslog_enabled=0
> [agent]
> ping_port=8670
> data_cleanup_max_size_MB=100
> prefix=/var/lib/ambari-agent/data
> cache_dir=/var/lib/ambari-agent/cache
> tolerate_download_failures=true
> parallel_execution=0
> data_cleanup_interval=86400
> tolerate_download_failuresf=false
> data_cleanup_max_age=2592000
> loglevel=INFO
> run_as_user=root
> [server]
> secured_url_port=8441
> hostname=cs-vagrant-hadoop-ambarimaster-01.gel.zone
> url_port=8440
> [services]
> pidLookupPath=/var/run/
> [heartbeat]
> dirs=/etc/hadoop,/etc/hadoop/conf,/etc/hbase,/etc/hcatalog,/etc/hive,/etc/oozie,/etc/sqoop,/etc/ganglia,/var/run/hadoop,/var/run/zookeeper,/var/run/hbase,/var/run/templeton,/var/run/oozie,/var/log/hadoop,/var/log/zookeeper,/var/log/hbase,/var/run/templeton,/var/log/hive
> log_lines_count=300
> state_interval=6
> [security]
> server_crt=ca.crt
> keysdir=/var/lib/ambari-agent/keys
> passphrase_env_var_name=AMBARI_PASSPHRASE
> {noformat}
> It looks like the following lines are to blame
> {noformat}
> ambari-sudo.sh chown -R $current_user "$AMBARI_PID_DIR/"
> ambari-sudo.sh mkdir -p "$AMBARI_AGENT_LOG_DIR"
> ambari-sudo.sh chown -R $current_user:$current_group 
> "$AMBARI_AGENT_LOG_DIR/"
> {noformat}
> No checking for unset variables in 2016? Top notch.
> http://www.davidpashley.com/articles/writing-robust-shell-scripts/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-17898) Add Kerberos HTTP SPNEGO authentication support to Ambari Metrics Monitor

2016-09-07 Thread Qin Liu (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-17898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Qin Liu updated AMBARI-17898:
-
Status: Patch Available  (was: In Progress)

> Add Kerberos HTTP SPNEGO authentication support to Ambari Metrics Monitor
> -
>
> Key: AMBARI-17898
> URL: https://issues.apache.org/jira/browse/AMBARI-17898
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-metrics
>Affects Versions: 2.2.0
>Reporter: Qin Liu
>Assignee: Qin Liu
> Fix For: trunk
>
> Attachments: AMBARI-17898.patch
>
>
> This is a subtask of AMBARI-14384 "Ambari Metrics doesn't use SPNEGO to 
> authenticate".
> In a Kerberos enabled cluster with SPNEGO enabled on Hadoop APIs, Ambari 
> Metrics Collector web-console will be Kerberos HTTP SPNEGO enabled too. But 
> Ambari Metrics Monitor, a client of Ambari Metrics Collector, currently does 
> not support Kerberos HTTP SPNEGO authentication.  
> /var/log/ambari-metrics-monitor/ambari-metrics-monitor.out:
> 2015-12-15 13:26:30,663 [INFO] emitter.py:101 - server: 
> http://metrics-collector:6188/ws/v1/timeline/metrics
> 2015-12-15 13:26:30,671 [WARNING] emitter.py:84 - Error sending metrics to 
> server. HTTP Error 401: Authentication required
> 2015-12-15 13:26:30,671 [WARNING] emitter.py:90 - Retrying after 5 ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-17898) Add Kerberos HTTP SPNEGO authentication support to Ambari Metrics Monitor

2016-09-07 Thread Qin Liu (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-17898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Qin Liu updated AMBARI-17898:
-
Fix Version/s: (was: 2.4.0)

> Add Kerberos HTTP SPNEGO authentication support to Ambari Metrics Monitor
> -
>
> Key: AMBARI-17898
> URL: https://issues.apache.org/jira/browse/AMBARI-17898
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-metrics
>Affects Versions: 2.2.0
>Reporter: Qin Liu
>Assignee: Qin Liu
> Fix For: trunk
>
> Attachments: AMBARI-17898.patch
>
>
> This is a subtask of AMBARI-14384 "Ambari Metrics doesn't use SPNEGO to 
> authenticate".
> In a Kerberos enabled cluster with SPNEGO enabled on Hadoop APIs, Ambari 
> Metrics Collector web-console will be Kerberos HTTP SPNEGO enabled too. But 
> Ambari Metrics Monitor, a client of Ambari Metrics Collector, currently does 
> not support Kerberos HTTP SPNEGO authentication.  
> /var/log/ambari-metrics-monitor/ambari-metrics-monitor.out:
> 2015-12-15 13:26:30,663 [INFO] emitter.py:101 - server: 
> http://metrics-collector:6188/ws/v1/timeline/metrics
> 2015-12-15 13:26:30,671 [WARNING] emitter.py:84 - Error sending metrics to 
> server. HTTP Error 401: Authentication required
> 2015-12-15 13:26:30,671 [WARNING] emitter.py:90 - Retrying after 5 ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-17898) Add Kerberos HTTP SPNEGO authentication support to Ambari Metrics Monitor

2016-09-07 Thread Qin Liu (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-17898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Qin Liu updated AMBARI-17898:
-
Fix Version/s: 2.4.0

> Add Kerberos HTTP SPNEGO authentication support to Ambari Metrics Monitor
> -
>
> Key: AMBARI-17898
> URL: https://issues.apache.org/jira/browse/AMBARI-17898
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-metrics
>Affects Versions: 2.2.0
>Reporter: Qin Liu
>Assignee: Qin Liu
> Fix For: trunk, 2.4.0
>
> Attachments: AMBARI-17898.patch
>
>
> This is a subtask of AMBARI-14384 "Ambari Metrics doesn't use SPNEGO to 
> authenticate".
> In a Kerberos enabled cluster with SPNEGO enabled on Hadoop APIs, Ambari 
> Metrics Collector web-console will be Kerberos HTTP SPNEGO enabled too. But 
> Ambari Metrics Monitor, a client of Ambari Metrics Collector, currently does 
> not support Kerberos HTTP SPNEGO authentication.  
> /var/log/ambari-metrics-monitor/ambari-metrics-monitor.out:
> 2015-12-15 13:26:30,663 [INFO] emitter.py:101 - server: 
> http://metrics-collector:6188/ws/v1/timeline/metrics
> 2015-12-15 13:26:30,671 [WARNING] emitter.py:84 - Error sending metrics to 
> server. HTTP Error 401: Authentication required
> 2015-12-15 13:26:30,671 [WARNING] emitter.py:90 - Retrying after 5 ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-17898) Add Kerberos HTTP SPNEGO authentication support to Ambari Metrics Monitor

2016-09-07 Thread Qin Liu (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-17898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Qin Liu updated AMBARI-17898:
-
Fix Version/s: trunk

> Add Kerberos HTTP SPNEGO authentication support to Ambari Metrics Monitor
> -
>
> Key: AMBARI-17898
> URL: https://issues.apache.org/jira/browse/AMBARI-17898
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-metrics
>Affects Versions: 2.2.0
>Reporter: Qin Liu
>Assignee: Qin Liu
> Fix For: trunk
>
> Attachments: AMBARI-17898.patch
>
>
> This is a subtask of AMBARI-14384 "Ambari Metrics doesn't use SPNEGO to 
> authenticate".
> In a Kerberos enabled cluster with SPNEGO enabled on Hadoop APIs, Ambari 
> Metrics Collector web-console will be Kerberos HTTP SPNEGO enabled too. But 
> Ambari Metrics Monitor, a client of Ambari Metrics Collector, currently does 
> not support Kerberos HTTP SPNEGO authentication.  
> /var/log/ambari-metrics-monitor/ambari-metrics-monitor.out:
> 2015-12-15 13:26:30,663 [INFO] emitter.py:101 - server: 
> http://metrics-collector:6188/ws/v1/timeline/metrics
> 2015-12-15 13:26:30,671 [WARNING] emitter.py:84 - Error sending metrics to 
> server. HTTP Error 401: Authentication required
> 2015-12-15 13:26:30,671 [WARNING] emitter.py:90 - Retrying after 5 ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-17898) Add Kerberos HTTP SPNEGO authentication support to Ambari Metrics Monitor

2016-09-07 Thread Qin Liu (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-17898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Qin Liu updated AMBARI-17898:
-
Attachment: AMBARI-17898.patch

> Add Kerberos HTTP SPNEGO authentication support to Ambari Metrics Monitor
> -
>
> Key: AMBARI-17898
> URL: https://issues.apache.org/jira/browse/AMBARI-17898
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-metrics
>Affects Versions: 2.2.0
>Reporter: Qin Liu
>Assignee: Qin Liu
> Attachments: AMBARI-17898.patch
>
>
> This is a subtask of AMBARI-14384 "Ambari Metrics doesn't use SPNEGO to 
> authenticate".
> In a Kerberos enabled cluster with SPNEGO enabled on Hadoop APIs, Ambari 
> Metrics Collector web-console will be Kerberos HTTP SPNEGO enabled too. But 
> Ambari Metrics Monitor, a client of Ambari Metrics Collector, currently does 
> not support Kerberos HTTP SPNEGO authentication.  
> /var/log/ambari-metrics-monitor/ambari-metrics-monitor.out:
> 2015-12-15 13:26:30,663 [INFO] emitter.py:101 - server: 
> http://metrics-collector:6188/ws/v1/timeline/metrics
> 2015-12-15 13:26:30,671 [WARNING] emitter.py:84 - Error sending metrics to 
> server. HTTP Error 401: Authentication required
> 2015-12-15 13:26:30,671 [WARNING] emitter.py:90 - Retrying after 5 ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18328) Blueprints: Log "setting" section of blueprint in ambari server log file

2016-09-07 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471871#comment-15471871
 ] 

Hudson commented on AMBARI-18328:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5633 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5633/])
AMBARI-18328: Blueprints: Log "setting" section of blueprint in ambari 
(nsomasundaram: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=73aa4d90e56941a4a6f7eb7ffa3127c5b4a82e45])
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintResourceProviderTest.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintResourceProvider.java


> Blueprints: Log "setting" section of blueprint in ambari server log file
> 
>
> Key: AMBARI-18328
> URL: https://issues.apache.org/jira/browse/AMBARI-18328
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: 2.5.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.5.0
>
> Attachments: rb51685 (1).patch, rb51685.patch
>
>
> A new section "setting" was added to the blueprint JSON to support auto 
> restart of components. When deploying the blueprint, logging the setting 
> section will help debugging blueprint deployments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18290) Ambari does not support HBase on HTTPS mode

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471873#comment-15471873
 ] 

Hadoop QA commented on AMBARI-18290:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827448/18290.txt
  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/8605//console

This message is automatically generated.

> Ambari does not support HBase on HTTPS mode
> ---
>
> Key: AMBARI-18290
> URL: https://issues.apache.org/jira/browse/AMBARI-18290
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0, 2.2.2
> Environment: all
>Reporter: amarnathreddy
>Assignee: amarnathreddy
>Priority: Critical
> Attachments: 18290.txt
>
>
> Ambari  tries to talk to Hbase URL on HTTP mode even after SSL is enabled for 
> HBase master. There is an issue when Ambari trying to retrive HBase JMX 
> parameters. Because of this Ambari shows incorrect information about 
> Active/Standby 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18290) Ambari does not support HBase on HTTPS mode

2016-09-07 Thread amarnathreddy (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

amarnathreddy updated AMBARI-18290:
---
Status: Patch Available  (was: In Progress)

> Ambari does not support HBase on HTTPS mode
> ---
>
> Key: AMBARI-18290
> URL: https://issues.apache.org/jira/browse/AMBARI-18290
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0, 2.2.2
> Environment: all
>Reporter: amarnathreddy
>Assignee: amarnathreddy
>Priority: Critical
> Attachments: 18290.txt
>
>
> Ambari  tries to talk to Hbase URL on HTTP mode even after SSL is enabled for 
> HBase master. There is an issue when Ambari trying to retrive HBase JMX 
> parameters. Because of this Ambari shows incorrect information about 
> Active/Standby 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18290) Ambari does not support HBase on HTTPS mode

2016-09-07 Thread amarnathreddy (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

amarnathreddy updated AMBARI-18290:
---
Attachment: 18290.txt

Here I am attaching the patch which can be applied on top on 2.4.0.1

> Ambari does not support HBase on HTTPS mode
> ---
>
> Key: AMBARI-18290
> URL: https://issues.apache.org/jira/browse/AMBARI-18290
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0, 2.2.2
> Environment: all
>Reporter: amarnathreddy
>Assignee: amarnathreddy
>Priority: Critical
> Attachments: 18290.txt
>
>
> Ambari  tries to talk to Hbase URL on HTTP mode even after SSL is enabled for 
> HBase master. There is an issue when Ambari trying to retrive HBase JMX 
> parameters. Because of this Ambari shows incorrect information about 
> Active/Standby 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (AMBARI-18336) RAT check failure

2016-09-07 Thread Sumit Mohanty (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sumit Mohanty resolved AMBARI-18336.

Resolution: Fixed

committed to 2.4.1/2.5/trunk

> RAT check failure
> -
>
> Key: AMBARI-18336
> URL: https://issues.apache.org/jira/browse/AMBARI-18336
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.1
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
>Priority: Critical
> Fix For: 2.4.1
>
> Attachments: AMBARI-18336.patch
>
>
> 1 Unknown Licenses
> ***
> Unapproved licenses:
>   
> ../ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/templates/atlas_kafka_acl.sh.j2
> ***



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (AMBARI-18336) RAT check failure

2016-09-07 Thread Sumit Mohanty (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471748#comment-15471748
 ] 

Sumit Mohanty edited comment on AMBARI-18336 at 9/7/16 8:48 PM:


committed to 2.4/2.5/trunk


was (Author: sumitmohanty):
committed to 2.4.1/2.5/trunk

> RAT check failure
> -
>
> Key: AMBARI-18336
> URL: https://issues.apache.org/jira/browse/AMBARI-18336
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.1
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
>Priority: Critical
> Fix For: 2.4.1
>
> Attachments: AMBARI-18336.patch
>
>
> 1 Unknown Licenses
> ***
> Unapproved licenses:
>   
> ../ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/templates/atlas_kafka_acl.sh.j2
> ***



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18333) While checking for component dependency code looks for incorrect component name

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471745#comment-15471745
 ] 

Hadoop QA commented on AMBARI-18333:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827408/AMBARI-18333.patch
  against trunk revision .

{color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8604//console

This message is automatically generated.

> While checking for component dependency code looks for incorrect component 
> name
> ---
>
> Key: AMBARI-18333
> URL: https://issues.apache.org/jira/browse/AMBARI-18333
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-18333.patch
>
>
> While validating host groups in blueprint for component dependency, code 
> should check if a dependency component is present in the host group component 
> list rather than the component on whose dependency list it is iterating.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18334) Password in the configurations.json file in the ambari-agent cache is not encrypted

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471735#comment-15471735
 ] 

Hadoop QA commented on AMBARI-18334:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827417/AMBARI-18334.patch
  against trunk revision .

{color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8603//console

This message is automatically generated.

> Password in the configurations.json file in the ambari-agent cache is not 
> encrypted
> ---
>
> Key: AMBARI-18334
> URL: https://issues.apache.org/jira/browse/AMBARI-18334
> Project: Ambari
>  Issue Type: Bug
>Reporter: Anita Gnanamalar Jebaraj
>Assignee: Anita Gnanamalar Jebaraj
> Attachments: AMBARI-18334.patch
>
>
> The  configurations.json  file loaded in the ambari-agent cache located at  
> /var/lib/ambari-agent/cache/cluster_configuration contains password details 
> in plaintext (Ex: ssl.client.keystore.password,ssl.client.truststore.password 
> etc.). The values are loaded both in the memory cache and file cache, the 
> file seems to be used only for debugging purposes, so it would be a better 
> approach to mask the passwords in the file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18336) RAT check failure

2016-09-07 Thread Siddharth Wagle (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471731#comment-15471731
 ] 

Siddharth Wagle commented on AMBARI-18336:
--

+1

> RAT check failure
> -
>
> Key: AMBARI-18336
> URL: https://issues.apache.org/jira/browse/AMBARI-18336
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.1
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
>Priority: Critical
> Fix For: 2.4.1
>
> Attachments: AMBARI-18336.patch
>
>
> 1 Unknown Licenses
> ***
> Unapproved licenses:
>   
> ../ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/templates/atlas_kafka_acl.sh.j2
> ***



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18328) Blueprints: Log "setting" section of blueprint in ambari server log file

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471725#comment-15471725
 ] 

Hadoop QA commented on AMBARI-18328:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12827432/rb51685%20%281%29.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/8602//console

This message is automatically generated.

> Blueprints: Log "setting" section of blueprint in ambari server log file
> 
>
> Key: AMBARI-18328
> URL: https://issues.apache.org/jira/browse/AMBARI-18328
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: 2.5.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.5.0
>
> Attachments: rb51685 (1).patch, rb51685.patch
>
>
> A new section "setting" was added to the blueprint JSON to support auto 
> restart of components. When deploying the blueprint, logging the setting 
> section will help debugging blueprint deployments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18321) atlas hook for hive and storm fail to push metadeta

2016-09-07 Thread Dmytro Grinenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-18321:
-
Attachment: AMBARI-18321-rat-fix.patch

> atlas hook for hive and storm fail to push metadeta
> ---
>
> Key: AMBARI-18321
> URL: https://issues.apache.org/jira/browse/AMBARI-18321
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Dmytro Grinenko
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-18321-rat-fix.patch, AMBARI-18321.patch, 
> AMBARI-18321.patch.1
>
>
> 1] On the upgraded cluster we added Atlas service 
> 2] On submitting the storm topology,atlas hook fails to send metadata. 
> Attached logs [ storm_atlas.log] where connect to kafka is failing.
> 3] Hive hook is also failing with the same error as below
> {code}
> Caused by: javax.security.auth.login.LoginException: Could not login: the 
> client is being asked for a password, but the Kafka client code does not 
> currently support obtaining a password from the user. not available to garner 
>  authentication information from the user
> at 
> com.sun.security.auth.module.Krb5LoginModule.promptForPass(Krb5LoginModule.java:940)
> at 
> com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:760)
> at 
> com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
> at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
> at 
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at 
> org.apache.kafka.common.security.authenticator.AbstractLogin.login(AbstractLogin.java:69)
> at 
> org.apache.kafka.common.security.kerberos.KerberosLogin.login(KerberosLogin.java:110)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.(LoginManager.java:46)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.acquireLoginManager(LoginManager.java:68)
> at 
> org.apache.kafka.common.network.SaslChannelBuilder.configure(SaslChannelBuilder.java:78)
> ... 18 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18308) Ambari UI: Memory leak while adding and removing property

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471723#comment-15471723
 ] 

Hadoop QA commented on AMBARI-18308:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827440/AMBARI-18308.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/8601//console

This message is automatically generated.

> Ambari UI: Memory leak while adding and removing property
> -
>
> Key: AMBARI-18308
> URL: https://issues.apache.org/jira/browse/AMBARI-18308
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Santhosh B Gowda
>Assignee: Jaimin D Jetly
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18308.patch
>
>
> Go to any of the service config screen ( for e.x Hive ) and add and remove 
> multiple properties one after another (without using bulk add).
> This results in javascript memory leak.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18324) Externalize skip repo url check to ambari.properties instead of hardcoding it in Ambari Java code

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471720#comment-15471720
 ] 

Hadoop QA commented on AMBARI-18324:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827224/AMBARI-18324.patch
  against trunk revision .

{color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8600//console

This message is automatically generated.

> Externalize skip repo url check to ambari.properties instead of hardcoding it 
> in Ambari Java code
> -
>
> Key: AMBARI-18324
> URL: https://issues.apache.org/jira/browse/AMBARI-18324
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-trunk
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
> Fix For: trunk
>
> Attachments: AMBARI-18324.patch
>
>
> Externalize skip repo url check to ambari.properties instead of hardcoding it 
> in Ambari Java code, so that users can define what repo ids to skip repo urls 
> validation when adding repos for the given stack



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18336) RAT check failure

2016-09-07 Thread Sumit Mohanty (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sumit Mohanty updated AMBARI-18336:
---
Attachment: AMBARI-18336.patch

> RAT check failure
> -
>
> Key: AMBARI-18336
> URL: https://issues.apache.org/jira/browse/AMBARI-18336
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.1
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
>Priority: Critical
> Fix For: 2.4.1
>
> Attachments: AMBARI-18336.patch
>
>
> 1 Unknown Licenses
> ***
> Unapproved licenses:
>   
> ../ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/templates/atlas_kafka_acl.sh.j2
> ***



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (AMBARI-18336) RAT check failure

2016-09-07 Thread Sumit Mohanty (JIRA)
Sumit Mohanty created AMBARI-18336:
--

 Summary: RAT check failure
 Key: AMBARI-18336
 URL: https://issues.apache.org/jira/browse/AMBARI-18336
 Project: Ambari
  Issue Type: Bug
  Components: stacks
Affects Versions: 2.4.1
Reporter: Sumit Mohanty
Assignee: Sumit Mohanty
Priority: Critical
 Fix For: 2.4.1



1 Unknown Licenses

***

Unapproved licenses:

  
../ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/templates/atlas_kafka_acl.sh.j2

***



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18308) Ambari UI: Memory leak while adding and removing property

2016-09-07 Thread Jaimin D Jetly (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jaimin D Jetly updated AMBARI-18308:

Attachment: AMBARI-18308.patch

> Ambari UI: Memory leak while adding and removing property
> -
>
> Key: AMBARI-18308
> URL: https://issues.apache.org/jira/browse/AMBARI-18308
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Santhosh B Gowda
>Assignee: Jaimin D Jetly
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18308.patch
>
>
> Go to any of the service config screen ( for e.x Hive ) and add and remove 
> multiple properties one after another (without using bulk add).
> This results in javascript memory leak.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18308) Ambari UI: Memory leak while adding and removing property

2016-09-07 Thread Jaimin D Jetly (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jaimin D Jetly updated AMBARI-18308:

Status: Patch Available  (was: Open)

> Ambari UI: Memory leak while adding and removing property
> -
>
> Key: AMBARI-18308
> URL: https://issues.apache.org/jira/browse/AMBARI-18308
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Santhosh B Gowda
>Assignee: Jaimin D Jetly
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18308.patch
>
>
> Go to any of the service config screen ( for e.x Hive ) and add and remove 
> multiple properties one after another (without using bulk add).
> This results in javascript memory leak.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18191) "Restart all required" services operation failed at Metrics Collector since HDFS was not yet up

2016-09-07 Thread Siddharth Wagle (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Siddharth Wagle updated AMBARI-18191:
-
Reporter: Sunitha  (was: Aravindan Vijayan)

> "Restart all required" services operation failed at Metrics Collector since 
> HDFS was not yet up
> ---
>
> Key: AMBARI-18191
> URL: https://issues.apache.org/jira/browse/AMBARI-18191
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Sunitha
>Assignee: Siddharth Wagle
>Priority: Blocker
> Fix For: trunk
>
> Attachments: AMBARI-18191.patch
>
>
> ambari-server --hash
> 4017036da951a10f519a578de934308cf866ba50
> *Steps*
> # Deploy HDP-2.3.6 cluster with Ambari 2.2.2.0 (AMS is configured in 
> distributed mode)
> # Upgrade Ambari to 2.4.0.0 and let it complete
> # Open Ambari web UI and hit "Restart all required" under Actions menu
> *Result*
> The operation fails while trying to restart Metrics Collector as it tried to 
> make a WebHDFS call while HDFS was not started:
> {code}
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_collector.py",
>  line 148, in 
> AmsCollector().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 280, in execute
> method(env)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 725, in restart
> self.start(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_collector.py",
>  line 46, in start
> self.configure(env, action = 'start') # for security
>   File 
> "/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_collector.py",
>  line 41, in configure
> hbase('master', action)
>   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/AMBARI_METRICS/0.1.0/package/scripts/hbase.py",
>  line 213, in hbase
> dfs_type=params.dfs_type
>   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/libraries/providers/hdfs_resource.py",
>  line 459, in action_create_on_execute
> self.action_delayed("create")
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
>  line 456, 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 256, in action_delayed
> self._set_mode(self.target_status)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
>  line 363, in _set_mode
> self.util.run_command(self.main_resource.resource.target, 
> 'SETPERMISSION', method='PUT', permission=self.mode, assertable_result=False)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
>  line 179, in run_command
> _, out, err = get_user_call_output(cmd, user=self.run_user, 
> logoutput=self.logoutput, quiet=False)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/functions/get_user_call_output.py",
>  line 61, in get_user_call_output
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'curl -sS -L -w 
> '%{http_code}' -X PUT --negotiate -u : 
> 'http://vsharma-eu-mt-5.openstacklocal:50070/webhdfs/v1/user/ams/hbase?op=SETPERMISSION=hdfs=775'
>  1>/tmp/tmp8twcZt 2>/tmp/tmpLPih9a' returned 7. curl: (7) couldn't connect to 
> host
> 401
> {code}
> Afterwards, restarted HDFS individually first and then hit "Restart all 
> Required" - the operation was successful
> Looks like the issue is because the order of restart is incorrect across the 
> hosts, hence the dependent services don't come up upfront



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18308) Ambari UI: Memory leak while adding and removing property

2016-09-07 Thread Jaimin D Jetly (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jaimin D Jetly updated AMBARI-18308:

Fix Version/s: (was: 2.4.1)
   2.5.0

> Ambari UI: Memory leak while adding and removing property
> -
>
> Key: AMBARI-18308
> URL: https://issues.apache.org/jira/browse/AMBARI-18308
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Santhosh B Gowda
>Assignee: Jaimin D Jetly
>Priority: Critical
> Fix For: 2.5.0
>
>
> Go to any of the service config screen ( for e.x Hive ) and add and remove 
> multiple properties one after another (without using bulk add).
> This results in javascript memory leak.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (AMBARI-18308) Ambari UI: Memory leak while adding and removing property

2016-09-07 Thread Jaimin D Jetly (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jaimin D Jetly reassigned AMBARI-18308:
---

Assignee: Jaimin D Jetly

> Ambari UI: Memory leak while adding and removing property
> -
>
> Key: AMBARI-18308
> URL: https://issues.apache.org/jira/browse/AMBARI-18308
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Santhosh B Gowda
>Assignee: Jaimin D Jetly
>Priority: Critical
> Fix For: 2.4.1
>
>
> Go to any of the service config screen ( for e.x Hive ) and add and remove 
> multiple properties one after another (without using bulk add).
> This results in javascript memory leak.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18328) Blueprints: Log "setting" section of blueprint in ambari server log file

2016-09-07 Thread Nahappan Somasundaram (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nahappan Somasundaram updated AMBARI-18328:
---
Status: Patch Available  (was: Open)

> Blueprints: Log "setting" section of blueprint in ambari server log file
> 
>
> Key: AMBARI-18328
> URL: https://issues.apache.org/jira/browse/AMBARI-18328
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: 2.5.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.5.0
>
> Attachments: rb51685 (1).patch, rb51685.patch
>
>
> A new section "setting" was added to the blueprint JSON to support auto 
> restart of components. When deploying the blueprint, logging the setting 
> section will help debugging blueprint deployments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18328) Blueprints: Log "setting" section of blueprint in ambari server log file

2016-09-07 Thread Nahappan Somasundaram (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nahappan Somasundaram updated AMBARI-18328:
---
Attachment: rb51685 (1).patch

> Blueprints: Log "setting" section of blueprint in ambari server log file
> 
>
> Key: AMBARI-18328
> URL: https://issues.apache.org/jira/browse/AMBARI-18328
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: 2.5.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.5.0
>
> Attachments: rb51685 (1).patch, rb51685.patch
>
>
> A new section "setting" was added to the blueprint JSON to support auto 
> restart of components. When deploying the blueprint, logging the setting 
> section will help debugging blueprint deployments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18328) Blueprints: Log "setting" section of blueprint in ambari server log file

2016-09-07 Thread Nahappan Somasundaram (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nahappan Somasundaram updated AMBARI-18328:
---
Status: Open  (was: Patch Available)

> Blueprints: Log "setting" section of blueprint in ambari server log file
> 
>
> Key: AMBARI-18328
> URL: https://issues.apache.org/jira/browse/AMBARI-18328
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: 2.5.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.5.0
>
> Attachments: rb51685.patch
>
>
> A new section "setting" was added to the blueprint JSON to support auto 
> restart of components. When deploying the blueprint, logging the setting 
> section will help debugging blueprint deployments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18321) atlas hook for hive and storm fail to push metadeta

2016-09-07 Thread Robert Levas (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471505#comment-15471505
 ] 

Robert Levas commented on AMBARI-18321:
---

[~dmitriusan], The patch commit for this is missing the appropriate header in 
{{common-services/ATLAS/0.1.0.2.3/package/templates/atlas_kafka_acl.sh.j2}} and 
thus the rat check is failing. 

Please fix.

> atlas hook for hive and storm fail to push metadeta
> ---
>
> Key: AMBARI-18321
> URL: https://issues.apache.org/jira/browse/AMBARI-18321
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Dmytro Grinenko
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-18321.patch, AMBARI-18321.patch.1
>
>
> 1] On the upgraded cluster we added Atlas service 
> 2] On submitting the storm topology,atlas hook fails to send metadata. 
> Attached logs [ storm_atlas.log] where connect to kafka is failing.
> 3] Hive hook is also failing with the same error as below
> {code}
> Caused by: javax.security.auth.login.LoginException: Could not login: the 
> client is being asked for a password, but the Kafka client code does not 
> currently support obtaining a password from the user. not available to garner 
>  authentication information from the user
> at 
> com.sun.security.auth.module.Krb5LoginModule.promptForPass(Krb5LoginModule.java:940)
> at 
> com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:760)
> at 
> com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
> at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
> at 
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at 
> org.apache.kafka.common.security.authenticator.AbstractLogin.login(AbstractLogin.java:69)
> at 
> org.apache.kafka.common.security.kerberos.KerberosLogin.login(KerberosLogin.java:110)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.(LoginManager.java:46)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.acquireLoginManager(LoginManager.java:68)
> at 
> org.apache.kafka.common.network.SaslChannelBuilder.configure(SaslChannelBuilder.java:78)
> ... 18 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18321) atlas hook for hive and storm fail to push metadeta

2016-09-07 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471475#comment-15471475
 ] 

Hudson commented on AMBARI-18321:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5632 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5632/])
AMBARI-18321. atlas hook for hive and storm fail to push metadeta 
(dlysnichenko: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=6e60b469c5ff87a328f0849d08c21c0730d0649e])
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.5/services/ATLAS/metainfo.xml
* (edit) 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata.py
* (edit) 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata_server.py
* (edit) 
ambari-server/src/main/resources/common-services/ATLAS/0.7.0.2.5/kerberos.json
* (edit) ambari-server/src/test/python/stacks/utils/RMFTestCase.py
* (add) 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/templates/kafka_jaas.conf.j2
* (edit) 
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/hbase_regionserver.py
* (edit) 
ambari-common/src/main/python/resource_management/libraries/script/script.py
* (edit) 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py
* (add) 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/templates/atlas_kafka_acl.sh.j2
* (edit) 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/status_params.py
* (edit) ambari-server/src/test/python/TestAmbariServer.py


> atlas hook for hive and storm fail to push metadeta
> ---
>
> Key: AMBARI-18321
> URL: https://issues.apache.org/jira/browse/AMBARI-18321
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Dmytro Grinenko
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-18321.patch, AMBARI-18321.patch.1
>
>
> 1] On the upgraded cluster we added Atlas service 
> 2] On submitting the storm topology,atlas hook fails to send metadata. 
> Attached logs [ storm_atlas.log] where connect to kafka is failing.
> 3] Hive hook is also failing with the same error as below
> {code}
> Caused by: javax.security.auth.login.LoginException: Could not login: the 
> client is being asked for a password, but the Kafka client code does not 
> currently support obtaining a password from the user. not available to garner 
>  authentication information from the user
> at 
> com.sun.security.auth.module.Krb5LoginModule.promptForPass(Krb5LoginModule.java:940)
> at 
> com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:760)
> at 
> com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
> at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
> at 
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at 
> org.apache.kafka.common.security.authenticator.AbstractLogin.login(AbstractLogin.java:69)
> at 
> org.apache.kafka.common.security.kerberos.KerberosLogin.login(KerberosLogin.java:110)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.(LoginManager.java:46)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.acquireLoginManager(LoginManager.java:68)
> at 
> org.apache.kafka.common.network.SaslChannelBuilder.configure(SaslChannelBuilder.java:78)
> ... 18 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (AMBARI-18335) After upgrading cluster from HDP-2.4.x to HDP-2.5.x and added atlas service - missing kafka security properties

2016-09-07 Thread Robert Levas (JIRA)
Robert Levas created AMBARI-18335:
-

 Summary: After upgrading cluster from HDP-2.4.x to HDP-2.5.x and 
added atlas service - missing kafka security properties
 Key: AMBARI-18335
 URL: https://issues.apache.org/jira/browse/AMBARI-18335
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.4.0
Reporter: Robert Levas
Assignee: Robert Levas
 Fix For: 2.4.1


Steps to repro:
* Install Ambari 2.2.2
* Install HDP-2.4.x cluster with Atlas
* Stop Atlas
* Upgrade Ambari to 2.4
* Delete Atlas service
* Upgrade the cluster to HDP-2.5.x cluster
* Add Atlas service.

*Below config properties are missing from atlas-applicataion.properties file 
for Atlas, Storm, Falcon, Hive services.*
#atlas.jaas.KafkaClient.option.keyTab = 
/etc/security/keytabs/atlas.service.keytab
#atlas.jaas.KafkaClient.option.principal = atlas/_h...@example.com

>From HDP 2.4 to 2.5, the kerberos.json file for Atlas changed.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18334) Password in the configurations.json file in the ambari-agent cache is not encrypted

2016-09-07 Thread Anita Gnanamalar Jebaraj (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anita Gnanamalar Jebaraj updated AMBARI-18334:
--
Attachment: AMBARI-18334.patch

> Password in the configurations.json file in the ambari-agent cache is not 
> encrypted
> ---
>
> Key: AMBARI-18334
> URL: https://issues.apache.org/jira/browse/AMBARI-18334
> Project: Ambari
>  Issue Type: Bug
>Reporter: Anita Gnanamalar Jebaraj
> Attachments: AMBARI-18334.patch
>
>
> The  configurations.json  file loaded in the ambari-agent cache located at  
> /var/lib/ambari-agent/cache/cluster_configuration contains password details 
> in plaintext (Ex: ssl.client.keystore.password,ssl.client.truststore.password 
> etc.). The values are loaded both in the memory cache and file cache, the 
> file seems to be used only for debugging purposes, so it would be a better 
> approach to mask the passwords in the file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18334) Password in the configurations.json file in the ambari-agent cache is not encrypted

2016-09-07 Thread Anita Gnanamalar Jebaraj (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anita Gnanamalar Jebaraj updated AMBARI-18334:
--
Assignee: Anita Gnanamalar Jebaraj
  Status: Patch Available  (was: Open)

> Password in the configurations.json file in the ambari-agent cache is not 
> encrypted
> ---
>
> Key: AMBARI-18334
> URL: https://issues.apache.org/jira/browse/AMBARI-18334
> Project: Ambari
>  Issue Type: Bug
>Reporter: Anita Gnanamalar Jebaraj
>Assignee: Anita Gnanamalar Jebaraj
> Attachments: AMBARI-18334.patch
>
>
> The  configurations.json  file loaded in the ambari-agent cache located at  
> /var/lib/ambari-agent/cache/cluster_configuration contains password details 
> in plaintext (Ex: ssl.client.keystore.password,ssl.client.truststore.password 
> etc.). The values are loaded both in the memory cache and file cache, the 
> file seems to be used only for debugging purposes, so it would be a better 
> approach to mask the passwords in the file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (AMBARI-18334) Password in the configurations.json file in the ambari-agent cache is not encrypted

2016-09-07 Thread Anita Gnanamalar Jebaraj (JIRA)
Anita Gnanamalar Jebaraj created AMBARI-18334:
-

 Summary: Password in the configurations.json file in the 
ambari-agent cache is not encrypted
 Key: AMBARI-18334
 URL: https://issues.apache.org/jira/browse/AMBARI-18334
 Project: Ambari
  Issue Type: Bug
Reporter: Anita Gnanamalar Jebaraj


The  configurations.json  file loaded in the ambari-agent cache located at  
/var/lib/ambari-agent/cache/cluster_configuration contains password details in 
plaintext (Ex: ssl.client.keystore.password,ssl.client.truststore.password 
etc.). The values are loaded both in the memory cache and file cache, the file 
seems to be used only for debugging purposes, so it would be a better approach 
to mask the passwords in the file.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18333) While checking for component dependency code looks for incorrect component name

2016-09-07 Thread Amruta Borkar (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amruta Borkar updated AMBARI-18333:
---
Status: Patch Available  (was: In Progress)

> While checking for component dependency code looks for incorrect component 
> name
> ---
>
> Key: AMBARI-18333
> URL: https://issues.apache.org/jira/browse/AMBARI-18333
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-18333.patch
>
>
> While validating host groups in blueprint for component dependency, code 
> should check if a dependency component is present in the host group component 
> list rather than the component on whose dependency list it is iterating.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18333) While checking for component dependency code looks for incorrect component name

2016-09-07 Thread Amruta Borkar (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amruta Borkar updated AMBARI-18333:
---
Attachment: AMBARI-18333.patch

> While checking for component dependency code looks for incorrect component 
> name
> ---
>
> Key: AMBARI-18333
> URL: https://issues.apache.org/jira/browse/AMBARI-18333
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-18333.patch
>
>
> While validating host groups in blueprint for component dependency, code 
> should check if a dependency component is present in the host group component 
> list rather than the component on whose dependency list it is iterating.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18331) JMX metric retrieval method may unnecessarily refresh metrics at a high rate

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471272#comment-15471272
 ] 

Hadoop QA commented on AMBARI-18331:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827401/AMBARI-18331.patch
  against trunk revision .

{color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8599//console

This message is automatically generated.

> JMX metric retrieval method may unnecessarily refresh metrics at a high rate
> 
>
> Key: AMBARI-18331
> URL: https://issues.apache.org/jira/browse/AMBARI-18331
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
> Fix For: trunk
>
> Attachments: AMBARI-18331.patch
>
>
> In AMBARI-16913 we revised the JMX retrieval method to maintain an internal 
> state of JMX metrics, with the retrieval taking place out of band of the 
> actual jetty query requiring the metric.  However, each query will still 
> generate a refresh request to the metric, regardless of it's current state.
> Recommend setting a TTL on a given metric such as 5 seconds, and only 
> generate a new request for the metric if a TTL has expired, to avoid large 
> amounts of repeat metrics collections in short windows.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (AMBARI-18333) While checking for component dependency code looks for incorrect component name

2016-09-07 Thread Amruta Borkar (JIRA)
Amruta Borkar created AMBARI-18333:
--

 Summary: While checking for component dependency code looks for 
incorrect component name
 Key: AMBARI-18333
 URL: https://issues.apache.org/jira/browse/AMBARI-18333
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: trunk
Reporter: Amruta Borkar
Assignee: Amruta Borkar
 Fix For: trunk


While validating host groups in blueprint for component dependency, code should 
check if a dependency component is present in the host group component list 
rather than the component on whose dependency list it is iterating.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18331) JMX metric retrieval method may unnecessarily refresh metrics at a high rate

2016-09-07 Thread Jonathan Hurley (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Hurley updated AMBARI-18331:
-
Attachment: AMBARI-18331.patch

> JMX metric retrieval method may unnecessarily refresh metrics at a high rate
> 
>
> Key: AMBARI-18331
> URL: https://issues.apache.org/jira/browse/AMBARI-18331
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
> Fix For: trunk
>
> Attachments: AMBARI-18331.patch
>
>
> In AMBARI-16913 we revised the JMX retrieval method to maintain an internal 
> state of JMX metrics, with the retrieval taking place out of band of the 
> actual jetty query requiring the metric.  However, each query will still 
> generate a refresh request to the metric, regardless of it's current state.
> Recommend setting a TTL on a given metric such as 5 seconds, and only 
> generate a new request for the metric if a TTL has expired, to avoid large 
> amounts of repeat metrics collections in short windows.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18331) JMX metric retrieval method may unnecessarily refresh metrics at a high rate

2016-09-07 Thread Jonathan Hurley (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Hurley updated AMBARI-18331:
-
Attachment: (was: AMBARI-18331.patch)

> JMX metric retrieval method may unnecessarily refresh metrics at a high rate
> 
>
> Key: AMBARI-18331
> URL: https://issues.apache.org/jira/browse/AMBARI-18331
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
> Fix For: trunk
>
>
> In AMBARI-16913 we revised the JMX retrieval method to maintain an internal 
> state of JMX metrics, with the retrieval taking place out of band of the 
> actual jetty query requiring the metric.  However, each query will still 
> generate a refresh request to the metric, regardless of it's current state.
> Recommend setting a TTL on a given metric such as 5 seconds, and only 
> generate a new request for the metric if a TTL has expired, to avoid large 
> amounts of repeat metrics collections in short windows.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18331) JMX metric retrieval method may unnecessarily refresh metrics at a high rate

2016-09-07 Thread Jonathan Hurley (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Hurley updated AMBARI-18331:
-
Status: Open  (was: Patch Available)

> JMX metric retrieval method may unnecessarily refresh metrics at a high rate
> 
>
> Key: AMBARI-18331
> URL: https://issues.apache.org/jira/browse/AMBARI-18331
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
> Fix For: trunk
>
>
> In AMBARI-16913 we revised the JMX retrieval method to maintain an internal 
> state of JMX metrics, with the retrieval taking place out of band of the 
> actual jetty query requiring the metric.  However, each query will still 
> generate a refresh request to the metric, regardless of it's current state.
> Recommend setting a TTL on a given metric such as 5 seconds, and only 
> generate a new request for the metric if a TTL has expired, to avoid large 
> amounts of repeat metrics collections in short windows.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18331) JMX metric retrieval method may unnecessarily refresh metrics at a high rate

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471174#comment-15471174
 ] 

Hadoop QA commented on AMBARI-18331:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827366/AMBARI-18331.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 1 new 
or modified test files.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 core tests{color}.  The patch failed these unit tests in 
ambari-server:

  
org.apache.ambari.server.controller.metrics.JMXPropertyProviderTest
  
org.apache.ambari.server.controller.metrics.RestMetricsPropertyProviderTest

Test results: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8598//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8598//console

This message is automatically generated.

> JMX metric retrieval method may unnecessarily refresh metrics at a high rate
> 
>
> Key: AMBARI-18331
> URL: https://issues.apache.org/jira/browse/AMBARI-18331
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
> Fix For: trunk
>
> Attachments: AMBARI-18331.patch
>
>
> In AMBARI-16913 we revised the JMX retrieval method to maintain an internal 
> state of JMX metrics, with the retrieval taking place out of band of the 
> actual jetty query requiring the metric.  However, each query will still 
> generate a refresh request to the metric, regardless of it's current state.
> Recommend setting a TTL on a given metric such as 5 seconds, and only 
> generate a new request for the metric if a TTL has expired, to avoid large 
> amounts of repeat metrics collections in short windows.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-17891) Provide stack-advisor support for Microsoft-R service

2016-09-07 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-17891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471146#comment-15471146
 ] 

Hudson commented on AMBARI-17891:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5631 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5631/])
AMBARI-17891. Provide stack-advisor support for Microsoft-R service. (stoader: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=60d96b15587642b561efc95c6c73277c5e90d534])
* (edit) 
contrib/management-packs/microsoft-r_mpack/src/main/resources/common-services/MICROSOFT_R/8.0.0/service_advisor.py


> Provide stack-advisor support for Microsoft-R service
> -
>
> Key: AMBARI-17891
> URL: https://issues.apache.org/jira/browse/AMBARI-17891
> Project: Ambari
>  Issue Type: Bug
>  Components: contrib
>Affects Versions: 2.4.0
>Reporter: Srimanth Gunturi
>Assignee: Doroszlai, Attila
> Fix For: 2.5.0
>
> Attachments: AMBARI-17891.patch, AMBARI-17891.patch
>
>
> Microsoft-R service should have stack-advisor ability to recommend component 
> layout for the client component which should be installed on hosts which have:
> * NodeManagers
> * Client nodes
> The script should also validate that the client component is on these hosts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18321) atlas hook for hive and storm fail to push metadeta

2016-09-07 Thread Dmitry Lysnichenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Lysnichenko updated AMBARI-18321:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed
To https://git-wip-us.apache.org/repos/asf/ambari.git
   60d96b1..6e60b46  trunk -> trunk

> atlas hook for hive and storm fail to push metadeta
> ---
>
> Key: AMBARI-18321
> URL: https://issues.apache.org/jira/browse/AMBARI-18321
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Dmytro Grinenko
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-18321.patch, AMBARI-18321.patch.1
>
>
> 1] On the upgraded cluster we added Atlas service 
> 2] On submitting the storm topology,atlas hook fails to send metadata. 
> Attached logs [ storm_atlas.log] where connect to kafka is failing.
> 3] Hive hook is also failing with the same error as below
> {code}
> Caused by: javax.security.auth.login.LoginException: Could not login: the 
> client is being asked for a password, but the Kafka client code does not 
> currently support obtaining a password from the user. not available to garner 
>  authentication information from the user
> at 
> com.sun.security.auth.module.Krb5LoginModule.promptForPass(Krb5LoginModule.java:940)
> at 
> com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:760)
> at 
> com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
> at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
> at 
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at 
> org.apache.kafka.common.security.authenticator.AbstractLogin.login(AbstractLogin.java:69)
> at 
> org.apache.kafka.common.security.kerberos.KerberosLogin.login(KerberosLogin.java:110)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.(LoginManager.java:46)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.acquireLoginManager(LoginManager.java:68)
> at 
> org.apache.kafka.common.network.SaslChannelBuilder.configure(SaslChannelBuilder.java:78)
> ... 18 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (AMBARI-18321) atlas hook for hive and storm fail to push metadeta

2016-09-07 Thread Dmitry Lysnichenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Lysnichenko reassigned AMBARI-18321:
---

Assignee: Dmitry Lysnichenko

> atlas hook for hive and storm fail to push metadeta
> ---
>
> Key: AMBARI-18321
> URL: https://issues.apache.org/jira/browse/AMBARI-18321
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Dmytro Grinenko
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-18321.patch, AMBARI-18321.patch.1
>
>
> 1] On the upgraded cluster we added Atlas service 
> 2] On submitting the storm topology,atlas hook fails to send metadata. 
> Attached logs [ storm_atlas.log] where connect to kafka is failing.
> 3] Hive hook is also failing with the same error as below
> {code}
> Caused by: javax.security.auth.login.LoginException: Could not login: the 
> client is being asked for a password, but the Kafka client code does not 
> currently support obtaining a password from the user. not available to garner 
>  authentication information from the user
> at 
> com.sun.security.auth.module.Krb5LoginModule.promptForPass(Krb5LoginModule.java:940)
> at 
> com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:760)
> at 
> com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
> at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
> at 
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at 
> org.apache.kafka.common.security.authenticator.AbstractLogin.login(AbstractLogin.java:69)
> at 
> org.apache.kafka.common.security.kerberos.KerberosLogin.login(KerberosLogin.java:110)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.(LoginManager.java:46)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.acquireLoginManager(LoginManager.java:68)
> at 
> org.apache.kafka.common.network.SaslChannelBuilder.configure(SaslChannelBuilder.java:78)
> ... 18 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (AMBARI-18332) Blueprints: API should make available "setting" property from blueprint

2016-09-07 Thread Nahappan Somasundaram (JIRA)
Nahappan Somasundaram created AMBARI-18332:
--

 Summary: Blueprints: API should make available "setting" property 
from blueprint
 Key: AMBARI-18332
 URL: https://issues.apache.org/jira/browse/AMBARI-18332
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.4.0
Reporter: Nahappan Somasundaram
Assignee: Nahappan Somasundaram
 Fix For: 2.5.0


The following APIs do not retrieve *setting* section from the blueprint that 
was used during deployment:

{code}
http://:/api/v1/blueprints/ 
http://:/api/v1/clusters/?format=blueprint 
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18321) atlas hook for hive and storm fail to push metadeta

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470919#comment-15470919
 ] 

Hadoop QA commented on AMBARI-18321:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827391/AMBARI-18321.patch.1
  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:red}-1 javac{color:red}.  The patch appears to cause the build to 
fail.

Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8597//console

This message is automatically generated.

> atlas hook for hive and storm fail to push metadeta
> ---
>
> Key: AMBARI-18321
> URL: https://issues.apache.org/jira/browse/AMBARI-18321
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-18321.patch, AMBARI-18321.patch.1
>
>
> 1] On the upgraded cluster we added Atlas service 
> 2] On submitting the storm topology,atlas hook fails to send metadata. 
> Attached logs [ storm_atlas.log] where connect to kafka is failing.
> 3] Hive hook is also failing with the same error as below
> {code}
> Caused by: javax.security.auth.login.LoginException: Could not login: the 
> client is being asked for a password, but the Kafka client code does not 
> currently support obtaining a password from the user. not available to garner 
>  authentication information from the user
> at 
> com.sun.security.auth.module.Krb5LoginModule.promptForPass(Krb5LoginModule.java:940)
> at 
> com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:760)
> at 
> com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
> at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
> at 
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at 
> org.apache.kafka.common.security.authenticator.AbstractLogin.login(AbstractLogin.java:69)
> at 
> org.apache.kafka.common.security.kerberos.KerberosLogin.login(KerberosLogin.java:110)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.(LoginManager.java:46)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.acquireLoginManager(LoginManager.java:68)
> at 
> org.apache.kafka.common.network.SaslChannelBuilder.configure(SaslChannelBuilder.java:78)
> ... 18 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18321) atlas hook for hive and storm fail to push metadeta

2016-09-07 Thread Dmytro Grinenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-18321:
-
Attachment: AMBARI-18321.patch.1

> atlas hook for hive and storm fail to push metadeta
> ---
>
> Key: AMBARI-18321
> URL: https://issues.apache.org/jira/browse/AMBARI-18321
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-18321.patch, AMBARI-18321.patch.1
>
>
> 1] On the upgraded cluster we added Atlas service 
> 2] On submitting the storm topology,atlas hook fails to send metadata. 
> Attached logs [ storm_atlas.log] where connect to kafka is failing.
> 3] Hive hook is also failing with the same error as below
> {code}
> Caused by: javax.security.auth.login.LoginException: Could not login: the 
> client is being asked for a password, but the Kafka client code does not 
> currently support obtaining a password from the user. not available to garner 
>  authentication information from the user
> at 
> com.sun.security.auth.module.Krb5LoginModule.promptForPass(Krb5LoginModule.java:940)
> at 
> com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:760)
> at 
> com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
> at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
> at 
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at 
> org.apache.kafka.common.security.authenticator.AbstractLogin.login(AbstractLogin.java:69)
> at 
> org.apache.kafka.common.security.kerberos.KerberosLogin.login(KerberosLogin.java:110)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.(LoginManager.java:46)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.acquireLoginManager(LoginManager.java:68)
> at 
> org.apache.kafka.common.network.SaslChannelBuilder.configure(SaslChannelBuilder.java:78)
> ... 18 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18330) Add optional digital clock widget attached to page.

2016-09-07 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470894#comment-15470894
 ] 

Hudson commented on AMBARI-18330:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5630 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5630/])
AMBARI-18330. Add optional digital clock widget attached to page. (hiveww: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=56a6ff82304dd0267b4b901fdd53fed7ee4ccc85])
* (edit) ambari-web/app/styles/application.less
* (edit) ambari-web/app/templates/application.hbs
* (add) ambari-web/app/views/common/clock_view.js
* (edit) ambari-web/app/config.js
* (edit) ambari-web/app/views.js


> Add optional digital clock widget attached to page.
> ---
>
> Key: AMBARI-18330
> URL: https://issues.apache.org/jira/browse/AMBARI-18330
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: trunk
>
> Attachments: AMBARI-18330.patch
>
>
> Add optional digital clock widget attached to page.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18302) Desired state of client component should not be changed in case configuration changes are applied through a "Restart"

2016-09-07 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470893#comment-15470893
 ] 

Hudson commented on AMBARI-18302:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5630 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5630/])
AMBARI-18302.Desired state of client component should not be changed in 
(stoader: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=6d13be5b9ab6aa129bc1a71fc2eb57ccf7bbe6cd])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java


> Desired state of client component should not be changed in case configuration 
> changes are applied through a "Restart"
> -
>
> Key: AMBARI-18302
> URL: https://issues.apache.org/jira/browse/AMBARI-18302
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Laszlo Puskas
>Assignee: Laszlo Puskas
> Fix For: trunk
>
> Attachments: AMBARI-18302.trunk.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Configuration changes are propagated to host components by issuing a restart 
> of the affected components.
> In case of master components this action will start the affected components 
> (regardless it is in INSTALLED or STARTED state) and the desired state will 
> be set to STARTED.
> In Ambari client components are always expected to be in INSTALLED state. 
> However upon configuration changes, the desired state of these components are 
> also set to STARTED. This may be misleading for ambari API users that 
> determine component states by checking the desired state and actual state. 
> (The actual state in case of client components will always be INSTALLED)
> This issue addresses this problem by not updating the desired state when 
> client components are restarted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18321) atlas hook for hive and storm fail to push metadeta

2016-09-07 Thread Dmytro Grinenko (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470892#comment-15470892
 ] 

Dmytro Grinenko commented on AMBARI-18321:
--

Test passed:

{code}
[15:14:59][Step 2/2] [INFO] Reactor Summary:
[15:14:59][Step 2/2] [INFO] 
[15:14:59][Step 2/2] [INFO] Ambari Views .. 
SUCCESS [4.102s]
[15:14:59][Step 2/2] [INFO] Ambari Metrics Common . 
SUCCESS [1.252s]
[15:14:59][Step 2/2] [INFO] Ambari Server . 
SUCCESS [1:16.952s]
[15:14:59][Step 2/2] [INFO] 

[15:14:59][Step 2/2] [INFO] BUILD SUCCESS
[15:14:59][Step 2/2] [INFO] 

[15:14:59][Step 2/2] [INFO] Total time: 1:23.065s
[15:14:59][Step 2/2] [INFO] Finished at: Wed Sep 07 15:14:59 UTC 2016
[15:14:59][Step 2/2] [INFO] Final Memory: 78M/1520M
[15:14:59][Step 2/2] [INFO] 

{code}

> atlas hook for hive and storm fail to push metadeta
> ---
>
> Key: AMBARI-18321
> URL: https://issues.apache.org/jira/browse/AMBARI-18321
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-18321.patch, AMBARI-18321.patch.1
>
>
> 1] On the upgraded cluster we added Atlas service 
> 2] On submitting the storm topology,atlas hook fails to send metadata. 
> Attached logs [ storm_atlas.log] where connect to kafka is failing.
> 3] Hive hook is also failing with the same error as below
> {code}
> Caused by: javax.security.auth.login.LoginException: Could not login: the 
> client is being asked for a password, but the Kafka client code does not 
> currently support obtaining a password from the user. not available to garner 
>  authentication information from the user
> at 
> com.sun.security.auth.module.Krb5LoginModule.promptForPass(Krb5LoginModule.java:940)
> at 
> com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:760)
> at 
> com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
> at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
> at 
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at 
> org.apache.kafka.common.security.authenticator.AbstractLogin.login(AbstractLogin.java:69)
> at 
> org.apache.kafka.common.security.kerberos.KerberosLogin.login(KerberosLogin.java:110)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.(LoginManager.java:46)
> at 
> org.apache.kafka.common.security.authenticator.LoginManager.acquireLoginManager(LoginManager.java:68)
> at 
> org.apache.kafka.common.network.SaslChannelBuilder.configure(SaslChannelBuilder.java:78)
> ... 18 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-17891) Provide stack-advisor support for Microsoft-R service

2016-09-07 Thread Doroszlai, Attila (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-17891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Doroszlai, Attila updated AMBARI-17891:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Provide stack-advisor support for Microsoft-R service
> -
>
> Key: AMBARI-17891
> URL: https://issues.apache.org/jira/browse/AMBARI-17891
> Project: Ambari
>  Issue Type: Bug
>  Components: contrib
>Affects Versions: 2.4.0
>Reporter: Srimanth Gunturi
>Assignee: Doroszlai, Attila
> Fix For: 2.5.0
>
> Attachments: AMBARI-17891.patch, AMBARI-17891.patch
>
>
> Microsoft-R service should have stack-advisor ability to recommend component 
> layout for the client component which should be installed on hosts which have:
> * NodeManagers
> * Client nodes
> The script should also validate that the client component is on these hosts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-17891) Provide stack-advisor support for Microsoft-R service

2016-09-07 Thread Doroszlai, Attila (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-17891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470828#comment-15470828
 ] 

Doroszlai, Attila commented on AMBARI-17891:


Review: https://reviews.apache.org/r/51575/

Commited to trunk:

commit b6f27dbd3b568f5dbdf9e602657aac693e29120c
Author: Attila Doroszlai 
Date:   Wed Sep 7 16:44:21 2016 +0200

AMBARI-17891. Provide stack-advisor support for Microsoft-R service. 
(Attila Doroszlai via stoader)


> Provide stack-advisor support for Microsoft-R service
> -
>
> Key: AMBARI-17891
> URL: https://issues.apache.org/jira/browse/AMBARI-17891
> Project: Ambari
>  Issue Type: Bug
>  Components: contrib
>Affects Versions: 2.4.0
>Reporter: Srimanth Gunturi
>Assignee: Doroszlai, Attila
> Fix For: 2.5.0
>
> Attachments: AMBARI-17891.patch, AMBARI-17891.patch
>
>
> Microsoft-R service should have stack-advisor ability to recommend component 
> layout for the client component which should be installed on hosts which have:
> * NodeManagers
> * Client nodes
> The script should also validate that the client component is on these hosts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18330) Add optional digital clock widget attached to page.

2016-09-07 Thread Antonenko Alexander (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonenko Alexander updated AMBARI-18330:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

committed to trunk


> Add optional digital clock widget attached to page.
> ---
>
> Key: AMBARI-18330
> URL: https://issues.apache.org/jira/browse/AMBARI-18330
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: trunk
>
> Attachments: AMBARI-18330.patch
>
>
> Add optional digital clock widget attached to page.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18278) Provide Notes On Service Config Changes During Ambari Upgrade

2016-09-07 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470628#comment-15470628
 ] 

Hudson commented on AMBARI-18278:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5629 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5629/])
AMBARI-18278. Provide Notes On Service Config Changes During Ambari 
(dlysnichenko: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=8755bf91e2a728132262669b50713388cf08b8db])
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog210Test.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/upgrade/AbstractUpgradeCatalog.java


> Provide Notes On Service Config Changes During Ambari Upgrade
> -
>
> Key: AMBARI-18278
> URL: https://issues.apache.org/jira/browse/AMBARI-18278
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 3.0.0
>
> Attachments: AMBARI-18278.2.patch, AMBARI-18278.patch
>
>
> For every configuration change made, a meaningful note should be included so 
> that administrators understand why so many versions are being created. Any of 
> the following would be fine:
> - Ambari Upgrade updated storm-site
> - Ambari Upgrade from 2.2.0 to 2.4.0 changed storm-site
> - The following configurations were changed as part of the Ambar Server 
> Upgrade: storm-site



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18326) Add custom jdbc path to ambari-server classpath

2016-09-07 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470629#comment-15470629
 ] 

Hudson commented on AMBARI-18326:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5629 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5629/])
AMBARI-18326. Add custom jdbc path to ambari-server (vbrodetskyi: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=3461a5c7c53115e95afc48f5ef963a3c51caaa69])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/orm/DBAccessorImpl.java
* (edit) ambari-server/src/main/python/ambari_server/dbConfiguration_linux.py


> Add custom jdbc path to ambari-server classpath
> ---
>
> Key: AMBARI-18326
> URL: https://issues.apache.org/jira/browse/AMBARI-18326
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-18326.patch
>
>
> We need to add custom jdbc path to ambari-server classpath



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18302) Desired state of client component should not be changed in case configuration changes are applied through a "Restart"

2016-09-07 Thread Laszlo Puskas (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470616#comment-15470616
 ] 

Laszlo Puskas commented on AMBARI-18302:


commit 6d13be5b9ab6aa129bc1a71fc2eb57ccf7bbe6cd
Author: Toader, Sebastian 
Date:   Wed Sep 7 15:18:25 2016 +0200

> Desired state of client component should not be changed in case configuration 
> changes are applied through a "Restart"
> -
>
> Key: AMBARI-18302
> URL: https://issues.apache.org/jira/browse/AMBARI-18302
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Laszlo Puskas
>Assignee: Laszlo Puskas
> Fix For: trunk
>
> Attachments: AMBARI-18302.trunk.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Configuration changes are propagated to host components by issuing a restart 
> of the affected components.
> In case of master components this action will start the affected components 
> (regardless it is in INSTALLED or STARTED state) and the desired state will 
> be set to STARTED.
> In Ambari client components are always expected to be in INSTALLED state. 
> However upon configuration changes, the desired state of these components are 
> also set to STARTED. This may be misleading for ambari API users that 
> determine component states by checking the desired state and actual state. 
> (The actual state in case of client components will always be INSTALLED)
> This issue addresses this problem by not updating the desired state when 
> client components are restarted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18302) Desired state of client component should not be changed in case configuration changes are applied through a "Restart"

2016-09-07 Thread Laszlo Puskas (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Laszlo Puskas updated AMBARI-18302:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Desired state of client component should not be changed in case configuration 
> changes are applied through a "Restart"
> -
>
> Key: AMBARI-18302
> URL: https://issues.apache.org/jira/browse/AMBARI-18302
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Laszlo Puskas
>Assignee: Laszlo Puskas
> Fix For: trunk
>
> Attachments: AMBARI-18302.trunk.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Configuration changes are propagated to host components by issuing a restart 
> of the affected components.
> In case of master components this action will start the affected components 
> (regardless it is in INSTALLED or STARTED state) and the desired state will 
> be set to STARTED.
> In Ambari client components are always expected to be in INSTALLED state. 
> However upon configuration changes, the desired state of these components are 
> also set to STARTED. This may be misleading for ambari API users that 
> determine component states by checking the desired state and actual state. 
> (The actual state in case of client components will always be INSTALLED)
> This issue addresses this problem by not updating the desired state when 
> client components are restarted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18331) JMX metric retrieval method may unnecessarily refresh metrics at a high rate

2016-09-07 Thread Jonathan Hurley (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Hurley updated AMBARI-18331:
-
Attachment: AMBARI-18331.patch

> JMX metric retrieval method may unnecessarily refresh metrics at a high rate
> 
>
> Key: AMBARI-18331
> URL: https://issues.apache.org/jira/browse/AMBARI-18331
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
> Fix For: trunk
>
> Attachments: AMBARI-18331.patch
>
>
> In AMBARI-16913 we revised the JMX retrieval method to maintain an internal 
> state of JMX metrics, with the retrieval taking place out of band of the 
> actual jetty query requiring the metric.  However, each query will still 
> generate a refresh request to the metric, regardless of it's current state.
> Recommend setting a TTL on a given metric such as 5 seconds, and only 
> generate a new request for the metric if a TTL has expired, to avoid large 
> amounts of repeat metrics collections in short windows.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18331) JMX metric retrieval method may unnecessarily refresh metrics at a high rate

2016-09-07 Thread Jonathan Hurley (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Hurley updated AMBARI-18331:
-
Status: Patch Available  (was: Open)

> JMX metric retrieval method may unnecessarily refresh metrics at a high rate
> 
>
> Key: AMBARI-18331
> URL: https://issues.apache.org/jira/browse/AMBARI-18331
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
> Fix For: trunk
>
> Attachments: AMBARI-18331.patch
>
>
> In AMBARI-16913 we revised the JMX retrieval method to maintain an internal 
> state of JMX metrics, with the retrieval taking place out of band of the 
> actual jetty query requiring the metric.  However, each query will still 
> generate a refresh request to the metric, regardless of it's current state.
> Recommend setting a TTL on a given metric such as 5 seconds, and only 
> generate a new request for the metric if a TTL has expired, to avoid large 
> amounts of repeat metrics collections in short windows.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (AMBARI-18331) JMX metric retrieval method may unnecessarily refresh metrics at a high rate

2016-09-07 Thread Jonathan Hurley (JIRA)
Jonathan Hurley created AMBARI-18331:


 Summary: JMX metric retrieval method may unnecessarily refresh 
metrics at a high rate
 Key: AMBARI-18331
 URL: https://issues.apache.org/jira/browse/AMBARI-18331
 Project: Ambari
  Issue Type: Task
  Components: ambari-server
Affects Versions: 2.4.0
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
 Fix For: trunk


In AMBARI-16913 we revised the JMX retrieval method to maintain an internal 
state of JMX metrics, with the retrieval taking place out of band of the actual 
jetty query requiring the metric.  However, each query will still generate a 
refresh request to the metric, regardless of it's current state.

Recommend setting a TTL on a given metric such as 5 seconds, and only generate 
a new request for the metric if a TTL has expired, to avoid large amounts of 
repeat metrics collections in short windows.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18324) Externalize skip repo url check to ambari.properties instead of hardcoding it in Ambari Java code

2016-09-07 Thread Di Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Di Li updated AMBARI-18324:
---
Status: Open  (was: Patch Available)

> Externalize skip repo url check to ambari.properties instead of hardcoding it 
> in Ambari Java code
> -
>
> Key: AMBARI-18324
> URL: https://issues.apache.org/jira/browse/AMBARI-18324
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-trunk
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
> Fix For: trunk
>
> Attachments: AMBARI-18324.patch
>
>
> Externalize skip repo url check to ambari.properties instead of hardcoding it 
> in Ambari Java code, so that users can define what repo ids to skip repo urls 
> validation when adding repos for the given stack



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18324) Externalize skip repo url check to ambari.properties instead of hardcoding it in Ambari Java code

2016-09-07 Thread Di Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Di Li updated AMBARI-18324:
---
Status: Patch Available  (was: Open)

> Externalize skip repo url check to ambari.properties instead of hardcoding it 
> in Ambari Java code
> -
>
> Key: AMBARI-18324
> URL: https://issues.apache.org/jira/browse/AMBARI-18324
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-trunk
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
> Fix For: trunk
>
> Attachments: AMBARI-18324.patch
>
>
> Externalize skip repo url check to ambari.properties instead of hardcoding it 
> in Ambari Java code, so that users can define what repo ids to skip repo urls 
> validation when adding repos for the given stack



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18330) Add optional digital clock widget attached to page.

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470388#comment-15470388
 ] 

Hadoop QA commented on AMBARI-18330:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827346/AMBARI-18330.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-web.

Test results: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8596//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8596//console

This message is automatically generated.

> Add optional digital clock widget attached to page.
> ---
>
> Key: AMBARI-18330
> URL: https://issues.apache.org/jira/browse/AMBARI-18330
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: trunk
>
> Attachments: AMBARI-18330.patch
>
>
> Add optional digital clock widget attached to page.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18326) Add custom jdbc path to ambari-server classpath

2016-09-07 Thread Vitaly Brodetskyi (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitaly Brodetskyi updated AMBARI-18326:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to trunk

> Add custom jdbc path to ambari-server classpath
> ---
>
> Key: AMBARI-18326
> URL: https://issues.apache.org/jira/browse/AMBARI-18326
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-18326.patch
>
>
> We need to add custom jdbc path to ambari-server classpath



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18326) Add custom jdbc path to ambari-server classpath

2016-09-07 Thread Vitaly Brodetskyi (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitaly Brodetskyi updated AMBARI-18326:
---
Fix Version/s: trunk

> Add custom jdbc path to ambari-server classpath
> ---
>
> Key: AMBARI-18326
> URL: https://issues.apache.org/jira/browse/AMBARI-18326
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-18326.patch
>
>
> We need to add custom jdbc path to ambari-server classpath



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18330) Add optional digital clock widget attached to page.

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470342#comment-15470342
 ] 

Hadoop QA commented on AMBARI-18330:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827346/AMBARI-18330.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-web.

Test results: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8595//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8595//console

This message is automatically generated.

> Add optional digital clock widget attached to page.
> ---
>
> Key: AMBARI-18330
> URL: https://issues.apache.org/jira/browse/AMBARI-18330
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: trunk
>
> Attachments: AMBARI-18330.patch
>
>
> Add optional digital clock widget attached to page.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18278) Provide Notes On Service Config Changes During Ambari Upgrade

2016-09-07 Thread Dmitry Lysnichenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Lysnichenko updated AMBARI-18278:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed
To https://git-wip-us.apache.org/repos/asf/ambari.git
   485d735..8755bf9  trunk -> trunk


> Provide Notes On Service Config Changes During Ambari Upgrade
> -
>
> Key: AMBARI-18278
> URL: https://issues.apache.org/jira/browse/AMBARI-18278
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 3.0.0
>
> Attachments: AMBARI-18278.2.patch, AMBARI-18278.patch
>
>
> For every configuration change made, a meaningful note should be included so 
> that administrators understand why so many versions are being created. Any of 
> the following would be fine:
> - Ambari Upgrade updated storm-site
> - Ambari Upgrade from 2.2.0 to 2.4.0 changed storm-site
> - The following configurations were changed as part of the Ambar Server 
> Upgrade: storm-site



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18327) multiple clicks on "Next" button of Step-4 (Choose Services) causes skipping of steps while installing a cluster

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470270#comment-15470270
 ] 

Hadoop QA commented on AMBARI-18327:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827255/AMBARI-18327.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-web.

Test results: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8594//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8594//console

This message is automatically generated.

> multiple clicks on "Next" button of Step-4 (Choose Services) causes skipping 
> of steps while installing a cluster
> 
>
> Key: AMBARI-18327
> URL: https://issues.apache.org/jira/browse/AMBARI-18327
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
>Priority: Minor
> Attachments: AMBARI-18327.patch
>
>
> While installing a cluster if the Ambari user happened to click the "Next" 
> button of Step-4 (Choose Services step) more than once, then it could lead to 
> skipping directly to step-6 or 7 or 8 depending on the number of times the 
> click got registered. This behavior is reproducible only when the host is 
> slow, which would allow enough time to click the Next button multiple times.
> This issue is related to AMBARI-14574, and is a revised fix for the Step-4.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18309) Add check to DB conistency checker for duplicate hostcomponentstate

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470242#comment-15470242
 ] 

Hadoop QA commented on AMBARI-18309:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827262/AMBARI-18309.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 1 new 
or modified test files.

{color: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 ambari-server 

Test results: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8593//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8593//console

This message is automatically generated.

> Add check to DB conistency checker for duplicate hostcomponentstate
> ---
>
> Key: AMBARI-18309
> URL: https://issues.apache.org/jira/browse/AMBARI-18309
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
> Fix For: 3.0.0
>
> Attachments: AMBARI-18309.patch
>
>
> Add db consistency check for hostcomponent tables, for each component we 
> should have only one state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18278) Provide Notes On Service Config Changes During Ambari Upgrade

2016-09-07 Thread Dmitry Lysnichenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Lysnichenko updated AMBARI-18278:

Attachment: AMBARI-18278.2.patch

> Provide Notes On Service Config Changes During Ambari Upgrade
> -
>
> Key: AMBARI-18278
> URL: https://issues.apache.org/jira/browse/AMBARI-18278
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 3.0.0
>
> Attachments: AMBARI-18278.2.patch, AMBARI-18278.patch
>
>
> For every configuration change made, a meaningful note should be included so 
> that administrators understand why so many versions are being created. Any of 
> the following would be fine:
> - Ambari Upgrade updated storm-site
> - Ambari Upgrade from 2.2.0 to 2.4.0 changed storm-site
> - The following configurations were changed as part of the Ambar Server 
> Upgrade: storm-site



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18330) Add optional digital clock widget attached to page.

2016-09-07 Thread Aleksandr Kovalenko (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470225#comment-15470225
 ] 

Aleksandr Kovalenko commented on AMBARI-18330:
--

+1 for the patch

> Add optional digital clock widget attached to page.
> ---
>
> Key: AMBARI-18330
> URL: https://issues.apache.org/jira/browse/AMBARI-18330
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: trunk
>
> Attachments: AMBARI-18330.patch
>
>
> Add optional digital clock widget attached to page.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18330) Add optional digital clock widget attached to page.

2016-09-07 Thread Antonenko Alexander (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonenko Alexander updated AMBARI-18330:
-
Status: Patch Available  (was: Open)

> Add optional digital clock widget attached to page.
> ---
>
> Key: AMBARI-18330
> URL: https://issues.apache.org/jira/browse/AMBARI-18330
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: trunk
>
> Attachments: AMBARI-18330.patch
>
>
> Add optional digital clock widget attached to page.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18330) Add optional digital clock widget attached to page.

2016-09-07 Thread Antonenko Alexander (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonenko Alexander updated AMBARI-18330:
-
Attachment: AMBARI-18330.patch

> Add optional digital clock widget attached to page.
> ---
>
> Key: AMBARI-18330
> URL: https://issues.apache.org/jira/browse/AMBARI-18330
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: trunk
>
> Attachments: AMBARI-18330.patch
>
>
> Add optional digital clock widget attached to page.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (AMBARI-18330) Add optional digital clock widget attached to page.

2016-09-07 Thread Antonenko Alexander (JIRA)
Antonenko Alexander created AMBARI-18330:


 Summary: Add optional digital clock widget attached to page.
 Key: AMBARI-18330
 URL: https://issues.apache.org/jira/browse/AMBARI-18330
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.5.0
Reporter: Antonenko Alexander
Assignee: Antonenko Alexander
 Fix For: trunk


Add optional digital clock widget attached to page.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18328) Blueprints: Log "setting" section of blueprint in ambari server log file

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470019#comment-15470019
 ] 

Hadoop QA commented on AMBARI-18328:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12827291/rb51685.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 core tests{color}.  The patch failed these unit tests in 
ambari-server:

  
org.apache.ambari.server.controller.internal.BlueprintResourceProviderTest

Test results: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8592//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8592//console

This message is automatically generated.

> Blueprints: Log "setting" section of blueprint in ambari server log file
> 
>
> Key: AMBARI-18328
> URL: https://issues.apache.org/jira/browse/AMBARI-18328
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: 2.5.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.5.0
>
> Attachments: rb51685.patch
>
>
> A new section "setting" was added to the blueprint JSON to support auto 
> restart of components. When deploying the blueprint, logging the setting 
> section will help debugging blueprint deployments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMBARI-18308) Ambari UI: Memory leak while adding and removing property

2016-09-07 Thread Santhosh B Gowda (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-18308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Santhosh B Gowda updated AMBARI-18308:
--
Fix Version/s: 2.4.1

> Ambari UI: Memory leak while adding and removing property
> -
>
> Key: AMBARI-18308
> URL: https://issues.apache.org/jira/browse/AMBARI-18308
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Santhosh B Gowda
>Priority: Critical
> Fix For: 2.4.1
>
>
> Go to any of the service config screen ( for e.x Hive ) and add and remove 
> multiple properties one after another (without using bulk add).
> This results in javascript memory leak.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-17225) Ambari Web UI stuck ON Repository Base URL validation when a local repository server is used and it's certificate is on the truststore that ambari is configured to us

2016-09-07 Thread Marcin Molak (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-17225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15469898#comment-15469898
 ] 

Marcin Molak commented on AMBARI-17225:
---

In Ambari 2.2 AmbariManagementControllerImpl.verifyRepository method doesn't 
provide trustore configuration (from ambari.properties). 
In Ambari 2.4 URLStreamProvider has additional method setupTruststoreForHttps 
which change HTTPS mode into HTTP mode. Then trustore settings are not verified.

> Ambari Web UI stuck ON Repository Base URL validation when a local repository 
> server is used and it's certificate is on the truststore that ambari is 
> configured to use
> ---
>
> Key: AMBARI-17225
> URL: https://issues.apache.org/jira/browse/AMBARI-17225
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
> Environment: REHL7
>Reporter: REYANE OUKPEDJO
>
> a local repository server is set up with ssl enabled and ambari is configured 
> to uses a truststore that has the local repository server certificate on it. 
> Yet ambari is throwing the following error during base url validation:
> 13 Jun 2016 16:31:11,974  WARN [qtp-ambari-client-23] ServletHandler:563 - 
> /api/v1/stacks/BigInsights/versions/4.2/operating_systems/redhat7/repositories/IOP-4.2
> java.lang.IllegalStateException: Can't get secure connection to 
> https://deployment.whac.local/repos/IOP/rhel/7/x86_64/4.2.0.0/beta/repodata/repomd.xml.
>   Truststore path or password is not set.
> at 
> org.apache.ambari.server.controller.internal.URLStreamProvider.getSSLConnection(URLStreamProvider.java:286)
> at 
> org.apache.ambari.server.controller.internal.URLStreamProvider.processURL(URLStreamProvider.java:173)
> at 
> org.apache.ambari.server.controller.internal.URLStreamProvider.processURL(URLStreamProvider.java:133)
> at 
> org.apache.ambari.server.controller.internal.URLStreamProvider.readFrom(URLStreamProvider.java:107)
> at 
> org.apache.ambari.server.controller.internal.URLStreamProvider.readFrom(URLStreamProvider.java:112)
> at 
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.verifyRepository(AmbariManagementControllerImpl.java:3701)
> at 
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateRepositories(AmbariManagementControllerImpl.java:3639)
> at 
> org.apache.ambari.server.controller.internal.RepositoryResourceProvider$4.invoke(RepositoryResourceProvider.java:120)
> at 
> org.apache.ambari.server.controller.internal.RepositoryResourceProvider$4.invoke(RepositoryResourceProvider.java:117)
> at 
> org.apache.ambari.server.controller.internal.AbstractResourceProvider.invokeWithRetry(AbstractResourceProvider.java:450)
> at 
> org.apache.ambari.server.controller.internal.AbstractResourceProvider.modifyResources(AbstractResourceProvider.java:331)
> at 
> org.apache.ambari.server.controller.internal.RepositoryResourceProvider.updateResources(RepositoryResourceProvider.java:117)
> at 
> org.apache.ambari.server.controller.internal.ClusterControllerImpl.updateResources(ClusterControllerImpl.java:310)
> at 
> org.apache.ambari.server.api.services.persistence.PersistenceManagerImpl.update(PersistenceManagerImpl.java:104)
> at 
> org.apache.ambari.server.api.handlers.UpdateHandler.persist(UpdateHandler.java:42)
> at 
> org.apache.ambari.server.api.handlers.BaseManagementHandler.handleRequest(BaseManagementHandler.java:72)
> at 
> org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:135)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:106)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:75)
> at 
> org.apache.ambari.server.api.services.RepositoryService.updateRepository(RepositoryService.java:145)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
> at 
> 

[jira] [Commented] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations

2016-09-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15469768#comment-15469768
 ] 

Hadoop QA commented on AMBARI-18071:


{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12827300/AMBARI-18071-Sep6.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 1 new 
or modified test files.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
contrib/views/utils.

Test results: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8591//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8591//console

This message is automatically generated.

> Ambari Files View needs to have ability to load security configurations
> ---
>
> Key: AMBARI-18071
> URL: https://issues.apache.org/jira/browse/AMBARI-18071
> Project: Ambari
>  Issue Type: Improvement
>  Components: contrib
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-18071-Sep6.patch, AMBARI-18071.patch, 
> NoKeyProvider.png
>
>
> When HDFS is configured with Encryption Zones, Files View to browser files 
> will give "No KeyProvider" error.
> Steps to reproduce this issue:
> 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can 
> follow the link 
> https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html
> I have used Hadoop's KMS (installed tar manually).
> 2. Create a Files View instance and provide a user/group the privilege to use 
> the instance.
> 3. Log into the Ambari console as the user with the Files View permission.
> 4. Open the Files View instance.
> 5. Go to the folder which is configured as an encrypted zone.
> 6. Try to open an existing file in this folder.
> 7. This throws an error - java.io.IOException: No KeyProvider is configured, 
> cannot access an encrypted file. 
> 8. When trying through the shell, opening this file works.
> This happens because Files View doesn't have enough configuration set to 
> browse secured zone. Files view doesn't even provide an option to add these 
> configurations.This is why we see errors "No KeyProvider is configured, 
> cannot access an encrypted file", to work around this, you could download 
> client configuration from HDFS service tab, and copy the core-site.xml and 
> hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. 
> After this, the user is able to open the file in the encrypted zone.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMBARI-18316) Ambari upgrade to Ambari 2.4.0 failed during DB upgrade due to incorrect TEZ view regex

2016-09-07 Thread DIPAYAN BHOWMICK (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-18316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15469743#comment-15469743
 ] 

DIPAYAN BHOWMICK commented on AMBARI-18316:
---

Checked into branch-2.5

> Ambari upgrade to Ambari 2.4.0 failed during DB upgrade due to incorrect TEZ 
> view regex
> ---
>
> Key: AMBARI-18316
> URL: https://issues.apache.org/jira/browse/AMBARI-18316
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: DIPAYAN BHOWMICK
>Assignee: DIPAYAN BHOWMICK
> Fix For: 2.4.1
>
> Attachments: AMBARI-18316.branch-2.4.patch
>
>
> Ambari upgrade to Ambari 2.4.0 failed during DB upgrade due to incorrect TEZ 
> view regular expression.  
> *Steps to Reproduce*
> # Install Ambari 2.2.0
> # Install cluster with TEZ
> # Change {{tez-site/tez.tez-ui.history-url.base}} from something like 
> {{http://c6501.ambari.apache.org:8080/#/main/views/TEZ/0.7.0.2.3.4.0-460/TEZ_CLUSTER_INSTANCE}}
>  to 
> {{http://c6501.ambari.apache.org:8080/#/main/views/TEZ/0.7.0.2.3.4.0-460/tezv1}}
>  
> ** Notice "TEZ_CLUSTER_INSTANCE" was changed to "tezv1"
> # Upgrade Ambari to 2.4.0.1
> # Execute {{ambari-server upgrade}}
> # See error
> {noformat}
> Using python /usr/bin/python 
> Upgrading ambari-server 
> Updating properties in ambari.properties ... 
> WARNING: Original file ambari-env.sh kept 
> Fixing database objects owner 
> Ambari Server configured for Embedded Postgres. Confirm you have made a 
> backup of the Ambari Server database [y/n] (y)? y 
> Upgrading database schema 
> Error output from schema upgrade command: 
> Exception in thread "main" org.apache.ambari.server.AmbariException: Cannot 
> prepare the new value for property: 'tez.tez-ui.history-url.base' using the 
> old value: 
> 'https://c6501.ambari.apache.org:8080/#/main/views/TEZ/0.7.0.2.3.4.0-460/tezv1;
>  
> at 
> org.apache.ambari.server.upgrade.SchemaUpgradeHelper.executeDMLUpdates(SchemaUpgradeHelper.java:237)
>  
> at 
> org.apache.ambari.server.upgrade.SchemaUpgradeHelper.main(SchemaUpgradeHelper.java:353)
>  
> Caused by: org.apache.ambari.server.AmbariException: Cannot prepare the new 
> value for property: 'tez.tez-ui.history-url.base' using the old value: 
> 'https://c6501.ambari.apache.org:8080/#/main/views/TEZ/0.7.0.2.3.4.0-460/tezv1;
>  
> at 
> org.apache.ambari.server.upgrade.AbstractUpgradeCatalog.getUpdatedTezHistoryUrlBase(AbstractUpgradeCatalog.java:951)
>  
> at 
> org.apache.ambari.server.upgrade.AbstractUpgradeCatalog.updateTezHistoryUrlBase(AbstractUpgradeCatalog.java:923)
>  
> at 
> org.apache.ambari.server.upgrade.AbstractUpgradeCatalog.upgradeData(AbstractUpgradeCatalog.java:900)
>  
> at 
> org.apache.ambari.server.upgrade.SchemaUpgradeHelper.executeDMLUpdates(SchemaUpgradeHelper.java:234)
>  
> ... 1 more 
> {noformat}
> *Cause*
> The cause for this error is in the regular expression below:
> {code:title=At or around 
> org/apache/ambari/server/upgrade/AbstractUpgradeCatalog.java:986}
> String pattern = "(.*\\/TEZ\\/)(.*)(\\/TEZ_CLUSTER_INSTANCE)";
> {code}
> This pattern assumes the URL will end with "TEZ_CLUSTER_INSTANCE", however 
> this may be changed by the user causing a failure when matching and yielding 
> an exception being thrown.
> *Workaround*
> If the Ambari server package has not yet been upgraded
> # Edit the {{tez-site/tez.tez-ui.history-url.base}} config to match the 
> pattern
> # Perform the upgrade
> # Edit the {{tez-site/tez.tez-ui.history-url.base}} config to fix the URL as 
> needed
> If the Ambari server package has been upgraded
> # If {{ambari-server upgrade}} has been executed and failed, restore the 
> database
> # Using some database access utility (example, Toad), edit the  
> {{config_data}} column of the {{clusterconfig}} table for the record that 
> represents the _desired_ version of the {{tez-site}} config to match the 
> pattern
> # Perform the upgrade
> # Edit the {{tez-site/tez.tez-ui.history-url.base}} config to fix the URL as 
> needed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


  1   2   >