[jira] [Comment Edited] (AMBARI-14236) HDFS and Yarn alerts in https mode when kerberos is disabled

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk edited comment on AMBARI-14236 at 7/12/16 6:52 AM:
---

[~tctruong] I think wire encryption for HDFS and YARN was enabled and when I 
tried to connect via curl to their jmx / ui via SSL of any version it failed. I 
could do that only via TLSv1. 

Connecting via Python gived this error:
{noformat}
_ssl.c:491: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol>
{noformat}

I think the proper fix might be to patch the library only in scope of 
ambari_alerts and not for ambari_agent.

[~rlevas] I remember you did some research on disabling TLSv1. Can you please 
chime in.


was (Author: aonishuk):
[~tctruong] I think wire encryption for HDFS and YARN was enabled and when I 
tried to connect via curl to their jmx / ui via SSL of any version it failed. I 
could do that only via TLSv1. 

Connecting via Python gived this error:
{noformat}
_ssl.c:491: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol>
{noformat}

[~rlevas] I remember you did some research on disabling TLSv1. Can you please 
chime in.

> HDFS and Yarn alerts in https mode when kerberos is disabled
> 
>
> Key: AMBARI-14236
> URL: https://issues.apache.org/jira/browse/AMBARI-14236
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.0
>
>
> From NN logs:
> 
> 
> javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled
> at 
> sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:637)
> at sun.security.ssl.InputRecord.read(InputRecord.java:527)
> at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:961)
> at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
> at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
> at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
> at 
> org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:723)
> at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> 
> Please check the live cluster for debugging: 



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

[jira] [Comment Edited] (AMBARI-14236) HDFS and Yarn alerts in https mode when kerberos is disabled

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk edited comment on AMBARI-14236 at 7/12/16 6:51 AM:
---

[~tctruong] I think wire encryption for HDFS and YARN was enabled and when I 
tried to connect via curl to their jmx / ui via SSL of any version it failed. I 
could do that only via TLSv1. 

Connecting via Python gived this error:
{noformat}
_ssl.c:491: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol>
{noformat}

[~rlevas] I remember you did some research on disabling TLSv1. Can you please 
chime in.


was (Author: aonishuk):
[~tctruong] I think wire encryption for HDFS and YARN was enabled and when I 
tried to connect via curl to their jmx / ui via SSL of any version it failed. I 
could do that only via TLSv1. 

[~rlevas] I remember you did some research on disabling TLSv1. Can you please 
chime in.

> HDFS and Yarn alerts in https mode when kerberos is disabled
> 
>
> Key: AMBARI-14236
> URL: https://issues.apache.org/jira/browse/AMBARI-14236
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.0
>
>
> From NN logs:
> 
> 
> javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled
> at 
> sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:637)
> at sun.security.ssl.InputRecord.read(InputRecord.java:527)
> at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:961)
> at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
> at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
> at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
> at 
> org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:723)
> at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> 
> Please check the live cluster for debugging: 



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

[jira] [Commented] (AMBARI-17607) Add localjceks support in ambari for Ranger and Ranger KMS services

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17607:
-

SUCCESS: Integrated in Ambari-trunk-Commit #5277 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5277/])
Revert "AMBARI-17607. Add localjecks support in ambari for Ranger and (gautam: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=e724158430a00b52c8626fcceb9ce6b971bf4aed])
* ambari-server/src/test/python/stacks/2.5/RANGER/test_ranger_admin.py
* ambari-server/src/test/python/stacks/2.5/RANGER/test_ranger_usersync.py
* 
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/package/scripts/params.py
* ambari-server/src/test/python/stacks/2.5/RANGER_KMS/test_kms_server.py
* 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/params.py
* 
ambari-server/src/main/resources/stacks/HDP/2.0.6/properties/stack_features.json
* 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/setup_ranger_xml.py
* 
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/package/scripts/kms.py
* 
ambari-common/src/main/python/resource_management/libraries/functions/constants.py


> Add localjceks support in ambari for Ranger and Ranger KMS services
> ---
>
> Key: AMBARI-17607
> URL: https://issues.apache.org/jira/browse/AMBARI-17607
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
> Attachments: AMBARI-17607.patch
>
>
> Currently, localjceks scheme is not supported for ranger installation through 
> Ambari. Ambari should use localjecks scheme to store, retrieve and list its 
> alias and values while installing ranger through Ambari.



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

[jira] [Commented] (AMBARI-14236) HDFS and Yarn alerts in https mode when kerberos is disabled

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk commented on AMBARI-14236:
--

[~tctruong] I think wire encryption for HDFS and YARN was enabled and when I 
tried to connect via curl to their jmx / ui via SSL of any version it failed. I 
could do that only via TLSv1. 

[~rlevas] I remember you did some research on disabling TLSv1. Can you please 
chime in.

> HDFS and Yarn alerts in https mode when kerberos is disabled
> 
>
> Key: AMBARI-14236
> URL: https://issues.apache.org/jira/browse/AMBARI-14236
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.0
>
>
> From NN logs:
> 
> 
> javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled
> at 
> sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:637)
> at sun.security.ssl.InputRecord.read(InputRecord.java:527)
> at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:961)
> at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
> at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
> at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
> at 
> org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:723)
> at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> 
> Please check the live cluster for debugging: 



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

[jira] [Updated] (AMBARI-17669) Zeppelin service: add default kerberos config for shell interpreter

[Renjith Kamath (JIRA)]

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

Renjith Kamath updated AMBARI-17669:

Status: Patch Available  (was: Open)

> Zeppelin service: add default kerberos config for shell interpreter
> ---
>
> Key: AMBARI-17669
> URL: https://issues.apache.org/jira/browse/AMBARI-17669
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.4.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
> Fix For: 2.4.0
>
> Attachments: AMBARI-17669_trunk+branch-2.4_v1.patch
>
>




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

[jira] [Updated] (AMBARI-17669) Zeppelin service: add default kerberos config for shell interpreter

[Renjith Kamath (JIRA)]

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

Renjith Kamath updated AMBARI-17669:

Attachment: AMBARI-17669_trunk+branch-2.4_v1.patch

> Zeppelin service: add default kerberos config for shell interpreter
> ---
>
> Key: AMBARI-17669
> URL: https://issues.apache.org/jira/browse/AMBARI-17669
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.4.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
> Fix For: 2.4.0
>
> Attachments: AMBARI-17669_trunk+branch-2.4_v1.patch
>
>




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

[jira] [Updated] (AMBARI-17652) Both Hive Views are auto-create. Should just be one

[DIPAYAN BHOWMICK (JIRA)]

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

DIPAYAN BHOWMICK updated AMBARI-17652:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

committed to trunk, branch-2.4

> Both Hive Views are auto-create. Should just be one
> ---
>
> Key: AMBARI-17652
> URL: https://issues.apache.org/jira/browse/AMBARI-17652
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.4.0
>Reporter: DIPAYAN BHOWMICK
>Assignee: DIPAYAN BHOWMICK
> Fix For: 2.5.0
>
> Attachments: AMBARI-17652.branch-2.4.patch
>
>
> Hive view 1.0 and Hive view 2.0 are both setup for auto-create instance.
> https://github.com/apache/ambari/blob/trunk/contrib/views/hive/src/main/resources/view.xml
> https://github.com/apache/ambari/blob/trunk/contrib/views/hive-next/src/main/resources/view.xml
> if Hive view 2.0 is meant to be the view moving forward (and replaces 1.0), 
> remove the Hive 1.0 auto-instance stuff. As it stands today: two 
> auto-instances will only create confusion and support cases.
> https://github.com/apache/ambari/blob/trunk/contrib/views/hive/src/main/resources/view.xml#L332-L340



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

[jira] [Created] (AMBARI-17671) Operation view showing pending task with start time dated Jan 01 1970

[Xavier FH Leong (JIRA)]

Xavier FH Leong created AMBARI-17671:


 Summary: Operation view showing pending task with start time dated 
Jan 01 1970
 Key: AMBARI-17671
 URL: https://issues.apache.org/jira/browse/AMBARI-17671
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.2.0
Reporter: Xavier FH Leong
Priority: Minor


On queue start operation from Background Operations Dialog showing Start Time 
as Jan 01 1970, it should show "Not Started" instead



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

[jira] [Commented] (AMBARI-17665) Fix the typo in 'alert_hive_interactive_thrift_port.py' for 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required extra '-' for 'findAppTimeout' pa

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-17665:


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

This message is automatically generated.

> Fix the typo in 'alert_hive_interactive_thrift_port.py' for 
> 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required 
> extra '-' for 'findAppTimeout' param in llapstatus comamnd.
> 
>
> Key: AMBARI-17665
> URL: https://issues.apache.org/jira/browse/AMBARI-17665
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.4.0
>
> Attachments: AMBARI-17665.patch
>
>
> - Current value : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
> '{{hive.server2.transport.mode/hive.server2.authentication}}'
>   *Fixed to :* HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
> '{{hive-site/hive.server2.authentication}}'
> - Added the required extra '-' for  'findAppTimeout' param in llapstatus 
> comamnd.



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

[jira] [Created] (AMBARI-17670) Modify Ambari Notice/License as needed for LogSearch

[Dharmesh Makwana (JIRA)]

Dharmesh Makwana created AMBARI-17670:
-

 Summary: Modify Ambari Notice/License as needed for LogSearch
 Key: AMBARI-17670
 URL: https://issues.apache.org/jira/browse/AMBARI-17670
 Project: Ambari
  Issue Type: Documentation
  Components: ambari-logsearch
Affects Versions: 2.4.0
Reporter: Dharmesh Makwana
Assignee: Dharmesh Makwana
 Fix For: 2.4.0


License file added for the component LogSearch-Portal



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

[jira] [Commented] (AMBARI-17668) optimize log description of ambari agent stop

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-17668:


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

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

This message is automatically generated.

> optimize log description of ambari agent stop
> -
>
> Key: AMBARI-17668
> URL: https://issues.apache.org/jira/browse/AMBARI-17668
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-agent
>Reporter: wangyaoxin
> Fix For: trunk, 2.4.0
>
> Attachments: AMBARI-17668.patch
>
>
> excute ambari agent ，going to execute kill -9，but none output log



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

[jira] [Commented] (AMBARI-17293) Ambari does not refresh yarn queues when HiveServerIntearctive component is restarted

[Antonenko Alexander (JIRA)]

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

Antonenko Alexander commented on AMBARI-17293:
--

+1 for the patch

> Ambari does not refresh yarn queues when HiveServerIntearctive component is 
> restarted
> -
>
> Key: AMBARI-17293
> URL: https://issues.apache.org/jira/browse/AMBARI-17293
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Aleksandr Kovalenko
>Assignee: Aleksandr Kovalenko
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17293.patch, AMBARI-17293_3.patch, 
> AMBARI-17293_second_patch.patch
>
>




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

[jira] [Commented] (AMBARI-17607) Add localjceks support in ambari for Ranger and Ranger KMS services

[Gautam Borad (JIRA)]

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

Gautam Borad commented on AMBARI-17607:
---

Reverted in trunk and branch-2.4.

branch-2.4:
{noformat}
commit 67e60e3085e776e1e396107c0ba2be49ed0bc74c
Author: Gautam Borad 
Date:   Tue Jul 12 10:28:42 2016 +0530

Revert "AMBARI-17607. Add localjecks support in ambari for Ranger and 
Ranger KMS services (Mugdha Varadkar via srimanth)"

This reverts commit 481d04ae8f14dd1c70b575fa40d7796106956828.
{noformat}

trunk:
{noformat}
commit e724158430a00b52c8626fcceb9ce6b971bf4aed
Author: Gautam Borad 
Date:   Tue Jul 12 10:27:22 2016 +0530

Revert "AMBARI-17607. Add localjecks support in ambari for Ranger and 
Ranger KMS services (Mugdha Varadkar via srimanth)"

This reverts commit 5e4faf1ea928695e6dc5e1ace3dd1a0f1636890e.
{noformat}

> Add localjceks support in ambari for Ranger and Ranger KMS services
> ---
>
> Key: AMBARI-17607
> URL: https://issues.apache.org/jira/browse/AMBARI-17607
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
> Attachments: AMBARI-17607.patch
>
>
> Currently, localjceks scheme is not supported for ranger installation through 
> Ambari. Ambari should use localjecks scheme to store, retrieve and list its 
> alias and values while installing ranger through Ambari.



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

[jira] [Updated] (AMBARI-17607) Add localjceks support in ambari for Ranger and Ranger KMS services

[Gautam Borad (JIRA)]

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

Gautam Borad updated AMBARI-17607:
--
Fix Version/s: (was: 2.4.0)

> Add localjceks support in ambari for Ranger and Ranger KMS services
> ---
>
> Key: AMBARI-17607
> URL: https://issues.apache.org/jira/browse/AMBARI-17607
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
> Attachments: AMBARI-17607.patch
>
>
> Currently, localjceks scheme is not supported for ranger installation through 
> Ambari. Ambari should use localjecks scheme to store, retrieve and list its 
> alias and values while installing ranger through Ambari.



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

[jira] [Commented] (AMBARI-17651) Restart indicator is not shown after modifying the configs

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17651:
-

SUCCESS: Integrated in Ambari-trunk-Commit #5276 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5276/])
Revert "AMBARI-17651. Restart indicator is not shown after modifying the 
(jhurley: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=8be77911e3d8ab86304297c05e76970f148395d4])
* 
ambari-server/src/test/java/org/apache/ambari/server/state/ConfigHelperTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ConfigGroupResourceProvider.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ConfigGroupResourceProviderTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
* ambari-server/src/main/java/org/apache/ambari/server/state/ConfigHelper.java
* 
ambari-server/src/main/java/org/apache/ambari/server/agent/HeartBeatHandler.java


> Restart indicator is not shown after modifying the configs
> --
>
> Key: AMBARI-17651
> URL: https://issues.apache.org/jira/browse/AMBARI-17651
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-17651.patch
>
>
> Restart indicator is not shown after modifying the configs.
> Test case modified the hdfs config 'Namenode new generation size'. But still 
> after saving the configuration, restart icon is not shown.



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

[jira] [Reopened] (AMBARI-17607) Add localjceks support in ambari for Ranger and Ranger KMS services

[Gautam Borad (JIRA)]

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

Gautam Borad reopened AMBARI-17607:
---

Reopening and reverting the commits made in this jira, since switching to 
localjceks is causing more issues in upgrade/downgrade and other places.

Consequences of revert will be a warn log message that is shown when the jckes 
is tried to accessed. However there is no loss in functionality.



> Add localjceks support in ambari for Ranger and Ranger KMS services
> ---
>
> Key: AMBARI-17607
> URL: https://issues.apache.org/jira/browse/AMBARI-17607
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
> Fix For: 2.4.0
>
> Attachments: AMBARI-17607.patch
>
>
> Currently, localjceks scheme is not supported for ranger installation through 
> Ambari. Ambari should use localjecks scheme to store, retrieve and list its 
> alias and values while installing ranger through Ambari.



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

[jira] [Commented] (AMBARI-17660) EU Downgrade Does Not Stop Services

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17660:
-

SUCCESS: Integrated in Ambari-trunk-Commit #5276 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5276/])
AMBARI-17660 - EU Downgrade Does Not Stop Services (jonathanhurley) (jhurley: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=29185fad2afdadd6c42f6fbce434ee8a9393])
* 
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.5.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.5.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.4.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.4.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.4.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.2.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.5.xml


> EU Downgrade Does Not Stop Services
> ---
>
> Key: AMBARI-17660
> URL: https://issues.apache.org/jira/browse/AMBARI-17660
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17660.patch
>
>
> When downgrading an express upgrade, the orchestration of the downgrade does 
> not perform the same steps as the upgrade did. Namely, the stopping of high- 
> and low-level services is not present. This leads to a scenario like this:
> - Upgrade HDP 2.x to 2.y
> -- Stop Storm
> -- Stop ZK
> -- Update Stack to 2.y
> -- Restart ZK on 2.y
> -- Restart Storm on 2.y
> - Downgrade  HDP 2.y to 2.x
> -- Update Stack to 2.x
> -- Restart ZK on 2.x
> -- Restart Storm on 2.x
> Notice that we didn't stop the running services. This leads to a problem 
> where actions which must take place while services are down can't complete 
> successfully.
> The case in point is Storm. Between HDP 2.4 and HDP 2.5, Storm changed the 
> name of a serialized class. Part of the Storm upgrade/downgrade is to always 
> delete local storm data. However, during an EU, if Nimbus and Supervisor are 
> co-located on the same host, Supervisor will write out 2.5 data since it 
> wasn't shut down. Consider:
> - Nimbus deletes local data and restarts on the downgrade version
> - A running 2.5 Supervisor on the same host then re-creates that directory 
> and puts 2.5 data back in
> - When the 2.5 Supervisor goes to downgrade and restart, it can't delete that 
> data again since Nimbus is already running and would stop.
> For this reason, we should always ensure that services are stopped on the 
> downgrade for an EU. 



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

[jira] [Assigned] (AMBARI-17669) Zeppelin service: add default kerberos config for shell interpreter

[Renjith Kamath (JIRA)]

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

Renjith Kamath reassigned AMBARI-17669:
---

Assignee: Renjith Kamath

> Zeppelin service: add default kerberos config for shell interpreter
> ---
>
> Key: AMBARI-17669
> URL: https://issues.apache.org/jira/browse/AMBARI-17669
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.4.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
> Fix For: 2.4.0
>
>




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

[jira] [Created] (AMBARI-17669) Zeppelin service: add default kerberos config for shell interpreter

