[jira] [Commented] (AMBARI-13705) Metrics Cache sizing test failing on trunk

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-13705:


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

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

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

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

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

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

  
org.apache.ambari.server.controller.metrics.timeline.cache.TimelineMetricCacheSizingTest

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

This message is automatically generated.

> Metrics Cache sizing test failing on trunk
> --
>
> Key: AMBARI-13705
> URL: https://issues.apache.org/jira/browse/AMBARI-13705
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.3
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
> Fix For: 2.1.3
>
> Attachments: AMBARI-13705.patch
>
>
> org.apache.ambari.server.controller.metrics.timeline.cache.TimelineMetricCacheSizingTest#testTimelineMetricCacheSizing
>  fails on apache infra only.



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

[jira] [Commented] (AMBARI-13727) Update Ambari 1.8 JDK build number to 1.8u60

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-13727:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12770718/AMBARI-13727.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 5 new 
or modified test files.

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

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

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

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

This message is automatically generated.

> Update Ambari 1.8 JDK build number to 1.8u60
> 
>
> Key: AMBARI-13727
> URL: https://issues.apache.org/jira/browse/AMBARI-13727
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Srimanth Gunturi
>Assignee: Srimanth Gunturi
> Fix For: 2.1.3
>
> Attachments: AMBARI-13727.patch
>
>
> Ambari uses JDK 1.8u40 build which has the following bug:
> [https://bugs.openjdk.java.net/browse/JDK-8078439]. This is a negotiation bug 
> that prevents properly configured web browsers on windows hosts from 
> accessing kerberized APIs if HDP 2.3 is installed with the JDK 1.8u40 which 
> we provide.  We should update this to the current JDK which is 1.8u60 on 
> Oracle's site, which I have had one customer already confirm does not have 
> this issue.



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

[jira] [Commented] (AMBARI-13688) Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 2.2->2.3

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13688:
-

ABORTED: Integrated in Ambari-trunk-Commit #3774 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3774/])
AMBARI-13688. Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 
(afernandez: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=efca65bfff18c8fe1340d5923a91726121359d93])
* 
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.2.xml
* 
ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/params_linux.py
* 
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
* ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml
* 
ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/storm_upgrade.py
* ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/config-upgrade.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml


> Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 2.2->2.3
> --
>
> Key: AMBARI-13688
> URL: https://issues.apache.org/jira/browse/AMBARI-13688
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.1.3
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Critical
> Fix For: 2.2.0, 2.1.3
>
> Attachments: AMBARI-13688.trunk.patch
>
>
> Miscellaneous bug fixes for Express Upgrade in HDP 2.2->2.3 for Storm and 
> Knox.
> Storm: Unable to start service because the Storm dir in the local FS and in 
> Zookeeper znode need to be deleted exactly once per host.
> Deleting the local Storm dir was not working because the marker json file 
> needs to contain the upgrade direction instead of the stage id.
> Knox: simple change to the manual task message to correct the location of the 
> data dir, which should be /var/lib/knox/data



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

[jira] [Commented] (AMBARI-13723) Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13723:
-

ABORTED: Integrated in Ambari-trunk-Commit #3774 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3774/])
AMBARI-13723. Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits 
(afernandez: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=67e069ef37400221ced55356f215ab591f8798ea])
* ambari-server/src/main/resources/custom_actions/scripts/remove_bits.py
* 
ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml


> Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3
> 
>
> Key: AMBARI-13723
> URL: https://issues.apache.org/jira/browse/AMBARI-13723
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.1.3
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.2.0, 2.1.3
>
> Attachments: AMBARI-13723.trunk.patch
>
>
> We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, 
> "hadoop" bin still points to the old binary because we had to install HDP 2.3 
> while 2.1 bits still existed.
> *Manual Upgrade Instructions:*
> * Stop all services using 2.1
> * yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
> /usr/bin/hdfs, /usr/bin/hive, etc/)
> * yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, and hence MR Service Check passes with "hadoop" command
> *Express Upgrade:*
> * Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
> process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
> 2.1 bits
> * Stop all services using 2.1
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, will fail on MR Service Check because ExecuteHadoop() 
> resource calls "hadoop" command, which is still pointing to 2.1 bits!
> One solution is for the orchestration to remove the 2.1 bits before starting 
> using 2.3.
> Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
> "hdp-select set hadoop-client " it will create the symlink 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop



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

[jira] [Commented] (AMBARI-13726) xa_ldap_ad_domain not found under Advanced tab when authentication method is set to AD

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13726:
-

ABORTED: Integrated in Ambari-trunk-Commit #3774 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3774/])
AMBARI-13726. xa_ldap_ad_domain not found under Advanced tab when (jaimin: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=c49a8540b2fdc9f51ac2aeac1b5b15557624aa89])
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/RANGER/themes/theme_version_1.json


> xa_ldap_ad_domain not found under Advanced tab when authentication method is 
> set to AD
> --
>
> Key: AMBARI-13726
> URL: https://issues.apache.org/jira/browse/AMBARI-13726
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, stacks
>Affects Versions: 2.1.3
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
> Fix For: 2.1.3
>
> Attachments: AMBARI-13726.patch
>
>
> The config *xa_ldap_ad_domain* was mentioned in themes.json file by mistake 
> without any widget declaration. This made the config invisible on themes tab 
> and Advanced tab



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

[jira] [Commented] (AMBARI-13726) xa_ldap_ad_domain not found under Advanced tab when authentication method is set to AD

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13726:
-

FAILURE: Integrated in Ambari-branch-2.1 #802 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/802/])
AMBARI-13726. xa_ldap_ad_domain not found under Advanced tab when (jaimin: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=06b3a016173319ccce08b51c411f5fe495a6f1dc])
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/RANGER/themes/theme_version_1.json


> xa_ldap_ad_domain not found under Advanced tab when authentication method is 
> set to AD
> --
>
> Key: AMBARI-13726
> URL: https://issues.apache.org/jira/browse/AMBARI-13726
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, stacks
>Affects Versions: 2.1.3
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
> Fix For: 2.1.3
>
> Attachments: AMBARI-13726.patch
>
>
> The config *xa_ldap_ad_domain* was mentioned in themes.json file by mistake 
> without any widget declaration. This made the config invisible on themes tab 
> and Advanced tab



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

[jira] [Commented] (AMBARI-13688) Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 2.2->2.3

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13688:
-

FAILURE: Integrated in Ambari-branch-2.1 #802 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/802/])
AMBARI-13688. Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 
(afernandez: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=81b912a9525ac788d8b747b54b8bd12a53ef7976])
* 
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.2.xml
* 
ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/params_linux.py
* 
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
* ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml
* 
ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/storm_upgrade.py


> Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 2.2->2.3
> --
>
> Key: AMBARI-13688
> URL: https://issues.apache.org/jira/browse/AMBARI-13688
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.1.3
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Critical
> Fix For: 2.2.0, 2.1.3
>
> Attachments: AMBARI-13688.trunk.patch
>
>
> Miscellaneous bug fixes for Express Upgrade in HDP 2.2->2.3 for Storm and 
> Knox.
> Storm: Unable to start service because the Storm dir in the local FS and in 
> Zookeeper znode need to be deleted exactly once per host.
> Deleting the local Storm dir was not working because the marker json file 
> needs to contain the upgrade direction instead of the stage id.
> Knox: simple change to the manual task message to correct the location of the 
> data dir, which should be /var/lib/knox/data



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

[jira] [Commented] (AMBARI-13723) Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13723:
-

FAILURE: Integrated in Ambari-branch-2.1 #802 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/802/])
AMBARI-13723. Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits 
(afernandez: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=1f5545766fd619c277fd830ec6f48e4d74035e42])
* ambari-server/src/main/resources/custom_actions/scripts/remove_bits.py
* 
ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml


> Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3
> 
>
> Key: AMBARI-13723
> URL: https://issues.apache.org/jira/browse/AMBARI-13723
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.1.3
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.2.0, 2.1.3
>
> Attachments: AMBARI-13723.trunk.patch
>
>
> We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, 
> "hadoop" bin still points to the old binary because we had to install HDP 2.3 
> while 2.1 bits still existed.
> *Manual Upgrade Instructions:*
> * Stop all services using 2.1
> * yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
> /usr/bin/hdfs, /usr/bin/hive, etc/)
> * yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, and hence MR Service Check passes with "hadoop" command
> *Express Upgrade:*
> * Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
> process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
> 2.1 bits
> * Stop all services using 2.1
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, will fail on MR Service Check because ExecuteHadoop() 
> resource calls "hadoop" command, which is still pointing to 2.1 bits!
> One solution is for the orchestration to remove the 2.1 bits before starting 
> using 2.3.
> Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
> "hdp-select set hadoop-client " it will create the symlink 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop



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

[jira] [Updated] (AMBARI-13729) Change the Spark thrift server security configurations

[Saisai Shao (JIRA)]

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

Saisai Shao updated AMBARI-13729:
-
Attachment: AMBARI-13729.patch

> Change the Spark thrift server security configurations
> --
>
> Key: AMBARI-13729
> URL: https://issues.apache.org/jira/browse/AMBARI-13729
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: trunk
>Reporter: Saisai Shao
> Fix For: trunk
>
> Attachments: AMBARI-13729.patch
>
>
> "hive.security.authorization.enabled" would be better changed to 
> "hive.server2.authentication". And "hive.server2.enable.doAs" is not well 
> supported currently.



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

[jira] [Created] (AMBARI-13729) Change the Spark thrift server security configurations

[Saisai Shao (JIRA)]

Saisai Shao created AMBARI-13729:


 Summary: Change the Spark thrift server security configurations
 Key: AMBARI-13729
 URL: https://issues.apache.org/jira/browse/AMBARI-13729
 Project: Ambari
  Issue Type: Bug
  Components: stacks
Affects Versions: trunk
Reporter: Saisai Shao


"hive.security.authorization.enabled" would be better changed to 
"hive.server2.authentication". And "hive.server2.enable.doAs" is not well 
supported currently.



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

[jira] [Commented] (AMBARI-13728) Fix Spark History server not work problem

[Saisai Shao (JIRA)]

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

Saisai Shao commented on AMBARI-13728:
--

Please help to review, this blocks the devdeploy.

> Fix Spark History server not work problem
> -
>
> Key: AMBARI-13728
> URL: https://issues.apache.org/jira/browse/AMBARI-13728
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: trunk
>Reporter: Saisai Shao
> Fix For: trunk
>
> Attachments: AMBARI-13728.patch
>
>
> While Spark bumps to 1.5.1, the classpath of history server is changed, the 
> definition in Ambari should be changed accordingly, otherwise it is failed to 
> start history server through Ambari.



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

[jira] [Updated] (AMBARI-13728) Fix Spark History server not work problem

[Saisai Shao (JIRA)]

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

Saisai Shao updated AMBARI-13728:
-
Attachment: AMBARI-13728.patch

> Fix Spark History server not work problem
> -
>
> Key: AMBARI-13728
> URL: https://issues.apache.org/jira/browse/AMBARI-13728
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: trunk
>Reporter: Saisai Shao
> Attachments: AMBARI-13728.patch
>
>
> While Spark bumps to 1.5.1, the classpath of history server is changed, the 
> definition in Ambari should be changed accordingly, otherwise it is failed to 
> start history server through Ambari.



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

[jira] [Commented] (AMBARI-13713) Ambari should restore tez.lib.uris to stack defaults when upgrading Tez

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-13713:


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

This message is automatically generated.

> Ambari should restore tez.lib.uris to stack defaults when upgrading Tez
> ---
>
> Key: AMBARI-13713
> URL: https://issues.apache.org/jira/browse/AMBARI-13713
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.1.3
>
> Attachments: AMBARI-13713.patch
>
>
> Customers apply hotfixes for Tez by modifying tez.lib.uris to point to a new 
> tez tarball to avoid affecting currently running jobs.
> When Ambari does an upgrade to a future version, this config should be 
> reverted to point to the newly uploaded tez tarball ( from the upgraded 
> version ).



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

[jira] [Created] (AMBARI-13728) Fix Spark History server not work problem

[Saisai Shao (JIRA)]

Saisai Shao created AMBARI-13728:


 Summary: Fix Spark History server not work problem
 Key: AMBARI-13728
 URL: https://issues.apache.org/jira/browse/AMBARI-13728
 Project: Ambari
  Issue Type: Bug
  Components: stacks
Affects Versions: trunk
Reporter: Saisai Shao


While Spark bumps to 1.5.1, the classpath of history server is changed, the 
definition in Ambari should be changed accordingly, otherwise it is failed to 
start history server through Ambari.



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

[jira] [Commented] (AMBARI-13650) Bump the Ambari Spark definition to Spark 1.5.1

[Saisai Shao (JIRA)]

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

Saisai Shao commented on AMBARI-13650:
--

Now the HDP trunk repo has bumped to Spark 1.5.1, I think the stack definition 
should also be updated, anyone please help to review? Thanks a lot.

> Bump the Ambari Spark definition to Spark 1.5.1
> ---
>
> Key: AMBARI-13650
> URL: https://issues.apache.org/jira/browse/AMBARI-13650
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Reporter: Saisai Shao
> Attachments: AMBARI-13650.patch
>
>
> Bump the version of Spark to 1.5.1 in Ambari stack definition, also remove 
> some obsolete configurations.



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

[jira] [Commented] (AMBARI-13717) Couldn`t start the most of services after upgrade from 2.1.2 to 2.1.3.0 (Debian7)

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13717:
-

FAILURE: Integrated in Ambari-trunk-Commit #3773 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3773/])
AMBARI-13717. Couldn`t start the most of services after upgrade from (aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=b841e95c4b9b656101b659efa5493fd3154208ae])
* 
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog213.java


> Couldn`t start the most of services after upgrade from 2.1.2 to 2.1.3.0 
> (Debian7)
> -
>
> Key: AMBARI-13717
> URL: https://issues.apache.org/jira/browse/AMBARI-13717
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.1.3
>
>
> STR:  
> 1)Deploy old version 2.1.2  
> 2)Make Ambari only upgrade to 2.1.3  
> 4)Try to start All services  
> Actual results:  
> Couldn`t start the most of services after upgrade (FALCON, FLUME,
> HISTORYSERVER, KNOX_GATEWAY, MC, NAMENODE, NM etc..)  
> **Details are in Last available request file - attached**



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

[jira] [Commented] (AMBARI-13722) Confusing message is shown when there are service check failures that have been skipped during RU

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13722:
-

FAILURE: Integrated in Ambari-trunk-Commit #3773 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3773/])
AMBARI-13722. Confusing message is shown when there are service check (ncole: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=da7d926e06dcced337d6f1c2a1d6746677fc586e])
* 
ambari-server/src/main/java/org/apache/ambari/server/metadata/ActionMetadata.java
* 
ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/AutoSkipFailedSummaryAction.java
* 
ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/AutoSkipFailedSummaryActionTest.java


