date:20150908


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

Gautam Borad updated AMBARI-13040:
--
Attachment: AMBARI-13040.patch

> Improve help text description for Ranger properties in Ambari
> -
>
> Key: AMBARI-13040
> URL: https://issues.apache.org/jira/browse/AMBARI-13040
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.1.2
>
> Attachments: AMBARI-13040.patch
>
>
> Improve help text description for Ranger properties in Ambari.



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

Review Request 38207: AMBARI-13040 : Improve help text description for Ranger properties in Ambari

2015-09-08 Thread Gautam Borad


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38207/
---

Review request for Ambari, Alejandro Fernandez, Mahadev Konar, Sumit Mohanty, 
Selvamohan Neethiraj, Velmurugan Periasamy, and Yusaku Sako.


Bugs: AMBARI-13040
https://issues.apache.org/jira/browse/AMBARI-13040


Repository: ambari


Description
---

Add and update help text description for various Ranger and Ranger component 
properties.


Diffs
-

  
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/configuration/ranger-knox-plugin-properties.xml
 8bf1dd3 
  
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/configuration/ranger-kms-audit.xml
 e5bd75e 
  
ambari-server/src/main/resources/stacks/HDP/2.2/services/HBASE/configuration/ranger-hbase-plugin-properties.xml
 30af22c 
  
ambari-server/src/main/resources/stacks/HDP/2.2/services/HDFS/configuration/ranger-hdfs-plugin-properties.xml
 32f7c54 
  
ambari-server/src/main/resources/stacks/HDP/2.2/services/HIVE/configuration/ranger-hive-plugin-properties.xml
 1b121bc 
  
ambari-server/src/main/resources/stacks/HDP/2.2/services/STORM/configuration/ranger-storm-plugin-properties.xml
 e0c47db 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/HBASE/configuration/ranger-hbase-audit.xml
 070b637 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/HBASE/configuration/ranger-hbase-policymgr-ssl.xml
 20b5e7d 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/HDFS/configuration/ranger-hdfs-audit.xml
 57329e3 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/HDFS/configuration/ranger-hdfs-policymgr-ssl.xml
 8f48fcf 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/HIVE/configuration/ranger-hive-audit.xml
 d5f07a9 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/HIVE/configuration/ranger-hive-policymgr-ssl.xml
 d4a6d45 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/HIVE/configuration/ranger-hive-security.xml
 5407ccf 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/KAFKA/configuration/ranger-kafka-audit.xml
 1433d0a 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/KAFKA/configuration/ranger-kafka-plugin-properties.xml
 893652d 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/KAFKA/configuration/ranger-kafka-policymgr-ssl.xml
 447320f 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/KNOX/configuration/ranger-knox-audit.xml
 ba8710a 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/KNOX/configuration/ranger-knox-policymgr-ssl.xml
 a39ff0b 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/RANGER/configuration/ranger-admin-site.xml
 57d21dd 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/RANGER/configuration/ranger-ugsync-site.xml
 d7dce19 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/STORM/configuration/ranger-storm-audit.xml
 3687e88 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/STORM/configuration/ranger-storm-policymgr-ssl.xml
 4fc6452 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/YARN/configuration/ranger-yarn-audit.xml
 044f8ec 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/YARN/configuration/ranger-yarn-plugin-properties.xml
 db456da 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/YARN/configuration/ranger-yarn-policymgr-ssl.xml
 ffb06d9 

Diff: https://reviews.apache.org/r/38207/diff/


Testing
---

Verified help texts on a Ambari based cluster for Ranger and its plugins.


Thanks,

Gautam Borad

[jira] [Updated] (AMBARI-13040) Improve help text description for Ranger properties in Ambari


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

Gautam Borad updated AMBARI-13040:
--
Summary: Improve help text description for Ranger properties in Ambari  
(was: Handle help text description for Ranger LDAP / AD properties in Ambari)

> Improve help text description for Ranger properties in Ambari
> -
>
> Key: AMBARI-13040
> URL: https://issues.apache.org/jira/browse/AMBARI-13040
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.1.2
>
>
> Handle help text description for Ranger LDAP / AD properties in Ambari.



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

[jira] [Updated] (AMBARI-13040) Improve help text description for Ranger properties in Ambari


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

Gautam Borad updated AMBARI-13040:
--
Description: Improve help text description for Ranger properties in Ambari. 
 (was: Handle help text description for Ranger LDAP / AD properties in Ambari.)

> Improve help text description for Ranger properties in Ambari
> -
>
> Key: AMBARI-13040
> URL: https://issues.apache.org/jira/browse/AMBARI-13040
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.1.2
>
>
> Improve help text description for Ranger properties in Ambari.



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

[jira] [Created] (AMBARI-13040) Handle help text description for Ranger LDAP / AD properties in Ambari

Gautam Borad created AMBARI-13040:
-

 Summary: Handle help text description for Ranger LDAP / AD 
properties in Ambari
 Key: AMBARI-13040
 URL: https://issues.apache.org/jira/browse/AMBARI-13040
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.1.2
Reporter: Gautam Borad
Assignee: Gautam Borad
 Fix For: 2.1.2


Handle help text description for Ranger LDAP / AD properties in Ambari.



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

[jira] [Commented] (AMBARI-12968) Hosts page 'clear filters' link does not work


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

Hudson commented on AMBARI-12968:
-

SUCCESS: Integrated in Ambari-branch-2.1 #496 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/496/])
AMBARI-12968. Hosts page 'clear filters' link does not work  (rzang) 
(rzang: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=8c254337b84f80e74c7a543f82cd72f5109a5b65)
* ambari-web/app/views/main/host.js


> Hosts page 'clear filters' link does not work
> -
>
> Key: AMBARI-12968
> URL: https://issues.apache.org/jira/browse/AMBARI-12968
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Richard Zang
>Assignee: Richard Zang
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-12968.patch, AMBARI-12968_fix2.patch
>
>
> On hosts Page click Filter->'Alerts' or any other filter that does not have 
> any hosts displayed.
> Now click 'clear filters' link
> Filter is reset to 'All', but no hosts displayed.
> Also instead of clicking 'clear filters' you can select Filter->All



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

[jira] [Commented] (AMBARI-12968) Hosts page 'clear filters' link does not work


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

Hudson commented on AMBARI-12968:
-

SUCCESS: Integrated in Ambari-trunk-Commit #3404 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3404/])
AMBARI-12968. Hosts page 'clear filters' link does not work  (rzang) 
(rzang: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=27803b592a53253e6e65cea63d363c8eb4f018ef)
* ambari-web/app/views/main/host.js


> Hosts page 'clear filters' link does not work
> -
>
> Key: AMBARI-12968
> URL: https://issues.apache.org/jira/browse/AMBARI-12968
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Richard Zang
>Assignee: Richard Zang
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-12968.patch, AMBARI-12968_fix2.patch
>
>
> On hosts Page click Filter->'Alerts' or any other filter that does not have 
> any hosts displayed.
> Now click 'clear filters' link
> Filter is reset to 'All', but no hosts displayed.
> Also instead of clicking 'clear filters' you can select Filter->All



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

[jira] [Commented] (AMBARI-13032) Automatically Skip Failed Tasks Of Slaves During Upgrade


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

Hudson commented on AMBARI-13032:
-

FAILURE: Integrated in Ambari-branch-2.1 #495 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/495/])
AMBARI-13032 - Automatically Skip Failed Tasks Of Slaves During Upgrade (part2) 
(jonathanhurley) (jhurley: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=9f3951a85493785f4aafe5c5b0cd318cb3aaf9a1)
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UpgradeResourceProviderTest.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/RequestResourceProviderTest.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UpgradeResourceProviderHDP22Test.java


> Automatically Skip Failed Tasks Of Slaves During Upgrade
> 
>
> Key: AMBARI-13032
> URL: https://issues.apache.org/jira/browse/AMBARI-13032
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13032.patch
>
>
> During an upgrade, if any slave component experiences a failure during its 
> restart state then there should be a way for the rest of the upgrade group to 
> automatically continue despite the failure. This will prevent the need of 
> administrators to babysit the upgrade process, especially in cases of larger 
> clusters.
> During the creation of the upgrade, an optional parameter should be supplied 
> to the REST endpoint to accomplish this.
> {code:title=POST api/v1/clusters/c1/upgrades}
> {
>   "Upgrade": {
> "repository_version": "2.3.0.0-2545",
> "skip_failures": true
>   }
> }
> {code}
> The various skippable parts of the upgrade can be broken out into distinct 
> request parameters:
> - {{skip_failures}} (skips all component failures)
> - {{skip_service_check_failures}} (skips all service check failures)
> If an upgrade begins without the skip option specified, it can later be added:
> {code:title=PUT api/v1/clusters/c1/upgrades/1}
> {
>   "Upgrade": {
> "skip_failures": true
>   }
> }
> {code}



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

[jira] [Commented] (AMBARI-13034) If for some reason, structured-out-status.json is empty then ambari-server will fail to report any status


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

Hadoop QA commented on AMBARI-13034:


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

This message is automatically generated.

> If for some reason, structured-out-status.json is empty then ambari-server 
> will fail to report any status
> -
>
> Key: AMBARI-13034
> URL: https://issues.apache.org/jira/browse/AMBARI-13034
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: 2.0.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: AMBARI-13034.patch
>
>
> If the file - /var/lib/ambari-agent/data/structured-out-status.json is empty 
> then agent fails to recover any status details. The reason is that the 
> execute() implementation tries to load the empty file and fails as it expects 
> a well formed json.



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

[jira] [Commented] (AMBARI-13037) AMS - stack advisor should recommend topology smarts alongwith optimistic settings


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

Hadoop QA commented on AMBARI-13037:


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

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

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

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

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

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

  
org.apache.ambari.server.controller.internal.RequestResourceProviderTest

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

This message is automatically generated.

> AMS - stack advisor should recommend topology smarts alongwith optimistic 
> settings
> --
>
> Key: AMBARI-13037
> URL: https://issues.apache.org/jira/browse/AMBARI-13037
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, ambari-server
>Affects Versions: 2.0.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13037_1.patch
>
>
> Goals:
> Metrics Collector is placed on a less busy master
> AMS HBase root dir is set to a separate mount if available, WARN user if the 
> default mount point say "/" is selected when some other partition is 
> available.
> Set hbase.tmpdir to separate mount or "/" (different from rootdir) if such an 
> option is available.
> Fine tune memory settings for clusters under 100 nodes but that have resource 
> avaialble, we see that sometimes 50 node settings are too conservative for a 
> 40 node cluster but they are fine for a 10 node.
> Tune the metrics collection frequency (This is experimental item, I am not 
> sure this will help in reducing load)



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

[jira] [Commented] (AMBARI-13032) Automatically Skip Failed Tasks Of Slaves During Upgrade


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

Hudson commented on AMBARI-13032:
-

FAILURE: Integrated in Ambari-trunk-Commit #3403 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3403/])
AMBARI-13032 - Automatically Skip Failed Tasks Of Slaves During Upgrade (part2) 
(jonathanhurley) (jhurley: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=dca7e5d03e78b34fc2a9718182127494e772e48b)
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/RequestResourceProviderTest.java


> Automatically Skip Failed Tasks Of Slaves During Upgrade
> 
>
> Key: AMBARI-13032
> URL: https://issues.apache.org/jira/browse/AMBARI-13032
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13032.patch
>
>
> During an upgrade, if any slave component experiences a failure during its 
> restart state then there should be a way for the rest of the upgrade group to 
> automatically continue despite the failure. This will prevent the need of 
> administrators to babysit the upgrade process, especially in cases of larger 
> clusters.
> During the creation of the upgrade, an optional parameter should be supplied 
> to the REST endpoint to accomplish this.
> {code:title=POST api/v1/clusters/c1/upgrades}
> {
>   "Upgrade": {
> "repository_version": "2.3.0.0-2545",
> "skip_failures": true
>   }
> }
> {code}
> The various skippable parts of the upgrade can be broken out into distinct 
> request parameters:
> - {{skip_failures}} (skips all component failures)
> - {{skip_service_check_failures}} (skips all service check failures)
> If an upgrade begins without the skip option specified, it can later be added:
> {code:title=PUT api/v1/clusters/c1/upgrades/1}
> {
>   "Upgrade": {
> "skip_failures": true
>   }
> }
> {code}



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

Review Request 38196: Optimize precision table Region split policy for AMS

2015-09-08 Thread Sid Wagle


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38196/
---

Review request for Ambari, Dmytro Sen, Mahadev Konar, Myroslav Papirkovskyy, 
and Sumit Mohanty.


Bugs: AMBARI-13039
https://issues.apache.org/jira/browse/AMBARI-13039


Repository: ambari


Description
---

- In light of AMBARI-12983, performance would be seen if the precision table 
can fully utilize the allocated memstore heap.
- With the single table getting most of the high volume reads and all of the 
high volume writes it is important to define a policy for splitting the Region 
in order to optimize performance of the scans.


Diffs
-

  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java
 1bd20a3 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricConfiguration.java
 d70d77d 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-site.xml
 fa30e19 
  
ambari-server/src/main/resources/stacks/HDP/2.0.6/services/AMBARI_METRICS/service-metrics/AMBARI_METRICS.txt
 PRE-CREATION 
  
ambari-server/src/main/resources/stacks/HDP/2.0.6/services/AMBARI_METRICS/service-metrics/FLUME.txt
 PRE-CREATION 
  
ambari-server/src/main/resources/stacks/HDP/2.0.6/services/AMBARI_METRICS/service-metrics/HBASE.txt
 PRE-CREATION 
  
ambari-server/src/main/resources/stacks/HDP/2.0.6/services/AMBARI_METRICS/service-metrics/HDFS.txt
 PRE-CREATION 
  
ambari-server/src/main/resources/stacks/HDP/2.0.6/services/AMBARI_METRICS/service-metrics/HOST.txt
 PRE-CREATION 
  
ambari-server/src/main/resources/stacks/HDP/2.0.6/services/AMBARI_METRICS/service-metrics/KAFKA.txt
 PRE-CREATION 
  
ambari-server/src/main/resources/stacks/HDP/2.0.6/services/AMBARI_METRICS/service-metrics/STORM.txt
 PRE-CREATION 
  
ambari-server/src/main/resources/stacks/HDP/2.0.6/services/AMBARI_METRICS/service-metrics/YARN.txt
 PRE-CREATION 
  
ambari-server/src/main/resources/stacks/HDP/2.0.6/services/AMBARI_METRICS/split_points.py
 PRE-CREATION 

Diff: https://reviews.apache.org/r/38196/diff/


Testing
---

Unit test pass.
Manual testing in progress.


Thanks,

Sid Wagle

Re: Review Request 38194: Hosts page 'clear filters' link does not work

2015-09-08 Thread Jaimin Jetly


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38194/#review98133
---

Ship it!


Ship It!

- Jaimin Jetly


On Sept. 9, 2015, 1 a.m., Richard Zang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38194/
> ---
> 
> (Updated Sept. 9, 2015, 1 a.m.)
> 
> 
> Review request for Ambari, Jaimin Jetly and Yusaku Sako.
> 
> 
> Bugs: AMBARI-12968
> https://issues.apache.org/jira/browse/AMBARI-12968
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Add addtional fix for category filter.
> Select "All" category is defined as a 'healthStatus' filter with empty value. 
> Handle this condition separately.
> 
> 
> Diffs
> -
> 
>   ambari-web/app/views/main/host.js 7ff4c69 
> 
> Diff: https://reviews.apache.org/r/38194/diff/
> 
> 
> Testing
> ---
> 
> Manually tested on live cluster.
> All unit tests passed.
>   6503 tests complete (9 seconds)
>   95 tests pending
> 
> 
> Thanks,
> 
> Richard Zang
> 
>

[jira] [Updated] (AMBARI-12968) Hosts page 'clear filters' link does not work

2015-09-08 Thread Richard Zang (JIRA)


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

Richard Zang updated AMBARI-12968:
--
Attachment: AMBARI-12968_fix2.patch

> Hosts page 'clear filters' link does not work
> -
>
> Key: AMBARI-12968
> URL: https://issues.apache.org/jira/browse/AMBARI-12968
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Richard Zang
>Assignee: Richard Zang
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-12968.patch, AMBARI-12968_fix2.patch
>
>
> On hosts Page click Filter->'Alerts' or any other filter that does not have 
> any hosts displayed.
> Now click 'clear filters' link
> Filter is reset to 'All', but no hosts displayed.
> Also instead of clicking 'clear filters' you can select Filter->All



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

[jira] [Reopened] (AMBARI-12968) Hosts page 'clear filters' link does not work

2015-09-08 Thread Richard Zang (JIRA)


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

Richard Zang reopened AMBARI-12968:
---

> Hosts page 'clear filters' link does not work
> -
>
> Key: AMBARI-12968
> URL: https://issues.apache.org/jira/browse/AMBARI-12968
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Richard Zang
>Assignee: Richard Zang
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-12968.patch, AMBARI-12968_fix2.patch
>
>
> On hosts Page click Filter->'Alerts' or any other filter that does not have 
> any hosts displayed.
> Now click 'clear filters' link
> Filter is reset to 'All', but no hosts displayed.
> Also instead of clicking 'clear filters' you can select Filter->All



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

Review Request 38194: Hosts page 'clear filters' link does not work

2015-09-08 Thread Richard Zang


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38194/
---

Review request for Ambari, Jaimin Jetly and Yusaku Sako.


Bugs: AMBARI-12968
https://issues.apache.org/jira/browse/AMBARI-12968


Repository: ambari


Description
---

Add addtional fix for category filter.
Select "All" category is defined as a 'healthStatus' filter with empty value. 
Handle this condition separately.


Diffs
-

  ambari-web/app/views/main/host.js 7ff4c69 

Diff: https://reviews.apache.org/r/38194/diff/


Testing
---

Manually tested on live cluster.
All unit tests passed.
  6503 tests complete (9 seconds)
  95 tests pending


Thanks,

Richard Zang

[jira] [Created] (AMBARI-13039) Optimize precision table Region split policy for AMS

2015-09-08 Thread Siddharth Wagle (JIRA)