[Renjith Kamath (JIRA)]

Renjith Kamath created AMBARI-17669:
---

 Summary: Zeppelin service: add default kerberos config for shell 
interpreter
 Key: AMBARI-17669
 URL: https://issues.apache.org/jira/browse/AMBARI-17669
 Project: Ambari
  Issue Type: Improvement
Affects Versions: 2.4.0
Reporter: Renjith Kamath
 Fix For: 2.4.0






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

[jira] [Updated] (AMBARI-17668) optimize log description of ambari agent stop

[wangyaoxin (JIRA)]

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

wangyaoxin updated AMBARI-17668:

Attachment: AMBARI-17668.patch

> optimize log description of ambari agent stop
> -
>
> Key: AMBARI-17668
> URL: https://issues.apache.org/jira/browse/AMBARI-17668
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-agent
>Reporter: wangyaoxin
> Fix For: trunk, 2.4.0
>
> Attachments: AMBARI-17668.patch
>
>
> excute ambari agent ，going to execute kill -9，but none output log



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

[jira] [Updated] (AMBARI-17668) optimize log description of ambari agent stop

[wangyaoxin (JIRA)]

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

wangyaoxin updated AMBARI-17668:

Status: Patch Available  (was: Open)

> optimize log description of ambari agent stop
> -
>
> Key: AMBARI-17668
> URL: https://issues.apache.org/jira/browse/AMBARI-17668
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-agent
>Reporter: wangyaoxin
> Fix For: trunk, 2.4.0
>
> Attachments: AMBARI-17668.patch
>
>
> excute ambari agent ，going to execute kill -9，but none output log



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

[jira] [Created] (AMBARI-17668) optimize log description of ambari agent stop

[wangyaoxin (JIRA)]

wangyaoxin created AMBARI-17668:
---

 Summary: optimize log description of ambari agent stop
 Key: AMBARI-17668
 URL: https://issues.apache.org/jira/browse/AMBARI-17668
 Project: Ambari
  Issue Type: Improvement
  Components: ambari-agent
Reporter: wangyaoxin
 Fix For: trunk, 2.4.0


excute ambari agent ，going to execute kill -9，but none output log



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

[jira] [Commented] (AMBARI-17663) Hosts page: JS error when sorting

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17663:
-

SUCCESS: Integrated in Ambari-trunk-Commit #5275 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5275/])
AMBARI-17663 - Hosts page: JS error when sorting (rzang) (rzang: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=624fb1c84d1be33b5c4c9d93293a7aa9717edfcc])
* ambari-web/app/views/common/sort_view.js


> Hosts page: JS error when sorting
> -
>
> Key: AMBARI-17663
> URL: https://issues.apache.org/jira/browse/AMBARI-17663
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.5.0
>
> Attachments: AMBARI-17663.patch
>
>
> Go to Hosts page and try sort by any column.
> JS error: 
> {noformat}
> Uncaught TypeError: wrapperView.removeSortingObserver is not a function
> {noformat}
> Although sorting works fine.



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

[jira] [Updated] (AMBARI-17665) Fix the typo in 'alert_hive_interactive_thrift_port.py' for 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required extra '-' for 'findAppTimeout' para

[Swapan Shridhar (JIRA)]

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

Swapan Shridhar updated AMBARI-17665:
-
Status: Patch Available  (was: Open)

> Fix the typo in 'alert_hive_interactive_thrift_port.py' for 
> 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required 
> extra '-' for 'findAppTimeout' param in llapstatus comamnd.
> 
>
> Key: AMBARI-17665
> URL: https://issues.apache.org/jira/browse/AMBARI-17665
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.4.0
>
> Attachments: AMBARI-17665.patch
>
>
> - Current value : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
> '{{hive.server2.transport.mode/hive.server2.authentication}}'
>   *Fixed to :* HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
> '{{hive-site/hive.server2.authentication}}'
> - Added the required extra '-' for  'findAppTimeout' param in llapstatus 
> comamnd.



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

[jira] [Updated] (AMBARI-17665) Fix the typo in 'alert_hive_interactive_thrift_port.py' for 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required extra '-' for 'findAppTimeout' para

[Swapan Shridhar (JIRA)]

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

Swapan Shridhar updated AMBARI-17665:
-
Attachment: AMBARI-17665.patch

> Fix the typo in 'alert_hive_interactive_thrift_port.py' for 
> 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required 
> extra '-' for 'findAppTimeout' param in llapstatus comamnd.
> 
>
> Key: AMBARI-17665
> URL: https://issues.apache.org/jira/browse/AMBARI-17665
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.4.0
>
> Attachments: AMBARI-17665.patch
>
>
> - Current value : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
> '{{hive.server2.transport.mode/hive.server2.authentication}}'
>   *Fixed to :* HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
> '{{hive-site/hive.server2.authentication}}'
> - Added the required extra '-' for  'findAppTimeout' param in llapstatus 
> comamnd.



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

[jira] [Commented] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-17635:


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

This message is automatically generated.

> Disable async logging for HiveServer2 + Hive 2.x
> 
>
> Key: AMBARI-17635
> URL: https://issues.apache.org/jira/browse/AMBARI-17635
> Project: Ambari
>  Issue Type: Bug
>  Components:  HiveServer2, Metastore, and Client Heap Sizes to Smart 
> Configs, ambari-server, stacks
>Affects Versions: 2.4.0
>Reporter: Prasanth Jayachandran
>Assignee: Prasanth Jayachandran
> Attachments: AMBARI-17635.1.patch, AMBARI-17635.2.patch, 
> AMBARI-17635.3.patch
>
>
> Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's 
> use of custom log divert appender. We should disable async logging for HS2 
> until we have a proper fix in hive.



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

[jira] [Updated] (AMBARI-11382) test_execute_retryable_command_succeed fails intermittently

[Sumit Mohanty (JIRA)]

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

Sumit Mohanty updated AMBARI-11382:
---
Resolution: Not A Problem
Status: Resolved  (was: Patch Available)

> test_execute_retryable_command_succeed fails intermittently
> ---
>
> Key: AMBARI-11382
> URL: https://issues.apache.org/jira/browse/AMBARI-11382
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: 2.1.0
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
> Attachments: AMBARI-11382-2.patch
>
>
> ==
> FAIL: test_execute_retryable_command_succeed (TestActionQueue.TestActionQueue)
> --
> Traceback (most recent call last):
>   File 
> "/home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-common/src/test/python/mock/mock.py",
>  line 1199, in patched
> return func(*args, **keywargs)
>   File 
> "/home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-agent/src/test/python/ambari_agent/TestActionQueue.py",
>  line 888, in test_execute_retryable_command_succeed
> self.assertFalse(sleep_mock.called)
> AssertionError: True is not false



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

[jira] [Resolved] (AMBARI-17439) Allow commands to specify if they should be auto-retried upon failure

[Sumit Mohanty (JIRA)]

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

Sumit Mohanty resolved AMBARI-17439.

Resolution: Duplicate

AMBARI-17443

> Allow commands to specify if they should be auto-retried upon failure
> -
>
> Key: AMBARI-17439
> URL: https://issues.apache.org/jira/browse/AMBARI-17439
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
>Priority: Critical
> Fix For: 2.4.0
>
>
> During cluster creation using a blueprint, the initial INSTALL and START 
> commands are automatically retried by the agent upon failure. This support 
> was added to allow immediate scheduling of commands (while hosts join the 
> cluster) rather than waiting for all hosts to join.
> The feature itself is straight forward - if any command failed then agent 
> will automatically retry them for a configurable duration.
> Auto retry itself is useful for other commands where user may want to retry 
> before giving up - e.g. Restart commands. Rather than failing immediately 
> agents can try a few more times. Its particularly useful if the start of a 
> service depends on another service which is also being restarted. 



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

[jira] [Resolved] (AMBARI-17438) Allow commands to specify if they should be auto-retried upon failure

[Sumit Mohanty (JIRA)]

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

Sumit Mohanty resolved AMBARI-17438.

Resolution: Duplicate

AMBARI-17443

> Allow commands to specify if they should be auto-retried upon failure
> -
>
> Key: AMBARI-17438
> URL: https://issues.apache.org/jira/browse/AMBARI-17438
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
>Priority: Critical
> Fix For: 2.4.0
>
>
> During cluster creation using a blueprint, the initial INSTALL and START 
> commands are automatically retried by the agent upon failure. This support 
> was added to allow immediate scheduling of commands (while hosts join the 
> cluster) rather than waiting for all hosts to join.
> The feature itself is straight forward - if any command failed then agent 
> will automatically retry them for a configurable duration.
> Auto retry itself is useful for other commands where user may want to retry 
> before giving up - e.g. Start/Restart/Stop commands. Rather than failing 
> immediately agents can try a few more times. Its particularly useful if the 
> start of a service depends on another service which is also being restarted. 



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

[jira] [Resolved] (AMBARI-15139) Tracks work items related to log accumulation and searching support in Ambari

[Sumit Mohanty (JIRA)]

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

Sumit Mohanty resolved AMBARI-15139.

Resolution: Not A Bug

> Tracks work items related to log accumulation and searching support in Ambari
> -
>
> Key: AMBARI-15139
> URL: https://issues.apache.org/jira/browse/AMBARI-15139
> Project: Ambari
>  Issue Type: Epic
>  Components: stacks
>Affects Versions: 2.2.2
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
>Priority: Critical
> Fix For: 2.4.0
>
>
> Ambari already deploys a number of services and is aware of the log file 
> location for all the services. If there is a need to debug, currently, user 
> needs to go to each host and browse through each file to debug issues. This 
> can be greatly improved by creating a log search service (a stack service in 
> itself) that can be configured to ingest existing log files and allowing easy 
> search/query across all log files - include Ambari's own.



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

[jira] [Resolved] (AMBARI-17440) Allow commands to specify if they should be auto-retried upon failure

[Sumit Mohanty (JIRA)]

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

Sumit Mohanty resolved AMBARI-17440.


AMBARI-17443

> Allow commands to specify if they should be auto-retried upon failure
> -
>
> Key: AMBARI-17440
> URL: https://issues.apache.org/jira/browse/AMBARI-17440
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
>Priority: Critical
> Fix For: 2.4.0
>
>
> During cluster creation using a blueprint, the initial INSTALL and START 
> commands are automatically retried by the agent upon failure. This support 
> was added to allow immediate scheduling of commands (while hosts join the 
> cluster) rather than waiting for all hosts to join.
> The feature itself is straight forward - if any command failed then agent 
> will automatically retry them for a configurable duration.
> Auto retry itself is useful for other commands where user may want to retry 
> before giving up - e.g. Restart commands. Rather than failing immediately 
> agents can try a few more times. Its particularly useful if the start of a 
> service depends on another service which is also being restarted. 



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

[jira] [Updated] (AMBARI-17507) Provide an option not to log ambari-agent command output for user custom script action

[Sumit Mohanty (JIRA)]

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

Sumit Mohanty updated AMBARI-17507:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Provide an option not to log ambari-agent command output for user custom 
> script action
> --
>
> Key: AMBARI-17507
> URL: https://issues.apache.org/jira/browse/AMBARI-17507
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17507.patch
>
>
> Custom commands is a way to create a set of commands that can perform 
> specific actions on the cluster. Class of actions typically involve 
> initialization, setup, and cleanup - different than the 
> start/stop/configure/install etc.
> By default all command output gets logged. It should be possible for the 
> command to indicate if the output should be logged if the command may output 
> PII information.



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

[jira] [Updated] (AMBARI-16080) Delete Service: Deleting Hive fails with 500 error

[Sumit Mohanty (JIRA)]

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

Sumit Mohanty updated AMBARI-16080:
---
   Resolution: Fixed
Fix Version/s: (was: 2.5.0)
   2.4.0
   Status: Resolved  (was: Patch Available)

> Delete Service: Deleting Hive fails with 500 error
> --
>
> Key: AMBARI-16080
> URL: https://issues.apache.org/jira/browse/AMBARI-16080
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
> Fix For: 2.4.0
>
> Attachments: AMBARI-16080.patch
>
>
> *STR:*
> # Stop all components of Hive service
> # Delete service from UI
> API fails with message
> {code}
> {
>   "status" : 500,
>   "message" : "org.apache.ambari.server.controller.spi.SystemException: An 
> internal system exception occurred: Could not delete service from cluster, 
> clusterName=c1, serviceName=HIVE"
> }
> {code}
> {code:title=ambari-server.log}
> 23 Apr 2016 02:14:38,714 ERROR [qtp-ambari-client-100] 
> AbstractResourceProvider:343 - Caught AmbariException when modifying a 
> resource
> org.apache.ambari.server.AmbariException: Could not delete service from 
> cluster, clusterName=c1, serviceName=HIVE
> at 
> org.apache.ambari.server.state.cluster.ClusterImpl.deleteService(ClusterImpl.java:2207)
> at 
> org.apache.ambari.server.controller.internal.ServiceResourceProvider.deleteServices(ServiceResourceProvider.java:810)
> at 
> org.apache.ambari.server.controller.internal.ServiceResourceProvider$3.invoke(ServiceResourceProvider.java:244)
> at 
> org.apache.ambari.server.controller.internal.ServiceResourceProvider$3.invoke(ServiceResourceProvider.java:241)
> at 
> org.apache.ambari.server.controller.internal.AbstractResourceProvider.invokeWithRetry(AbstractResourceProvider.java:455)
> at 
> org.apache.ambari.server.controller.internal.AbstractResourceProvider.modifyResources(AbstractResourceProvider.java:336)
> at 
> org.apache.ambari.server.controller.internal.ServiceResourceProvider.deleteResourcesAuthorized(ServiceResourceProvider.java:241)
> at 
> org.apache.ambari.server.controller.internal.AbstractAuthorizedResourceProvider.deleteResources(AbstractAuthorizedResourceProvider.java:335)
> at 
> org.apache.ambari.server.controller.internal.ClusterControllerImpl.deleteResources(ClusterControllerImpl.java:339)
> at 
> org.apache.ambari.server.api.services.persistence.PersistenceManagerImpl.delete(PersistenceManagerImpl.java:132)
> at 
> org.apache.ambari.server.api.handlers.DeleteHandler.persist(DeleteHandler.java:49)
> at 
> org.apache.ambari.server.api.handlers.BaseManagementHandler.handleRequest(BaseManagementHandler.java:73)
> at 
> org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:145)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:119)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:83)
> at 
> org.apache.ambari.server.api.services.ServiceService.deleteService(ServiceService.java:178)
> {code}



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

[jira] [Updated] (AMBARI-17667) Storm 1.0 Does Not Support Rolling Upgrades

[Jonathan Hurley (JIRA)]

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

Jonathan Hurley updated AMBARI-17667:
-
Description: 
HDP 2.5 includes a new version of Storm where packages named {{backtype.storm}} 
were changed to {{org.apache.storm}}. As a result, Storm local data is not 
compatible between versions earlier versions of HDP and HDP 2.5. Consider the 
following situatio where Nimbus and a Supervisor are co-located on the same 
host:

- Nimbus deletes local data and restarts on the new version
- A running 2.4 Supervisor on the same host then re-creates that directory and 
puts 2.4 data back in
- When the 2.4 Supervisor goes to upgrade and restart, it can't delete that 
data again since Nimbus is already running and would stop.

