[jira] [Commented] (AMBARI-18870) Ranger PID file not being read if a custom location is provided

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18870:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6036 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6036/])
AMBARI-18870 Ranger PID file not being read if a custom location is (mugdha: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=07bdabdd021caa86e863b7b1ecf8543542ecf62e])
* (edit) ambari-server/src/test/python/stacks/2.5/RANGER_KMS/test_kms_server.py
* (edit) 
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/package/scripts/kms.py
* (edit) 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/setup_ranger_xml.py
* (edit) ambari-server/src/test/python/stacks/2.5/RANGER/test_ranger_usersync.py
* (edit) ambari-server/src/test/python/stacks/2.5/RANGER/test_ranger_admin.py
* (edit) ambari-server/src/test/python/stacks/2.5/RANGER/test_ranger_tagsync.py


> Ranger PID file not being read if a custom location is provided
> ---
>
> Key: AMBARI-18870
> URL: https://issues.apache.org/jira/browse/AMBARI-18870
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0, 2.4.1, 2.4.2
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
> Fix For: 2.5.0
>
> Attachments: AMBARI-18870.patch
>
>
> Ranger PID file is not being read if a custom location is provided from 
> Ambari.
> Fix include creation of .sh file which will have env variable with value as 
> PID path. This .sh file will get executed by start script of service to make 
> the env variable value to be taken into consideration.



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


[jira] [Resolved] (AMBARI-18755) Deployment failing at creating principal

2016-11-16 Thread Sumit Mohanty (JIRA)

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

Sumit Mohanty resolved AMBARI-18755.

Resolution: Fixed

> Deployment failing at creating principal
> 
>
> Key: AMBARI-18755
> URL: https://issues.apache.org/jira/browse/AMBARI-18755
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Vivek Rathod
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-18755.addendum.3.patch, 
> AMBARI-18755.addendum.patch, AMBARI-18755.patch
>
>
> Cluster deployment via blueprint failed at creating principals



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


[jira] [Updated] (AMBARI-18870) Ranger PID file not being read if a custom location is provided

2016-11-16 Thread Mugdha Varadkar (JIRA)

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

Mugdha Varadkar updated AMBARI-18870:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to
trunk : 
https://github.com/apache/ambari/commit/07bdabdd021caa86e863b7b1ecf8543542ecf62e
branch-2.5 : 
https://github.com/apache/ambari/commit/68d5e237fda336eba6677120ec237810c930ce96

> Ranger PID file not being read if a custom location is provided
> ---
>
> Key: AMBARI-18870
> URL: https://issues.apache.org/jira/browse/AMBARI-18870
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0, 2.4.1, 2.4.2
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
> Fix For: 2.5.0
>
> Attachments: AMBARI-18870.patch
>
>
> Ranger PID file is not being read if a custom location is provided from 
> Ambari.
> Fix include creation of .sh file which will have env variable with value as 
> PID path. This .sh file will get executed by start script of service to make 
> the env variable value to be taken into consideration.



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


[jira] [Commented] (AMBARI-18912) Implement Create Alerts: step 1 select alert type

2016-11-16 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on AMBARI-18912:


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

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

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

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

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

{color:red}-1 core tests{color}.  The test build failed in ambari-web 

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

This message is automatically generated.

> Implement Create Alerts: step 1 select alert type
> -
>
> Key: AMBARI-18912
> URL: https://issues.apache.org/jira/browse/AMBARI-18912
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
> Fix For: 2.5.0
>
> Attachments: AMBARI-18912.patch, Screen Shot 2016-11-16 at 6.13.51 
> PM.png
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> This is a FE task to implement the "Create Alerts Wizard " based on the 
> design attached.
> In this task, should implement the step 1 in the design. All available alert 
> types should be displayed as options with icon, type and description. Make 
> sure that on clicking a type use would jump to next step.



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


[jira] [Commented] (AMBARI-18903) Implement Create Alerts: Create a base wizard for all steps

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18903:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6035 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6035/])
AMBARI-18903. Implement Create Alerts: Create a base wizard for all (xiwang: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=33d8c56c5bd47e466e126079d457ae4bf4e904de])
* (edit) 
ambari-web/app/controllers/main/alerts/alert_definitions_actions_controller.js


> Implement Create Alerts: Create a base wizard for all steps
> ---
>
> Key: AMBARI-18903
> URL: https://issues.apache.org/jira/browse/AMBARI-18903
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18903.patch
>
>
> This is a FE task to implement the "Create Alerts Wizard " based on the 
> design attached.
> This task is to create the the following files so that we have a blank base 
> wizard as a start point.
> *4 controllers* in folder: controllers/main/alerts/create
> wizard_controller.js  (should extend App.WizardController)
> step1_controller.js
> step2_controller.js
> step3_controller.js
> *4 views* in folder: views/main/alerts/create
> wizard_view.js  (extend sApp.WizardMenuMixin)
> step1_view.js
> step2_view.js
> step3_view.js
> *4 templates* in folder: templates/main/alerts/create
> wizard.hbs 
> step1.hbs
> step2.hbs
> step3.hbs



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


[jira] [Commented] (AMBARI-18903) Implement Create Alerts: Create a base wizard for all steps

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18903:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #352 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/352/])
AMBARI-18903. Implement Create Alerts: Create a base wizard for all (xiwang: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=521995f4a9884ee62bd92f9f226b152f0155afc9])
* (edit) 
ambari-web/app/controllers/main/alerts/alert_definitions_actions_controller.js


> Implement Create Alerts: Create a base wizard for all steps
> ---
>
> Key: AMBARI-18903
> URL: https://issues.apache.org/jira/browse/AMBARI-18903
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18903.patch
>
>
> This is a FE task to implement the "Create Alerts Wizard " based on the 
> design attached.
> This task is to create the the following files so that we have a blank base 
> wizard as a start point.
> *4 controllers* in folder: controllers/main/alerts/create
> wizard_controller.js  (should extend App.WizardController)
> step1_controller.js
> step2_controller.js
> step3_controller.js
> *4 views* in folder: views/main/alerts/create
> wizard_view.js  (extend sApp.WizardMenuMixin)
> step1_view.js
> step2_view.js
> step3_view.js
> *4 templates* in folder: templates/main/alerts/create
> wizard.hbs 
> step1.hbs
> step2.hbs
> step3.hbs



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


[jira] [Commented] (AMBARI-18916) Manage JournalNodes Wizard: Text adjustments

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18916:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6034 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6034/])
AMBARI-18916 - Manage JournalNodes Wizard: Text adjustments (rzang) (rzang: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=dbf9e66b2f232083a01e22ecd283d385b76b1790])
* (edit) 
ambari-web/app/templates/main/admin/highAvailability/journalNode/step2.hbs
* (edit) ambari-web/app/messages.js


> Manage JournalNodes Wizard: Text adjustments
> 
>
> Key: AMBARI-18916
> URL: https://issues.apache.org/jira/browse/AMBARI-18916
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.5.0
>
> Attachments: AMBARI-18916.patch
>
>
> Text adjustments for Manage JournalNodes Wizard



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


[jira] [Commented] (AMBARI-18907) Auto-start should respect maintenance mode on hosts and services

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18907:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6034 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6034/])
AMBARI-18907: Auto-start should respect maintenance mode on hosts and 
(nsomasundaram: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=82c13df406b3e4d28e2b6242d29113fa96f015fe])
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/events/listeners/upgrade/AlertMaintenanceModeListenerTest.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/agent/RecoveryConfigHelper.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/state/host/HostImpl.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/events/MaintenanceModeEvent.java


> Auto-start should respect maintenance mode on hosts and services
> 
>
> Key: AMBARI-18907
> URL: https://issues.apache.org/jira/browse/AMBARI-18907
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: rb53811.patch
>
>
> Auto-start should respect maintenance mode. If any host or service (meaning 
> it's host components) or component is in maintenance mode, the auto-start 
> directive should be ignored.
> Maintenance mode is ignored at host and service level. If you mark a host as 
> in maintenance mode, and then restart the host, the services marked for 
> auto-restart are started on that host. What should happen is those services 
> should be ignored and excluded from auto-restart as the host is in 
> maintenance mode. Currently, auto-start respects maintenance mode on 
> component level alone.



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


[jira] [Commented] (AMBARI-18755) Deployment failing at creating principal

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18755:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #351 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/351/])
AMBARI-18755. Deployment failing at creating principal (smohanty: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=7620635ee45b1418253a96e20c2852db4eadca50])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/MITKerberosOperationHandler.java


> Deployment failing at creating principal
> 
>
> Key: AMBARI-18755
> URL: https://issues.apache.org/jira/browse/AMBARI-18755
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Vivek Rathod
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-18755.addendum.3.patch, 
> AMBARI-18755.addendum.patch, AMBARI-18755.patch
>
>
> Cluster deployment via blueprint failed at creating principals



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


[jira] [Updated] (AMBARI-18916) Manage JournalNodes Wizard: Text adjustments

2016-11-16 Thread Richard Zang (JIRA)

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

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

> Manage JournalNodes Wizard: Text adjustments
> 
>
> Key: AMBARI-18916
> URL: https://issues.apache.org/jira/browse/AMBARI-18916
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.5.0
>
> Attachments: AMBARI-18916.patch
>
>
> Text adjustments for Manage JournalNodes Wizard



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


[jira] [Updated] (AMBARI-18916) Manage JournalNodes Wizard: Text adjustments

2016-11-16 Thread Richard Zang (JIRA)

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

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

Committed to trunk and 2.5 61a703600667df68fbf80425ecd0e8e0b4e61a77

> Manage JournalNodes Wizard: Text adjustments
> 
>
> Key: AMBARI-18916
> URL: https://issues.apache.org/jira/browse/AMBARI-18916
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.5.0
>
> Attachments: AMBARI-18916.patch
>
>
> Text adjustments for Manage JournalNodes Wizard



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


[jira] [Updated] (AMBARI-18916) Manage JournalNodes Wizard: Text adjustments

2016-11-16 Thread Richard Zang (JIRA)

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

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

> Manage JournalNodes Wizard: Text adjustments
> 
>
> Key: AMBARI-18916
> URL: https://issues.apache.org/jira/browse/AMBARI-18916
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.5.0
>
> Attachments: AMBARI-18916.patch
>
>
> Text adjustments for Manage JournalNodes Wizard



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


[jira] [Updated] (AMBARI-18912) Implement Create Alerts: step 1 select alert type

2016-11-16 Thread Xi Wang (JIRA)

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

Xi Wang updated AMBARI-18912:
-
Attachment: (was: AMBARI-18912.patch)

> Implement Create Alerts: step 1 select alert type
> -
>
> Key: AMBARI-18912
> URL: https://issues.apache.org/jira/browse/AMBARI-18912
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
> Fix For: 2.5.0
>
> Attachments: AMBARI-18912.patch, Screen Shot 2016-11-16 at 6.13.51 
> PM.png
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> This is a FE task to implement the "Create Alerts Wizard " based on the 
> design attached.
> In this task, should implement the step 1 in the design. All available alert 
> types should be displayed as options with icon, type and description. Make 
> sure that on clicking a type use would jump to next step.



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


[jira] [Updated] (AMBARI-18912) Implement Create Alerts: step 1 select alert type

2016-11-16 Thread Xi Wang (JIRA)

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

Xi Wang updated AMBARI-18912:
-
Attachment: AMBARI-18912.patch

> Implement Create Alerts: step 1 select alert type
> -
>
> Key: AMBARI-18912
> URL: https://issues.apache.org/jira/browse/AMBARI-18912
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
> Fix For: 2.5.0
>
> Attachments: AMBARI-18912.patch, Screen Shot 2016-11-16 at 6.13.51 
> PM.png
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> This is a FE task to implement the "Create Alerts Wizard " based on the 
> design attached.
> In this task, should implement the step 1 in the design. All available alert 
> types should be displayed as options with icon, type and description. Make 
> sure that on clicking a type use would jump to next step.



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


[jira] [Updated] (AMBARI-18912) Implement Create Alerts: step 1 select alert type

2016-11-16 Thread Xi Wang (JIRA)

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

Xi Wang updated AMBARI-18912:
-
Attachment: Screen Shot 2016-11-16 at 6.13.51 PM.png

> Implement Create Alerts: step 1 select alert type
> -
>
> Key: AMBARI-18912
> URL: https://issues.apache.org/jira/browse/AMBARI-18912
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
> Fix For: 2.5.0
>
> Attachments: AMBARI-18912.patch, Screen Shot 2016-11-16 at 6.13.51 
> PM.png
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> This is a FE task to implement the "Create Alerts Wizard " based on the 
> design attached.
> In this task, should implement the step 1 in the design. All available alert 
> types should be displayed as options with icon, type and description. Make 
> sure that on clicking a type use would jump to next step.



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


[jira] [Updated] (AMBARI-18912) Implement Create Alerts: step 1 select alert type

2016-11-16 Thread Xi Wang (JIRA)

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

Xi Wang updated AMBARI-18912:
-
Status: Patch Available  (was: Open)

> Implement Create Alerts: step 1 select alert type
> -
>
> Key: AMBARI-18912
> URL: https://issues.apache.org/jira/browse/AMBARI-18912
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
> Fix For: 2.5.0
>
> Attachments: AMBARI-18912.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> This is a FE task to implement the "Create Alerts Wizard " based on the 
> design attached.
> In this task, should implement the step 1 in the design. All available alert 
> types should be displayed as options with icon, type and description. Make 
> sure that on clicking a type use would jump to next step.



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


[jira] [Updated] (AMBARI-18912) Implement Create Alerts: step 1 select alert type

2016-11-16 Thread Xi Wang (JIRA)

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

Xi Wang updated AMBARI-18912:
-
Attachment: AMBARI-18912.patch

> Implement Create Alerts: step 1 select alert type
> -
>
> Key: AMBARI-18912
> URL: https://issues.apache.org/jira/browse/AMBARI-18912
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
> Fix For: 2.5.0
>
> Attachments: AMBARI-18912.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> This is a FE task to implement the "Create Alerts Wizard " based on the 
> design attached.
> In this task, should implement the step 1 in the design. All available alert 
> types should be displayed as options with icon, type and description. Make 
> sure that on clicking a type use would jump to next step.



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


[jira] [Updated] (AMBARI-18903) Implement Create Alerts: Create a base wizard for all steps

2016-11-16 Thread Xi Wang (JIRA)

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

Xi Wang updated AMBARI-18903:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to trunk and branch-2.5

> Implement Create Alerts: Create a base wizard for all steps
> ---
>
> Key: AMBARI-18903
> URL: https://issues.apache.org/jira/browse/AMBARI-18903
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18903.patch
>
>
> This is a FE task to implement the "Create Alerts Wizard " based on the 
> design attached.
> This task is to create the the following files so that we have a blank base 
> wizard as a start point.
> *4 controllers* in folder: controllers/main/alerts/create
> wizard_controller.js  (should extend App.WizardController)
> step1_controller.js
> step2_controller.js
> step3_controller.js
> *4 views* in folder: views/main/alerts/create
> wizard_view.js  (extend sApp.WizardMenuMixin)
> step1_view.js
> step2_view.js
> step3_view.js
> *4 templates* in folder: templates/main/alerts/create
> wizard.hbs 
> step1.hbs
> step2.hbs
> step3.hbs



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


[jira] [Updated] (AMBARI-18903) Implement Create Alerts: Create a base wizard for all steps

2016-11-16 Thread Xi Wang (JIRA)

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

Xi Wang updated AMBARI-18903:
-
Status: Patch Available  (was: Open)

> Implement Create Alerts: Create a base wizard for all steps
> ---
>
> Key: AMBARI-18903
> URL: https://issues.apache.org/jira/browse/AMBARI-18903
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18903.patch
>
>
> This is a FE task to implement the "Create Alerts Wizard " based on the 
> design attached.
> This task is to create the the following files so that we have a blank base 
> wizard as a start point.
> *4 controllers* in folder: controllers/main/alerts/create
> wizard_controller.js  (should extend App.WizardController)
> step1_controller.js
> step2_controller.js
> step3_controller.js
> *4 views* in folder: views/main/alerts/create
> wizard_view.js  (extend sApp.WizardMenuMixin)
> step1_view.js
> step2_view.js
> step3_view.js
> *4 templates* in folder: templates/main/alerts/create
> wizard.hbs 
> step1.hbs
> step2.hbs
> step3.hbs



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


[jira] [Commented] (AMBARI-18755) Deployment failing at creating principal

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18755:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6032 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6032/])
AMBARI-18755. Deployment failing at creating principal (smohanty: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=ae1a98198c28ac8a3210fe21c0ce480095f21469])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/MITKerberosOperationHandler.java


> Deployment failing at creating principal
> 
>
> Key: AMBARI-18755
> URL: https://issues.apache.org/jira/browse/AMBARI-18755
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Vivek Rathod
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-18755.addendum.3.patch, 
> AMBARI-18755.addendum.patch, AMBARI-18755.patch
>
>
> Cluster deployment via blueprint failed at creating principals



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


[jira] [Updated] (AMBARI-18907) Auto-start should respect maintenance mode on hosts and services

2016-11-16 Thread Nahappan Somasundaram (JIRA)

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