> Confusing message is shown when there are service check failures that have 
> been skipped during RU
> -
>
> Key: AMBARI-13722
> URL: https://issues.apache.org/jira/browse/AMBARI-13722
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.3
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.1.3
>
> Attachments: AMBARI-13722.patch
>
>
> When failures are skipped in the Upgrade Wizard, there's a manual 
> confirmation step that is injected.
> {code}
> "Manual steps required"
> Verifying Skipped Failures
> [ ] I have performed the manual steps above.
> [Pause Upgrade] [Proceed]  <- [Downgrade] was missing, but that's a different 
> issue
> {code}
> This doesn't really make sense to the end user.
> So the full scope if this jira becomes changes to structuredOut to 
> incorporate auto-skipped detail (hosts and services/components) and failures 
> (hosts and services/components)
> {code}
> {
> "failures":{
> "service_check":[
> "ZOOKEEPER"
> ],
> "host_component":{
> "host1.vm":[
> {
> "component":"DATANODE"
> }
> ],
> "host2.vm":[
> {
> "component":"DATANODE"
> }
> ]
> }
> },
> "skipped":[
> "service_check",
> "host_component"
> ]
> }
> {code}



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

[jira] [Commented] (AMBARI-13708) RU/EU: invalid state transition, INSTALL_FAILED (cannot Finalize)

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13708:
-

FAILURE: Integrated in Ambari-trunk-Commit #3773 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3773/])
AMBARI-13708: RU/EU: invalid state transition, INSTALL_FAILED (cannot (jluniya: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=f859570ae8cedbff71986e5940f42bba195b9f2f])
* 
ambari-server/src/main/java/org/apache/ambari/server/checks/AbstractCheckDescriptor.java
* 
ambari-server/src/test/java/org/apache/ambari/server/state/CheckHelperTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
* 
ambari-server/src/main/java/org/apache/ambari/server/checks/ComponentsInstallationCheck.java
* 
ambari-server/src/test/java/org/apache/ambari/server/checks/InstallPackagesCheckTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/checks/InstallPackagesCheck.java
* 
ambari-server/src/main/java/org/apache/ambari/server/checks/CheckDescription.java
* 
ambari-server/src/test/java/org/apache/ambari/server/checks/ComponentsInstallationCheckTest.java


> RU/EU: invalid state transition, INSTALL_FAILED (cannot Finalize)
> -
>
> Key: AMBARI-13708
> URL: https://issues.apache.org/jira/browse/AMBARI-13708
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: AMBARI-13708.patch
>
>
> Steps to reproduce:
> # Put some unhealthy hosts to MM
> # Start Rolling Upgrade
> # Proceed to "Check Unhealthy Hosts" step
> # Delete host in unhealthy state
> # Proceed to Finalize Upgrade
> # Finalize Upgrade fails
> Root Cause: 
> This is because cluster version remains in INSTALL_FAILED state



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

[jira] [Commented] (AMBARI-13279) Pig view shows completed but does not state if anything went wrong

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13279:
-

FAILURE: Integrated in Ambari-trunk-Commit #3773 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3773/])
AMBARI-13279. Pig view shows completed but does not state if anything 
(sgunturi: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=943323fc613e7b3a81a37d1814fcb19963de9485])
* contrib/views/pig/src/main/resources/ui/pig-web/app/templates/script/job.hbs
* contrib/views/pig/src/main/resources/ui/pig-web/app/styles/style.less
* contrib/views/pig/src/main/resources/ui/pig-web/app/controllers/pig.js
* contrib/views/pig/src/main/resources/ui/pig-web/app/initialize.js
* 
contrib/views/pig/src/main/resources/ui/pig-web/app/components/highlightErrors.js
* contrib/views/pig/src/main/resources/ui/pig-web/app/views/pig/alert.js
* contrib/views/pig/src/main/resources/ui/pig-web/app/controllers/pigAlert.js
* contrib/views/pig/src/main/resources/ui/pig-web/app/controllers/scriptJob.js
* contrib/views/pig/src/main/resources/ui/pig-web/app/controllers/pigScripts.js
* contrib/views/pig/src/main/resources/ui/pig-web/app/views/script/job.js


> Pig view shows completed but does not state if anything went wrong
> --
>
> Key: AMBARI-13279
> URL: https://issues.apache.org/jira/browse/AMBARI-13279
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.1.0
>Reporter: Nitiraj Singh Rathore
>Assignee: Nitiraj Singh Rathore
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: AMBARI-13279_branch-2.1.patch
>
>
> Lets say there was some error while executing pig script. In this case the 
> status appears as "Completed" (in green color) and Results is empty and the 
> Log includes the exception that occurred.
> So there is no visual cue to show if there was error and because of it the 
> result set is empty.
> To Reproduce : Include a HCatalog statement in the pig script and run it with 
> the -useHCatalog argument. 
> Example :
> a = LOAD 'someHiveTable' USING org.apache.hive.hcatalog.pig.HCatLoader();
> dump a;
> Executing this without -useHCatalog will create an exception, which will 
> appear in logs but the result will be empty and status will appear as 
> completed. So it is not clear that some exception occurred.



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

[jira] [Commented] (AMBARI-13722) Confusing message is shown when there are service check failures that have been skipped during RU

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13722:
-

FAILURE: Integrated in Ambari-branch-2.1 #801 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/801/])
AMBARI-13722. Confusing message is shown when there are service check (ncole: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=36681a57e8cbda3ce9530e49e90426df6a91e2ef])
* 
ambari-server/src/main/java/org/apache/ambari/server/metadata/ActionMetadata.java
* 
ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/AutoSkipFailedSummaryActionTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/AutoSkipFailedSummaryAction.java


> Confusing message is shown when there are service check failures that have 
> been skipped during RU
> -
>
> Key: AMBARI-13722
> URL: https://issues.apache.org/jira/browse/AMBARI-13722
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.3
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.1.3
>
> Attachments: AMBARI-13722.patch
>
>
> When failures are skipped in the Upgrade Wizard, there's a manual 
> confirmation step that is injected.
> {code}
> "Manual steps required"
> Verifying Skipped Failures
> [ ] I have performed the manual steps above.
> [Pause Upgrade] [Proceed]  <- [Downgrade] was missing, but that's a different 
> issue
> {code}
> This doesn't really make sense to the end user.
> So the full scope if this jira becomes changes to structuredOut to 
> incorporate auto-skipped detail (hosts and services/components) and failures 
> (hosts and services/components)
> {code}
> {
> "failures":{
> "service_check":[
> "ZOOKEEPER"
> ],
> "host_component":{
> "host1.vm":[
> {
> "component":"DATANODE"
> }
> ],
> "host2.vm":[
> {
> "component":"DATANODE"
> }
> ]
> }
> },
> "skipped":[
> "service_check",
> "host_component"
> ]
> }
> {code}



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

[jira] [Commented] (AMBARI-13279) Pig view shows completed but does not state if anything went wrong

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13279:
-

FAILURE: Integrated in Ambari-branch-2.1 #801 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/801/])
AMBARI-13279. Pig view shows completed but does not state if anything 
(sgunturi: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=d9f468ce644c67c0d15a4f53768e81298abd2e93])
* contrib/views/pig/src/main/resources/ui/pig-web/app/controllers/scriptJob.js
* contrib/views/pig/src/main/resources/ui/pig-web/app/views/pig/alert.js
* contrib/views/pig/src/main/resources/ui/pig-web/app/controllers/pigScripts.js
* contrib/views/pig/src/main/resources/ui/pig-web/app/controllers/pigAlert.js
* contrib/views/pig/src/main/resources/ui/pig-web/app/templates/script/job.hbs
* 
contrib/views/pig/src/main/resources/ui/pig-web/app/components/highlightErrors.js
* contrib/views/pig/src/main/resources/ui/pig-web/app/styles/style.less
* contrib/views/pig/src/main/resources/ui/pig-web/app/controllers/pig.js
* contrib/views/pig/src/main/resources/ui/pig-web/app/views/script/job.js
* contrib/views/pig/src/main/resources/ui/pig-web/app/initialize.js


> Pig view shows completed but does not state if anything went wrong
> --
>
> Key: AMBARI-13279
> URL: https://issues.apache.org/jira/browse/AMBARI-13279
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.1.0
>Reporter: Nitiraj Singh Rathore
>Assignee: Nitiraj Singh Rathore
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: AMBARI-13279_branch-2.1.patch
>
>
> Lets say there was some error while executing pig script. In this case the 
> status appears as "Completed" (in green color) and Results is empty and the 
> Log includes the exception that occurred.
> So there is no visual cue to show if there was error and because of it the 
> result set is empty.
> To Reproduce : Include a HCatalog statement in the pig script and run it with 
> the -useHCatalog argument. 
> Example :
> a = LOAD 'someHiveTable' USING org.apache.hive.hcatalog.pig.HCatLoader();
> dump a;
> Executing this without -useHCatalog will create an exception, which will 
> appear in logs but the result will be empty and status will appear as 
> completed. So it is not clear that some exception occurred.



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

[jira] [Commented] (AMBARI-13708) RU/EU: invalid state transition, INSTALL_FAILED (cannot Finalize)

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13708:
-

FAILURE: Integrated in Ambari-branch-2.1 #801 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/801/])
AMBARI-13708: RU/EU: invalid state transition, INSTALL_FAILED (cannot (jluniya: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=d0c0a5edf4a39d11bbba1a6027d900d377470a3f])
* 
ambari-server/src/main/java/org/apache/ambari/server/checks/AbstractCheckDescriptor.java
* 
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
* 
ambari-server/src/test/java/org/apache/ambari/server/state/CheckHelperTest.java
* 
ambari-server/src/test/java/org/apache/ambari/server/checks/InstallPackagesCheckTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/checks/InstallPackagesCheck.java
* 
ambari-server/src/main/java/org/apache/ambari/server/checks/CheckDescription.java
* 
ambari-server/src/test/java/org/apache/ambari/server/checks/ComponentsInstallationCheckTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/checks/ComponentsInstallationCheck.java


> RU/EU: invalid state transition, INSTALL_FAILED (cannot Finalize)
> -
>
> Key: AMBARI-13708
> URL: https://issues.apache.org/jira/browse/AMBARI-13708
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: AMBARI-13708.patch
>
>
> Steps to reproduce:
> # Put some unhealthy hosts to MM
> # Start Rolling Upgrade
> # Proceed to "Check Unhealthy Hosts" step
> # Delete host in unhealthy state
> # Proceed to Finalize Upgrade
> # Finalize Upgrade fails
> Root Cause: 
> This is because cluster version remains in INSTALL_FAILED state



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

[jira] [Commented] (AMBARI-13717) Couldn`t start the most of services after upgrade from 2.1.2 to 2.1.3.0 (Debian7)

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13717:
-

FAILURE: Integrated in Ambari-branch-2.1 #801 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/801/])
AMBARI-13717. Couldn`t start the most of services after upgrade from (aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=b90a7e33c74c86d7263cc6059f466378fb2f6329])
* 
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog213.java


> Couldn`t start the most of services after upgrade from 2.1.2 to 2.1.3.0 
> (Debian7)
> -
>
> Key: AMBARI-13717
> URL: https://issues.apache.org/jira/browse/AMBARI-13717
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.1.3
>
>
> STR:  
> 1)Deploy old version 2.1.2  
> 2)Make Ambari only upgrade to 2.1.3  
> 4)Try to start All services  
> Actual results:  
> Couldn`t start the most of services after upgrade (FALCON, FLUME,
> HISTORYSERVER, KNOX_GATEWAY, MC, NAMENODE, NM etc..)  
> **Details are in Last available request file - attached**



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

[jira] [Resolved] (AMBARI-13688) Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 2.2->2.3

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez resolved AMBARI-13688.
--
Resolution: Fixed

Pushed to trunk,
commit efca65bfff18c8fe1340d5923a91726121359d93

Pushed to branch-2.1,
commit 81b912a9525ac788d8b747b54b8bd12a53ef7976

> Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 2.2->2.3
> --
>
> Key: AMBARI-13688
> URL: https://issues.apache.org/jira/browse/AMBARI-13688
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.1.3
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Critical
> Fix For: 2.2.0, 2.1.3
>
> Attachments: AMBARI-13688.trunk.patch
>
>
> Miscellaneous bug fixes for Express Upgrade in HDP 2.2->2.3 for Storm and 
> Knox.
> Storm: Unable to start service because the Storm dir in the local FS and in 
> Zookeeper znode need to be deleted exactly once per host.
> Deleting the local Storm dir was not working because the marker json file 
> needs to contain the upgrade direction instead of the stage id.
> Knox: simple change to the manual task message to correct the location of the 
> data dir, which should be /var/lib/knox/data



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

[jira] [Updated] (AMBARI-13725) HAWQ and PXF to support 3 digit versioning than 4.

[jun aoki (JIRA)]

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

jun aoki updated AMBARI-13725:
--
Attachment: AMBARI-13725.patch

> HAWQ and PXF to support 3 digit versioning than 4.
> --
>
> Key: AMBARI-13725
> URL: https://issues.apache.org/jira/browse/AMBARI-13725
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: trunk
>Reporter: jun aoki
>Assignee: jun aoki
>Priority: Minor
> Fix For: trunk
>
> Attachments: AMBARI-13725.patch
>
>
> HAWQ and PXF are going to support 3 digit versioning.
> Currently our trunk has their service definitions but are 4 digits.
> This ticket is to adjust it.



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

Re: Review Request 39926: AMBARI-13688. Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 2.2->2.3

[Alejandro Fernandez]