When starting the Supevisor, the following error is seen:
{code}
2016-06-21 23:10:48.000 o.a.s.c.f.s.ConnectionStateManager [INFO] State change: 
CONNECTED
2016-06-21 23:10:48.058 b.s.d.supervisor [INFO] Starting supervisor with id 
03d8bceb-0271-4076-810d-04aeaa91533c at host 
nat-os-r6-omns-dgm10toeriedwngdha-r6-2.openstacklocal
2016-06-21 23:10:48.785 b.s.event [ERROR] Error when processing event
java.lang.RuntimeException: java.lang.ClassNotFoundException: 
org.apache.storm.generated.LSSupervisorAssignments
at backtype.storm.utils.LocalState.deserialize(LocalState.java:83) 
~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
at backtype.storm.utils.LocalState.get(LocalState.java:130) 
~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
at 
backtype.storm.local_state$ls_local_assignments.invoke(local_state.clj:83) 
~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
at 
backtype.storm.daemon.supervisor$sync_processes.invoke(supervisor.clj:323) 
~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
at clojure.lang.AFn.applyToHelper(AFn.java:154) ~[clojure-1.6.0.jar:?]
at clojure.lang.AFn.applyTo(AFn.java:144) ~[clojure-1.6.0.jar:?]
at clojure.core$apply.invoke(core.clj:626) ~[clojure-1.6.0.jar:?]
at clojure.core$partial$fn__4228.doInvoke(core.clj:2468) 
~[clojure-1.6.0.jar:?]
at clojure.lang.RestFn.invoke(RestFn.java:397) ~[clojure-1.6.0.jar:?]
at backtype.storm.event$event_manager$fn__6135.invoke(event.clj:40) 
[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
at clojure.lang.AFn.run(AFn.java:22) [clojure-1.6.0.jar:?]
at java.lang.Thread.run(Thread.java:745) [?:1.7.0_67]
Caused by: java.lang.ClassNotFoundException: 
org.apache.storm.generated.LSSupervisorAssignments
at java.net.URLClassLoader$1.run(URLClassLoader.java:366) ~[?:1.7.0_67]
at java.net.URLClassLoader$1.run(URLClassLoader.java:355) ~[?:1.7.0_67]
at java.security.AccessController.doPrivileged(Native Method) 
~[?:1.7.0_67]
at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 
~[?:1.7.0_67]
at java.lang.ClassLoader.loadClass(ClassLoader.java:425) ~[?:1.7.0_67]
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
~[?:1.7.0_67]
at java.lang.ClassLoader.loadClass(ClassLoader.java:358) ~[?:1.7.0_67]
at java.lang.Class.forName0(Native Method) ~[?:1.7.0_67]
at java.lang.Class.forName(Class.java:190) ~[?:1.7.0_67]
at backtype.storm.utils.LocalState.deserialize(LocalState.java:78) 
~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
{code}

  was:
HDP 2.5 includes a new version of Storm where packages named {{backtype.storm}} 
were changed to {{org.apache.storm}}. As a result, Storm local data is not 
compatible between versions earlier versions of HDP and HDP 2.5. Consider the 
following situatio where Nimbus and a Supervisor are co-located on the same 
host:

- Nimbus deletes local data and restarts on the downgrade version
- A running 2.5 Supervisor on the same host then re-creates that directory and 
puts 2.5 data back in
- When the 2.5 Supervisor goes to downgrade and restart, it can't delete that 
data again since Nimbus is already running and would stop.

When starting the Supevisor, the following error is seen:
{code}
2016-06-21 23:10:48.000 o.a.s.c.f.s.ConnectionStateManager [INFO] State change: 
CONNECTED
2016-06-21 23:10:48.058 b.s.d.supervisor [INFO] Starting supervisor with id 
03d8bceb-0271-4076-810d-04aeaa91533c at host 
nat-os-r6-omns-dgm10toeriedwngdha-r6-2.openstacklocal
2016-06-21 23:10:48.785 b.s.event [ERROR] Error when processing event
java.lang.RuntimeException: java.lang.ClassNotFoundException: 
org.apache.storm.generated.LSSupervisorAssignments
at backtype.storm.utils.LocalState.deserialize(LocalState.java:83) 
~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
at backtype.storm.utils.LocalState.get(LocalState.java:130) 
~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
at 
backtype.storm.local_state$ls_local_assignments.invoke(local_state.clj:83) 
~

[jira] [Commented] (AMBARI-17662) Atlas HA fails to come up with error finding ids

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-17662:


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

This message is automatically generated.

> Atlas HA fails to come up with error finding ids
> 
>
> Key: AMBARI-17662
> URL: https://issues.apache.org/jira/browse/AMBARI-17662
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.4.0
>
> Attachments: AMBARI-17662.branch-2.4.patch, AMBARI-17662.trunk.patch
>
>
> Deploy multiple Atlas servers and one of them will fail since it will be 
> missing its ids.
> {noformat}
> 2016-06-14 10:48:23,249 WARN  - [main:] ~ Failed startup of context 
> o.e.j.w.WebAppContext@2ad31d76{/,file:/grid/0/hdp/2.5.0.0-723/atlas/server/webapp/atlas/,STARTING}{/usr/hdp/current/atlas-server/server/webapp/atlas}
>  (WebAppContext:514)
> java.lang.RuntimeException: org.apache.atlas.AtlasException: Could not find 
> server id for this instance. Unable to find IDs matching any local host and 
> port binding among id1
> at org.apache.atlas.service.Services.start(Services.java:48)
> at 
> org.apache.atlas.web.listeners.GuiceServletConfig.startServices(GuiceServletConfig.java:142)
> at 
> org.apache.atlas.web.listeners.GuiceServletConfig.contextInitialized(GuiceServletConfig.java:136)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
> at org.eclipse.jetty.server.Server.start(Server.java:387)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> at org.eclipse.jetty.server.Server.doStart(Server.java:354)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.apache.atlas.web.service.EmbeddedServer.start(EmbeddedServer.java:93)
> at org.apache.atlas.Atlas.main(Atlas.java:113)
> Caused by: org.apache.atlas.AtlasException: Could not find server id for this 
> instance. Unable to find IDs matching any local host and port binding among 
> id1
> at 
> org.apache.atlas.ha.AtlasServerIdSelector.selectServerId(AtlasServerIdSelector.java:77)
> at 
> org.apache.atlas.web.service.ActiveInstanceElectorService.start(ActiveInstanceElectorService.java:105)
> at org.apache.atlas.service.Services.start(Services.java:45)
> ... 19 more
> 2016-06-14 10:48:23,284 INFO  - [main:] ~ Started 
> ServerConnector@255af999{HTTP/1.1}{0.0.0.0:21000} (ServerConnector:266)
> {noformat}
> To fix this,
> atlas.server.ha.enabled will not be shown on the UI and instead derived. But 
> if for whatever reason we need to do some debugging/troubleshooting on Atlas, 
> we may allow the user to override the property.
> * single Atlas Server => write config with atlas.server.ha.enabled=false (if 
> atlas.server.ha.enabled is set to true, still write it out as false)
> * multiple Atlas Servers => write config with atlas.server.ha.enabled=true 
> (only if atlas.server.ha.enabled is not a property, otherwise, take its value)



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

[jira] [Commented] (AMBARI-17253) Ambari Alert causes too many wanings in ZooKeeper logs.

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-17253:


{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12817268/AMBARI-17253.6.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 
ambari-server.

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

This message is automatically generated.

> Ambari Alert causes too many wanings in ZooKeeper logs.
> ---
>
> Key: AMBARI-17253
> URL: https://issues.apache.org/jira/browse/AMBARI-17253
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: trunk
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
> Attachments: AMBARI-17253.1.patch, AMBARI-17253.2.patch, 
> AMBARI-17253.3.patch, AMBARI-17253.4.patch, AMBARI-17253.5.patch, 
> AMBARI-17253.6.patch, AMBARI-17253.patch
>
>
> There are too many WARNING in ZooKeeper log.
> {code}
> 2016-06-15 21:02:15,405 - WARN  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@357] - caught end of 
> stream exception
> EndOfStreamException: Unable to read additional data from client sessionid 
> 0x0, likely client has closed socket
> at 
> org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:228)
> at 
> org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> It may be because of Ambari Alert. Ambari Alert pings to the zookeeper port 
> to do monitoring.
> We should use 'ruok' to monitor zookeepers.



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

[jira] [Reopened] (AMBARI-17651) Restart indicator is not shown after modifying the configs

[Jonathan Hurley (JIRA)]

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

Jonathan Hurley reopened AMBARI-17651:
--

Reverted because it caused a deadlock (see attached  [^jstack.txt] ):

{code}
"ambari-client-thread-80" prio=5 tid=0x7fc2413ed000 nid=0xc703 waiting on 
condition [0x74f0]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x000701ad15a8> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:964)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1282)
at 
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:731)
at 
org.apache.ambari.server.state.ConfigHelper.isStaleConfigs(ConfigHelper.java:482)
at 
org.apache.ambari.server.state.cluster.ClusterImpl.getClusterHealthReport(ClusterImpl.java:3186)
at 
org.apache.ambari.server.state.cluster.ClusterImpl.convertToResponse(ClusterImpl.java:2140)
at 
org.apache.ambari.server.controller.AmbariManagementControllerImpl.getClusters(AmbariManagementControllerImpl.java:1046)
at 
org.apache.ambari.server.controller.AmbariManagementControllerImpl.getClusters(AmbariManagementControllerImpl.java:3345)
at 
org.apache.ambari.server.controller.internal.ClusterResourceProvider$1.invoke(ClusterResourceProvider.java:254)
at 
org.apache.ambari.server.controller.internal.ClusterResourceProvider$1.invoke(ClusterResourceProvider.java:1)
at 
org.apache.ambari.server.controller.internal.AbstractResourceProvider.getResources(AbstractResourceProvider.java:307)
at 
org.apache.ambari.server.controller.internal.ClusterResourceProvider.getResources(ClusterResourceProvider.java:251)
at 
org.apache.ambari.server.controller.internal.ClusterControllerImpl$ExtendedResourceProviderWrapper.queryForResources(ClusterControllerImpl.java:967)
at 
org.apache.ambari.server.controller.internal.ClusterControllerImpl.getResources(ClusterControllerImpl.java:141)
{code}

> Restart indicator is not shown after modifying the configs
> --
>
> Key: AMBARI-17651
> URL: https://issues.apache.org/jira/browse/AMBARI-17651
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-17651.patch
>
>
> Restart indicator is not shown after modifying the configs.
> Test case modified the hdfs config 'Namenode new generation size'. But still 
> after saving the configuration, restart icon is not shown.



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

[jira] [Updated] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x

[Prasanth Jayachandran (JIRA)]

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

Prasanth Jayachandran updated AMBARI-17635:
---
Attachment: AMBARI-17635.3.patch

[~jaimin] Now that hiveserver2-interactive-site.xml file is committed. Could 
you please review this change?

> Disable async logging for HiveServer2 + Hive 2.x
> 
>
> Key: AMBARI-17635
> URL: https://issues.apache.org/jira/browse/AMBARI-17635
> Project: Ambari
>  Issue Type: Bug
>  Components:  HiveServer2, Metastore, and Client Heap Sizes to Smart 
> Configs, ambari-server, stacks
>Affects Versions: 2.4.0
>Reporter: Prasanth Jayachandran
>Assignee: Prasanth Jayachandran
> Attachments: AMBARI-17635.1.patch, AMBARI-17635.2.patch, 
> AMBARI-17635.3.patch
>
>
> Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's 
> use of custom log divert appender. We should disable async logging for HS2 
> until we have a proper fix in hive.



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

[jira] [Updated] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x

[Prasanth Jayachandran (JIRA)]

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

Prasanth Jayachandran updated AMBARI-17635:
---
Status: Patch Available  (was: Open)

> Disable async logging for HiveServer2 + Hive 2.x
> 
>
> Key: AMBARI-17635
> URL: https://issues.apache.org/jira/browse/AMBARI-17635
> Project: Ambari
>  Issue Type: Bug
>  Components:  HiveServer2, Metastore, and Client Heap Sizes to Smart 
> Configs, ambari-server, stacks
>Affects Versions: 2.4.0
>Reporter: Prasanth Jayachandran
>Assignee: Prasanth Jayachandran
> Attachments: AMBARI-17635.1.patch, AMBARI-17635.2.patch, 
> AMBARI-17635.3.patch
>
>
> Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's 
> use of custom log divert appender. We should disable async logging for HS2 
> until we have a proper fix in hive.



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

[jira] [Updated] (AMBARI-17644) hiveserver2-site.xml is missing from /etc/hive2/conf/conf.server when hsi is set up by Ambari

[Sumit Mohanty (JIRA)]

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

Sumit Mohanty updated AMBARI-17644:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

committed to trunk and branch-2.4

> hiveserver2-site.xml is missing from /etc/hive2/conf/conf.server when hsi is 
> set up by Ambari
> -
>
> Key: AMBARI-17644
> URL: https://issues.apache.org/jira/browse/AMBARI-17644
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.0
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17644.patch
>
>
> Currently hiveserver2-site.xml is missing from /etc/hive2/conf/conf.server 
> when a llap cluster is setup by Ambari as shown in the below:
> {noformat}
> [root@r7-hsi-0706-r-4 ~]# ls -l /etc/hive2/conf/conf.server/
> total 68
> -rw-r--r--. 1 hive hadoop  1596 Jul  6 20:04 beeline-log4j2.properties
> -rw-r--r--. 1 hive hadoop  1434 Jul  6 20:04 
> hadoop-metrics2-llapdaemon.properties
> -rw-r--r--. 1 hive hadoop  1441 Jul  6 20:04 
> hadoop-metrics2-llaptaskscheduler.properties
> -rw-r--r--. 1 hive hadoop 0 Jul  6 20:04 hive-default.xml.template
> -rw-r--r--. 1 hive hadoop  1887 Jul  6 20:04 hive-env.sh
> -rw-r--r--. 1 hive hadoop 0 Jul  6 20:04 hive-env.sh.template
> -rw-r--r--. 1 hive hadoop  2287 Jul  6 20:04 hive-exec-log4j2.properties
> -rw-r--r--. 1 hive hadoop  2754 Jul  6 20:04 hive-log4j2.properties
> -rw-r--r--. 1 hive hadoop 24226 Jul  6 20:14 hive-site.xml
> -rw-r--r--. 1 hive hadoop  2752 Jul  6 20:04 llap-cli-log4j2.properties
> -rw-r--r--. 1 hive hadoop  4217 Jul  6 20:04 llap-daemon-log4j2.properties
> -rw-r--r--. 1 hive hadoop  6776 Jul  6 20:04 mapred-site.xml
> {noformat}
> The test framework requires hiveserver2-site.xml to be present and in a case 
> of Hive 1, it is there as shown in the below:
> {noformat}
> root@nat-d7-0629-hs2-12-rangeroff-3:~# ls -l /etc/hive/conf/conf.server/
> total 56
> -rw-r--r-- 1 hive hadoop  1535 Jun 29 13:52 
> hadoop-metrics2-hivemetastore.properties
> -rw-r--r-- 1 hive hadoop  1533 Jun 29 13:54 
> hadoop-metrics2-hiveserver2.properties
> -rw-r--r-- 1 hive hadoop 0 Jun 29 13:52 hive-default.xml.template
> -rw-r--r-- 1 hive hadoop  2077 Jun 29 13:54 hive-env.sh
> -rw-r--r-- 1 hive hadoop 0 Jun 29 13:52 hive-env.sh.template
> -rw-r--r-- 1 hive hadoop  2652 Jun 29 13:52 hive-exec-log4j.properties
> -rw-r--r-- 1 hive hadoop  3050 Jun 29 13:52 hive-log4j.properties
> -rw-r--r-- 1 hive hadoop   563 Jun 29 13:52 hivemetastore-site.xml
> -rw-r--r-- 1 hive hadoop   677 Jun 29 13:54 hiveserver2-site.xml
> -rw-r--r-- 1 hive hadoop 20362 Jun 29 13:52 hive-site.xml
> -rw-r--r-- 1 hive hadoop  7391 Jun 29 13:52 mapred-site.xml
> {noformat}
> And its content is:
> {noformat}
>   
> 
>   hive.metastore.metrics.enabled
>   true
> 
> 
>   hive.security.authorization.enabled
>   false
> 
> 
>   hive.service.metrics.file.location
>   /var/log/hive/hiveserver2-report.json
> 
> 
>   hive.service.metrics.hadoop2.component
>   hiveserver2
> 
> 
>   hive.service.metrics.reporter
>   JSON_FILE, JMX, HADOOP2
> 
>   
> {noformat}



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

[jira] [Created] (AMBARI-17667) Storm 1.0 Does Not Support Rolling Upgrades

[Jonathan Hurley (JIRA)]

Jonathan Hurley created AMBARI-17667:


 Summary: Storm 1.0 Does Not Support Rolling Upgrades
 Key: AMBARI-17667
 URL: https://issues.apache.org/jira/browse/AMBARI-17667
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.4.0
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
Priority: Blocker
 Fix For: 2.4.0


HDP 2.5 includes a new version of Storm where packages named {{backtype.storm}} 
were changed to {{org.apache.storm}}. As a result, Storm local data is not 
compatible between versions earlier versions of HDP and HDP 2.5. Consider the 
following situatio where Nimbus and a Supervisor are co-located on the same 
host:

- Nimbus deletes local data and restarts on the downgrade version
- A running 2.5 Supervisor on the same host then re-creates that directory and 
puts 2.5 data back in
- When the 2.5 Supervisor goes to downgrade and restart, it can't delete that 
data again since Nimbus is already running and would stop.