Nahappan Somasundaram updated AMBARI-18907:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Auto-start should respect maintenance mode on hosts and services
> 
>
> Key: AMBARI-18907
> URL: https://issues.apache.org/jira/browse/AMBARI-18907
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: rb53811.patch
>
>
> Auto-start should respect maintenance mode. If any host or service (meaning 
> it's host components) or component is in maintenance mode, the auto-start 
> directive should be ignored.
> Maintenance mode is ignored at host and service level. If you mark a host as 
> in maintenance mode, and then restart the host, the services marked for 
> auto-restart are started on that host. What should happen is those services 
> should be ignored and excluded from auto-restart as the host is in 
> maintenance mode. Currently, auto-start respects maintenance mode on 
> component level alone.



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


[jira] [Commented] (AMBARI-18915) Update AMS pom to use Apache hbase,hadoop,phoenix tarballs

2016-11-16 Thread Siddharth Wagle (JIRA)

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

Siddharth Wagle commented on AMBARI-18915:
--

+1 Don;t forget documentation for config change to disable SNAPPY.

> Update AMS pom to use Apache hbase,hadoop,phoenix tarballs
> --
>
> Key: AMBARI-18915
> URL: https://issues.apache.org/jira/browse/AMBARI-18915
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18915.patch
>
>
> Ambari Metrics Service have a specific dependency on HDP tarballs. Ideally 
> this dependency is not desired. Apache should be self sufficient without 
> dependencies on a particular distribution.



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


[jira] [Comment Edited] (AMBARI-18915) Update AMS pom to use Apache hbase,hadoop,phoenix tarballs

2016-11-16 Thread Siddharth Wagle (JIRA)

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

Siddharth Wagle edited comment on AMBARI-18915 at 11/17/16 1:14 AM:


+1 Don't forget documentation for config change to disable SNAPPY.


was (Author: swagle):
+1 Don;t forget documentation for config change to disable SNAPPY.

> Update AMS pom to use Apache hbase,hadoop,phoenix tarballs
> --
>
> Key: AMBARI-18915
> URL: https://issues.apache.org/jira/browse/AMBARI-18915
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18915.patch
>
>
> Ambari Metrics Service have a specific dependency on HDP tarballs. Ideally 
> this dependency is not desired. Apache should be self sufficient without 
> dependencies on a particular distribution.



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


[jira] [Updated] (AMBARI-18915) Update AMS pom to use Apache hbase,hadoop,phoenix tarballs

2016-11-16 Thread Aravindan Vijayan (JIRA)

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

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

> Update AMS pom to use Apache hbase,hadoop,phoenix tarballs
> --
>
> Key: AMBARI-18915
> URL: https://issues.apache.org/jira/browse/AMBARI-18915
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18915.patch
>
>
> Ambari Metrics Service have a specific dependency on HDP tarballs. Ideally 
> this dependency is not desired. Apache should be self sufficient without 
> dependencies on a particular distribution.



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


[jira] [Updated] (AMBARI-18915) Update AMS pom to use Apache hbase,hadoop,phoenix tarballs

2016-11-16 Thread Aravindan Vijayan (JIRA)

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

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

> Update AMS pom to use Apache hbase,hadoop,phoenix tarballs
> --
>
> Key: AMBARI-18915
> URL: https://issues.apache.org/jira/browse/AMBARI-18915
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18915.patch
>
>
> Ambari Metrics Service have a specific dependency on HDP tarballs. Ideally 
> this dependency is not desired. Apache should be self sufficient without 
> dependencies on a particular distribution.



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


[jira] [Commented] (AMBARI-18755) Deployment failing at creating principal

2016-11-16 Thread Sumit Mohanty (JIRA)

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

Sumit Mohanty commented on AMBARI-18755:


Ran unit tests locally

{code}
--
Ran 269 tests in 6.888s

OK
--
Total run:1126
Total errors:0
Total failures:0
OK
[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] Ambari Views .. SUCCESS [1.960s]
[INFO] Ambari Metrics Common . SUCCESS [1.019s]
[INFO] Ambari Server . SUCCESS [1:51.969s]
[INFO] 
{code}

> Deployment failing at creating principal
> 
>
> Key: AMBARI-18755
> URL: https://issues.apache.org/jira/browse/AMBARI-18755
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Vivek Rathod
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-18755.addendum.3.patch, 
> AMBARI-18755.addendum.patch, AMBARI-18755.patch
>
>
> Cluster deployment via blueprint failed at creating principals



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


[jira] [Created] (AMBARI-18915) Update AMS pom to use Apache hbase,hadoop,phoenix tarballs

2016-11-16 Thread Aravindan Vijayan (JIRA)
Aravindan Vijayan created AMBARI-18915:
--

 Summary: Update AMS pom to use Apache hbase,hadoop,phoenix tarballs
 Key: AMBARI-18915
 URL: https://issues.apache.org/jira/browse/AMBARI-18915
 Project: Ambari
  Issue Type: Task
  Components: ambari-metrics
Affects Versions: 2.5.0
Reporter: Aravindan Vijayan
Assignee: Aravindan Vijayan
Priority: Critical
 Fix For: 2.5.0


Ambari Metrics Service have a specific dependency on HDP tarballs. Ideally this 
dependency is not desired. Apache should be self sufficient without 
dependencies on a particular distribution.



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


[jira] [Commented] (AMBARI-18905) Management pack purge option should support extensions

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18905:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6031 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6031/])
AMBARI-18905 - Management pack purge option should support extensions (tthorpe: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=d1b14bd0d8d843e8ac8bb39a8c2c6579f615])
* (edit) ambari-server/src/test/python/TestMpacks.py
* (edit) ambari-server/src/main/python/ambari_server/setupMpacks.py


> Management pack purge option should support extensions
> --
>
> Key: AMBARI-18905
> URL: https://issues.apache.org/jira/browse/AMBARI-18905
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: trunk, 2.4.0, 2.5.0
>Reporter: Tim Thorpe
>Assignee: Tim Thorpe
>Priority: Minor
> Fix For: trunk, 2.5.0
>
> Attachments: AMBARI-18905.patch
>
>
> Currently you can add extensions but you can't purge them.



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


[jira] [Commented] (AMBARI-18897) HBase conf directory should not have a copy of core-site.xml and hdfs-site.xml

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18897:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6031 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6031/])
AMBARI-18897. HBase conf directory should not have a copy of (vbrodetskyi: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=b5779fe6dca4db7df15abd905ef4b3dfae9d2c03])
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.0.6/properties/stack_features.json
* (edit) 
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/hbase.py
* (edit) ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_master.py
* (edit) 
ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_regionserver.py
* (edit) 
ambari-common/src/main/python/resource_management/libraries/functions/constants.py
* (edit) 
ambari-server/src/test/python/stacks/2.0.6/HBASE/test_phoenix_queryserver.py
* (edit) ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_client.py


> HBase conf directory should not have a copy of core-site.xml and hdfs-site.xml
> --
>
> Key: AMBARI-18897
> URL: https://issues.apache.org/jira/browse/AMBARI-18897
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18897.patch
>
>
> /etc/hbase/conf/ contains core-site.xml and hdfs-site.xml which should not be 
> needed at all. But more importantly, when we change a setting in Ambari, they 
> do not get reflected in the hdfs-site.xml that is under the hbase conf 
> directory. Since there are more than 1 core-site.xml in the classpath, this 
> obviously causes issues since the changed configs are not picked up.



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


[jira] [Commented] (AMBARI-18903) Implement Create Alerts: Create a base wizard for all steps

2016-11-16 Thread Xi Wang (JIRA)

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

Xi Wang commented on AMBARI-18903:
--

Got +1 from review board

> Implement Create Alerts: Create a base wizard for all steps
> ---
>
> Key: AMBARI-18903
> URL: https://issues.apache.org/jira/browse/AMBARI-18903
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18903.patch
>
>
> This is a FE task to implement the "Create Alerts Wizard " based on the 
> design attached.
> This task is to create the the following files so that we have a blank base 
> wizard as a start point.
> *4 controllers* in folder: controllers/main/alerts/create
> wizard_controller.js  (should extend App.WizardController)
> step1_controller.js
> step2_controller.js
> step3_controller.js
> *4 views* in folder: views/main/alerts/create
> wizard_view.js  (extend sApp.WizardMenuMixin)
> step1_view.js
> step2_view.js
> step3_view.js
> *4 templates* in folder: templates/main/alerts/create
> wizard.hbs 
> step1.hbs
> step2.hbs
> step3.hbs



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


[jira] [Commented] (AMBARI-18911) Storm start is failing due to metrics initialization error

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18911:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6031 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6031/])
AMBARI-18911 : Storm start is failing due to metrics initialization (avijayan: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=940143eea80270919f57fe197375b8691c10e3aa])
* (add) 
ambari-metrics/ambari-metrics-common/src/test/java/org/apache/hadoop/metrics2/sink/timeline/availability/AbstractTimelineMetricSinkTest.java
* (edit) 
ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/AbstractTimelineMetricsSink.java
* (edit) ambari-metrics/ambari-metrics-common/pom.xml


> Storm start is failing due to metrics initialization error
> --
>
> Key: AMBARI-18911
> URL: https://issues.apache.org/jira/browse/AMBARI-18911
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Blocker
> Fix For: 2.5.0
>
> Attachments: AMBARI-18911.patch
>
>
> {code}
> 2016-11-10 07:14:58.311 o.a.s.d.nimbus [ERROR] Error on initialization of 
> server service-handler
> java.lang.RuntimeException: Could not instantiate a class listed in config 
> under section storm.cluster.metrics.consumer.register with fully qualified 
> name org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
> at 
> org.apache.storm.metric.ClusterMetricsConsumerExecutor.prepare(ClusterMetricsConsumerExecutor.java:50)
> 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__11381$exec_fn__3535__auto11382.invoke(nimbus.clj:2192)
> 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__11381$service_handler__11417.doInvoke(nimbus.clj:2169)
> at clojure.lang.RestFn.invoke(RestFn.java:421)
> at 
> org.apache.storm.daemon.nimbus$launch_server_BANG_.invoke(nimbus.clj:2258)
> at org.apache.storm.daemon.nimbus$_launch.invoke(nimbus.clj:2291)
> at org.apache.storm.daemon.nimbus$_main.invoke(nimbus.clj:2314)
> 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: 
> org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
> 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)
> 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)
> {code}
> in some of the cluster we are seeing following error too:
> {code}
> 2016-11-10 07:56:06.674 o.a.s.zookeeper [INFO] Accepting leadership, all 
> active topology found localy.
> 2016-11-10 07:56:07.125 o.a.s.d.nimbus [ERROR] Error when processing event
> java.lang.NullPointerException
> at 
> clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:301)
> at 
> org.apache.storm.daemon.nimbus$get_cluster_info$fn__11126.invoke(nimbus.clj:1385)
> at 
> org.apache.storm.daemon.nimbus$get_cluster_info.invoke(nimbus.clj:1384)
> at 
> org.apache.storm.daemon.nimbus$send_cluster_metrics_to_executors.invoke(nimbus.clj:1445)
> at 
> org.apache.storm.daemon.nimbus$fn__11381$exec_fn__3535__auto11382$fn__11408.invoke(nimbus.clj:2244)
> at 
> org.apache.storm.timer$schedule_recurring$this__2162.invoke(timer.clj:105)
> at 
> org.apache.storm.timer$mk_timer$fn__2145$fn__2146.invoke(timer.clj:50)
> at org.apache.storm.timer$mk_timer$fn__2145.invoke(timer.clj:42)
> at clojure.lang.AFn.run(AFn.java:22)
> at java.lang.Thread.run(Thread.java:745)
> 2016-11-10 07:56:07.128 o.a.s.util 

[jira] [Commented] (AMBARI-18740) Perf: Automate deployment of PERF stack on 2500+ Ambari Agents

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18740:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6031 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6031/])
AMBARI-18740. Perf: Automate deployment of PERF stack on 2500+ Ambari 
(vbrodetskyi: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=f7b346b825056b27ce04957867ee3e073bccfed7])
* (add) contrib/utils/perf/deploy-gce-perf-cluster.py


> Perf: Automate deployment of PERF stack on 2500+ Ambari Agents
> --
>
> Key: AMBARI-18740
> URL: https://issues.apache.org/jira/browse/AMBARI-18740
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-agent
>Affects Versions: 2.5.0
>Reporter: Alejandro Fernandez
>Assignee: Vitaly Brodetskyi
> Fix For: 2.5.0
>
> Attachments: AMBARI-18740.patch
>
>
> We need automation to enable the deployment of 2500+ Agents.
> This may either be local using Vagrant or GCE.
> Local: Assume 5-10 VMs running CentOS 6
> GCE: Assume 50-500 VMs running CentOS 6
> The script should be able to
> # provision the VMs
> # install Ambari Server
> # install Ambari Agent
> # run the simulator with the number of Agents (and point it to the server)
> # deploy cluster with Blueprint



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


[jira] [Commented] (AMBARI-18903) Implement Create Alerts: Create a base wizard for all steps

2016-11-16 Thread Xi Wang (JIRA)

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

Xi Wang commented on AMBARI-18903:
--

30621 tests complete (2 minutes)
  151 tests pending

> Implement Create Alerts: Create a base wizard for all steps
> ---
>
> Key: AMBARI-18903
> URL: https://issues.apache.org/jira/browse/AMBARI-18903
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18903.patch
>
>
> This is a FE task to implement the "Create Alerts Wizard " based on the 
> design attached.
> This task is to create the the following files so that we have a blank base 
> wizard as a start point.
> *4 controllers* in folder: controllers/main/alerts/create
> wizard_controller.js  (should extend App.WizardController)
> step1_controller.js
> step2_controller.js
> step3_controller.js
> *4 views* in folder: views/main/alerts/create
> wizard_view.js  (extend sApp.WizardMenuMixin)
> step1_view.js
> step2_view.js
> step3_view.js
> *4 templates* in folder: templates/main/alerts/create
> wizard.hbs 
> step1.hbs
> step2.hbs
> step3.hbs



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


[jira] [Updated] (AMBARI-18755) Deployment failing at creating principal

2016-11-16 Thread Sumit Mohanty (JIRA)

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

Sumit Mohanty updated AMBARI-18755:
---
Attachment: AMBARI-18755.addendum.3.patch

> Deployment failing at creating principal
> 
>
> Key: AMBARI-18755
> URL: https://issues.apache.org/jira/browse/AMBARI-18755
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Vivek Rathod
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-18755.addendum.3.patch, 
> AMBARI-18755.addendum.patch, AMBARI-18755.patch
>
>
> Cluster deployment via blueprint failed at creating principals



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


[jira] [Commented] (AMBARI-18907) Auto-start should respect maintenance mode on hosts and services

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18907:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #349 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/349/])
AMBARI-18907: Auto-start should respect maintenance mode on hosts and 
(nsomasundaram: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=6a58b4b400303e93aefcceeccf0ebf8aef851a4d])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/state/host/HostImpl.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/events/MaintenanceModeEvent.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/agent/RecoveryConfigHelper.java
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/events/listeners/upgrade/AlertMaintenanceModeListenerTest.java


> Auto-start should respect maintenance mode on hosts and services
> 
>
> Key: AMBARI-18907
> URL: https://issues.apache.org/jira/browse/AMBARI-18907
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: rb53811.patch
>
>
> Auto-start should respect maintenance mode. If any host or service (meaning 
> it's host components) or component is in maintenance mode, the auto-start 
> directive should be ignored.
> Maintenance mode is ignored at host and service level. If you mark a host as 
> in maintenance mode, and then restart the host, the services marked for 
> auto-restart are started on that host. What should happen is those services 
> should be ignored and excluded from auto-restart as the host is in 
> maintenance mode. Currently, auto-start respects maintenance mode on 
> component level alone.



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


[jira] [Comment Edited] (AMBARI-18755) Deployment failing at creating principal

2016-11-16 Thread Robert Levas (JIRA)

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

Robert Levas edited comment on AMBARI-18755 at 11/17/16 12:26 AM:
--

[~sumitmohanty]

Maybe we should add a comment declaring the delay else +1 for the addendum 
patch - [^AMBARI-18755.addendum.patch]



was (Author: rlevas):
[~sumitmohanty]

+1 for the addendum patch - [^AMBARI-18755.addendum.patch]


> Deployment failing at creating principal
> 
>
> Key: AMBARI-18755
> URL: https://issues.apache.org/jira/browse/AMBARI-18755
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Vivek Rathod
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-18755.addendum.patch, AMBARI-18755.patch
>
>
> Cluster deployment via blueprint failed at creating principals



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


[jira] [Comment Edited] (AMBARI-18755) Deployment failing at creating principal

2016-11-16 Thread Robert Levas (JIRA)

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

Robert Levas edited comment on AMBARI-18755 at 11/17/16 12:24 AM:
--

[~sumit]

+1 for the addendum patch - [^AMBARI-18755.addendum.patch]




was (Author: rlevas):
+1 for the addendum patch - [^AMBARI-18755.addendum.patch]


> Deployment failing at creating principal
> 
>
> Key: AMBARI-18755
> URL: https://issues.apache.org/jira/browse/AMBARI-18755
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Vivek Rathod
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-18755.addendum.patch, AMBARI-18755.patch
>
>
> Cluster deployment via blueprint failed at creating principals



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


[jira] [Comment Edited] (AMBARI-18755) Deployment failing at creating principal

2016-11-16 Thread Robert Levas (JIRA)

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

Robert Levas edited comment on AMBARI-18755 at 11/17/16 12:25 AM:
--

[~sumitmohanty]

+1 for the addendum patch - [^AMBARI-18755.addendum.patch]



was (Author: rlevas):
[~sumit]

+1 for the addendum patch - [^AMBARI-18755.addendum.patch]



> Deployment failing at creating principal
> 
>
> Key: AMBARI-18755
> URL: https://issues.apache.org/jira/browse/AMBARI-18755
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Vivek Rathod
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-18755.addendum.patch, AMBARI-18755.patch
>
>
> Cluster deployment via blueprint failed at creating principals



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


[jira] [Commented] (AMBARI-18755) Deployment failing at creating principal

2016-11-16 Thread Robert Levas (JIRA)

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

Robert Levas commented on AMBARI-18755:
---

+1 for the addendum patch - [^AMBARI-18755.addendum.patch]


> Deployment failing at creating principal
> 
>
> Key: AMBARI-18755
> URL: https://issues.apache.org/jira/browse/AMBARI-18755
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Vivek Rathod
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-18755.addendum.patch, AMBARI-18755.patch
>
>
> Cluster deployment via blueprint failed at creating principals



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


[jira] [Commented] (AMBARI-18913) Hive view service check fails first time after server restart

2016-11-16 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on AMBARI-18913:


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

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

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

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

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

{color:red}-1 core tests{color}.  The test build failed in 
contrib/views/hive-next 

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

This message is automatically generated.

> Hive view service check fails first time after server restart
> -
>
> Key: AMBARI-18913
> URL: https://issues.apache.org/jira/browse/AMBARI-18913
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.2
>Reporter: Ashwin Rajeev
>Assignee: Ashwin Rajeev
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18913.trunk.patch
>
>
> Hive view service checks fail intermittently when the cluster is Kerberized



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


[jira] [Commented] (AMBARI-18827) Allow acceptor / seclector configuration for API and agent connectors

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18827:
-

ABORTED: Integrated in Jenkins build Ambari-trunk-Commit #6030 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6030/])
AMBARI-18827. Allow acceptor / seclector configuration for API and agent 
(swagle: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=d92dc0ed47172f69293c1052ef2b7244462bb893])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java