> On Nov. 4, 2015, 7:23 p.m., Jayush Luniya wrote:
> > ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/config-upgrade.xml,
> >  line 748
> > 
> >
> > :( Very hard to read

I tried this and got an error since CDATA cannot be used inside values.
http://stackoverflow.com/questions/2546640/cdata-for-a-value-in-xml


- Alejandro


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


On Nov. 5, 2015, 12:29 a.m., Alejandro Fernandez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39926/
> ---
> 
> (Updated Nov. 5, 2015, 12:29 a.m.)
> 
> 
> Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, Jonathan 
> Hurley, Jayush Luniya, Nate Cole, and Swapan Shridhar.
> 
> 
> Bugs: AMBARI-13688
> https://issues.apache.org/jira/browse/AMBARI-13688
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Miscellaneous bug fixes for Express Upgrade in HDP 2.2->2.3 for Storm and 
> Knox.
> 
> Storm: Unable to start service because the Storm dir in the local FS and in 
> Zookeeper znode need to be deleted exactly once per host.
> Deleting the local Storm dir was not working because the marker json file 
> needs to contain the upgrade direction instead of the stage id.
> 
> Knox: simple change to the manual task message to correct the location of the 
> data dir, which should be /var/lib/knox/data
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/params_linux.py
>  86de2ec 
>   
> ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/storm_upgrade.py
>  d10e7dc 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.2.xml
>  69be963 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml
>  06e5859 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
> 645ec0d 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/config-upgrade.xml 
> 8b170e6 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
>  016bad6 
> 
> Diff: https://reviews.apache.org/r/39926/diff/
> 
> 
> Testing
> ---
> 
> Tested during Express Upgrade.
> Unit tests passed,
> 
> --
> Total run:827
> Total errors:0
> Total failures:0
> 
> 
> Thanks,
> 
> Alejandro Fernandez
> 
>

[jira] [Updated] (AMBARI-13725) HAWQ and PXF to support 3 digit versioning instead of 4.

[jun aoki (JIRA)]

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

jun aoki updated AMBARI-13725:
--
Summary: HAWQ and PXF to support 3 digit versioning instead of 4.  (was: 
HAWQ and PXF to support 3 digit versioning than 4.)

> HAWQ and PXF to support 3 digit versioning instead of 4.
> 
>
> Key: AMBARI-13725
> URL: https://issues.apache.org/jira/browse/AMBARI-13725
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: trunk
>Reporter: jun aoki
>Assignee: jun aoki
>Priority: Minor
> Fix For: trunk
>
> Attachments: AMBARI-13725.patch
>
>
> HAWQ and PXF are going to support 3 digit versioning.
> Currently our trunk has their service definitions but are 4 digits.
> This ticket is to adjust it.



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

Re: Review Request 39926: AMBARI-13688. Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 2.2->2.3

[Alejandro Fernandez]

> On Nov. 4, 2015, 3:43 p.m., Nate Cole wrote:
> > ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/config-upgrade.xml,
> >  lines 734-752
> > 
> >
> > Out of curiosity, Can we use a  block here?  Escaping 
> > this much is a bit hard to read.
> 
> Alejandro Fernandez wrote:
> Will try.

I tried this and got an error since CDATA cannot be used inside values.
http://stackoverflow.com/questions/2546640/cdata-for-a-value-in-xml


- Alejandro


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


On Nov. 5, 2015, 12:29 a.m., Alejandro Fernandez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39926/
> ---
> 
> (Updated Nov. 5, 2015, 12:29 a.m.)
> 
> 
> Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, Jonathan 
> Hurley, Jayush Luniya, Nate Cole, and Swapan Shridhar.
> 
> 
> Bugs: AMBARI-13688
> https://issues.apache.org/jira/browse/AMBARI-13688
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Miscellaneous bug fixes for Express Upgrade in HDP 2.2->2.3 for Storm and 
> Knox.
> 
> Storm: Unable to start service because the Storm dir in the local FS and in 
> Zookeeper znode need to be deleted exactly once per host.
> Deleting the local Storm dir was not working because the marker json file 
> needs to contain the upgrade direction instead of the stage id.
> 
> Knox: simple change to the manual task message to correct the location of the 
> data dir, which should be /var/lib/knox/data
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/params_linux.py
>  86de2ec 
>   
> ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/storm_upgrade.py
>  d10e7dc 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.2.xml
>  69be963 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml
>  06e5859 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
> 645ec0d 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/config-upgrade.xml 
> 8b170e6 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
>  016bad6 
> 
> Diff: https://reviews.apache.org/r/39926/diff/
> 
> 
> Testing
> ---
> 
> Tested during Express Upgrade.
> Unit tests passed,
> 
> --
> Total run:827
> Total errors:0
> Total failures:0
> 
> 
> Thanks,
> 
> Alejandro Fernandez
> 
>

[jira] [Updated] (AMBARI-13688) Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 2.2->2.3

[Alejandro Fernandez (JIRA)]

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

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

> Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 2.2->2.3
> --
>
> Key: AMBARI-13688
> URL: https://issues.apache.org/jira/browse/AMBARI-13688
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.1.3
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Critical
> Fix For: 2.2.0, 2.1.3
>
> Attachments: AMBARI-13688.trunk.patch
>
>
> Miscellaneous bug fixes for Express Upgrade in HDP 2.2->2.3 for Storm and 
> Knox.
> Storm: Unable to start service because the Storm dir in the local FS and in 
> Zookeeper znode need to be deleted exactly once per host.
> Deleting the local Storm dir was not working because the marker json file 
> needs to contain the upgrade direction instead of the stage id.
> Knox: simple change to the manual task message to correct the location of the 
> data dir, which should be /var/lib/knox/data



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

[jira] [Updated] (AMBARI-13688) Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 2.2->2.3

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-13688:
-
Attachment: AMBARI-13688.trunk.patch

> Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 2.2->2.3
> --
>
> Key: AMBARI-13688
> URL: https://issues.apache.org/jira/browse/AMBARI-13688
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.1.3
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Critical
> Fix For: 2.2.0, 2.1.3
>
> Attachments: AMBARI-13688.trunk.patch
>
>
> Miscellaneous bug fixes for Express Upgrade in HDP 2.2->2.3 for Storm and 
> Knox.
> Storm: Unable to start service because the Storm dir in the local FS and in 
> Zookeeper znode need to be deleted exactly once per host.
> Deleting the local Storm dir was not working because the marker json file 
> needs to contain the upgrade direction instead of the stage id.
> Knox: simple change to the manual task message to correct the location of the 
> data dir, which should be /var/lib/knox/data



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

Re: Review Request 39926: AMBARI-13688. Stop-and-Start Upgrade: Misc fixes for Storm, Knox in HDP 2.2->2.3

[Alejandro Fernandez]

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

(Updated Nov. 5, 2015, 12:29 a.m.)


Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, Jonathan 
Hurley, Jayush Luniya, Nate Cole, and Swapan Shridhar.


Changes
---

Removed changes for unit tests.


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


Repository: ambari


Description
---

Miscellaneous bug fixes for Express Upgrade in HDP 2.2->2.3 for Storm and Knox.

Storm: Unable to start service because the Storm dir in the local FS and in 
Zookeeper znode need to be deleted exactly once per host.
Deleting the local Storm dir was not working because the marker json file needs 
to contain the upgrade direction instead of the stage id.

Knox: simple change to the manual task message to correct the location of the 
data dir, which should be /var/lib/knox/data


Diffs (updated)
-

  
ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/params_linux.py
 86de2ec 
  
ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/storm_upgrade.py
 d10e7dc 
  
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.2.xml
 69be963 
  
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml
 06e5859 
  ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
645ec0d 
  ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/config-upgrade.xml 
8b170e6 
  
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
 016bad6 

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


Testing
---

Tested during Express Upgrade.
Unit tests passed,

--
Total run:827
Total errors:0
Total failures:0


Thanks,

Alejandro Fernandez

[jira] [Commented] (AMBARI-13727) Update Ambari 1.8 JDK build number to 1.8u60

[Siddharth Wagle (JIRA)]

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

Siddharth Wagle commented on AMBARI-13727:
--

+1

> Update Ambari 1.8 JDK build number to 1.8u60
> 
>
> Key: AMBARI-13727
> URL: https://issues.apache.org/jira/browse/AMBARI-13727
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Srimanth Gunturi
>Assignee: Srimanth Gunturi
> Fix For: 2.1.3
>
> Attachments: AMBARI-13727.patch
>
>
> Ambari uses JDK 1.8u40 build which has the following bug:
> [https://bugs.openjdk.java.net/browse/JDK-8078439]. This is a negotiation bug 
> that prevents properly configured web browsers on windows hosts from 
> accessing kerberized APIs if HDP 2.3 is installed with the JDK 1.8u40 which 
> we provide.  We should update this to the current JDK which is 1.8u60 on 
> Oracle's site, which I have had one customer already confirm does not have 
> this issue.



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

[jira] [Commented] (AMBARI-13705) Metrics Cache sizing test failing on trunk

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-13705:


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

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

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

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

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

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

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

This message is automatically generated.

> Metrics Cache sizing test failing on trunk
> --
>
> Key: AMBARI-13705
> URL: https://issues.apache.org/jira/browse/AMBARI-13705
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.3
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
> Fix For: 2.1.3
>
> Attachments: AMBARI-13705.patch
>
>
> org.apache.ambari.server.controller.metrics.timeline.cache.TimelineMetricCacheSizingTest#testTimelineMetricCacheSizing
>  fails on apache infra only.



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

[jira] [Commented] (AMBARI-13727) Update Ambari 1.8 JDK build number to 1.8u60

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez commented on AMBARI-13727:
--

+1 on patch

> Update Ambari 1.8 JDK build number to 1.8u60
> 
>
> Key: AMBARI-13727
> URL: https://issues.apache.org/jira/browse/AMBARI-13727
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Srimanth Gunturi
>Assignee: Srimanth Gunturi
> Fix For: 2.1.3
>
> Attachments: AMBARI-13727.patch
>
>
> Ambari uses JDK 1.8u40 build which has the following bug:
> [https://bugs.openjdk.java.net/browse/JDK-8078439]. This is a negotiation bug 
> that prevents properly configured web browsers on windows hosts from 
> accessing kerberized APIs if HDP 2.3 is installed with the JDK 1.8u40 which 
> we provide.  We should update this to the current JDK which is 1.8u60 on 
> Oracle's site, which I have had one customer already confirm does not have 
> this issue.



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

[jira] [Commented] (AMBARI-13726) xa_ldap_ad_domain not found under Advanced tab when authentication method is set to AD

[Srimanth Gunturi (JIRA)]

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

Srimanth Gunturi commented on AMBARI-13726:
---

+1 for patch

> xa_ldap_ad_domain not found under Advanced tab when authentication method is 
> set to AD
> --
>
> Key: AMBARI-13726
> URL: https://issues.apache.org/jira/browse/AMBARI-13726
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, stacks
>Affects Versions: 2.1.3
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
> Fix For: 2.1.3
>
> Attachments: AMBARI-13726.patch
>
>
> The config *xa_ldap_ad_domain* was mentioned in themes.json file by mistake 
> without any widget declaration. This made the config invisible on themes tab 
> and Advanced tab



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

[jira] [Updated] (AMBARI-13726) xa_ldap_ad_domain not found under Advanced tab when authentication method is set to AD

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-13726:

Description: The config *xa_ldap_ad_domain* was mentioned in themes.json 
file by mistake without any widget declaration. This made the config invisible 
on themes tab and Advanced tab  (was: The con)

> xa_ldap_ad_domain not found under Advanced tab when authentication method is 
> set to AD
> --
>
> Key: AMBARI-13726
> URL: https://issues.apache.org/jira/browse/AMBARI-13726
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, stacks
>Affects Versions: 2.1.3
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
> Fix For: 2.1.3
>
> Attachments: AMBARI-13726.patch
>
>
> The config *xa_ldap_ad_domain* was mentioned in themes.json file by mistake 
> without any widget declaration. This made the config invisible on themes tab 
> and Advanced tab



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

[jira] [Updated] (AMBARI-13726) xa_ldap_ad_domain not found under Advanced tab when authentication method is set to AD

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-13726:

Description: The con

> xa_ldap_ad_domain not found under Advanced tab when authentication method is 
> set to AD
> --
>
> Key: AMBARI-13726
> URL: https://issues.apache.org/jira/browse/AMBARI-13726
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, stacks
>Affects Versions: 2.1.3
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
> Fix For: 2.1.3
>
> Attachments: AMBARI-13726.patch
>
>
> The con



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

[jira] [Commented] (AMBARI-13726) xa_ldap_ad_domain not found under Advanced tab when authentication method is set to AD

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly commented on AMBARI-13726:
-

Tested the patch manually to work on a cluster

> xa_ldap_ad_domain not found under Advanced tab when authentication method is 
> set to AD
> --
>
> Key: AMBARI-13726
> URL: https://issues.apache.org/jira/browse/AMBARI-13726
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, stacks
>Affects Versions: 2.1.3
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
> Fix For: 2.1.3
>
> Attachments: AMBARI-13726.patch
>
>




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

[jira] [Updated] (AMBARI-13727) Update Ambari 1.8 JDK build number to 1.8u60

[Srimanth Gunturi (JIRA)]

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

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

> Update Ambari 1.8 JDK build number to 1.8u60
> 
>
> Key: AMBARI-13727
> URL: https://issues.apache.org/jira/browse/AMBARI-13727
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Srimanth Gunturi
>Assignee: Srimanth Gunturi
> Fix For: 2.1.3
>
> Attachments: AMBARI-13727.patch
>
>
> Ambari uses JDK 1.8u40 build which has the following bug:
> [https://bugs.openjdk.java.net/browse/JDK-8078439]. This is a negotiation bug 
> that prevents properly configured web browsers on windows hosts from 
> accessing kerberized APIs if HDP 2.3 is installed with the JDK 1.8u40 which 
> we provide.  We should update this to the current JDK which is 1.8u60 on 
> Oracle's site, which I have had one customer already confirm does not have 
> this issue.



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

[jira] [Updated] (AMBARI-13726) xa_ldap_ad_domain not found under Advanced tab when authentication method is set to AD

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-13726:

Attachment: AMBARI-13726.patch

> xa_ldap_ad_domain not found under Advanced tab when authentication method is 
> set to AD
> --
>
> Key: AMBARI-13726
> URL: https://issues.apache.org/jira/browse/AMBARI-13726
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, stacks
>Affects Versions: 2.1.3
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
> Fix For: 2.1.3
>
> Attachments: AMBARI-13726.patch
>
>




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

[jira] [Updated] (AMBARI-13727) Update Ambari 1.8 JDK build number to 1.8u60

[Srimanth Gunturi (JIRA)]

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

Srimanth Gunturi updated AMBARI-13727:
--
Summary: Update Ambari 1.8 JDK build number to 1.8u60  (was: Update Ambari 
1.8 JDK build number)

> Update Ambari 1.8 JDK build number to 1.8u60
> 
>
> Key: AMBARI-13727
> URL: https://issues.apache.org/jira/browse/AMBARI-13727
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Srimanth Gunturi
>Assignee: Srimanth Gunturi
> Fix For: 2.1.3
>
>
> Ambari uses JDK 1.8u40 build which has the following bug:
> [https://bugs.openjdk.java.net/browse/JDK-8078439]. This is a negotiation bug 
> that prevents properly configured web browsers on windows hosts from 
> accessing kerberized APIs if HDP 2.3 is installed with the JDK 1.8u40 which 
> we provide.  We should update this to the current JDK which is 1.8u60 on 
> Oracle's site, which I have had one customer already confirm does not have 
> this issue.



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

[jira] [Created] (AMBARI-13727) Update Ambari 1.8 JDK build number

[Srimanth Gunturi (JIRA)]

Srimanth Gunturi created AMBARI-13727:
-

 Summary: Update Ambari 1.8 JDK build number
 Key: AMBARI-13727
 URL: https://issues.apache.org/jira/browse/AMBARI-13727
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.1.2
Reporter: Srimanth Gunturi
Assignee: Srimanth Gunturi
 Fix For: 2.1.3


Ambari uses JDK 1.8u40 build which has the following bug:
[https://bugs.openjdk.java.net/browse/JDK-8078439]. This is a negotiation bug 
that prevents properly configured web browsers on windows hosts from accessing 
kerberized APIs if HDP 2.3 is installed with the JDK 1.8u40 which we provide.  
We should update this to the current JDK which is 1.8u60 on Oracle's site, 
which I have had one customer already confirm does not have this issue.



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

[jira] [Created] (AMBARI-13726) xa_ldap_ad_domain not found under Advanced tab when authentication method is set to AD

[Jaimin D Jetly (JIRA)]

Jaimin D Jetly created AMBARI-13726:
---

 Summary: xa_ldap_ad_domain not found under Advanced tab when 
authentication method is set to AD
 Key: AMBARI-13726
 URL: https://issues.apache.org/jira/browse/AMBARI-13726
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server, stacks
Affects Versions: 2.1.3
Reporter: Jaimin D Jetly
Assignee: Jaimin D Jetly
 Fix For: 2.1.3






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

[jira] [Updated] (AMBARI-13705) Metrics Cache sizing test failing on trunk

[Siddharth Wagle (JIRA)]

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

Siddharth Wagle updated AMBARI-13705:
-
Attachment: AMBARI-13705.patch

> Metrics Cache sizing test failing on trunk
> --
>
> Key: AMBARI-13705
> URL: https://issues.apache.org/jira/browse/AMBARI-13705
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.3
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
> Fix For: 2.1.3
>
> Attachments: AMBARI-13705.patch
>
>
> org.apache.ambari.server.controller.metrics.timeline.cache.TimelineMetricCacheSizingTest#testTimelineMetricCacheSizing
>  fails on apache infra only.



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

[jira] [Updated] (AMBARI-13705) Metrics Cache sizing test failing on trunk

[Siddharth Wagle (JIRA)]

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

Siddharth Wagle updated AMBARI-13705:
-
Attachment: (was: AMBARI-13705.patch)

> Metrics Cache sizing test failing on trunk
> --
>
> Key: AMBARI-13705
> URL: https://issues.apache.org/jira/browse/AMBARI-13705
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.3
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
> Fix For: 2.1.3
>
>
> org.apache.ambari.server.controller.metrics.timeline.cache.TimelineMetricCacheSizingTest#testTimelineMetricCacheSizing
>  fails on apache infra only.



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

[jira] [Updated] (AMBARI-13725) HAWQ and PXF to support 3 digit versioning than 4.

[jun aoki (JIRA)]

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

jun aoki updated AMBARI-13725:
--
Affects Version/s: trunk

> HAWQ and PXF to support 3 digit versioning than 4.
> --
>
> Key: AMBARI-13725
> URL: https://issues.apache.org/jira/browse/AMBARI-13725
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: trunk
>Reporter: jun aoki
>Assignee: jun aoki
> Fix For: trunk
>
>
> HAWQ and PXF are going to support 3 digit versioning.
> Currently our trunk has their service definitions but are 4 digits.
> This ticket is to adjust it.



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

[jira] [Updated] (AMBARI-13725) HAWQ and PXF to support 3 digit versioning than 4.

[jun aoki (JIRA)]

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

jun aoki updated AMBARI-13725:
--
Fix Version/s: trunk

> HAWQ and PXF to support 3 digit versioning than 4.
> --
>
> Key: AMBARI-13725
> URL: https://issues.apache.org/jira/browse/AMBARI-13725
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: trunk
>Reporter: jun aoki
>Assignee: jun aoki
> Fix For: trunk
>
>
> HAWQ and PXF are going to support 3 digit versioning.
> Currently our trunk has their service definitions but are 4 digits.
> This ticket is to adjust it.



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

[jira] [Updated] (AMBARI-13725) HAWQ and PXF to support 3 digit versioning than 4.

[jun aoki (JIRA)]

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

jun aoki updated AMBARI-13725:
--
Priority: Minor  (was: Major)

> HAWQ and PXF to support 3 digit versioning than 4.
> --
>
> Key: AMBARI-13725
> URL: https://issues.apache.org/jira/browse/AMBARI-13725
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: trunk
>Reporter: jun aoki
>Assignee: jun aoki
>Priority: Minor
> Fix For: trunk
>
>
> HAWQ and PXF are going to support 3 digit versioning.
> Currently our trunk has their service definitions but are 4 digits.
> This ticket is to adjust it.



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

[jira] [Created] (AMBARI-13725) HAWQ and PXF to support 3 digit versioning than 4.

[jun aoki (JIRA)]

jun aoki created AMBARI-13725:
-

 Summary: HAWQ and PXF to support 3 digit versioning than 4.
 Key: AMBARI-13725
 URL: https://issues.apache.org/jira/browse/AMBARI-13725
 Project: Ambari
  Issue Type: Bug
Reporter: jun aoki
Assignee: jun aoki


HAWQ and PXF are going to support 3 digit versioning.

Currently our trunk has their service definitions but are 4 digits.
This ticket is to adjust it.



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

Re: Review Request 39955: AMBARI-13723. Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Alejandro Fernandez]

> On Nov. 4, 2015, 11 p.m., Jayush Luniya wrote:
> > ambari-server/src/main/resources/custom_actions/scripts/remove_bits.py, 
> > line 46
> > 
> >
> > Instead of hardcoding the list of packages, cant we build the list of 
> > packages similar to how we do for Install Packages from the stack 
> > definition? That way it would work for all OSes.

We don't have a very good way of doing this right now, since it would involve a 
custom command to pass in configs.
For the time being, this works. Closing this issue.


- Alejandro


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


On Nov. 4, 2015, 11:25 p.m., Alejandro Fernandez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39955/
> ---
> 
> (Updated Nov. 4, 2015, 11:25 p.m.)
> 
> 
> Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, Jayush 
> Luniya, Nate Cole, and Swapan Shridhar.
> 
> 
> Bugs: AMBARI-13723
> https://issues.apache.org/jira/browse/AMBARI-13723
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, 
> "hadoop" bin still points to the old binary because we had to install HDP 2.3 
> while 2.1 bits still existed.
> 
> **Manual Upgrade Instructions:**
> 
> * Stop all services using 2.1
> * yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
> /usr/bin/hdfs, /usr/bin/hive, etc/)
> * yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, and hence MR Service Check passes with "hadoop" command
> 
> **Express Upgrade:**
> 
> * Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
> process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
> 2.1 bits
> * Stop all services using 2.1
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, will fail on MR Service Check because ExecuteHadoop() 
> resource calls "hadoop" command, which is still pointing to 2.1 bits!
> 
> One solution is for the orchestration to remove the 2.1 bits before starting 
> using 2.3.
> Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
> "hdp-select set hadoop-client " it will create the symlink 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop
> 
> 
> Diffs
> -
> 
>   ambari-server/src/main/resources/custom_actions/scripts/remove_bits.py 
> PRE-CREATION 
>   
> ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
>  91d4f64 
> 
> Diff: https://reviews.apache.org/r/39955/diff/
> 
> 
> Testing
> ---
> 
> Verified during Express Upgrade from HDP 2.1->2.3
> 
> 
> Thanks,
> 
> Alejandro Fernandez
> 
>

Re: Review Request 39955: AMBARI-13723. Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Alejandro Fernandez]

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

(Updated Nov. 4, 2015, 11:25 p.m.)


Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, Jayush Luniya, 
Nate Cole, and Swapan Shridhar.


Changes
---

Changed text message.


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


Repository: ambari


Description
---

We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, "hadoop" 
bin still points to the old binary because we had to install HDP 2.3 while 2.1 
bits still existed.

**Manual Upgrade Instructions:**

* Stop all services using 2.1
* yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
/usr/bin/hdfs, /usr/bin/hive, etc/)
* yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
/usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
* Change the version to 2.3 (hdp-select, conf-select, etc.)
* Start all services, and hence MR Service Check passes with "hadoop" command

**Express Upgrade:**

* Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
2.1 bits
* Stop all services using 2.1
* Change the version to 2.3 (hdp-select, conf-select, etc.)
* Start all services, will fail on MR Service Check because ExecuteHadoop() 
resource calls "hadoop" command, which is still pointing to 2.1 bits!

One solution is for the orchestration to remove the 2.1 bits before starting 
using 2.3.
Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
"hdp-select set hadoop-client " it will create the symlink 
/usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop


Diffs (updated)
-

  ambari-server/src/main/resources/custom_actions/scripts/remove_bits.py 
PRE-CREATION 
  
ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
 91d4f64 

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


Testing
---

Verified during Express Upgrade from HDP 2.1->2.3


Thanks,

Alejandro Fernandez

Re: Review Request 39955: AMBARI-13723. Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Jayush Luniya]

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



ambari-server/src/main/resources/custom_actions/scripts/remove_bits.py (line 46)


Instead of hardcoding the list of packages, cant we build the list of 
packages similar to how we do for Install Packages from the stack definition? 
That way it would work for all OSes.


- Jayush Luniya


On Nov. 4, 2015, 10:38 p.m., Alejandro Fernandez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39955/
> ---
> 
> (Updated Nov. 4, 2015, 10:38 p.m.)
> 
> 
> Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, Jayush 
> Luniya, Nate Cole, and Swapan Shridhar.
> 
> 
> Bugs: AMBARI-13723
> https://issues.apache.org/jira/browse/AMBARI-13723
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, 
> "hadoop" bin still points to the old binary because we had to install HDP 2.3 
> while 2.1 bits still existed.
> 
> **Manual Upgrade Instructions:**
> 
> * Stop all services using 2.1
> * yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
> /usr/bin/hdfs, /usr/bin/hive, etc/)
> * yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, and hence MR Service Check passes with "hadoop" command
> 
> **Express Upgrade:**
> 
> * Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
> process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
> 2.1 bits
> * Stop all services using 2.1
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, will fail on MR Service Check because ExecuteHadoop() 
> resource calls "hadoop" command, which is still pointing to 2.1 bits!
> 
> One solution is for the orchestration to remove the 2.1 bits before starting 
> using 2.3.
> Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
> "hdp-select set hadoop-client " it will create the symlink 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop
> 
> 
> Diffs
> -
> 
>   ambari-server/src/main/resources/custom_actions/scripts/remove_bits.py 
> PRE-CREATION 
>   
> ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
>  91d4f64 
> 
> Diff: https://reviews.apache.org/r/39955/diff/
> 
> 
> Testing
> ---
> 
> Verified during Express Upgrade from HDP 2.1->2.3
> 
> 
> Thanks,
> 
> Alejandro Fernandez
> 
>