When starting the Supevisor, the following error is seen:
{code}
2016-06-21 23:10:48.000 o.a.s.c.f.s.ConnectionStateManager [INFO] State change: 
CONNECTED
2016-06-21 23:10:48.058 b.s.d.supervisor [INFO] Starting supervisor with id 
03d8bceb-0271-4076-810d-04aeaa91533c at host 
nat-os-r6-omns-dgm10toeriedwngdha-r6-2.openstacklocal
2016-06-21 23:10:48.785 b.s.event [ERROR] Error when processing event
java.lang.RuntimeException: java.lang.ClassNotFoundException: 
org.apache.storm.generated.LSSupervisorAssignments
at backtype.storm.utils.LocalState.deserialize(LocalState.java:83) 
~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
at backtype.storm.utils.LocalState.get(LocalState.java:130) 
~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
at 
backtype.storm.local_state$ls_local_assignments.invoke(local_state.clj:83) 
~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
at 
backtype.storm.daemon.supervisor$sync_processes.invoke(supervisor.clj:323) 
~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
at clojure.lang.AFn.applyToHelper(AFn.java:154) ~[clojure-1.6.0.jar:?]
at clojure.lang.AFn.applyTo(AFn.java:144) ~[clojure-1.6.0.jar:?]
at clojure.core$apply.invoke(core.clj:626) ~[clojure-1.6.0.jar:?]
at clojure.core$partial$fn__4228.doInvoke(core.clj:2468) 
~[clojure-1.6.0.jar:?]
at clojure.lang.RestFn.invoke(RestFn.java:397) ~[clojure-1.6.0.jar:?]
at backtype.storm.event$event_manager$fn__6135.invoke(event.clj:40) 
[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
at clojure.lang.AFn.run(AFn.java:22) [clojure-1.6.0.jar:?]
at java.lang.Thread.run(Thread.java:745) [?:1.7.0_67]
Caused by: java.lang.ClassNotFoundException: 
org.apache.storm.generated.LSSupervisorAssignments
at java.net.URLClassLoader$1.run(URLClassLoader.java:366) ~[?:1.7.0_67]
at java.net.URLClassLoader$1.run(URLClassLoader.java:355) ~[?:1.7.0_67]
at java.security.AccessController.doPrivileged(Native Method) 
~[?:1.7.0_67]
at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 
~[?:1.7.0_67]
at java.lang.ClassLoader.loadClass(ClassLoader.java:425) ~[?:1.7.0_67]
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
~[?:1.7.0_67]
at java.lang.ClassLoader.loadClass(ClassLoader.java:358) ~[?:1.7.0_67]
at java.lang.Class.forName0(Native Method) ~[?:1.7.0_67]
at java.lang.Class.forName(Class.java:190) ~[?:1.7.0_67]
at backtype.storm.utils.LocalState.deserialize(LocalState.java:78) 
~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
{code}



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

[jira] [Updated] (AMBARI-17660) EU Downgrade Does Not Stop Services

[Jonathan Hurley (JIRA)]

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

Jonathan Hurley updated AMBARI-17660:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> EU Downgrade Does Not Stop Services
> ---
>
> Key: AMBARI-17660
> URL: https://issues.apache.org/jira/browse/AMBARI-17660
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17660.patch
>
>
> When downgrading an express upgrade, the orchestration of the downgrade does 
> not perform the same steps as the upgrade did. Namely, the stopping of high- 
> and low-level services is not present. This leads to a scenario like this:
> - Upgrade HDP 2.x to 2.y
> -- Stop Storm
> -- Stop ZK
> -- Update Stack to 2.y
> -- Restart ZK on 2.y
> -- Restart Storm on 2.y
> - Downgrade  HDP 2.y to 2.x
> -- Update Stack to 2.x
> -- Restart ZK on 2.x
> -- Restart Storm on 2.x
> Notice that we didn't stop the running services. This leads to a problem 
> where actions which must take place while services are down can't complete 
> successfully.
> The case in point is Storm. Between HDP 2.4 and HDP 2.5, Storm changed the 
> name of a serialized class. Part of the Storm upgrade/downgrade is to always 
> delete local storm data. However, during an EU, if Nimbus and Supervisor are 
> co-located on the same host, Supervisor will write out 2.5 data since it 
> wasn't shut down. Consider:
> - Nimbus deletes local data and restarts on the downgrade version
> - A running 2.5 Supervisor on the same host then re-creates that directory 
> and puts 2.5 data back in
> - When the 2.5 Supervisor goes to downgrade and restart, it can't delete that 
> data again since Nimbus is already running and would stop.
> For this reason, we should always ensure that services are stopped on the 
> downgrade for an EU. 



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

[jira] [Commented] (AMBARI-17587) Handle post ambari upgrade scenario for real names of jdbc jar file[Ranger]

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17587:
-

SUCCESS: Integrated in Ambari-trunk-Commit #5274 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5274/])
Revert "AMBARI-17587. Handle post ambari upgrade scenario for real names 
(jluniya: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=9e8d297348f11c54a68917ed452caadc656b43f2])
* 
ambari-server/src/main/resources/stacks/HDP/2.5/services/ATLAS/configuration/ranger-atlas-audit.xml
* 
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/configuration/kms-properties.xml
* 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/configuration/admin-properties.xml


> Handle post ambari upgrade scenario for real names of jdbc jar file[Ranger]
> ---
>
> Key: AMBARI-17587
> URL: https://issues.apache.org/jira/browse/AMBARI-17587
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0
>
> Attachments: AMBARI-17587.patch
>
>
> Post Ambari upgrade nothing should break for Ranger and Ranger Plugin after  
> implementation of AMBARI-15628.



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

[jira] [Updated] (AMBARI-17663) Hosts page: JS error when sorting

[Richard Zang (JIRA)]

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

Richard Zang updated AMBARI-17663:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to trunk 624fb1c84d1be33b5c4c9d93293a7aa9717edfcc

> Hosts page: JS error when sorting
> -
>
> Key: AMBARI-17663
> URL: https://issues.apache.org/jira/browse/AMBARI-17663
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.5.0
>
> Attachments: AMBARI-17663.patch
>
>
> Go to Hosts page and try sort by any column.
> JS error: 
> {noformat}
> Uncaught TypeError: wrapperView.removeSortingObserver is not a function
> {noformat}
> Although sorting works fine.



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

[jira] [Updated] (AMBARI-17663) Hosts page: JS error when sorting

[Richard Zang (JIRA)]

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

Richard Zang updated AMBARI-17663:
--
Status: Patch Available  (was: Open)

> Hosts page: JS error when sorting
> -
>
> Key: AMBARI-17663
> URL: https://issues.apache.org/jira/browse/AMBARI-17663
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.5.0
>
> Attachments: AMBARI-17663.patch
>
>
> Go to Hosts page and try sort by any column.
> JS error: 
> {noformat}
> Uncaught TypeError: wrapperView.removeSortingObserver is not a function
> {noformat}
> Although sorting works fine.



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

[jira] [Updated] (AMBARI-17663) Hosts page: JS error when sorting

[Richard Zang (JIRA)]

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

Richard Zang updated AMBARI-17663:
--
Attachment: AMBARI-17663.patch

> Hosts page: JS error when sorting
> -
>
> Key: AMBARI-17663
> URL: https://issues.apache.org/jira/browse/AMBARI-17663
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.5.0
>
> Attachments: AMBARI-17663.patch
>
>
> Go to Hosts page and try sort by any column.
> JS error: 
> {noformat}
> Uncaught TypeError: wrapperView.removeSortingObserver is not a function
> {noformat}
> Although sorting works fine.



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

[jira] [Commented] (AMBARI-17640) Storm Ambari View should provide a config page & make calls to Storm Rest API

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-17640:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12817298/0001-Updated-storm-view-with-cors-support-and-search-logs.patch
  against trunk revision .

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

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

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

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

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

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

This message is automatically generated.

> Storm Ambari View should provide a config page & make calls to Storm Rest API
> -
>
> Key: AMBARI-17640
> URL: https://issues.apache.org/jira/browse/AMBARI-17640
> Project: Ambari
>  Issue Type: Improvement
>Reporter: Sriharsha Chintalapani
>Assignee: Sriharsha Chintalapani
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: 
> 0001-Updated-storm-view-with-cors-support-and-search-logs.patch
>
>
> 1. Config page to add storm UI REST API server
> 2. Make storm view to call UI Rest API directly instead of going through 
> ambari server.
> 3. Additional small fixes.



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

[jira] [Updated] (AMBARI-17285) Custom service repos in repoinfo.xml got overwritten by public VDFs

[Sumit Mohanty (JIRA)]

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

Sumit Mohanty updated AMBARI-17285:
---
Assignee: Nate Cole

> Custom service repos in repoinfo.xml got overwritten by public VDFs
> ---
>
> Key: AMBARI-17285
> URL: https://issues.apache.org/jira/browse/AMBARI-17285
> Project: Ambari
>  Issue Type: Bug
>Reporter: Alexander Denissov
>Assignee: Nate Cole
>Priority: Critical
> Fix For: 2.4.0
>
>
> Ambari 2.4 introduced Version Definition Files that break the functionality 
> of adding a custom service repo, since custom services do not have an entry 
> in the public VDF.
> In the case of HAWQ, the plugin is installed on Ambari host and it adds the 
> new repo information to the repoinfo.xml of all available stacks on the file 
> system. Once Ambari cluster creation wizard queries the latest repo info from 
> the public URLs, it will get the info for all stack repos, but not the custom 
> ones. 
> So, the logic should be:
> 1. Use default repoinfo (from file system) as the base
> 2. Query public VDF, if available
> 3. For each entry in public VDF overwrite values in the default repoinfo
> 4. Entries in default repoinfo that do not have corresponding entries in VDF 
> should stay intact
> This way custom services can be added via file edit and the latest 
> information can still be retrieved and applied for the standard stack.



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

[jira] [Updated] (AMBARI-17666) Ambari agent can't start when TLSv1 is disabled in Java security

[Tuong Truong (JIRA)]

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

Tuong Truong updated AMBARI-17666:
--
Labels: security  (was: )

> Ambari agent can't start when TLSv1 is disabled in Java security
> 
>
> Key: AMBARI-17666
> URL: https://issues.apache.org/jira/browse/AMBARI-17666
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: 2.2.0
>Reporter: Tuong Truong
>  Labels: security
>
> Currently, the commit for https://issues.apache.org/jira/browse/AMBARI-14236 
> explicit force the SSL protocol to TLSv1 in  
> ambari-agent/src/main/python/ambari_agent/alerts/web_alert.py.  Unfortunate, 
> this setting in effect whenever web_alert pacackged is loaded 
> (ambari-agent/src/main/python/ambari_agent/AlertSchedulerHandler.py) 
> regardless whether ssl is used or not. 
> As a result, disabling TLSv1 in Ambari server will cause the agent to fail to 
> start.
> Recreate:
> In Ambari's acitve JDK on Ambari server node, in java.security file, set 
> jdk.tls.disabledAlgorithms=MD5, SSLv2, SSLv3, TLSv1, DSA, RC4, RSA keySize < 
> 2048
> restart ambari-server, and you will see errors in ambari agent logs:
> ERROR 2016-07-11 15:11:15,269 NetUtil.py:84 - [Errno 8] _ssl.c:492: EOF 
> occurred in violation of protocol
> ERROR 2016-07-11 15:11:15,269 NetUtil.py:85 - SSLError: Failed to connect. 
> Please check openssl library versions.
> Refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1022468 for more 
> details.



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

[jira] [Updated] (AMBARI-17666) Ambari agent can't start when TLSv1 is disabled in Java security

[Tuong Truong (JIRA)]

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

Tuong Truong updated AMBARI-17666:
--
Description: 
Currently, the commit for https://issues.apache.org/jira/browse/AMBARI-14236 
explicit force the SSL protocol to TLSv1 in  
ambari-agent/src/main/python/ambari_agent/alerts/web_alert.py.  Unfortunate, 
this setting in effect whenever web_alert pacackged is loaded 
(ambari-agent/src/main/python/ambari_agent/AlertSchedulerHandler.py) regardless 
whether ssl is used or not. 

As a result, disabling TLSv1 in Ambari server will cause the agent to fail to 
start.

Recreate:

In Ambari's acitve JDK on Ambari server node, in java.security file, set 
jdk.tls.disabledAlgorithms=MD5, SSLv2, SSLv3, TLSv1, DSA, RC4, RSA keySize < 
2048
restart ambari-server, and you will see errors in ambari agent logs:

ERROR 2016-07-11 15:11:15,269 NetUtil.py:84 - [Errno 8] _ssl.c:492: EOF 
occurred in violation of protocol
ERROR 2016-07-11 15:11:15,269 NetUtil.py:85 - SSLError: Failed to connect. 
Please check openssl library versions.
Refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1022468 for more details.

  was:
Currently, the commit for https://issues.apache.org/jira/browse/AMBARI-14236 
explicit force the SSL protocol to TLSv1 in  
ambari-agent/src/main/python/ambari_agent/alerts/web_alert.py.  Unfortunate, 
this setting in effect whenever web_alert pacackged is loaded 
(ambari-agent/src/main/python/ambari_agent/AlertSchedulerHandler.py) regardless 
whether ssl is used or not. 

As a result, disabling TLSv1 in Ambari server will cause the agent to fail to 
start.




> Ambari agent can't start when TLSv1 is disabled in Java security
> 
>
> Key: AMBARI-17666
> URL: https://issues.apache.org/jira/browse/AMBARI-17666
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: 2.2.0
>Reporter: Tuong Truong
>
> Currently, the commit for https://issues.apache.org/jira/browse/AMBARI-14236 
> explicit force the SSL protocol to TLSv1 in  
> ambari-agent/src/main/python/ambari_agent/alerts/web_alert.py.  Unfortunate, 
> this setting in effect whenever web_alert pacackged is loaded 
> (ambari-agent/src/main/python/ambari_agent/AlertSchedulerHandler.py) 
> regardless whether ssl is used or not. 
> As a result, disabling TLSv1 in Ambari server will cause the agent to fail to 
> start.
> Recreate:
> In Ambari's acitve JDK on Ambari server node, in java.security file, set 
> jdk.tls.disabledAlgorithms=MD5, SSLv2, SSLv3, TLSv1, DSA, RC4, RSA keySize < 
> 2048
> restart ambari-server, and you will see errors in ambari agent logs:
> ERROR 2016-07-11 15:11:15,269 NetUtil.py:84 - [Errno 8] _ssl.c:492: EOF 
> occurred in violation of protocol
> ERROR 2016-07-11 15:11:15,269 NetUtil.py:85 - SSLError: Failed to connect. 
> Please check openssl library versions.
> Refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1022468 for more 
> details.



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

[jira] [Created] (AMBARI-17666) Ambari agent can't start when TLSv1 is disabled in Java security

[Tuong Truong (JIRA)]

Tuong Truong created AMBARI-17666:
-

 Summary: Ambari agent can't start when TLSv1 is disabled in Java 
security
 Key: AMBARI-17666
 URL: https://issues.apache.org/jira/browse/AMBARI-17666
 Project: Ambari
  Issue Type: Bug
  Components: ambari-agent
Affects Versions: 2.2.0
Reporter: Tuong Truong


Currently, the commit for https://issues.apache.org/jira/browse/AMBARI-14236 
explicit force the SSL protocol to TLSv1 in  
ambari-agent/src/main/python/ambari_agent/alerts/web_alert.py.  Unfortunate, 
this setting in effect whenever web_alert pacackged is loaded 
(ambari-agent/src/main/python/ambari_agent/AlertSchedulerHandler.py) regardless 
whether ssl is used or not. 

As a result, disabling TLSv1 in Ambari server will cause the agent to fail to 
start.





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

[jira] [Updated] (AMBARI-17640) Storm Ambari View should provide a config page & make calls to Storm Rest API

[Sriharsha Chintalapani (JIRA)]

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

Sriharsha Chintalapani updated AMBARI-17640:

Status: Patch Available  (was: Open)

> Storm Ambari View should provide a config page & make calls to Storm Rest API
> -
>
> Key: AMBARI-17640
> URL: https://issues.apache.org/jira/browse/AMBARI-17640
> Project: Ambari
>  Issue Type: Improvement
>Reporter: Sriharsha Chintalapani
>Assignee: Sriharsha Chintalapani
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: 
> 0001-Updated-storm-view-with-cors-support-and-search-logs.patch
>
>
> 1. Config page to add storm UI REST API server
> 2. Make storm view to call UI Rest API directly instead of going through 
> ambari server.
> 3. Additional small fixes.



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

[jira] [Updated] (AMBARI-17640) Storm Ambari View should provide a config page & make calls to Storm Rest API

[Sriharsha Chintalapani (JIRA)]

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

Sriharsha Chintalapani updated AMBARI-17640:

Attachment: 0001-Updated-storm-view-with-cors-support-and-search-logs.patch

> Storm Ambari View should provide a config page & make calls to Storm Rest API
> -
>
> Key: AMBARI-17640
> URL: https://issues.apache.org/jira/browse/AMBARI-17640
> Project: Ambari
>  Issue Type: Improvement
>Reporter: Sriharsha Chintalapani
>Assignee: Sriharsha Chintalapani
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: 
> 0001-Updated-storm-view-with-cors-support-and-search-logs.patch
>
>
> 1. Config page to add storm UI REST API server
> 2. Make storm view to call UI Rest API directly instead of going through 
> ambari server.
> 3. Additional small fixes.



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

[jira] [Commented] (AMBARI-17664) ServicePropertiesTest.validatePropertySchemaOfServiceXMLs unit test failure

[Jayush Luniya (JIRA)]

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

Jayush Luniya commented on AMBARI-17664:


cc: [~vperiasamy] [~gautamborad] [~u39kun]
I backed out the commits for AMBARI-17587.