> Allow acceptor / seclector configuration for API and agent connectors
> -
>
> Key: AMBARI-18827
> URL: https://issues.apache.org/jira/browse/AMBARI-18827
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.2.1
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18827-1.patch, AMBARI-18827.patch
>
>
> _Objectives_:
> - Allow acceptors for agent and api connectors to be configurable
> - The thread pool configuration did not take into account both 2-way and 
> 1-way connectors are configured for agent every time although only one is 
> used and not a mixed-mode. This causes insufficient threads in agent 
> threadpool for a high cpu core environment.



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


[jira] [Commented] (AMBARI-18476) Ambari UI changes to support PAM authentication

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18476:
-

ABORTED: Integrated in Jenkins build Ambari-trunk-Commit #6030 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6030/])
AMBARI-18476: Ambari UI changes to support PAM authentication (Sangeeta (dili: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=745d1057b04f1ecf8a089d437e49a1ef672c2090])
* (edit) ambari-admin/src/main/resources/ui/admin-web/app/index.html
* (edit) 
ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/Group.js
* (edit) ambari-admin/src/main/resources/ui/admin-web/app/views/groups/edit.html
* (edit) ambari-admin/src/main/resources/ui/admin-web/app/scripts/i18n.config.js
* (edit) 
ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/groups/GroupsListCtrl.js
* (edit) 
ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/UserConstants.js
* (add) 
ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/GroupConstants.js
* (edit) ambari-admin/src/main/resources/ui/admin-web/app/views/groups/list.html
* (edit) 
ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/users/UsersShowCtrl.js
* (edit) 
ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/groups/GroupsEditCtrl.js
* (edit) ambari-admin/src/main/resources/ui/admin-web/app/views/users/show.html


> Ambari UI changes to support PAM authentication
> ---
>
> Key: AMBARI-18476
> URL: https://issues.apache.org/jira/browse/AMBARI-18476
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: trunk
>Reporter: Sangeeta Ravindran
>Assignee: Sangeeta Ravindran
> Fix For: trunk, 2.5.0
>
> Attachments: AMBARI-18476.patch, AMBARI-18476_2.5patch
>
>
> AMBARI-12263 adds support for PAM as authentication mechanism for accessing 
> Ambari UI/REST. 
> Since a new column group_type has been added for groups, the UI will display 
> labels for group type and enable/disable group delete/add member 
> functionality based on the group_type instead of the ldap_group flag.
> The user_type will be used to determine if the user can be deleted or if the 
> user's password can be changed.



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


[jira] [Commented] (AMBARI-18910) SSL/TLS protocols should be explicitly enabled and then filtered when Ambari starts up

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18910:
-

ABORTED: Integrated in Jenkins build Ambari-trunk-Commit #6030 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6030/])
AMBARI-18910. SSL/TLS protocols should be explicitly enabled and then (rlevas: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=430ecee6139c413faee7a8ed14a988181688cd54])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java


> SSL/TLS protocols should be explicitly enabled and then filtered when Ambari 
> starts up
> --
>
> Key: AMBARI-18910
> URL: https://issues.apache.org/jira/browse/AMBARI-18910
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18910_branch-2.4_01.patch, 
> AMBARI-18910_branch-2.5_01.patch
>
>
> SSL/TLS protocols should be explicitly enabled and then filtered when Ambari 
> starts up.
> Currently the following protocols are explicitly enabled: 
> * {{SSLv2Hello}}
> * {{TLSv1}}
> {code:title=org/apache/ambari/server/controller/AmbariServer.java:718} 
> factory.setIncludeProtocols(new String[] { "SSLv2Hello","TLSv1"});
> {code}
> However the following protocols should be enabled by default:
> * {{SSLv2Hello}}
> * {{TLSv1}}
> * {{TLSv1.1}}
> * {{TLSv1.2}}
> * {{SSLv3}}
> {code:title=Example} 
> factory.setIncludeProtocols(new String[] 
> {"SSLv2Hello","SSLv3","TLSv1","TLSv1.1","TLSv1.2"});{code}
> Once set, the protocols may be filtered out using the 
> {{security.server.disabled.protocols}} property from the ambari.properties 
> file. For example:
> {code:title=Disables TLSv1, TLSv1.1, and SSLv2Hello}
> security.server.disabled.protocols=TLSv1.1|TLSv1|SSLv2Hello
> {code}
> The availability of a particular protocol may be tested using the OpenSSL 
> s_client facility.
> {noformat:title=Example: Test for TLSv1.2}
> openssl s_client -connect localhost:8440 -tls1_2
> {noformat}
> {noformat:title=Example successful result}
> CONNECTED(0003)
> depth=0 C = XX, L = Default City, O = Default Company Ltd
> verify error:num=18:self signed certificate
> verify return:1
> depth=0 C = XX, L = Default City, O = Default Company Ltd
> verify return:1
> ---
> Certificate chain
> 0 s:/C=XX/L=Default City/O=Default Company Ltd
>i:/C=XX/L=Default City/O=Default Company Ltd
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MII…
> -END CERTIFICATE-
> subject=/C=XX/L=Default City/O=Default Company Ltd
> issuer=/C=XX/L=Default City/O=Default Company Ltd
> ---
> No client certificate CA names sent
> Server Temp Key: ECDH, secp521r1, 521 bits
> ---
> SSL handshake has read 2248 bytes and written 441 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
> Server public key is 4096 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: ECDHE-RSA-AES256-GCM-SHA384
> Session-ID: 
> 5829F75B49C2FED58C60CB7663181B39BCA3AF473F253EDB4BA04D827B9D58BA
> Session-ID-ctx:
> Master-Key: 
> 46301FB9B4263547C62F8C793380319DC60A10C1D077C7DAB52D328B12D1FB4B868EE5131CD7F62917C02866196317B8
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> Start Time: 1479145307
> Timeout   : 7200 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> {noformat}
> {noformat:title=Example failure result}
> CONNECTED(0003)
> 140518067173192:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake 
> failure:s3_pkt.c:598:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 0 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: 
> Session-ID:
> Session-ID-ctx:
> Master-Key:
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> Start Time: 1479145122
> Timeout   : 7200 (sec)
> Verify return code: 0 (ok)
> ---
> {noformat}
> Note: This does not address the agent-side issue of connecting to an Ambari 
> server where TLSv1 is disabled.  See AMBARI-17666.



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


[jira] [Commented] (AMBARI-18872) Zeppelin notebook execution fails due missing spark dependency

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18872:
-

ABORTED: Integrated in Jenkins build Ambari-trunk-Commit #6030 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6030/])
AMBARI-18872 Zeppelin notebook execution fails due missing spark 
(renjith.kamath: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=49d6d88dcf7ed8c15152cdca7bc1fbf2ba6c8d5a])
* (edit) ambari-server/src/main/resources/scripts/Ambaripreupload.py
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.6/services/ZEPPELIN/metainfo.xml
* (edit) 
ambari-server/src/main/resources/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py


> Zeppelin notebook execution fails due missing spark dependency
> --
>
> Key: AMBARI-18872
> URL: https://issues.apache.org/jira/browse/AMBARI-18872
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
> Fix For: 2.5.0
>
> Attachments: AMBARI-18872-branch-2.5-v1.patch, 
> AMBARI-18872-branch-2.5-v2.patch
>
>
> {code}
> org.apache.hadoop.security.AccessControlException: Permission denied: 
> user=zeppelin, access=WRITE, 
> inode="/user/zeppelin/.sparkStaging/application_1478558403343_0012":hdfs:hdfs:drwxr-xr-x
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:319)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:292)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:213)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:190)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1827)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1811)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkAncestorAccess(FSDirectory.java:1794)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirMkdirOp.mkdirs(FSDirMkdirOp.java:71)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.mkdirs(FSNamesystem.java:4017)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.mkdirs(NameNodeRpcServer.java:1102)
> at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.mkdirs(ClientNamenodeProtocolServerSideTranslatorPB.java:630)
> at 
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
> at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:640)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:982)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2313)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2309)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1724)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2307)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at 
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
> at 
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:73)
> at org.apache.hadoop.hdfs.DFSClient.primitiveMkdir(DFSClient.java:3063)
> at org.apache.hadoop.hdfs.DFSClient.mkdirs(DFSClient.java:3031)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem$24.doCall(DistributedFileSystem.java:1162)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem$24.doCall(DistributedFileSystem.java:1158)
> at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem.mkdirsInternal(DistributedFileSystem.java:1158)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem.mkdirs(DistributedFileSystem.java:1150)
> at org.apache.hadoop.fs.FileSystem.mkdirs(FileSystem.java:1898)
> at org.apache.hadoop.fs.FileSystem.mkdirs(FileSystem.java:613)
> at org.apache.spark.deploy.yarn.Client.prepareLocalResources(Client.scala:394)
> at 
> org.apache.spark.deploy.yarn.Client.createContainerLaunchContext(Client.scala:763)
> at 

[jira] [Commented] (AMBARI-18897) HBase conf directory should not have a copy of core-site.xml and hdfs-site.xml

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18897:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #348 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/348/])
AMBARI-18897. HBase conf directory should not have a copy of (vbrodetskyi: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=3c3d3d23d4713954e0ac487c87c3f1283a34b284])
* (edit) 
ambari-common/src/main/python/resource_management/libraries/functions/constants.py
* (edit) ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_client.py
* (edit) 
ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_regionserver.py
* (edit) 
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/hbase.py
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.0.6/properties/stack_features.json
* (edit) ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_master.py
* (edit) 
ambari-server/src/test/python/stacks/2.0.6/HBASE/test_phoenix_queryserver.py


> HBase conf directory should not have a copy of core-site.xml and hdfs-site.xml
> --
>
> Key: AMBARI-18897
> URL: https://issues.apache.org/jira/browse/AMBARI-18897
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18897.patch
>
>
> /etc/hbase/conf/ contains core-site.xml and hdfs-site.xml which should not be 
> needed at all. But more importantly, when we change a setting in Ambari, they 
> do not get reflected in the hdfs-site.xml that is under the hbase conf 
> directory. Since there are more than 1 core-site.xml in the classpath, this 
> obviously causes issues since the changed configs are not picked up.



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


[jira] [Commented] (AMBARI-18911) Storm start is failing due to metrics initialization error

2016-11-16 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on AMBARI-18911:


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

This message is automatically generated.

> Storm start is failing due to metrics initialization error
> --
>
> Key: AMBARI-18911
> URL: https://issues.apache.org/jira/browse/AMBARI-18911
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Blocker
> Fix For: 2.5.0
>
> Attachments: AMBARI-18911.patch
>
>
> {code}
> 2016-11-10 07:14:58.311 o.a.s.d.nimbus [ERROR] Error on initialization of 
> server service-handler
> java.lang.RuntimeException: Could not instantiate a class listed in config 
> under section storm.cluster.metrics.consumer.register with fully qualified 
> name org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
> at 
> org.apache.storm.metric.ClusterMetricsConsumerExecutor.prepare(ClusterMetricsConsumerExecutor.java:50)
> 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__11381$exec_fn__3535__auto11382.invoke(nimbus.clj:2192)
> 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__11381$service_handler__11417.doInvoke(nimbus.clj:2169)
> at clojure.lang.RestFn.invoke(RestFn.java:421)
> at 
> org.apache.storm.daemon.nimbus$launch_server_BANG_.invoke(nimbus.clj:2258)
> at org.apache.storm.daemon.nimbus$_launch.invoke(nimbus.clj:2291)
> at org.apache.storm.daemon.nimbus$_main.invoke(nimbus.clj:2314)
> 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: 
> org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
> 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)
> 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)
> {code}
> in some of the cluster we are seeing following error too:
> {code}
> 2016-11-10 07:56:06.674 o.a.s.zookeeper [INFO] Accepting leadership, all 
> active topology found localy.
> 2016-11-10 07:56:07.125 o.a.s.d.nimbus [ERROR] Error when processing event
> java.lang.NullPointerException
> at 
> clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:301)
> at 
> org.apache.storm.daemon.nimbus$get_cluster_info$fn__11126.invoke(nimbus.clj:1385)
> at 
> org.apache.storm.daemon.nimbus$get_cluster_info.invoke(nimbus.clj:1384)
> at 
> org.apache.storm.daemon.nimbus$send_cluster_metrics_to_executors.invoke(nimbus.clj:1445)
> at 
> org.apache.storm.daemon.nimbus$fn__11381$exec_fn__3535__auto11382$fn__11408.invoke(nimbus.clj:2244)
> at 
> org.apache.storm.timer$schedule_recurring$this__2162.invoke(timer.clj:105)
> at 
> org.apache.storm.timer$mk_timer$fn__2145$fn__2146.invoke(timer.clj:50)
> at org.apache.storm.timer$mk_timer$fn__2145.invoke(timer.clj:42)
> at clojure.lang.AFn.run(AFn.java:22)
> at java.lang.Thread.run(Thread.java:745)
> 2016-11-10 07:56:07.128 o.a.s.util [ERROR] Halting process: ("Error when 
> processing an event")
> java.lang.RuntimeException: ("Error when processing an event")
> at org.apache.storm.util$exit_process_BANG_.doInvoke(util.clj:341)
> at 

[jira] [Updated] (AMBARI-18740) Perf: Automate deployment of PERF stack on 2500+ Ambari Agents

2016-11-16 Thread Vitaly Brodetskyi (JIRA)

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

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

Committed to trunk and branch-2.5

> Perf: Automate deployment of PERF stack on 2500+ Ambari Agents
> --
>
> Key: AMBARI-18740
> URL: https://issues.apache.org/jira/browse/AMBARI-18740
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-agent
>Affects Versions: 2.5.0
>Reporter: Alejandro Fernandez
>Assignee: Vitaly Brodetskyi
> Fix For: 2.5.0
>
> Attachments: AMBARI-18740.patch
>
>
> We need automation to enable the deployment of 2500+ Agents.
> This may either be local using Vagrant or GCE.
> Local: Assume 5-10 VMs running CentOS 6
> GCE: Assume 50-500 VMs running CentOS 6
> The script should be able to
> # provision the VMs
> # install Ambari Server
> # install Ambari Agent
> # run the simulator with the number of Agents (and point it to the server)
> # deploy cluster with Blueprint



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


[jira] [Updated] (AMBARI-18897) HBase conf directory should not have a copy of core-site.xml and hdfs-site.xml

2016-11-16 Thread Vitaly Brodetskyi (JIRA)

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

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

Committed to trunk and branch-2.5

> HBase conf directory should not have a copy of core-site.xml and hdfs-site.xml
> --
>
> Key: AMBARI-18897
> URL: https://issues.apache.org/jira/browse/AMBARI-18897
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18897.patch
>
>
> /etc/hbase/conf/ contains core-site.xml and hdfs-site.xml which should not be 
> needed at all. But more importantly, when we change a setting in Ambari, they 
> do not get reflected in the hdfs-site.xml that is under the hbase conf 
> directory. Since there are more than 1 core-site.xml in the classpath, this 
> obviously causes issues since the changed configs are not picked up.



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


[jira] [Updated] (AMBARI-18827) Allow acceptor / seclector configuration for API and agent connectors

2016-11-16 Thread Siddharth Wagle (JIRA)

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

Siddharth Wagle updated AMBARI-18827:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Pushed to 2.5 and trunk

> Allow acceptor / seclector configuration for API and agent connectors
> -
>
> Key: AMBARI-18827
> URL: https://issues.apache.org/jira/browse/AMBARI-18827
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.2.1
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18827-1.patch, AMBARI-18827.patch
>
>
> _Objectives_:
> - Allow acceptors for agent and api connectors to be configurable
> - The thread pool configuration did not take into account both 2-way and 
> 1-way connectors are configured for agent every time although only one is 
> used and not a mixed-mode. This causes insufficient threads in agent 
> threadpool for a high cpu core environment.



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


[jira] [Commented] (AMBARI-18905) Management pack purge option should support extensions

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18905:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #347 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/347/])
AMBARI-18905 - Management pack purge option should support extensions (tthorpe: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=0ea79d3ee5caa23666d08efef4bde50620650f20])
* (edit) ambari-server/src/main/python/ambari_server/setupMpacks.py
* (edit) ambari-server/src/test/python/TestMpacks.py


> Management pack purge option should support extensions
> --
>
> Key: AMBARI-18905
> URL: https://issues.apache.org/jira/browse/AMBARI-18905
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: trunk, 2.4.0, 2.5.0
>Reporter: Tim Thorpe
>Assignee: Tim Thorpe
>Priority: Minor
> Fix For: trunk, 2.5.0
>
> Attachments: AMBARI-18905.patch
>
>
> Currently you can add extensions but you can't purge them.



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


[jira] [Updated] (AMBARI-18740) Perf: Automate deployment of PERF stack on 2500+ Ambari Agents

2016-11-16 Thread Vitaly Brodetskyi (JIRA)

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

Vitaly Brodetskyi updated AMBARI-18740:
---
Attachment: AMBARI-18740.patch

> Perf: Automate deployment of PERF stack on 2500+ Ambari Agents
> --
>
> Key: AMBARI-18740
> URL: https://issues.apache.org/jira/browse/AMBARI-18740
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-agent
>Affects Versions: 2.5.0
>Reporter: Alejandro Fernandez
> Fix For: 2.5.0
>
> Attachments: AMBARI-18740.patch
>
>
> We need automation to enable the deployment of 2500+ Agents.
> This may either be local using Vagrant or GCE.
> Local: Assume 5-10 VMs running CentOS 6
> GCE: Assume 50-500 VMs running CentOS 6
> The script should be able to
> # provision the VMs
> # install Ambari Server
> # install Ambari Agent
> # run the simulator with the number of Agents (and point it to the server)
> # deploy cluster with Blueprint



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