[jira] [Updated] (AMBARI-13723) Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Alejandro Fernandez (JIRA)]

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

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

> Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3
> 
>
> Key: AMBARI-13723
> URL: https://issues.apache.org/jira/browse/AMBARI-13723
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.1.3
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.2.0, 2.1.3
>
> Attachments: AMBARI-13723.trunk.patch
>
>
> We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, 
> "hadoop" bin still points to the old binary because we had to install HDP 2.3 
> while 2.1 bits still existed.
> *Manual Upgrade Instructions:*
> * Stop all services using 2.1
> * yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
> /usr/bin/hdfs, /usr/bin/hive, etc/)
> * yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, and hence MR Service Check passes with "hadoop" command
> *Express Upgrade:*
> * Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
> process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
> 2.1 bits
> * Stop all services using 2.1
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, will fail on MR Service Check because ExecuteHadoop() 
> resource calls "hadoop" command, which is still pointing to 2.1 bits!
> One solution is for the orchestration to remove the 2.1 bits before starting 
> using 2.3.
> Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
> "hdp-select set hadoop-client " it will create the symlink 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop



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

[jira] [Updated] (AMBARI-13723) Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-13723:
-
Attachment: AMBARI-13723.trunk.patch

> Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3
> 
>
> Key: AMBARI-13723
> URL: https://issues.apache.org/jira/browse/AMBARI-13723
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.1.3
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.2.0, 2.1.3
>
> Attachments: AMBARI-13723.trunk.patch
>
>
> We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, 
> "hadoop" bin still points to the old binary because we had to install HDP 2.3 
> while 2.1 bits still existed.
> *Manual Upgrade Instructions:*
> * Stop all services using 2.1
> * yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
> /usr/bin/hdfs, /usr/bin/hive, etc/)
> * yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, and hence MR Service Check passes with "hadoop" command
> *Express Upgrade:*
> * Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
> process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
> 2.1 bits
> * Stop all services using 2.1
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, will fail on MR Service Check because ExecuteHadoop() 
> resource calls "hadoop" command, which is still pointing to 2.1 bits!
> One solution is for the orchestration to remove the 2.1 bits before starting 
> using 2.3.
> Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
> "hdp-select set hadoop-client " it will create the symlink 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop



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

Re: Review Request 39955: AMBARI-13723. Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Nate Cole]

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

Ship it!



ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
 (line 190)


Just "Remove HDP-2.1"  no need to say "bits" :)



ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
 (line 196)


"will delete HDP-2.1."  "This is because 2.1 did not..."


- Nate Cole


On Nov. 4, 2015, 5:38 p.m., Alejandro Fernandez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39955/
> ---
> 
> (Updated Nov. 4, 2015, 5:38 p.m.)
> 
> 
> Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, Jayush 
> Luniya, Nate Cole, and Swapan Shridhar.
> 
> 
> Bugs: AMBARI-13723
> https://issues.apache.org/jira/browse/AMBARI-13723
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, 
> "hadoop" bin still points to the old binary because we had to install HDP 2.3 
> while 2.1 bits still existed.
> 
> **Manual Upgrade Instructions:**
> 
> * Stop all services using 2.1
> * yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
> /usr/bin/hdfs, /usr/bin/hive, etc/)
> * yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, and hence MR Service Check passes with "hadoop" command
> 
> **Express Upgrade:**
> 
> * Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
> process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
> 2.1 bits
> * Stop all services using 2.1
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, will fail on MR Service Check because ExecuteHadoop() 
> resource calls "hadoop" command, which is still pointing to 2.1 bits!
> 
> One solution is for the orchestration to remove the 2.1 bits before starting 
> using 2.3.
> Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
> "hdp-select set hadoop-client " it will create the symlink 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop
> 
> 
> Diffs
> -
> 
>   ambari-server/src/main/resources/custom_actions/scripts/remove_bits.py 
> PRE-CREATION 
>   
> ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
>  91d4f64 
> 
> Diff: https://reviews.apache.org/r/39955/diff/
> 
> 
> Testing
> ---
> 
> Verified during Express Upgrade from HDP 2.1->2.3
> 
> 
> Thanks,
> 
> Alejandro Fernandez
> 
>