> ServicePropertiesTest.validatePropertySchemaOfServiceXMLs unit test failure
> ---
>
> Key: AMBARI-17664
> URL: https://issues.apache.org/jira/browse/AMBARI-17664
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.0
>Reporter: Jayush Luniya
>Assignee: Gautam Borad
>Priority: Blocker
> Fix For: 2.4.0
>
>
> Following commit introduced unit test failures.
> Commit 79d76898b9a880f20910770029747dc8fe3fbc09 by sgunturi
> AMBARI-17587. Handle post ambari upgrade scenario for real names of jdbc jar 
> file [Ranger] (Gautam Borad via srimanth)
> https://builds.apache.org/job/Ambari-trunk-Commit/5250/testReport/org.apache.ambari.server.state/ServicePropertiesTest/validatePropertySchemaOfServiceXMLs/
>  
> org.apache.ambari.server.state.ServicePropertiesTest.validatePropertySchemaOfServiceXMLs
> Failing for the past 1 build (Since Failed#5250 )
> Took 0.49 sec.
> Error Message
> File 
> /home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-server/target/test-classes/TestAmbaryServer.samples/../../../src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/configuration/kms-properties.xml
>  didn't pass the validation. Error message is : cvc-complex-type.3.2.2: 
> Attribute 'update' is not allowed to appear in element 'on-ambari-upgrade'.
> Stacktrace
> org.apache.ambari.server.AmbariException: File 
> /home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-server/target/test-classes/TestAmbaryServer.samples/../../../src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/configuration/kms-properties.xml
>  didn't pass the validation. Error message is : cvc-complex-type.3.2.2: 
> Attribute 'update' is not allowed to appear in element 'on-ambari-upgrade'.
>   at 
> org.apache.ambari.server.state.ServicePropertiesTest.validatePropertySchemaOfServiceXMLs(ServicePropertiesTest.java:48)
> Standard Output
> 2016-07-07 22:00:46,592 ERROR [main] stack.StackManager 
> (StackManager.java:validateAllPropertyXmlsInFolderRecursively(451)) - File 
> /home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-server/target/test-classes/TestAmbaryServer.samples/../../../src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/configuration/kms-properties.xml
>  didn't pass the validation. Error message is : cvc-complex-type.3.2.2: 
> Attribute 'update' is not allowed to appear in element 'on-ambari-upgrade’.



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

[jira] [Reopened] (AMBARI-17587) Handle post ambari upgrade scenario for real names of jdbc jar file[Ranger]

[Jayush Luniya (JIRA)]

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

Jayush Luniya reopened AMBARI-17587:


> Handle post ambari upgrade scenario for real names of jdbc jar file[Ranger]
> ---
>
> Key: AMBARI-17587
> URL: https://issues.apache.org/jira/browse/AMBARI-17587
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0
>
> Attachments: AMBARI-17587.patch
>
>
> Post Ambari upgrade nothing should break for Ranger and Ranger Plugin after  
> implementation of AMBARI-15628.



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

[jira] [Updated] (AMBARI-17665) Fix the typo in 'alert_hive_interactive_thrift_port.py' for 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required extra '-' for 'findAppTimeout' para

[Swapan Shridhar (JIRA)]

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

Swapan Shridhar updated AMBARI-17665:
-
Description: 
- Current value : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
'{{hive.server2.transport.mode/hive.server2.authentication}}'
  *Fixed to :* HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
'{{hive-site/hive.server2.authentication}}'

- Added the required extra '-' for  'findAppTimeout' param in llapstatus 
comamnd.

  was:
- Current value : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
'{{hive.server2.transport.mode/hive.server2.authentication}}'
  Fixed to : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
'{{hive-site/hive.server2.authentication}}'

- Added the required extra '-' for  'findAppTimeout' param in llapstatus 
comamnd.


> Fix the typo in 'alert_hive_interactive_thrift_port.py' for 
> 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required 
> extra '-' for 'findAppTimeout' param in llapstatus comamnd.
> 
>
> Key: AMBARI-17665
> URL: https://issues.apache.org/jira/browse/AMBARI-17665
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.4.0
>
>
> - Current value : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
> '{{hive.server2.transport.mode/hive.server2.authentication}}'
>   *Fixed to :* HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
> '{{hive-site/hive.server2.authentication}}'
> - Added the required extra '-' for  'findAppTimeout' param in llapstatus 
> comamnd.



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

[jira] [Updated] (AMBARI-17665) Fix the typo in 'alert_hive_interactive_thrift_port.py' for 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required extra '-' for 'findAppTimeout' para

[Swapan Shridhar (JIRA)]

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

Swapan Shridhar updated AMBARI-17665:
-
Description: 
- Current value : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
'{{hive.server2.transport.mode/hive.server2.authentication}}'
  Fixed to : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
'{{hive-site/hive.server2.authentication}}'

- Added the required extra '-' for  'findAppTimeout' param in llapstatus 
comamnd.

  was:
- Current value : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
'{{hive.server2.transport.mode/hive.server2.authentication}}'
  Fixed to : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
'{{hive-site/hive.server2.authentication}}'

- Added the required extra '-' for 


> Fix the typo in 'alert_hive_interactive_thrift_port.py' for 
> 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required 
> extra '-' for 'findAppTimeout' param in llapstatus comamnd.
> 
>
> Key: AMBARI-17665
> URL: https://issues.apache.org/jira/browse/AMBARI-17665
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.4.0
>
>
> - Current value : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
> '{{hive.server2.transport.mode/hive.server2.authentication}}'
>   Fixed to : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
> '{{hive-site/hive.server2.authentication}}'
> - Added the required extra '-' for  'findAppTimeout' param in llapstatus 
> comamnd.



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

[jira] [Updated] (AMBARI-17665) Fix the typo in 'alert_hive_interactive_thrift_port.py' for 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required extra '-' for 'findAppTimeout' para

[Swapan Shridhar (JIRA)]

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

Swapan Shridhar updated AMBARI-17665:
-
Description: 
- Current value : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
'{{hive.server2.transport.mode/hive.server2.authentication}}'
  Fixed to : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
'{{hive-site/hive.server2.authentication}}'

- Added the required extra '-' for 

> Fix the typo in 'alert_hive_interactive_thrift_port.py' for 
> 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required 
> extra '-' for 'findAppTimeout' param in llapstatus comamnd.
> 
>
> Key: AMBARI-17665
> URL: https://issues.apache.org/jira/browse/AMBARI-17665
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.4.0
>
>
> - Current value : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
> '{{hive.server2.transport.mode/hive.server2.authentication}}'
>   Fixed to : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY = 
> '{{hive-site/hive.server2.authentication}}'
> - Added the required extra '-' for 



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

[jira] [Created] (AMBARI-17665) Fix the typo in 'alert_hive_interactive_thrift_port.py' for 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required extra '-' for 'findAppTimeout' para

[Swapan Shridhar (JIRA)]

Swapan Shridhar created AMBARI-17665:


 Summary: Fix the typo in 'alert_hive_interactive_thrift_port.py' 
for 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required 
extra '-' for 'findAppTimeout' param in llapstatus comamnd.
 Key: AMBARI-17665
 URL: https://issues.apache.org/jira/browse/AMBARI-17665
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.4.0
Reporter: Swapan Shridhar
Assignee: Swapan Shridhar
 Fix For: 2.4.0






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

[jira] [Created] (AMBARI-17664) ServicePropertiesTest.validatePropertySchemaOfServiceXMLs unit test failure

[Jayush Luniya (JIRA)]

Jayush Luniya created AMBARI-17664:
--

 Summary: ServicePropertiesTest.validatePropertySchemaOfServiceXMLs 
unit test failure
 Key: AMBARI-17664
 URL: https://issues.apache.org/jira/browse/AMBARI-17664
 Project: Ambari
  Issue Type: Bug
  Components: stacks
Affects Versions: 2.4.0
Reporter: Jayush Luniya
Assignee: Gautam Borad
Priority: Blocker
 Fix For: 2.4.0


Following commit introduced unit test failures.

Commit 79d76898b9a880f20910770029747dc8fe3fbc09 by sgunturi
AMBARI-17587. Handle post ambari upgrade scenario for real names of jdbc jar 
file [Ranger] (Gautam Borad via srimanth)

https://builds.apache.org/job/Ambari-trunk-Commit/5250/testReport/org.apache.ambari.server.state/ServicePropertiesTest/validatePropertySchemaOfServiceXMLs/
 

org.apache.ambari.server.state.ServicePropertiesTest.validatePropertySchemaOfServiceXMLs
Failing for the past 1 build (Since Failed#5250 )
Took 0.49 sec.
Error Message

File 
/home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-server/target/test-classes/TestAmbaryServer.samples/../../../src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/configuration/kms-properties.xml
 didn't pass the validation. Error message is : cvc-complex-type.3.2.2: 
Attribute 'update' is not allowed to appear in element 'on-ambari-upgrade'.
Stacktrace

org.apache.ambari.server.AmbariException: File 
/home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-server/target/test-classes/TestAmbaryServer.samples/../../../src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/configuration/kms-properties.xml
 didn't pass the validation. Error message is : cvc-complex-type.3.2.2: 
Attribute 'update' is not allowed to appear in element 'on-ambari-upgrade'.
at 
org.apache.ambari.server.state.ServicePropertiesTest.validatePropertySchemaOfServiceXMLs(ServicePropertiesTest.java:48)
Standard Output

2016-07-07 22:00:46,592 ERROR [main] stack.StackManager 
(StackManager.java:validateAllPropertyXmlsInFolderRecursively(451)) - File 
/home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-server/target/test-classes/TestAmbaryServer.samples/../../../src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/configuration/kms-properties.xml
 didn't pass the validation. Error message is : cvc-complex-type.3.2.2: 
Attribute 'update' is not allowed to appear in element 'on-ambari-upgrade’.



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

[jira] [Updated] (AMBARI-17285) Custom service repos in repoinfo.xml got overwritten by public VDFs

[Jayush Luniya (JIRA)]

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

Jayush Luniya updated AMBARI-17285:
---
Priority: Critical  (was: Major)

> Custom service repos in repoinfo.xml got overwritten by public VDFs
> ---
>
> Key: AMBARI-17285
> URL: https://issues.apache.org/jira/browse/AMBARI-17285
> Project: Ambari
>  Issue Type: Bug
>Reporter: Alexander Denissov
>Priority: Critical
> Fix For: 2.4.0
>
>
> Ambari 2.4 introduced Version Definition Files that break the functionality 
> of adding a custom service repo, since custom services do not have an entry 
> in the public VDF.
> In the case of HAWQ, the plugin is installed on Ambari host and it adds the 
> new repo information to the repoinfo.xml of all available stacks on the file 
> system. Once Ambari cluster creation wizard queries the latest repo info from 
> the public URLs, it will get the info for all stack repos, but not the custom 
> ones. 
> So, the logic should be:
> 1. Use default repoinfo (from file system) as the base
> 2. Query public VDF, if available
> 3. For each entry in public VDF overwrite values in the default repoinfo
> 4. Entries in default repoinfo that do not have corresponding entries in VDF 
> should stay intact
> This way custom services can be added via file edit and the latest 
> information can still be retrieved and applied for the standard stack.



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

[jira] [Commented] (AMBARI-17285) Custom service repos in repoinfo.xml got overwritten by public VDFs

[Jayush Luniya (JIRA)]

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

Jayush Luniya commented on AMBARI-17285:


[~adenisso]
 Yes this was part of a blanket move of JIRAs that are not blockers/critical to 
2.5.0. 

I will move this JIRA back to 2.4.0. 

Also as we discussed during the meetup, I am following up on this with the team 
for a solution for this issue. Stay tuned :) 



> Custom service repos in repoinfo.xml got overwritten by public VDFs
> ---
>
> Key: AMBARI-17285
> URL: https://issues.apache.org/jira/browse/AMBARI-17285
> Project: Ambari
>  Issue Type: Bug
>Reporter: Alexander Denissov
> Fix For: 2.4.0
>
>
> Ambari 2.4 introduced Version Definition Files that break the functionality 
> of adding a custom service repo, since custom services do not have an entry 
> in the public VDF.
> In the case of HAWQ, the plugin is installed on Ambari host and it adds the 
> new repo information to the repoinfo.xml of all available stacks on the file 
> system. Once Ambari cluster creation wizard queries the latest repo info from 
> the public URLs, it will get the info for all stack repos, but not the custom 
> ones. 
> So, the logic should be:
> 1. Use default repoinfo (from file system) as the base
> 2. Query public VDF, if available
> 3. For each entry in public VDF overwrite values in the default repoinfo
> 4. Entries in default repoinfo that do not have corresponding entries in VDF 
> should stay intact
> This way custom services can be added via file edit and the latest 
> information can still be retrieved and applied for the standard stack.



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

[jira] [Updated] (AMBARI-17285) Custom service repos in repoinfo.xml got overwritten by public VDFs

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-17285:
-
Fix Version/s: (was: 2.5.0)
   2.4.0

> Custom service repos in repoinfo.xml got overwritten by public VDFs
> ---
>
> Key: AMBARI-17285
> URL: https://issues.apache.org/jira/browse/AMBARI-17285
> Project: Ambari
>  Issue Type: Bug
>Reporter: Alexander Denissov
> Fix For: 2.4.0
>
>
> Ambari 2.4 introduced Version Definition Files that break the functionality 
> of adding a custom service repo, since custom services do not have an entry 
> in the public VDF.
> In the case of HAWQ, the plugin is installed on Ambari host and it adds the 
> new repo information to the repoinfo.xml of all available stacks on the file 
> system. Once Ambari cluster creation wizard queries the latest repo info from 
> the public URLs, it will get the info for all stack repos, but not the custom 
> ones. 
> So, the logic should be:
> 1. Use default repoinfo (from file system) as the base
> 2. Query public VDF, if available
> 3. For each entry in public VDF overwrite values in the default repoinfo
> 4. Entries in default repoinfo that do not have corresponding entries in VDF 
> should stay intact
> This way custom services can be added via file edit and the latest 
> information can still be retrieved and applied for the standard stack.



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

[jira] [Commented] (AMBARI-17285) Custom service repos in repoinfo.xml got overwritten by public VDFs

[Yusaku Sako (JIRA)]

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

Yusaku Sako commented on AMBARI-17285:
--

[~adenisso], I think the move to 2.5.0 was a result of bulk move that 
[~jluniya] did.
Let's discuss and come up with an acceptable solution that would work for non 
HDP stacks.

> Custom service repos in repoinfo.xml got overwritten by public VDFs
> ---
>
> Key: AMBARI-17285
> URL: https://issues.apache.org/jira/browse/AMBARI-17285
> Project: Ambari
>  Issue Type: Bug
>Reporter: Alexander Denissov
> Fix For: 2.4.0
>
>
> Ambari 2.4 introduced Version Definition Files that break the functionality 
> of adding a custom service repo, since custom services do not have an entry 
> in the public VDF.
> In the case of HAWQ, the plugin is installed on Ambari host and it adds the 
> new repo information to the repoinfo.xml of all available stacks on the file 
> system. Once Ambari cluster creation wizard queries the latest repo info from 
> the public URLs, it will get the info for all stack repos, but not the custom 
> ones. 
> So, the logic should be:
> 1. Use default repoinfo (from file system) as the base
> 2. Query public VDF, if available
> 3. For each entry in public VDF overwrite values in the default repoinfo
> 4. Entries in default repoinfo that do not have corresponding entries in VDF 
> should stay intact
> This way custom services can be added via file edit and the latest 
> information can still be retrieved and applied for the standard stack.



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

[jira] [Commented] (AMBARI-17285) Custom service repos in repoinfo.xml got overwritten by public VDFs

[Alexander Denissov (JIRA)]

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

Alexander Denissov commented on AMBARI-17285:
-

[~jluniya] -- I noticed this issue has been moved out of 2.4 release, which 
presents a problem for HAWQ / PXF services. Was there a specific reason for 
this decision ?

This is a functional regression from the previous releases and without this 
feature the user experience of new cluster installation with HAWQ / PXF becomes 
very cumbersome, because:
- if we add HDB repo to stack's repoinfo.xml as before, it will only show up in 
the "default" configuration and users will not be able to get the latest stack 
maintenance release without manually overriding the URL there.
- if the user chooses "latest" version, there is no way to specify a custom 
repo there, so they are not able to install HAWQ / PXF.

If we create our own VDF file, we can only do this statically before Ambari 
release, in which case the stack version will not be the latest by the time 
users are installing their stacks, correct ? In custom VDFs, does Ambari go 
check for the latest stack updates ?

Asking users to generate VDFs dynamically before cluster installation would 
introduce complexity and is error-prone.

We are out of user-friendly options without this issue being fixed and I don't 
know how a statically defined custom VDF would allow users to install the 
latest HDP stack at the time of install.

> Custom service repos in repoinfo.xml got overwritten by public VDFs
> ---
>
> Key: AMBARI-17285
> URL: https://issues.apache.org/jira/browse/AMBARI-17285
> Project: Ambari
>  Issue Type: Bug
>Reporter: Alexander Denissov
> Fix For: 2.5.0
>
>
> Ambari 2.4 introduced Version Definition Files that break the functionality 
> of adding a custom service repo, since custom services do not have an entry 
> in the public VDF.
> In the case of HAWQ, the plugin is installed on Ambari host and it adds the 
> new repo information to the repoinfo.xml of all available stacks on the file 
> system. Once Ambari cluster creation wizard queries the latest repo info from 
> the public URLs, it will get the info for all stack repos, but not the custom 
> ones. 
> So, the logic should be:
> 1. Use default repoinfo (from file system) as the base
> 2. Query public VDF, if available
> 3. For each entry in public VDF overwrite values in the default repoinfo
> 4. Entries in default repoinfo that do not have corresponding entries in VDF 
> should stay intact
> This way custom services can be added via file edit and the latest 
> information can still be retrieved and applied for the standard stack.



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

[jira] [Commented] (AMBARI-17241) Services should be able to reload configs without requiring restart

[Arpit Agarwal (JIRA)]

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

Arpit Agarwal commented on AMBARI-17241:


Hi [~mithmatt] I like the idea of Ambari supporting restart-less configuration 
changes.

This may be a naive question but how will Ambari communicate the configuration 
change to the service when restart is not required? I missed that from a quick 
look at the doc.

Also is the supports-reload or restart-required parameter expected to be 
configured by the administrator? That could be error prone.

> Services should be able to reload configs without requiring restart
> ---
>
> Key: AMBARI-17241
> URL: https://issues.apache.org/jira/browse/AMBARI-17241
> Project: Ambari
>  Issue Type: New Feature
>Reporter: Matt
>Assignee: Matt
>Priority: Minor
> Fix For: trunk
>
> Attachments: AMBARI-17241-Design-Proposal.pdf
>
>
> The current implementation forces users to restart the service if any of the 
> configurations have been updated. 
> However some of the services support reloading the configuration parameters 
> during run-time which does not require restart of the service.
> This behavior should be driven by metadata defined in configuration files.
> {code}
>   
> foo-bar
> 0
> true
>   
> {code}



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

[jira] [Commented] (AMBARI-15321) Alerts : Support in Ambari for hive Server Interactive related Alerts.

[Vaibhav Gumashta (JIRA)]

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

Vaibhav Gumashta commented on AMBARI-15321:
---

This patch has an issue. https://reviews.apache.org/r/44464/diff/1#1 has a typo 
due to which it will cause an issue when HS2 is running in SASL mode.

> Alerts : Support in Ambari for hive Server Interactive related Alerts.
> --
>
> Key: AMBARI-15321
> URL: https://issues.apache.org/jira/browse/AMBARI-15321
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.4.0
>
> Attachments: AMBARI-15321.patch
>
>
> - Adding support for alerts for Hive's component "Hive Server Interactive".
>   - Specific alerts added is for checking Thrift port status.



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

[jira] [Created] (AMBARI-17663) Hosts page: JS error when sorting

[Richard Zang (JIRA)]

Richard Zang created AMBARI-17663:
-

 Summary: Hosts page: JS error when sorting
 Key: AMBARI-17663
 URL: https://issues.apache.org/jira/browse/AMBARI-17663
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.4.0
Reporter: Richard Zang
Assignee: Richard Zang
 Fix For: 2.5.0


Go to Hosts page and try sort by any column.
JS error: 
{noformat}
Uncaught TypeError: wrapperView.removeSortingObserver is not a function
{noformat}

Although sorting works fine.



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

[jira] [Commented] (AMBARI-14236) HDFS and Yarn alerts in https mode when kerberos is disabled

[Tuong Truong (JIRA)]

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

Tuong Truong commented on AMBARI-14236:
---

Hi [~aonishuk], do you have any more background information on this problem 
that you are trying to fix?  This commit is forcing TLSv1 protocol is causing 
an issue with Ambari agent/server communication when we disable TLSv1 and 
TLSv1.1 in Java8.  
In Ambari's acitve JDK,  in java.security file, set 
jdk.tls.disabledAlgorithms=MD5, SSLv2, SSLv3, TLSv1, DSA, RC4, RSA keySize < 
2048
restart ambari-server, and you will see errors in ambari agent logs:

ERROR 2016-07-11 15:11:15,269 NetUtil.py:84 - [Errno 8] _ssl.c:492: EOF 
occurred in violation of protocol
ERROR 2016-07-11 15:11:15,269 NetUtil.py:85 - SSLError: Failed to connect. 
Please check openssl library versions.
Refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1022468 for more details.


> HDFS and Yarn alerts in https mode when kerberos is disabled
> 
>
> Key: AMBARI-14236
> URL: https://issues.apache.org/jira/browse/AMBARI-14236
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.0
>
>
> From NN logs:
> 
> 
> javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled
> at 
> sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:637)
> at sun.security.ssl.InputRecord.read(InputRecord.java:527)
> at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:961)
> at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
> at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
> at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
> at 
> org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:723)
> at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> 
> Please check the live cluster for debugging: 



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