[jira] [Assigned] (AMBARI-18740) Perf: Automate deployment of PERF stack on 2500+ Ambari Agents

2016-11-16 Thread Vitaly Brodetskyi (JIRA)

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

Vitaly Brodetskyi reassigned AMBARI-18740:
--

Assignee: Vitaly Brodetskyi

> Perf: Automate deployment of PERF stack on 2500+ Ambari Agents
> --
>
> Key: AMBARI-18740
> URL: https://issues.apache.org/jira/browse/AMBARI-18740
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-agent
>Affects Versions: 2.5.0
>Reporter: Alejandro Fernandez
>Assignee: Vitaly Brodetskyi
> Fix For: 2.5.0
>
> Attachments: AMBARI-18740.patch
>
>
> We need automation to enable the deployment of 2500+ Agents.
> This may either be local using Vagrant or GCE.
> Local: Assume 5-10 VMs running CentOS 6
> GCE: Assume 50-500 VMs running CentOS 6
> The script should be able to
> # provision the VMs
> # install Ambari Server
> # install Ambari Agent
> # run the simulator with the number of Agents (and point it to the server)
> # deploy cluster with Blueprint



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


[jira] [Updated] (AMBARI-18740) Perf: Automate deployment of PERF stack on 2500+ Ambari Agents

2016-11-16 Thread Vitaly Brodetskyi (JIRA)

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

Vitaly Brodetskyi updated AMBARI-18740:
---
Status: Patch Available  (was: Open)

> Perf: Automate deployment of PERF stack on 2500+ Ambari Agents
> --
>
> Key: AMBARI-18740
> URL: https://issues.apache.org/jira/browse/AMBARI-18740
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-agent
>Affects Versions: 2.5.0
>Reporter: Alejandro Fernandez
>Assignee: Vitaly Brodetskyi
> Fix For: 2.5.0
>
> Attachments: AMBARI-18740.patch
>
>
> We need automation to enable the deployment of 2500+ Agents.
> This may either be local using Vagrant or GCE.
> Local: Assume 5-10 VMs running CentOS 6
> GCE: Assume 50-500 VMs running CentOS 6
> The script should be able to
> # provision the VMs
> # install Ambari Server
> # install Ambari Agent
> # run the simulator with the number of Agents (and point it to the server)
> # deploy cluster with Blueprint



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


[jira] [Commented] (AMBARI-17291) zookeeper.quorum in storm-metrics2.properties is broken

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-17291:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #346 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/346/])
AMBARI-17291 zookeeper.quorum in storm-metrics2.properties is broken (avijayan: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=9dae770a4b90dbc6116a0298ed322880ab732173])
* (edit) 
ambari-server/src/main/resources/common-services/STORM/0.9.1/package/scripts/params_linux.py


> zookeeper.quorum in storm-metrics2.properties is broken
> ---
>
> Key: AMBARI-17291
> URL: https://issues.apache.org/jira/browse/AMBARI-17291
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, ambari-server
>Affects Versions: 2.5.0
> Environment: CentOS7.2
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-17291.1.patch, AMBARI-17291.patch
>
>
> When installed Storm and Ambari Metrics (and ZooKeeper, for dependency), 
> {{zookeeper.quorum}} in /etc/storm/conf/storm-metrics2.properties is looks 
> like this.
> {code}
> zookeeper.quorum=[:2181,':2181,c:2181,7:2181,2:2181,0:2181,1:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,,:2181,':2181,c:2181,7:2181,2:2181,0:2181,2:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,,:2181,':2181,c:2181,7:2181,2:2181,0:2181,3:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,]:2181
> {code}
> storm.zookeeper.servers is 
> {{['c7201.ambari.apache.org','c7202.ambari.apache.org','c7203.ambari.apache.org']}}
> Steps to reproduce.
> Install Ambari Server (I used 
> http://s3.amazonaws.com/dev.hortonworks.com/ambari/centos7/2.x/latest/trunk/ambaribn.repo)
> Setup and start Ambari Server (ambari-server setup -s and ambari-server start)
> Install Storm and ZooKeeper via Ambari Server (HDP2.4)
> Install Ambari Metrics
> Restart all required



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


[jira] [Commented] (AMBARI-18911) Storm start is failing due to metrics initialization error

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18911:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #346 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/346/])
AMBARI-18911 : Storm start is failing due to metrics initialization (avijayan: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=280bb6ecfac05e32de104edc4e9532d44580dc93])
* (edit) 
ambari-metrics/ambari-metrics-storm-sink/src/main/java/org/apache/hadoop/metrics2/sink/storm/StormTimelineMetricsReporter.java
* (edit) ambari-metrics/ambari-metrics-common/pom.xml
* (add) 
ambari-metrics/ambari-metrics-common/src/test/java/org/apache/hadoop/metrics2/sink/timeline/availability/AbstractTimelineMetricSinkTest.java
* (edit) 
ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/AbstractTimelineMetricsSink.java


> Storm start is failing due to metrics initialization error
> --
>
> Key: AMBARI-18911
> URL: https://issues.apache.org/jira/browse/AMBARI-18911
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Blocker
> Fix For: 2.5.0
>
> Attachments: AMBARI-18911.patch
>
>
> {code}
> 2016-11-10 07:14:58.311 o.a.s.d.nimbus [ERROR] Error on initialization of 
> server service-handler
> java.lang.RuntimeException: Could not instantiate a class listed in config 
> under section storm.cluster.metrics.consumer.register with fully qualified 
> name org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
> at 
> org.apache.storm.metric.ClusterMetricsConsumerExecutor.prepare(ClusterMetricsConsumerExecutor.java:50)
> 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__11381$exec_fn__3535__auto11382.invoke(nimbus.clj:2192)
> 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__11381$service_handler__11417.doInvoke(nimbus.clj:2169)
> at clojure.lang.RestFn.invoke(RestFn.java:421)
> at 
> org.apache.storm.daemon.nimbus$launch_server_BANG_.invoke(nimbus.clj:2258)
> at org.apache.storm.daemon.nimbus$_launch.invoke(nimbus.clj:2291)
> at org.apache.storm.daemon.nimbus$_main.invoke(nimbus.clj:2314)
> 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: 
> org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
> 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)
> 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)
> {code}
> in some of the cluster we are seeing following error too:
> {code}
> 2016-11-10 07:56:06.674 o.a.s.zookeeper [INFO] Accepting leadership, all 
> active topology found localy.
> 2016-11-10 07:56:07.125 o.a.s.d.nimbus [ERROR] Error when processing event
> java.lang.NullPointerException
> at 
> clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:301)
> at 
> org.apache.storm.daemon.nimbus$get_cluster_info$fn__11126.invoke(nimbus.clj:1385)
> at 
> org.apache.storm.daemon.nimbus$get_cluster_info.invoke(nimbus.clj:1384)
> at 
> org.apache.storm.daemon.nimbus$send_cluster_metrics_to_executors.invoke(nimbus.clj:1445)
> at 
> org.apache.storm.daemon.nimbus$fn__11381$exec_fn__3535__auto11382$fn__11408.invoke(nimbus.clj:2244)
> at 
> org.apache.storm.timer$schedule_recurring$this__2162.invoke(timer.clj:105)
> at 
> org.apache.storm.timer$mk_timer$fn__2145$fn__2146.invoke(timer.clj:50)
> at org.apache.storm.timer$mk_timer$fn__2145.invoke(timer.clj:42)
>

[jira] [Updated] (AMBARI-18905) Management pack purge option should support extensions

2016-11-16 Thread Tim Thorpe (JIRA)

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

Tim Thorpe updated AMBARI-18905:

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

> Management pack purge option should support extensions
> --
>
> Key: AMBARI-18905
> URL: https://issues.apache.org/jira/browse/AMBARI-18905
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: trunk, 2.4.0, 2.5.0
>Reporter: Tim Thorpe
>Assignee: Tim Thorpe
>Priority: Minor
> Fix For: trunk, 2.5.0
>
> Attachments: AMBARI-18905.patch
>
>
> Currently you can add extensions but you can't purge them.



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


[jira] [Updated] (AMBARI-18913) Hive view service check fails first time after server restart

2016-11-16 Thread Ashwin Rajeev (JIRA)

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

Ashwin Rajeev updated AMBARI-18913:
---
Status: Patch Available  (was: Open)

> Hive view service check fails first time after server restart
> -
>
> Key: AMBARI-18913
> URL: https://issues.apache.org/jira/browse/AMBARI-18913
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.2
>Reporter: Ashwin Rajeev
>Assignee: Ashwin Rajeev
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18913.trunk.patch
>
>
> Hive view service checks fail intermittently when the cluster is Kerberized



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


[jira] [Reopened] (AMBARI-18911) Storm start is failing due to metrics initialization error

2016-11-16 Thread Aravindan Vijayan (JIRA)

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

Aravindan Vijayan reopened AMBARI-18911:


> Storm start is failing due to metrics initialization error
> --
>
> Key: AMBARI-18911
> URL: https://issues.apache.org/jira/browse/AMBARI-18911
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Blocker
> Fix For: 2.5.0
>
> Attachments: AMBARI-18911.patch
>
>
> {code}
> 2016-11-10 07:14:58.311 o.a.s.d.nimbus [ERROR] Error on initialization of 
> server service-handler
> java.lang.RuntimeException: Could not instantiate a class listed in config 
> under section storm.cluster.metrics.consumer.register with fully qualified 
> name org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
> at 
> org.apache.storm.metric.ClusterMetricsConsumerExecutor.prepare(ClusterMetricsConsumerExecutor.java:50)
> 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__11381$exec_fn__3535__auto11382.invoke(nimbus.clj:2192)
> 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__11381$service_handler__11417.doInvoke(nimbus.clj:2169)
> at clojure.lang.RestFn.invoke(RestFn.java:421)
> at 
> org.apache.storm.daemon.nimbus$launch_server_BANG_.invoke(nimbus.clj:2258)
> at org.apache.storm.daemon.nimbus$_launch.invoke(nimbus.clj:2291)
> at org.apache.storm.daemon.nimbus$_main.invoke(nimbus.clj:2314)
> 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: 
> org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
> 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)
> 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)
> {code}
> in some of the cluster we are seeing following error too:
> {code}
> 2016-11-10 07:56:06.674 o.a.s.zookeeper [INFO] Accepting leadership, all 
> active topology found localy.
> 2016-11-10 07:56:07.125 o.a.s.d.nimbus [ERROR] Error when processing event
> java.lang.NullPointerException
> at 
> clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:301)
> at 
> org.apache.storm.daemon.nimbus$get_cluster_info$fn__11126.invoke(nimbus.clj:1385)
> at 
> org.apache.storm.daemon.nimbus$get_cluster_info.invoke(nimbus.clj:1384)
> at 
> org.apache.storm.daemon.nimbus$send_cluster_metrics_to_executors.invoke(nimbus.clj:1445)
> at 
> org.apache.storm.daemon.nimbus$fn__11381$exec_fn__3535__auto11382$fn__11408.invoke(nimbus.clj:2244)
> at 
> org.apache.storm.timer$schedule_recurring$this__2162.invoke(timer.clj:105)
> at 
> org.apache.storm.timer$mk_timer$fn__2145$fn__2146.invoke(timer.clj:50)
> at org.apache.storm.timer$mk_timer$fn__2145.invoke(timer.clj:42)
> at clojure.lang.AFn.run(AFn.java:22)
> at java.lang.Thread.run(Thread.java:745)
> 2016-11-10 07:56:07.128 o.a.s.util [ERROR] Halting process: ("Error when 
> processing an event")
> java.lang.RuntimeException: ("Error when processing an event")
> at org.apache.storm.util$exit_process_BANG_.doInvoke(util.clj:341)
> at clojure.lang.RestFn.invoke(RestFn.java:423)
> at 
> org.apache.storm.daemon.nimbus$nimbus_data$fn__10339.invoke(nimbus.clj:206)
> at 
> org.apache.storm.timer$mk_timer$fn__2145$fn__2146.invoke(timer.clj:71)
> at org.apache.storm.timer$mk_timer$fn__2145.invoke(timer.clj:42)
> at clojure.lang.AFn.run(AFn.java:22)
> at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA

[jira] [Updated] (AMBARI-18913) Hive view service check fails first time after server restart

2016-11-16 Thread Ashwin Rajeev (JIRA)

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

Ashwin Rajeev updated AMBARI-18913:
---
Attachment: AMBARI-18913.trunk.patch

> Hive view service check fails first time after server restart
> -
>
> Key: AMBARI-18913
> URL: https://issues.apache.org/jira/browse/AMBARI-18913
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.2
>Reporter: Ashwin Rajeev
>Assignee: Ashwin Rajeev
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18913.trunk.patch
>
>
> Hive view service checks fail intermittently when the cluster is Kerberized



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


[jira] [Updated] (AMBARI-18911) Storm start is failing due to metrics initialization error

2016-11-16 Thread Aravindan Vijayan (JIRA)

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

Aravindan Vijayan updated AMBARI-18911:
---
Status: Patch Available  (was: Reopened)

> Storm start is failing due to metrics initialization error
> --
>
> Key: AMBARI-18911
> URL: https://issues.apache.org/jira/browse/AMBARI-18911
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Blocker
> Fix For: 2.5.0
>
> Attachments: AMBARI-18911.patch
>
>
> {code}
> 2016-11-10 07:14:58.311 o.a.s.d.nimbus [ERROR] Error on initialization of 
> server service-handler
> java.lang.RuntimeException: Could not instantiate a class listed in config 
> under section storm.cluster.metrics.consumer.register with fully qualified 
> name org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
> at 
> org.apache.storm.metric.ClusterMetricsConsumerExecutor.prepare(ClusterMetricsConsumerExecutor.java:50)
> 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__11381$exec_fn__3535__auto11382.invoke(nimbus.clj:2192)
> 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__11381$service_handler__11417.doInvoke(nimbus.clj:2169)
> at clojure.lang.RestFn.invoke(RestFn.java:421)
> at 
> org.apache.storm.daemon.nimbus$launch_server_BANG_.invoke(nimbus.clj:2258)
> at org.apache.storm.daemon.nimbus$_launch.invoke(nimbus.clj:2291)
> at org.apache.storm.daemon.nimbus$_main.invoke(nimbus.clj:2314)
> 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: 
> org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
> 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)
> 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)
> {code}
> in some of the cluster we are seeing following error too:
> {code}
> 2016-11-10 07:56:06.674 o.a.s.zookeeper [INFO] Accepting leadership, all 
> active topology found localy.
> 2016-11-10 07:56:07.125 o.a.s.d.nimbus [ERROR] Error when processing event
> java.lang.NullPointerException
> at 
> clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:301)
> at 
> org.apache.storm.daemon.nimbus$get_cluster_info$fn__11126.invoke(nimbus.clj:1385)
> at 
> org.apache.storm.daemon.nimbus$get_cluster_info.invoke(nimbus.clj:1384)
> at 
> org.apache.storm.daemon.nimbus$send_cluster_metrics_to_executors.invoke(nimbus.clj:1445)
> at 
> org.apache.storm.daemon.nimbus$fn__11381$exec_fn__3535__auto11382$fn__11408.invoke(nimbus.clj:2244)
> at 
> org.apache.storm.timer$schedule_recurring$this__2162.invoke(timer.clj:105)
> at 
> org.apache.storm.timer$mk_timer$fn__2145$fn__2146.invoke(timer.clj:50)
> at org.apache.storm.timer$mk_timer$fn__2145.invoke(timer.clj:42)
> at clojure.lang.AFn.run(AFn.java:22)
> at java.lang.Thread.run(Thread.java:745)
> 2016-11-10 07:56:07.128 o.a.s.util [ERROR] Halting process: ("Error when 
> processing an event")
> java.lang.RuntimeException: ("Error when processing an event")
> at org.apache.storm.util$exit_process_BANG_.doInvoke(util.clj:341)
> at clojure.lang.RestFn.invoke(RestFn.java:423)
> at 
> org.apache.storm.daemon.nimbus$nimbus_data$fn__10339.invoke(nimbus.clj:206)
> at 
> org.apache.storm.timer$mk_timer$fn__2145$fn__2146.invoke(timer.clj:71)
> at org.apache.storm.timer$mk_timer$fn__2145.invoke(timer.clj:42)
> at clojure.lang.AFn.run(AFn.java:22)
> at java.lang.Thread.run(Thread.java:745)
> {code}




[jira] [Updated] (AMBARI-18913) Hive view service check fails first time after server restart

2016-11-16 Thread Ashwin Rajeev (JIRA)

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

Ashwin Rajeev updated AMBARI-18913:
---
Summary: Hive view service check fails first time after server restart  
(was: Hive view service check fails, first time after server restart)

> Hive view service check fails first time after server restart
> -
>
> Key: AMBARI-18913
> URL: https://issues.apache.org/jira/browse/AMBARI-18913
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.2
>Reporter: Ashwin Rajeev
>Assignee: Ashwin Rajeev
>Priority: Critical
> Fix For: 2.4.2
>
>
> Hive view service checks fail intermittently when the cluster is Kerberized



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


[jira] [Updated] (AMBARI-18913) Hive view service check fails, first time after server restart

2016-11-16 Thread Ashwin Rajeev (JIRA)

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

Ashwin Rajeev updated AMBARI-18913:
---
Description: Hive view service checks fail intermittently when the cluster 
is Kerberized

> Hive view service check fails, first time after server restart
> --
>
> Key: AMBARI-18913
> URL: https://issues.apache.org/jira/browse/AMBARI-18913
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.2
>Reporter: Ashwin Rajeev
>Assignee: Ashwin Rajeev
>Priority: Critical
> Fix For: 2.4.2
>
>
> Hive view service checks fail intermittently when the cluster is Kerberized



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


[jira] [Created] (AMBARI-18913) Hive view service check fails, first time after server restart

2016-11-16 Thread Ashwin Rajeev (JIRA)
Ashwin Rajeev created AMBARI-18913:
--

 Summary: Hive view service check fails, first time after server 
restart
 Key: AMBARI-18913
 URL: https://issues.apache.org/jira/browse/AMBARI-18913
 Project: Ambari
  Issue Type: Bug
Affects Versions: 2.4.2
Reporter: Ashwin Rajeev
Assignee: Ashwin Rajeev
Priority: Critical
 Fix For: 2.4.2






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


[jira] [Updated] (AMBARI-18911) Storm start is failing due to metrics initialization error

2016-11-16 Thread Aravindan Vijayan (JIRA)

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

Aravindan Vijayan updated AMBARI-18911:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Pushed to branch-2.5 and trunk.

> Storm start is failing due to metrics initialization error
> --
>
> Key: AMBARI-18911
> URL: https://issues.apache.org/jira/browse/AMBARI-18911
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Blocker
> Fix For: 2.5.0
>
> Attachments: AMBARI-18911.patch
>
>
> {code}
> 2016-11-10 07:14:58.311 o.a.s.d.nimbus [ERROR] Error on initialization of 
> server service-handler
> java.lang.RuntimeException: Could not instantiate a class listed in config 
> under section storm.cluster.metrics.consumer.register with fully qualified 
> name org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
> at 
> org.apache.storm.metric.ClusterMetricsConsumerExecutor.prepare(ClusterMetricsConsumerExecutor.java:50)
> 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__11381$exec_fn__3535__auto11382.invoke(nimbus.clj:2192)
> 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__11381$service_handler__11417.doInvoke(nimbus.clj:2169)
> at clojure.lang.RestFn.invoke(RestFn.java:421)
> at 
> org.apache.storm.daemon.nimbus$launch_server_BANG_.invoke(nimbus.clj:2258)
> at org.apache.storm.daemon.nimbus$_launch.invoke(nimbus.clj:2291)
> at org.apache.storm.daemon.nimbus$_main.invoke(nimbus.clj:2314)
> 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: 
> org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
> 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)
> 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)
> {code}
> in some of the cluster we are seeing following error too:
> {code}
> 2016-11-10 07:56:06.674 o.a.s.zookeeper [INFO] Accepting leadership, all 
> active topology found localy.
> 2016-11-10 07:56:07.125 o.a.s.d.nimbus [ERROR] Error when processing event
> java.lang.NullPointerException
> at 
> clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:301)
> at 
> org.apache.storm.daemon.nimbus$get_cluster_info$fn__11126.invoke(nimbus.clj:1385)
> at 
> org.apache.storm.daemon.nimbus$get_cluster_info.invoke(nimbus.clj:1384)
> at 
> org.apache.storm.daemon.nimbus$send_cluster_metrics_to_executors.invoke(nimbus.clj:1445)
> at 
> org.apache.storm.daemon.nimbus$fn__11381$exec_fn__3535__auto11382$fn__11408.invoke(nimbus.clj:2244)
> at 
> org.apache.storm.timer$schedule_recurring$this__2162.invoke(timer.clj:105)
> at 
> org.apache.storm.timer$mk_timer$fn__2145$fn__2146.invoke(timer.clj:50)
> at org.apache.storm.timer$mk_timer$fn__2145.invoke(timer.clj:42)
> at clojure.lang.AFn.run(AFn.java:22)
> at java.lang.Thread.run(Thread.java:745)
> 2016-11-10 07:56:07.128 o.a.s.util [ERROR] Halting process: ("Error when 
> processing an event")
> java.lang.RuntimeException: ("Error when processing an event")
> at org.apache.storm.util$exit_process_BANG_.doInvoke(util.clj:341)
> at clojure.lang.RestFn.invoke(RestFn.java:423)
> at 
> org.apache.storm.daemon.nimbus$nimbus_data$fn__10339.invoke(nimbus.clj:206)
> at 
> org.apache.storm.timer$mk_timer$fn__2145$fn__2146.invoke(timer.clj:71)
> at org.apache.storm.timer$mk_timer$fn__2145.invoke(timer.clj:42)
> at clojure.lang.AFn.run(AFn.java:22)
>   

[jira] [Created] (AMBARI-18912) Implement Create Alerts: step 1 select alert type

2016-11-16 Thread Xi Wang (JIRA)
Xi Wang created AMBARI-18912:


 Summary: Implement Create Alerts: step 1 select alert type
 Key: AMBARI-18912
 URL: https://issues.apache.org/jira/browse/AMBARI-18912
 Project: Ambari
  Issue Type: Task
  Components: ambari-web
Affects Versions: 2.5.0
Reporter: Xi Wang
Assignee: Xi Wang
 Fix For: 2.5.0


This is a FE task to implement the "Create Alerts Wizard " based on the design 
attached.
In this task, should implement the step 1 in the design. All available alert 
types should be displayed as options with icon, type and description. Make sure 
that on clicking a type use would jump to next step.



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


[jira] [Commented] (AMBARI-17291) zookeeper.quorum in storm-metrics2.properties is broken

2016-11-16 Thread Aravindan Vijayan (JIRA)

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

Aravindan Vijayan commented on AMBARI-17291:


Pushed to branch-2.5
{code}
commit 9dae770a4b90dbc6116a0298ed322880ab732173
Author: Aravindan Vijayan 
Date:   Wed Nov 16 12:25:51 2016 -0800

AMBARI-17291 zookeeper.quorum in storm-metrics2.properties is broken 
(Masahiro Tanaka via avijayan)

{code}

> zookeeper.quorum in storm-metrics2.properties is broken
> ---
>
> Key: AMBARI-17291
> URL: https://issues.apache.org/jira/browse/AMBARI-17291
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, ambari-server
>Affects Versions: 2.5.0
> Environment: CentOS7.2
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-17291.1.patch, AMBARI-17291.patch
>
>
> When installed Storm and Ambari Metrics (and ZooKeeper, for dependency), 
> {{zookeeper.quorum}} in /etc/storm/conf/storm-metrics2.properties is looks 
> like this.
> {code}
> zookeeper.quorum=[:2181,':2181,c:2181,7:2181,2:2181,0:2181,1:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,,:2181,':2181,c:2181,7:2181,2:2181,0:2181,2:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,,:2181,':2181,c:2181,7:2181,2:2181,0:2181,3:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,]:2181
> {code}
> storm.zookeeper.servers is 
> {{['c7201.ambari.apache.org','c7202.ambari.apache.org','c7203.ambari.apache.org']}}
> Steps to reproduce.
> Install Ambari Server (I used 
> http://s3.amazonaws.com/dev.hortonworks.com/ambari/centos7/2.x/latest/trunk/ambaribn.repo)
> Setup and start Ambari Server (ambari-server setup -s and ambari-server start)
> Install Storm and ZooKeeper via Ambari Server (HDP2.4)
> Install Ambari Metrics
> Restart all required



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


[jira] [Commented] (AMBARI-18827) Allow acceptor / seclector configuration for API and agent connectors

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18827:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #344 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/344/])
AMBARI-18827. Allow acceptor / seclector configuration for API and agent 
(swagle: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=43d30212f54f1f3e9b847712a9df8a776a266370])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java


> Allow acceptor / seclector configuration for API and agent connectors
> -
>
> Key: AMBARI-18827
> URL: https://issues.apache.org/jira/browse/AMBARI-18827
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.2.1
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18827-1.patch, AMBARI-18827.patch
>
>
> _Objectives_:
> - Allow acceptors for agent and api connectors to be configurable
> - The thread pool configuration did not take into account both 2-way and 
> 1-way connectors are configured for agent every time although only one is 
> used and not a mixed-mode. This causes insufficient threads in agent 
> threadpool for a high cpu core environment.



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


[jira] [Updated] (AMBARI-18911) Storm start is failing due to metrics initialization error

2016-11-16 Thread Aravindan Vijayan (JIRA)

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

Aravindan Vijayan updated AMBARI-18911:
---
Status: Patch Available  (was: In Progress)

> Storm start is failing due to metrics initialization error
> --
>
> Key: AMBARI-18911
> URL: https://issues.apache.org/jira/browse/AMBARI-18911
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Blocker
> Fix For: 2.5.0
>
> Attachments: AMBARI-18911.patch
>
>
> {code}
> 2016-11-10 07:14:58.311 o.a.s.d.nimbus [ERROR] Error on initialization of 
> server service-handler
> java.lang.RuntimeException: Could not instantiate a class listed in config 
> under section storm.cluster.metrics.consumer.register with fully qualified 
> name org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
> at 
> org.apache.storm.metric.ClusterMetricsConsumerExecutor.prepare(ClusterMetricsConsumerExecutor.java:50)
> 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__11381$exec_fn__3535__auto11382.invoke(nimbus.clj:2192)
> 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__11381$service_handler__11417.doInvoke(nimbus.clj:2169)
> at clojure.lang.RestFn.invoke(RestFn.java:421)
> at 
> org.apache.storm.daemon.nimbus$launch_server_BANG_.invoke(nimbus.clj:2258)
> at org.apache.storm.daemon.nimbus$_launch.invoke(nimbus.clj:2291)
> at org.apache.storm.daemon.nimbus$_main.invoke(nimbus.clj:2314)
> 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: 
> org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
> 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)
> 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)
> {code}
> in some of the cluster we are seeing following error too:
> {code}
> 2016-11-10 07:56:06.674 o.a.s.zookeeper [INFO] Accepting leadership, all 
> active topology found localy.
> 2016-11-10 07:56:07.125 o.a.s.d.nimbus [ERROR] Error when processing event
> java.lang.NullPointerException
> at 
> clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:301)
> at 
> org.apache.storm.daemon.nimbus$get_cluster_info$fn__11126.invoke(nimbus.clj:1385)
> at 
> org.apache.storm.daemon.nimbus$get_cluster_info.invoke(nimbus.clj:1384)
> at 
> org.apache.storm.daemon.nimbus$send_cluster_metrics_to_executors.invoke(nimbus.clj:1445)
> at 
> org.apache.storm.daemon.nimbus$fn__11381$exec_fn__3535__auto11382$fn__11408.invoke(nimbus.clj:2244)
> at 
> org.apache.storm.timer$schedule_recurring$this__2162.invoke(timer.clj:105)
> at 
> org.apache.storm.timer$mk_timer$fn__2145$fn__2146.invoke(timer.clj:50)
> at org.apache.storm.timer$mk_timer$fn__2145.invoke(timer.clj:42)
> at clojure.lang.AFn.run(AFn.java:22)
> at java.lang.Thread.run(Thread.java:745)
> 2016-11-10 07:56:07.128 o.a.s.util [ERROR] Halting process: ("Error when 
> processing an event")
> java.lang.RuntimeException: ("Error when processing an event")
> at org.apache.storm.util$exit_process_BANG_.doInvoke(util.clj:341)
> at clojure.lang.RestFn.invoke(RestFn.java:423)
> at 
> org.apache.storm.daemon.nimbus$nimbus_data$fn__10339.invoke(nimbus.clj:206)
> at 
> org.apache.storm.timer$mk_timer$fn__2145$fn__2146.invoke(timer.clj:71)
> at org.apache.storm.timer$mk_timer$fn__2145.invoke(timer.clj:42)
> at clojure.lang.AFn.run(AFn.java:22)
> at java.lang.Thread.run(Thread.java:745)
> {code}

[jira] [Commented] (AMBARI-18827) Allow acceptor / seclector configuration for API and agent connectors

2016-11-16 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on AMBARI-18827:


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

This message is automatically generated.

> Allow acceptor / seclector configuration for API and agent connectors
> -
>
> Key: AMBARI-18827
> URL: https://issues.apache.org/jira/browse/AMBARI-18827
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.2.1
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18827-1.patch, AMBARI-18827.patch
>
>
> _Objectives_:
> - Allow acceptors for agent and api connectors to be configurable
> - The thread pool configuration did not take into account both 2-way and 
> 1-way connectors are configured for agent every time although only one is 
> used and not a mixed-mode. This causes insufficient threads in agent 
> threadpool for a high cpu core environment.



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


[jira] [Updated] (AMBARI-18755) Deployment failing at creating principal

2016-11-16 Thread Sumit Mohanty (JIRA)

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

Sumit Mohanty updated AMBARI-18755:
---
Attachment: AMBARI-18755.addendum.patch

> Deployment failing at creating principal
> 
>
> Key: AMBARI-18755
> URL: https://issues.apache.org/jira/browse/AMBARI-18755
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Vivek Rathod
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-18755.addendum.patch, AMBARI-18755.patch
>
>
> Cluster deployment via blueprint failed at creating principals



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


[jira] [Reopened] (AMBARI-18755) Deployment failing at creating principal

2016-11-16 Thread Sumit Mohanty (JIRA)

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

Sumit Mohanty reopened AMBARI-18755:


It appears that retries in close succession does not help - so a delay is being 
added to the retry logic.

> Deployment failing at creating principal
> 
>
> Key: AMBARI-18755
> URL: https://issues.apache.org/jira/browse/AMBARI-18755
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Vivek Rathod
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-18755.addendum.patch, AMBARI-18755.patch
>
>
> Cluster deployment via blueprint failed at creating principals



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


[jira] [Updated] (AMBARI-17291) zookeeper.quorum in storm-metrics2.properties is broken

2016-11-16 Thread Aravindan Vijayan (JIRA)

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

Aravindan Vijayan updated AMBARI-17291:
---
Fix Version/s: (was: trunk)
   2.5.0

> zookeeper.quorum in storm-metrics2.properties is broken
> ---
>
> Key: AMBARI-17291
> URL: https://issues.apache.org/jira/browse/AMBARI-17291
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, ambari-server
>Affects Versions: 2.5.0
> Environment: CentOS7.2
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-17291.1.patch, AMBARI-17291.patch
>
>
> When installed Storm and Ambari Metrics (and ZooKeeper, for dependency), 
> {{zookeeper.quorum}} in /etc/storm/conf/storm-metrics2.properties is looks 
> like this.
> {code}
> zookeeper.quorum=[:2181,':2181,c:2181,7:2181,2:2181,0:2181,1:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,,:2181,':2181,c:2181,7:2181,2:2181,0:2181,2:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,,:2181,':2181,c:2181,7:2181,2:2181,0:2181,3:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,]:2181
> {code}
> storm.zookeeper.servers is 
> {{['c7201.ambari.apache.org','c7202.ambari.apache.org','c7203.ambari.apache.org']}}
> Steps to reproduce.
> Install Ambari Server (I used 
> http://s3.amazonaws.com/dev.hortonworks.com/ambari/centos7/2.x/latest/trunk/ambaribn.repo)
> Setup and start Ambari Server (ambari-server setup -s and ambari-server start)
> Install Storm and ZooKeeper via Ambari Server (HDP2.4)
> Install Ambari Metrics
> Restart all required



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


[jira] [Commented] (AMBARI-17291) zookeeper.quorum in storm-metrics2.properties is broken

2016-11-16 Thread Aravindan Vijayan (JIRA)

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

Aravindan Vijayan commented on AMBARI-17291:


Backporting to Ambari-2.5.0

> zookeeper.quorum in storm-metrics2.properties is broken
> ---
>
> Key: AMBARI-17291
> URL: https://issues.apache.org/jira/browse/AMBARI-17291
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, ambari-server
>Affects Versions: 2.5.0
> Environment: CentOS7.2
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-17291.1.patch, AMBARI-17291.patch
>
>
> When installed Storm and Ambari Metrics (and ZooKeeper, for dependency), 
> {{zookeeper.quorum}} in /etc/storm/conf/storm-metrics2.properties is looks 
> like this.
> {code}
> zookeeper.quorum=[:2181,':2181,c:2181,7:2181,2:2181,0:2181,1:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,,:2181,':2181,c:2181,7:2181,2:2181,0:2181,2:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,,:2181,':2181,c:2181,7:2181,2:2181,0:2181,3:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,]:2181
> {code}
> storm.zookeeper.servers is 
> {{['c7201.ambari.apache.org','c7202.ambari.apache.org','c7203.ambari.apache.org']}}
> Steps to reproduce.
> Install Ambari Server (I used 
> http://s3.amazonaws.com/dev.hortonworks.com/ambari/centos7/2.x/latest/trunk/ambaribn.repo)
> Setup and start Ambari Server (ambari-server setup -s and ambari-server start)
> Install Storm and ZooKeeper via Ambari Server (HDP2.4)
> Install Ambari Metrics
> Restart all required



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


[jira] [Updated] (AMBARI-17291) zookeeper.quorum in storm-metrics2.properties is broken

2016-11-16 Thread Aravindan Vijayan (JIRA)

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

Aravindan Vijayan updated AMBARI-17291:
---
Affects Version/s: (was: trunk)
   2.5.0

> zookeeper.quorum in storm-metrics2.properties is broken
> ---
>
> Key: AMBARI-17291
> URL: https://issues.apache.org/jira/browse/AMBARI-17291
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, ambari-server
>Affects Versions: 2.5.0
> Environment: CentOS7.2
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-17291.1.patch, AMBARI-17291.patch
>
>
> When installed Storm and Ambari Metrics (and ZooKeeper, for dependency), 
> {{zookeeper.quorum}} in /etc/storm/conf/storm-metrics2.properties is looks 
> like this.
> {code}
> zookeeper.quorum=[:2181,':2181,c:2181,7:2181,2:2181,0:2181,1:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,,:2181,':2181,c:2181,7:2181,2:2181,0:2181,2:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,,:2181,':2181,c:2181,7:2181,2:2181,0:2181,3:2181,.:2181,a:2181,m:2181,b:2181,a:2181,r:2181,i:2181,.:2181,a:2181,p:2181,a:2181,c:2181,h:2181,e:2181,.:2181,o:2181,r:2181,g:2181,':2181,]:2181
> {code}
> storm.zookeeper.servers is 
> {{['c7201.ambari.apache.org','c7202.ambari.apache.org','c7203.ambari.apache.org']}}
> Steps to reproduce.
> Install Ambari Server (I used 
> http://s3.amazonaws.com/dev.hortonworks.com/ambari/centos7/2.x/latest/trunk/ambaribn.repo)
> Setup and start Ambari Server (ambari-server setup -s and ambari-server start)
> Install Storm and ZooKeeper via Ambari Server (HDP2.4)
> Install Ambari Metrics
> Restart all required



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


[jira] [Created] (AMBARI-18911) Storm start is failing due to metrics initialization error

2016-11-16 Thread Aravindan Vijayan (JIRA)
Aravindan Vijayan created AMBARI-18911:
--

 Summary: Storm start is failing due to metrics initialization error
 Key: AMBARI-18911
 URL: https://issues.apache.org/jira/browse/AMBARI-18911
 Project: Ambari
  Issue Type: Bug
Affects Versions: 2.5.0
Reporter: Aravindan Vijayan
Assignee: Aravindan Vijayan
Priority: Blocker
 Fix For: 2.5.0


{code}
2016-11-10 07:14:58.311 o.a.s.d.nimbus [ERROR] Error on initialization of 
server service-handler
java.lang.RuntimeException: Could not instantiate a class listed in config 
under section storm.cluster.metrics.consumer.register with fully qualified name 
org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
at 
org.apache.storm.metric.ClusterMetricsConsumerExecutor.prepare(ClusterMetricsConsumerExecutor.java:50)
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__11381$exec_fn__3535__auto11382.invoke(nimbus.clj:2192)
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__11381$service_handler__11417.doInvoke(nimbus.clj:2169)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at 
org.apache.storm.daemon.nimbus$launch_server_BANG_.invoke(nimbus.clj:2258)
at org.apache.storm.daemon.nimbus$_launch.invoke(nimbus.clj:2291)
at org.apache.storm.daemon.nimbus$_main.invoke(nimbus.clj:2314)
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: 
org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter
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)
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)
{code}

in some of the cluster we are seeing following error too:

{code}
2016-11-10 07:56:06.674 o.a.s.zookeeper [INFO] Accepting leadership, all active 
topology found localy.
2016-11-10 07:56:07.125 o.a.s.d.nimbus [ERROR] Error when processing event
java.lang.NullPointerException
at clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:301)
at 
org.apache.storm.daemon.nimbus$get_cluster_info$fn__11126.invoke(nimbus.clj:1385)
at 
org.apache.storm.daemon.nimbus$get_cluster_info.invoke(nimbus.clj:1384)
at 
org.apache.storm.daemon.nimbus$send_cluster_metrics_to_executors.invoke(nimbus.clj:1445)
at 
org.apache.storm.daemon.nimbus$fn__11381$exec_fn__3535__auto11382$fn__11408.invoke(nimbus.clj:2244)
at 
org.apache.storm.timer$schedule_recurring$this__2162.invoke(timer.clj:105)
at 
org.apache.storm.timer$mk_timer$fn__2145$fn__2146.invoke(timer.clj:50)
at org.apache.storm.timer$mk_timer$fn__2145.invoke(timer.clj:42)
at clojure.lang.AFn.run(AFn.java:22)
at java.lang.Thread.run(Thread.java:745)
2016-11-10 07:56:07.128 o.a.s.util [ERROR] Halting process: ("Error when 
processing an event")
java.lang.RuntimeException: ("Error when processing an event")
at org.apache.storm.util$exit_process_BANG_.doInvoke(util.clj:341)
at clojure.lang.RestFn.invoke(RestFn.java:423)
at 
org.apache.storm.daemon.nimbus$nimbus_data$fn__10339.invoke(nimbus.clj:206)
at 
org.apache.storm.timer$mk_timer$fn__2145$fn__2146.invoke(timer.clj:71)
at org.apache.storm.timer$mk_timer$fn__2145.invoke(timer.clj:42)
at clojure.lang.AFn.run(AFn.java:22)
at java.lang.Thread.run(Thread.java:745)
{code}




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


[jira] [Commented] (AMBARI-18910) SSL/TLS protocols should be explicitly enabled and then filtered when Ambari starts up

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18910:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #343 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/343/])
AMBARI-18910. SSL/TLS protocols should be explicitly enabled and then (rlevas: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=18ea7cf57997b0579407822f821c96d0b11bd7dd])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java


> SSL/TLS protocols should be explicitly enabled and then filtered when Ambari 
> starts up
> --
>
> Key: AMBARI-18910
> URL: https://issues.apache.org/jira/browse/AMBARI-18910
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18910_branch-2.4_01.patch, 
> AMBARI-18910_branch-2.5_01.patch
>
>
> SSL/TLS protocols should be explicitly enabled and then filtered when Ambari 
> starts up.
> Currently the following protocols are explicitly enabled: 
> * {{SSLv2Hello}}
> * {{TLSv1}}
> {code:title=org/apache/ambari/server/controller/AmbariServer.java:718} 
> factory.setIncludeProtocols(new String[] { "SSLv2Hello","TLSv1"});
> {code}
> However the following protocols should be enabled by default:
> * {{SSLv2Hello}}
> * {{TLSv1}}
> * {{TLSv1.1}}
> * {{TLSv1.2}}
> * {{SSLv3}}
> {code:title=Example} 
> factory.setIncludeProtocols(new String[] 
> {"SSLv2Hello","SSLv3","TLSv1","TLSv1.1","TLSv1.2"});{code}
> Once set, the protocols may be filtered out using the 
> {{security.server.disabled.protocols}} property from the ambari.properties 
> file. For example:
> {code:title=Disables TLSv1, TLSv1.1, and SSLv2Hello}
> security.server.disabled.protocols=TLSv1.1|TLSv1|SSLv2Hello
> {code}
> The availability of a particular protocol may be tested using the OpenSSL 
> s_client facility.
> {noformat:title=Example: Test for TLSv1.2}
> openssl s_client -connect localhost:8440 -tls1_2
> {noformat}
> {noformat:title=Example successful result}
> CONNECTED(0003)
> depth=0 C = XX, L = Default City, O = Default Company Ltd
> verify error:num=18:self signed certificate
> verify return:1
> depth=0 C = XX, L = Default City, O = Default Company Ltd
> verify return:1
> ---
> Certificate chain
> 0 s:/C=XX/L=Default City/O=Default Company Ltd
>i:/C=XX/L=Default City/O=Default Company Ltd
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MII…
> -END CERTIFICATE-
> subject=/C=XX/L=Default City/O=Default Company Ltd
> issuer=/C=XX/L=Default City/O=Default Company Ltd
> ---
> No client certificate CA names sent
> Server Temp Key: ECDH, secp521r1, 521 bits
> ---
> SSL handshake has read 2248 bytes and written 441 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
> Server public key is 4096 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: ECDHE-RSA-AES256-GCM-SHA384
> Session-ID: 
> 5829F75B49C2FED58C60CB7663181B39BCA3AF473F253EDB4BA04D827B9D58BA
> Session-ID-ctx:
> Master-Key: 
> 46301FB9B4263547C62F8C793380319DC60A10C1D077C7DAB52D328B12D1FB4B868EE5131CD7F62917C02866196317B8
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> Start Time: 1479145307
> Timeout   : 7200 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> {noformat}
> {noformat:title=Example failure result}
> CONNECTED(0003)
> 140518067173192:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake 
> failure:s3_pkt.c:598:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 0 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: 
> Session-ID:
> Session-ID-ctx:
> Master-Key:
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> Start Time: 1479145122
> Timeout   : 7200 (sec)
> Verify return code: 0 (ok)
> ---
> {noformat}
> Note: This does not address the agent-side issue of connecting to an Ambari 
> server where TLSv1 is disabled.  See AMBARI-17666.



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


[jira] [Commented] (AMBARI-18821) Logsearch support KNOX SSO (with JWT)

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18821:
-

ABORTED: Integrated in Jenkins build Ambari-trunk-Commit #6029 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6029/])
AMBARI-18821. Logsearch support KNOX SSO (oleewere) (oleewere: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=7d2fa09ebea5eaf1617e2661ae5691fa3ba7cf76])
* (edit) 
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/filters/LogsearchUsernamePasswordAuthenticationFilter.java
* (edit) ambari-web/app/data/HDP2/site_properties.js
* (edit) 
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/conf/AuthPropsConfig.java
* (edit) 
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/conf/SecurityConfig.java
* (edit) 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-properties.xml
* (add) 
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/model/JWTAuthenticationToken.java
* (edit) 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/themes/theme.json
* (edit) ambari-logsearch/ambari-logsearch-portal/pom.xml
* (add) 
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/filters/LogsearchJWTFilter.java
* (edit) 
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/filters/LogsearchSecurityContextFormationFilter.java


> Logsearch support KNOX SSO (with JWT)
> -
>
> Key: AMBARI-18821
> URL: https://issues.apache.org/jira/browse/AMBARI-18821
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 2.5.0
>
> Attachments: AMBARI-18821.patch
>
>
> Add some new configuration properties to ambari and logsearch as well to 
> handle JWT based authentication: (SSO with KNOX)
> {{logsearch.auth.jwt.enabled}}
> {{logsearch.auth.jwt.provider_url}}
> {{logsearch.auth.jwt.public_key}}
> And some more optional properties
> {{logsearch.auth.jwt.audiances}}
> {{logsearch.auth.jwt.cookie.name}}
> {{logsearch.auth.jwt.query.param.original_url}}



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


[jira] [Commented] (AMBARI-18898) Multiple kerberos name rules can not be set up for Ambari Infra Solr

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18898:
-

ABORTED: Integrated in Jenkins build Ambari-trunk-Commit #6029 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6029/])
AMBARI-18898. Multiple kerberos name rules can not be set up for Ambari 
(oleewere: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=b70c78b2a2f4d1fa33aae180abea6724eca1b01a])
* (add) ambari-logsearch/ambari-logsearch-assembly/src/main/resources/solr
* (edit) 
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/package/scripts/params.py
* (edit) 
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/properties/infra-solr-env.sh.j2
* (edit) ambari-logsearch/ambari-logsearch-assembly/pom.xml


> Multiple kerberos name rules can not be set up for Ambari Infra Solr
> 
>
> Key: AMBARI-18898
> URL: https://issues.apache.org/jira/browse/AMBARI-18898
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-logsearch
>Affects Versions: 2.4.0
>Reporter: Miklos Gergely
>Assignee: Miklos Gergely
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18898.patch
>
>
> If multiple rules are entered into the proprety
> Advanced infra-solr-env / Infra Solr Kerberos name rules
> There are multiple issues here:
> 1. The rules should be escaped, the $ characters in them should be handled, 
> so that the expressions in the rules like $0, $1 are not replaced with the 
> script directory, and the script file name. Currently the user must do this 
> in the value entered, which is not even documented.
> 2. The variable SOLR_KERB_NAME_RULES in infra-solr-env.sh should have quotes 
> around it's value, so that the whole string is assigned to it, not only the 
> first rule.
> 3. SOLR_KERB_NAME_RULES can not be the part of SOLR_AUTHENTICATION_OPTS, 
> because it is handled incorrectly, if an expression like -Dname="value1 
> value2" is passed to the jvm from a bash variable. Therefore 
> /usr/lib/ambari-infra-solr/bin/solr should be updated, and 
> -Dsolr.kerberos.name.rules="$SOLR_KERB_NAME_RULES" should be added directly 
> into the command script.
> Options



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


[jira] [Commented] (AMBARI-18854) Add ability to add custom input descriptor to logfeeder

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18854:
-

ABORTED: Integrated in Jenkins build Ambari-trunk-Commit #6029 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6029/])
AMBARI-18854. Add ability to add custom input descriptor to logfeeder 
(oleewere: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=50a36810bf9bfafb50f13f11bfe39d6b88972b74])
* (edit) 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/logsearch_config_aggregator.py
* (edit) 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logfeeder.py
* (edit) 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/params.py
* (edit) ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logfeeder.py
* (add) 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logfeeder-custom-logsearch-conf.xml
* (edit) 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/templates/HadoopServiceConfig.json.j2