Re: Review Request 39955: AMBARI-13723. Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Alejandro Fernandez]

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



ambari-server/src/main/resources/custom_actions/scripts/remove_bits.py (line 46)


We may need to test this on other OS'es.


- Alejandro Fernandez


On Nov. 4, 2015, 10:38 p.m., Alejandro Fernandez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39955/
> ---
> 
> (Updated Nov. 4, 2015, 10:38 p.m.)
> 
> 
> Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, Jayush 
> Luniya, Nate Cole, and Swapan Shridhar.
> 
> 
> Bugs: AMBARI-13723
> https://issues.apache.org/jira/browse/AMBARI-13723
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, 
> "hadoop" bin still points to the old binary because we had to install HDP 2.3 
> while 2.1 bits still existed.
> 
> **Manual Upgrade Instructions:**
> 
> * Stop all services using 2.1
> * yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
> /usr/bin/hdfs, /usr/bin/hive, etc/)
> * yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, and hence MR Service Check passes with "hadoop" command
> 
> **Express Upgrade:**
> 
> * Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
> process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
> 2.1 bits
> * Stop all services using 2.1
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, will fail on MR Service Check because ExecuteHadoop() 
> resource calls "hadoop" command, which is still pointing to 2.1 bits!
> 
> One solution is for the orchestration to remove the 2.1 bits before starting 
> using 2.3.
> Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
> "hdp-select set hadoop-client " it will create the symlink 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop
> 
> 
> Diffs
> -
> 
>   ambari-server/src/main/resources/custom_actions/scripts/remove_bits.py 
> PRE-CREATION 
>   
> ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
>  91d4f64 
> 
> Diff: https://reviews.apache.org/r/39955/diff/
> 
> 
> Testing
> ---
> 
> Verified during Express Upgrade from HDP 2.1->2.3
> 
> 
> Thanks,
> 
> Alejandro Fernandez
> 
>

[jira] [Updated] (AMBARI-13723) Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-13723:
-
Attachment: AMBARI-13723.trunk.patch

> Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3
> 
>
> Key: AMBARI-13723
> URL: https://issues.apache.org/jira/browse/AMBARI-13723
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.1.3
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.2.0, 2.1.3
>
> Attachments: AMBARI-13723.trunk.patch
>
>
> We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, 
> "hadoop" bin still points to the old binary because we had to install HDP 2.3 
> while 2.1 bits still existed.
> *Manual Upgrade Instructions:*
> * Stop all services using 2.1
> * yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
> /usr/bin/hdfs, /usr/bin/hive, etc/)
> * yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, and hence MR Service Check passes with "hadoop" command
> *Express Upgrade:*
> * Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
> process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
> 2.1 bits
> * Stop all services using 2.1
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, will fail on MR Service Check because ExecuteHadoop() 
> resource calls "hadoop" command, which is still pointing to 2.1 bits!
> One solution is for the orchestration to remove the 2.1 bits before starting 
> using 2.3.
> Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
> "hdp-select set hadoop-client " it will create the symlink 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop



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

[jira] [Updated] (AMBARI-13723) Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Alejandro Fernandez (JIRA)]

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

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

> Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3
> 
>
> Key: AMBARI-13723
> URL: https://issues.apache.org/jira/browse/AMBARI-13723
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.1.3
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.2.0, 2.1.3
>
> Attachments: AMBARI-13723.trunk.patch
>
>
> We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, 
> "hadoop" bin still points to the old binary because we had to install HDP 2.3 
> while 2.1 bits still existed.
> *Manual Upgrade Instructions:*
> * Stop all services using 2.1
> * yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
> /usr/bin/hdfs, /usr/bin/hive, etc/)
> * yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, and hence MR Service Check passes with "hadoop" command
> *Express Upgrade:*
> * Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
> process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
> 2.1 bits
> * Stop all services using 2.1
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, will fail on MR Service Check because ExecuteHadoop() 
> resource calls "hadoop" command, which is still pointing to 2.1 bits!
> One solution is for the orchestration to remove the 2.1 bits before starting 
> using 2.3.
> Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
> "hdp-select set hadoop-client " it will create the symlink 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop



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

Re: Review Request 39955: AMBARI-13723. Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Alejandro Fernandez]

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

(Updated Nov. 4, 2015, 10:38 p.m.)


Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, Jayush Luniya, 
Nate Cole, and Swapan Shridhar.


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


Repository: ambari


Description
---

We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, "hadoop" 
bin still points to the old binary because we had to install HDP 2.3 while 2.1 
bits still existed.

**Manual Upgrade Instructions:**

* Stop all services using 2.1
* yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
/usr/bin/hdfs, /usr/bin/hive, etc/)
* yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
/usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
* Change the version to 2.3 (hdp-select, conf-select, etc.)
* Start all services, and hence MR Service Check passes with "hadoop" command

**Express Upgrade:**

* Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
2.1 bits
* Stop all services using 2.1
* Change the version to 2.3 (hdp-select, conf-select, etc.)
* Start all services, will fail on MR Service Check because ExecuteHadoop() 
resource calls "hadoop" command, which is still pointing to 2.1 bits!

One solution is for the orchestration to remove the 2.1 bits before starting 
using 2.3.
Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
"hdp-select set hadoop-client " it will create the symlink 
/usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop


Diffs (updated)
-

  ambari-server/src/main/resources/custom_actions/scripts/remove_bits.py 
PRE-CREATION 
  
ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
 91d4f64 

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


Testing
---

Verified during Express Upgrade from HDP 2.1->2.3


Thanks,

Alejandro Fernandez

[jira] [Created] (AMBARI-13724) PHD Ambari out of base2.1 plus HAWQ/PXF patch won't bring the services in

[jun aoki (JIRA)]

jun aoki created AMBARI-13724:
-

 Summary: PHD Ambari out of base2.1 plus HAWQ/PXF patch won't bring 
the services in
 Key: AMBARI-13724
 URL: https://issues.apache.org/jira/browse/AMBARI-13724
 Project: Ambari
  Issue Type: Bug
Reporter: jun aoki


We've built an ambari-server.rpm from branch-2.1 + a patch that consolidates 
all our recent work for HAWQ and PXF described 
https://issues.apache.org/jira/browse/AMBARI-13665

That installation, however, does not provide HAWQ and PXF service definitions 
at all. [1] not even in its common-services [2]

There are 2 things
1. common-services should have all the open source has, regardless of what are 
actually enabled.
2. HAWQ and PXF should be enabled on PHD stack.

1. I am guessing copy_common_services() [3] filters services but I believe it 
won't be necessary as HDP does not filter anything.
For HDP, all services show up in common-services but some of them are just not 
enabled (e.g. HAWQ and PXF not enabled by default)
GenerateStackDefinition.py should not filter any services in common-services so 
that all distribution can be aligned

2. This probably is rather simple. HAWQ and PXF should be enabled for PHD stack.





[1] HAWQ and PXF are not shown up in PHD/2.0.6/srvices
[root@ip-10-32-36-173 stacks]# find /var/lib/ambari-server/resources/stacks 
-name services | xargs ls
/var/lib/ambari-server/resources/stacks/PHD/2.0.6/services:
AMBARI_METRICS  GANGLIA  HBASE  HDFS  HIVE  KERBEROS  OOZIE  PIG  
stack_advisor.py  YARN  ZOOKEEPER

/var/lib/ambari-server/resources/stacks/PHD/2.1/services:
HBASE  HDFS  HIVE  KERBEROS  OOZIE  PIG  stack_advisor.py  TEZ  YARN  ZOOKEEPER

/var/lib/ambari-server/resources/stacks/PHD/3.0/services:
HBASE  HDFS  HIVE  KERBEROS  KNOX  OOZIE  PIG  RANGER  SPARK  stack_advisor.py  
TEZ  YARN  ZOOKEEPER

/var/lib/ambari-server/resources/stacks/PHD/3.3/services:
HBASE  HDFS  HIVE  KERBEROS  KNOX  OOZIE  PIG  RANGER  RANGER_KMS  SPARK  
stack_advisor.py  TEZ  YARN  ZOOKEEPER


[2] HAWQ and PXF do not exist even in common-services
ls /var/lib/ambari-server/resources/common-services/
AMBARI_METRICS  GANGLIA  HBASE  HDFS  HIVE  KERBEROS  KNOX  OOZIE  PIG  RANGER  
RANGER_KMS  SPARK  TEZ  YARN  ZOOKEEPER

[3] copy_common_services()
https://github.com/apache/ambari/blob/branch-2.1/ambari-common/src/main/python/pluggable_stack_definition/GenerateStackDefinition.py#L542




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

Re: Review Request 38918: Pig view shows completed but does not state if anything went wrong

[Srimanth Gunturi]

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

Ship it!


Ship It!

- Srimanth Gunturi


On Oct. 1, 2015, 9:20 a.m., Nitiraj Rathore wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38918/
> ---
> 
> (Updated Oct. 1, 2015, 9:20 a.m.)
> 
> 
> Review request for Ambari, Srimanth Gunturi, Sid Wagle, and Yusaku Sako.
> 
> 
> Bugs: AMBARI-13279
> https://issues.apache.org/jira/browse/AMBARI-13279
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Earliar : In case of error the Results tab is empty and Logs tab contains 
> error and the status shows  as completed. But there is no cue that some error 
> occurred.
> After the Patch : if the results is empty the Logs open up and the lines 
> containing " ERROR " are highlighted. There is a warning sign near the Logs 
> Heading and near the Completed Status showing that something might be wrong.
> 
> In the Patch : complete UI side changes
> Refactoring in pig.js and pigAlert.js controller.
> pigScript.js : extracted out function getOrCreate to handle complexity of 
> getting script from store or create
> scriptJob.js : added properties to handle when to show logs and to check if 
> result is empty.
> highlightErrors.js : new component to highlight error lines.
> jobs.hbs : added the warning sign. used the hightlight component to show the 
> ERROR lines
> jobs.js : handled collapsing and uncollapsing of Logs
> 
> 
> Diffs
> -
> 
>   
> contrib/views/pig/src/main/resources/ui/pig-web/app/components/highlightErrors.js
>  PRE-CREATION 
>   contrib/views/pig/src/main/resources/ui/pig-web/app/controllers/pig.js 
> 1741a07 
>   contrib/views/pig/src/main/resources/ui/pig-web/app/controllers/pigAlert.js 
> 27685f2 
>   
> contrib/views/pig/src/main/resources/ui/pig-web/app/controllers/pigScripts.js 
> 2c2318b 
>   
> contrib/views/pig/src/main/resources/ui/pig-web/app/controllers/scriptJob.js 
> 2d8226b 
>   contrib/views/pig/src/main/resources/ui/pig-web/app/initialize.js 91b335b 
>   contrib/views/pig/src/main/resources/ui/pig-web/app/styles/style.less 
> 652cc9b 
>   
> contrib/views/pig/src/main/resources/ui/pig-web/app/templates/script/job.hbs 
> 1584648 
>   contrib/views/pig/src/main/resources/ui/pig-web/app/views/pig/alert.js 
> 542e047 
>   contrib/views/pig/src/main/resources/ui/pig-web/app/views/script/job.js 
> 6582688 
> 
> Diff: https://reviews.apache.org/r/38918/diff/
> 
> 
> Testing
> ---
> 
> Manual testing of UI by generating error case and success case done.
> 
> 
> Thanks,
> 
> Nitiraj Rathore
> 
>

Re: Review Request 39952: Confusing message is shown when there are service check failures that have been skipped during RU

[Nate Cole]

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


Thanks for doing this so quickly!  This has been pushed.  Please go ahead and 
close the review.

- Nate Cole


On Nov. 4, 2015, 3:38 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39952/
> ---
> 
> (Updated Nov. 4, 2015, 3:38 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Jayush 
> Luniya, Mahadev Konar, and Nate Cole.
> 
> 
> Bugs: AMBARI-13722
> https://issues.apache.org/jira/browse/AMBARI-13722
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When failures are skipped in the Upgrade Wizard, there's a manual 
> confirmation step that is injected.
> 
> {code}
> "Manual steps required"
> Verifying Skipped Failures
> 
> [ ] I have performed the manual steps above.
> 
> [Pause Upgrade] [Proceed]  <- [Downgrade] was missing, but that's a different 
> issue
> {code}
> 
> This doesn't really make sense to the end user.
> So the full scope if this jira becomes changes to structuredOut to 
> incorporate auto-skipped detail (hosts and services/components) and failures 
> (hosts and services/components)
> 
> {code}
> {
> "failures":{
> "service_check":[
> "ZOOKEEPER"
> ],
> "host_component":{
> "host1.vm":[
> {
> "component":"DATANODE"
> }
> ],
> "host2.vm":[
> {
> "component":"DATANODE"
> }
> ]
> }
> },
> "skipped":[
> "service_check",
> "host_component"
> ]
> }
> 
> {code}
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/metadata/ActionMetadata.java
>  f5642a0 
>   
> ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/AutoSkipFailedSummaryAction.java
>  9a84e38 
>   
> ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/AutoSkipFailedSummaryActionTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/39952/diff/
> 
> 
> Testing
> ---
> 
> running full unit tests, should be good
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

[jira] [Commented] (AMBARI-13716) Check Tez is failed(after upgrade from 1.6.1 to 2.1.2.1)

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13716:
-

ABORTED: Integrated in Ambari-trunk-Commit #3772 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3772/])
AMBARI-13716. Check Tez is failed(after upgrade from 1.6.1 to (vbrodetskyi: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=af56de5ac24ed8101a3ed17fbed7c633ec320435])
* ambari-server/src/test/python/stacks/2.1/TEZ/test_service_check.py
* 
ambari-server/src/main/resources/common-services/TEZ/0.4.0.2.1/package/scripts/service_check.py


> Check Tez is failed(after upgrade from 1.6.1 to 2.1.2.1)
> 
>
> Key: AMBARI-13716
> URL: https://issues.apache.org/jira/browse/AMBARI-13716
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: AMBARI-13716.patch
>
>
> STR:  
> 1)Deploy old version (1.6.1)
> 2)Make Ambari Only Upgrade to 2.1.2.1
> 3)Enable security
> 4)Run Tez Check
> Actual results:
> Check Tez is failed
> {code}
> stderr:   /var/lib/ambari-agent/data/errors-878.txt
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/TEZ/0.4.0.2.1/package/scripts/service_check.py",
>  line 98, in 
> TezServiceCheck().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 216, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/TEZ/0.4.0.2.1/package/scripts/service_check.py",
>  line 75, in service_check
> bin_dir = params.hadoop_bin_dir
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
> line 154, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 152, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 118, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/execute_hadoop.py",
>  line 55, in action_run
> environment = self.resource.environment,
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
> line 154, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 152, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 118, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 260, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 70, in inner
> result = function(command, **kwargs)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 92, in checked_call
> tries=tries, try_sleep=try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 291, in _call
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'hadoop --config 
> /etc/hadoop/conf jar /usr/lib/tez/tez-mapreduce-examples*.jar 
> orderedwordcount /tmp/tezsmokeinput/sample-tez-test /tmp/tezsmokeoutput/' 
> returned 255. 15/10/29 15:07:55 INFO impl.TimelineClientImpl: Timeline 
> service address: 
> http://amb-upg161-rhel6mysql1446082270-4.novalocal:8188/ws/v1/timeline/
> 15/10/29 15:07:56 INFO client.ConfiguredRMFailoverProxyProvider: Failing over 
> to rm2
> 15/10/29 15:07:57 INFO client.TezClientUtils: Permissions on staging 
> directory 
> hdfs://nameservice/user/ambari-qa/.staging/application_1446130514848_0008 are 
> incorrect: rwxr-xr-x. Fixing permissions to correct value rwx--
> 15/10/29 15:07:57 INFO examples.OrderedWordCount: Creating Tez Session
> 15/10/29 15:07:57 INFO impl.TimelineClientImpl: Timeline service address: 
> http://amb-upg161-rhel6mysql1446082270-4.novalocal:8188/ws/v1/timeline/
> 15/10/29 15:07:58 INFO client.ConfiguredRMFailoverProxyProvider: Failing over 
> to rm2
> 15/10/29 15:07:58 INFO impl.YarnClientImpl: Submitted application 
> application_1446130514848_0008
> 15/10/29 15:07:58 INFO examples.OrderedWordCount: Created Tez Session
> 15/10/29 15:07:58 ERROR examples.OrderedWordCount: Error