[jira] [Commented] (AMBARI-17661) Support YARN timeline plugin classpath config

[Bikas Saha (JIRA)]

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

Bikas Saha commented on AMBARI-17661:
-

Updated the patch with the fix for the new and existing paths in that file. 
Please review. Updated review board also.

> Support YARN timeline plugin classpath config
> -
>
> Key: AMBARI-17661
> URL: https://issues.apache.org/jira/browse/AMBARI-17661
> Project: Ambari
>  Issue Type: Bug
>Reporter: Bikas Saha
>Assignee: Bikas Saha
> Attachments: AMBARI-17661.1.patch, AMBARI-17661.2.patch
>
>
> YARN-5233 added a config to specify the plugin classpath. Adding support for 
> that config.



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

[jira] [Updated] (AMBARI-17661) Support YARN timeline plugin classpath config

[Bikas Saha (JIRA)]

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

Bikas Saha updated AMBARI-17661:

Attachment: AMBARI-17661.2.patch

> Support YARN timeline plugin classpath config
> -
>
> Key: AMBARI-17661
> URL: https://issues.apache.org/jira/browse/AMBARI-17661
> Project: Ambari
>  Issue Type: Bug
>Reporter: Bikas Saha
>Assignee: Bikas Saha
> Attachments: AMBARI-17661.1.patch, AMBARI-17661.2.patch
>
>
> YARN-5233 added a config to specify the plugin classpath. Adding support for 
> that config.



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

[jira] [Updated] (AMBARI-17253) Ambari Alert causes too many wanings in ZooKeeper logs.

[Masahiro Tanaka (JIRA)]

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

Masahiro Tanaka updated AMBARI-17253:
-
Attachment: AMBARI-17253.6.patch

> Ambari Alert causes too many wanings in ZooKeeper logs.
> ---
>
> Key: AMBARI-17253
> URL: https://issues.apache.org/jira/browse/AMBARI-17253
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: trunk
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
> Attachments: AMBARI-17253.1.patch, AMBARI-17253.2.patch, 
> AMBARI-17253.3.patch, AMBARI-17253.4.patch, AMBARI-17253.5.patch, 
> AMBARI-17253.6.patch, AMBARI-17253.patch
>
>
> There are too many WARNING in ZooKeeper log.
> {code}
> 2016-06-15 21:02:15,405 - WARN  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@357] - caught end of 
> stream exception
> EndOfStreamException: Unable to read additional data from client sessionid 
> 0x0, likely client has closed socket
> at 
> org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:228)
> at 
> org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> It may be because of Ambari Alert. Ambari Alert pings to the zookeeper port 
> to do monitoring.
> We should use 'ruok' to monitor zookeepers.



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

[jira] [Updated] (AMBARI-17662) Atlas HA fails to come up with error finding ids

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-17662:
-
Attachment: (was: AMBARI-17662.branch-2.4.patch)

> Atlas HA fails to come up with error finding ids
> 
>
> Key: AMBARI-17662
> URL: https://issues.apache.org/jira/browse/AMBARI-17662
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.4.0
>
> Attachments: AMBARI-17662.branch-2.4.patch, AMBARI-17662.trunk.patch
>
>
> Deploy multiple Atlas servers and one of them will fail since it will be 
> missing its ids.
> {noformat}
> 2016-06-14 10:48:23,249 WARN  - [main:] ~ Failed startup of context 
> o.e.j.w.WebAppContext@2ad31d76{/,file:/grid/0/hdp/2.5.0.0-723/atlas/server/webapp/atlas/,STARTING}{/usr/hdp/current/atlas-server/server/webapp/atlas}
>  (WebAppContext:514)
> java.lang.RuntimeException: org.apache.atlas.AtlasException: Could not find 
> server id for this instance. Unable to find IDs matching any local host and 
> port binding among id1
> at org.apache.atlas.service.Services.start(Services.java:48)
> at 
> org.apache.atlas.web.listeners.GuiceServletConfig.startServices(GuiceServletConfig.java:142)
> at 
> org.apache.atlas.web.listeners.GuiceServletConfig.contextInitialized(GuiceServletConfig.java:136)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
> at org.eclipse.jetty.server.Server.start(Server.java:387)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> at org.eclipse.jetty.server.Server.doStart(Server.java:354)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.apache.atlas.web.service.EmbeddedServer.start(EmbeddedServer.java:93)
> at org.apache.atlas.Atlas.main(Atlas.java:113)
> Caused by: org.apache.atlas.AtlasException: Could not find server id for this 
> instance. Unable to find IDs matching any local host and port binding among 
> id1
> at 
> org.apache.atlas.ha.AtlasServerIdSelector.selectServerId(AtlasServerIdSelector.java:77)
> at 
> org.apache.atlas.web.service.ActiveInstanceElectorService.start(ActiveInstanceElectorService.java:105)
> at org.apache.atlas.service.Services.start(Services.java:45)
> ... 19 more
> 2016-06-14 10:48:23,284 INFO  - [main:] ~ Started 
> ServerConnector@255af999{HTTP/1.1}{0.0.0.0:21000} (ServerConnector:266)
> {noformat}
> To fix this,
> atlas.server.ha.enabled will not be shown on the UI and instead derived. But 
> if for whatever reason we need to do some debugging/troubleshooting on Atlas, 
> we may allow the user to override the property.
> * single Atlas Server => write config with atlas.server.ha.enabled=false (if 
> atlas.server.ha.enabled is set to true, still write it out as false)
> * multiple Atlas Servers => write config with atlas.server.ha.enabled=true 
> (only if atlas.server.ha.enabled is not a property, otherwise, take its value)



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

[jira] [Updated] (AMBARI-17662) Atlas HA fails to come up with error finding ids

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-17662:
-
Attachment: AMBARI-17662.trunk.patch
AMBARI-17662.branch-2.4.patch

> Atlas HA fails to come up with error finding ids
> 
>
> Key: AMBARI-17662
> URL: https://issues.apache.org/jira/browse/AMBARI-17662
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.4.0
>
> Attachments: AMBARI-17662.branch-2.4.patch, AMBARI-17662.trunk.patch
>
>
> Deploy multiple Atlas servers and one of them will fail since it will be 
> missing its ids.
> {noformat}
> 2016-06-14 10:48:23,249 WARN  - [main:] ~ Failed startup of context 
> o.e.j.w.WebAppContext@2ad31d76{/,file:/grid/0/hdp/2.5.0.0-723/atlas/server/webapp/atlas/,STARTING}{/usr/hdp/current/atlas-server/server/webapp/atlas}
>  (WebAppContext:514)
> java.lang.RuntimeException: org.apache.atlas.AtlasException: Could not find 
> server id for this instance. Unable to find IDs matching any local host and 
> port binding among id1
> at org.apache.atlas.service.Services.start(Services.java:48)
> at 
> org.apache.atlas.web.listeners.GuiceServletConfig.startServices(GuiceServletConfig.java:142)
> at 
> org.apache.atlas.web.listeners.GuiceServletConfig.contextInitialized(GuiceServletConfig.java:136)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
> at org.eclipse.jetty.server.Server.start(Server.java:387)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> at org.eclipse.jetty.server.Server.doStart(Server.java:354)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.apache.atlas.web.service.EmbeddedServer.start(EmbeddedServer.java:93)
> at org.apache.atlas.Atlas.main(Atlas.java:113)
> Caused by: org.apache.atlas.AtlasException: Could not find server id for this 
> instance. Unable to find IDs matching any local host and port binding among 
> id1
> at 
> org.apache.atlas.ha.AtlasServerIdSelector.selectServerId(AtlasServerIdSelector.java:77)
> at 
> org.apache.atlas.web.service.ActiveInstanceElectorService.start(ActiveInstanceElectorService.java:105)
> at org.apache.atlas.service.Services.start(Services.java:45)
> ... 19 more
> 2016-06-14 10:48:23,284 INFO  - [main:] ~ Started 
> ServerConnector@255af999{HTTP/1.1}{0.0.0.0:21000} (ServerConnector:266)
> {noformat}
> To fix this,
> atlas.server.ha.enabled will not be shown on the UI and instead derived. But 
> if for whatever reason we need to do some debugging/troubleshooting on Atlas, 
> we may allow the user to override the property.
> * single Atlas Server => write config with atlas.server.ha.enabled=false (if 
> atlas.server.ha.enabled is set to true, still write it out as false)
> * multiple Atlas Servers => write config with atlas.server.ha.enabled=true 
> (only if atlas.server.ha.enabled is not a property, otherwise, take its value)



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

[jira] [Updated] (AMBARI-17662) Atlas HA fails to come up with error finding ids

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-17662:
-
Attachment: (was: AMBARI-17662.trunk.patch)

> Atlas HA fails to come up with error finding ids
> 
>
> Key: AMBARI-17662
> URL: https://issues.apache.org/jira/browse/AMBARI-17662
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.4.0
>
> Attachments: AMBARI-17662.branch-2.4.patch, AMBARI-17662.trunk.patch
>
>
> Deploy multiple Atlas servers and one of them will fail since it will be 
> missing its ids.
> {noformat}
> 2016-06-14 10:48:23,249 WARN  - [main:] ~ Failed startup of context 
> o.e.j.w.WebAppContext@2ad31d76{/,file:/grid/0/hdp/2.5.0.0-723/atlas/server/webapp/atlas/,STARTING}{/usr/hdp/current/atlas-server/server/webapp/atlas}
>  (WebAppContext:514)
> java.lang.RuntimeException: org.apache.atlas.AtlasException: Could not find 
> server id for this instance. Unable to find IDs matching any local host and 
> port binding among id1
> at org.apache.atlas.service.Services.start(Services.java:48)
> at 
> org.apache.atlas.web.listeners.GuiceServletConfig.startServices(GuiceServletConfig.java:142)
> at 
> org.apache.atlas.web.listeners.GuiceServletConfig.contextInitialized(GuiceServletConfig.java:136)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
> at org.eclipse.jetty.server.Server.start(Server.java:387)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> at org.eclipse.jetty.server.Server.doStart(Server.java:354)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.apache.atlas.web.service.EmbeddedServer.start(EmbeddedServer.java:93)
> at org.apache.atlas.Atlas.main(Atlas.java:113)
> Caused by: org.apache.atlas.AtlasException: Could not find server id for this 
> instance. Unable to find IDs matching any local host and port binding among 
> id1
> at 
> org.apache.atlas.ha.AtlasServerIdSelector.selectServerId(AtlasServerIdSelector.java:77)
> at 
> org.apache.atlas.web.service.ActiveInstanceElectorService.start(ActiveInstanceElectorService.java:105)
> at org.apache.atlas.service.Services.start(Services.java:45)
> ... 19 more
> 2016-06-14 10:48:23,284 INFO  - [main:] ~ Started 
> ServerConnector@255af999{HTTP/1.1}{0.0.0.0:21000} (ServerConnector:266)
> {noformat}
> To fix this,
> atlas.server.ha.enabled will not be shown on the UI and instead derived. But 
> if for whatever reason we need to do some debugging/troubleshooting on Atlas, 
> we may allow the user to override the property.
> * single Atlas Server => write config with atlas.server.ha.enabled=false (if 
> atlas.server.ha.enabled is set to true, still write it out as false)
> * multiple Atlas Servers => write config with atlas.server.ha.enabled=true 
> (only if atlas.server.ha.enabled is not a property, otherwise, take its value)



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

[jira] [Commented] (AMBARI-17657) Ambari uses default hdfs user on NNHA wizard

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-17657:


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

This message is automatically generated.

> Ambari uses default hdfs user on NNHA wizard
> 
>
> Key: AMBARI-17657
> URL: https://issues.apache.org/jira/browse/AMBARI-17657
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17657.patch
>
>
> 1. During install change hdfs (ex: 'hdfs1')
> 2. Go to NNHA wizard 
> 3. On 4 step in manual command default hfds user is shown like:
> "sudo su *hdfs* -l -c 'hdfs dfsadmin -safemode enter'"
> But should be:
> "sudo su *hdfs1* -l -c 'hdfs dfsadmin -safemode enter'"



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

[jira] [Updated] (AMBARI-17662) Atlas HA fails to come up with error finding ids

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-17662:
-
Status: Patch Available  (was: In Progress)

> Atlas HA fails to come up with error finding ids
> 
>
> Key: AMBARI-17662
> URL: https://issues.apache.org/jira/browse/AMBARI-17662
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.4.0
>
> Attachments: AMBARI-17662.branch-2.4.patch, AMBARI-17662.trunk.patch
>
>
> Deploy multiple Atlas servers and one of them will fail since it will be 
> missing its ids.
> {noformat}
> 2016-06-14 10:48:23,249 WARN  - [main:] ~ Failed startup of context 
> o.e.j.w.WebAppContext@2ad31d76{/,file:/grid/0/hdp/2.5.0.0-723/atlas/server/webapp/atlas/,STARTING}{/usr/hdp/current/atlas-server/server/webapp/atlas}
>  (WebAppContext:514)
> java.lang.RuntimeException: org.apache.atlas.AtlasException: Could not find 
> server id for this instance. Unable to find IDs matching any local host and 
> port binding among id1
> at org.apache.atlas.service.Services.start(Services.java:48)
> at 
> org.apache.atlas.web.listeners.GuiceServletConfig.startServices(GuiceServletConfig.java:142)
> at 
> org.apache.atlas.web.listeners.GuiceServletConfig.contextInitialized(GuiceServletConfig.java:136)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
> at org.eclipse.jetty.server.Server.start(Server.java:387)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> at org.eclipse.jetty.server.Server.doStart(Server.java:354)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.apache.atlas.web.service.EmbeddedServer.start(EmbeddedServer.java:93)
> at org.apache.atlas.Atlas.main(Atlas.java:113)
> Caused by: org.apache.atlas.AtlasException: Could not find server id for this 
> instance. Unable to find IDs matching any local host and port binding among 
> id1
> at 
> org.apache.atlas.ha.AtlasServerIdSelector.selectServerId(AtlasServerIdSelector.java:77)
> at 
> org.apache.atlas.web.service.ActiveInstanceElectorService.start(ActiveInstanceElectorService.java:105)
> at org.apache.atlas.service.Services.start(Services.java:45)
> ... 19 more
> 2016-06-14 10:48:23,284 INFO  - [main:] ~ Started 
> ServerConnector@255af999{HTTP/1.1}{0.0.0.0:21000} (ServerConnector:266)
> {noformat}
> To fix this,
> atlas.server.ha.enabled will not be shown on the UI and instead derived. But 
> if for whatever reason we need to do some debugging/troubleshooting on Atlas, 
> we may allow the user to override the property.
> * single Atlas Server => write config with atlas.server.ha.enabled=false (if 
> atlas.server.ha.enabled is set to true, still write it out as false)
> * multiple Atlas Servers => write config with atlas.server.ha.enabled=true 
> (only if atlas.server.ha.enabled is not a property, otherwise, take its value)



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

[jira] [Updated] (AMBARI-17662) Atlas HA fails to come up with error finding ids

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-17662:
-
Attachment: AMBARI-17662.trunk.patch
AMBARI-17662.branch-2.4.patch