> Add ability to add custom input descriptor to logfeeder
> ---
>
> Key: AMBARI-18854
> URL: https://issues.apache.org/jira/browse/AMBARI-18854
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-logsearch
>Affects Versions: 2.5.0
>Reporter: Miklos Gergely
>Assignee: Miklos Gergely
>Priority: Minor
> Fix For: 2.5.0
>
> Attachments: AMBARI-18854.patch
>
>
> Offer some properties in the logsearch configuration via which the user can 
> set up some other input logs in a similar way as the component logs.



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


[jira] [Commented] (AMBARI-18910) SSL/TLS protocols should be explicitly enabled and then filtered when Ambari starts up

2016-11-16 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on AMBARI-18910:


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

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

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

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

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

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

  
org.apache.ambari.server.controller.metrics.JMXPropertyProviderTest
  
org.apache.ambari.server.state.svccomphost.ServiceComponentHostTest

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

This message is automatically generated.

> SSL/TLS protocols should be explicitly enabled and then filtered when Ambari 
> starts up
> --
>
> Key: AMBARI-18910
> URL: https://issues.apache.org/jira/browse/AMBARI-18910
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18910_branch-2.4_01.patch, 
> AMBARI-18910_branch-2.5_01.patch
>
>
> SSL/TLS protocols should be explicitly enabled and then filtered when Ambari 
> starts up.
> Currently the following protocols are explicitly enabled: 
> * {{SSLv2Hello}}
> * {{TLSv1}}
> {code:title=org/apache/ambari/server/controller/AmbariServer.java:718} 
> factory.setIncludeProtocols(new String[] { "SSLv2Hello","TLSv1"});
> {code}
> However the following protocols should be enabled by default:
> * {{SSLv2Hello}}
> * {{TLSv1}}
> * {{TLSv1.1}}
> * {{TLSv1.2}}
> * {{SSLv3}}
> {code:title=Example} 
> factory.setIncludeProtocols(new String[] 
> {"SSLv2Hello","SSLv3","TLSv1","TLSv1.1","TLSv1.2"});{code}
> Once set, the protocols may be filtered out using the 
> {{security.server.disabled.protocols}} property from the ambari.properties 
> file. For example:
> {code:title=Disables TLSv1, TLSv1.1, and SSLv2Hello}
> security.server.disabled.protocols=TLSv1.1|TLSv1|SSLv2Hello
> {code}
> The availability of a particular protocol may be tested using the OpenSSL 
> s_client facility.
> {noformat:title=Example: Test for TLSv1.2}
> openssl s_client -connect localhost:8440 -tls1_2
> {noformat}
> {noformat:title=Example successful result}
> CONNECTED(0003)
> depth=0 C = XX, L = Default City, O = Default Company Ltd
> verify error:num=18:self signed certificate
> verify return:1
> depth=0 C = XX, L = Default City, O = Default Company Ltd
> verify return:1
> ---
> Certificate chain
> 0 s:/C=XX/L=Default City/O=Default Company Ltd
>i:/C=XX/L=Default City/O=Default Company Ltd
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MII…
> -END CERTIFICATE-
> subject=/C=XX/L=Default City/O=Default Company Ltd
> issuer=/C=XX/L=Default City/O=Default Company Ltd
> ---
> No client certificate CA names sent
> Server Temp Key: ECDH, secp521r1, 521 bits
> ---
> SSL handshake has read 2248 bytes and written 441 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
> Server public key is 4096 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: ECDHE-RSA-AES256-GCM-SHA384
> Session-ID: 
> 5829F75B49C2FED58C60CB7663181B39BCA3AF473F253EDB4BA04D827B9D58BA
> Session-ID-ctx:
> Master-Key: 
> 46301FB9B4263547C62F8C793380319DC60A10C1D077C7DAB52D328B12D1FB4B868EE5131CD7F62917C02866196317B8
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> Start Time: 1479145307
> Timeout   : 7200 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> {noformat}
> {noformat:title=Example failure result}
> CONNECTED(0003)
> 140518067173192:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake 
> failure:s3_pkt.c:598:
> ---
> no peer certificate available
> ---
> No client certificate CA names 

[jira] [Updated] (AMBARI-18910) SSL/TLS protocols should be explicitly enabled and then filtered when Ambari starts up

2016-11-16 Thread Robert Levas (JIRA)

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

Robert Levas updated AMBARI-18910:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to trunk
{noformat}
commit 430ecee6139c413faee7a8ed14a988181688cd54
Author: Robert Levas 
Date:   Wed Nov 16 14:42:23 2016 -0500
{noformat}

Committed to branch-2.5
{noformat}
commit 18ea7cf57997b0579407822f821c96d0b11bd7dd
Author: Robert Levas 
Date:   Wed Nov 16 14:43:41 2016 -0500
{noformat}

Committed to branch-2.4
{noformat}
commit b8d6580593e13f1b5c722bca73190c07b5ed1e41
Author: Robert Levas 
Date:   Wed Nov 16 14:44:56 2016 -0500
{noformat}