[jira] [Commented] (AMBARI-13714) Magician Script licensing is confusing / incorrect

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13714:
-

ABORTED: Integrated in Ambari-trunk-Commit #3772 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3772/])
AMBARI-13714. Magician Script licensing is confusing / incorrect (vbrodetskyi: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=198755193692848e126071f81c3073d9587cf949])
* pom.xml
* contrib/ru_magician/ru_magician.py
* contrib/ru_magician/lgpl_license.txt
* contrib/ru_magician/README.md
* contrib/ru_magician/mit_license.txt


> Magician Script licensing is confusing / incorrect
> --
>
> Key: AMBARI-13714
> URL: https://issues.apache.org/jira/browse/AMBARI-13714
> Project: Ambari
>  Issue Type: Bug
>  Components: contrib
>Affects Versions: 2.1.1
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: AMBARI-13714.patch
>
>
> Before we can include the magician script in Ambari releases, need to review 
> the license situation.
> We're considering deleting the script since it was meant to be a stop-gap 
> solution for Ambari 2.1.0 and 2.1.1. RU is far more stable now so we don't 
> need RU Magician anymore.(Alejandro)



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

[jira] [Commented] (AMBARI-13715) Refactor Quick Links View

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13715:
-

ABORTED: Integrated in Ambari-trunk-Commit #3772 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3772/])
AMBARI-13715 Refactor Quick Links View. (atkach) (atkach: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=e97b321647e5966bdd94291ce454bf29b8cf2ed5])
* ambari-web/test/views/main/admin/highAvailability/progress_view_test.js
* ambari-web/app/utils/ember_reopen.js
* ambari-web/app/utils/ajax/ajax.js
* ambari-web/app/assets/test/tests.js
* ambari-web/app/app.js
* ambari-web/test/views/common/chart/linear_time_test.js
* ambari-web/test/app_test.js
* ambari-web/app/views/main/admin/highAvailability/progress_view.js
* ambari-web/test/views/main/admin_test.js
* ambari-web/app/views/common/quick_view_link_view.js
* ambari-web/test/views/common/quick_link_view_test.js
* ambari-web/app/models/quick_links.js


> Refactor Quick Links View
> -
>
> Key: AMBARI-13715
> URL: https://issues.apache.org/jira/browse/AMBARI-13715
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
> Fix For: 2.2.0
>
> Attachments: AMBARI-13715.patch
>
>
> * Remove duplicated logic
> * Add unit tests



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

Review Request 39955: AMBARI-13723. Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Alejandro Fernandez]

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

Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, Jayush Luniya, 
Nate Cole, and Swapan Shridhar.


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


Repository: ambari


Description
---

We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, "hadoop" 
bin still points to the old binary because we had to install HDP 2.3 while 2.1 
bits still existed.

**Manual Upgrade Instructions:**

* Stop all services using 2.1
* yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
/usr/bin/hdfs, /usr/bin/hive, etc/)
* yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
/usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
* Change the version to 2.3 (hdp-select, conf-select, etc.)
* Start all services, and hence MR Service Check passes with "hadoop" command

**Express Upgrade:**

* Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
2.1 bits
* Stop all services using 2.1
* Change the version to 2.3 (hdp-select, conf-select, etc.)
* Start all services, will fail on MR Service Check because ExecuteHadoop() 
resource calls "hadoop" command, which is still pointing to 2.1 bits!

One solution is for the orchestration to remove the 2.1 bits before starting 
using 2.3.
Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
"hdp-select set hadoop-client " it will create the symlink 
/usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop


Diffs
-

  ambari-server/src/main/resources/custom_actions/scripts/remove_bits.py 
PRE-CREATION 
  
ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
 91d4f64 

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


Testing
---

Verified during Express Upgrade from HDP 2.1->2.3


Thanks,

Alejandro Fernandez

[jira] [Updated] (AMBARI-13723) Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-13723:
-
Attachment: AMBARI-13723.trunk.patch

> Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3
> 
>
> Key: AMBARI-13723
> URL: https://issues.apache.org/jira/browse/AMBARI-13723
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.1.3
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.2.0, 2.1.3
>
> Attachments: AMBARI-13723.trunk.patch
>
>
> We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, 
> "hadoop" bin still points to the old binary because we had to install HDP 2.3 
> while 2.1 bits still existed.
> *Manual Upgrade Instructions:*
> * Stop all services using 2.1
> * yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
> /usr/bin/hdfs, /usr/bin/hive, etc/)
> * yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, and hence MR Service Check passes with "hadoop" command
> *Express Upgrade:*
> * Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
> process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
> 2.1 bits
> * Stop all services using 2.1
> * Change the version to 2.3 (hdp-select, conf-select, etc.)
> * Start all services, will fail on MR Service Check because ExecuteHadoop() 
> resource calls "hadoop" command, which is still pointing to 2.1 bits!
> One solution is for the orchestration to remove the 2.1 bits before starting 
> using 2.3.
> Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
> "hdp-select set hadoop-client " it will create the symlink 
> /usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop



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

Re: Review Request 39937: Ambari should restore tez.lib.uris to stack defaults when upgrading Tez

[Alejandro Fernandez]

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



ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
 (line 260)


I thought that during merging configs we always accepted the current value 
if it was modified from the default. Meaning, that this type of config needs to 
be forced.


- Alejandro Fernandez


On Nov. 4, 2015, 4:58 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39937/
> ---
> 
> (Updated Nov. 4, 2015, 4:58 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Jayush 
> Luniya, and Nate Cole.
> 
> 
> Bugs: AMBARI-13713
> https://issues.apache.org/jira/browse/AMBARI-13713
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Customers apply hotfixes for Tez by modifying tez.lib.uris to point to a new 
> tez tarball to avoid affecting currently running jobs.
> 
> When Ambari does an upgrade to a future version, this config should be 
> reverted to point to the newly uploaded tez tarball ( from the upgraded 
> version ).
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
>  ad9346e 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/config-upgrade.xml 
> 14bd266 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.2.xml
>  c9ba8d2 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml
>  06e5859 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.2.xml 
> f210930 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
> 5b78cfd 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/config-upgrade.xml 
> 53329ee 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
>  016bad6 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml 
> b0bd7d9 
> 
> Diff: https://reviews.apache.org/r/39937/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

[jira] [Resolved] (AMBARI-13708) RU/EU: invalid state transition, INSTALL_FAILED (cannot Finalize)

[Jayush Luniya (JIRA)]

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

Jayush Luniya resolved AMBARI-13708.

Resolution: Fixed

> RU/EU: invalid state transition, INSTALL_FAILED (cannot Finalize)
> -
>
> Key: AMBARI-13708
> URL: https://issues.apache.org/jira/browse/AMBARI-13708
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: AMBARI-13708.patch
>
>
> Steps to reproduce:
> # Put some unhealthy hosts to MM
> # Start Rolling Upgrade
> # Proceed to "Check Unhealthy Hosts" step
> # Delete host in unhealthy state
> # Proceed to Finalize Upgrade
> # Finalize Upgrade fails
> Root Cause: 
> This is because cluster version remains in INSTALL_FAILED state



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

[jira] [Commented] (AMBARI-13708) RU/EU: invalid state transition, INSTALL_FAILED (cannot Finalize)

[Jayush Luniya (JIRA)]

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

Jayush Luniya commented on AMBARI-13708:


Branch-2.1
commit d0c0a5edf4a39d11bbba1a6027d900d377470a3f
Author: Jayush Luniya 
Date:   Wed Nov 4 13:40:48 2015 -0800

AMBARI-13708: RU/EU: invalid state transition, INSTALL_FAILED (cannot 
Finalize) (jluniya)

> RU/EU: invalid state transition, INSTALL_FAILED (cannot Finalize)
> -
>
> Key: AMBARI-13708
> URL: https://issues.apache.org/jira/browse/AMBARI-13708
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: AMBARI-13708.patch
>
>
> Steps to reproduce:
> # Put some unhealthy hosts to MM
> # Start Rolling Upgrade
> # Proceed to "Check Unhealthy Hosts" step
> # Delete host in unhealthy state
> # Proceed to Finalize Upgrade
> # Finalize Upgrade fails
> Root Cause: 
> This is because cluster version remains in INSTALL_FAILED state



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

[jira] [Commented] (AMBARI-13708) RU/EU: invalid state transition, INSTALL_FAILED (cannot Finalize)

[Jayush Luniya (JIRA)]

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

Jayush Luniya commented on AMBARI-13708:


Trunk
commit f859570ae8cedbff71986e5940f42bba195b9f2f
Author: Jayush Luniya 
Date:   Wed Nov 4 13:40:48 2015 -0800

AMBARI-13708: RU/EU: invalid state transition, INSTALL_FAILED (cannot 
Finalize) (jluniya)

> RU/EU: invalid state transition, INSTALL_FAILED (cannot Finalize)
> -
>
> Key: AMBARI-13708
> URL: https://issues.apache.org/jira/browse/AMBARI-13708
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: AMBARI-13708.patch
>
>
> Steps to reproduce:
> # Put some unhealthy hosts to MM
> # Start Rolling Upgrade
> # Proceed to "Check Unhealthy Hosts" step
> # Delete host in unhealthy state
> # Proceed to Finalize Upgrade
> # Finalize Upgrade fails
> Root Cause: 
> This is because cluster version remains in INSTALL_FAILED state



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

[jira] [Created] (AMBARI-13723) Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits before starting on 2.3

[Alejandro Fernandez (JIRA)]

Alejandro Fernandez created AMBARI-13723:


 Summary: Express Upgrade: HDP 2.1->2.3 must uninstall 2.1 bits 
before starting on 2.3
 Key: AMBARI-13723
 URL: https://issues.apache.org/jira/browse/AMBARI-13723
 Project: Ambari
  Issue Type: Story
  Components: ambari-server
Affects Versions: 2.2.0, 2.1.3
Reporter: Alejandro Fernandez
Assignee: Alejandro Fernandez
 Fix For: 2.2.0, 2.1.3


We found a major flaw in the Express Upgrade from 2.1->2.3. Basically, "hadoop" 
bin still points to the old binary because we had to install HDP 2.3 while 2.1 
bits still existed.

*Manual Upgrade Instructions:*
* Stop all services using 2.1
* yum erase hadoop hdfs hive … (this will remove scripts /usr/bin/hadoop, 
/usr/bin/hdfs, /usr/bin/hive, etc/)
* yum install hadoop_2_3_* hdfs_2_3_* hive_2_3_* (rpm should point 
/usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop)
* Change the version to 2.3 (hdp-select, conf-select, etc.)
* Start all services, and hence MR Service Check passes with "hadoop" command

*Express Upgrade:*
* Install HDP 2.3 bits. We reused the RU framework that relies on a 2 step 
process: install bits, perform upgrade. Hence, /usr/bin/hadoop is still using 
2.1 bits
* Stop all services using 2.1
* Change the version to 2.3 (hdp-select, conf-select, etc.)
* Start all services, will fail on MR Service Check because ExecuteHadoop() 
resource calls "hadoop" command, which is still pointing to 2.1 bits!

One solution is for the orchestration to remove the 2.1 bits before starting 
using 2.3.
Uninstalling the 2.1 bits will remove /usr/bin/hadoop, but when we call 
"hdp-select set hadoop-client " it will create the symlink 
/usr/bin/hadoop -> /usr/hdp/current/hadoop-client/bin/hadoop




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

Re: Review Request 39952: Confusing message is shown when there are service check failures that have been skipped during RU

[Nate Cole]

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

Ship it!


Ship It!

- Nate Cole


On Nov. 4, 2015, 3:38 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39952/
> ---
> 
> (Updated Nov. 4, 2015, 3:38 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Jayush 
> Luniya, Mahadev Konar, and Nate Cole.
> 
> 
> Bugs: AMBARI-13722
> https://issues.apache.org/jira/browse/AMBARI-13722
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When failures are skipped in the Upgrade Wizard, there's a manual 
> confirmation step that is injected.
> 
> {code}
> "Manual steps required"
> Verifying Skipped Failures
> 
> [ ] I have performed the manual steps above.
> 
> [Pause Upgrade] [Proceed]  <- [Downgrade] was missing, but that's a different 
> issue
> {code}
> 
> This doesn't really make sense to the end user.
> So the full scope if this jira becomes changes to structuredOut to 
> incorporate auto-skipped detail (hosts and services/components) and failures 
> (hosts and services/components)
> 
> {code}
> {
> "failures":{
> "service_check":[
> "ZOOKEEPER"
> ],
> "host_component":{
> "host1.vm":[
> {
> "component":"DATANODE"
> }
> ],
> "host2.vm":[
> {
> "component":"DATANODE"
> }
> ]
> }
> },
> "skipped":[
> "service_check",
> "host_component"
> ]
> }
> 
> {code}
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/metadata/ActionMetadata.java
>  f5642a0 
>   
> ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/AutoSkipFailedSummaryAction.java
>  9a84e38 
>   
> ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/AutoSkipFailedSummaryActionTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/39952/diff/
> 
> 
> Testing
> ---
> 
> running full unit tests, should be good
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

[jira] [Commented] (AMBARI-13716) Check Tez is failed(after upgrade from 1.6.1 to 2.1.2.1)

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13716:
-

FAILURE: Integrated in Ambari-branch-2.1 #800 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/800/])
AMBARI-13716. Check Tez is failed(after upgrade from 1.6.1 to (vbrodetskyi: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=f10ece280f442b4f63e22635466f9c9dbee8e421])
* ambari-server/src/test/python/stacks/2.1/TEZ/test_service_check.py
* 
ambari-server/src/main/resources/common-services/TEZ/0.4.0.2.1/package/scripts/service_check.py


> Check Tez is failed(after upgrade from 1.6.1 to 2.1.2.1)
> 
>
> Key: AMBARI-13716
> URL: https://issues.apache.org/jira/browse/AMBARI-13716
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: AMBARI-13716.patch
>
>
> STR:  
> 1)Deploy old version (1.6.1)
> 2)Make Ambari Only Upgrade to 2.1.2.1
> 3)Enable security
> 4)Run Tez Check
> Actual results:
> Check Tez is failed
> {code}
> stderr:   /var/lib/ambari-agent/data/errors-878.txt
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/TEZ/0.4.0.2.1/package/scripts/service_check.py",
>  line 98, in 
> TezServiceCheck().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 216, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/TEZ/0.4.0.2.1/package/scripts/service_check.py",
>  line 75, in service_check
> bin_dir = params.hadoop_bin_dir
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
> line 154, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 152, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 118, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/execute_hadoop.py",
>  line 55, in action_run
> environment = self.resource.environment,
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
> line 154, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 152, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 118, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 260, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 70, in inner
> result = function(command, **kwargs)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 92, in checked_call
> tries=tries, try_sleep=try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 291, in _call
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'hadoop --config 
> /etc/hadoop/conf jar /usr/lib/tez/tez-mapreduce-examples*.jar 
> orderedwordcount /tmp/tezsmokeinput/sample-tez-test /tmp/tezsmokeoutput/' 
> returned 255. 15/10/29 15:07:55 INFO impl.TimelineClientImpl: Timeline 
> service address: 
> http://amb-upg161-rhel6mysql1446082270-4.novalocal:8188/ws/v1/timeline/
> 15/10/29 15:07:56 INFO client.ConfiguredRMFailoverProxyProvider: Failing over 
> to rm2
> 15/10/29 15:07:57 INFO client.TezClientUtils: Permissions on staging 
> directory 
> hdfs://nameservice/user/ambari-qa/.staging/application_1446130514848_0008 are 
> incorrect: rwxr-xr-x. Fixing permissions to correct value rwx--
> 15/10/29 15:07:57 INFO examples.OrderedWordCount: Creating Tez Session
> 15/10/29 15:07:57 INFO impl.TimelineClientImpl: Timeline service address: 
> http://amb-upg161-rhel6mysql1446082270-4.novalocal:8188/ws/v1/timeline/
> 15/10/29 15:07:58 INFO client.ConfiguredRMFailoverProxyProvider: Failing over 
> to rm2
> 15/10/29 15:07:58 INFO impl.YarnClientImpl: Submitted application 
> application_1446130514848_0008
> 15/10/29 15:07:58 INFO examples.OrderedWordCount: Created Tez Session
> 15/10/29 15:07:58 ERROR examples.OrderedWordCount: Error occur