> Atlas HA fails to come up with error finding ids
> 
>
> Key: AMBARI-17662
> URL: https://issues.apache.org/jira/browse/AMBARI-17662
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.4.0
>
> Attachments: AMBARI-17662.branch-2.4.patch, AMBARI-17662.trunk.patch
>
>
> Deploy multiple Atlas servers and one of them will fail since it will be 
> missing its ids.
> {noformat}
> 2016-06-14 10:48:23,249 WARN  - [main:] ~ Failed startup of context 
> o.e.j.w.WebAppContext@2ad31d76{/,file:/grid/0/hdp/2.5.0.0-723/atlas/server/webapp/atlas/,STARTING}{/usr/hdp/current/atlas-server/server/webapp/atlas}
>  (WebAppContext:514)
> java.lang.RuntimeException: org.apache.atlas.AtlasException: Could not find 
> server id for this instance. Unable to find IDs matching any local host and 
> port binding among id1
> at org.apache.atlas.service.Services.start(Services.java:48)
> at 
> org.apache.atlas.web.listeners.GuiceServletConfig.startServices(GuiceServletConfig.java:142)
> at 
> org.apache.atlas.web.listeners.GuiceServletConfig.contextInitialized(GuiceServletConfig.java:136)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
> at org.eclipse.jetty.server.Server.start(Server.java:387)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> at org.eclipse.jetty.server.Server.doStart(Server.java:354)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.apache.atlas.web.service.EmbeddedServer.start(EmbeddedServer.java:93)
> at org.apache.atlas.Atlas.main(Atlas.java:113)
> Caused by: org.apache.atlas.AtlasException: Could not find server id for this 
> instance. Unable to find IDs matching any local host and port binding among 
> id1
> at 
> org.apache.atlas.ha.AtlasServerIdSelector.selectServerId(AtlasServerIdSelector.java:77)
> at 
> org.apache.atlas.web.service.ActiveInstanceElectorService.start(ActiveInstanceElectorService.java:105)
> at org.apache.atlas.service.Services.start(Services.java:45)
> ... 19 more
> 2016-06-14 10:48:23,284 INFO  - [main:] ~ Started 
> ServerConnector@255af999{HTTP/1.1}{0.0.0.0:21000} (ServerConnector:266)
> {noformat}
> To fix this,
> atlas.server.ha.enabled will not be shown on the UI and instead derived. But 
> if for whatever reason we need to do some debugging/troubleshooting on Atlas, 
> we may allow the user to override the property.
> * single Atlas Server => write config with atlas.server.ha.enabled=false (if 
> atlas.server.ha.enabled is set to true, still write it out as false)
> * multiple Atlas Servers => write config with atlas.server.ha.enabled=true 
> (only if atlas.server.ha.enabled is not a property, otherwise, take its value)



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

[jira] [Created] (AMBARI-17662) Atlas HA fails to come up with error finding ids

[Alejandro Fernandez (JIRA)]

Alejandro Fernandez created AMBARI-17662:


 Summary: Atlas HA fails to come up with error finding ids
 Key: AMBARI-17662
 URL: https://issues.apache.org/jira/browse/AMBARI-17662
 Project: Ambari
  Issue Type: Bug
  Components: stacks
Affects Versions: 2.4.0
Reporter: Alejandro Fernandez
Assignee: Alejandro Fernandez
 Fix For: 2.4.0


Deploy multiple Atlas servers and one of them will fail since it will be 
missing its ids.

{noformat}
2016-06-14 10:48:23,249 WARN  - [main:] ~ Failed startup of context 
o.e.j.w.WebAppContext@2ad31d76{/,file:/grid/0/hdp/2.5.0.0-723/atlas/server/webapp/atlas/,STARTING}{/usr/hdp/current/atlas-server/server/webapp/atlas}
 (WebAppContext:514)
java.lang.RuntimeException: org.apache.atlas.AtlasException: Could not find 
server id for this instance. Unable to find IDs matching any local host and 
port binding among id1
at org.apache.atlas.service.Services.start(Services.java:48)
at 
org.apache.atlas.web.listeners.GuiceServletConfig.startServices(GuiceServletConfig.java:142)
at 
org.apache.atlas.web.listeners.GuiceServletConfig.contextInitialized(GuiceServletConfig.java:136)
at 
org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
at 
org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444)
at 
org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
at 
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)
at 
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
at 
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
at 
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
at 
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
at org.eclipse.jetty.server.Server.start(Server.java:387)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
at org.eclipse.jetty.server.Server.doStart(Server.java:354)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at 
org.apache.atlas.web.service.EmbeddedServer.start(EmbeddedServer.java:93)
at org.apache.atlas.Atlas.main(Atlas.java:113)
Caused by: org.apache.atlas.AtlasException: Could not find server id for this 
instance. Unable to find IDs matching any local host and port binding among id1
at 
org.apache.atlas.ha.AtlasServerIdSelector.selectServerId(AtlasServerIdSelector.java:77)
at 
org.apache.atlas.web.service.ActiveInstanceElectorService.start(ActiveInstanceElectorService.java:105)
at org.apache.atlas.service.Services.start(Services.java:45)
... 19 more
2016-06-14 10:48:23,284 INFO  - [main:] ~ Started 
ServerConnector@255af999{HTTP/1.1}{0.0.0.0:21000} (ServerConnector:266)
{noformat}

To fix this,

atlas.server.ha.enabled will not be shown on the UI and instead derived. But if 
for whatever reason we need to do some debugging/troubleshooting on Atlas, we 
may allow the user to override the property.

* single Atlas Server => write config with atlas.server.ha.enabled=false (if 
atlas.server.ha.enabled is set to true, still write it out as false)
* multiple Atlas Servers => write config with atlas.server.ha.enabled=true 
(only if atlas.server.ha.enabled is not a property, otherwise, take its value)



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

[jira] [Commented] (AMBARI-17659) Ambari build fails with CSS minimization

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17659:
-

FAILURE: Integrated in Ambari-trunk-Commit #5273 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5273/])
AMBARI-17659. Ambari build fails with CSS minimization (alexantonenko) (hiveww: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=70ac854c70b17d6b8de07fc3bacf46504ad0fe9a])
* contrib/views/jobs/src/main/resources/ui/bower.json


> Ambari build fails with CSS minimization
> 
>
> Key: AMBARI-17659
> URL: https://issues.apache.org/jira/browse/AMBARI-17659
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17659.patch
>
>
> Buidl fails during css minimization:
> {quote}
> Running "cssmin:dist" (cssmin) task
> >> Error: Broken @import declaration of 
> "../../app/bower_components/jquery-ui/themes/base/all.css"
> Warning: css minification failed. Use --force to continue.
> Aborted due to warnings.
> [ERROR] Command execution failed.
> org.apache.commons.exec.ExecuteException: Process exited with an error: 6 
> (Exit value: 6)
>   at 
> org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:404)
>   at 
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:166)
>   at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:764)
>   at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:711)
>   at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:289)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {quote}



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

[jira] [Commented] (AMBARI-17654) Installation of Components was failed on suse12 with suse11sp3 ambari/hdp repo

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17654:
-

FAILURE: Integrated in Ambari-trunk-Commit #5273 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5273/])
AMBARI-17654. Installation of Components was failed on suse12 with (aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=ce2c123f9c7f4c64078a2aab0bfb27fd277bff65])
* ambari-server/src/main/resources/stacks/HDP/2.2/services/HDFS/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.3/services/HDFS/metainfo.xml
* ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/metainfo.xml
* 
ambari-common/src/main/python/resource_management/libraries/functions/get_lzo_packages.py


> Installation of Components was failed on suse12 with suse11sp3 ambari/hdp repo
> --
>
> Key: AMBARI-17654
> URL: https://issues.apache.org/jira/browse/AMBARI-17654
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-17654.patch
>
>
> STR:  
> 1) Try to deploy ambari on sles12 by using suse11sp3 repo as was proposed
> before
> **Cluster:** 
> Actual result:  
> Installation of Components are failed on suse12 with suse11sp3 ambari/hdp repo
> 
> 
> 
> 2016-07-06 12:22:59,978 - checked_call['rpm -q --queryformat 
> '%{version}-%{release}' hdp-select | sed -e 's/\.el[0-9]//g''] {'stderr': -1}
> 2016-07-06 12:22:59,994 - checked_call returned (0, '2.5.0.0-887', '')
> 2016-07-06 12:23:00,001 - Package['hadoop_2_5_0_0_887'] 
> {'retry_on_repo_unavailability': True, 'retry_count': 5}
> 2016-07-06 12:23:00,019 - Skipping installation of existing package 
> hadoop_2_5_0_0_887
> 2016-07-06 12:23:00,020 - Package['snappy'] 
> {'retry_on_repo_unavailability': True, 'retry_count': 5}
> 2016-07-06 12:23:00,095 - Skipping installation of existing package snappy
> 2016-07-06 12:23:00,096 - Package['snappy-devel'] 
> {'retry_on_repo_unavailability': True, 'retry_count': 5}
> 2016-07-06 12:23:00,105 - Skipping installation of existing package 
> snappy-devel
> 2016-07-06 12:23:00,107 - Package['lzo'] {'retry_on_repo_unavailability': 
> True, 'retry_count': 5}
> 2016-07-06 12:23:00,209 - Installing package lzo ('/usr/bin/zypper 
> --quiet install --auto-agree-with-licenses --no-confirm lzo')
> 
> Command failed after 1 tries
> 



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

[jira] [Commented] (AMBARI-17624) Host service mapping has incorrect default mapping

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17624:
-

FAILURE: Integrated in Ambari-trunk-Commit #5273 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5273/])
AMBARI-17624. Host service mapping has incorrect default mapping (aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=6c03848a724ea3cf004f49f6ef09f0f0f164802c])
* ambari-server/src/test/python/stacks/2.0.6/common/test_stack_advisor.py
* ambari-server/src/main/resources/stacks/stack_advisor.py


> Host service mapping has incorrect default mapping
> --
>
> Key: AMBARI-17624
> URL: https://issues.apache.org/jira/browse/AMBARI-17624
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-17624.patch
>
>
> Activity Analyzer and Explorer are salves with cardinality
> [0-1].  
> However the default selection maps to all hosts. This used to work fine in
> previous builds, but seems to be broken recently
> Ambari version:
> 
> 
> [root@cn030 ~]# rpm -qa | grep ambari
> ambari-agent-2.4.0.0-764.x86_64
> ambari-server-2.4.0.0-764.x86_64
> 



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

[jira] [Commented] (AMBARI-17655) Redundant horizontal scrollbar on Versions tab

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17655:
-

FAILURE: Integrated in Ambari-trunk-Commit #5273 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5273/])
AMBARI-17655. Redundant horizontal scrollbar on Versions tab (hiveww: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=8a2f5ccfebc59518a85c94f8a7e43009c1125e7d])
* ambari-web/app/styles/stack_versions.less


> Redundant horizontal scrollbar on Versions tab
> --
>
> Key: AMBARI-17655
> URL: https://issues.apache.org/jira/browse/AMBARI-17655
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-17655.patch, no-versions.jpg, versions.jpg
>
>
> Versions blocks on Admin -> Stack and versions page are laid out 
> horizontally, but scrollbar appears even if they don't overflow section's 
> width: [^versions.jpg].
> Case of no filtered versions: [^no-versions.jpg].



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

[jira] [Commented] (AMBARI-17562) Adding single stack, extension and service should be removed from management pack support

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17562:
-

FAILURE: Integrated in Ambari-trunk-Commit #5273 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5273/])
AMBARI-17562 - Adding single stack, extension and service should be (jluniya: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=376ac438988bc32451ed030601ab13524692dc53])
* ambari-server/src/main/python/ambari_server/setupMpacks.py
* ambari-server/src/test/python/mpacks/myservice-ambari-mpack-1.0.0.0/mpack.json
* ambari-server/src/test/python/TestMpacks.py


> Adding single stack, extension and service should be removed from management 
> pack support
> -
>
> Key: AMBARI-17562
> URL: https://issues.apache.org/jira/browse/AMBARI-17562
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Tim Thorpe
>Assignee: Tim Thorpe
> Fix For: 2.4.0
>
> Attachments: AMBARI-17562.patch
>
>
> This code is duplicated by the ability to add multiple stacks, extensions and 
> addon services.  There is no reason to maintain both code paths.



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

[jira] [Commented] (AMBARI-17651) Restart indicator is not shown after modifying the configs

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17651:
-

FAILURE: Integrated in Ambari-trunk-Commit #5273 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5273/])
AMBARI-17651. Restart indicator is not shown after modifying the configs 
(dlysnichenko: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=31e2c30b9cae7bdf4cc99bca27f759a66ae1738c])
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ConfigGroupResourceProviderTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java
* 
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ConfigGroupResourceProvider.java
* ambari-server/src/main/java/org/apache/ambari/server/state/ConfigHelper.java
* 
ambari-server/src/main/java/org/apache/ambari/server/agent/HeartBeatHandler.java
* 
ambari-server/src/test/java/org/apache/ambari/server/state/ConfigHelperTest.java


> Restart indicator is not shown after modifying the configs
> --
>
> Key: AMBARI-17651
> URL: https://issues.apache.org/jira/browse/AMBARI-17651
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-17651.patch
>
>
> Restart indicator is not shown after modifying the configs.
> Test case modified the hdfs config 'Namenode new generation size'. But still 
> after saving the configuration, restart icon is not shown.



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

[jira] [Commented] (AMBARI-17661) Support YARN timeline plugin classpath config

[Bikas Saha (JIRA)]

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

Bikas Saha commented on AMBARI-17661:
-

[~jluniya] Can you please comment on how to use stack_root for the above patch?

> Support YARN timeline plugin classpath config
> -
>
> Key: AMBARI-17661
> URL: https://issues.apache.org/jira/browse/AMBARI-17661
> Project: Ambari
>  Issue Type: Bug
>Reporter: Bikas Saha
>Assignee: Bikas Saha
> Attachments: AMBARI-17661.1.patch
>
>
> YARN-5233 added a config to specify the plugin classpath. Adding support for 
> that config.



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

[jira] [Commented] (AMBARI-17661) Support YARN timeline plugin classpath config

[Bikas Saha (JIRA)]

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

Bikas Saha commented on AMBARI-17661:
-

[~gtCarrera9] Please review the config value for correctness.

[~afernandez] Please review Ambari changes. https://reviews.apache.org/r/49923/

Since this is a new property, I think there is no need to edit the upgrade 
related files.

> Support YARN timeline plugin classpath config
> -
>
> Key: AMBARI-17661
> URL: https://issues.apache.org/jira/browse/AMBARI-17661
> Project: Ambari
>  Issue Type: Bug
>Reporter: Bikas Saha
>Assignee: Bikas Saha
> Attachments: AMBARI-17661.1.patch
>
>
> YARN-5233 added a config to specify the plugin classpath. Adding support for 
> that config.



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

[jira] [Updated] (AMBARI-17661) Support YARN timeline plugin classpath config

[Bikas Saha (JIRA)]

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

Bikas Saha updated AMBARI-17661:

Attachment: AMBARI-17661.1.patch

> Support YARN timeline plugin classpath config
> -
>
> Key: AMBARI-17661
> URL: https://issues.apache.org/jira/browse/AMBARI-17661
> Project: Ambari
>  Issue Type: Bug
>Reporter: Bikas Saha
>Assignee: Bikas Saha
> Attachments: AMBARI-17661.1.patch
>
>
> YARN-5233 added a config to specify the plugin classpath. Adding support for 
> that config.



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

[jira] [Created] (AMBARI-17661) Support YARN timeline plugin classpath config

[Bikas Saha (JIRA)]

Bikas Saha created AMBARI-17661:
---

 Summary: Support YARN timeline plugin classpath config
 Key: AMBARI-17661
 URL: https://issues.apache.org/jira/browse/AMBARI-17661
 Project: Ambari
  Issue Type: Bug
Reporter: Bikas Saha
Assignee: Bikas Saha


YARN-5233 added a config to specify the plugin classpath. Adding support for 
that config.



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

[jira] [Updated] (AMBARI-17660) EU Downgrade Does Not Stop Services

[Jonathan Hurley (JIRA)]

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

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

> EU Downgrade Does Not Stop Services
> ---
>
> Key: AMBARI-17660
> URL: https://issues.apache.org/jira/browse/AMBARI-17660
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17660.patch
>
>
> When downgrading an express upgrade, the orchestration of the downgrade does 
> not perform the same steps as the upgrade did. Namely, the stopping of high- 
> and low-level services is not present. This leads to a scenario like this:
> - Upgrade HDP 2.x to 2.y
> -- Stop Storm
> -- Stop ZK
> -- Update Stack to 2.y
> -- Restart ZK on 2.y
> -- Restart Storm on 2.y
> - Downgrade  HDP 2.y to 2.x
> -- Update Stack to 2.x
> -- Restart ZK on 2.x
> -- Restart Storm on 2.x
> Notice that we didn't stop the running services. This leads to a problem 
> where actions which must take place while services are down can't complete 
> successfully.
> The case in point is Storm. Between HDP 2.4 and HDP 2.5, Storm changed the 
> name of a serialized class. Part of the Storm upgrade/downgrade is to always 
> delete local storm data. However, during an EU, if Nimbus and Supervisor are 
> co-located on the same host, Supervisor will write out 2.5 data since it 
> wasn't shut down. Consider:
> - Nimbus deletes local data and restarts on the downgrade version
> - A running 2.5 Supervisor on the same host then re-creates that directory 
> and puts 2.5 data back in
> - When the 2.5 Supervisor goes to downgrade and restart, it can't delete that 
> data again since Nimbus is already running and would stop.
> For this reason, we should always ensure that services are stopped on the 
> downgrade for an EU. 



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