Siddharth Wagle created AMBARI-13039:


 Summary: Optimize precision table Region split policy for AMS
 Key: AMBARI-13039
 URL: https://issues.apache.org/jira/browse/AMBARI-13039
 Project: Ambari
  Issue Type: Task
  Components: ambari-metrics
Affects Versions: 2.1.2
Reporter: Siddharth Wagle
Assignee: Siddharth Wagle
Priority: Critical
 Fix For: 2.1.2


- In light of AMBARI-12983, performance would be seen if the precision table 
can fully utilize the allocated memstore heap.
- With the single table getting most of the high volume reads and all of the 
high volume writes it is important to define a policy for splitting the Region 
in order to optimize performance of the scans.




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

[jira] [Commented] (AMBARI-12738) In Pig view, File does not exist: /user/${username}/pig/jobs/job_id/stdout and stderr

2015-09-08 Thread Q Huang (JIRA)


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

Q Huang commented on AMBARI-12738:
--

We ran into the same problem in HDP pig view. 

> In Pig view,  File does not exist: /user/${username}/pig/jobs/job_id/stdout 
> and stderr
> --
>
> Key: AMBARI-12738
> URL: https://issues.apache.org/jira/browse/AMBARI-12738
> Project: Ambari
>  Issue Type: Bug
>  Components: contrib
>Affects Versions: 2.1.0
>Reporter: li xiang
>Priority: Critical
>
> using HDP 2.3
> 1. Login ambari using admin/admin 
> 2. Follow 
> http://docs.hortonworks.com/HDPDocuments/Ambari-2.1.0.0/bk_ambari_views_guide/content/ch_using_pig_view.html
>  to config and create a Pig view. Accept all default settings
> 3. On HDFS, create /user/admin/pig/scripts (the folder to save the scripts on 
> HDFS) and set the permission as 777 
> 4. on HDFS, create /user/admin/pig/jobs (the folder to save job logs and etc) 
> and set the permission as 777
> 5. Create a new script called pig1.scirpt, add any content, such as A = load 
> '/tmp/passwd' using PigStorage(':');
> 6. Run the syntax check or execute, get the following exception



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

Re: Python client abandoned?

2015-09-08 Thread Greg Hill

Alejandro,

I meant to contribute it back in whole as a replacement.  I have no
interest in porting the functionality to the current client; the main
reason I wrote my own is that the current one is difficult to work on and
requires way too much boilerplate code to add anything.  I first proposed
to refactor the existing client to make it easier to use and work on, but
my proposal was rejected, and nobody has touched the client since (my
patches were the last to be applied, based on the git history).

As for Ambari features that my client supports that the official one
doesn't:

1. Users
2. Groups
3. Privileges
4. Stacks
5. Views
6. Add hosts to hostgroup
7. Ambari Alerts
8. Ambari Metrics
9. Execute custom action
10. DECOMMISSION component
(probably a lot more that I'm forgetting)

It's also been updated to work with changes in Ambari 2.0 and 2.1, and has
a mechanism to mark what version a feature was added to prevent people
from using it against an older cluster.  It's also been released on Pypi
so it's easier for Python programmers to install and use.

Greg

On 9/8/15, 12:39 PM, "Alejandro Fernandez" 
wrote:

>That's great Greg.
>
>I took a quick peek and it has,
>PyLint checks
>Command to query Alerts
>Command to restart a component on a host, and service-level restart
>
>Can you come up with a high-level list of some of the features you want to
>contribute back?
>
>Thanks,
>Alejandro
>
>On 9/8/15, 7:44 AM, "Greg Hill"  wrote:
>
>>The Python client hasn't been updated in a year or so:
>>
>>https://github.com/apache/ambari/tree/trunk/ambari-client/python-client/s
>>r
>>c/main/python
>>
>>I tried to work with Subin to modernize it previously but things didn't
>>work out so I ended up making my own client:
>>
>>https://github.com/jimbobhickville/python-ambariclient
>>
>>We've been using it here at Rackspace for nearly a year now and it's been
>>pretty great.  Easy to use, easy to work on, and much more full-featured
>>than the existing client.  I'd love to contribute it back as the official
>>Python client, since the existing one is broken and missing a lot of
>>features (for example, it can't create clusters since Ambari 1.7, and has
>>no support for newer features like metrics).
>>
>>I know there is some work to be done to make it integrate better with the
>>existing Ambari tooling, but I wanted to reach out and see if such an
>>addition would be welcome.  If it is, we can sort out what all
>>requirements need to be met before it can be integrated back in.
>>
>>Greg
>>
>>
>>
>

[jira] [Commented] (AMBARI-13032) Automatically Skip Failed Tasks Of Slaves During Upgrade


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

Hudson commented on AMBARI-13032:
-

FAILURE: Integrated in Ambari-branch-2.1 #494 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/494/])
AMBARI-13032 - Automatically Skip Failed Tasks Of Slaves During Upgrade 
(jonathanhurley) (jhurley: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=2b665fdd4652bf144151fff4240bb28b02735b2e)
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
* 
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog212Test.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
* ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeContext.java
* 
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommand.java
* ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
* 
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandStatusSummaryDTO.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/HostStackVersionResourceProvider.java
* ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql
* 
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionScheduler.java
* ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java
* 
ambari-server/src/test/java/org/apache/ambari/server/serveraction/ServerActionExecutorTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
* 
ambari-server/src/test/java/org/apache/ambari/server/stageplanner/TestStagePlanner.java
* ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql
* 
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactory.java
* 
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleStatus.java
* ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql
* 
ambari-server/src/main/java/org/apache/ambari/server/topology/LogicalRequest.java
* 
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/ExecutionCommandWrapperTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariActionExecutionHelper.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/ActionExecutionContext.java
* ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql
* 
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandDAO.java
* 
ambari-server/src/test/java/org/apache/ambari/server/agent/TestHeartbeatHandler.java
* 
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactoryImpl.java
* ambari-server/src/main/java/org/apache/ambari/server/actionmanager/Stage.java
* 
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionManager.java
* 
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostRoleCommandEntity.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog212.java
* 
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/StageTest.java
* ambari-server/src/main/java/org/apache/ambari/server/utils/StageUtils.java
* 
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestStage.java
* 
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/ActionDBAccessorImpl.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/CalculatedStatusTest.java
* 
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionDBAccessorImpl.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/StageResourceProviderTest.java


> Automatically Skip Failed Tasks Of Slaves During Upgrade
> 
>
> Key: AMBARI-13032
> URL: https://issues.apache.org/jira/browse/AMBARI-13032
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13032.patch
>
>
> During an upgrade, if any slave component experiences a failure during its 
> restart state then there should be a way for the rest of the upgrade group to 
> automatically continue despite the failure. This will prevent the need of 
> administr

[jira] [Commented] (AMBARI-13032) Automatically Skip Failed Tasks Of Slaves During Upgrade


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

Hudson commented on AMBARI-13032:
-

FAILURE: Integrated in Ambari-trunk-Commit #3402 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3402/])
AMBARI-13032 - Automatically Skip Failed Tasks Of Slaves During Upgrade 
(jonathanhurley) (jhurley: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=8def5a407399c56c51ad4edca1a59377dc3c3ba6)
* 
ambari-server/src/test/java/org/apache/ambari/server/agent/TestHeartbeatHandler.java
* 
ambari-server/src/main/java/org/apache/ambari/server/topology/LogicalRequest.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/StageResourceProviderTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/HostStackVersionResourceProvider.java
* 
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/StageTest.java
* ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql
* ambari-server/src/main/java/org/apache/ambari/server/actionmanager/Stage.java
* 
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandDAO.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariActionExecutionHelper.java
* 
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/ActionDBAccessorImpl.java
* 
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionManager.java
* 
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactory.java
* 
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/ExecutionCommandWrapperTest.java
* 
ambari-server/src/test/java/org/apache/ambari/server/serveraction/ServerActionExecutorTest.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
* 
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandStatusSummaryDTO.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
* ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql
* 
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionScheduler.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
* 
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostRoleCommandEntity.java
* ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/ActionExecutionContext.java
* 
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog212.java
* 
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommand.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java
* ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql
* ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeContext.java
* ambari-server/src/main/java/org/apache/ambari/server/utils/StageUtils.java
* ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql
* 
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog212Test.java
* 
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactoryImpl.java
* 
ambari-server/src/test/java/org/apache/ambari/server/stageplanner/TestStagePlanner.java
* 
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleStatus.java
* 
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestStage.java
* 
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionDBAccessorImpl.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/CalculatedStatusTest.java
* ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql


> Automatically Skip Failed Tasks Of Slaves During Upgrade
> 
>
> Key: AMBARI-13032
> URL: https://issues.apache.org/jira/browse/AMBARI-13032
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13032.patch
>
>
> During an upgrade, if any slave component experiences a failure during its 
> restart state then there should be a way for the rest of the upgrade group to 
> automatically continue despite the failure. This will prevent the need of 
> adm

Re: Review Request 38182: Blueprint: API call to create cluster instance with blueprint fails when blueprint_name is not correct

2015-09-08 Thread Robert Nettleton


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38182/#review98064
---


I think we should consider a different approach to fix this issue.  My concerns 
are listed in the issue below.  

Thanks.


ambari-server/src/main/java/org/apache/ambari/server/api/services/persistence/PersistenceManagerImpl.java
 (line 73)


I'm a little concerned with this modification, as it will affect basically 
every resource type managed by Ambari.  

We probably should not make a change that could potentially affect API 
compatibility in the "v1" version of the API.  

While it would be a less-generic solution, I think I would recommend 
building a solution that is specific to the Blueprints issue, to reduce the 
risk of creating an API incompatibility for all resource types managed by 
ambari-server. 

John Speidel should probably comment on this further, since he was the lead 
on the API services in Ambari.


- Robert Nettleton


On Sept. 8, 2015, 3:57 p.m., Sandor Magyari wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38182/
> ---
> 
> (Updated Sept. 8, 2015, 3:57 p.m.)
> 
> 
> Review request for Ambari, John Speidel, Robert Nettleton, and Jeff Sposetti.
> 
> 
> Bugs: AMBARI-12989
> https://issues.apache.org/jira/browse/AMBARI-12989
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> PROBLEM
> 
> When creating any resource like blueprint, cluster etc, you can specify the 
> resource name both in the Url and Json payload as well. For example in case 
> of a blueprint creation: api/v1/blueprints/sandboxURL Json: 
> {"Blueprints":{"blueprint_name":"sandboxJson"}}. In this case the blueprint 
> will be created as sandboxJson so the name specified in Json will override 
> the name specifie din the Url. The behavoir is true for cluster creation and 
> any other resource where you can specify name in Json as well. This could be 
> a bit misleading so the API may return an error in case of resource names 
> don't match.
> 
> SOLUTION
> 
> The solution would be to throw an error message (Error code 400) in case 
> resource names are different. To achive this only for cluster creation would 
> be quite complicated since resource handling is quite generic and in 
> ClusterResourceProvider - which contains resource specific handling - only 
> the request body is available, the url is not. The actual behaviour is that 
> in PersistenceManagerImpl.create method the resource name (eg. 
> blueprint_name) is inserted from the url in Json in case it's missing. So if 
> resource name is specified in url than that will be used, if is specified 
> both url and Json then latter will be used. Because of this behaviour I think 
> we should hadnle this problem in PersistenceManagerImpl.create as you can see 
> in attached patch. This will affect of course the creation of all resources. 
> All unittests were
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/services/persistence/PersistenceManagerImpl.java
>  4db5611 
>   
> ambari-server/src/test/java/org/apache/ambari/server/api/services/PersistenceManagerImplTest.java
>  9ff1506 
> 
> Diff: https://reviews.apache.org/r/38182/diff/
> 
> 
> Testing
> ---
> 
> Manually tested blueprint and cluster creation, then cluster creation with 
> blueprint. All unitests passed, it seems it doesn't affect normal 
> functionality.
> 
> 
> Thanks,
> 
> Sandor Magyari
> 
>

[jira] [Commented] (AMBARI-13035) BE / Hosts Page Performance: "alerts_summary" takes too long to load


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

Hadoop QA commented on AMBARI-13035:


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

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

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

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

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

{color:green}+1 core tests{color}.  The patch passed unit tests in 
ambari-server.

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

This message is automatically generated.

> BE / Hosts Page Performance: "alerts_summary" takes too long to load
> 
>
> Key: AMBARI-13035
> URL: https://issues.apache.org/jira/browse/AMBARI-13035
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.1
>Reporter: Srimanth Gunturi
>Assignee: Srimanth Gunturi
> Fix For: 2.1.2
>
> Attachments: AMBARI-13035.patch
>
>
> http://c6401.ambari.apache.org:8080/api/v1/clusters/MuonBlue/hosts?fields=alerts_summary
> is taking almost 10s every time to load.
> Here is a typical request for hosts update
> {code}
> http://c6401.ambari.apache.org:8080/api/v1/clusters/MuonBlue/hosts?fields=Hosts/rack_info,Hosts/host_name,
> Hosts/maintenance_state,Hosts/public_host_name,Hosts/cpu_count,Hosts/ph_cpu_count,alerts_summary,Hosts/host_status,
> Hosts/last_heartbeat_time,Hosts/ip,host_components/HostRoles/state,host_components/HostRoles/maintenance_state,
> host_components/HostRoles/stale_configs,host_components/HostRoles/service_name,host_components/HostRoles/desired_admin_state,
> Hosts/total_mem,stack_versions/HostStackVersions,stack_versions/repository_versions/RepositoryVersions/repository_version,
> stack_versions/repository_versions/RepositoryVersions/id,
> stack_versions/repository_versions/RepositoryVersions/display_name&minimal_response=true&page_size=100&from=0&sortBy=Hosts/host_name.asc&_=1439416717498
> {code}
> By removing "alert_summary", it will take only 1/10 of the time to load.



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

Re: Review Request 38181: Automatically Skip Failed Tasks Of Slaves During Upgrade



> On Sept. 8, 2015, 4:35 p.m., Alejandro Fernandez wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/controller/ActionExecutionContext.java,
> >  line 43
> > 
> >
> > Should this default to true?

Thanks for the review.

I don't think so. Retry-ability was only added for upgrades. If you take a look 
at the patch, most of the method signatures that accepted that boolean were 
always given false (except for upgrades). So, making it default to false keeps 
it consistent with what most of the methods were.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38181/#review98061
---


On Sept. 8, 2015, 12:41 p.m., Jonathan Hurley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38181/
> ---
> 
> (Updated Sept. 8, 2015, 12:41 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Nate Cole.
> 
> 
> Bugs: AMBARI-13032
> https://issues.apache.org/jira/browse/AMBARI-13032
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> During an upgrade, if any slave component experiences a failure during its 
> restart state then there should be a way for the rest of the upgrade group to 
> automatically continue despite the failure. This will prevent the need of 
> administrators to babysit the upgrade process, especially in cases of larger 
> clusters.
> 
> During the creation of the upgrade, an optional parameter should be supplied 
> to the REST endpoint to accomplish this.
> 
> {code:title=POST api/v1/clusters/c1/upgrades}
> {
>   "Upgrade": {
> "repository_version": "2.3.0.0-2545",
> "skip_failures": true
>   }
> }
> {code}
> 
> The various skippable parts of the upgrade can be broken out into distinct 
> request parameters:
> - {{skip_failures}} (skips all component failures)
> - {{skip_service_check_failures}} (skips all service check failures)
> 
> If an upgrade begins without the skip option specified, it can later be added:
> 
> {code:title=PUT api/v1/clusters/c1/upgrades/1}
> {
>   "Upgrade": {
> "skip_failures": true
>   }
> }
> {code}
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/ActionDBAccessorImpl.java
>  62f8be9 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommand.java
>  9d44454 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactory.java
>  84c2d2a 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactoryImpl.java
>  0440f87 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleStatus.java
>  39cbabc 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/Stage.java 
> fcd0324 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/ActionExecutionContext.java
>  ee5febe 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariActionExecutionHelper.java
>  a422b2d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
>  43bdbfe 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
>  a90cb31 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
>  6f407c9 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java
>  a942c93 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/HostStackVersionResourceProvider.java
>  1051056 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
>  770cc04 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandDAO.java
>  9c91656 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandStatusSummaryDTO.java
>  54ade92 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostRoleCommandEntity.java
>  d99da6d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeContext.java
>  86dbccd 
>   
> ambari-server/src/main/java/org/apache/ambari/server/topology/LogicalRequest.java
>  b7f95cf 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog212.java
>  02df181 
>   ambari-server/src/main/java/org/apache/ambari/server/utils/StageUtils.java 
> 3da0fe2 
>   ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql 265e42e 
>   ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql 0053837 
>   ambari-server/src/main/resources/Ambari-DDL-Postg

Re: Review Request 38181: Automatically Skip Failed Tasks Of Slaves During Upgrade


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38181/#review98061
---

Ship it!



ambari-server/src/main/java/org/apache/ambari/server/controller/ActionExecutionContext.java
 (line 43)


Should this default to true?


- Alejandro Fernandez


On Sept. 8, 2015, 4:41 p.m., Jonathan Hurley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38181/
> ---
> 
> (Updated Sept. 8, 2015, 4:41 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Nate Cole.
> 
> 
> Bugs: AMBARI-13032
> https://issues.apache.org/jira/browse/AMBARI-13032
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> During an upgrade, if any slave component experiences a failure during its 
> restart state then there should be a way for the rest of the upgrade group to 
> automatically continue despite the failure. This will prevent the need of 
> administrators to babysit the upgrade process, especially in cases of larger 
> clusters.
> 
> During the creation of the upgrade, an optional parameter should be supplied 
> to the REST endpoint to accomplish this.
> 
> {code:title=POST api/v1/clusters/c1/upgrades}
> {
>   "Upgrade": {
> "repository_version": "2.3.0.0-2545",
> "skip_failures": true
>   }
> }
> {code}
> 
> The various skippable parts of the upgrade can be broken out into distinct 
> request parameters:
> - {{skip_failures}} (skips all component failures)
> - {{skip_service_check_failures}} (skips all service check failures)
> 
> If an upgrade begins without the skip option specified, it can later be added:
> 
> {code:title=PUT api/v1/clusters/c1/upgrades/1}
> {
>   "Upgrade": {
> "skip_failures": true
>   }
> }
> {code}
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/ActionDBAccessorImpl.java
>  62f8be9 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommand.java
>  9d44454 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactory.java
>  84c2d2a 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactoryImpl.java
>  0440f87 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleStatus.java
>  39cbabc 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/Stage.java 
> fcd0324 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/ActionExecutionContext.java
>  ee5febe 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariActionExecutionHelper.java
>  a422b2d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
>  43bdbfe 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
>  a90cb31 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
>  6f407c9 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java
>  a942c93 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/HostStackVersionResourceProvider.java
>  1051056 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
>  770cc04 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandDAO.java
>  9c91656 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandStatusSummaryDTO.java
>  54ade92 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostRoleCommandEntity.java
>  d99da6d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeContext.java
>  86dbccd 
>   
> ambari-server/src/main/java/org/apache/ambari/server/topology/LogicalRequest.java
>  b7f95cf 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog212.java
>  02df181 
>   ambari-server/src/main/java/org/apache/ambari/server/utils/StageUtils.java 
> 3da0fe2 
>   ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql 265e42e 
>   ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql 0053837 
>   ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql 30b669d 
>   ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql 
> 4f7569c 
>   ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql 97b5e11 
>   ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 81d0e6f 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
> 04befaf 
>   
> ambari-server/src/test/java

Ambari views and Knox

2015-09-08 Thread Eric Yang

Hi all,

Ambari web offers Ambari views feature to proxy third party UI in 2014,
then Knox was introduced as a security REST gateway.  It seems there are
some duplicate functions of reverse proxy from two different view points.
Ambari was original design to be a multi-cluster deployment system for
system administrators.  The exposure of Ambari Server is mostly to
operational folks who may want to restrict Ambari Server access to private
management network only.  Can Ambari views be exposed to outside and not
expose Ambari-Server UI?

Is Knox designed as a gateway in front of Ambari views?  If Knox is a
gateway in front of Ambari views, shouldn't reverse proxy feature being
inside of Knox project instead of Ambari views?

If Knox is behind Ambari views, what mechanism will be to secure Ambari
views?

Take Hue as a possible candidate for assimilation.  For someone to
integrate Hue into the stack of software.

Option 1: Someone needs to modify the login mechanism for Hue to accept
Knox authentication, and define Ambari views quick link to Hue UI, if Knox
is in front of Ambari views.  Ambari views is the landing page for all end
user facing UI.  The only issue is, can Ambari views and Ambari Server
deploy to two different networks?  Hue is a data scientist UI that end
users facing network.  Ambari Web is ops oriented, and deployed on ops only
network.

Option 2: It is also possible only reverse proxy via Knox only, which makes
Ambari views proxy irrelevant to end user facing UI.

Option 3: If Ambari views are in front of Knox, Hue authentication remains
standalone, and Ambari views will do the proxy.  This may breach security
model offer by Knox.

It would be great to discuss this to ensure there is no duplication between
projects.  Thanks

regards,
Eric

[jira] [Updated] (AMBARI-13032) Automatically Skip Failed Tasks Of Slaves During Upgrade

2015-09-08 Thread Jonathan Hurley (JIRA)


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

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

> Automatically Skip Failed Tasks Of Slaves During Upgrade
> 
>
> Key: AMBARI-13032
> URL: https://issues.apache.org/jira/browse/AMBARI-13032
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13032.patch
>
>
> During an upgrade, if any slave component experiences a failure during its 
> restart state then there should be a way for the rest of the upgrade group to 
> automatically continue despite the failure. This will prevent the need of 
> administrators to babysit the upgrade process, especially in cases of larger 
> clusters.
> During the creation of the upgrade, an optional parameter should be supplied 
> to the REST endpoint to accomplish this.
> {code:title=POST api/v1/clusters/c1/upgrades}
> {
>   "Upgrade": {
> "repository_version": "2.3.0.0-2545",
> "skip_failures": true
>   }
> }
> {code}
> The various skippable parts of the upgrade can be broken out into distinct 
> request parameters:
> - {{skip_failures}} (skips all component failures)
> - {{skip_service_check_failures}} (skips all service check failures)
> If an upgrade begins without the skip option specified, it can later be added:
> {code:title=PUT api/v1/clusters/c1/upgrades/1}
> {
>   "Upgrade": {
> "skip_failures": true
>   }
> }
> {code}



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

[jira] [Commented] (AMBARI-11740) Duplicated property dfs.heartbeat.interval on hdfs-site


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

Hudson commented on AMBARI-11740:
-

SUCCESS: Integrated in Ambari-branch-2.1 #493 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/493/])
AMBARI-11740. Duplicated property dfs.heartbeat.interval on hdfs-site (Juanjo 
Marron via alejandro) (afernandez: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=b018ed4478ff3d9c64e5bba9885122c33e156b2e)
* 
ambari-server/src/main/resources/stacks/HDP/2.0.6.GlusterFS/services/HDFS/configuration/hdfs-site.xml
* 
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-site.xml
* 
ambari-server/src/main/resources/stacks/BIGTOP/0.8/services/HDFS/configuration/hdfs-site.xml


> Duplicated property dfs.heartbeat.interval on hdfs-site
> ---
>
> Key: AMBARI-11740
> URL: https://issues.apache.org/jira/browse/AMBARI-11740
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Juanjo Marron
>Assignee: Juanjo Marron
>Priority: Minor
> Fix For: 2.2.0, 2.1.2
>
> Attachments: AMBARI-11740.patch
>
>
> The property dfs.heartbeat.interval is duplicated on the HDFS configuration 
> file 
> /ambari/ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-site.xml



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

Re: Review Request 38183: Installing falcon with blueprint, oozie extensions are missing, hence causing misconfigured installations that are using blueprint.

2015-09-08 Thread Robert Nettleton


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38183/#review98052
---


This patch looks fine to me.  Overall, the general approach taken here looks 
correct.

The way that "excluded-config" has been interpreted by the UI and by Blueprints 
has historically been slightly different.  Because of this, I think it may make 
sense to do a little more functional testing.

I'd request that the author of this patch run some additional cluster 
deployments to test this change out, and please use the other services (in 
addition to Falcon) as part of these tests.  It looks like the following 
components use this excluded-config construct:  AMBARI METRICS, FALCON, 
MAPREDUCE, YARN, HBASE.  I think this extra testing would be worthwhile, given 
that this modifies how the Blueprints processor treats excluded config.

- Robert Nettleton


On Sept. 8, 2015, 4:05 p.m., Sandor Magyari wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38183/
> ---
> 
> (Updated Sept. 8, 2015, 4:05 p.m.)
> 
> 
> Review request for Ambari and Robert Nettleton.
> 
> 
> Bugs: AMBARI-13017
> https://issues.apache.org/jira/browse/AMBARI-13017
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> PROBLEM
> 
> Installing falcon with blueprint, oozie extensions are missing, hence causing 
> misconfigured installations that are using blueprint.
> 
> SOLUTION
> 
> This issue seems to be related not only for case of falcon but for every 
> service which has a configuration file for another service.
> In case of falcon there is an oozie-site.xml (this contains oozie extensions) 
> in configuration of falcon service, which is marked as exclued-config-type in 
> service metainfo.xml. The same is true for AMBARI_METRICS which includes the 
> storm-site.xml. In case of a bluprint install these are excluded from 
> properties, which is fine because you can not add a config-type twice. The 
> solution would to add these properties from excluded-config-type at update 
> phase of properties in 
> BluprintConfigurationProcessor.doUpdateForClusterCreate.
> We can apply this only specifically for FALCON but I dont see yet any 
> drawbacks of applying it for each service with excluded property.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
>  892cf32 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
>  a881472 
> 
> Diff: https://reviews.apache.org/r/38183/diff/
> 
> 
> Testing
> ---
> 
> Manually tested, creating new cluster with blueprint, unitests passed, 
> created a new testcase.
> 
> 
> Thanks,
> 
> Sandor Magyari
> 
>

[jira] [Commented] (AMBARI-11740) Duplicated property dfs.heartbeat.interval on hdfs-site


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

Hudson commented on AMBARI-11740:
-

SUCCESS: Integrated in Ambari-trunk-Commit #3401 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3401/])
AMBARI-11740. Duplicated property dfs.heartbeat.interval on hdfs-site (Juanjo 
Marron via alejandro) (afernandez: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=577ae0ced464fcdc06fda5592f589f73afd481ed)
* 
ambari-server/src/main/resources/stacks/HDP/2.0.6.GlusterFS/services/HDFS/configuration/hdfs-site.xml
* 
ambari-server/src/main/resources/stacks/BIGTOP/0.8/services/HDFS/configuration/hdfs-site.xml
* 
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-site.xml


> Duplicated property dfs.heartbeat.interval on hdfs-site
> ---
>
> Key: AMBARI-11740
> URL: https://issues.apache.org/jira/browse/AMBARI-11740
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Juanjo Marron
>Assignee: Juanjo Marron
>Priority: Minor
> Fix For: 2.2.0, 2.1.2
>
> Attachments: AMBARI-11740.patch
>
>
> The property dfs.heartbeat.interval is duplicated on the HDFS configuration 
> file 
> /ambari/ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-site.xml



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

[jira] [Created] (AMBARI-13038) Define ephemeral port range for Ambari agents

Olivér Szabó created AMBARI-13038:
-

 Summary: Define ephemeral port range for Ambari agents
 Key: AMBARI-13038
 URL: https://issues.apache.org/jira/browse/AMBARI-13038
 Project: Ambari
  Issue Type: Bug
  Components: ambari-agent
Affects Versions: 2.1.0
 Environment: All
Reporter: Olivér Szabó
Assignee: Olivér Szabó


Problem: 
When Ambari agent starts,it tries to use an ephemeral port that is already in 
use by another component.

Steps to Reproduce:
1. Install a cluster with Ambari
2. Restart the Ambari agent until it takes a port in use by another service

Solution:
Range of ephemeral ports used by Ambari should be narrowed. (configurable)



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

[jira] [Updated] (AMBARI-13035) BE / Hosts Page Performance: "alerts_summary" takes too long to load

2015-09-08 Thread Srimanth Gunturi (JIRA)


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

Srimanth Gunturi updated AMBARI-13035:
--
Attachment: AMBARI-13035.patch

{{AlertSummaryPropertyProvider}} when populating 'alerts_summary'  currently 
makes 1 sql query per host. So 1000 sql queries are made when populating this 
query on a 1000 node cluster, which grows linearly based on the number of hosts.

One of the optimizations is to get alert_summaries for all hosts in 1 SQL call 
so that the SQL call count is constant. 

There are bigger changes that will be tracked in a different JIRA, but this 
JIRA will be used for optimizing the SQL call count.

> BE / Hosts Page Performance: "alerts_summary" takes too long to load
> 
>
> Key: AMBARI-13035
> URL: https://issues.apache.org/jira/browse/AMBARI-13035
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.1
>Reporter: Srimanth Gunturi
>Assignee: Srimanth Gunturi
> Fix For: 2.1.2
>
> Attachments: AMBARI-13035.patch
>
>
> http://c6401.ambari.apache.org:8080/api/v1/clusters/MuonBlue/hosts?fields=alerts_summary
> is taking almost 10s every time to load.
> Here is a typical request for hosts update
> {code}
> http://c6401.ambari.apache.org:8080/api/v1/clusters/MuonBlue/hosts?fields=Hosts/rack_info,Hosts/host_name,
> Hosts/maintenance_state,Hosts/public_host_name,Hosts/cpu_count,Hosts/ph_cpu_count,alerts_summary,Hosts/host_status,
> Hosts/last_heartbeat_time,Hosts/ip,host_components/HostRoles/state,host_components/HostRoles/maintenance_state,
> host_components/HostRoles/stale_configs,host_components/HostRoles/service_name,host_components/HostRoles/desired_admin_state,
> Hosts/total_mem,stack_versions/HostStackVersions,stack_versions/repository_versions/RepositoryVersions/repository_version,
> stack_versions/repository_versions/RepositoryVersions/id,
> stack_versions/repository_versions/RepositoryVersions/display_name&minimal_response=true&page_size=100&from=0&sortBy=Hosts/host_name.asc&_=1439416717498
> {code}
> By removing "alert_summary", it will take only 1/10 of the time to load.



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

[jira] [Updated] (AMBARI-13036) Enable JPA statement caching (internal/external)


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

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

> Enable JPA statement caching (internal/external)
> 
>
> Key: AMBARI-13036
> URL: https://issues.apache.org/jira/browse/AMBARI-13036
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: 2.1.1
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Attachments: AMBARI-13036.patch
>
>




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

[jira] [Updated] (AMBARI-13036) Enable JPA statement caching (internal/external)


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

Olivér Szabó updated AMBARI-13036:
--
Attachment: (was: AMBARI-13036.patch)

> Enable JPA statement caching (internal/external)
> 
>
> Key: AMBARI-13036
> URL: https://issues.apache.org/jira/browse/AMBARI-13036
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: 2.1.1
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
>




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

[jira] [Updated] (AMBARI-13037) AMS - stack advisor should recommend topology smarts alongwith optimistic settings

2015-09-08 Thread Dmytro Sen (JIRA)


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

Dmytro Sen updated AMBARI-13037:

Attachment: AMBARI-13037_1.patch

> AMS - stack advisor should recommend topology smarts alongwith optimistic 
> settings
> --
>
> Key: AMBARI-13037
> URL: https://issues.apache.org/jira/browse/AMBARI-13037
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, ambari-server
>Affects Versions: 2.0.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13037_1.patch
>
>
> Goals:
> Metrics Collector is placed on a less busy master
> AMS HBase root dir is set to a separate mount if available, WARN user if the 
> default mount point say "/" is selected when some other partition is 
> available.
> Set hbase.tmpdir to separate mount or "/" (different from rootdir) if such an 
> option is available.
> Fine tune memory settings for clusters under 100 nodes but that have resource 
> avaialble, we see that sometimes 50 node settings are too conservative for a 
> 40 node cluster but they are fine for a 10 node.
> Tune the metrics collection frequency (This is experimental item, I am not 
> sure this will help in reducing load)



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

[jira] [Updated] (AMBARI-13036) Enable JPA statement caching (internal/external)


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

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

> Enable JPA statement caching (internal/external)
> 
>
> Key: AMBARI-13036
> URL: https://issues.apache.org/jira/browse/AMBARI-13036
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: 2.1.1
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Attachments: AMBARI-13036.patch
>
>




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

Review Request 38186: AMS - stack advisor should recommend topology smarts alongwith optimistic settings

2015-09-08 Thread Dmytro Sen


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38186/
---

Review request for Ambari, Myroslav Papirkovskyy and Sid Wagle.


Bugs: AMBARI-13037
https://issues.apache.org/jira/browse/AMBARI-13037


Repository: ambari


Description
---

Goals:
Metrics Collector is placed on a less busy master
AMS HBase root dir is set to a separate mount if available, WARN user if the 
default mount point say "/" is selected when some other partition is available.
Set hbase.tmpdir to separate mount or "/" (different from rootdir) if such an 
option is available.
Fine tune memory settings for clusters under 100 nodes but that have resource 
avaialble, we see that sometimes 50 node settings are too conservative for a 40 
node cluster but they are fine for a 10 node.
Tune the metrics collection frequency (This is experimental item, I am not sure 
this will help in reducing load)


Diffs
-

  
ambari-metrics/ambari-metrics-timelineservice/src/main/resources/scripts/ams_query.py
 7fea3df 
  
ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/package/scripts/params.py
 45fa367 
  
ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/package/templates/hadoop-metrics2-accumulo.properties.j2
 4ab6635 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-hbase-site.xml
 b2cfccd 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-site.xml
 fa30e19 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/params.py
 245802c 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/templates/hadoop-metrics2-hbase.properties.j2
 3f404eb 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/templates/metric_monitor.ini.j2
 2ee21d4 
  
ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/package/scripts/params.py
 dce73b3 
  
ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/package/templates/flume-metrics2.properties.j2
 bc18043 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/params_linux.py
 2633640 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/templates/hadoop-metrics2-hbase.properties-GANGLIA-MASTER.j2
 78ee5fa 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/templates/hadoop-metrics2-hbase.properties-GANGLIA-RS.j2
 fc46aa4 
  
ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/params_linux.py
 3bec0d8 
  
ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/templates/storm-metrics2.properties.j2
 4553224 
  
ambari-server/src/main/resources/stacks/HDP/2.0.6/hooks/before-START/scripts/params.py
 0fc87a5 
  
ambari-server/src/main/resources/stacks/HDP/2.0.6/hooks/before-START/templates/hadoop-metrics2.properties.j2
 f75947e 
  ambari-server/src/main/resources/stacks/HDP/2.0.6/services/stack_advisor.py 
3d535de 
  ambari-server/src/main/resources/stacks/HDP/2.1/services/stack_advisor.py 
1607287 
  ambari-server/src/main/resources/stacks/HDP/2.2/services/stack_advisor.py 
9a7d7a0 
  ambari-server/src/test/python/stacks/2.0.6/common/test_stack_advisor.py 
75e59f9 
  ambari-server/src/test/python/stacks/2.2/common/test_stack_advisor.py d0260f9 

Diff: https://reviews.apache.org/r/38186/diff/


Testing
---

--
Ran 261 tests in 9.103s

OK
--
Total run:814
Total errors:0
Total failures:0
OK


Thanks,

Dmytro Sen

[jira] [Created] (AMBARI-13037) AMS - stack advisor should recommend topology smarts alongwith optimistic settings

2015-09-08 Thread Dmytro Sen (JIRA)

Dmytro Sen created AMBARI-13037:
---

 Summary: AMS - stack advisor should recommend topology smarts 
alongwith optimistic settings
 Key: AMBARI-13037
 URL: https://issues.apache.org/jira/browse/AMBARI-13037
 Project: Ambari
  Issue Type: Bug
  Components: ambari-metrics, ambari-server
Affects Versions: 2.0.0
Reporter: Dmytro Sen
Assignee: Dmytro Sen
Priority: Critical
 Fix For: 2.1.2


Goals:
Metrics Collector is placed on a less busy master
AMS HBase root dir is set to a separate mount if available, WARN user if the 
default mount point say "/" is selected when some other partition is available.
Set hbase.tmpdir to separate mount or "/" (different from rootdir) if such an 
option is available.
Fine tune memory settings for clusters under 100 nodes but that have resource 
avaialble, we see that sometimes 50 node settings are too conservative for a 40 
node cluster but they are fine for a 10 node.
Tune the metrics collection frequency (This is experimental item, I am not sure 
this will help in reducing load)



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

[jira] [Created] (AMBARI-13036) Enable JPA statement caching (internal/external)

Olivér Szabó created AMBARI-13036:
-

 Summary: Enable JPA statement caching (internal/external)
 Key: AMBARI-13036
 URL: https://issues.apache.org/jira/browse/AMBARI-13036
 Project: Ambari
  Issue Type: Improvement
  Components: ambari-server
Affects Versions: 2.1.1
Reporter: Olivér Szabó
Assignee: Olivér Szabó






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

Re: Review Request 38127: RU: Installing version stuck on host


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38127/#review98042
---

Ship it!


Ship It!

- Nate Cole


On Sept. 4, 2015, 9:51 a.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38127/
> ---
> 
> (Updated Sept. 4, 2015, 9:51 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, and Nate 
> Cole.
> 
> 
> Bugs: AMBARI-13014
> https://issues.apache.org/jira/browse/AMBARI-13014
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> ambari-server-2.1.0-1462.x86_64
> Attempting to register and install a repo version was stuck on one of the 
> hosts.
> The cluster version was stuck in INSTALLING, and so was one of the hosts; the 
> other hosts were fine
> Log from host were it failed
> 
> ```
> 2015-09-03 12:21:59,319 - Attempting to determine actual version with build 
> number.
> 2015-09-03 12:21:59,319 - Old versions: ['2.3.2.0-2598', '2.3.2.0-2716']
> 2015-09-03 12:21:59,369 - New versions: ['2.3.2.0-2598', '2.3.2.0-2716']
> 2015-09-03 12:21:59,369 - Deltas: set([])
> 2015-09-03 12:21:59,370 - Cannot determine a new actual version installed by 
> using the delta method.
> 2015-09-03 12:21:59,370 - Found actual version 2.3.2.0-210 by parsing file 
> /var/lib/ambari-agent/data/repo_version_history.csv
> ```
> 
> In fact, the bug (at least at branch-2.1.0) is that we can not overwrite old 
> build version of the same stack. For example, 
> 
> ```
> >>> import repo_version_history
> >>> import logging
> >>> Logger = logging.getLogger()
> >>> global Logger
> >>> repo_version_history.write_actual_version_to_history_file('2.3.2.0', 
> >>> '2.3.2.0-210')
> False
> >>> repo_version_history.write_actual_version_to_history_file('2.3.2.0', 
> >>> '2.3.2.0-2716')
> False
> ```
> 
> produces
> ```
> cat /tmp/repo_version_history.csv
> 2.3.2.0,2.3.2.0-210
> ```
> 
> Originally check for existing repo version was added to avoid appending the 
> same repo version multiple times to file. But later we decided to consider 
> only "normalized" repo version (without build number) and introduced this bug
> 
> So the bug STR is to:
> - successfully install first repo version on host
> - install second repo version (of the same stack) on host, and it should fail 
> during installation.
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/repo_version_history.py
>  f8ea7c9 
>   ambari-server/src/test/python/custom_actions/TestRepoVersionHistory.py 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/38127/diff/
> 
> 
> Testing
> ---
> 
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] Ambari Views .. SUCCESS [2.138s]
> [INFO] Ambari Metrics Common . SUCCESS [1.105s]
> [INFO] Ambari Server . SUCCESS [51.800s]
> [INFO] Ambari Agent .. SUCCESS [7.897s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 1:03.538s
> [INFO] Finished at: Fri Sep 04 16:43:50 EEST 2015
> [INFO] Final Memory: 76M/1012M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Re: Review Request 38127: RU: Installing version stuck on host



> On Sept. 8, 2015, 1:10 p.m., Nate Cole wrote:
> > ambari-common/src/main/python/resource_management/libraries/functions/repo_version_history.py,
> >  lines 89-92
> > 
> >
> > Just checks the key being passed in and writes ONLY the single version 
> > passed in.  Multiple installed versions would each need their own line, 
> > right?  So you would have to write the one that's not there _and_ all the 
> > existing ones?
> 
> Jonathan Hurley wrote:
> This re-opens the file for append. Wouldn't that add the new line?
> 
> Alejandro Fernandez wrote:
> I verified this, it will append a new line.

Ah, ok - skipped right over that "a" there.  Ship it!


- Nate


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38127/#review98021
---


On Sept. 4, 2015, 9:51 a.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38127/
> ---
> 
> (Updated Sept. 4, 2015, 9:51 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, and Nate 
> Cole.
> 
> 
> Bugs: AMBARI-13014
> https://issues.apache.org/jira/browse/AMBARI-13014
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> ambari-server-2.1.0-1462.x86_64
> Attempting to register and install a repo version was stuck on one of the 
> hosts.
> The cluster version was stuck in INSTALLING, and so was one of the hosts; the 
> other hosts were fine
> Log from host were it failed
> 
> ```
> 2015-09-03 12:21:59,319 - Attempting to determine actual version with build 
> number.
> 2015-09-03 12:21:59,319 - Old versions: ['2.3.2.0-2598', '2.3.2.0-2716']
> 2015-09-03 12:21:59,369 - New versions: ['2.3.2.0-2598', '2.3.2.0-2716']
> 2015-09-03 12:21:59,369 - Deltas: set([])
> 2015-09-03 12:21:59,370 - Cannot determine a new actual version installed by 
> using the delta method.
> 2015-09-03 12:21:59,370 - Found actual version 2.3.2.0-210 by parsing file 
> /var/lib/ambari-agent/data/repo_version_history.csv
> ```
> 
> In fact, the bug (at least at branch-2.1.0) is that we can not overwrite old 
> build version of the same stack. For example, 
> 
> ```
> >>> import repo_version_history
> >>> import logging
> >>> Logger = logging.getLogger()
> >>> global Logger
> >>> repo_version_history.write_actual_version_to_history_file('2.3.2.0', 
> >>> '2.3.2.0-210')
> False
> >>> repo_version_history.write_actual_version_to_history_file('2.3.2.0', 
> >>> '2.3.2.0-2716')
> False
> ```
> 
> produces
> ```
> cat /tmp/repo_version_history.csv
> 2.3.2.0,2.3.2.0-210
> ```
> 
> Originally check for existing repo version was added to avoid appending the 
> same repo version multiple times to file. But later we decided to consider 
> only "normalized" repo version (without build number) and introduced this bug
> 
> So the bug STR is to:
> - successfully install first repo version on host
> - install second repo version (of the same stack) on host, and it should fail 
> during installation.
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/repo_version_history.py
>  f8ea7c9 
>   ambari-server/src/test/python/custom_actions/TestRepoVersionHistory.py 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/38127/diff/
> 
> 
> Testing
> ---
> 
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] Ambari Views .. SUCCESS [2.138s]
> [INFO] Ambari Metrics Common . SUCCESS [1.105s]
> [INFO] Ambari Server . SUCCESS [51.800s]
> [INFO] Ambari Agent .. SUCCESS [7.897s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 1:03.538s
> [INFO] Finished at: Fri Sep 04 16:43:50 EEST 2015
> [INFO] Final Memory: 76M/1012M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Re: Review Request 38127: RU: Installing version stuck on host



> On Sept. 8, 2015, 5:10 p.m., Nate Cole wrote:
> > ambari-common/src/main/python/resource_management/libraries/functions/repo_version_history.py,
> >  lines 89-92
> > 
> >
> > Just checks the key being passed in and writes ONLY the single version 
> > passed in.  Multiple installed versions would each need their own line, 
> > right?  So you would have to write the one that's not there _and_ all the 
> > existing ones?
> 
> Jonathan Hurley wrote:
> This re-opens the file for append. Wouldn't that add the new line?

I verified this, it will append a new line.


- Alejandro


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38127/#review98021
---


On Sept. 4, 2015, 1:51 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38127/
> ---
> 
> (Updated Sept. 4, 2015, 1:51 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, and Nate 
> Cole.
> 
> 
> Bugs: AMBARI-13014
> https://issues.apache.org/jira/browse/AMBARI-13014
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> ambari-server-2.1.0-1462.x86_64
> Attempting to register and install a repo version was stuck on one of the 
> hosts.
> The cluster version was stuck in INSTALLING, and so was one of the hosts; the 
> other hosts were fine
> Log from host were it failed
> 
> ```
> 2015-09-03 12:21:59,319 - Attempting to determine actual version with build 
> number.
> 2015-09-03 12:21:59,319 - Old versions: ['2.3.2.0-2598', '2.3.2.0-2716']
> 2015-09-03 12:21:59,369 - New versions: ['2.3.2.0-2598', '2.3.2.0-2716']
> 2015-09-03 12:21:59,369 - Deltas: set([])
> 2015-09-03 12:21:59,370 - Cannot determine a new actual version installed by 
> using the delta method.
> 2015-09-03 12:21:59,370 - Found actual version 2.3.2.0-210 by parsing file 
> /var/lib/ambari-agent/data/repo_version_history.csv
> ```
> 
> In fact, the bug (at least at branch-2.1.0) is that we can not overwrite old 
> build version of the same stack. For example, 
> 
> ```
> >>> import repo_version_history
> >>> import logging
> >>> Logger = logging.getLogger()
> >>> global Logger
> >>> repo_version_history.write_actual_version_to_history_file('2.3.2.0', 
> >>> '2.3.2.0-210')
> False
> >>> repo_version_history.write_actual_version_to_history_file('2.3.2.0', 
> >>> '2.3.2.0-2716')
> False
> ```
> 
> produces
> ```
> cat /tmp/repo_version_history.csv
> 2.3.2.0,2.3.2.0-210
> ```
> 
> Originally check for existing repo version was added to avoid appending the 
> same repo version multiple times to file. But later we decided to consider 
> only "normalized" repo version (without build number) and introduced this bug
> 
> So the bug STR is to:
> - successfully install first repo version on host
> - install second repo version (of the same stack) on host, and it should fail 
> during installation.
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/repo_version_history.py
>  f8ea7c9 
>   ambari-server/src/test/python/custom_actions/TestRepoVersionHistory.py 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/38127/diff/
> 
> 
> Testing
> ---
> 
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] Ambari Views .. SUCCESS [2.138s]
> [INFO] Ambari Metrics Common . SUCCESS [1.105s]
> [INFO] Ambari Server . SUCCESS [51.800s]
> [INFO] Ambari Agent .. SUCCESS [7.897s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 1:03.538s
> [INFO] Finished at: Fri Sep 04 16:43:50 EEST 2015
> [INFO] Final Memory: 76M/1012M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

[jira] [Created] (AMBARI-13035) BE / Hosts Page Performance: "alerts_summary" takes too long to load

2015-09-08 Thread Srimanth Gunturi (JIRA)

Srimanth Gunturi created AMBARI-13035:
-

 Summary: BE / Hosts Page Performance: "alerts_summary" takes too 
long to load
 Key: AMBARI-13035
 URL: https://issues.apache.org/jira/browse/AMBARI-13035
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.1.1
Reporter: Srimanth Gunturi
Assignee: Srimanth Gunturi
 Fix For: 2.1.2


http://c6401.ambari.apache.org:8080/api/v1/clusters/MuonBlue/hosts?fields=alerts_summary
is taking almost 10s every time to load.

Here is a typical request for hosts update
{code}
http://c6401.ambari.apache.org:8080/api/v1/clusters/MuonBlue/hosts?fields=Hosts/rack_info,Hosts/host_name,
Hosts/maintenance_state,Hosts/public_host_name,Hosts/cpu_count,Hosts/ph_cpu_count,alerts_summary,Hosts/host_status,
Hosts/last_heartbeat_time,Hosts/ip,host_components/HostRoles/state,host_components/HostRoles/maintenance_state,
host_components/HostRoles/stale_configs,host_components/HostRoles/service_name,host_components/HostRoles/desired_admin_state,
Hosts/total_mem,stack_versions/HostStackVersions,stack_versions/repository_versions/RepositoryVersions/repository_version,
stack_versions/repository_versions/RepositoryVersions/id,
stack_versions/repository_versions/RepositoryVersions/display_name&minimal_response=true&page_size=100&from=0&sortBy=Hosts/host_name.asc&_=1439416717498
{code}
By removing "alert_summary", it will take only 1/10 of the time to load.



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

Re: Review Request 38127: RU: Installing version stuck on host


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38127/#review98036
---

Ship it!


I don't see any problems, but I'd want the issue opened by Nate to be double 
checked in case I'm not seeing the issue.

- Jonathan Hurley


On Sept. 4, 2015, 9:51 a.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38127/
> ---
> 
> (Updated Sept. 4, 2015, 9:51 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, and Nate 
> Cole.
> 
> 
> Bugs: AMBARI-13014
> https://issues.apache.org/jira/browse/AMBARI-13014
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> ambari-server-2.1.0-1462.x86_64
> Attempting to register and install a repo version was stuck on one of the 
> hosts.
> The cluster version was stuck in INSTALLING, and so was one of the hosts; the 
> other hosts were fine
> Log from host were it failed
> 
> ```
> 2015-09-03 12:21:59,319 - Attempting to determine actual version with build 
> number.
> 2015-09-03 12:21:59,319 - Old versions: ['2.3.2.0-2598', '2.3.2.0-2716']
> 2015-09-03 12:21:59,369 - New versions: ['2.3.2.0-2598', '2.3.2.0-2716']
> 2015-09-03 12:21:59,369 - Deltas: set([])
> 2015-09-03 12:21:59,370 - Cannot determine a new actual version installed by 
> using the delta method.
> 2015-09-03 12:21:59,370 - Found actual version 2.3.2.0-210 by parsing file 
> /var/lib/ambari-agent/data/repo_version_history.csv
> ```
> 
> In fact, the bug (at least at branch-2.1.0) is that we can not overwrite old 
> build version of the same stack. For example, 
> 
> ```
> >>> import repo_version_history
> >>> import logging
> >>> Logger = logging.getLogger()
> >>> global Logger
> >>> repo_version_history.write_actual_version_to_history_file('2.3.2.0', 
> >>> '2.3.2.0-210')
> False
> >>> repo_version_history.write_actual_version_to_history_file('2.3.2.0', 
> >>> '2.3.2.0-2716')
> False
> ```
> 
> produces
> ```
> cat /tmp/repo_version_history.csv
> 2.3.2.0,2.3.2.0-210
> ```
> 
> Originally check for existing repo version was added to avoid appending the 
> same repo version multiple times to file. But later we decided to consider 
> only "normalized" repo version (without build number) and introduced this bug
> 
> So the bug STR is to:
> - successfully install first repo version on host
> - install second repo version (of the same stack) on host, and it should fail 
> during installation.
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/repo_version_history.py
>  f8ea7c9 
>   ambari-server/src/test/python/custom_actions/TestRepoVersionHistory.py 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/38127/diff/
> 
> 
> Testing
> ---
> 
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] Ambari Views .. SUCCESS [2.138s]
> [INFO] Ambari Metrics Common . SUCCESS [1.105s]
> [INFO] Ambari Server . SUCCESS [51.800s]
> [INFO] Ambari Agent .. SUCCESS [7.897s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 1:03.538s
> [INFO] Finished at: Fri Sep 04 16:43:50 EEST 2015
> [INFO] Final Memory: 76M/1012M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Re: Review Request 38127: RU: Installing version stuck on host



> On Sept. 8, 2015, 1:10 p.m., Nate Cole wrote:
> > ambari-common/src/main/python/resource_management/libraries/functions/repo_version_history.py,
> >  lines 89-92
> > 
> >
> > Just checks the key being passed in and writes ONLY the single version 
> > passed in.  Multiple installed versions would each need their own line, 
> > right?  So you would have to write the one that's not there _and_ all the 
> > existing ones?

This re-opens the file for append. Wouldn't that add the new line?


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38127/#review98021
---


On Sept. 4, 2015, 9:51 a.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38127/
> ---
> 
> (Updated Sept. 4, 2015, 9:51 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, and Nate 
> Cole.
> 
> 
> Bugs: AMBARI-13014
> https://issues.apache.org/jira/browse/AMBARI-13014
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> ambari-server-2.1.0-1462.x86_64
> Attempting to register and install a repo version was stuck on one of the 
> hosts.
> The cluster version was stuck in INSTALLING, and so was one of the hosts; the 
> other hosts were fine
> Log from host were it failed
> 
> ```
> 2015-09-03 12:21:59,319 - Attempting to determine actual version with build 
> number.
> 2015-09-03 12:21:59,319 - Old versions: ['2.3.2.0-2598', '2.3.2.0-2716']
> 2015-09-03 12:21:59,369 - New versions: ['2.3.2.0-2598', '2.3.2.0-2716']
> 2015-09-03 12:21:59,369 - Deltas: set([])
> 2015-09-03 12:21:59,370 - Cannot determine a new actual version installed by 
> using the delta method.
> 2015-09-03 12:21:59,370 - Found actual version 2.3.2.0-210 by parsing file 
> /var/lib/ambari-agent/data/repo_version_history.csv
> ```
> 
> In fact, the bug (at least at branch-2.1.0) is that we can not overwrite old 
> build version of the same stack. For example, 
> 
> ```
> >>> import repo_version_history
> >>> import logging
> >>> Logger = logging.getLogger()
> >>> global Logger
> >>> repo_version_history.write_actual_version_to_history_file('2.3.2.0', 
> >>> '2.3.2.0-210')
> False
> >>> repo_version_history.write_actual_version_to_history_file('2.3.2.0', 
> >>> '2.3.2.0-2716')
> False
> ```
> 
> produces
> ```
> cat /tmp/repo_version_history.csv
> 2.3.2.0,2.3.2.0-210
> ```
> 
> Originally check for existing repo version was added to avoid appending the 
> same repo version multiple times to file. But later we decided to consider 
> only "normalized" repo version (without build number) and introduced this bug
> 
> So the bug STR is to:
> - successfully install first repo version on host
> - install second repo version (of the same stack) on host, and it should fail 
> during installation.
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/repo_version_history.py
>  f8ea7c9 
>   ambari-server/src/test/python/custom_actions/TestRepoVersionHistory.py 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/38127/diff/
> 
> 
> Testing
> ---
> 
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] Ambari Views .. SUCCESS [2.138s]
> [INFO] Ambari Metrics Common . SUCCESS [1.105s]
> [INFO] Ambari Server . SUCCESS [51.800s]
> [INFO] Ambari Agent .. SUCCESS [7.897s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 1:03.538s
> [INFO] Finished at: Fri Sep 04 16:43:50 EEST 2015
> [INFO] Final Memory: 76M/1012M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Re: Review Request 38127: RU: Installing version stuck on host


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38127/#review98031
---

Ship it!


Ship It!

- Alejandro Fernandez


On Sept. 4, 2015, 1:51 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38127/
> ---
> 
> (Updated Sept. 4, 2015, 1:51 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, and Nate 
> Cole.
> 
> 
> Bugs: AMBARI-13014
> https://issues.apache.org/jira/browse/AMBARI-13014
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> ambari-server-2.1.0-1462.x86_64
> Attempting to register and install a repo version was stuck on one of the 
> hosts.
> The cluster version was stuck in INSTALLING, and so was one of the hosts; the 
> other hosts were fine
> Log from host were it failed
> 
> ```
> 2015-09-03 12:21:59,319 - Attempting to determine actual version with build 
> number.
> 2015-09-03 12:21:59,319 - Old versions: ['2.3.2.0-2598', '2.3.2.0-2716']
> 2015-09-03 12:21:59,369 - New versions: ['2.3.2.0-2598', '2.3.2.0-2716']
> 2015-09-03 12:21:59,369 - Deltas: set([])
> 2015-09-03 12:21:59,370 - Cannot determine a new actual version installed by 
> using the delta method.
> 2015-09-03 12:21:59,370 - Found actual version 2.3.2.0-210 by parsing file 
> /var/lib/ambari-agent/data/repo_version_history.csv
> ```
> 
> In fact, the bug (at least at branch-2.1.0) is that we can not overwrite old 
> build version of the same stack. For example, 
> 
> ```
> >>> import repo_version_history
> >>> import logging
> >>> Logger = logging.getLogger()
> >>> global Logger
> >>> repo_version_history.write_actual_version_to_history_file('2.3.2.0', 
> >>> '2.3.2.0-210')
> False
> >>> repo_version_history.write_actual_version_to_history_file('2.3.2.0', 
> >>> '2.3.2.0-2716')
> False
> ```
> 
> produces
> ```
> cat /tmp/repo_version_history.csv
> 2.3.2.0,2.3.2.0-210
> ```
> 
> Originally check for existing repo version was added to avoid appending the 
> same repo version multiple times to file. But later we decided to consider 
> only "normalized" repo version (without build number) and introduced this bug
> 
> So the bug STR is to:
> - successfully install first repo version on host
> - install second repo version (of the same stack) on host, and it should fail 
> during installation.
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/repo_version_history.py
>  f8ea7c9 
>   ambari-server/src/test/python/custom_actions/TestRepoVersionHistory.py 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/38127/diff/
> 
> 
> Testing
> ---
> 
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] Ambari Views .. SUCCESS [2.138s]
> [INFO] Ambari Metrics Common . SUCCESS [1.105s]
> [INFO] Ambari Server . SUCCESS [51.800s]
> [INFO] Ambari Agent .. SUCCESS [7.897s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 1:03.538s
> [INFO] Finished at: Fri Sep 04 16:43:50 EEST 2015
> [INFO] Final Memory: 76M/1012M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Re: Review Request 37682: [Preview] Stop-and-Start Upgrade: Move Configs out of Upgrade Pack


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/37682/#review98029
---

Ship it!



ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
 (line 624)


This function is allowed to return null, let's make sure the value isn't 
null before we pass it to another function.



ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
 (line 651)


FYI, for STW Upgrade, we'll need to apply configs after all services have 
been stopped, and before calling hdp-select set all.

For now, I'm ok with just getting this patch in.



ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeHelper.java 
(line 231)


Why was  removed?



ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeHelper.java 
(line 282)


Why was  removed?



ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/ConfigureTask.java
 (line 151)


Let's use isEmpty or isBlank instead.



ambari-server/src/test/java/org/apache/ambari/server/state/UpgradeHelperTest.java
 (line 375)


For the sake of getting this in, let's ignore unit tests for now.


- Alejandro Fernandez


On Sept. 8, 2015, 3:37 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/37682/
> ---
> 
> (Updated Sept. 8, 2015, 3:37 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Dmytro Grinenko, Jonathan 
> Hurley, and Nate Cole.
> 
> 
> Bugs: AMBARI-12700
> https://issues.apache.org/jira/browse/AMBARI-12700
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> The configs need to move out of the Upgrade Packs and into their own file.
> This will make it easier to maintain, and clearer since there will not be any 
> dups.
> 
> Since it is going to be a massive change, it would be great to get early 
> feedback. Code is not complete (still full of TODOs and does not even build)
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/services/AmbariMetaInfo.java
>  4afa9b0 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
>  dddec73 
>   
> ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/ConfigureAction.java
>  c717582 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/ModuleFileUnmarshaller.java
>  aa8e17b 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/StackDefinitionDirectory.java
>  8f81b5a 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/StackDirectory.java
>  db947ca 
>   ambari-server/src/main/java/org/apache/ambari/server/stack/StackModule.java 
> 4b88aff 
>   ambari-server/src/main/java/org/apache/ambari/server/state/StackInfo.java 
> 87301e5 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeHelper.java 
> ecefe6e 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/stack/ConfigUpgradePatch.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/ConfigureTask.java
>  8361ea6 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/ConfigureTask.java
>  8361ea6 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/Grouping.java
>  9d89b7a 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/StageWrapperBuilder.java
>  c9c6b8c 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
> 7c1a1f9 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
> 7c1a1f9 
>   
> ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/ConfigureActionTest.java
>  e702e0a 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/UpgradeHelperTest.java
>  2eee2df 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/stack/UpgradePackTest.java
>  fc731d9 
> 
> Diff: https://reviews.apache.org/r/37682/diff/
> 
> 
> Testing
> ---
> 
> just published preview of changes
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

[jira] [Commented] (AMBARI-13033) Add Service Wizard:After populating KMS properties, Ranger tab shows up as missing 2 properties


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

Hudson commented on AMBARI-13033:
-

FAILURE: Integrated in Ambari-trunk-Commit #3400 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3400/])
AMBARI-13033. Add Service Wizard:After populating KMS properties, Ranger tab 
shows up as missing 2 properties (alexantonenko) (hiveww: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=00eb338f62ad6ce45a2739483656228107581538)
* ambari-web/app/models/configs/objects/service_config.js
* ambari-web/app/views/common/controls_view.js


> Add Service Wizard:After populating KMS properties, Ranger tab shows up as 
> missing 2 properties
> ---
>
> Key: AMBARI-13033
> URL: https://issues.apache.org/jira/browse/AMBARI-13033
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13033.patch
>
>
> At the add service wizard- Adding KMS, after populating the fields for KMS, 
> Next button was not enabled and you can see that Ranger tab has an indicator 
> '2' which says its expecting some properties to be populated. Upon clicking 
> the Ranger tab, thats gone too and Next button is enabled by then. As per the 
> analysis this seems to be FE issue. please help take a look



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

[jira] [Commented] (AMBARI-13033) Add Service Wizard:After populating KMS properties, Ranger tab shows up as missing 2 properties


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

Hudson commented on AMBARI-13033:
-

SUCCESS: Integrated in Ambari-branch-2.1 #492 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/492/])
AMBARI-13033. Add Service Wizard:After populating KMS properties, Ranger tab 
shows up as missing 2 properties (alexantonenko) (hiveww: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=8f45138195f5aec58ef974e1d253fa9e414d1c3d)
* ambari-web/app/views/common/controls_view.js
* ambari-web/app/models/configs/objects/service_config.js


> Add Service Wizard:After populating KMS properties, Ranger tab shows up as 
> missing 2 properties
> ---
>
> Key: AMBARI-13033
> URL: https://issues.apache.org/jira/browse/AMBARI-13033
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13033.patch
>
>
> At the add service wizard- Adding KMS, after populating the fields for KMS, 
> Next button was not enabled and you can see that Ranger tab has an indicator 
> '2' which says its expecting some properties to be populated. Upon clicking 
> the Ranger tab, thats gone too and Next button is enabled by then. As per the 
> analysis this seems to be FE issue. please help take a look



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

Re: Python client abandoned?

That's great Greg.

I took a quick peek and it has,
PyLint checks
Command to query Alerts
Command to restart a component on a host, and service-level restart

Can you come up with a high-level list of some of the features you want to
contribute back?

Thanks,
Alejandro

On 9/8/15, 7:44 AM, "Greg Hill"  wrote:

>The Python client hasn't been updated in a year or so:
>
>https://github.com/apache/ambari/tree/trunk/ambari-client/python-client/sr
>c/main/python
>
>I tried to work with Subin to modernize it previously but things didn't
>work out so I ended up making my own client:
>
>https://github.com/jimbobhickville/python-ambariclient
>
>We've been using it here at Rackspace for nearly a year now and it's been
>pretty great.  Easy to use, easy to work on, and much more full-featured
>than the existing client.  I'd love to contribute it back as the official
>Python client, since the existing one is broken and missing a lot of
>features (for example, it can't create clusters since Ambari 1.7, and has
>no support for newer features like metrics).
>
>I know there is some work to be done to make it integrate better with the
>existing Ambari tooling, but I wanted to reach out and see if such an
>addition would be welcome.  If it is, we can sort out what all
>requirements need to be met before it can be integrated back in.
>
>Greg
>
>
>

Re: v2 API?

Hi Greg,

Thanks for bringing up this initiative; this would be a good chance to
come up with a proposal on a google doc so others can comment, and link it
to a Jira.

-Alejandro


On 9/8/15, 10:16 AM, "Greg Hill"  wrote:

>Is there any work towards a v2 API yet?  I'd like to have some input on
>the design, if so.  I'd really like to see the configurations API cleaned
>up and made more consistent with the rest of the API, for example.  The
>way it works currently is a pain to handle in the client libraries
>because it breaks out of the normal patterns used by the rest of the API.
> Alternatively, we could just fix the v1 API, but I can't think of a way
>to handle it without breaking compatibility.
>
>If there isn't anything going on in this area, is it something the
>community is open to discussing?
>
>Greg

v2 API?

2015-09-08 Thread Greg Hill

Is there any work towards a v2 API yet?  I'd like to have some input on the 
design, if so.  I'd really like to see the configurations API cleaned up and 
made more consistent with the rest of the API, for example.  The way it works 
currently is a pain to handle in the client libraries because it breaks out of 
the normal patterns used by the rest of the API.  Alternatively, we could just 
fix the v1 API, but I can't think of a way to handle it without breaking 
compatibility.

If there isn't anything going on in this area, is it something the community is 
open to discussing?

Greg

Review Request 38184: If for some reason, structured-out-status.json is empty then ambari-server will fail to report any status

2015-09-08 Thread Vitalyi Brodetskyi


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38184/
---

Review request for Ambari, Andrew Onischuk and Sumit Mohanty.


Bugs: AMBARI-13034
https://issues.apache.org/jira/browse/AMBARI-13034


Repository: ambari


Description
---

If the file - /var/lib/ambari-agent/data/structured-out-status.json is empty 
then agent fails to recover any status details. The reason is that the 
execute() implementation tries to load the empty file and fails as it expects a 
well formed json.


Diffs
-

  ambari-agent/src/test/python/resource_management/TestScript.py fd31910 
  ambari-common/src/main/python/resource_management/libraries/script/script.py 
962b54c 

Diff: https://reviews.apache.org/r/38184/diff/


Testing
---

mvn clean test


Thanks,

Vitalyi Brodetskyi

[jira] [Created] (AMBARI-13034) If for some reason, structured-out-status.json is empty then ambari-server will fail to report any status

Vitaly Brodetskyi created AMBARI-13034:
--

 Summary: If for some reason, structured-out-status.json is empty 
then ambari-server will fail to report any status
 Key: AMBARI-13034
 URL: https://issues.apache.org/jira/browse/AMBARI-13034
 Project: Ambari
  Issue Type: Bug
  Components: ambari-agent
Affects Versions: 2.0.0
Reporter: Vitaly Brodetskyi
Assignee: Vitaly Brodetskyi
Priority: Critical
 Fix For: 2.2.0
 Attachments: AMBARI-13034.patch

If the file - /var/lib/ambari-agent/data/structured-out-status.json is empty 
then agent fails to recover any status details. The reason is that the 
execute() implementation tries to load the empty file and fails as it expects a 
well formed json.



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

[jira] [Updated] (AMBARI-13034) If for some reason, structured-out-status.json is empty then ambari-server will fail to report any status


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

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

> If for some reason, structured-out-status.json is empty then ambari-server 
> will fail to report any status
> -
>
> Key: AMBARI-13034
> URL: https://issues.apache.org/jira/browse/AMBARI-13034
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: 2.0.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: AMBARI-13034.patch
>
>
> If the file - /var/lib/ambari-agent/data/structured-out-status.json is empty 
> then agent fails to recover any status details. The reason is that the 
> execute() implementation tries to load the empty file and fails as it expects 
> a well formed json.



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

Re: Review Request 38127: RU: Installing version stuck on host


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38127/#review98021
---



ambari-common/src/main/python/resource_management/libraries/functions/repo_version_history.py
 (lines 89 - 92)


Just checks the key being passed in and writes ONLY the single version 
passed in.  Multiple installed versions would each need their own line, right?  
So you would have to write the one that's not there _and_ all the existing ones?


- Nate Cole


On Sept. 4, 2015, 9:51 a.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38127/
> ---
> 
> (Updated Sept. 4, 2015, 9:51 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, and Nate 
> Cole.
> 
> 
> Bugs: AMBARI-13014
> https://issues.apache.org/jira/browse/AMBARI-13014
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> ambari-server-2.1.0-1462.x86_64
> Attempting to register and install a repo version was stuck on one of the 
> hosts.
> The cluster version was stuck in INSTALLING, and so was one of the hosts; the 
> other hosts were fine
> Log from host were it failed
> 
> ```
> 2015-09-03 12:21:59,319 - Attempting to determine actual version with build 
> number.
> 2015-09-03 12:21:59,319 - Old versions: ['2.3.2.0-2598', '2.3.2.0-2716']
> 2015-09-03 12:21:59,369 - New versions: ['2.3.2.0-2598', '2.3.2.0-2716']
> 2015-09-03 12:21:59,369 - Deltas: set([])
> 2015-09-03 12:21:59,370 - Cannot determine a new actual version installed by 
> using the delta method.
> 2015-09-03 12:21:59,370 - Found actual version 2.3.2.0-210 by parsing file 
> /var/lib/ambari-agent/data/repo_version_history.csv
> ```
> 
> In fact, the bug (at least at branch-2.1.0) is that we can not overwrite old 
> build version of the same stack. For example, 
> 
> ```
> >>> import repo_version_history
> >>> import logging
> >>> Logger = logging.getLogger()
> >>> global Logger
> >>> repo_version_history.write_actual_version_to_history_file('2.3.2.0', 
> >>> '2.3.2.0-210')
> False
> >>> repo_version_history.write_actual_version_to_history_file('2.3.2.0', 
> >>> '2.3.2.0-2716')
> False
> ```
> 
> produces
> ```
> cat /tmp/repo_version_history.csv
> 2.3.2.0,2.3.2.0-210
> ```
> 
> Originally check for existing repo version was added to avoid appending the 
> same repo version multiple times to file. But later we decided to consider 
> only "normalized" repo version (without build number) and introduced this bug
> 
> So the bug STR is to:
> - successfully install first repo version on host
> - install second repo version (of the same stack) on host, and it should fail 
> during installation.
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/repo_version_history.py
>  f8ea7c9 
>   ambari-server/src/test/python/custom_actions/TestRepoVersionHistory.py 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/38127/diff/
> 
> 
> Testing
> ---
> 
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] Ambari Views .. SUCCESS [2.138s]
> [INFO] Ambari Metrics Common . SUCCESS [1.105s]
> [INFO] Ambari Server . SUCCESS [51.800s]
> [INFO] Ambari Agent .. SUCCESS [7.897s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 1:03.538s
> [INFO] Finished at: Fri Sep 04 16:43:50 EEST 2015
> [INFO] Final Memory: 76M/1012M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Re: Review Request 38181: Automatically Skip Failed Tasks Of Slaves During Upgrade


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38181/
---

(Updated Sept. 8, 2015, 12:41 p.m.)


Review request for Ambari, Alejandro Fernandez and Nate Cole.


Bugs: AMBARI-13032
https://issues.apache.org/jira/browse/AMBARI-13032


Repository: ambari


Description
---

During an upgrade, if any slave component experiences a failure during its 
restart state then there should be a way for the rest of the upgrade group to 
automatically continue despite the failure. This will prevent the need of 
administrators to babysit the upgrade process, especially in cases of larger 
clusters.

During the creation of the upgrade, an optional parameter should be supplied to 
the REST endpoint to accomplish this.

{code:title=POST api/v1/clusters/c1/upgrades}
{
  "Upgrade": {
"repository_version": "2.3.0.0-2545",
"skip_failures": true
  }
}
{code}

The various skippable parts of the upgrade can be broken out into distinct 
request parameters:
- {{skip_failures}} (skips all component failures)
- {{skip_service_check_failures}} (skips all service check failures)

If an upgrade begins without the skip option specified, it can later be added:

{code:title=PUT api/v1/clusters/c1/upgrades/1}
{
  "Upgrade": {
"skip_failures": true
  }
}
{code}


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/ActionDBAccessorImpl.java
 62f8be9 
  
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommand.java
 9d44454 
  
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactory.java
 84c2d2a 
  
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactoryImpl.java
 0440f87 
  
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleStatus.java
 39cbabc 
  ambari-server/src/main/java/org/apache/ambari/server/actionmanager/Stage.java 
fcd0324 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/ActionExecutionContext.java
 ee5febe 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariActionExecutionHelper.java
 a422b2d 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
 43bdbfe 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
 a90cb31 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
 6f407c9 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java
 a942c93 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/HostStackVersionResourceProvider.java
 1051056 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
 770cc04 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandDAO.java
 9c91656 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandStatusSummaryDTO.java
 54ade92 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostRoleCommandEntity.java
 d99da6d 
  
ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeContext.java 
86dbccd 
  
ambari-server/src/main/java/org/apache/ambari/server/topology/LogicalRequest.java
 b7f95cf 
  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog212.java
 02df181 
  ambari-server/src/main/java/org/apache/ambari/server/utils/StageUtils.java 
3da0fe2 
  ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql 265e42e 
  ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql 0053837 
  ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql 30b669d 
  ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql 
4f7569c 
  ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql 97b5e11 
  ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 81d0e6f 
  ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
04befaf 
  
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/ExecutionCommandWrapperTest.java
 8d21b80 
  
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/StageTest.java
 fa1e770 
  
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionDBAccessorImpl.java
 520be9f 
  
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionManager.java
 27f11f7 
  
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionScheduler.java
 cfbc38e 
  
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestStage.java
 13453df 
  
ambari-server/src/test/java/org/apache/ambari/server/agent/TestHeartbeatHandler.java
 4a4f8c9 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementC

[jira] [Updated] (AMBARI-13017) Installing falcon with blueprint, oozie extensions are missing, hence causing misconfigured installations that are using blueprint

2015-09-08 Thread Mahadev konar (JIRA)


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

Mahadev konar updated AMBARI-13017:
---
Assignee: Sandor Magyari

> Installing falcon with blueprint, oozie extensions are missing, hence causing 
> misconfigured installations that are using blueprint
> --
>
> Key: AMBARI-13017
> URL: https://issues.apache.org/jira/browse/AMBARI-13017
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.0
> Environment: all
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: AMBARI-13017.patch
>
>
> PROBLEM: Installing falcon with blueprint, oozie extensions are missing, 
> hence causing misconfigured installations that are using blueprint. 
> For instance, on the sandbox which uses blueprint to install falcon(attached 
> to this bug) outputs the following for 
> grep -i ext /etc/oozie/conf/oozie-site.xml
> oozie.services.ext
> on a cluster that install falcon via add service via the webui, running grep 
> -i ext /etc/oozie/conf/oozie-site.xml produces 
> oozie.service.ELService.ext.functions.coord-action-create
> oozie.service.ELService.ext.functions.coord-sla-create
> oozie.service.ELService.ext.functions.coord-sla-submit
> Hence, the blueprint install will be missing needed properties.
> IMPACT: falcon will not operate as expected
> STEPS TO REPRODUCE:
> 1. Install cluster via ambari blueprint attached. 
> 2. view the oozie site and do grep -i ext /etc/oozie/conf/oozie-site.xml
> 3. Install cluster via ambari webui UI 
> 4. view the oozie site and do grep -i ext /etc/oozie/conf/oozie-site.xml you 
> should proper complete set of configs.



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

[jira] [Updated] (AMBARI-13017) Installing falcon with blueprint, oozie extensions are missing, hence causing misconfigured installations that are using blueprint

2015-09-08 Thread Mahadev konar (JIRA)


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

Mahadev konar updated AMBARI-13017:
---
Fix Version/s: 2.2.0

> Installing falcon with blueprint, oozie extensions are missing, hence causing 
> misconfigured installations that are using blueprint
> --
>
> Key: AMBARI-13017
> URL: https://issues.apache.org/jira/browse/AMBARI-13017
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.0
> Environment: all
>Reporter: Sandor Magyari
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: AMBARI-13017.patch
>
>
> PROBLEM: Installing falcon with blueprint, oozie extensions are missing, 
> hence causing misconfigured installations that are using blueprint. 
> For instance, on the sandbox which uses blueprint to install falcon(attached 
> to this bug) outputs the following for 
> grep -i ext /etc/oozie/conf/oozie-site.xml
> oozie.services.ext
> on a cluster that install falcon via add service via the webui, running grep 
> -i ext /etc/oozie/conf/oozie-site.xml produces 
> oozie.service.ELService.ext.functions.coord-action-create
> oozie.service.ELService.ext.functions.coord-sla-create
> oozie.service.ELService.ext.functions.coord-sla-submit
> Hence, the blueprint install will be missing needed properties.
> IMPACT: falcon will not operate as expected
> STEPS TO REPRODUCE:
> 1. Install cluster via ambari blueprint attached. 
> 2. view the oozie site and do grep -i ext /etc/oozie/conf/oozie-site.xml
> 3. Install cluster via ambari webui UI 
> 4. view the oozie site and do grep -i ext /etc/oozie/conf/oozie-site.xml you 
> should proper complete set of configs.



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

Re: Review Request 37733: AMBARI-11740 Duplicated property dfs.heartbeat.interval on hdfs-site

2015-09-08 Thread Juanjo Marron



> On Aug. 25, 2015, midnight, Alejandro Fernandez wrote:
> > Ship It!

Waiting to be shipped


- Juanjo


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/37733/#review96243
---


On Aug. 24, 2015, 10:59 p.m., Juanjo  Marron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/37733/
> ---
> 
> (Updated Aug. 24, 2015, 10:59 p.m.)
> 
> 
> Review request for Ambari and Alejandro Fernandez.
> 
> 
> Bugs: AMBARI-11740
> https://issues.apache.org/jira/browse/AMBARI-11740
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> The property dfs.heartbeat.interval is duplicated on the HDFS configuration 
> files /HDFS/2.1.0.2.0/configuration/hdfs-site.xml
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-site.xml
>  a34d8c0 
>   
> ambari-server/src/main/resources/stacks/BIGTOP/0.8/services/HDFS/configuration/hdfs-site.xml
>  6499868 
>   
> ambari-server/src/main/resources/stacks/HDP/2.0.6.GlusterFS/services/HDFS/configuration/hdfs-site.xml
>  c11523a 
> 
> Diff: https://reviews.apache.org/r/37733/diff/
> 
> 
> Testing
> ---
> 
> Minor change to clean up duplicated propety
> 
> 
> Thanks,
> 
> Juanjo  Marron
> 
>

Review Request 38183: Installing falcon with blueprint, oozie extensions are missing, hence causing misconfigured installations that are using blueprint.

2015-09-08 Thread Sandor Magyari

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38183/
---

Review request for Ambari and Robert Nettleton.

Bugs: AMBARI-13017
https://issues.apache.org/jira/browse/AMBARI-13017

Repository: ambari

Description
---

PROBLEM

Installing falcon with blueprint, oozie extensions are missing, hence causing
misconfigured installations that are using blueprint.

SOLUTION

This issue seems to be related not only for case of falcon but for every
service which has a configuration file for another service.
In case of falcon there is an oozie-site.xml (this contains oozie extensions)
in configuration of falcon service, which is marked as exclued-config-type in
service metainfo.xml. The same is true for AMBARI_METRICS which includes the
storm-site.xml. In case of a bluprint install these are excluded from
properties, which is fine because you can not add a config-type twice. The
solution would to add these properties from excluded-config-type at update
phase of properties in BluprintConfigurationProcessor.doUpdateForClusterCreate.
We can apply this only specifically for FALCON but I dont see yet any drawbacks
of applying it for each service with excluded property.

Diffs
-

ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
892cf32

ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
a881472

Diff: https://reviews.apache.org/r/38183/diff/

Testing
---

Manually tested, creating new cluster with blueprint, unitests passed, created
a new testcase.

Thanks,

Sandor Magyari

Review Request 38182: Blueprint: API call to create cluster instance with blueprint fails when blueprint_name is not correct

2015-09-08 Thread Sandor Magyari

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38182/
---

Review request for Ambari, John Speidel, Robert Nettleton, and Jeff Sposetti.

Bugs: AMBARI-12989
https://issues.apache.org/jira/browse/AMBARI-12989

Repository: ambari

Description
---

PROBLEM

When creating any resource like blueprint, cluster etc, you can specify the
resource name both in the Url and Json payload as well. For example in case of
a blueprint creation: api/v1/blueprints/sandboxURL Json:
{"Blueprints":{"blueprint_name":"sandboxJson"}}. In this case the blueprint
will be created as sandboxJson so the name specified in Json will override the
name specifie din the Url. The behavoir is true for cluster creation and any
other resource where you can specify name in Json as well. This could be a bit
misleading so the API may return an error in case of resource names don't match.

SOLUTION

The solution would be to throw an error message (Error code 400) in case
resource names are different. To achive this only for cluster creation would be
quite complicated since resource handling is quite generic and in
ClusterResourceProvider - which contains resource specific handling - only the
request body is available, the url is not. The actual behaviour is that in
PersistenceManagerImpl.create method the resource name (eg. blueprint_name) is
inserted from the url in Json in case it's missing. So if resource name is
specified in url than that will be used, if is specified both url and Json then
latter will be used. Because of this behaviour I think we should hadnle this
problem in PersistenceManagerImpl.create as you can see in attached patch. This
will affect of course the creation of all resources.
All unittests were

Diffs
-

ambari-server/src/main/java/org/apache/ambari/server/api/services/persistence/PersistenceManagerImpl.java
4db5611

ambari-server/src/test/java/org/apache/ambari/server/api/services/PersistenceManagerImplTest.java
9ff1506

Diff: https://reviews.apache.org/r/38182/diff/

Testing
---

Manually tested blueprint and cluster creation, then cluster creation with
blueprint. All unitests passed, it seems it doesn't affect normal functionality.

Thanks,

Sandor Magyari

[jira] [Commented] (AMBARI-13033) Add Service Wizard:After populating KMS properties, Ranger tab shows up as missing 2 properties

2015-09-08 Thread Aleksandr Kovalenko (JIRA)


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

Aleksandr Kovalenko commented on AMBARI-13033:
--

+1 for the patch

> Add Service Wizard:After populating KMS properties, Ranger tab shows up as 
> missing 2 properties
> ---
>
> Key: AMBARI-13033
> URL: https://issues.apache.org/jira/browse/AMBARI-13033
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13033.patch
>
>
> At the add service wizard- Adding KMS, after populating the fields for KMS, 
> Next button was not enabled and you can see that Ranger tab has an indicator 
> '2' which says its expecting some properties to be populated. Upon clicking 
> the Ranger tab, thats gone too and Next button is enabled by then. As per the 
> analysis this seems to be FE issue. please help take a look



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

[jira] [Updated] (AMBARI-13033) Add Service Wizard:After populating KMS properties, Ranger tab shows up as missing 2 properties


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

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

> Add Service Wizard:After populating KMS properties, Ranger tab shows up as 
> missing 2 properties
> ---
>
> Key: AMBARI-13033
> URL: https://issues.apache.org/jira/browse/AMBARI-13033
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13033.patch
>
>
> At the add service wizard- Adding KMS, after populating the fields for KMS, 
> Next button was not enabled and you can see that Ranger tab has an indicator 
> '2' which says its expecting some properties to be populated. Upon clicking 
> the Ranger tab, thats gone too and Next button is enabled by then. As per the 
> analysis this seems to be FE issue. please help take a look



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

Re: Review Request 37682: [Preview] Stop-and-Start Upgrade: Move Configs out of Upgrade Pack

2015-09-08 Thread Dmitro Lisnichenko


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/37682/#review98012
---



ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
 (line 496)


Without this change, RU can not be started at all


- Dmitro Lisnichenko


On Sept. 8, 2015, 3:37 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/37682/
> ---
> 
> (Updated Sept. 8, 2015, 3:37 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Dmytro Grinenko, Jonathan 
> Hurley, and Nate Cole.
> 
> 
> Bugs: AMBARI-12700
> https://issues.apache.org/jira/browse/AMBARI-12700
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> The configs need to move out of the Upgrade Packs and into their own file.
> This will make it easier to maintain, and clearer since there will not be any 
> dups.
> 
> Since it is going to be a massive change, it would be great to get early 
> feedback. Code is not complete (still full of TODOs and does not even build)
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/services/AmbariMetaInfo.java
>  4afa9b0 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
>  dddec73 
>   
> ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/ConfigureAction.java
>  c717582 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/ModuleFileUnmarshaller.java
>  aa8e17b 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/StackDefinitionDirectory.java
>  8f81b5a 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/StackDirectory.java
>  db947ca 
>   ambari-server/src/main/java/org/apache/ambari/server/stack/StackModule.java 
> 4b88aff 
>   ambari-server/src/main/java/org/apache/ambari/server/state/StackInfo.java 
> 87301e5 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeHelper.java 
> ecefe6e 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/stack/ConfigUpgradePatch.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/ConfigureTask.java
>  8361ea6 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/ConfigureTask.java
>  8361ea6 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/Grouping.java
>  9d89b7a 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/StageWrapperBuilder.java
>  c9c6b8c 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
> 7c1a1f9 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
> 7c1a1f9 
>   
> ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/ConfigureActionTest.java
>  e702e0a 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/UpgradeHelperTest.java
>  2eee2df 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/stack/UpgradePackTest.java
>  fc731d9 
> 
> Diff: https://reviews.apache.org/r/37682/diff/
> 
> 
> Testing
> ---
> 
> just published preview of changes
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Re: Review Request 37682: [Preview] Stop-and-Start Upgrade: Move Configs out of Upgrade Pack

2015-09-08 Thread Dmitro Lisnichenko


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/37682/
---

(Updated Sept. 8, 2015, 3:37 p.m.)


Review request for Ambari, Alejandro Fernandez, Dmytro Grinenko, Jonathan 
Hurley, and Nate Cole.


Changes
---

Published a new patch. 
I've tested RU 2.2->2.3 for few services on live cluster, and config changes 
seem to work properly.
I've refactored all configure tasks for 2.2->2.3 to a new format 

My current plan is to:
- Move config changes for RU and SWU for 2.2->2.2+ to a separate file
- Commit the patch and close current jira 
- Open a separate jira to fix unit tests. As of now, unit tests are commented 
out/ignored. 
- Implement config upgrade for cross-stack upgrade
- Commit the patch to unblock cross-stack upgrade development and avoid further 
merges
- Complete fix unit tests jira


Bugs: AMBARI-12700
https://issues.apache.org/jira/browse/AMBARI-12700


Repository: ambari


Description
---

The configs need to move out of the Upgrade Packs and into their own file.
This will make it easier to maintain, and clearer since there will not be any 
dups.

Since it is going to be a massive change, it would be great to get early 
feedback. Code is not complete (still full of TODOs and does not even build)


Diffs (updated)
-

  
ambari-server/src/main/java/org/apache/ambari/server/api/services/AmbariMetaInfo.java
 4afa9b0 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
 dddec73 
  
ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/ConfigureAction.java
 c717582 
  
ambari-server/src/main/java/org/apache/ambari/server/stack/ModuleFileUnmarshaller.java
 aa8e17b 
  
ambari-server/src/main/java/org/apache/ambari/server/stack/StackDefinitionDirectory.java
 8f81b5a 
  
ambari-server/src/main/java/org/apache/ambari/server/stack/StackDirectory.java 
db947ca 
  ambari-server/src/main/java/org/apache/ambari/server/stack/StackModule.java 
4b88aff 
  ambari-server/src/main/java/org/apache/ambari/server/state/StackInfo.java 
87301e5 
  ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeHelper.java 
ecefe6e 
  
ambari-server/src/main/java/org/apache/ambari/server/state/stack/ConfigUpgradePatch.java
 PRE-CREATION 
  
ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/ConfigureTask.java
 8361ea6 
  
ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/ConfigureTask.java
 8361ea6 
  
ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/Grouping.java
 9d89b7a 
  
ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/StageWrapperBuilder.java
 c9c6b8c 
  ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
7c1a1f9 
  ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
7c1a1f9 
  
ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/ConfigureActionTest.java
 e702e0a 
  
ambari-server/src/test/java/org/apache/ambari/server/state/UpgradeHelperTest.java
 2eee2df 
  
ambari-server/src/test/java/org/apache/ambari/server/state/stack/UpgradePackTest.java
 fc731d9 

Diff: https://reviews.apache.org/r/37682/diff/


Testing
---

just published preview of changes


Thanks,

Dmitro Lisnichenko

Re: Review Request 38181: Automatically Skip Failed Tasks Of Slaves During Upgrade



> On Sept. 8, 2015, 10:12 a.m., Nate Cole wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/actionmanager/ActionDBAccessorImpl.java,
> >  lines 466-469
> > 
> >
> > Doesn't have to be addressed for this patch (or maybe ever), but we may 
> > want to consider this auto-skip feature for TIMEDOUT statuses as well.

Thanks for the review. I agree that it's unclear whether we want this state to 
be skippable too. Timedout usually means something nasty happened, like a 
heartbeat lost. In that case, it's a different breed of failure, so I left it 
as-is for now. Certainly, I can open a Jira to track this.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38181/#review98001
---


On Sept. 8, 2015, 9:30 a.m., Jonathan Hurley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38181/
> ---
> 
> (Updated Sept. 8, 2015, 9:30 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Nate Cole.
> 
> 
> Bugs: AMBARI-13032
> https://issues.apache.org/jira/browse/AMBARI-13032
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> During an upgrade, if any slave component experiences a failure during its 
> restart state then there should be a way for the rest of the upgrade group to 
> automatically continue despite the failure. This will prevent the need of 
> administrators to babysit the upgrade process, especially in cases of larger 
> clusters.
> 
> During the creation of the upgrade, an optional parameter should be supplied 
> to the REST endpoint to accomplish this.
> 
> {code:title=POST api/v1/clusters/c1/upgrades}
> {
>   "Upgrade": {
> "repository_version": "2.3.0.0-2545",
> "skip_failures": true
>   }
> }
> {code}
> 
> The various skippable parts of the upgrade can be broken out into distinct 
> request parameters:
> - {{skip_failures}} (skips all component failures)
> - {{skip_service_check_failures}} (skips all service check failures)
> 
> If an upgrade begins without the skip option specified, it can later be added:
> 
> {code:title=PUT api/v1/clusters/c1/upgrades/1}
> {
>   "Upgrade": {
> "skip_failures": true
>   }
> }
> {code}
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/ActionDBAccessorImpl.java
>  62f8be9 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommand.java
>  9d44454 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactory.java
>  84c2d2a 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactoryImpl.java
>  0440f87 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleStatus.java
>  39cbabc 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/Stage.java 
> fcd0324 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/ActionExecutionContext.java
>  ee5febe 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariActionExecutionHelper.java
>  a422b2d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
>  43bdbfe 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
>  a90cb31 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
>  6f407c9 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java
>  a942c93 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/HostStackVersionResourceProvider.java
>  1051056 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
>  770cc04 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandDAO.java
>  9c91656 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandStatusSummaryDTO.java
>  54ade92 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostRoleCommandEntity.java
>  d99da6d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeContext.java
>  86dbccd 
>   
> ambari-server/src/main/java/org/apache/ambari/server/topology/LogicalRequest.java
>  b7f95cf 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog212.java
>  02df181 
>   ambari-server/src/main/java/org/apache/ambari/server/utils/StageUtils.java 
> 3da0fe2 
>   ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql 265e42e 
>   ambari-server/src/main/reso

New Branch

All,

Just a heads-up that development is soon ramping up on a new feature: Patch 
Upgrades.  Patch Upgrades will be used for incremental stack fixes that do not 
fit into either Rolling or Stop-the-World Upgrades.

In that context, we will be creating a new branch called 
branch-dev-patch-upgrade that will be kept in-sync with trunk (similar to how 
we are doing SWU with branch-dev-stop-all-upgrade).

Thanks,
Nate

[jira] [Commented] (AMBARI-13030) Alerts are automatically added to newly created alert group if some alert group was chosen


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

Hudson commented on AMBARI-13030:
-

FAILURE: Integrated in Ambari-branch-2.1 #491 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/491/])
AMBARI-13030. Alerts are automatically added to newly created alert group if 
some alert group was chosen (alexantonenko) (hiveww: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=520a601da227ed4b503849b506a2b6e1e5ce16e2)
* ambari-web/app/controllers/main/alerts/manage_alert_groups_controller.js


> Alerts are automatically added to newly created alert group if some alert 
> group was chosen
> --
>
> Key: AMBARI-13030
> URL: https://issues.apache.org/jira/browse/AMBARI-13030
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13030.patch
>
>
> # Go to alert groups page
> # Click on some alert group
> # Create alert group
> AR : created alert group contains alerts from alert group that was chosen



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

[jira] [Created] (AMBARI-13033) Add Service Wizard:After populating KMS properties, Ranger tab shows up as missing 2 properties

Antonenko Alexander created AMBARI-13033:


 Summary: Add Service Wizard:After populating KMS properties, 
Ranger tab shows up as missing 2 properties
 Key: AMBARI-13033
 URL: https://issues.apache.org/jira/browse/AMBARI-13033
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.1.2
Reporter: Antonenko Alexander
Assignee: Antonenko Alexander
Priority: Critical
 Fix For: 2.1.2


At the add service wizard- Adding KMS, after populating the fields for KMS, 
Next button was not enabled and you can see that Ranger tab has an indicator 
'2' which says its expecting some properties to be populated. Upon clicking the 
Ranger tab, thats gone too and Next button is enabled by then. As per the 
analysis this seems to be FE issue. please help take a look



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

[jira] [Commented] (AMBARI-13030) Alerts are automatically added to newly created alert group if some alert group was chosen


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

Hudson commented on AMBARI-13030:
-

SUCCESS: Integrated in Ambari-trunk-Commit #3399 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3399/])
AMBARI-13030. Alerts are automatically added to newly created alert group if 
some alert group was chosen (alexantonenko) (hiveww: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=efb10fb0268c224b0892c1a1ace09cf3cbbb15d1)
* ambari-web/app/controllers/main/alerts/manage_alert_groups_controller.js


> Alerts are automatically added to newly created alert group if some alert 
> group was chosen
> --
>
> Key: AMBARI-13030
> URL: https://issues.apache.org/jira/browse/AMBARI-13030
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13030.patch
>
>
> # Go to alert groups page
> # Click on some alert group
> # Create alert group
> AR : created alert group contains alerts from alert group that was chosen



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

Python client abandoned?

2015-09-08 Thread Greg Hill

The Python client hasn't been updated in a year or so:

https://github.com/apache/ambari/tree/trunk/ambari-client/python-client/src/main/python

I tried to work with Subin to modernize it previously but things didn't work 
out so I ended up making my own client:

https://github.com/jimbobhickville/python-ambariclient

We've been using it here at Rackspace for nearly a year now and it's been 
pretty great.  Easy to use, easy to work on, and much more full-featured than 
the existing client.  I'd love to contribute it back as the official Python 
client, since the existing one is broken and missing a lot of features (for 
example, it can't create clusters since Ambari 1.7, and has no support for 
newer features like metrics).

I know there is some work to be done to make it integrate better with the 
existing Ambari tooling, but I wanted to reach out and see if such an addition 
would be welcome.  If it is, we can sort out what all requirements need to be 
met before it can be integrated back in.

Greg

Re: Review Request 38181: Automatically Skip Failed Tasks Of Slaves During Upgrade


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38181/#review98001
---

Ship it!



ambari-server/src/main/java/org/apache/ambari/server/actionmanager/ActionDBAccessorImpl.java
 (lines 465 - 468)


Doesn't have to be addressed for this patch (or maybe ever), but we may 
want to consider this auto-skip feature for TIMEDOUT statuses as well.


- Nate Cole


On Sept. 8, 2015, 9:30 a.m., Jonathan Hurley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38181/
> ---
> 
> (Updated Sept. 8, 2015, 9:30 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Nate Cole.
> 
> 
> Bugs: AMBARI-13032
> https://issues.apache.org/jira/browse/AMBARI-13032
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> During an upgrade, if any slave component experiences a failure during its 
> restart state then there should be a way for the rest of the upgrade group to 
> automatically continue despite the failure. This will prevent the need of 
> administrators to babysit the upgrade process, especially in cases of larger 
> clusters.
> 
> During the creation of the upgrade, an optional parameter should be supplied 
> to the REST endpoint to accomplish this.
> 
> {code:title=POST api/v1/clusters/c1/upgrades}
> {
>   "Upgrade": {
> "repository_version": "2.3.0.0-2545",
> "skip_failures": true
>   }
> }
> {code}
> 
> The various skippable parts of the upgrade can be broken out into distinct 
> request parameters:
> - {{skip_failures}} (skips all component failures)
> - {{skip_service_check_failures}} (skips all service check failures)
> 
> If an upgrade begins without the skip option specified, it can later be added:
> 
> {code:title=PUT api/v1/clusters/c1/upgrades/1}
> {
>   "Upgrade": {
> "skip_failures": true
>   }
> }
> {code}
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/ActionDBAccessorImpl.java
>  62f8be9 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommand.java
>  9d44454 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactory.java
>  84c2d2a 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactoryImpl.java
>  0440f87 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleStatus.java
>  39cbabc 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/Stage.java 
> fcd0324 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/ActionExecutionContext.java
>  ee5febe 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariActionExecutionHelper.java
>  a422b2d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
>  43bdbfe 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
>  a90cb31 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
>  6f407c9 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java
>  a942c93 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/HostStackVersionResourceProvider.java
>  1051056 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
>  770cc04 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandDAO.java
>  9c91656 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandStatusSummaryDTO.java
>  54ade92 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostRoleCommandEntity.java
>  d99da6d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeContext.java
>  86dbccd 
>   
> ambari-server/src/main/java/org/apache/ambari/server/topology/LogicalRequest.java
>  b7f95cf 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog212.java
>  02df181 
>   ambari-server/src/main/java/org/apache/ambari/server/utils/StageUtils.java 
> 3da0fe2 
>   ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql 265e42e 
>   ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql 0053837 
>   ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql 30b669d 
>   ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql 
> 4f7569c 
>   ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql 97b5e11 
>   ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 81d0e6f 
>   ambar

Re: Review Request 38157: Ambari over riding customer specific properties for HDFS, YARN and Hive on Upgrade of Ambari

2015-09-08 Thread Robert Levas


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38157/#review97998
---

Ship it!


Ship It!

- Robert Levas


On Sept. 7, 2015, 10:46 a.m., Vitalyi Brodetskyi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38157/
> ---
> 
> (Updated Sept. 7, 2015, 10:46 a.m.)
> 
> 
> Review request for Ambari, Robert Levas and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-13026
> https://issues.apache.org/jira/browse/AMBARI-13026
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Upgrade from ambari 1.7.0 to 2.1.1 HDP2.2 was done. During kerberos enabling 
> hadoop.rpc.protection property, was added. Start datanode fails, because this 
> property need few other related properties.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/kerberos.json 
> b9e6a75 
> 
> Diff: https://reviews.apache.org/r/38157/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Vitalyi Brodetskyi
> 
>

Review Request 38181: Automatically Skip Failed Tasks Of Slaves During Upgrade


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38181/
---

Review request for Ambari, Alejandro Fernandez and Nate Cole.


Bugs: AMBARI-13032
https://issues.apache.org/jira/browse/AMBARI-13032


Repository: ambari


Description
---

During an upgrade, if any slave component experiences a failure during its 
restart state then there should be a way for the rest of the upgrade group to 
automatically continue despite the failure. This will prevent the need of 
administrators to babysit the upgrade process, especially in cases of larger 
clusters.

During the creation of the upgrade, an optional parameter should be supplied to 
the REST endpoint to accomplish this.

{code:title=POST api/v1/clusters/c1/upgrades}
{
  "Upgrade": {
"repository_version": "2.3.0.0-2545",
"skip_failures": true
  }
}
{code}

The various skippable parts of the upgrade can be broken out into distinct 
request parameters:
- {{skip_failures}} (skips all component failures)
- {{skip_service_check_failures}} (skips all service check failures)

If an upgrade begins without the skip option specified, it can later be added:

{code:title=PUT api/v1/clusters/c1/upgrades/1}
{
  "Upgrade": {
"skip_failures": true
  }
}
{code}


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/ActionDBAccessorImpl.java
 62f8be9 
  
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommand.java
 9d44454 
  
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactory.java
 84c2d2a 
  
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleCommandFactoryImpl.java
 0440f87 
  
ambari-server/src/main/java/org/apache/ambari/server/actionmanager/HostRoleStatus.java
 39cbabc 
  ambari-server/src/main/java/org/apache/ambari/server/actionmanager/Stage.java 
fcd0324 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/ActionExecutionContext.java
 ee5febe 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariActionExecutionHelper.java
 a422b2d 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
 43bdbfe 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
 a90cb31 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
 6f407c9 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java
 a942c93 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/HostStackVersionResourceProvider.java
 1051056 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
 770cc04 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandDAO.java
 9c91656 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandStatusSummaryDTO.java
 54ade92 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostRoleCommandEntity.java
 d99da6d 
  
ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeContext.java 
86dbccd 
  
ambari-server/src/main/java/org/apache/ambari/server/topology/LogicalRequest.java
 b7f95cf 
  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog212.java
 02df181 
  ambari-server/src/main/java/org/apache/ambari/server/utils/StageUtils.java 
3da0fe2 
  ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql 265e42e 
  ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql 0053837 
  ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql 30b669d 
  ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql 
4f7569c 
  ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql 97b5e11 
  ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 81d0e6f 
  ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
04befaf 
  
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/ExecutionCommandWrapperTest.java
 8d21b80 
  
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/StageTest.java
 fa1e770 
  
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionDBAccessorImpl.java
 520be9f 
  
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionManager.java
 27f11f7 
  
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionScheduler.java
 cfbc38e 
  
ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestStage.java
 13453df 
  
ambari-server/src/test/java/org/apache/ambari/server/agent/TestHeartbeatHandler.java
 4a4f8c9 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
 4235ccd 
  
ambari

[jira] [Created] (AMBARI-13032) Automatically Skip Failed Tasks Of Slaves During Upgrade

2015-09-08 Thread Jonathan Hurley (JIRA)

Jonathan Hurley created AMBARI-13032:


 Summary: Automatically Skip Failed Tasks Of Slaves During Upgrade
 Key: AMBARI-13032
 URL: https://issues.apache.org/jira/browse/AMBARI-13032
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.1.0
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
Priority: Critical
 Fix For: 2.1.2


During an upgrade, if any slave component experiences a failure during its 
restart state then there should be a way for the rest of the upgrade group to 
automatically continue despite the failure. This will prevent the need of 
administrators to babysit the upgrade process, especially in cases of larger 
clusters.

During the creation of the upgrade, an optional parameter should be supplied to 
the REST endpoint to accomplish this.

{code:title=POST api/v1/clusters/c1/upgrades}
{
  "Upgrade": {
"repository_version": "2.3.0.0-2545",
"skip_failures": true
  }
}
{code}

The various skippable parts of the upgrade can be broken out into distinct 
request parameters:
- {{skip_failures}} (skips all component failures)
- {{skip_service_check_failures}} (skips all service check failures)

If an upgrade begins without the skip option specified, it can later be added:

{code:title=PUT api/v1/clusters/c1/upgrades/1}
{
  "Upgrade": {
"skip_failures": true
  }
}
{code}



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

[jira] [Commented] (AMBARI-13028) Need more informative error message on set-current


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

Hudson commented on AMBARI-13028:
-

FAILURE: Integrated in Ambari-branch-2.1 #490 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/490/])
AMBARI-13028. Need more informative error message on set-current.(vbrodetskyi) 
(vbrodetskyi: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=6dd8940bcc359b309c102e16b76d15287f3a3441)
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java


> Need more informative error message on set-current
> --
>
> Key: AMBARI-13028
> URL: https://issues.apache.org/jira/browse/AMBARI-13028
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.1
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
> Fix For: 2.1.2
>
> Attachments: AMBARI-13028.patch
>
>
> When a user performances a manual upgrade (2.2 -> 2.3 or maint), they have to 
> run set-current at the end and provide cluster name and version display name.
> If they incorrectly enter the cluster name, the error looks like this:
> {code}
> ambari-server set-current --cluster-name=os-rhel6-upgrade-t2-allservices 
> --version-display-name=HDP-2.2.8.0
> Using python  /usr/bin/python2.6
> Setting current version...
> Enter Ambari Admin login: admin
> Enter Ambari Admin password:
> ERROR: Exiting with exit code 1.
> REASON: Error during setting current version. Http status code - 500.
>  {
>   "status" : 500,
>   "message" : "org.apache.ambari.server.controller.spi.SystemException: Can 
> not perform request"
> }
> {code}
> This error should be a lot more informative to tell the user the cluster was 
> not found, that they should provide the cluster name and to double-check 
> their command.



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

[jira] [Commented] (AMBARI-13031) Config tab for Ranger updates incorrectly


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

Hudson commented on AMBARI-13031:
-

FAILURE: Integrated in Ambari-branch-2.1 #490 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/490/])
AMBARI-13031 Config tab for Ranger updates incorrectly. (ababiichuk) 
(ababiichuk: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=5aa60e7b090b8f902c900803e0f79bdb1aa9ed17)
* ambari-web/app/views/common/controls_view.js


> Config tab for Ranger updates incorrectly
> -
>
> Key: AMBARI-13031
> URL: https://issues.apache.org/jira/browse/AMBARI-13031
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Blocker
> Fix For: 2.1.2
>
> Attachments: AMBARI-13031.patch
>
>
> Deploy a cluster with Ranger, set Ranger DB to SQLA.
> Go to Ranger config tab, change property 'Location of Sql Connector Jar' 
> (default value is '/path_to_driver/sqla-client-jdbc.tar.gz')
> Save.
> Update the page (F5, or go on another service and back).
> Actual behaviour : Save/Discard buttons are available (discard in case of 
> clicking do nothing), and 'Location of Sql Connector Jar' property has the 
> default value with undo indicator present 
> (/path_to_driver/sqla-client-jdbc.tar.gz).



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

[jira] [Commented] (AMBARI-12837) Server component should read HCFS type info from stack and propagate it in dictionary for agent and UI to consume


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

Hadoop QA commented on AMBARI-12837:


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

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

This message is automatically generated.

> Server component should read HCFS type info from stack and propagate it in 
> dictionary for agent and UI to consume
> -
>
> Key: AMBARI-12837
> URL: https://issues.apache.org/jira/browse/AMBARI-12837
> Project: Ambari
>  Issue Type: Task
>Affects Versions: trunk
>Reporter: Vijay Srinivasaraghavan
>Assignee: Vijay Srinivasaraghavan
> Attachments: AMBARI-12837.patch
>
>
> UI and agent code is using namenode configuration as a validation to check if 
> HDFS is selected or not and perform some HDFS specific operations like 
> creating /tmp directory, reading hadoop-env configurations like 
> hdfs_log_dir_prefix, dropping fast-hdfs-resource.jar etc., because of which 
> the configurations defined for HCFS types are not getting populated. The 
> ambari server component should tarverse thhrough the stack configuration and 
> populate (hadoop-env or cluster-env) dictionary if HCFS file system is 
> asscoated as part of the stack. The dictionary configuration should be used 
> in UI and agent code to allow FS operations require to bootstrap the cluster 
> deployment.



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

[jira] [Commented] (AMBARI-13028) Need more informative error message on set-current


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

Hudson commented on AMBARI-13028:
-

SUCCESS: Integrated in Ambari-trunk-Commit #3398 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3398/])
AMBARI-13028. Need more informative error message on set-current.(vbrodetskyi) 
(vbrodetskyi: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=1757b859125ea0bf9c8fc4d683e9567e73aa537e)
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java


> Need more informative error message on set-current
> --
>
> Key: AMBARI-13028
> URL: https://issues.apache.org/jira/browse/AMBARI-13028
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.1
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
> Fix For: 2.1.2
>
> Attachments: AMBARI-13028.patch
>
>
> When a user performances a manual upgrade (2.2 -> 2.3 or maint), they have to 
> run set-current at the end and provide cluster name and version display name.
> If they incorrectly enter the cluster name, the error looks like this:
> {code}
> ambari-server set-current --cluster-name=os-rhel6-upgrade-t2-allservices 
> --version-display-name=HDP-2.2.8.0
> Using python  /usr/bin/python2.6
> Setting current version...
> Enter Ambari Admin login: admin
> Enter Ambari Admin password:
> ERROR: Exiting with exit code 1.
> REASON: Error during setting current version. Http status code - 500.
>  {
>   "status" : 500,
>   "message" : "org.apache.ambari.server.controller.spi.SystemException: Can 
> not perform request"
> }
> {code}
> This error should be a lot more informative to tell the user the cluster was 
> not found, that they should provide the cluster name and to double-check 
> their command.



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

[jira] [Commented] (AMBARI-13031) Config tab for Ranger updates incorrectly


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

Hudson commented on AMBARI-13031:
-

SUCCESS: Integrated in Ambari-trunk-Commit #3398 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3398/])
AMBARI-13031 Config tab for Ranger updates incorrectly. (ababiichuk) 
(ababiichuk: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=9acb26f275ef0a0b5dc2f221d877cd91a4368201)
* ambari-web/app/views/common/controls_view.js


> Config tab for Ranger updates incorrectly
> -
>
> Key: AMBARI-13031
> URL: https://issues.apache.org/jira/browse/AMBARI-13031
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Blocker
> Fix For: 2.1.2
>
> Attachments: AMBARI-13031.patch
>
>
> Deploy a cluster with Ranger, set Ranger DB to SQLA.
> Go to Ranger config tab, change property 'Location of Sql Connector Jar' 
> (default value is '/path_to_driver/sqla-client-jdbc.tar.gz')
> Save.
> Update the page (F5, or go on another service and back).
> Actual behaviour : Save/Discard buttons are available (discard in case of 
> clicking do nothing), and 'Location of Sql Connector Jar' property has the 
> default value with undo indicator present 
> (/path_to_driver/sqla-client-jdbc.tar.gz).



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

[jira] [Commented] (AMBARI-13029) when ambari-agent has 'run_as_user' as a comment in ambari-agent.ini, wrong user to run ambari as can be picked up


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

Hudson commented on AMBARI-13029:
-

SUCCESS: Integrated in Ambari-trunk-Commit #3397 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3397/])
AMBARI-13029. when ambari-agent has 'run_as_user' as a comment in 
ambari-agent.ini, wrong user to run ambari as can be picked up (aonishuk) 
(aonishuk: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=bfba14cbd06efb0d41029575118ce6ea0ae06b21)
* ambari-agent/etc/init.d/ambari-agent


> when ambari-agent has 'run_as_user' as a comment in ambari-agent.ini, wrong 
> user to run ambari as can be picked up
> --
>
> Key: AMBARI-13029
> URL: https://issues.apache.org/jira/browse/AMBARI-13029
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.1.2
>
>




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

[jira] [Commented] (AMBARI-13029) when ambari-agent has 'run_as_user' as a comment in ambari-agent.ini, wrong user to run ambari as can be picked up


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

Hudson commented on AMBARI-13029:
-

FAILURE: Integrated in Ambari-branch-2.1 #489 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/489/])
AMBARI-13029. when ambari-agent has 'run_as_user' as a comment in 
ambari-agent.ini, wrong user to run ambari as can be picked up (aonishuk) 
(aonishuk: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=0cbe4da800555d440933cb6eabedd5628c222a0a)
* ambari-agent/etc/init.d/ambari-agent


> when ambari-agent has 'run_as_user' as a comment in ambari-agent.ini, wrong 
> user to run ambari as can be picked up
> --
>
> Key: AMBARI-13029
> URL: https://issues.apache.org/jira/browse/AMBARI-13029
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.1.2
>
>




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

[jira] [Commented] (AMBARI-13031) Config tab for Ranger updates incorrectly

2015-09-08 Thread Oleg Nechiporenko (JIRA)


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

Oleg Nechiporenko commented on AMBARI-13031:


+1 for patch

> Config tab for Ranger updates incorrectly
> -
>
> Key: AMBARI-13031
> URL: https://issues.apache.org/jira/browse/AMBARI-13031
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Blocker
> Fix For: 2.1.2
>
> Attachments: AMBARI-13031.patch
>
>
> Deploy a cluster with Ranger, set Ranger DB to SQLA.
> Go to Ranger config tab, change property 'Location of Sql Connector Jar' 
> (default value is '/path_to_driver/sqla-client-jdbc.tar.gz')
> Save.
> Update the page (F5, or go on another service and back).
> Actual behaviour : Save/Discard buttons are available (discard in case of 
> clicking do nothing), and 'Location of Sql Connector Jar' property has the 
> default value with undo indicator present 
> (/path_to_driver/sqla-client-jdbc.tar.gz).



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

[jira] [Updated] (AMBARI-13031) Config tab for Ranger updates incorrectly

2015-09-08 Thread Andrii Babiichuk (JIRA)


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

Andrii Babiichuk updated AMBARI-13031:
--
Attachment: AMBARI-13031.patch

> Config tab for Ranger updates incorrectly
> -
>
> Key: AMBARI-13031
> URL: https://issues.apache.org/jira/browse/AMBARI-13031
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Blocker
> Fix For: 2.1.2
>
> Attachments: AMBARI-13031.patch
>
>
> Deploy a cluster with Ranger, set Ranger DB to SQLA.
> Go to Ranger config tab, change property 'Location of Sql Connector Jar' 
> (default value is '/path_to_driver/sqla-client-jdbc.tar.gz')
> Save.
> Update the page (F5, or go on another service and back).
> Actual behaviour : Save/Discard buttons are available (discard in case of 
> clicking do nothing), and 'Location of Sql Connector Jar' property has the 
> default value with undo indicator present 
> (/path_to_driver/sqla-client-jdbc.tar.gz).



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

[jira] [Created] (AMBARI-13031) Config tab for Ranger updates incorrectly

2015-09-08 Thread Andrii Babiichuk (JIRA)

Andrii Babiichuk created AMBARI-13031:
-

 Summary: Config tab for Ranger updates incorrectly
 Key: AMBARI-13031
 URL: https://issues.apache.org/jira/browse/AMBARI-13031
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.1.2
Reporter: Andrii Babiichuk
Assignee: Andrii Babiichuk
Priority: Blocker
 Fix For: 2.1.2


Deploy a cluster with Ranger, set Ranger DB to SQLA.
Go to Ranger config tab, change property 'Location of Sql Connector Jar' 
(default value is '/path_to_driver/sqla-client-jdbc.tar.gz')
Save.
Update the page (F5, or go on another service and back).
Actual behaviour : Save/Discard buttons are available (discard in case of 
clicking do nothing), and 'Location of Sql Connector Jar' property has the 
default value with undo indicator present 
(/path_to_driver/sqla-client-jdbc.tar.gz).



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

[jira] [Commented] (AMBARI-13030) Alerts are automatically added to newly created alert group if some alert group was chosen

2015-09-08 Thread Aleksandr Kovalenko (JIRA)


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

Aleksandr Kovalenko commented on AMBARI-13030:
--

+1 for the patch

> Alerts are automatically added to newly created alert group if some alert 
> group was chosen
> --
>
> Key: AMBARI-13030
> URL: https://issues.apache.org/jira/browse/AMBARI-13030
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13030.patch
>
>
> # Go to alert groups page
> # Click on some alert group
> # Create alert group
> AR : created alert group contains alerts from alert group that was chosen



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

[jira] [Commented] (AMBARI-13030) Alerts are automatically added to newly created alert group if some alert group was chosen


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

Hadoop QA commented on AMBARI-13030:


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

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

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

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

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

{color:green}+1 core tests{color}.  The patch passed unit tests in .

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

This message is automatically generated.

> Alerts are automatically added to newly created alert group if some alert 
> group was chosen
> --
>
> Key: AMBARI-13030
> URL: https://issues.apache.org/jira/browse/AMBARI-13030
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13030.patch
>
>
> # Go to alert groups page
> # Click on some alert group
> # Create alert group
> AR : created alert group contains alerts from alert group that was chosen



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

Re: Review Request 38163: Need more informative error message on set-current


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38163/#review97981
---

Ship it!


Ship It!

- Andrew Onischuk


On Sept. 8, 2015, 8:43 a.m., Vitalyi Brodetskyi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38163/
> ---
> 
> (Updated Sept. 8, 2015, 8:43 a.m.)
> 
> 
> Review request for Ambari, Andrew Onischuk, Dmitro Lisnichenko, and Dmytro 
> Sen.
> 
> 
> Bugs: AMBARI-13028
> https://issues.apache.org/jira/browse/AMBARI-13028
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When a user performances a manual upgrade (2.2 -> 2.3 or maint), they have to 
> run set-current at the end and provide cluster name and version display name.
> 
> If they incorrectly enter the cluster name, the error looks like this:
> 
> {code}
> ambari-server set-current --cluster-name=os-rhel6-upgrade-t2-allservices 
> --version-display-name=HDP-2.2.8.0
> Using python  /usr/bin/python2.6
> Setting current version...
> Enter Ambari Admin login: admin
> Enter Ambari Admin password:
> ERROR: Exiting with exit code 1.
> REASON: Error during setting current version. Http status code - 500.
>  {
>   "status" : 500,
>   "message" : "org.apache.ambari.server.controller.spi.SystemException: Can 
> not perform request"
> }
> {code}
> 
> This error should be a lot more informative to tell the user the cluster was 
> not found, that they should provide the cluster name and to double-check 
> their command.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java
>  be0af16 
> 
> Diff: https://reviews.apache.org/r/38163/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Vitalyi Brodetskyi
> 
>

[jira] [Updated] (AMBARI-13030) Alerts are automatically added to newly created alert group if some alert group was chosen


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

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

> Alerts are automatically added to newly created alert group if some alert 
> group was chosen
> --
>
> Key: AMBARI-13030
> URL: https://issues.apache.org/jira/browse/AMBARI-13030
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13030.patch
>
>
> # Go to alert groups page
> # Click on some alert group
> # Create alert group
> AR : created alert group contains alerts from alert group that was chosen



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

[jira] [Created] (AMBARI-13030) Alerts are automatically added to newly created alert group if some alert group was chosen

Antonenko Alexander created AMBARI-13030:


 Summary: Alerts are automatically added to newly created alert 
group if some alert group was chosen
 Key: AMBARI-13030
 URL: https://issues.apache.org/jira/browse/AMBARI-13030
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.1.2
Reporter: Antonenko Alexander
Assignee: Antonenko Alexander
Priority: Critical
 Fix For: 2.1.2


# Go to alert groups page
# Click on some alert group
# Create alert group
AR : created alert group contains alerts from alert group that was chosen




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

[jira] [Updated] (AMBARI-13028) Need more informative error message on set-current


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

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

> Need more informative error message on set-current
> --
>
> Key: AMBARI-13028
> URL: https://issues.apache.org/jira/browse/AMBARI-13028
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.1
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
> Fix For: 2.1.2
>
> Attachments: AMBARI-13028.patch
>
>
> When a user performances a manual upgrade (2.2 -> 2.3 or maint), they have to 
> run set-current at the end and provide cluster name and version display name.
> If they incorrectly enter the cluster name, the error looks like this:
> {code}
> ambari-server set-current --cluster-name=os-rhel6-upgrade-t2-allservices 
> --version-display-name=HDP-2.2.8.0
> Using python  /usr/bin/python2.6
> Setting current version...
> Enter Ambari Admin login: admin
> Enter Ambari Admin password:
> ERROR: Exiting with exit code 1.
> REASON: Error during setting current version. Http status code - 500.
>  {
>   "status" : 500,
>   "message" : "org.apache.ambari.server.controller.spi.SystemException: Can 
> not perform request"
> }
> {code}
> This error should be a lot more informative to tell the user the cluster was 
> not found, that they should provide the cluster name and to double-check 
> their command.



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

[jira] [Updated] (AMBARI-13028) Need more informative error message on set-current


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

Vitaly Brodetskyi updated AMBARI-13028:
---
Attachment: (was: AMBARI-13028.patch)

> Need more informative error message on set-current
> --
>
> Key: AMBARI-13028
> URL: https://issues.apache.org/jira/browse/AMBARI-13028
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.1
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
> Fix For: 2.1.2
>
> Attachments: AMBARI-13028.patch
>
>
> When a user performances a manual upgrade (2.2 -> 2.3 or maint), they have to 
> run set-current at the end and provide cluster name and version display name.
> If they incorrectly enter the cluster name, the error looks like this:
> {code}
> ambari-server set-current --cluster-name=os-rhel6-upgrade-t2-allservices 
> --version-display-name=HDP-2.2.8.0
> Using python  /usr/bin/python2.6
> Setting current version...
> Enter Ambari Admin login: admin
> Enter Ambari Admin password:
> ERROR: Exiting with exit code 1.
> REASON: Error during setting current version. Http status code - 500.
>  {
>   "status" : 500,
>   "message" : "org.apache.ambari.server.controller.spi.SystemException: Can 
> not perform request"
> }
> {code}
> This error should be a lot more informative to tell the user the cluster was 
> not found, that they should provide the cluster name and to double-check 
> their command.



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

Re: Review Request 38163: Need more informative error message on set-current

2015-09-08 Thread Vitalyi Brodetskyi


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38163/
---

(Updated Вер. 8, 2015, 8:43 до полудня)


Review request for Ambari, Andrew Onischuk, Dmitro Lisnichenko, and Dmytro Sen.


Bugs: AMBARI-13028
https://issues.apache.org/jira/browse/AMBARI-13028


Repository: ambari


Description
---

When a user performances a manual upgrade (2.2 -> 2.3 or maint), they have to 
run set-current at the end and provide cluster name and version display name.

If they incorrectly enter the cluster name, the error looks like this:

{code}
ambari-server set-current --cluster-name=os-rhel6-upgrade-t2-allservices 
--version-display-name=HDP-2.2.8.0
Using python  /usr/bin/python2.6
Setting current version...
Enter Ambari Admin login: admin
Enter Ambari Admin password:
ERROR: Exiting with exit code 1.
REASON: Error during setting current version. Http status code - 500.
 {
  "status" : 500,
  "message" : "org.apache.ambari.server.controller.spi.SystemException: Can not 
perform request"
}
{code}

This error should be a lot more informative to tell the user the cluster was 
not found, that they should provide the cluster name and to double-check their 
command.


Diffs (updated)
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java
 be0af16 

Diff: https://reviews.apache.org/r/38163/diff/


Testing
---

mvn clean test


Thanks,

Vitalyi Brodetskyi

[jira] [Resolved] (AMBARI-13029) when ambari-agent has 'run_as_user' as a comment in ambari-agent.ini, wrong user to run ambari as can be picked up

2015-09-08 Thread Andrew Onischuk (JIRA)


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

Andrew Onischuk resolved AMBARI-13029.
--
Resolution: Fixed

Committed to trunk and branch-2.1

> when ambari-agent has 'run_as_user' as a comment in ambari-agent.ini, wrong 
> user to run ambari as can be picked up
> --
>
> Key: AMBARI-13029
> URL: https://issues.apache.org/jira/browse/AMBARI-13029
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.1.2
>
>




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

Re: Review Request 38177: when ambari-agent has 'run_as_user' as a comment in ambari-agent.ini, wrong user to run ambari as can be picked up

2015-09-08 Thread Dmitro Lisnichenko


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38177/#review97980
---

Ship it!


Ship It!

- Dmitro Lisnichenko


On Sept. 8, 2015, 8:33 a.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38177/
> ---
> 
> (Updated Sept. 8, 2015, 8:33 a.m.)
> 
> 
> Review request for Ambari and Dmitro Lisnichenko.
> 
> 
> Bugs: AMBARI-13029
> https://issues.apache.org/jira/browse/AMBARI-13029
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> .
> 
> 
> Diffs
> -
> 
>   ambari-agent/etc/init.d/ambari-agent 01fc45c 
> 
> Diff: https://reviews.apache.org/r/38177/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Andrew Onischuk
> 
>

Re: Review Request 38177: when ambari-agent has 'run_as_user' as a comment in ambari-agent.ini, wrong user to run ambari as can be picked up


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38177/
---

(Updated Sept. 8, 2015, 8:33 a.m.)


Review request for Ambari and Dmitro Lisnichenko.


Bugs: AMBARI-13029
https://issues.apache.org/jira/browse/AMBARI-13029


Repository: ambari


Description (updated)
---

.


Diffs
-

  ambari-agent/etc/init.d/ambari-agent 01fc45c 

Diff: https://reviews.apache.org/r/38177/diff/


Testing
---

mvn clean test


Thanks,

Andrew Onischuk

[jira] [Created] (AMBARI-13029) when ambari-agent has 'run_as_user' as a comment in ambari-agent.ini, wrong user to run ambari as can be picked up

2015-09-08 Thread Andrew Onischuk (JIRA)

Andrew Onischuk created AMBARI-13029:


 Summary: when ambari-agent has 'run_as_user' as a comment in 
ambari-agent.ini, wrong user to run ambari as can be picked up
 Key: AMBARI-13029
 URL: https://issues.apache.org/jira/browse/AMBARI-13029
 Project: Ambari
  Issue Type: Bug
Reporter: Andrew Onischuk
Assignee: Andrew Onischuk
 Fix For: 2.1.2






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

Review Request 38177: when ambari-agent has 'run_as_user' as a comment in ambari-agent.ini, wrong user to run ambari as can be picked up


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38177/
---

Review request for Ambari and Dmitro Lisnichenko.


Bugs: AMBARI-13029
https://issues.apache.org/jira/browse/AMBARI-13029


Repository: ambari


Description
---


Diffs
-

  ambari-agent/etc/init.d/ambari-agent 01fc45c 

Diff: https://reviews.apache.org/r/38177/diff/


Testing
---

mvn clean test


Thanks,

Andrew Onischuk

Re: Review Request 38163: Need more informative error message on set-current