[jira] [Commented] (AMBARI-13714) Magician Script licensing is confusing / incorrect

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13714:
-

FAILURE: Integrated in Ambari-branch-2.1 #800 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/800/])
AMBARI-13714. Magician Script licensing is confusing / (vbrodetskyi: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=7a2c225d81d8302f7cd49680c66ba5d48051678f])
* contrib/ru_magician/README.md
* contrib/ru_magician/ru_magician.py
* contrib/ru_magician/mit_license.txt
* contrib/ru_magician/lgpl_license.txt
AMBARI-13714. Magician Script licensing is confusing / incorrect (vbrodetskyi: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=055fe0fcc22ada1f7c168c3aa56bafeaa180e5e8])
* pom.xml


> Magician Script licensing is confusing / incorrect
> --
>
> Key: AMBARI-13714
> URL: https://issues.apache.org/jira/browse/AMBARI-13714
> Project: Ambari
>  Issue Type: Bug
>  Components: contrib
>Affects Versions: 2.1.1
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: AMBARI-13714.patch
>
>
> Before we can include the magician script in Ambari releases, need to review 
> the license situation.
> We're considering deleting the script since it was meant to be a stop-gap 
> solution for Ambari 2.1.0 and 2.1.1. RU is far more stable now so we don't 
> need RU Magician anymore.(Alejandro)



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

Re: Review Request 39934: AMS HBase prinicpals for Master and RS need to have the same value

[Sid Wagle]

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

Ship it!


Ship It!

- Sid Wagle


On Nov. 4, 2015, 11:48 a.m., Dmytro Sen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39934/
> ---
> 
> (Updated Nov. 4, 2015, 11:48 a.m.)
> 
> 
> Review request for Ambari, Myroslav Papirkovskyy, Sid Wagle, and Vitalyi 
> Brodetskyi.
> 
> 
> Bugs: AMBARI-13711
> https://issues.apache.org/jira/browse/AMBARI-13711
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Zookeeper ACLs not allow znode created using one principal to be read by the 
> other unless proper ACL are set.
> Error trace:
> 2015-10-19 09:13:04,145 WARN  [main-EventThread] zookeeper.ZKUtil: 
> regionserver:61320-0x1507f5f87460001, quorum=host1:61181, 
> baseZNode=/ams-hbase Unable to get data of znode /ams-hbase/running
> org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = 
> NoAuth for /ams-hbase/running
> at 
> org.apache.zookeeper.KeeperException.create(KeeperException.java:113)
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/kerberos.json
>  8753b1f 
> 
> Diff: https://reviews.apache.org/r/39934/diff/
> 
> 
> Testing
> ---
> 
> Unit tests passed.
> Tested end-to-end with distributed AMS
> 
> 
> Thanks,
> 
> Dmytro Sen
> 
>

[jira] [Commented] (AMBARI-13712) Blueprints: Support for Blueprint export of a running Kerberized Cluster

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-13712:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12770617/AMBARI-13712.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 test build failed in ambari-server 

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

This message is automatically generated.

> Blueprints: Support for Blueprint export of a running Kerberized Cluster
> 
>
> Key: AMBARI-13712
> URL: https://issues.apache.org/jira/browse/AMBARI-13712
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
> Attachments: AMBARI-13712.patch
>
>
> This task involves implementing the support for exporting a Blueprint from a 
> Kerberized cluster, and having this document contain everything necessary to 
> re-create this Kerberized cluster with new hardware.
> An exported Blueprint for a Kerberized cluster will need to contain:
> The existing component and configuration for the cluster (this can remain as 
> it currently is, no changes required)
> The “kerberos-env” and “k2b5-conf” configuration types. This will largely 
> occur automatically, since these types are just plain configuration types on 
> the cluster, and will be exported along with the other config types. Note: 
> There will be some work required here in order to make sure that hostnames 
> and passwords are not included in the exported Blueprint. The 
> BlueprintConfigurationProcessor will need to be updated to properly mask out 
> the hostnames/passwords. This is similar to existing config type handling, 
> and will be a relatively small amount of work.
> The Kerberos state of the cluster. The Blueprint processor will need to query 
> the “KerberosHelper” API to determine if a cluster is Kerberized. If Kerberos 
> is enabled, then the Blueprint processor will use the same API to obtain the 
> Kerberos descriptor associated with this cluster (found as a REST resource 
> under /api/v1/clusters/cluster_name/artifacts/kerberos_descriptor). This 
> Kerberos descriptor should be added to the exported Blueprint, as an embedded 
> descriptor inside the Blueprint .json file.
> We should be able to export a Blueprint from a Kerberized cluster regardless 
> of the initial deployment type (Ambari UI used to create cluster vs. 
> Blueprint deployment used to create cluster).



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

Review Request 39952: Confusing message is shown when there are service check failures that have been skipped during RU

[Dmitro Lisnichenko]

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

Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Jayush Luniya, 
Mahadev Konar, and Nate Cole.


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


Repository: ambari


Description
---

When failures are skipped in the Upgrade Wizard, there's a manual confirmation 
step that is injected.

{code}
"Manual steps required"
Verifying Skipped Failures

[ ] I have performed the manual steps above.

[Pause Upgrade] [Proceed]  <- [Downgrade] was missing, but that's a different 
issue
{code}

This doesn't really make sense to the end user.
So the full scope if this jira becomes changes to structuredOut to incorporate 
auto-skipped detail (hosts and services/components) and failures (hosts and 
services/components)

{code}
{
"failures":{
"service_check":[
"ZOOKEEPER"
],
"host_component":{
"host1.vm":[
{
"component":"DATANODE"
}
],
"host2.vm":[
{
"component":"DATANODE"
}
]
}
},
"skipped":[
"service_check",
"host_component"
]
}

{code}


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/metadata/ActionMetadata.java
 f5642a0 
  
ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/AutoSkipFailedSummaryAction.java
 9a84e38 
  
ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/AutoSkipFailedSummaryActionTest.java
 PRE-CREATION 

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


Testing
---

running full unit tests, should be good


Thanks,

Dmitro Lisnichenko

[jira] [Updated] (AMBARI-13722) Confusing message is shown when there are service check failures that have been skipped during RU

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-13722:

Affects Version/s: 2.1.3

> Confusing message is shown when there are service check failures that have 
> been skipped during RU
> -
>
> Key: AMBARI-13722
> URL: https://issues.apache.org/jira/browse/AMBARI-13722
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.3
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.1.3
>
> Attachments: AMBARI-13722.patch
>
>
> When failures are skipped in the Upgrade Wizard, there's a manual 
> confirmation step that is injected.
> {code}
> "Manual steps required"
> Verifying Skipped Failures
> [ ] I have performed the manual steps above.
> [Pause Upgrade] [Proceed]  <- [Downgrade] was missing, but that's a different 
> issue
> {code}
> This doesn't really make sense to the end user.
> So the full scope if this jira becomes changes to structuredOut to 
> incorporate auto-skipped detail (hosts and services/components) and failures 
> (hosts and services/components)
> {code}
> {
> "failures":{
> "service_check":[
> "ZOOKEEPER"
> ],
> "host_component":{
> "host1.vm":[
> {
> "component":"DATANODE"
> }
> ],
> "host2.vm":[
> {
> "component":"DATANODE"
> }
> ]
> }
> },
> "skipped":[
> "service_check",
> "host_component"
> ]
> }
> {code}



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

[jira] [Updated] (AMBARI-13722) Confusing message is shown when there are service check failures that have been skipped during RU

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-13722:

Fix Version/s: 2.1.3

> Confusing message is shown when there are service check failures that have 
> been skipped during RU
> -
>
> Key: AMBARI-13722
> URL: https://issues.apache.org/jira/browse/AMBARI-13722
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.3
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.1.3
>
> Attachments: AMBARI-13722.patch
>
>
> When failures are skipped in the Upgrade Wizard, there's a manual 
> confirmation step that is injected.
> {code}
> "Manual steps required"
> Verifying Skipped Failures
> [ ] I have performed the manual steps above.
> [Pause Upgrade] [Proceed]  <- [Downgrade] was missing, but that's a different 
> issue
> {code}
> This doesn't really make sense to the end user.
> So the full scope if this jira becomes changes to structuredOut to 
> incorporate auto-skipped detail (hosts and services/components) and failures 
> (hosts and services/components)
> {code}
> {
> "failures":{
> "service_check":[
> "ZOOKEEPER"
> ],
> "host_component":{
> "host1.vm":[
> {
> "component":"DATANODE"
> }
> ],
> "host2.vm":[
> {
> "component":"DATANODE"
> }
> ]
> }
> },
> "skipped":[
> "service_check",
> "host_component"
> ]
> }
> {code}



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

[jira] [Created] (AMBARI-13722) Confusing message is shown when there are service check failures that have been skipped during RU

[Dmitry Lysnichenko (JIRA)]

Dmitry Lysnichenko created AMBARI-13722:
---

 Summary: Confusing message is shown when there are service check 
failures that have been skipped during RU
 Key: AMBARI-13722
 URL: https://issues.apache.org/jira/browse/AMBARI-13722
 Project: Ambari
  Issue Type: Bug
Reporter: Dmitry Lysnichenko
Assignee: Dmitry Lysnichenko
 Attachments: AMBARI-13722.patch


When failures are skipped in the Upgrade Wizard, there's a manual confirmation 
step that is injected.

{code}
"Manual steps required"
Verifying Skipped Failures

[ ] I have performed the manual steps above.

[Pause Upgrade] [Proceed]  <- [Downgrade] was missing, but that's a different 
issue
{code}

This doesn't really make sense to the end user.
So the full scope if this jira becomes changes to structuredOut to incorporate 
auto-skipped detail (hosts and services/components) and failures (hosts and 
services/components)

{code}
{
"failures":{
"service_check":[
"ZOOKEEPER"
],
"host_component":{
"host1.vm":[
{
"component":"DATANODE"
}
],
"host2.vm":[
{
"component":"DATANODE"
}
]
}
},
"skipped":[
"service_check",
"host_component"
]
}

{code}





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

[jira] [Updated] (AMBARI-13722) Confusing message is shown when there are service check failures that have been skipped during RU

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-13722:

Component/s: ambari-server

> Confusing message is shown when there are service check failures that have 
> been skipped during RU
> -
>
> Key: AMBARI-13722
> URL: https://issues.apache.org/jira/browse/AMBARI-13722
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Attachments: AMBARI-13722.patch
>
>
> When failures are skipped in the Upgrade Wizard, there's a manual 
> confirmation step that is injected.
> {code}
> "Manual steps required"
> Verifying Skipped Failures
> [ ] I have performed the manual steps above.
> [Pause Upgrade] [Proceed]  <- [Downgrade] was missing, but that's a different 
> issue
> {code}
> This doesn't really make sense to the end user.
> So the full scope if this jira becomes changes to structuredOut to 
> incorporate auto-skipped detail (hosts and services/components) and failures 
> (hosts and services/components)
> {code}
> {
> "failures":{
> "service_check":[
> "ZOOKEEPER"
> ],
> "host_component":{
> "host1.vm":[
> {
> "component":"DATANODE"
> }
> ],
> "host2.vm":[
> {
> "component":"DATANODE"
> }
> ]
> }
> },
> "skipped":[
> "service_check",
> "host_component"
> ]
> }
> {code}



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

[jira] [Updated] (AMBARI-13722) Confusing message is shown when there are service check failures that have been skipped during RU

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-13722:

Attachment: AMBARI-13722.patch

> Confusing message is shown when there are service check failures that have 
> been skipped during RU
> -
>
> Key: AMBARI-13722
> URL: https://issues.apache.org/jira/browse/AMBARI-13722
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Attachments: AMBARI-13722.patch
>
>
> When failures are skipped in the Upgrade Wizard, there's a manual 
> confirmation step that is injected.
> {code}
> "Manual steps required"
> Verifying Skipped Failures
> [ ] I have performed the manual steps above.
> [Pause Upgrade] [Proceed]  <- [Downgrade] was missing, but that's a different 
> issue
> {code}
> This doesn't really make sense to the end user.
> So the full scope if this jira becomes changes to structuredOut to 
> incorporate auto-skipped detail (hosts and services/components) and failures 
> (hosts and services/components)
> {code}
> {
> "failures":{
> "service_check":[
> "ZOOKEEPER"
> ],
> "host_component":{
> "host1.vm":[
> {
> "component":"DATANODE"
> }
> ],
> "host2.vm":[
> {
> "component":"DATANODE"
> }
> ]
> }
> },
> "skipped":[
> "service_check",
> "host_component"
> ]
> }
> {code}



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

[jira] [Updated] (AMBARI-1390) Move Secondary NameNode to new server

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-1390:

Assignee: Nate Cole

> Move Secondary NameNode to new server
> -
>
> Key: AMBARI-1390
> URL: https://issues.apache.org/jira/browse/AMBARI-1390
> Project: Ambari
>  Issue Type: Sub-task
>Reporter: Nate Cole
>Assignee: Nate Cole
> Fix For: 1.4.2
>
>
> Move Secondary NameNode to new server



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

Re: Review Request 39937: Ambari should restore tez.lib.uris to stack defaults when upgrading Tez

[Jayush Luniya]

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



ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.2.xml
 (line 234)


Since this change requires a Configure Task to be executed within the same 
stack ex: HDP-2.2 -> HDP-2.2, we should add a unit test to cover the 
intra-stack upgrade test on Configure Task.


- Jayush Luniya


On Nov. 4, 2015, 4:58 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39937/
> ---
> 
> (Updated Nov. 4, 2015, 4:58 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Jayush 
> Luniya, and Nate Cole.
> 
> 
> Bugs: AMBARI-13713
> https://issues.apache.org/jira/browse/AMBARI-13713
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Customers apply hotfixes for Tez by modifying tez.lib.uris to point to a new 
> tez tarball to avoid affecting currently running jobs.
> 
> When Ambari does an upgrade to a future version, this config should be 
> reverted to point to the newly uploaded tez tarball ( from the upgraded 
> version ).
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
>  ad9346e 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/config-upgrade.xml 
> 14bd266 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.2.xml
>  c9ba8d2 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml
>  06e5859 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.2.xml 
> f210930 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
> 5b78cfd 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/config-upgrade.xml 
> 53329ee 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
>  016bad6 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml 
> b0bd7d9 
> 
> Diff: https://reviews.apache.org/r/39937/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

[jira] [Created] (AMBARI-13721) Ambari functional tests infrastructure

[Nahappan Somasundaram (JIRA)]

Nahappan Somasundaram created AMBARI-13721:
--

 Summary: Ambari functional tests infrastructure
 Key: AMBARI-13721
 URL: https://issues.apache.org/jira/browse/AMBARI-13721
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.1.3
Reporter: Nahappan Somasundaram
Assignee: Nahappan Somasundaram
 Fix For: 2.2.0


Run a test version of the ambari-server with an in-memory DB and ambari-agent 
that run during the functional testing and cover several basic use cases  like 
heartbeat monitoring, adding and deleting services, components, hosts, etc.



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

[jira] [Updated] (AMBARI-1361) Install progress dialog WARN icon + color

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-1361:

Assignee: Jaimin D Jetly

> Install progress dialog WARN icon + color 
> --
>
> Key: AMBARI-1361
> URL: https://issues.apache.org/jira/browse/AMBARI-1361
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-web
>Affects Versions: 1.2.1
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
>  Labels: Installer, client
> Fix For: 1.2.2
>
> Attachments: AMBARI-1361_1.patch
>
>
> On the install/start/test task popup, two changes:
> 1) For items that get cancelled (since those are just WARN), the icon should 
> be orange just like the WARN condition
> 2) Use the icon-minus instead of the icon-remove.



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

[jira] [Updated] (AMBARI-1389) Move NameNode to new server

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-1389:

Assignee: Nate Cole

> Move NameNode to new server
> ---
>
> Key: AMBARI-1389
> URL: https://issues.apache.org/jira/browse/AMBARI-1389
> Project: Ambari
>  Issue Type: Sub-task
>Reporter: Nate Cole
>Assignee: Nate Cole
> Fix For: 1.4.2
>
>
> Move NameNode to new server



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

[jira] [Updated] (AMBARI-1543) Hadoop 2.0 support in Ambari for HDFS and YARN.

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-1543:

Assignee: Mahadev konar

> Hadoop 2.0 support in Ambari for HDFS and YARN.
> ---
>
> Key: AMBARI-1543
> URL: https://issues.apache.org/jira/browse/AMBARI-1543
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Mahadev konar
>Assignee: Mahadev konar
> Fix For: 1.4.1
>
>
> Hadoop 2.0 support in Ambari for HDFS and YARN.



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

[jira] [Updated] (AMBARI-13718) Install cluster wizard frozen on step 7 for Ambari 2.1.2.1 with PHD 3.3.2

[Mithun Mathew (JIRA)]

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

Mithun Mathew updated AMBARI-13718:
---
Description: 
The install cluster wizard is frozen on step 7: Customize Services when trying 
to deploy all services in the stack. 
The Next button is disabled because of the error.

Error thrown:
{color:red}Uncaught Error: assertion failed: Invalid property unit type for 
dfs.datanode.max.transfer.threads valueAttributes: {} {color}

  was:
The install cluster wizard is frozen on step 7: Customize Services when trying 
to deploy all services in the stack. 
The Next button is disabled because of the error.

Error thrown:
{color:red}
Uncaught Error: assertion failed: Invalid property unit type for 
dfs.datanode.max.transfer.threads valueAttributes: {} {color}


> Install cluster wizard frozen on step 7 for Ambari 2.1.2.1 with PHD 3.3.2
> -
>
> Key: AMBARI-13718
> URL: https://issues.apache.org/jira/browse/AMBARI-13718
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.1.2
>Reporter: Mithun Mathew
> Fix For: 2.1.2
>
> Attachments: Install cluster frozen Step 7.png
>
>
> The install cluster wizard is frozen on step 7: Customize Services when 
> trying to deploy all services in the stack. 
> The Next button is disabled because of the error.
> Error thrown:
> {color:red}Uncaught Error: assertion failed: Invalid property unit type for 
> dfs.datanode.max.transfer.threads valueAttributes: {} {color}



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

[jira] [Updated] (AMBARI-1195) Add unit tests for ambari-server.py and make sure we run them when running mvn test.

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-1195:

Assignee: Mahadev konar

> Add unit tests for ambari-server.py and make sure we run them when running 
> mvn test.
> 
>
> Key: AMBARI-1195
> URL: https://issues.apache.org/jira/browse/AMBARI-1195
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Mahadev konar
>Assignee: Mahadev konar
> Fix For: 1.2.5
>
>
> Add unit tests for ambari-server.py and make sure we run them when running 
> mvn test.



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

[jira] [Updated] (AMBARI-866) Add ORM layer for the FSM's in the server.

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-866:
---
Assignee: Mahadev konar

> Add ORM layer for the FSM's in the server.
> --
>
> Key: AMBARI-866
> URL: https://issues.apache.org/jira/browse/AMBARI-866
> Project: Ambari
>  Issue Type: Sub-task
>Affects Versions: 1.2.0
>Reporter: Mahadev konar
>Assignee: Mahadev konar
> Fix For: 1.2.0
>
> Attachments: AMBARI-866.patch
>
>
> ORM layer for the FSM's.



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

[jira] [Updated] (AMBARI-13720) HDFS Configuration widgets do not show up under settings tab for Ambari 2.1.2.1 with PHD 3.3.2

[Mithun Mathew (JIRA)]

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

Mithun Mathew updated AMBARI-13720:
---
Summary: HDFS Configuration widgets do not show up under settings tab for 
Ambari 2.1.2.1 with PHD 3.3.2  (was: HDFS Configuration widgets do not show up 
under settings tab for Ambari 2.1.2.1 on dashboard)

> HDFS Configuration widgets do not show up under settings tab for Ambari 
> 2.1.2.1 with PHD 3.3.2
> --
>
> Key: AMBARI-13720
> URL: https://issues.apache.org/jira/browse/AMBARI-13720
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.1.2
>Reporter: Mithun Mathew
> Fix For: 2.1.2
>
> Attachments: Missing widget HDFS_Configs_Settings.png
>
>
> On the Ambari dashboard for HDFS, the widgets do not show up on the UI under 
> Configs -> Settings
> Error thrown:
> {color: red}Uncaught Error: assertion failed: Invalid property unit type for 
> dfs.datanode.max.transfer.threads valueAttributes: {}{color}



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

[jira] [Updated] (AMBARI-5704) Pig View Cleanup.

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-5704:

Assignee: Mahadev konar

> Pig View Cleanup.
> -
>
> Key: AMBARI-5704
> URL: https://issues.apache.org/jira/browse/AMBARI-5704
> Project: Ambari
>  Issue Type: Bug
>Reporter: Mahadev konar
>Assignee: Mahadev konar
> Fix For: 1.6.0
>
> Attachments: AMBARI-5704.patch
>
>
> Pig View Cleanup. 



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

[jira] [Updated] (AMBARI-13718) Install cluster wizard frozen on step 7 for Ambari 2.1.2.1 with PHD 3.3.2

[Mithun Mathew (JIRA)]

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

Mithun Mathew updated AMBARI-13718:
---
Description: 
The install cluster wizard is frozen on step 7: Customize Services when trying 
to deploy all services in the stack. 
The Next button is disabled because of the error.

Error thrown:
{color:red}
Uncaught Error: assertion failed: Invalid property unit type for 
dfs.datanode.max.transfer.threads valueAttributes: {} {color}

  was:
The install cluster wizard is frozen on step 7: Customize Services when trying 
to deploy all services in the stack. 
Error thrown:
{color:red}
Uncaught Error: assertion failed: Invalid property unit type for 
dfs.datanode.max.transfer.threads valueAttributes: {} {color}


> Install cluster wizard frozen on step 7 for Ambari 2.1.2.1 with PHD 3.3.2
> -
>
> Key: AMBARI-13718
> URL: https://issues.apache.org/jira/browse/AMBARI-13718
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.1.2
>Reporter: Mithun Mathew
> Fix For: 2.1.2
>
> Attachments: Install cluster frozen Step 7.png
>
>
> The install cluster wizard is frozen on step 7: Customize Services when 
> trying to deploy all services in the stack. 
> The Next button is disabled because of the error.
> Error thrown:
> {color:red}
> Uncaught Error: assertion failed: Invalid property unit type for 
> dfs.datanode.max.transfer.threads valueAttributes: {} {color}



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

[jira] [Updated] (AMBARI-13718) Install cluster wizard frozen on step 7 for Ambari 2.1.2.1 with PHD 3.3.2

[Mithun Mathew (JIRA)]

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

Mithun Mathew updated AMBARI-13718:
---
Summary: Install cluster wizard frozen on step 7 for Ambari 2.1.2.1 with 
PHD 3.3.2  (was: Install cluster wizard frozen on step 7 for Ambari 2.1.2.1)

> Install cluster wizard frozen on step 7 for Ambari 2.1.2.1 with PHD 3.3.2
> -
>
> Key: AMBARI-13718
> URL: https://issues.apache.org/jira/browse/AMBARI-13718
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.1.2
>Reporter: Mithun Mathew
> Fix For: 2.1.2
>
> Attachments: Install cluster frozen Step 7.png
>
>
> The install cluster wizard is frozen on step 7: Customize Services when 
> trying to deploy all services in the stack. 
> Error thrown:
> {color:red}
> Uncaught Error: assertion failed: Invalid property unit type for 
> dfs.datanode.max.transfer.threads valueAttributes: {} {color}



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

[jira] [Updated] (AMBARI-6739) Java side for BE work for download client configurations

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-6739:

Assignee: Mahadev konar

> Java side for BE work for download client configurations
> 
>
> Key: AMBARI-6739
> URL: https://issues.apache.org/jira/browse/AMBARI-6739
> Project: Ambari
>  Issue Type: Task
>Affects Versions: 1.7.0
>Reporter: Mahadev konar
>Assignee: Mahadev konar
> Fix For: 1.7.0
>
> Attachments: AMBARI-6739.patch
>
>
> Java side for BE work for download client configurations



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

[jira] [Reopened] (AMBARI-5887) Suse11 repo missing from Install Wizard Review Page

[Yusaku Sako (JIRA)]

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

Yusaku Sako reopened AMBARI-5887:
-

> Suse11 repo missing from Install Wizard Review Page
> ---
>
> Key: AMBARI-5887
> URL: https://issues.apache.org/jira/browse/AMBARI-5887
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 1.6.0
>Reporter: Michael Harp
> Fix For: 1.6.1
>
>
> Seeing this issue on sles11 and centos6



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

[jira] [Reopened] (AMBARI-10971) Unable to save configs in Ambari Metrics

[Yusaku Sako (JIRA)]

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

Yusaku Sako reopened AMBARI-10971:
--

> Unable to save configs in Ambari Metrics
> 
>
> Key: AMBARI-10971
> URL: https://issues.apache.org/jira/browse/AMBARI-10971
> Project: Ambari
>  Issue Type: Bug
> Environment: ambari-2.1.0-376 
> sles11sp3
>Reporter: Michael Harp
> Fix For: 2.1.0
>
>
> Make a change to any property in AMS and click save. Front end throws 
> "Failure in saving service configuration" and ambari-server logs,
> {code}
> ERROR [qtp-client-387] ClusterImpl:2330 - Updating configs for multiple 
> services by a single API request isn't supported, config version not created
> {code}



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

[jira] [Resolved] (AMBARI-5887) Suse11 repo missing from Install Wizard Review Page

[Yusaku Sako (JIRA)]

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

Yusaku Sako resolved AMBARI-5887.
-
Resolution: Implemented

> Suse11 repo missing from Install Wizard Review Page
> ---
>
> Key: AMBARI-5887
> URL: https://issues.apache.org/jira/browse/AMBARI-5887
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 1.6.0
>Reporter: Michael Harp
> Fix For: 1.6.1
>
>
> Seeing this issue on sles11 and centos6



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