> SSL/TLS protocols should be explicitly enabled and then filtered when Ambari 
> starts up
> --
>
> Key: AMBARI-18910
> URL: https://issues.apache.org/jira/browse/AMBARI-18910
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18910_branch-2.4_01.patch, 
> AMBARI-18910_branch-2.5_01.patch
>
>
> SSL/TLS protocols should be explicitly enabled and then filtered when Ambari 
> starts up.
> Currently the following protocols are explicitly enabled: 
> * {{SSLv2Hello}}
> * {{TLSv1}}
> {code:title=org/apache/ambari/server/controller/AmbariServer.java:718} 
> factory.setIncludeProtocols(new String[] { "SSLv2Hello","TLSv1"});
> {code}
> However the following protocols should be enabled by default:
> * {{SSLv2Hello}}
> * {{TLSv1}}
> * {{TLSv1.1}}
> * {{TLSv1.2}}
> * {{SSLv3}}
> {code:title=Example} 
> factory.setIncludeProtocols(new String[] 
> {"SSLv2Hello","SSLv3","TLSv1","TLSv1.1","TLSv1.2"});{code}
> Once set, the protocols may be filtered out using the 
> {{security.server.disabled.protocols}} property from the ambari.properties 
> file. For example:
> {code:title=Disables TLSv1, TLSv1.1, and SSLv2Hello}
> security.server.disabled.protocols=TLSv1.1|TLSv1|SSLv2Hello
> {code}
> The availability of a particular protocol may be tested using the OpenSSL 
> s_client facility.
> {noformat:title=Example: Test for TLSv1.2}
> openssl s_client -connect localhost:8440 -tls1_2
> {noformat}
> {noformat:title=Example successful result}
> CONNECTED(0003)
> depth=0 C = XX, L = Default City, O = Default Company Ltd
> verify error:num=18:self signed certificate
> verify return:1
> depth=0 C = XX, L = Default City, O = Default Company Ltd
> verify return:1
> ---
> Certificate chain
> 0 s:/C=XX/L=Default City/O=Default Company Ltd
>i:/C=XX/L=Default City/O=Default Company Ltd
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MII…
> -END CERTIFICATE-
> subject=/C=XX/L=Default City/O=Default Company Ltd
> issuer=/C=XX/L=Default City/O=Default Company Ltd
> ---
> No client certificate CA names sent
> Server Temp Key: ECDH, secp521r1, 521 bits
> ---
> SSL handshake has read 2248 bytes and written 441 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
> Server public key is 4096 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: ECDHE-RSA-AES256-GCM-SHA384
> Session-ID: 
> 5829F75B49C2FED58C60CB7663181B39BCA3AF473F253EDB4BA04D827B9D58BA
> Session-ID-ctx:
> Master-Key: 
> 46301FB9B4263547C62F8C793380319DC60A10C1D077C7DAB52D328B12D1FB4B868EE5131CD7F62917C02866196317B8
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> Start Time: 1479145307
> Timeout   : 7200 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> {noformat}
> {noformat:title=Example failure result}
> CONNECTED(0003)
> 140518067173192:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake 
> failure:s3_pkt.c:598:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 0 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: 
> Session-ID:
> Session-ID-ctx:
> Master-Key:
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> Start Time: 1479145122
> Timeout   : 7200 (sec)
> Verify return code: 0 (ok)
> ---
> {noformat}
> Note: This does not address the agent-side issue of connecting to an Ambari 
> server where TLSv1 is disabled.  See AMBARI-17666.



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


[jira] [Updated] (AMBARI-18827) Allow acceptor / seclector configuration for API and agent connectors

2016-11-16 Thread Siddharth Wagle (JIRA)

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

Siddharth Wagle updated AMBARI-18827:
-
Status: Patch Available  (was: Reopened)

> Allow acceptor / seclector configuration for API and agent connectors
> -
>
> Key: AMBARI-18827
> URL: https://issues.apache.org/jira/browse/AMBARI-18827
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.2.1
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18827-1.patch, AMBARI-18827.patch
>
>
> _Objectives_:
> - Allow acceptors for agent and api connectors to be configurable
> - The thread pool configuration did not take into account both 2-way and 
> 1-way connectors are configured for agent every time although only one is 
> used and not a mixed-mode. This causes insufficient threads in agent 
> threadpool for a high cpu core environment.



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


[jira] [Updated] (AMBARI-18827) Allow acceptor / seclector configuration for API and agent connectors

2016-11-16 Thread Siddharth Wagle (JIRA)

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

Siddharth Wagle updated AMBARI-18827:
-
Attachment: AMBARI-18827-1.patch

> Allow acceptor / seclector configuration for API and agent connectors
> -
>
> Key: AMBARI-18827
> URL: https://issues.apache.org/jira/browse/AMBARI-18827
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.2.1
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18827-1.patch, AMBARI-18827.patch
>
>
> _Objectives_:
> - Allow acceptors for agent and api connectors to be configurable
> - The thread pool configuration did not take into account both 2-way and 
> 1-way connectors are configured for agent every time although only one is 
> used and not a mixed-mode. This causes insufficient threads in agent 
> threadpool for a high cpu core environment.



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


[jira] [Commented] (AMBARI-18476) Ambari UI changes to support PAM authentication

2016-11-16 Thread Di Li (JIRA)

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

Di Li commented on AMBARI-18476:


Following unit tests failed, none is related to the ambari admin view code 
change from this JIRA.
Test Result (12 failures / +1)
org.apache.ambari.server.controller.metrics.JMXPropertyProviderTest.testJMXPropertyProviderAsAdministrator
org.apache.ambari.server.state.svccomphost.ServiceComponentHostTest.testStaleConfigs
org.apache.ambari.server.controller.internal.StackDefinedPropertyProviderTest.testStackDefinedPropertyProviderAsClusterAdministrator
org.apache.ambari.server.controller.internal.StackDefinedPropertyProviderTest.testStackDefinedPropertyProviderAsAdministrator
org.apache.ambari.server.controller.internal.StackDefinedPropertyProviderTest.testStackDefinedPropertyProviderAsServiceAdministrator
org.apache.ambari.server.controller.metrics.RestMetricsPropertyProviderTest.testRestMetricsPropertyProviderAsClusterAdministrator
org.apache.ambari.server.controller.metrics.RestMetricsPropertyProviderTest.testRestMetricsPropertyProviderAsAdministrator
org.apache.ambari.server.controller.metrics.RestMetricsPropertyProviderTest.testRestMetricsPropertyProviderAsServiceAdministrator
org.apache.ambari.server.controller.metrics.RestMetricsPropertyProviderTest.testRestMetricsPropertyProviderAsViewUser
org.apache.ambari.server.controller.metrics.RestMetricsPropertyProviderTest.testResolvePort
org.apache.ambari.server.state.ServicePropertiesTest.validatePropertySchemaOfServiceXMLs
org.apache.ambari.server.upgrade.UpgradeCatalog250Test.testExecuteDMLUpdates

> Ambari UI changes to support PAM authentication
> ---
>
> Key: AMBARI-18476
> URL: https://issues.apache.org/jira/browse/AMBARI-18476
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: trunk
>Reporter: Sangeeta Ravindran
>Assignee: Sangeeta Ravindran
> Fix For: trunk, 2.5.0
>
> Attachments: AMBARI-18476.patch, AMBARI-18476_2.5patch
>
>
> AMBARI-12263 adds support for PAM as authentication mechanism for accessing 
> Ambari UI/REST. 
> Since a new column group_type has been added for groups, the UI will display 
> labels for group type and enable/disable group delete/add member 
> functionality based on the group_type instead of the ldap_group flag.
> The user_type will be used to determine if the user can be deleted or if the 
> user's password can be changed.



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


[jira] [Updated] (AMBARI-16169) Enhance blueprints to export placeholder/token for external host properties

2016-11-16 Thread Amruta Borkar (JIRA)

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

Amruta Borkar updated AMBARI-16169:
---
Summary: Enhance blueprints to export placeholder/token for external host 
properties  (was: Enhance blueprints to export placeholder/token for 
Kerberos-related properties)

> Enhance blueprints to export placeholder/token for external host properties
> ---
>
> Key: AMBARI-16169
> URL: https://issues.apache.org/jira/browse/AMBARI-16169
> Project: Ambari
>  Issue Type: Technical task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
>
> Enhance blueprints to export placeholder/token for Kerberos-related properties
> Kerberos blueprints can use several hostname properties such as:
> "admin_server_host" in "kerberos-env"
> "kdc_host" in "kerberos-env"
> We should be able to introduce a reference that is exportable and then 
> addressed appropriately with some associated defaults in the cluster 
> template. If these are not specified in the template, it would be an error 
> condition unless there could be appropriate defaults that could be "assumed" 
> based on the cluster host list.



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


[jira] [Commented] (AMBARI-18476) Ambari UI changes to support PAM authentication

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18476:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #342 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/342/])
AMBARI-18476: Ambari UI changes to support PAM authentication (Sangeeta (dili: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=31caa528ff07c8cb1f58ff355fc4c82c3cf7fdf3])
* (edit) ambari-admin/src/main/resources/ui/admin-web/app/views/groups/list.html
* (edit) ambari-admin/src/main/resources/ui/admin-web/app/views/users/show.html
* (edit) 
ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/groups/GroupsListCtrl.js
* (edit) ambari-admin/src/main/resources/ui/admin-web/app/views/groups/edit.html
* (edit) 
ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/users/UsersShowCtrl.js
* (edit) ambari-admin/src/main/resources/ui/admin-web/app/scripts/i18n.config.js
* (edit) 
ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/Group.js
* (edit) ambari-admin/src/main/resources/ui/admin-web/app/index.html
* (add) 
ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/GroupConstants.js
* (edit) 
ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/groups/GroupsEditCtrl.js
* (edit) 
ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/UserConstants.js


> Ambari UI changes to support PAM authentication
> ---
>
> Key: AMBARI-18476
> URL: https://issues.apache.org/jira/browse/AMBARI-18476
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: trunk
>Reporter: Sangeeta Ravindran
>Assignee: Sangeeta Ravindran
> Fix For: trunk, 2.5.0
>
> Attachments: AMBARI-18476.patch, AMBARI-18476_2.5patch
>
>
> AMBARI-12263 adds support for PAM as authentication mechanism for accessing 
> Ambari UI/REST. 
> Since a new column group_type has been added for groups, the UI will display 
> labels for group type and enable/disable group delete/add member 
> functionality based on the group_type instead of the ldap_group flag.
> The user_type will be used to determine if the user can be deleted or if the 
> user's password can be changed.



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


[jira] [Reopened] (AMBARI-18827) Allow acceptor / seclector configuration for API and agent connectors

2016-11-16 Thread Nahappan Somasundaram (JIRA)

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

Nahappan Somasundaram reopened AMBARI-18827:


 ambari-agent fails to register with the server:
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line 167, 
in registerWithServer
ret = self.sendRequest(self.registerUrl, data)
  File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line 514, 
in sendRequest
raise IOError('Request to {0} failed due to {1}'.format(url, 
str(exception)))
IOError: Request to 
https://localhost:8441/agent/v1/register/c6402.ambari.apache.org failed due to 
[Errno 111] Connection refused

> Allow acceptor / seclector configuration for API and agent connectors
> -
>
> Key: AMBARI-18827
> URL: https://issues.apache.org/jira/browse/AMBARI-18827
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.2.1
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18827.patch
>
>
> _Objectives_:
> - Allow acceptors for agent and api connectors to be configurable
> - The thread pool configuration did not take into account both 2-way and 
> 1-way connectors are configured for agent every time although only one is 
> used and not a mixed-mode. This causes insufficient threads in agent 
> threadpool for a high cpu core environment.



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


[jira] [Updated] (AMBARI-18910) SSL/TLS protocols should be explicitly enabled and then filtered when Ambari starts up

2016-11-16 Thread Robert Levas (JIRA)

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

Robert Levas updated AMBARI-18910:
--
Status: Patch Available  (was: Open)

> SSL/TLS protocols should be explicitly enabled and then filtered when Ambari 
> starts up
> --
>
> Key: AMBARI-18910
> URL: https://issues.apache.org/jira/browse/AMBARI-18910
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18910_branch-2.4_01.patch, 
> AMBARI-18910_branch-2.5_01.patch
>
>
> SSL/TLS protocols should be explicitly enabled and then filtered when Ambari 
> starts up.
> Currently the following protocols are explicitly enabled: 
> * {{SSLv2Hello}}
> * {{TLSv1}}
> {code:title=org/apache/ambari/server/controller/AmbariServer.java:718} 
> factory.setIncludeProtocols(new String[] { "SSLv2Hello","TLSv1"});
> {code}
> However the following protocols should be enabled by default:
> * {{SSLv2Hello}}
> * {{TLSv1}}
> * {{TLSv1.1}}
> * {{TLSv1.2}}
> * {{SSLv3}}
> {code:title=Example} 
> factory.setIncludeProtocols(new String[] 
> {"SSLv2Hello","SSLv3","TLSv1","TLSv1.1","TLSv1.2"});{code}
> Once set, the protocols may be filtered out using the 
> {{security.server.disabled.protocols}} property from the ambari.properties 
> file. For example:
> {code:title=Disables TLSv1, TLSv1.1, and SSLv2Hello}
> security.server.disabled.protocols=TLSv1.1|TLSv1|SSLv2Hello
> {code}
> The availability of a particular protocol may be tested using the OpenSSL 
> s_client facility.
> {noformat:title=Example: Test for TLSv1.2}
> openssl s_client -connect localhost:8440 -tls1_2
> {noformat}
> {noformat:title=Example successful result}
> CONNECTED(0003)
> depth=0 C = XX, L = Default City, O = Default Company Ltd
> verify error:num=18:self signed certificate
> verify return:1
> depth=0 C = XX, L = Default City, O = Default Company Ltd
> verify return:1
> ---
> Certificate chain
> 0 s:/C=XX/L=Default City/O=Default Company Ltd
>i:/C=XX/L=Default City/O=Default Company Ltd
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MII…
> -END CERTIFICATE-
> subject=/C=XX/L=Default City/O=Default Company Ltd
> issuer=/C=XX/L=Default City/O=Default Company Ltd
> ---
> No client certificate CA names sent
> Server Temp Key: ECDH, secp521r1, 521 bits
> ---
> SSL handshake has read 2248 bytes and written 441 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
> Server public key is 4096 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: ECDHE-RSA-AES256-GCM-SHA384
> Session-ID: 
> 5829F75B49C2FED58C60CB7663181B39BCA3AF473F253EDB4BA04D827B9D58BA
> Session-ID-ctx:
> Master-Key: 
> 46301FB9B4263547C62F8C793380319DC60A10C1D077C7DAB52D328B12D1FB4B868EE5131CD7F62917C02866196317B8
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> Start Time: 1479145307
> Timeout   : 7200 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> {noformat}
> {noformat:title=Example failure result}
> CONNECTED(0003)
> 140518067173192:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake 
> failure:s3_pkt.c:598:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 0 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: 
> Session-ID:
> Session-ID-ctx:
> Master-Key:
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> Start Time: 1479145122
> Timeout   : 7200 (sec)
> Verify return code: 0 (ok)
> ---
> {noformat}
> Note: This does not address the agent-side issue of connecting to an Ambari 
> server where TLSv1 is disabled.  See AMBARI-17666.



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


[jira] [Updated] (AMBARI-18910) SSL/TLS protocols should be explicitly enabled and then filtered when Ambari starts up

2016-11-16 Thread Robert Levas (JIRA)

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

Robert Levas updated AMBARI-18910:
--
Attachment: AMBARI-18910_branch-2.5_01.patch
AMBARI-18910_branch-2.4_01.patch

> SSL/TLS protocols should be explicitly enabled and then filtered when Ambari 
> starts up
> --
>
> Key: AMBARI-18910
> URL: https://issues.apache.org/jira/browse/AMBARI-18910
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18910_branch-2.4_01.patch, 
> AMBARI-18910_branch-2.5_01.patch
>
>
> SSL/TLS protocols should be explicitly enabled and then filtered when Ambari 
> starts up.
> Currently the following protocols are explicitly enabled: 
> * {{SSLv2Hello}}
> * {{TLSv1}}
> {code:title=org/apache/ambari/server/controller/AmbariServer.java:718} 
> factory.setIncludeProtocols(new String[] { "SSLv2Hello","TLSv1"});
> {code}
> However the following protocols should be enabled by default:
> * {{SSLv2Hello}}
> * {{TLSv1}}
> * {{TLSv1.1}}
> * {{TLSv1.2}}
> * {{SSLv3}}
> {code:title=Example} 
> factory.setIncludeProtocols(new String[] 
> {"SSLv2Hello","SSLv3","TLSv1","TLSv1.1","TLSv1.2"});{code}
> Once set, the protocols may be filtered out using the 
> {{security.server.disabled.protocols}} property from the ambari.properties 
> file. For example:
> {code:title=Disables TLSv1, TLSv1.1, and SSLv2Hello}
> security.server.disabled.protocols=TLSv1.1|TLSv1|SSLv2Hello
> {code}
> The availability of a particular protocol may be tested using the OpenSSL 
> s_client facility.
> {noformat:title=Example: Test for TLSv1.2}
> openssl s_client -connect localhost:8440 -tls1_2
> {noformat}
> {noformat:title=Example successful result}
> CONNECTED(0003)
> depth=0 C = XX, L = Default City, O = Default Company Ltd
> verify error:num=18:self signed certificate
> verify return:1
> depth=0 C = XX, L = Default City, O = Default Company Ltd
> verify return:1
> ---
> Certificate chain
> 0 s:/C=XX/L=Default City/O=Default Company Ltd
>i:/C=XX/L=Default City/O=Default Company Ltd
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MII…
> -END CERTIFICATE-
> subject=/C=XX/L=Default City/O=Default Company Ltd
> issuer=/C=XX/L=Default City/O=Default Company Ltd
> ---
> No client certificate CA names sent
> Server Temp Key: ECDH, secp521r1, 521 bits
> ---
> SSL handshake has read 2248 bytes and written 441 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
> Server public key is 4096 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: ECDHE-RSA-AES256-GCM-SHA384
> Session-ID: 
> 5829F75B49C2FED58C60CB7663181B39BCA3AF473F253EDB4BA04D827B9D58BA
> Session-ID-ctx:
> Master-Key: 
> 46301FB9B4263547C62F8C793380319DC60A10C1D077C7DAB52D328B12D1FB4B868EE5131CD7F62917C02866196317B8
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> Start Time: 1479145307
> Timeout   : 7200 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> {noformat}
> {noformat:title=Example failure result}
> CONNECTED(0003)
> 140518067173192:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake 
> failure:s3_pkt.c:598:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 0 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: 
> Session-ID:
> Session-ID-ctx:
> Master-Key:
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> Start Time: 1479145122
> Timeout   : 7200 (sec)
> Verify return code: 0 (ok)
> ---
> {noformat}
> Note: This does not address the agent-side issue of connecting to an Ambari 
> server where TLSv1 is disabled.  See AMBARI-17666.



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