[jira] [Updated] (AMBARI-17660) EU Downgrade Does Not Stop Services

[Jonathan Hurley (JIRA)]

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

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

> EU Downgrade Does Not Stop Services
> ---
>
> Key: AMBARI-17660
> URL: https://issues.apache.org/jira/browse/AMBARI-17660
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17660.patch
>
>
> When downgrading an express upgrade, the orchestration of the downgrade does 
> not perform the same steps as the upgrade did. Namely, the stopping of high- 
> and low-level services is not present. This leads to a scenario like this:
> - Upgrade HDP 2.x to 2.y
> -- Stop Storm
> -- Stop ZK
> -- Update Stack to 2.y
> -- Restart ZK on 2.y
> -- Restart Storm on 2.y
> - Downgrade  HDP 2.y to 2.x
> -- Update Stack to 2.x
> -- Restart ZK on 2.x
> -- Restart Storm on 2.x
> Notice that we didn't stop the running services. This leads to a problem 
> where actions which must take place while services are down can't complete 
> successfully.
> The case in point is Storm. Between HDP 2.4 and HDP 2.5, Storm changed the 
> name of a serialized class. Part of the Storm upgrade/downgrade is to always 
> delete local storm data. However, during an EU, if Nimbus and Supervisor are 
> co-located on the same host, Supervisor will write out 2.5 data since it 
> wasn't shut down. Consider:
> - Nimbus deletes local data and restarts on the downgrade version
> - A running 2.5 Supervisor on the same host then re-creates that directory 
> and puts 2.5 data back in
> - When the 2.5 Supervisor goes to downgrade and restart, it can't delete that 
> data again since Nimbus is already running and would stop.
> For this reason, we should always ensure that services are stopped on the 
> downgrade for an EU. 



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

[jira] [Updated] (AMBARI-17562) Adding single stack, extension and service should be removed from management pack support

[Tim Thorpe (JIRA)]

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

Tim Thorpe updated AMBARI-17562:

   Resolution: Fixed
Fix Version/s: 2.4.0
   Status: Resolved  (was: Patch Available)

> Adding single stack, extension and service should be removed from management 
> pack support
> -
>
> Key: AMBARI-17562
> URL: https://issues.apache.org/jira/browse/AMBARI-17562
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Tim Thorpe
>Assignee: Tim Thorpe
> Fix For: 2.4.0
>
> Attachments: AMBARI-17562.patch
>
>
> This code is duplicated by the ability to add multiple stacks, extensions and 
> addon services.  There is no reason to maintain both code paths.



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

[jira] [Commented] (AMBARI-17658) Storm nimbus server fails to come up with CNF backtype.storm.metric.IClusterReporter error

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-17658:


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

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

This message is automatically generated.

> Storm nimbus server fails to come up with CNF 
> backtype.storm.metric.IClusterReporter error
> --
>
> Key: AMBARI-17658
> URL: https://issues.apache.org/jira/browse/AMBARI-17658
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, stacks
>Affects Versions: 2.4.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17658.patch
>
>
> See the following in nimbus log
> {code}
> 2016-07-06 21:41:51.546 o.a.s.d.nimbus [ERROR] Error on initialization of 
> server service-handler
> java.lang.NoClassDefFoundError: backtype/storm/metric/IClusterReporter
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at 
> org.apache.storm.metric.ClusterMetricsConsumerExecutor.prepare(ClusterMetricsConsumerExecutor.java:48)
> 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 clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
> at 
> clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:313)
> at 
> org.apache.storm.daemon.nimbus$fn__11247$exec_fn__3182__auto11248.invoke(nimbus.clj:2205)
> at clojure.lang.AFn.applyToHelper(AFn.java:156)
> at clojure.lang.AFn.applyTo(AFn.java:144)
> at clojure.core$apply.invoke(core.clj:630)
> at 
> org.apache.storm.daemon.nimbus$fn__11247$service_handler__11283.doInvoke(nimbus.clj:2181)
> at clojure.lang.RestFn.invoke(RestFn.java:421)
> at 
> org.apache.storm.daemon.nimbus$launch_server_BANG_.invoke(nimbus.clj:2271)
> at org.apache.storm.daemon.nimbus$_launch.invoke(nimbus.clj:2304)
> at org.apache.storm.daemon.nimbus$_main.invoke(nimbus.clj:2327)
> at clojure.lang.AFn.applyToHelper(AFn.java:152)
> at clojure.lang.AFn.applyTo(AFn.java:144)
> at org.apache.storm.daemon.nimbus.main(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: 
> backtype.storm.metric.IClusterReporter
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> 

[jira] [Resolved] (AMBARI-15848) Remove localhost assumptions in the LogSearch Integration Code

[Robert Nettleton (JIRA)]

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

Robert Nettleton resolved AMBARI-15848.
---
   Resolution: Fixed
Fix Version/s: (was: 2.5.0)
   2.4.0

Marking this issue as Fixed, since the patch for AMBARI-15976 resolves the 
assumption of the LogSearch server running on "localhost". 



> Remove localhost assumptions in the LogSearch Integration Code
> --
>
> Key: AMBARI-15848
> URL: https://issues.apache.org/jira/browse/AMBARI-15848
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Nettleton
>Assignee: Robert Nettleton
> Fix For: 2.4.0
>
>
> This issue tracks a small change required to the LoggingRequestHelperImpl 
> class in the LogSearch integration code:
> org.apache.ambari.server.controller.logging.LoggingRequestHelperImpl
> The default hostname listed as a constant in this class:
> private static String DEFAULT_HOSTNAME = "localhost";
> should be removed.
> This constant was put in place during the initial development of this code, 
> when an assumption was that Ambari and LogSearch run on the same host.  This 
> restriction has already been removed in a previous patch, but this constant 
> should be removed to make this point clearer. 



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

[jira] [Commented] (AMBARI-17618) Fix ConcurrentModificationException in Resource.Type

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17618:
-

ABORTED: Integrated in Ambari-trunk-Commit #5272 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5272/])
AMBARI-17618. Fix ConcurrentModificationException in Resource.Type (smagyari: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=e8bfdb9248d8b305650555c7a7d2b230a163639b])
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/utilities/PropertyHelper.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/spi/Resource.java


> Fix ConcurrentModificationException in Resource.Type
> 
>
> Key: AMBARI-17618
> URL: https://issues.apache.org/jira/browse/AMBARI-17618
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17618.patch, AMBARI-17618_v2.patch
>
>
> Resource.Type is not thread-safe, sometimes ConcurrentModificationException 
> may occur when for. ex Ambari is extracting a new view and adding a new view 
> resource type call Resource.Type.setType()), meanwhile on a separate incoming 
> request processing thread iterating through resource types calling 
> Resource.type.values().



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

[jira] [Commented] (AMBARI-17649) Fix Logfeeder input configs for hdfs and hbase

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17649:
-

ABORTED: Integrated in Ambari-trunk-Commit #5272 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5272/])
AMBARI-17649. Fix logfeeder inputs for hbase and hdfs (oleewere) (oleewere: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=15e58ecc283b32458920ed1c167e746ba335a05e])
* 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/templates/input.config-hbase.json.j2
* 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/templates/input.config-hdfs.json.j2


> Fix Logfeeder input configs for hdfs and hbase
> --
>
> Key: AMBARI-17649
> URL: https://issues.apache.org/jira/browse/AMBARI-17649
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-logsearch
>Affects Versions: 2.4.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 2.4.0
>
>
> hdfs audit log is not parsed, same with hbase if custom there is a custom 
> hbase user



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

[jira] [Commented] (AMBARI-17632) Zeppelin service: Dependencies for phoenix in JDBC interpreter are not configured by default

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17632:
-

ABORTED: Integrated in Ambari-trunk-Commit #5272 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5272/])
AMBARI-17632. Zeppelin service: Dependencies for phoenix in JDBC (pallav.kul: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=e5350040d4742cd1eaef62372a306f4c5d25403d])
* 
ambari-server/src/main/resources/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/params.py
* 
ambari-server/src/main/resources/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py


> Zeppelin service: Dependencies for phoenix in JDBC interpreter are not 
> configured by default
> 
>
> Key: AMBARI-17632
> URL: https://issues.apache.org/jira/browse/AMBARI-17632
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Kshitij Badani
>Assignee: Renjith Kamath
> Fix For: 2.4.0
>
> Attachments: AMBARI-17632_trunk+branch-2.4_v1.patch
>
>
> It is observed that the dependencies for phoenix are not configured in JDBC 
> interpreter out-of-the-box. A user has to manually configure it 
> (org.apache.phoenix:phoenix-core:4.4.0-HBase-1.0) and save the interpreter 
> configurations.
> After configuring dependency,  Zeppelin does not work with phoenix .
> My Zeppelin JDBC interpreter configs corresponding to pheonix are
> phoenix.driverorg.apache.phoenix.jdbc.PhoenixDriver
> phoenix.hbase.client.retries.number   1
> phoenix.password  
> phoenix.url   jdbc:phoenix::2181:/hbase-unsecure
> phoenix.user  phoenixuser
> When I try to run query:
> %jdbc(phoenix)
> create table if not exists PRICES (
>  SYMBOL varchar(10),
>  DATE   varchar(10),
>  TIME varchar(10),
>  OPEN varchar(10),
>  HIGH varchar(10),
>  LOWvarchar(10),
>  CLOSE varchar(10),
>  VOLUME varchar(30),
>  CONSTRAINT pk PRIMARY KEY (SYMBOL, DATE, TIME)
> ) 
> It gives PhoenixIOException
> class org.apache.phoenix.exception.PhoenixIOException
> org.apache.phoenix.util.ServerUtil.parseServerException(ServerUtil.java:108)
> org.apache.phoenix.query.ConnectionQueryServicesImpl.ensureTableCreated(ConnectionQueryServicesImpl.java:879)
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createTable(ConnectionQueryServicesImpl.java:1213)
> org.apache.phoenix.query.DelegateConnectionQueryServices.createTable(DelegateConnectionQueryServices.java:112)
> org.apache.phoenix.schema.MetaDataClient.createTableInternal(MetaDataClient.java:1902)
> org.apache.phoenix.schema.MetaDataClient.createTable(MetaDataClient.java:744)
> org.apache.phoenix.compile.CreateTableCompiler$2.execute(CreateTableCompiler.java:186)
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:303)
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:295)
> org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:293)
> org.apache.phoenix.jdbc.PhoenixStatement.executeUpdate(PhoenixStatement.java:1236)
> org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(ConnectionQueryServicesImpl.java:1891)
> org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(ConnectionQueryServicesImpl.java:1860)
> org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:77)
> org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:1860)
> org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:162)
> org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.connect(PhoenixEmbeddedDriver.java:131)
> org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:133)
> java.sql.DriverManager.getConnection(DriverManager.java:571)
> java.sql.DriverManager.getConnection(DriverManager.java:187)
> org.apache.zeppelin.jdbc.JDBCInterpreter.getConnection(JDBCInterpreter.java:222)
> org.apache.zeppelin.jdbc.JDBCInterpreter.getStatement(JDBCInterpreter.java:233)
> org.apache.zeppelin.jdbc.JDBCInterpreter.executeSql(JDBCInterpreter.java:292)
> org.apache.zeppelin.jdbc.JDBCInterpreter.interpret(JDBCInterpreter.java:396)
> org.apache.zeppelin.interpreter.LazyOpenInterpreter.interpret(LazyOpenInterpreter.java:94)
> org.apache.zeppelin.interpreter.remote.RemoteInterpreterServer$InterpretJob.jobRun(RemoteInterpreterServer.java:341)
> org.apache.zeppelin.scheduler.Job.run(Job.java:176)
> org.apache.zeppelin.scheduler.ParallelScheduler$JobRunner.run(ParallelScheduler.java:162)
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> java.util.concurrent.FutureTask.run(FutureTask.java:262)
> java.util.concurrent.Sched

[jira] [Commented] (AMBARI-17637) Zeppelin service: remove principal and keytab from interpreter settings when kerberos is disabled on a secure cluster

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17637:
-

ABORTED: Integrated in Ambari-trunk-Commit #5272 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5272/])
AMBARI-17637. Zeppelin service: remove principal and keytab from (pallav.kul: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=17ae4230d01bfe89f78c1d6bef95d32d151b076e])
* 
ambari-server/src/main/resources/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py


> Zeppelin service: remove principal and keytab from interpreter settings when 
> kerberos is disabled on a secure cluster
> -
>
> Key: AMBARI-17637
> URL: https://issues.apache.org/jira/browse/AMBARI-17637
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Prabhjyot Singh
>Assignee: Renjith Kamath
> Fix For: 2.4.0
>
> Attachments: AMBARI-17637_trunk+branch-2.4_v1.patch
>
>




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

[jira] [Commented] (AMBARI-17639) Spark Interpreter fails with "HiveException: org.apache.thrift.transport.TTransportException"

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17639:
-

ABORTED: Integrated in Ambari-trunk-Commit #5272 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5272/])
AMBARI-17639. Fix Spark Interpreter fails with (pallav.kul: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=8e3b1ff61f2c987fa740b74f8ef099303831379c])
* 
ambari-server/src/main/resources/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py
* 
ambari-server/src/main/resources/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh
* 
ambari-server/src/main/resources/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/params.py


> Spark Interpreter fails with "HiveException: 
> org.apache.thrift.transport.TTransportException"
> -
>
> Key: AMBARI-17639
> URL: https://issues.apache.org/jira/browse/AMBARI-17639
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Yesha Vora
>Assignee: Renjith Kamath
> Fix For: 2.4.0
>
> Attachments: AMBARI-17639_trunk+branch-2.4_v1.patch, 
> AMBARI-17639_trunk+branch-2.4_v2.patch
>
>
> Scenario:
> * Create a new notebook 
> * Run below paragraph
> {code}
> %sh
> hdfs dfs -copyFromLocal /etc/hadoop//conf/core-site.xml /tmp{code}
> {code}
> %spark 
> val file = sc.textFile("/tmp/core-site.xml")
> val counts = file.flatMap(line => line.split(" ")).map(word => (word, 
> 1)).reduceByKey(_ + _)
> counts.saveAsTextFile("/tmp/wordcount1"){code}
> {code:title=output from zeppelin notebook}
> org.apache.thrift.transport.TTransportException
>   at 
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
>   at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>   at 
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:429)
>   at 
> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:318)
>   at 
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:219)
>   at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:69)
>   at 
> org.apache.hadoop.hive.metastore.api.ThriftHiveMetastore$Client.recv_get_delegation_token(ThriftHiveMetastore.java:3715)
>   at 
> org.apache.hadoop.hive.metastore.api.ThriftHiveMetastore$Client.get_delegation_token(ThriftHiveMetastore.java:3701)
>   at 
> org.apache.hadoop.hive.metastore.HiveMetaStoreClient.getDelegationToken(HiveMetaStoreClient.java:1796)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.apache.hadoop.hive.metastore.RetryingMetaStoreClient.invoke(RetryingMetaStoreClient.java:156)
>   at com.sun.proxy.$Proxy29.getDelegationToken(Unknown Source)
>   at 
> org.apache.hadoop.hive.ql.metadata.Hive.getDelegationToken(Hive.java:3150)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.apache.spark.deploy.yarn.YarnSparkHadoopUtil$$anonfun$obtainTokenForHiveMetastoreInner$4.apply(YarnSparkHadoopUtil.scala:251)
>   at 
> org.apache.spark.deploy.yarn.YarnSparkHadoopUtil$$anonfun$obtainTokenForHiveMetastoreInner$4.apply(YarnSparkHadoopUtil.scala:249)
>   at 
> org.apache.spark.deploy.yarn.YarnSparkHadoopUtil$$anon$1.run(YarnSparkHadoopUtil.scala:340)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:415)
>   at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1724)
>   at 
> org.apache.spark.deploy.yarn.YarnSparkHadoopUtil.doAsRealUser(YarnSparkHadoopUtil.scala:339)
>   at 
> org.apache.spark.deploy.yarn.YarnSparkHadoopUtil.obtainTokenForHiveMetastoreInner(YarnSparkHadoopUtil.scala:249)
>   at 
> org.apache.spark.deploy.yarn.YarnSparkHadoopUtil.obtainTokenForHiveMetastore(YarnSparkHadoopUtil.scala:204)
>   at 
> org.apache.spark.deploy.yarn.YarnSparkHadoopUtil.obtainTokenForHiveMetastore(YarnSparkHadoopUtil.scala:151)
>   at 
> org.apache.spark.deploy.yarn.Client.prepareLocalResources(Client.scala:348)
>   at 
> org.apache.spark.deploy.yarn.Client.createContainerLaunchContext(Clien

[jira] [Updated] (AMBARI-15670) Disable ability to open Edit Widget Wizard if Ambari Metrics is not installed

[Aleksandr Kovalenko (JIRA)]

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

Aleksandr Kovalenko updated AMBARI-15670:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Disable ability to open Edit Widget Wizard if Ambari Metrics is not installed 
> --
>
> Key: AMBARI-15670
> URL: https://issues.apache.org/jira/browse/AMBARI-15670
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Aleksandr Kovalenko
>Assignee: Aleksandr Kovalenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-15670.patch
>
>
> If Ambari Metrics is not installed, we are still able to run Edit Widget 
> Wizard by clicking on clone or edit icons on widgets.
> We should either hide the whole section or disable buttons to clone/edit 
> widgets.



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