[jira] [Created] (AMBARI-18910) SSL/TLS protocols should be explicitly enabled and then filtered when Ambari starts up

2016-11-16 Thread Robert Levas (JIRA)
Robert Levas created AMBARI-18910:
-

 Summary: SSL/TLS protocols should be explicitly enabled and then 
filtered when Ambari starts up
 Key: AMBARI-18910
 URL: https://issues.apache.org/jira/browse/AMBARI-18910
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.4.0
Reporter: Robert Levas
Assignee: Robert Levas
Priority: Critical
 Fix For: 2.4.2


SSL/TLS protocols should be explicitly enabled and then filtered when Ambari 
starts up.

Currently the following protocols are explicitly enabled: 
* {{SSLv2Hello}}
* {{TLSv1}}

{code:title=org/apache/ambari/server/controller/AmbariServer.java:718} 
factory.setIncludeProtocols(new String[] { "SSLv2Hello","TLSv1"});
{code}

However the following protocols should be enabled by default:
* {{SSLv2Hello}}
* {{TLSv1}}
* {{TLSv1.1}}
* {{TLSv1.2}}
* {{SSLv3}}

{code:title=Example} 
factory.setIncludeProtocols(new String[] 
{"SSLv2Hello","SSLv3","TLSv1","TLSv1.1","TLSv1.2"});{code}

Once set, the protocols may be filtered out using the 
{{security.server.disabled.protocols}} property from the ambari.properties 
file. For example:
{code:title=Disables TLSv1, TLSv1.1, and SSLv2Hello}
security.server.disabled.protocols=TLSv1.1|TLSv1|SSLv2Hello
{code}

The availability of a particular protocol may be tested using the OpenSSL 
s_client facility.

{noformat:title=Example: Test for TLSv1.2}
openssl s_client -connect localhost:8440 -tls1_2
{noformat}

{noformat:title=Example successful result}
CONNECTED(0003)
depth=0 C = XX, L = Default City, O = Default Company Ltd
verify error:num=18:self signed certificate
verify return:1
depth=0 C = XX, L = Default City, O = Default Company Ltd
verify return:1
---
Certificate chain
0 s:/C=XX/L=Default City/O=Default Company Ltd
   i:/C=XX/L=Default City/O=Default Company Ltd
---
Server certificate
-BEGIN CERTIFICATE-
MII…
-END CERTIFICATE-
subject=/C=XX/L=Default City/O=Default Company Ltd
issuer=/C=XX/L=Default City/O=Default Company Ltd
---
No client certificate CA names sent
Server Temp Key: ECDH, secp521r1, 521 bits
---
SSL handshake has read 2248 bytes and written 441 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 5829F75B49C2FED58C60CB7663181B39BCA3AF473F253EDB4BA04D827B9D58BA
Session-ID-ctx:
Master-Key: 
46301FB9B4263547C62F8C793380319DC60A10C1D077C7DAB52D328B12D1FB4B868EE5131CD7F62917C02866196317B8
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1479145307
Timeout   : 7200 (sec)
Verify return code: 18 (self signed certificate)
---
{noformat}

{noformat:title=Example failure result}
CONNECTED(0003)
140518067173192:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake 
failure:s3_pkt.c:598:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1.2
Cipher: 
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1479145122
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
---
{noformat}


Note: This does not address the agent-side issue of connecting to an Ambari 
server where TLSv1 is disabled.  See AMBARI-17666.




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


[jira] [Updated] (AMBARI-18476) Ambari UI changes to support PAM authentication

2016-11-16 Thread Di Li (JIRA)

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

Di Li updated AMBARI-18476:
---
   Resolution: Fixed
Fix Version/s: 2.5.0
   trunk
   Status: Resolved  (was: Patch Available)

> Ambari UI changes to support PAM authentication
> ---
>
> Key: AMBARI-18476
> URL: https://issues.apache.org/jira/browse/AMBARI-18476
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: trunk
>Reporter: Sangeeta Ravindran
>Assignee: Sangeeta Ravindran
> Fix For: trunk, 2.5.0
>
> Attachments: AMBARI-18476.patch, AMBARI-18476_2.5patch
>
>
> AMBARI-12263 adds support for PAM as authentication mechanism for accessing 
> Ambari UI/REST. 
> Since a new column group_type has been added for groups, the UI will display 
> labels for group type and enable/disable group delete/add member 
> functionality based on the group_type instead of the ldap_group flag.
> The user_type will be used to determine if the user can be deleted or if the 
> user's password can be changed.



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


[jira] [Commented] (AMBARI-18476) Ambari UI changes to support PAM authentication

2016-11-16 Thread Di Li (JIRA)

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

Di Li commented on AMBARI-18476:


Pushed to trunk as 
https://git-wip-us.apache.org/repos/asf?p=ambari.git;a=commit;h=745d1057b04f1ecf8a089d437e49a1ef672c2090
Pushed to branch 2.5 as  
https://git-wip-us.apache.org/repos/asf?p=ambari.git;a=commit;h=31caa528ff07c8cb1f58ff355fc4c82c3cf7fdf3


> Ambari UI changes to support PAM authentication
> ---
>
> Key: AMBARI-18476
> URL: https://issues.apache.org/jira/browse/AMBARI-18476
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: trunk
>Reporter: Sangeeta Ravindran
>Assignee: Sangeeta Ravindran
> Attachments: AMBARI-18476.patch, AMBARI-18476_2.5patch
>
>
> AMBARI-12263 adds support for PAM as authentication mechanism for accessing 
> Ambari UI/REST. 
> Since a new column group_type has been added for groups, the UI will display 
> labels for group type and enable/disable group delete/add member 
> functionality based on the group_type instead of the ldap_group flag.
> The user_type will be used to determine if the user can be deleted or if the 
> user's password can be changed.



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


[jira] [Commented] (AMBARI-18871) HTTP responses needs to have the character encoding specified in the content type header

2016-11-16 Thread Robert Levas (JIRA)

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

Robert Levas commented on AMBARI-18871:
---

[~u39kun], [~jaimin],  Can you take a look at this and make sure the location 
for setting the character set is ok.  I am doubtful that setting the character 
set for the UI in the backend is appropriate. However there may be no other 
place for this. 


> HTTP responses needs to have the character encoding specified in the content 
> type header
> 
>
> Key: AMBARI-18871
> URL: https://issues.apache.org/jira/browse/AMBARI-18871
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Anita Gnanamalar Jebaraj
>Assignee: Anita Gnanamalar Jebaraj
> Fix For: trunk
>
> Attachments: AMBARI-18871-updated.patch, AMBARI-18871.patch
>
>
> The charset information(UTF-8) can be added to all the response headers to 
> harden the security for the client. When the charset information is not 
> specified the web browser may choose a different encoding by guessing which 
> encoding is actually being used by the web page. 
> This specific issue is mentioned in the section 3.1.1.5 of RFC7231



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


[jira] [Commented] (AMBARI-18872) Zeppelin notebook execution fails due missing spark dependency

2016-11-16 Thread Hudson (JIRA)

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

Hudson commented on AMBARI-18872:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #341 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/341/])
AMBARI-18872 Zeppelin notebook execution fails due missing spark 
(renjith.kamath: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=48074fc7ae52e9603431bc6a85ef57c7ec96fcd7])
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.6/services/ZEPPELIN/metainfo.xml
* (edit) ambari-server/src/main/resources/scripts/Ambaripreupload.py
* (edit) 
ambari-server/src/main/resources/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py


> Zeppelin notebook execution fails due missing spark dependency
> --
>
> Key: AMBARI-18872
> URL: https://issues.apache.org/jira/browse/AMBARI-18872
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
> Fix For: 2.5.0
>
> Attachments: AMBARI-18872-branch-2.5-v1.patch, 
> AMBARI-18872-branch-2.5-v2.patch
>
>
> {code}
> org.apache.hadoop.security.AccessControlException: Permission denied: 
> user=zeppelin, access=WRITE, 
> inode="/user/zeppelin/.sparkStaging/application_1478558403343_0012":hdfs:hdfs:drwxr-xr-x
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:319)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:292)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:213)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:190)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1827)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1811)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkAncestorAccess(FSDirectory.java:1794)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirMkdirOp.mkdirs(FSDirMkdirOp.java:71)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.mkdirs(FSNamesystem.java:4017)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.mkdirs(NameNodeRpcServer.java:1102)
> at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.mkdirs(ClientNamenodeProtocolServerSideTranslatorPB.java:630)
> at 
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
> at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:640)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:982)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2313)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2309)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1724)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2307)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at 
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
> at 
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:73)
> at org.apache.hadoop.hdfs.DFSClient.primitiveMkdir(DFSClient.java:3063)
> at org.apache.hadoop.hdfs.DFSClient.mkdirs(DFSClient.java:3031)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem$24.doCall(DistributedFileSystem.java:1162)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem$24.doCall(DistributedFileSystem.java:1158)
> at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem.mkdirsInternal(DistributedFileSystem.java:1158)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem.mkdirs(DistributedFileSystem.java:1150)
> at org.apache.hadoop.fs.FileSystem.mkdirs(FileSystem.java:1898)
> at org.apache.hadoop.fs.FileSystem.mkdirs(FileSystem.java:613)
> at org.apache.spark.deploy.yarn.Client.prepareLocalResources(Client.scala:394)
> at 
> org.apache.spark.deploy.yarn.Client.createContainerLaunchContext(Client.scala:763)
> at 

[jira] [Updated] (AMBARI-18909) Log Search - make logsearch rest api docs as default under /docs/ instead of petstore

2016-11-16 Thread JIRA

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

Olivér Szabó updated AMBARI-18909:
--
Attachment: AMBARI-18909.patch

> Log Search - make logsearch rest api docs as default under /docs/ instead of 
> petstore
> -
>
> Key: AMBARI-18909
> URL: https://issues.apache.org/jira/browse/AMBARI-18909
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-logsearch
>Affects Versions: 2.5.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 2.5.0
>
> Attachments: AMBARI-18909.patch
>
>




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


[jira] [Commented] (AMBARI-18907) Auto-start should respect maintenance mode on hosts and services

2016-11-16 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on AMBARI-18907:


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

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

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

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

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

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

  
org.apache.ambari.server.state.svccomphost.ServiceComponentHostTest

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

This message is automatically generated.

> Auto-start should respect maintenance mode on hosts and services
> 
>
> Key: AMBARI-18907
> URL: https://issues.apache.org/jira/browse/AMBARI-18907
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: rb53811.patch
>
>
> Auto-start should respect maintenance mode. If any host or service (meaning 
> it's host components) or component is in maintenance mode, the auto-start 
> directive should be ignored.
> Maintenance mode is ignored at host and service level. If you mark a host as 
> in maintenance mode, and then restart the host, the services marked for 
> auto-restart are started on that host. What should happen is those services 
> should be ignored and excluded from auto-restart as the host is in 
> maintenance mode. Currently, auto-start respects maintenance mode on 
> component level alone.



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


[jira] [Commented] (AMBARI-18637) Management pack purge option should warn user and ask for confirmation before purging

2016-11-16 Thread Jayush Luniya (JIRA)

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

Jayush Luniya commented on AMBARI-18637:


Build failures not related to the addendum patch as it is a python code change. 

mvn clean install -DskipSurefireTests
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 5:16.144s
[INFO] Finished at: Wed Nov 16 08:38:04 PST 2016
[INFO] Final Memory: 184M/1730M
[INFO] 

> Management pack purge option should warn user and ask for confirmation before 
> purging
> -
>
> Key: AMBARI-18637
> URL: https://issues.apache.org/jira/browse/AMBARI-18637
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.2
>
> Attachments: AMBARI-18637.addendum.patch, AMBARI-18637.patch
>
>




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


[jira] [Created] (AMBARI-18909) Log Search - make logsearch rest api docs as default under /docs/ instead of petstore

2016-11-16 Thread JIRA
Olivér Szabó created AMBARI-18909:
-

 Summary: Log Search - make logsearch rest api docs as default 
under /docs/ instead of petstore
 Key: AMBARI-18909
 URL: https://issues.apache.org/jira/browse/AMBARI-18909
 Project: Ambari
  Issue Type: Bug
  Components: ambari-logsearch
Affects Versions: 2.5.0
Reporter: Olivér Szabó
Assignee: Olivér Szabó
 Fix For: 2.5.0






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


[jira] [Updated] (AMBARI-18872) Zeppelin notebook execution fails due missing spark dependency

2016-11-16 Thread Renjith Kamath (JIRA)

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

Renjith Kamath updated AMBARI-18872:

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

> Zeppelin notebook execution fails due missing spark dependency
> --
>
> Key: AMBARI-18872
> URL: https://issues.apache.org/jira/browse/AMBARI-18872
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
> Fix For: 2.5.0
>
> Attachments: AMBARI-18872-branch-2.5-v1.patch, 
> AMBARI-18872-branch-2.5-v2.patch
>
>
> {code}
> org.apache.hadoop.security.AccessControlException: Permission denied: 
> user=zeppelin, access=WRITE, 
> inode="/user/zeppelin/.sparkStaging/application_1478558403343_0012":hdfs:hdfs:drwxr-xr-x
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:319)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:292)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:213)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:190)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1827)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1811)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkAncestorAccess(FSDirectory.java:1794)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirMkdirOp.mkdirs(FSDirMkdirOp.java:71)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.mkdirs(FSNamesystem.java:4017)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.mkdirs(NameNodeRpcServer.java:1102)
> at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.mkdirs(ClientNamenodeProtocolServerSideTranslatorPB.java:630)
> at 
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
> at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:640)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:982)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2313)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2309)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1724)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2307)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at 
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
> at 
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:73)
> at org.apache.hadoop.hdfs.DFSClient.primitiveMkdir(DFSClient.java:3063)
> at org.apache.hadoop.hdfs.DFSClient.mkdirs(DFSClient.java:3031)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem$24.doCall(DistributedFileSystem.java:1162)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem$24.doCall(DistributedFileSystem.java:1158)
> at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem.mkdirsInternal(DistributedFileSystem.java:1158)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem.mkdirs(DistributedFileSystem.java:1150)
> at org.apache.hadoop.fs.FileSystem.mkdirs(FileSystem.java:1898)
> at org.apache.hadoop.fs.FileSystem.mkdirs(FileSystem.java:613)
> at org.apache.spark.deploy.yarn.Client.prepareLocalResources(Client.scala:394)
> at 
> org.apache.spark.deploy.yarn.Client.createContainerLaunchContext(Client.scala:763)
> at org.apache.spark.deploy.yarn.Client.submitApplication(Client.scala:143)
> at 
> org.apache.spark.scheduler.cluster.YarnClientSchedulerBackend.start(YarnClientSchedulerBackend.scala:56)
> at 
> org.apache.spark.scheduler.TaskSchedulerImpl.start(TaskSchedulerImpl.scala:144)
> at org.apache.spark.SparkContext.(SparkContext.scala:530)
> at 
> org.apache.zeppelin.spark.SparkInterpreter.createSparkContext_1(SparkInterpreter.java:463)
> at 
> org.apache.zeppelin.spark.SparkInterpreter.createSparkContext(SparkInterpreter.java:361)
> at 
> 

[jira] [Commented] (AMBARI-18872) Zeppelin notebook execution fails due missing spark dependency

2016-11-16 Thread Renjith Kamath (JIRA)

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

Renjith Kamath commented on AMBARI-18872:
-

Committed to trunk and branch-2.5

> Zeppelin notebook execution fails due missing spark dependency
> --
>
> Key: AMBARI-18872
> URL: https://issues.apache.org/jira/browse/AMBARI-18872
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
> Fix For: 2.5.0
>
> Attachments: AMBARI-18872-branch-2.5-v1.patch, 
> AMBARI-18872-branch-2.5-v2.patch
>
>
> {code}
> org.apache.hadoop.security.AccessControlException: Permission denied: 
> user=zeppelin, access=WRITE, 
> inode="/user/zeppelin/.sparkStaging/application_1478558403343_0012":hdfs:hdfs:drwxr-xr-x
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:319)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:292)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:213)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:190)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1827)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1811)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkAncestorAccess(FSDirectory.java:1794)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSDirMkdirOp.mkdirs(FSDirMkdirOp.java:71)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.mkdirs(FSNamesystem.java:4017)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.mkdirs(NameNodeRpcServer.java:1102)
> at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.mkdirs(ClientNamenodeProtocolServerSideTranslatorPB.java:630)
> at 
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
> at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:640)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:982)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2313)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2309)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1724)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2307)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at 
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
> at 
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:73)
> at org.apache.hadoop.hdfs.DFSClient.primitiveMkdir(DFSClient.java:3063)
> at org.apache.hadoop.hdfs.DFSClient.mkdirs(DFSClient.java:3031)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem$24.doCall(DistributedFileSystem.java:1162)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem$24.doCall(DistributedFileSystem.java:1158)
> at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem.mkdirsInternal(DistributedFileSystem.java:1158)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem.mkdirs(DistributedFileSystem.java:1150)
> at org.apache.hadoop.fs.FileSystem.mkdirs(FileSystem.java:1898)
> at org.apache.hadoop.fs.FileSystem.mkdirs(FileSystem.java:613)
> at org.apache.spark.deploy.yarn.Client.prepareLocalResources(Client.scala:394)
> at 
> org.apache.spark.deploy.yarn.Client.createContainerLaunchContext(Client.scala:763)
> at org.apache.spark.deploy.yarn.Client.submitApplication(Client.scala:143)
> at 
> org.apache.spark.scheduler.cluster.YarnClientSchedulerBackend.start(YarnClientSchedulerBackend.scala:56)
> at 
> org.apache.spark.scheduler.TaskSchedulerImpl.start(TaskSchedulerImpl.scala:144)
> at org.apache.spark.SparkContext.(SparkContext.scala:530)
> at 
> org.apache.zeppelin.spark.SparkInterpreter.createSparkContext_1(SparkInterpreter.java:463)
> at 
> org.apache.zeppelin.spark.SparkInterpreter.createSparkContext(SparkInterpreter.java:361)
> at 
> 

  1   2   >