[jira] [Updated] (AMBARI-14383) Add support for Ranger TagSync process as a component under RANGER

[Gautam Borad (JIRA)]

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

Gautam Borad updated AMBARI-14383:
--
Status: Patch Available  (was: In Progress)

> Add support for Ranger TagSync process as a component under RANGER
> --
>
> Key: AMBARI-14383
> URL: https://issues.apache.org/jira/browse/AMBARI-14383
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0
>
> Attachments: AMBARI-14383.1.patch, AMBARI-14383.2.patch, 
> AMBARI-14383.patch
>
>
> Ranger TagSync is a separate service that will be responsible for 
> synchronizing the tags from Apache Atlas into Apache Ranger (db).
> This jira will track changes required to install/configure TagSync from 
> Ambari.
> * Add Ranger TagSync component under existing RANGER service. 
> * The component will be a master component
> * Ability to start/stop the component independently of Ranger Admin.
> * Ability to install the component on any host of the cluster
> * Support should be available only from HDP 2.3
> * Any other changes required in Ambari stack to support such component



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

[jira] [Commented] (AMBARI-15656) Record and Expose Alert Occurrence Values

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-15656:


{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12796395/AMBARI-15656.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:green}+1 core tests{color}.  The patch passed unit tests in 
ambari-server.

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

This message is automatically generated.

> Record and Expose Alert Occurrence Values
> -
>
> Key: AMBARI-15656
> URL: https://issues.apache.org/jira/browse/AMBARI-15656
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-15656.patch
>
>
> Alert repeat tolerance values should be captured and exposed via the API. The 
> rules for capturing the occurrences of an alert are:
> - Alert instances always start at 1
> - Alerts with an {{OK}} state always reset the counter
> - When transitioning from {{OK}} to non-{{OK}}, the counter is reset
> - When transitioning within non-{{OK}} states (such as back and forth between 
> {{WARNING}} and {{CRITICAL}}, the counter is merely incremented.
> {code}
> GET api/v1/clusters/c1/alerts/1
> {
>   "href": "http://localhost:8080/api/v1/clusters/c1/alerts/1;,
>   "Alert": {
> "cluster_name": "c1",
> ...
> "repeat_tolerance": 1,
> "repeat_tolerance_remaining": 0,
> "occurrences": 8,
> 
> {code}
> - {{OK}} alert instances will *always* have a value of {{0}} for 
> {{repeat_tolerance_remaining}} since they do not honor repeat tolerance. An 
> {{OK}} alert is considered to be correct always.



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

[jira] [Updated] (AMBARI-14383) Add support for Ranger TagSync process as a component under RANGER

[Gautam Borad (JIRA)]

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

Gautam Borad updated AMBARI-14383:
--
Attachment: AMBARI-14383.2.patch

> Add support for Ranger TagSync process as a component under RANGER
> --
>
> Key: AMBARI-14383
> URL: https://issues.apache.org/jira/browse/AMBARI-14383
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0
>
> Attachments: AMBARI-14383.1.patch, AMBARI-14383.2.patch, 
> AMBARI-14383.patch
>
>
> Ranger TagSync is a separate service that will be responsible for 
> synchronizing the tags from Apache Atlas into Apache Ranger (db).
> This jira will track changes required to install/configure TagSync from 
> Ambari.
> * Add Ranger TagSync component under existing RANGER service. 
> * The component will be a master component
> * Ability to start/stop the component independently of Ranger Admin.
> * Ability to install the component on any host of the cluster
> * Support should be available only from HDP 2.3
> * Any other changes required in Ambari stack to support such component



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

[jira] [Updated] (AMBARI-14383) Add support for Ranger TagSync process as a component under RANGER

[Gautam Borad (JIRA)]

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

Gautam Borad updated AMBARI-14383:
--
Status: In Progress  (was: Patch Available)

> Add support for Ranger TagSync process as a component under RANGER
> --
>
> Key: AMBARI-14383
> URL: https://issues.apache.org/jira/browse/AMBARI-14383
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0
>
> Attachments: AMBARI-14383.1.patch, AMBARI-14383.2.patch, 
> AMBARI-14383.patch
>
>
> Ranger TagSync is a separate service that will be responsible for 
> synchronizing the tags from Apache Atlas into Apache Ranger (db).
> This jira will track changes required to install/configure TagSync from 
> Ambari.
> * Add Ranger TagSync component under existing RANGER service. 
> * The component will be a master component
> * Ability to start/stop the component independently of Ranger Admin.
> * Ability to install the component on any host of the cluster
> * Support should be available only from HDP 2.3
> * Any other changes required in Ambari stack to support such component



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

[jira] [Updated] (AMBARI-14383) Add support for Ranger TagSync process as a component under RANGER

[Gautam Borad (JIRA)]

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

Gautam Borad updated AMBARI-14383:
--
Attachment: AMBARI-14383.2.patch

> Add support for Ranger TagSync process as a component under RANGER
> --
>
> Key: AMBARI-14383
> URL: https://issues.apache.org/jira/browse/AMBARI-14383
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0
>
> Attachments: AMBARI-14383.1.patch, AMBARI-14383.2.patch, 
> AMBARI-14383.patch
>
>
> Ranger TagSync is a separate service that will be responsible for 
> synchronizing the tags from Apache Atlas into Apache Ranger (db).
> This jira will track changes required to install/configure TagSync from 
> Ambari.
> * Add Ranger TagSync component under existing RANGER service. 
> * The component will be a master component
> * Ability to start/stop the component independently of Ranger Admin.
> * Ability to install the component on any host of the cluster
> * Support should be available only from HDP 2.3
> * Any other changes required in Ambari stack to support such component



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

[jira] [Updated] (AMBARI-15628) Ranger: update code for jdbc according to new logic

[Mugdha Varadkar (JIRA)]

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

Mugdha Varadkar updated AMBARI-15628:
-
Status: Patch Available  (was: In Progress)

> Ranger: update code for jdbc according to new logic
> ---
>
> Key: AMBARI-15628
> URL: https://issues.apache.org/jira/browse/AMBARI-15628
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: ambari-2.4.0
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Critical
> Fix For: ambari-2.4.0
>
> Attachments: AMBARI-15628.1.patch, AMBARI-15628.2.patch, 
> AMBARI-15628.3.patch, AMBARI-15628.patch
>
>
> After code changes from AMBARI-15390, need to update Ranger, Ranger Plugin 
> and Ranger KMS code to support real time name for jdbc jar.



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

[jira] [Updated] (AMBARI-15628) Ranger: update code for jdbc according to new logic

[Mugdha Varadkar (JIRA)]

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

Mugdha Varadkar updated AMBARI-15628:
-
Attachment: AMBARI-15628.3.patch

> Ranger: update code for jdbc according to new logic
> ---
>
> Key: AMBARI-15628
> URL: https://issues.apache.org/jira/browse/AMBARI-15628
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: ambari-2.4.0
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Critical
> Fix For: ambari-2.4.0
>
> Attachments: AMBARI-15628.1.patch, AMBARI-15628.2.patch, 
> AMBARI-15628.3.patch, AMBARI-15628.patch
>
>
> After code changes from AMBARI-15390, need to update Ranger, Ranger Plugin 
> and Ranger KMS code to support real time name for jdbc jar.



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

[jira] [Commented] (AMBARI-15637) If RU/EU is paused, services are restarted on the older version. EU is more complex since stopping services should use the original version.

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15637:
-

FAILURE: Integrated in Ambari-trunk-Commit #4578 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4578/])
AMBARI-15637. If RU/EU is paused, services are restarted on the older 
(afernandez: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=6fe7f83277a269dc6d9634b186ff3fc05fca8505])
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
* 
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/UpgradeEntity.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java
* ambari-server/src/main/java/org/apache/ambari/server/state/Cluster.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UpgradeResourceProviderTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
* 
ambari-server/src/test/java/org/apache/ambari/server/orm/dao/UpgradeDAOTest.java
* ambari-server/src/main/java/org/apache/ambari/server/orm/dao/UpgradeDAO.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
* 
ambari-server/src/test/resources/stacks/HDP/2.2.0/upgrades/upgrade_test_skip_failures.xml
* 
ambari-funtest/src/test/resources/stacks/HDP/2.2.0/upgrades/upgrade_test_skip_failures.xml
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java


> If RU/EU is paused, services are restarted on the older version. EU is more 
> complex since stopping services should use the original version.
> 
>
> Key: AMBARI-15637
> URL: https://issues.apache.org/jira/browse/AMBARI-15637
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Alejandro Fernandez
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15637.branch-2.2.patch, AMBARI-15637.trunk.patch
>
>
> Currently, if RU/EU is paused, then restarting services manually will use the 
> version whose state is CURRENT. This means that services may be restarted on 
> the wrong version, preventing Ambari from correctly Finalizing the upgrade.
> Instead, the logic should be as follows during Upgrade:
> RU: always use to_version
> EU: if haven't completed the action "UPDATE_DESIRED_STACK_ID", then use the 
> from_version, otherwise, use the to_version.
> During Downgrade, both should use the original version, which is actually the 
> to_version column in the upgrade table.
> Assertions:
> A: restart a service (should have version parameter,
> B: run a service check (no version needed)
> C: run HDFS Rebalance (should have version parameter).
> Test Cases:
> 1. Before stack upgrade, run A, B, and C, which should all use the current 
> version
> 2. EU, immediately click pause. Run A, B, and C, which should use the 
> original version if it exists
> 3. EU, after the services have been stopped and the stack has been upgraded. 
> Run A, B, and C, which should use the new version since the services are now 
> to be started.
> 4. EU, click downgrade and pause. Run A, B, C, which should use the original 
> version.
> 5. RU, click pause whenever a manual task occurs. Run A, B, and C, which 
> should use the destination version.
> 6. RU, click downgrade. Run A, B, and C, which should use the original 
> version.



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

[jira] [Commented] (AMBARI-15655) Remove remaining hdp specific logic from resource_management library

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-15655:


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

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

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

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

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

This message is automatically generated.

> Remove remaining hdp specific logic from resource_management library
> 
>
> Key: AMBARI-15655
> URL: https://issues.apache.org/jira/browse/AMBARI-15655
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent, ambari-server
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15655.2.patch, AMBARI-15655.patch
>
>
> Remove remaining HDP specific logic from resource_management. 
> AMBARI-15420 didnt cover them as this need stack_featurization changes.
> TODOs:
> 1. Cleanup HDP hardcodings in custom_actions scripts
> 2. Cleanup HDP hardcodings in configurations especially in common-services
> 3. Stack-driven configs for lzo-packages, list of repos etc.



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

[jira] [Commented] (AMBARI-15654) ambari-server database check is failing due to EOF Error

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-15654:


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

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

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

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

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

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

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

This message is automatically generated.

> ambari-server database check is failing due to EOF Error
> 
>
> Key: AMBARI-15654
> URL: https://issues.apache.org/jira/browse/AMBARI-15654
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Blocker
> Fix For: 2.2.2
>
> Attachments: AMBARI-15654.patch
>
>
> Tests for encrypt passwords are failing on DB check.
> STR:
> setup -> encrypt (persist master) -> setup-ldap -> encrypt (persist master) 
> -> start
> All tests run ambari-server db checks as part of qe framework. For all 
> encrypt password tests this check is failing due to below error



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

[jira] [Moved] (AMBARI-15664) upgrading the HDP stack through Ambari (from 2.3 to 2.4)

[Akira AJISAKA (JIRA)]

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

Akira AJISAKA moved HADOOP-12988 to AMBARI-15664:
-

Assignee: (was: Ali Bajwa)
 Key: AMBARI-15664  (was: HADOOP-12988)
 Project: Ambari  (was: Hadoop Common)

> upgrading the HDP stack through Ambari (from 2.3 to 2.4)
> 
>
> Key: AMBARI-15664
> URL: https://issues.apache.org/jira/browse/AMBARI-15664
> Project: Ambari
>  Issue Type: Bug
> Environment: SLES11 SP4
>Reporter: Arun Singh
>
>  - Issue 3: When upgrading the HDP stack through Ambari (from 2.3 to 2.4), at 
> some point a YARN smokescreen test is performed. This smoke screen test 
> fails, as it is trying to call an API command using curl with the --negotiate 
> option. The problem is that on SUSE 11, the version of curl does not ship 
> with one that understands "--negotiate", grinding the whole upgrade process 
> to a halt. 
>  
> There are quite a few files in Ambari where this seems to be the case, 
> although I personally only encountered it during the YARN component: 
> /var/lib/ambari-server/resources/common-services/RANGER/0.4.0/package/scripts/service_check.py:
>   
> Execute(format("curl -s -o /dev/null -w'%{{http_code}}' --negotiate -u: 
> -k {ranger_external_url}/login.jsp | grep 200"),
> /var/lib/ambari-server/resources/common-services/SPARK/1.2.0.2.2/package/scripts/service_check.py:
> 
> Execute(format("curl -s -o /dev/null -w'%{{http_code}}' --negotiate -u: 
> -khttp://{spark_history_server_host}:{spark_history_ui_port} | grep 200"),
> /var/lib/ambari-server/resources/common-services/YARN/2.1.0.2.0/package/scripts/service_check.py:
>   
> get_app_info_cmd = "curl --negotiate -u : -ksL --connect-timeout " + 
> CURL_CONNECTION_TIMEOUT + " " + info_app_url
> /var/lib/ambari-server/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py:
> 
> smoke_cmd = format('curl --negotiate -u : -b ~/cookiejar.txt -c 
> ~/cookiejar.txt -s -o /dev/null -w 
> "%{{http_code}}"http://{metadata_host}:{metadata_port}/')
> /var/lib/ambari-server/resources/common-services/HIVE/0.12.0.2.0/package/files/templetonSmoke.sh:
> cmd="${kinitcmd}curl --negotiate -u : -s -w 'http_code <%{http_code}>'  
> $ttonurl/status 2>&1"
> /var/lib/ambari-server/resources/common-services/HIVE/0.12.0.2.0/package/files/templetonSmoke.sh:
>   
> cmd="${kinitcmd}curl --negotiate -u : -s -w 'http_code <%{http_code}>'  
> $ttonurl/status?user.name=$smoke_test_user 2>&1"
> /var/lib/ambari-server/resources/common-services/HIVE/0.12.0.2.0/package/files/templetonSmoke.sh:
> cmd="${kinitcmd}curl --negotiate -u : -s -w 'http_code <%{http_code}>' -d 
>  \@${destdir}/show_db.post.txt  $ttonurl/ddl 2>&1"
> For example, in this file: 
> /var/lib/ambari-server/resources/common-services/YARN/2.1.0.2.0/package/scripts/service_check.py
> You will see the code as:
> for rm_webapp_address in params.rm_webapp_addresses_list:
>   info_app_url = params.scheme + "://" + rm_webapp_address + 
> "/ws/v1/cluster/apps/" + application_name
>   get_app_info_cmd = "curl --negotiate -u : -ksL --connect-timeout " + 
> CURL_CONNECTION_TIMEOUT + " " + info_app_url
>   return_code, stdout, _ = get_user_call_output(get_app_info_cmd,
> user=params.smokeuser,
> 
> path='/usr/sbin:/sbin:/usr/local/bin:/bin:/usr/bin',
> )
>  
>  
> There is no code checking whether RHEL vs SUSE, to run the correct usage of 
> curl. Or alternatively, there is no code to check for version of curl, and 
> run a "deprecated" version of the command as a fallback should it detect that 
> the installed curl does not support --negotiate. This is just blindly 
> assuming to work on SUSE 11 (or any version of curl). 
>  
> Information about the curl installed on the system: 
> hdplab02:~ # curl -V 
> curl 7.45.0 (x86_64-pc-linux-gnu) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 
> Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp 
> smb smbs smtp smtps telnet tftp 
> Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets
>  



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

[jira] [Commented] (AMBARI-15658) If there is a host with no components then host page spins

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15658:
-

SUCCESS: Integrated in Ambari-trunk-Commit #4577 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4577/])
AMBARI-15658. If there is a host with no components then host page spins 
(rzang: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=b0d6a57819cfac1d950f1ce7bbde4ef739c90ca8])
* ambari-web/app/mappers/hosts_mapper.js


> If there is a host with no components then host page spins
> --
>
> Key: AMBARI-15658
> URL: https://issues.apache.org/jira/browse/AMBARI-15658
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.4.0
>
> Attachments: AMBARI-15658.patch
>
>
> If there is a host with no components then host page spins



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

[jira] [Commented] (AMBARI-15637) If RU/EU is paused, services are restarted on the older version. EU is more complex since stopping services should use the original version.

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15637:
-

SUCCESS: Integrated in Ambari-branch-2.2 #579 (See 
[https://builds.apache.org/job/Ambari-branch-2.2/579/])
AMBARI-15637. If RU/EU is paused, services are restarted on the older 
(afernandez: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=aa59546bbfdf2c4c92aaa724be4e64ab4b80ea72])
* ambari-server/src/main/java/org/apache/ambari/server/state/Cluster.java
* 
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostRoleCommandEntity.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UpgradeResourceProviderTest.java
* 
ambari-server/src/test/resources/stacks/HDP/2.2.0/upgrades/upgrade_test_skip_failures.xml
* 
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/UpgradeEntity.java
* ambari-server/src/main/java/org/apache/ambari/server/orm/dao/UpgradeDAO.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
* 
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandDAO.java
* 
ambari-server/src/test/java/org/apache/ambari/server/orm/dao/UpgradeDAOTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java


> If RU/EU is paused, services are restarted on the older version. EU is more 
> complex since stopping services should use the original version.
> 
>
> Key: AMBARI-15637
> URL: https://issues.apache.org/jira/browse/AMBARI-15637
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Alejandro Fernandez
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15637.branch-2.2.patch, AMBARI-15637.trunk.patch
>
>
> Currently, if RU/EU is paused, then restarting services manually will use the 
> version whose state is CURRENT. This means that services may be restarted on 
> the wrong version, preventing Ambari from correctly Finalizing the upgrade.
> Instead, the logic should be as follows during Upgrade:
> RU: always use to_version
> EU: if haven't completed the action "UPDATE_DESIRED_STACK_ID", then use the 
> from_version, otherwise, use the to_version.
> During Downgrade, both should use the original version, which is actually the 
> to_version column in the upgrade table.
> Assertions:
> A: restart a service (should have version parameter,
> B: run a service check (no version needed)
> C: run HDFS Rebalance (should have version parameter).
> Test Cases:
> 1. Before stack upgrade, run A, B, and C, which should all use the current 
> version
> 2. EU, immediately click pause. Run A, B, and C, which should use the 
> original version if it exists
> 3. EU, after the services have been stopped and the stack has been upgraded. 
> Run A, B, and C, which should use the new version since the services are now 
> to be started.
> 4. EU, click downgrade and pause. Run A, B, C, which should use the original 
> version.
> 5. RU, click pause whenever a manual task occurs. Run A, B, and C, which 
> should use the destination version.
> 6. RU, click downgrade. Run A, B, and C, which should use the original 
> version.



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

[jira] [Commented] (AMBARI-15628) Ranger: update code for jdbc according to new logic

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-15628:


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

This message is automatically generated.

> Ranger: update code for jdbc according to new logic
> ---
>
> Key: AMBARI-15628
> URL: https://issues.apache.org/jira/browse/AMBARI-15628
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: ambari-2.4.0
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Critical
> Fix For: ambari-2.4.0
>
> Attachments: AMBARI-15628.1.patch, AMBARI-15628.2.patch, 
> AMBARI-15628.patch
>
>
> After code changes from AMBARI-15390, need to update Ranger, Ranger Plugin 
> and Ranger KMS code to support real time name for jdbc jar.



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

[jira] [Commented] (AMBARI-14627) Ability to automate setup-security and setup-ldap/sync-ldap

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-14627:


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

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

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

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

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

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

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

This message is automatically generated.

> Ability to automate setup-security and setup-ldap/sync-ldap
> ---
>
> Key: AMBARI-14627
> URL: https://issues.apache.org/jira/browse/AMBARI-14627
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.1
>Reporter: Krisztian Horvath
>Assignee: Olivér Szabó
> Fix For: 2.4.0
>
> Attachments: AMBARI-14627_v5.patch
>
>
> Currently the ambari-server setup-security command does not have any options 
> thus it's interactive. This makes it really hard to automate this process. 
> For kerberos 1 option should be enough for setting the master key.
> Same for setup-ldap and sync-ldap



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

[jira] [Updated] (AMBARI-15663) Ambari Management Packs - Initial version

[Jayush Luniya (JIRA)]

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

Jayush Luniya updated AMBARI-15663:
---
Attachment: AMBARI-15663.patch

> Ambari Management Packs - Initial version
> -
>
> Key: AMBARI-15663
> URL: https://issues.apache.org/jira/browse/AMBARI-15663
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15663.patch
>
>




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

[jira] [Created] (AMBARI-15661) Add Upgrade Management Pack option (ambari-server upgrade-mpack)

[Jayush Luniya (JIRA)]

Jayush Luniya created AMBARI-15661:
--

 Summary: Add Upgrade Management Pack option (ambari-server 
upgrade-mpack)
 Key: AMBARI-15661
 URL: https://issues.apache.org/jira/browse/AMBARI-15661
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.4.0
Reporter: Jayush Luniya
Assignee: Jayush Luniya
 Fix For: 2.4.0






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

[jira] [Created] (AMBARI-15662) Ambari Server Upgrade should not cause mpacks and related stacks to be wiped out

[Jayush Luniya (JIRA)]

Jayush Luniya created AMBARI-15662:
--

 Summary: Ambari Server Upgrade should not cause mpacks and related 
stacks to be wiped out
 Key: AMBARI-15662
 URL: https://issues.apache.org/jira/browse/AMBARI-15662
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.4.0
Reporter: Jayush Luniya
Assignee: Jayush Luniya
 Fix For: 2.4.0






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

[jira] [Created] (AMBARI-15660) Add Install Management Packs option (ambari-server install-mpack)

[Jayush Luniya (JIRA)]

Jayush Luniya created AMBARI-15660:
--

 Summary: Add Install Management Packs option (ambari-server 
install-mpack)
 Key: AMBARI-15660
 URL: https://issues.apache.org/jira/browse/AMBARI-15660
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.4.0
Reporter: Jayush Luniya
Assignee: Jayush Luniya
 Fix For: 2.4.0






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

[jira] [Updated] (AMBARI-15637) If RU/EU is paused, services are restarted on the older version. EU is more complex since stopping services should use the original version.

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-15637:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Pushed to trunk,
commit 6fe7f83277a269dc6d9634b186ff3fc05fca8505

Pushed to branch-2.2,
commit aa59546bbfdf2c4c92aaa724be4e64ab4b80ea72

> If RU/EU is paused, services are restarted on the older version. EU is more 
> complex since stopping services should use the original version.
> 
>
> Key: AMBARI-15637
> URL: https://issues.apache.org/jira/browse/AMBARI-15637
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Alejandro Fernandez
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15637.branch-2.2.patch, AMBARI-15637.trunk.patch
>
>
> Currently, if RU/EU is paused, then restarting services manually will use the 
> version whose state is CURRENT. This means that services may be restarted on 
> the wrong version, preventing Ambari from correctly Finalizing the upgrade.
> Instead, the logic should be as follows during Upgrade:
> RU: always use to_version
> EU: if haven't completed the action "UPDATE_DESIRED_STACK_ID", then use the 
> from_version, otherwise, use the to_version.
> During Downgrade, both should use the original version, which is actually the 
> to_version column in the upgrade table.
> Assertions:
> A: restart a service (should have version parameter,
> B: run a service check (no version needed)
> C: run HDFS Rebalance (should have version parameter).
> Test Cases:
> 1. Before stack upgrade, run A, B, and C, which should all use the current 
> version
> 2. EU, immediately click pause. Run A, B, and C, which should use the 
> original version if it exists
> 3. EU, after the services have been stopped and the stack has been upgraded. 
> Run A, B, and C, which should use the new version since the services are now 
> to be started.
> 4. EU, click downgrade and pause. Run A, B, C, which should use the original 
> version.
> 5. RU, click pause whenever a manual task occurs. Run A, B, and C, which 
> should use the destination version.
> 6. RU, click downgrade. Run A, B, and C, which should use the original 
> version.



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

[jira] [Commented] (AMBARI-15579) Stack Featurize Falcon service

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15579:
-

SUCCESS: Integrated in Ambari-trunk-Commit #4576 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4576/])
AMBARI-15579: Stack Featurize Falcon service (jluniya) (jluniya: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=4ecd3c7620edcfa1ced4a25abd022c21f42960af])
* 
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/params_linux.py
* 
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon_server.py
* 
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/status_params.py
* 
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon_client.py


> Stack Featurize Falcon service
> --
>
> Key: AMBARI-15579
> URL: https://issues.apache.org/jira/browse/AMBARI-15579
> Project: Ambari
>  Issue Type: Technical task
>  Components: stacks
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15579.patch
>
>




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

[jira] [Commented] (AMBARI-15575) Stack Featurize Knox Service

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15575:
-

SUCCESS: Integrated in Ambari-trunk-Commit #4576 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4576/])
AMBARI-15575: Stack Featurize Knox Service (jluniya) (jluniya: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=1d6ca13aec42e864235d9b5fa3047cbc1e9c0f7c])
* 
ambari-common/src/main/python/resource_management/libraries/functions/stack_features.py
* 
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/knox_gateway.py
* 
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/upgrade.py
* 
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/knox.py
* 
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/params_linux.py
* 
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/status_params.py
* 
ambari-server/src/main/resources/stacks/HDP/2.0.6/properties/stack_features.json
* 
ambari-common/src/main/python/resource_management/libraries/functions/constants.py


> Stack Featurize Knox Service
> 
>
> Key: AMBARI-15575
> URL: https://issues.apache.org/jira/browse/AMBARI-15575
> Project: Ambari
>  Issue Type: Technical task
>  Components: stacks
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15575.patch
>
>




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

[jira] [Created] (AMBARI-15659) HortonWorks Zeppelin SUSE Install issue in HDP 2.4

[Arun Singh (JIRA)]

Arun Singh created AMBARI-15659:
---

 Summary: HortonWorks Zeppelin SUSE Install issue in HDP 2.4
 Key: AMBARI-15659
 URL: https://issues.apache.org/jira/browse/AMBARI-15659
 Project: Ambari
  Issue Type: Bug
 Environment: SLES11 SP4
Reporter: Arun Singh


Issue 2: Zeppelin. Zeppelin is a new component in Tech Preview in the latest 
HDP stack (2.4). I've been following this guide: 
http://hortonworks.com/hadoop-tutorial/apache-zeppelin-hdp-2-4/
   When installing Zeppelin through the Ambari interface, it errors out with a 
message saying it can't install the package gcc-gfortran
 
   If you open the file: 
/var/lib/ambari-server/resources/stacks/HDP/2.4/services/ZEPPELIN/metainfo.xml 
 Line 72: 
 
  redhat7,redhat6,redhat5,suse11 
 
   
gcc-gfortran 
   
   
blas-devel 
   
   
lapack-devel 
   
   
python-devel 
   
   
 python-pip 
   
   
zeppelin 
   
 
 

This list packages to install on SUSE11, but you don't find these packages on 
SUSE11 as they have different names than the RHEL ones... 
Eg: 
RHEL: gcc-gfortran 
SUSE: gcc-fortran 

RHEL: blas-devel 
SUSE: libblas3 ? 

RHEL: lapack-devel 
SUSE: liblapack3 ? 

RHEL: python-dev 
SUSE: python-devel 

RHEL: python-pip 
SUSE: doesn't seem to be part of the standard repo 

Solution: Make a custom  for SUSE 11, with the correct 
named packages as they are named on SUSE 11




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

[jira] [Commented] (AMBARI-15640) Missing Properties in Kafka Config Tab

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15640:
-

FAILURE: Integrated in Ambari-branch-2.2 #578 (See 
[https://builds.apache.org/job/Ambari-branch-2.2/578/])
AMBARI-15640. Missing Properties in Kafka Config Tab. (jaimin) (jaimin: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=3b11cf2ff9a291961bd7f80306b7a81bf80d69d4])
* 
ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/configuration/kafka-env.xml


> Missing Properties in Kafka Config Tab
> --
>
> Key: AMBARI-15640
> URL: https://issues.apache.org/jira/browse/AMBARI-15640
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Dhanya Balasundaran
>Assignee: Jaimin D Jetly
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-15640.patch
>
>
> call 
> /api/v1/clusters/cl1/configurations/service_config_versions?service_name.in(KAFKA)_current=true
> This api will provide the list of properties which need to be shown on the UI.
> Properties retrieved includes, kafka_keytab and kafka_principal_name.
> But these 2 properties are not present on UI at Kafka Configs tab



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

[jira] [Updated] (AMBARI-15658) If there is a host with no components then host page spins

[Richard Zang (JIRA)]

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

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

committed to trunk b0d6a57819cfac1d950f1ce7bbde4ef739c90ca8

> If there is a host with no components then host page spins
> --
>
> Key: AMBARI-15658
> URL: https://issues.apache.org/jira/browse/AMBARI-15658
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.4.0
>
> Attachments: AMBARI-15658.patch
>
>
> If there is a host with no components then host page spins



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

[jira] [Updated] (AMBARI-15658) If there is a host with no components then host page spins

[Richard Zang (JIRA)]

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

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

> If there is a host with no components then host page spins
> --
>
> Key: AMBARI-15658
> URL: https://issues.apache.org/jira/browse/AMBARI-15658
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.4.0
>
> Attachments: AMBARI-15658.patch
>
>
> If there is a host with no components then host page spins



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

[jira] [Commented] (AMBARI-15443) Make Host bulk command menu item list stack driven instead of a hardcoded list in UI code

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15443:
-

FAILURE: Integrated in Ambari-trunk-Commit #4575 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4575/])
AMBARI-15443:Make Host bulk command menu item list stack driven instead (dili: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=2410929485dc8d8b3baac28528d8762322d748a4])
* ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/metainfo.xml
* ambari-web/app/models/stack_service_component.js
* ambari-server/src/test/resources/stacks/HDP/2.0.5/services/HDFS/metainfo.xml
* ambari-server/src/test/resources/stacks/HDP/2.0.6/services/HBASE/metainfo.xml
* ambari-server/src/test/resources/stacks/HDP/2.0.5/services/HBASE/metainfo.xml
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StackServiceComponentResourceProvider.java
* ambari-server/src/main/resources/common-services/PXF/3.0.0/metainfo.xml
* ambari-server/src/main/resources/common-services/HAWQ/2.0.0/metainfo.xml
* ambari-web/app/mappers/stack_service_mapper.js
* ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/metainfo.xml
* ambari-web/app/views/main/host/hosts_table_menu_view.js
* ambari-server/src/main/java/org/apache/ambari/server/state/ComponentInfo.java
* ambari-server/src/main/resources/properties.json
* ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/metainfo.xml
* 
ambari-server/src/main/java/org/apache/ambari/server/state/BulkCommandDefinition.java
* 
ambari-server/src/test/java/org/apache/ambari/server/stack/ComponentModuleTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/stack/ComponentModule.java
* ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/metainfo.xml
* ambari-web/test/mappers/stack_service_mapper_test.js
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/StackServiceComponentResponse.java


> Make Host bulk command menu item list stack driven instead of a hardcoded 
> list in UI code
> -
>
> Key: AMBARI-15443
> URL: https://issues.apache.org/jira/browse/AMBARI-15443
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server, ambari-web
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
> Fix For: trunk
>
> Attachments: AMBARI-15443.patch
>
>
> The items described here are the ones on the Hosts tab, in the Actions 
> drop-down list where the UI shows entries such as All Hosts. If user mouses 
> over the All Hosts, it shows a sub-list including Hosts and slave components. 
> The slave component items are hardcoded in hosts_table_menu_view.js as shown 
> below. This jira is to put this info into each service's metainfo.xml so that 
> the slave component items can be stack driven.
> components: function () {
> var serviceNames = App.Service.find().mapProperty('serviceName');
> var menuItems = [
>   O.create({
> serviceName: 'HDFS',
> componentName: 'DATANODE',
> masterComponentName: 'NAMENODE',
> componentNameFormatted: Em.I18n.t('dashboard.services.hdfs.datanodes')
>   }),
>   O.create({
> serviceName: 'YARN',
> componentName: 'NODEMANAGER',
> masterComponentName: 'RESOURCEMANAGER',
> componentNameFormatted: 
> Em.I18n.t('dashboard.services.yarn.nodeManagers')
>   }),
>   O.create({
> serviceName: 'HBASE',
> componentName: 'HBASE_REGIONSERVER',
> masterComponentName: 'HBASE_MASTER',
> componentNameFormatted: 
> Em.I18n.t('dashboard.services.hbase.regionServers')
>   }),
>   O.create({
> serviceName: 'STORM',
> componentName: 'SUPERVISOR',
> masterComponentName: 'SUPERVISOR',
> componentNameFormatted: 
> Em.I18n.t('dashboard.services.storm.supervisors')
>   })];
> return menuItems.filter(function (item) {
>   return serviceNames.contains(item.serviceName);
> });
>   }.property(),



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

[jira] [Commented] (AMBARI-15580) Stack Featurize Flume Service

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15580:
-

FAILURE: Integrated in Ambari-trunk-Commit #4575 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4575/])
AMBARI-15580: Stack Featurize Flume Service (jluniya) (jluniya: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=0c4b2954963b5975557de664e7f3d08dde3f29f3])
* 
ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/package/scripts/params_linux.py
* 
ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/package/scripts/params.py
* 
ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/package/scripts/flume_handler.py


> Stack Featurize Flume Service
> -
>
> Key: AMBARI-15580
> URL: https://issues.apache.org/jira/browse/AMBARI-15580
> Project: Ambari
>  Issue Type: Technical task
>  Components: stacks
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15580.patch
>
>




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

[jira] [Commented] (AMBARI-15640) Missing Properties in Kafka Config Tab

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15640:
-

FAILURE: Integrated in Ambari-trunk-Commit #4575 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4575/])
AMBARI-15640. Missing Properties in Kafka Config Tab. (jaimin) (jaimin: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=490fa51f104ce4a87469069fc72033ace08d537f])
* 
ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/configuration/kafka-env.xml


> Missing Properties in Kafka Config Tab
> --
>
> Key: AMBARI-15640
> URL: https://issues.apache.org/jira/browse/AMBARI-15640
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Dhanya Balasundaran
>Assignee: Jaimin D Jetly
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-15640.patch
>
>
> call 
> /api/v1/clusters/cl1/configurations/service_config_versions?service_name.in(KAFKA)_current=true
> This api will provide the list of properties which need to be shown on the UI.
> Properties retrieved includes, kafka_keytab and kafka_principal_name.
> But these 2 properties are not present on UI at Kafka Configs tab



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

[jira] [Commented] (AMBARI-15653) Blueprint installation with Hive without Atlas fails

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15653:
-

FAILURE: Integrated in Ambari-trunk-Commit #4575 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4575/])
AMBARI-15653. Blueprint installation with Hive without Atlas fails  (aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=2b122b3b70c115d60f9c042e625c0b6e4422fbc3])
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java


> Blueprint installation with Hive without Atlas fails 
> -
>
> Key: AMBARI-15653
> URL: https://issues.apache.org/jira/browse/AMBARI-15653
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15653.patch
>
>
> 31 Mar 2016 15:55:55,479  INFO [qtp-ambari-client-22] 
> AmbariManagementControllerImpl:1445 - Received a updateCluster request, 
> clusterId=null, clusterName=c1, securityType=null, request={ clusterName=c1, 
> clusterId=null, provisioningState=INSTALLED, securityType=null, 
> stackVersion=HDP-2.4, desired_scv=null, hosts=[] }
> 31 Mar 2016 15:55:55,502 ERROR [pool-11-thread-1] TopologyManager:762 - 
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting 
> to process cluster configs and set on cluster: 
> java.lang.IllegalArgumentException: Unable to update configuration 
> property 'atlas.rest.address' with topology information. Component 
> 'ATLAS_SERVER' is mapped to an invalid number of hosts '0'.
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor$SingleHostTopologyUpdater.updateForClusterCreate(BlueprintConfigurationProcessor.java:1328)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForClusterCreate(BlueprintConfigurationProcessor.java:263)
> at 
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:150)
> at 
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:760)
> at 
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:734)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 31 Mar 2016 15:55:55,502  INFO [pool-2-thread-1] AsyncCallableService:111 
> - Exception during task execution: 
> java.util.concurrent.ExecutionException: java.lang.Exception: 
> java.lang.IllegalArgumentException: Unable to update configuration property 
> 'atlas.rest.address' with topology information. Component 'ATLAS_SERVER' is 
> mapped to an invalid number of hosts '0'.
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at 
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at 
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at 
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.Exception: java.lang.IllegalArgumentException: 
> Unable to update configuration property 'atlas.rest.address' with topology 
> information. Component 'ATLAS_SERVER' is mapped to an invalid number of hosts 
> '0'.
> at 
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:766)
> at 
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:734)
> at 

[jira] [Commented] (AMBARI-15647) Alerts Using the SKIPPED State Cause Stale Alert Notification

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15647:
-

FAILURE: Integrated in Ambari-trunk-Commit #4575 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4575/])
AMBARI-15647 - Alerts Using the SKIPPED State Cause Stale Alert (jhurley: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=449be0f5c8c3a06b2f414d53e91136f66c0f1743])
* ambari-agent/src/main/python/ambari_agent/alerts/base_alert.py
* ambari-server/src/main/java/org/apache/ambari/server/state/AlertState.java
* 
ambari-server/src/main/java/org/apache/ambari/server/events/listeners/alerts/AlertReceivedListener.java
* ambari-agent/src/test/python/ambari_agent/TestAlerts.py
* 
ambari-server/src/test/java/org/apache/ambari/server/state/alerts/AlertReceivedListenerTest.java


> Alerts Using the SKIPPED State Cause Stale Alert Notification
> -
>
> Key: AMBARI-15647
> URL: https://issues.apache.org/jira/browse/AMBARI-15647
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
> Fix For: 2.4.0
>
> Attachments: AMBARI-15647.patch
>
>
> SCRIPT alerts which use the {{SKIPPED}} state as a way of preventing 
> processing are causing instances of the Ambari Stale Alert to trigger. This 
> is because the agents do not return these alerts in the heartbeat causing 
> their timestamps not to update.
> STR:
> - Create a SCRIPT alert which returns {{SKIPPED}} as it's state.
> - Wait for the stale alert to trigger.
> {code}
> There are 1 stale alerts from 1 host(s): c6401.ambari.apache.org[NameNode 
> Service RPC Queue Latency (Hourly) (2h 18m), NameNode Service RPC Processing 
> Latency (Hourly) (2h 18m)]
> {code}



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

[jira] [Updated] (AMBARI-15657) HAWQ config should not allow multiple Master/Segment directories

[Lav Jain (JIRA)]

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

Lav Jain updated AMBARI-15657:
--
Attachment: AMBARI-15657.branch22.patch

> HAWQ config should not allow multiple Master/Segment directories
> 
>
> Key: AMBARI-15657
> URL: https://issues.apache.org/jira/browse/AMBARI-15657
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: trunk, 2.2.0
>Reporter: Lav Jain
>Assignee: Lav Jain
>Priority: Minor
> Attachments: AMBARI-15657.branch22.patch
>
>
> User can add multiple space delimited directories, but after installation, it 
> shows a comma in between. however, only first directory goes into effect, 
> that too with a comma in the end.
> {code}
> [pivotal@ip-10-32-36-213 etc]$ cat hawq-site.xml
> 
>   hawq_master_directory
>   /data/hawq/master,/data/hawq/master2
> 
> 
>   hawq_segment_directory
>   /data/hawq/segment,/data/hawq/segment2
> 
> [pivotal@ip-10-32-36-213 etc]$ ls -l /data/hawq
> drwxr-xr-x 3 root root 4096 Mar 12 01:00 master,
> drwxr-xr-x 3 root root 4096 Mar 12 01:00 segment,
> {code}



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

[jira] [Created] (AMBARI-15658) If there is a host with no components then host page spins

[Richard Zang (JIRA)]

Richard Zang created AMBARI-15658:
-

 Summary: If there is a host with no components then host page spins
 Key: AMBARI-15658
 URL: https://issues.apache.org/jira/browse/AMBARI-15658
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.2.0
Reporter: Richard Zang
Assignee: Richard Zang
 Fix For: 2.4.0


If there is a host with no components then host page spins



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

[jira] [Updated] (AMBARI-15637) If RU/EU is paused, services are restarted on the older version. EU is more complex since stopping services should use the original version.

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-15637:
-
Attachment: AMBARI-15637.branch-2.2.patch

> If RU/EU is paused, services are restarted on the older version. EU is more 
> complex since stopping services should use the original version.
> 
>
> Key: AMBARI-15637
> URL: https://issues.apache.org/jira/browse/AMBARI-15637
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Alejandro Fernandez
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15637.branch-2.2.patch
>
>
> Currently, if RU/EU is paused, then restarting services manually will use the 
> version whose state is CURRENT. This means that services may be restarted on 
> the wrong version, preventing Ambari from correctly Finalizing the upgrade.
> Instead, the logic should be as follows during Upgrade:
> RU: always use to_version
> EU: if haven't completed the action "UPDATE_DESIRED_STACK_ID", then use the 
> from_version, otherwise, use the to_version.
> During Downgrade, both should use the original version, which is actually the 
> to_version column in the upgrade table.
> Assertions:
> A: restart a service (should have version parameter,
> B: run a service check (no version needed)
> C: run HDFS Rebalance (should have version parameter).
> Test Cases:
> 1. Before stack upgrade, run A, B, and C, which should all use the current 
> version
> 2. EU, immediately click pause. Run A, B, and C, which should use the 
> original version if it exists
> 3. EU, after the services have been stopped and the stack has been upgraded. 
> Run A, B, and C, which should use the new version since the services are now 
> to be started.
> 4. EU, click downgrade and pause. Run A, B, C, which should use the original 
> version.
> 5. RU, click pause whenever a manual task occurs. Run A, B, and C, which 
> should use the destination version.
> 6. RU, click downgrade. Run A, B, and C, which should use the original 
> version.



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

[jira] [Commented] (AMBARI-15647) Alerts Using the SKIPPED State Cause Stale Alert Notification

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15647:
-

SUCCESS: Integrated in Ambari-branch-2.2 #577 (See 
[https://builds.apache.org/job/Ambari-branch-2.2/577/])
AMBARI-15647 - Alerts Using the SKIPPED State Cause Stale Alert (jhurley: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=6c83a334140197b4da106540984711ed4eeff812])
* ambari-agent/src/main/python/ambari_agent/alerts/base_alert.py
* 
ambari-server/src/main/java/org/apache/ambari/server/events/listeners/alerts/AlertReceivedListener.java
* 
ambari-server/src/test/java/org/apache/ambari/server/state/alerts/AlertReceivedListenerTest.java
* ambari-server/src/main/java/org/apache/ambari/server/state/AlertState.java
* ambari-agent/src/test/python/ambari_agent/TestAlerts.py


> Alerts Using the SKIPPED State Cause Stale Alert Notification
> -
>
> Key: AMBARI-15647
> URL: https://issues.apache.org/jira/browse/AMBARI-15647
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
> Fix For: 2.4.0
>
> Attachments: AMBARI-15647.patch
>
>
> SCRIPT alerts which use the {{SKIPPED}} state as a way of preventing 
> processing are causing instances of the Ambari Stale Alert to trigger. This 
> is because the agents do not return these alerts in the heartbeat causing 
> their timestamps not to update.
> STR:
> - Create a SCRIPT alert which returns {{SKIPPED}} as it's state.
> - Wait for the stale alert to trigger.
> {code}
> There are 1 stale alerts from 1 host(s): c6401.ambari.apache.org[NameNode 
> Service RPC Queue Latency (Hourly) (2h 18m), NameNode Service RPC Processing 
> Latency (Hourly) (2h 18m)]
> {code}



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

[jira] [Updated] (AMBARI-15637) If RU/EU is paused, services are restarted on the older version. EU is more complex since stopping services should use the original version.

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-15637:
-
Attachment: (was: AMBARI-15637.branch-2.2.patch)

> If RU/EU is paused, services are restarted on the older version. EU is more 
> complex since stopping services should use the original version.
> 
>
> Key: AMBARI-15637
> URL: https://issues.apache.org/jira/browse/AMBARI-15637
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Alejandro Fernandez
>Priority: Critical
> Fix For: 2.2.2
>
>
> Currently, if RU/EU is paused, then restarting services manually will use the 
> version whose state is CURRENT. This means that services may be restarted on 
> the wrong version, preventing Ambari from correctly Finalizing the upgrade.
> Instead, the logic should be as follows during Upgrade:
> RU: always use to_version
> EU: if haven't completed the action "UPDATE_DESIRED_STACK_ID", then use the 
> from_version, otherwise, use the to_version.
> During Downgrade, both should use the original version, which is actually the 
> to_version column in the upgrade table.
> Assertions:
> A: restart a service (should have version parameter,
> B: run a service check (no version needed)
> C: run HDFS Rebalance (should have version parameter).
> Test Cases:
> 1. Before stack upgrade, run A, B, and C, which should all use the current 
> version
> 2. EU, immediately click pause. Run A, B, and C, which should use the 
> original version if it exists
> 3. EU, after the services have been stopped and the stack has been upgraded. 
> Run A, B, and C, which should use the new version since the services are now 
> to be started.
> 4. EU, click downgrade and pause. Run A, B, C, which should use the original 
> version.
> 5. RU, click pause whenever a manual task occurs. Run A, B, and C, which 
> should use the destination version.
> 6. RU, click downgrade. Run A, B, and C, which should use the original 
> version.



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

[jira] [Commented] (AMBARI-15575) Stack Featurize Knox Service

[Jayush Luniya (JIRA)]

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

Jayush Luniya commented on AMBARI-15575:


commit 1d6ca13aec42e864235d9b5fa3047cbc1e9c0f7c
Author: Jayush Luniya 
Date:   Thu Mar 31 13:57:06 2016 -0700

AMBARI-15575: Stack Featurize Knox Service (jluniya)

> Stack Featurize Knox Service
> 
>
> Key: AMBARI-15575
> URL: https://issues.apache.org/jira/browse/AMBARI-15575
> Project: Ambari
>  Issue Type: Technical task
>  Components: stacks
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15575.patch
>
>




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

[jira] [Updated] (AMBARI-15578) Stack Featurize Atlas Service

[Jayush Luniya (JIRA)]

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

Jayush Luniya updated AMBARI-15578:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Stack Featurize Atlas Service
> -
>
> Key: AMBARI-15578
> URL: https://issues.apache.org/jira/browse/AMBARI-15578
> Project: Ambari
>  Issue Type: Technical task
>  Components: stacks
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15578.patch
>
>




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

[jira] [Commented] (AMBARI-15578) Stack Featurize Atlas Service

[Jayush Luniya (JIRA)]

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

Jayush Luniya commented on AMBARI-15578:


commit d812b17048afbb418e87dc46212b2b165456472c
Author: Jayush Luniya 
Date:   Thu Mar 31 14:03:27 2016 -0700

AMBARI-15578: Stack Featurize Atlas Service (jluniya)

> Stack Featurize Atlas Service
> -
>
> Key: AMBARI-15578
> URL: https://issues.apache.org/jira/browse/AMBARI-15578
> Project: Ambari
>  Issue Type: Technical task
>  Components: stacks
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15578.patch
>
>




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

[jira] [Commented] (AMBARI-15579) Stack Featurize Falcon service

[Jayush Luniya (JIRA)]

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

Jayush Luniya commented on AMBARI-15579:


Ignore above comment

commit 4ecd3c7620edcfa1ced4a25abd022c21f42960af
Author: Jayush Luniya 
Date:   Thu Mar 31 13:55:46 2016 -0700

AMBARI-15579: Stack Featurize Falcon service (jluniya)

> Stack Featurize Falcon service
> --
>
> Key: AMBARI-15579
> URL: https://issues.apache.org/jira/browse/AMBARI-15579
> Project: Ambari
>  Issue Type: Technical task
>  Components: stacks
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15579.patch
>
>




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

[jira] [Updated] (AMBARI-15580) Stack Featurize Flume Service

[Jayush Luniya (JIRA)]

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

Jayush Luniya updated AMBARI-15580:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Stack Featurize Flume Service
> -
>
> Key: AMBARI-15580
> URL: https://issues.apache.org/jira/browse/AMBARI-15580
> Project: Ambari
>  Issue Type: Technical task
>  Components: stacks
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15580.patch
>
>




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

[jira] [Updated] (AMBARI-15640) Missing Properties in Kafka Config Tab

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-15640:

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

Patch committed to trunk and branch-2.2

> Missing Properties in Kafka Config Tab
> --
>
> Key: AMBARI-15640
> URL: https://issues.apache.org/jira/browse/AMBARI-15640
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Dhanya Balasundaran
>Assignee: Jaimin D Jetly
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-15640.patch
>
>
> call 
> /api/v1/clusters/cl1/configurations/service_config_versions?service_name.in(KAFKA)_current=true
> This api will provide the list of properties which need to be shown on the UI.
> Properties retrieved includes, kafka_keytab and kafka_principal_name.
> But these 2 properties are not present on UI at Kafka Configs tab



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

[jira] [Updated] (AMBARI-15579) Stack Featurize Falcon service

[Jayush Luniya (JIRA)]

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

Jayush Luniya updated AMBARI-15579:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Stack Featurize Falcon service
> --
>
> Key: AMBARI-15579
> URL: https://issues.apache.org/jira/browse/AMBARI-15579
> Project: Ambari
>  Issue Type: Technical task
>  Components: stacks
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15579.patch
>
>




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

[jira] [Commented] (AMBARI-15579) Stack Featurize Falcon service

[Jayush Luniya (JIRA)]

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

Jayush Luniya commented on AMBARI-15579:


commit 6b5adc463d422641cdd5a0da2b848063c4b19c08
Author: Jayush Luniya 
Date:   Thu Mar 31 13:40:08 2016 -0700

AMBARI-15579: Stack Featurize Falcon service (jluniya)

> Stack Featurize Falcon service
> --
>
> Key: AMBARI-15579
> URL: https://issues.apache.org/jira/browse/AMBARI-15579
> Project: Ambari
>  Issue Type: Technical task
>  Components: stacks
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15579.patch
>
>




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

[jira] [Commented] (AMBARI-15640) Missing Properties in Kafka Config Tab

[Srimanth Gunturi (JIRA)]

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

Srimanth Gunturi commented on AMBARI-15640:
---

+1 for patch

> Missing Properties in Kafka Config Tab
> --
>
> Key: AMBARI-15640
> URL: https://issues.apache.org/jira/browse/AMBARI-15640
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Dhanya Balasundaran
>Assignee: Jaimin D Jetly
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-15640.patch
>
>
> call 
> /api/v1/clusters/cl1/configurations/service_config_versions?service_name.in(KAFKA)_current=true
> This api will provide the list of properties which need to be shown on the UI.
> Properties retrieved includes, kafka_keytab and kafka_principal_name.
> But these 2 properties are not present on UI at Kafka Configs tab



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

[jira] [Commented] (AMBARI-15580) Stack Featurize Flume Service

[Jayush Luniya (JIRA)]

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

Jayush Luniya commented on AMBARI-15580:


commit 0c4b2954963b5975557de664e7f3d08dde3f29f3
Author: Jayush Luniya 
Date:   Thu Mar 31 13:37:09 2016 -0700

AMBARI-15580: Stack Featurize Flume Service (jluniya)

> Stack Featurize Flume Service
> -
>
> Key: AMBARI-15580
> URL: https://issues.apache.org/jira/browse/AMBARI-15580
> Project: Ambari
>  Issue Type: Technical task
>  Components: stacks
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15580.patch
>
>




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

[jira] [Commented] (AMBARI-15610) Add Service Wizard: invalid host name doesn't prevent proceeding to next page

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15610:
-

SUCCESS: Integrated in Ambari-trunk-Commit #4574 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4574/])
AMBARI-15610 Add Service Wizard: invalid host name doesn't prevent (zhewang: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=354b0a9756f24d2dcbbaa7c4867e95cfd4c03471])
* ambari-web/app/messages.js
* ambari-web/app/mixins/wizard/assign_master_components.js
* ambari-web/app/views/common/assign_master_components_view.js


> Add Service Wizard: invalid host name doesn't prevent proceeding to next page
> -
>
> Key: AMBARI-15610
> URL: https://issues.apache.org/jira/browse/AMBARI-15610
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Zhe (Joe) Wang
>Assignee: Zhe (Joe) Wang
> Fix For: 2.4.0
>
> Attachments: AMBARI-15610.v0.patch
>
>
> On "Add Service Wizard Assign Masters" page, invalid host name (when there 
> are more than 25 hosts, we use input field instead of select list) does not 
> disable the "next" button. After clicking the next button, wizard navigates 
> to "Assign Slaves and Clients" page and the (wrong) input of the host name 
> gets ignored without notification.



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

[jira] [Commented] (AMBARI-15383) Cleanup LDAP sync process

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15383:
-

SUCCESS: Integrated in Ambari-trunk-Commit #4574 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4574/])
AMBARI-15383. Cleanup Ldap Sync Process (oleewere) (oleewere: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=a6f0fbfb48e27e0199ade5eb4d9cfdfb7d5807c5])
* 
ambari-server/src/main/java/org/apache/ambari/server/security/ldap/AmbariLdapDataPopulator.java
* 
ambari-server/src/test/java/org/apache/ambari/server/security/ldap/AmbariLdapDataPopulatorTest.java
* 
ambari-server/src/test/java/org/apache/ambari/server/security/AmbariLdapUtilsTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/security/authorization/AmbariLdapUtils.java
* 
ambari-server/src/main/java/org/apache/ambari/server/security/authorization/Users.java


> Cleanup LDAP sync process
> -
>
> Key: AMBARI-15383
> URL: https://issues.apache.org/jira/browse/AMBARI-15383
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 2.4.0
>
> Attachments: AMBARI-15383.patch
>
>
> 1. Skip unnecessary queries during ldap sync (speed up --all)
> 2. Remove membership attribute case sensitivity 
> 3. Skip processing on that group/user which is out of scope of the base DN
> also add additional logging:
> log4j.logger.org.apache.ambari.server.security.ldap.AmbariLdapDataPopulator=TRACE
> in order to log the LDAP queries during sync



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

[jira] [Updated] (AMBARI-15655) Remove remaining hdp specific logic from resource_management library

[Jayush Luniya (JIRA)]

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

Jayush Luniya updated AMBARI-15655:
---
Description: 
Remove remaining HDP specific logic from resource_management. 
AMBARI-15420 didnt cover them as this need stack_featurization changes.

TODOs:
1. Cleanup HDP hardcodings in custom_actions scripts
2. Cleanup HDP hardcodings in configurations especially in common-services
3. Stack-driven configs for lzo-packages, list of repos etc.

> Remove remaining hdp specific logic from resource_management library
> 
>
> Key: AMBARI-15655
> URL: https://issues.apache.org/jira/browse/AMBARI-15655
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent, ambari-server
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15655.patch
>
>
> Remove remaining HDP specific logic from resource_management. 
> AMBARI-15420 didnt cover them as this need stack_featurization changes.
> TODOs:
> 1. Cleanup HDP hardcodings in custom_actions scripts
> 2. Cleanup HDP hardcodings in configurations especially in common-services
> 3. Stack-driven configs for lzo-packages, list of repos etc.



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

[jira] [Updated] (AMBARI-15655) Remove remaining hdp specific logic from resource_management library

[Jayush Luniya (JIRA)]

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

Jayush Luniya updated AMBARI-15655:
---
Status: Patch Available  (was: In Progress)

> Remove remaining hdp specific logic from resource_management library
> 
>
> Key: AMBARI-15655
> URL: https://issues.apache.org/jira/browse/AMBARI-15655
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent, ambari-server
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.0
>
> Attachments: AMBARI-15655.patch
>
>




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

[jira] [Updated] (AMBARI-15656) Record and Expose Alert Occurrence Values

[Jonathan Hurley (JIRA)]

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

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

> Record and Expose Alert Occurrence Values
> -
>
> Key: AMBARI-15656
> URL: https://issues.apache.org/jira/browse/AMBARI-15656
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-15656.patch
>
>
> Alert repeat tolerance values should be captured and exposed via the API. The 
> rules for capturing the occurrences of an alert are:
> - Alert instances always start at 1
> - Alerts with an {{OK}} state always reset the counter
> - When transitioning from {{OK}} to non-{{OK}}, the counter is reset
> - When transitioning within non-{{OK}} states (such as back and forth between 
> {{WARNING}} and {{CRITICAL}}, the counter is merely incremented.
> {code}
> GET api/v1/clusters/c1/alerts/1
> {
>   "href": "http://localhost:8080/api/v1/clusters/c1/alerts/1;,
>   "Alert": {
> "cluster_name": "c1",
> ...
> "repeat_tolerance": 1,
> "repeat_tolerance_remaining": 0,
> "occurrences": 8,
> 
> {code}
> - {{OK}} alert instances will *always* have a value of {{0}} for 
> {{repeat_tolerance_remaining}} since they do not honor repeat tolerance. An 
> {{OK}} alert is considered to be correct always.



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

[jira] [Updated] (AMBARI-15656) Record and Expose Alert Occurrence Values

[Jonathan Hurley (JIRA)]

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

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

> Record and Expose Alert Occurrence Values
> -
>
> Key: AMBARI-15656
> URL: https://issues.apache.org/jira/browse/AMBARI-15656
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-15656.patch
>
>
> Alert repeat tolerance values should be captured and exposed via the API. The 
> rules for capturing the occurrences of an alert are:
> - Alert instances always start at 1
> - Alerts with an {{OK}} state always reset the counter
> - When transitioning from {{OK}} to non-{{OK}}, the counter is reset
> - When transitioning within non-{{OK}} states (such as back and forth between 
> {{WARNING}} and {{CRITICAL}}, the counter is merely incremented.
> {code}
> GET api/v1/clusters/c1/alerts/1
> {
>   "href": "http://localhost:8080/api/v1/clusters/c1/alerts/1;,
>   "Alert": {
> "cluster_name": "c1",
> ...
> "repeat_tolerance": 1,
> "repeat_tolerance_remaining": 0,
> "occurrences": 8,
> 
> {code}
> - {{OK}} alert instances will *always* have a value of {{0}} for 
> {{repeat_tolerance_remaining}} since they do not honor repeat tolerance. An 
> {{OK}} alert is considered to be correct always.



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

[jira] [Created] (AMBARI-15656) Record and Expose Alert Occurrence Values

[Jonathan Hurley (JIRA)]

Jonathan Hurley created AMBARI-15656:


 Summary: Record and Expose Alert Occurrence Values
 Key: AMBARI-15656
 URL: https://issues.apache.org/jira/browse/AMBARI-15656
 Project: Ambari
  Issue Type: Task
  Components: ambari-server
Affects Versions: 2.4.0
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
Priority: Critical
 Fix For: 2.4.0


Alert repeat tolerance values should be captured and exposed via the API. The 
rules for capturing the occurrences of an alert are:

- Alert instances always start at 1
- Alerts with an {{OK}} state always reset the counter
- When transitioning from {{OK}} to non-{{OK}}, the counter is reset
- When transitioning within non-{{OK}} states (such as back and forth between 
{{WARNING}} and {{CRITICAL}}, the counter is merely incremented.

{code}
GET api/v1/clusters/c1/alerts/1
{
  "href": "http://localhost:8080/api/v1/clusters/c1/alerts/1;,
  "Alert": {
"cluster_name": "c1",
...
"repeat_tolerance": 1,
"repeat_tolerance_remaining": 0,
"occurrences": 8,

{code}

- {{OK}} alert instances will *always* have a value of {{0}} for 
{{repeat_tolerance_remaining}} since they do not honor repeat tolerance. An 
{{OK}} alert is considered to be correct always.



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

[jira] [Created] (AMBARI-15655) Remove remaining hdp specific logic from resource_management library

[Jayush Luniya (JIRA)]

Jayush Luniya created AMBARI-15655:
--

 Summary: Remove remaining hdp specific logic from 
resource_management library
 Key: AMBARI-15655
 URL: https://issues.apache.org/jira/browse/AMBARI-15655
 Project: Ambari
  Issue Type: Bug
  Components: ambari-agent, ambari-server
Affects Versions: 2.1.0, 2.2.0
Reporter: Jayush Luniya
Assignee: Jayush Luniya
 Fix For: 2.4.0






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

[jira] [Updated] (AMBARI-15653) Blueprint installation with Hive without Atlas fails

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk updated AMBARI-15653:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to trunk

> Blueprint installation with Hive without Atlas fails 
> -
>
> Key: AMBARI-15653
> URL: https://issues.apache.org/jira/browse/AMBARI-15653
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15653.patch
>
>
> 31 Mar 2016 15:55:55,479  INFO [qtp-ambari-client-22] 
> AmbariManagementControllerImpl:1445 - Received a updateCluster request, 
> clusterId=null, clusterName=c1, securityType=null, request={ clusterName=c1, 
> clusterId=null, provisioningState=INSTALLED, securityType=null, 
> stackVersion=HDP-2.4, desired_scv=null, hosts=[] }
> 31 Mar 2016 15:55:55,502 ERROR [pool-11-thread-1] TopologyManager:762 - 
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting 
> to process cluster configs and set on cluster: 
> java.lang.IllegalArgumentException: Unable to update configuration 
> property 'atlas.rest.address' with topology information. Component 
> 'ATLAS_SERVER' is mapped to an invalid number of hosts '0'.
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor$SingleHostTopologyUpdater.updateForClusterCreate(BlueprintConfigurationProcessor.java:1328)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForClusterCreate(BlueprintConfigurationProcessor.java:263)
> at 
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:150)
> at 
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:760)
> at 
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:734)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 31 Mar 2016 15:55:55,502  INFO [pool-2-thread-1] AsyncCallableService:111 
> - Exception during task execution: 
> java.util.concurrent.ExecutionException: java.lang.Exception: 
> java.lang.IllegalArgumentException: Unable to update configuration property 
> 'atlas.rest.address' with topology information. Component 'ATLAS_SERVER' is 
> mapped to an invalid number of hosts '0'.
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at 
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at 
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at 
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.Exception: java.lang.IllegalArgumentException: 
> Unable to update configuration property 'atlas.rest.address' with topology 
> information. Component 'ATLAS_SERVER' is mapped to an invalid number of hosts 
> '0'.
> at 
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:766)
> at 
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:734)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> ... 3 more
> Caused by: java.lang.IllegalArgumentException: Unable to update 
> configuration property 'atlas.rest.address' with 

[jira] [Commented] (AMBARI-15653) Blueprint installation with Hive without Atlas fails

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk commented on AMBARI-15653:
--

Unittest results:
{noformat}
INFO: Return code from stack upgrade command, retcode = 0
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Ambari Views .. SUCCESS [4.716s]
[INFO] Ambari Metrics Common . SUCCESS [3.939s]
[INFO] Ambari Server . SUCCESS 
[1:25:20.704s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 1:25:30.087s
[INFO] Finished at: Thu Mar 31 20:58:11 EEST 2016
[INFO] Final Memory: 44M/560M
[INFO] 
{noformat}
There is a big queue on Hadoop QA.

> Blueprint installation with Hive without Atlas fails 
> -
>
> Key: AMBARI-15653
> URL: https://issues.apache.org/jira/browse/AMBARI-15653
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15653.patch
>
>
> 31 Mar 2016 15:55:55,479  INFO [qtp-ambari-client-22] 
> AmbariManagementControllerImpl:1445 - Received a updateCluster request, 
> clusterId=null, clusterName=c1, securityType=null, request={ clusterName=c1, 
> clusterId=null, provisioningState=INSTALLED, securityType=null, 
> stackVersion=HDP-2.4, desired_scv=null, hosts=[] }
> 31 Mar 2016 15:55:55,502 ERROR [pool-11-thread-1] TopologyManager:762 - 
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting 
> to process cluster configs and set on cluster: 
> java.lang.IllegalArgumentException: Unable to update configuration 
> property 'atlas.rest.address' with topology information. Component 
> 'ATLAS_SERVER' is mapped to an invalid number of hosts '0'.
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor$SingleHostTopologyUpdater.updateForClusterCreate(BlueprintConfigurationProcessor.java:1328)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForClusterCreate(BlueprintConfigurationProcessor.java:263)
> at 
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:150)
> at 
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:760)
> at 
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:734)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 31 Mar 2016 15:55:55,502  INFO [pool-2-thread-1] AsyncCallableService:111 
> - Exception during task execution: 
> java.util.concurrent.ExecutionException: java.lang.Exception: 
> java.lang.IllegalArgumentException: Unable to update configuration property 
> 'atlas.rest.address' with topology information. Component 'ATLAS_SERVER' is 
> mapped to an invalid number of hosts '0'.
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at 
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at 
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at 
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.Exception: java.lang.IllegalArgumentException: 
> Unable to update configuration property 'atlas.rest.address' with topology 
> information. Component 

[jira] [Updated] (AMBARI-15647) Alerts Using the SKIPPED State Cause Stale Alert Notification

[Jonathan Hurley (JIRA)]

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

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

> Alerts Using the SKIPPED State Cause Stale Alert Notification
> -
>
> Key: AMBARI-15647
> URL: https://issues.apache.org/jira/browse/AMBARI-15647
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
> Fix For: 2.4.0
>
> Attachments: AMBARI-15647.patch
>
>
> SCRIPT alerts which use the {{SKIPPED}} state as a way of preventing 
> processing are causing instances of the Ambari Stale Alert to trigger. This 
> is because the agents do not return these alerts in the heartbeat causing 
> their timestamps not to update.
> STR:
> - Create a SCRIPT alert which returns {{SKIPPED}} as it's state.
> - Wait for the stale alert to trigger.
> {code}
> There are 1 stale alerts from 1 host(s): c6401.ambari.apache.org[NameNode 
> Service RPC Queue Latency (Hourly) (2h 18m), NameNode Service RPC Processing 
> Latency (Hourly) (2h 18m)]
> {code}



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

[jira] [Updated] (AMBARI-15637) If RU/EU is paused, services are restarted on the older version. EU is more complex since stopping services should use the original version.

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-15637:
-
Attachment: (was: AMBARI-15637.branch-2.2.patch)

> If RU/EU is paused, services are restarted on the older version. EU is more 
> complex since stopping services should use the original version.
> 
>
> Key: AMBARI-15637
> URL: https://issues.apache.org/jira/browse/AMBARI-15637
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Alejandro Fernandez
>Priority: Critical
> Fix For: 2.2.2
>
>
> Currently, if RU/EU is paused, then restarting services manually will use the 
> version whose state is CURRENT. This means that services may be restarted on 
> the wrong version, preventing Ambari from correctly Finalizing the upgrade.
> Instead, the logic should be as follows during Upgrade:
> RU: always use to_version
> EU: if haven't completed the action "UPDATE_DESIRED_STACK_ID", then use the 
> from_version, otherwise, use the to_version.
> During Downgrade, both should use the original version, which is actually the 
> to_version column in the upgrade table.
> Assertions:
> A: restart a service (should have version parameter,
> B: run a service check (no version needed)
> C: run HDFS Rebalance (should have version parameter).
> Test Cases:
> 1. Before stack upgrade, run A, B, and C, which should all use the current 
> version
> 2. EU, immediately click pause. Run A, B, and C, which should use the 
> original version if it exists
> 3. EU, after the services have been stopped and the stack has been upgraded. 
> Run A, B, and C, which should use the new version since the services are now 
> to be started.
> 4. EU, click downgrade and pause. Run A, B, C, which should use the original 
> version.
> 5. RU, click pause whenever a manual task occurs. Run A, B, and C, which 
> should use the destination version.
> 6. RU, click downgrade. Run A, B, and C, which should use the original 
> version.



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

[jira] [Updated] (AMBARI-15637) If RU/EU is paused, services are restarted on the older version. EU is more complex since stopping services should use the original version.

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-15637:
-
Attachment: (was: AMBARI-15637.branch-2.2.patch)

> If RU/EU is paused, services are restarted on the older version. EU is more 
> complex since stopping services should use the original version.
> 
>
> Key: AMBARI-15637
> URL: https://issues.apache.org/jira/browse/AMBARI-15637
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Alejandro Fernandez
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15637.branch-2.2.patch
>
>
> Currently, if RU/EU is paused, then restarting services manually will use the 
> version whose state is CURRENT. This means that services may be restarted on 
> the wrong version, preventing Ambari from correctly Finalizing the upgrade.
> Instead, the logic should be as follows during Upgrade:
> RU: always use to_version
> EU: if haven't completed the action "UPDATE_DESIRED_STACK_ID", then use the 
> from_version, otherwise, use the to_version.
> During Downgrade, both should use the original version, which is actually the 
> to_version column in the upgrade table.
> Assertions:
> A: restart a service (should have version parameter,
> B: run a service check (no version needed)
> C: run HDFS Rebalance (should have version parameter).
> Test Cases:
> 1. Before stack upgrade, run A, B, and C, which should all use the current 
> version
> 2. EU, immediately click pause. Run A, B, and C, which should use the 
> original version if it exists
> 3. EU, after the services have been stopped and the stack has been upgraded. 
> Run A, B, and C, which should use the new version since the services are now 
> to be started.
> 4. EU, click downgrade and pause. Run A, B, C, which should use the original 
> version.
> 5. RU, click pause whenever a manual task occurs. Run A, B, and C, which 
> should use the destination version.
> 6. RU, click downgrade. Run A, B, and C, which should use the original 
> version.



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

[jira] [Updated] (AMBARI-15637) If RU/EU is paused, services are restarted on the older version. EU is more complex since stopping services should use the original version.

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-15637:
-
Attachment: AMBARI-15637.branch-2.2.patch

> If RU/EU is paused, services are restarted on the older version. EU is more 
> complex since stopping services should use the original version.
> 
>
> Key: AMBARI-15637
> URL: https://issues.apache.org/jira/browse/AMBARI-15637
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Alejandro Fernandez
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15637.branch-2.2.patch
>
>
> Currently, if RU/EU is paused, then restarting services manually will use the 
> version whose state is CURRENT. This means that services may be restarted on 
> the wrong version, preventing Ambari from correctly Finalizing the upgrade.
> Instead, the logic should be as follows during Upgrade:
> RU: always use to_version
> EU: if haven't completed the action "UPDATE_DESIRED_STACK_ID", then use the 
> from_version, otherwise, use the to_version.
> During Downgrade, both should use the original version, which is actually the 
> to_version column in the upgrade table.
> Assertions:
> A: restart a service (should have version parameter,
> B: run a service check (no version needed)
> C: run HDFS Rebalance (should have version parameter).
> Test Cases:
> 1. Before stack upgrade, run A, B, and C, which should all use the current 
> version
> 2. EU, immediately click pause. Run A, B, and C, which should use the 
> original version if it exists
> 3. EU, after the services have been stopped and the stack has been upgraded. 
> Run A, B, and C, which should use the new version since the services are now 
> to be started.
> 4. EU, click downgrade and pause. Run A, B, C, which should use the original 
> version.
> 5. RU, click pause whenever a manual task occurs. Run A, B, and C, which 
> should use the destination version.
> 6. RU, click downgrade. Run A, B, and C, which should use the original 
> version.



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

[jira] [Commented] (AMBARI-15443) Make Host bulk command menu item list stack driven instead of a hardcoded list in UI code

[Di Li (JIRA)]

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

Di Li commented on AMBARI-15443:


pushed to trunk as 
https://git-wip-us.apache.org/repos/asf/ambari/repo?p=ambari.git;a=commit;h=2410929485dc8d8b3baac28528d8762322d748a4

> Make Host bulk command menu item list stack driven instead of a hardcoded 
> list in UI code
> -
>
> Key: AMBARI-15443
> URL: https://issues.apache.org/jira/browse/AMBARI-15443
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server, ambari-web
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
> Fix For: trunk
>
> Attachments: AMBARI-15443.patch
>
>
> The items described here are the ones on the Hosts tab, in the Actions 
> drop-down list where the UI shows entries such as All Hosts. If user mouses 
> over the All Hosts, it shows a sub-list including Hosts and slave components. 
> The slave component items are hardcoded in hosts_table_menu_view.js as shown 
> below. This jira is to put this info into each service's metainfo.xml so that 
> the slave component items can be stack driven.
> components: function () {
> var serviceNames = App.Service.find().mapProperty('serviceName');
> var menuItems = [
>   O.create({
> serviceName: 'HDFS',
> componentName: 'DATANODE',
> masterComponentName: 'NAMENODE',
> componentNameFormatted: Em.I18n.t('dashboard.services.hdfs.datanodes')
>   }),
>   O.create({
> serviceName: 'YARN',
> componentName: 'NODEMANAGER',
> masterComponentName: 'RESOURCEMANAGER',
> componentNameFormatted: 
> Em.I18n.t('dashboard.services.yarn.nodeManagers')
>   }),
>   O.create({
> serviceName: 'HBASE',
> componentName: 'HBASE_REGIONSERVER',
> masterComponentName: 'HBASE_MASTER',
> componentNameFormatted: 
> Em.I18n.t('dashboard.services.hbase.regionServers')
>   }),
>   O.create({
> serviceName: 'STORM',
> componentName: 'SUPERVISOR',
> masterComponentName: 'SUPERVISOR',
> componentNameFormatted: 
> Em.I18n.t('dashboard.services.storm.supervisors')
>   })];
> return menuItems.filter(function (item) {
>   return serviceNames.contains(item.serviceName);
> });
>   }.property(),



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

[jira] [Updated] (AMBARI-15592) Auto-start services: Support blueprint deployment

[Nahappan Somasundaram (JIRA)]

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

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

> Auto-start services: Support blueprint deployment
> -
>
> Key: AMBARI-15592
> URL: https://issues.apache.org/jira/browse/AMBARI-15592
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.4.0
>
> Attachments: rb45347.patch
>
>
> Add support to blueprint to enable auto start of services.



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

[jira] [Updated] (AMBARI-15610) Add Service Wizard: invalid host name doesn't prevent proceeding to next page

[Zhe (Joe) Wang (JIRA)]

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

Zhe (Joe) Wang updated AMBARI-15610:

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

Committed to trunk

> Add Service Wizard: invalid host name doesn't prevent proceeding to next page
> -
>
> Key: AMBARI-15610
> URL: https://issues.apache.org/jira/browse/AMBARI-15610
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Zhe (Joe) Wang
>Assignee: Zhe (Joe) Wang
> Fix For: 2.4.0
>
> Attachments: AMBARI-15610.v0.patch
>
>
> On "Add Service Wizard Assign Masters" page, invalid host name (when there 
> are more than 25 hosts, we use input field instead of select list) does not 
> disable the "next" button. After clicking the next button, wizard navigates 
> to "Assign Slaves and Clients" page and the (wrong) input of the host name 
> gets ignored without notification.



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

[jira] [Commented] (AMBARI-15643) During cluster creation using Blueprints the cluster creation request has incorrect COMPLETED state instead of PENDING.

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15643:
-

SUCCESS: Integrated in Ambari-trunk-Commit #4573 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4573/])
AMBARI-15643. During cluster creation using Blueprints the cluster (stoader: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=6f61de093943a75868925cb7f76cbceea6215ae9])
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/RequestResourceProvider.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/RequestResourceProviderTest.java


> During cluster creation using Blueprints the cluster creation request has 
> incorrect COMPLETED state instead of PENDING.
> ---
>
> Key: AMBARI-15643
> URL: https://issues.apache.org/jira/browse/AMBARI-15643
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15643.v1.patch
>
>
> After the cluster creation template posted to Ambari (via the REST Api) to 
> provision a cluster using Blueprints is accepted for processing Ambari 
> returns in the response the url of the request through which the 
> status/progress of the cluster creation can be tracked.
> When querying the status of the request it erroneously returns "COMPLETED" 
> instead of returning "PENDING" until the first task of the cluster creation 
> is scheduled to be executed on one of the cluster nodes. Once at least one 
> task is scheduled to be executed the status of the request should change to 
> "IN_PROGRESS". The "COMPLETED" state should be reached when all tasks 
> completed succesfully.



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

[jira] [Commented] (AMBARI-15650) Output short logs summary on start/stop failure

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15650:
-

SUCCESS: Integrated in Ambari-trunk-Commit #4573 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4573/])
AMBARI-15650. Output short logs summary on start/stop failure (aonishuk) 
(aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=017fbf130f7a3ce880baa11bf6a783f3ca850d78])
* 
ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/package/scripts/kafka_broker.py
* 
ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/package/scripts/oozie_service.py
* 
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/package/scripts/kms_service.py
* 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/ranger_service.py
* 
ambari-common/src/main/python/resource_management/libraries/functions/__init__.py
* 
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/utils.py
* 
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/knox_gateway.py
* 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata_server.py
* 
ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/package/scripts/accumulo_service.py
* 
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py
* 
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/hbase_service.py
* ambari-server/src/test/python/stacks/2.0.6/ZOOKEEPER/test_zookeeper_server.py
* ambari-server/src/test/python/stacks/2.3/ATLAS/test_metadata_server.py
* 
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/params_linux.py
* 
ambari-common/src/main/python/resource_management/libraries/functions/show_logs.py
* 
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py
* 
ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/package/scripts/flume.py
* 
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/service.py
* 
ambari-server/src/main/resources/common-services/SPARK/1.2.0.2.2/package/scripts/spark_service.py
* 
ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/service.py
* 
ambari-server/src/main/resources/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_service.py
* 
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hive_service.py
* 
ambari-common/src/main/python/resource_management/libraries/functions/version_select_util.py
* 
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/ams_service.py


> Output short logs summary on start/stop failure
> ---
>
> Key: AMBARI-15650
> URL: https://issues.apache.org/jira/browse/AMBARI-15650
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15650.patch
>
>
> There were tons of situations when we had only output of task failure, when a 
> certain service failed to start/stop/restart, but couldn't get the logs of 
> services.
> Which makes fixing those bugs pretty problematic or even impossible if no 
> reproduce is available.
> This jira aims to output a short tail of service logs on start/stop failures, 
> this should cover a big part of such a scenarios.



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

[jira] [Commented] (AMBARI-15651) Sqoop client install

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15651:
-

SUCCESS: Integrated in Ambari-trunk-Commit #4573 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4573/])
AMBARI-15651. Sqoop client install (aonishuk) (aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=8d91e710995d2b911c60882f84b6a46d8f26])
* 
ambari-server/src/main/resources/common-services/SQOOP/1.4.4.2.0/package/scripts/sqoop_client.py
* ambari-common/src/main/python/resource_management/core/environment.py
* 
ambari-common/src/main/python/resource_management/libraries/functions/format.py
* 
ambari-server/src/main/resources/common-services/SQOOP/1.4.4.2.0/package/scripts/params_linux.py


> Sqoop client install
> 
>
> Key: AMBARI-15651
> URL: https://issues.apache.org/jira/browse/AMBARI-15651
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15651.patch
>
>




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

[jira] [Updated] (AMBARI-15639) Expose MariaDB option for Hive, Oozie and Ranger

[Richard Zang (JIRA)]

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

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

Committed to trunk 1fbc106b88c04fe7da16491b4740b94b71130db1

> Expose MariaDB option for Hive, Oozie and Ranger
> 
>
> Key: AMBARI-15639
> URL: https://issues.apache.org/jira/browse/AMBARI-15639
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.4.0
>
>
> Change "Existing MySQL database" label shown in Hive Config UI to "Existing 
> MySQL / MariaDB database".
> Note that "New MySQL database" option should NOT change, as we do not yet 
> support installing MariaDB.



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

[jira] [Updated] (AMBARI-15640) Missing Properties in Kafka Config Tab

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-15640:

Attachment: AMBARI-15640.patch

> Missing Properties in Kafka Config Tab
> --
>
> Key: AMBARI-15640
> URL: https://issues.apache.org/jira/browse/AMBARI-15640
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Dhanya Balasundaran
>Assignee: Jaimin D Jetly
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-15640.patch
>
>
> call 
> /api/v1/clusters/cl1/configurations/service_config_versions?service_name.in(KAFKA)_current=true
> This api will provide the list of properties which need to be shown on the UI.
> Properties retrieved includes, kafka_keytab and kafka_principal_name.
> But these 2 properties are not present on UI at Kafka Configs tab



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

[jira] [Updated] (AMBARI-15654) ambari-server database check is failing due to EOF Error

[Vitaly Brodetskyi (JIRA)]

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

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

> ambari-server database check is failing due to EOF Error
> 
>
> Key: AMBARI-15654
> URL: https://issues.apache.org/jira/browse/AMBARI-15654
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Blocker
> Fix For: 2.2.2
>
> Attachments: AMBARI-15654.patch
>
>
> Tests for encrypt passwords are failing on DB check.
> STR:
> setup -> encrypt (persist master) -> setup-ldap -> encrypt (persist master) 
> -> start
> All tests run ambari-server db checks as part of qe framework. For all 
> encrypt password tests this check is failing due to below error



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

[jira] [Created] (AMBARI-15654) ambari-server database check is failing due to EOF Error

[Vitaly Brodetskyi (JIRA)]

Vitaly Brodetskyi created AMBARI-15654:
--

 Summary: ambari-server database check is failing due to EOF Error
 Key: AMBARI-15654
 URL: https://issues.apache.org/jira/browse/AMBARI-15654
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.2.2
Reporter: Vitaly Brodetskyi
Assignee: Vitaly Brodetskyi
Priority: Blocker
 Fix For: 2.2.2


Tests for encrypt passwords are failing on DB check.
STR:
setup -> encrypt (persist master) -> setup-ldap -> encrypt (persist master) -> 
start
All tests run ambari-server db checks as part of qe framework. For all encrypt 
password tests this check is failing due to below error



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

[jira] [Updated] (AMBARI-15640) Missing Properties in Kafka Config Tab

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-15640:

Fix Version/s: 2.4.0

> Missing Properties in Kafka Config Tab
> --
>
> Key: AMBARI-15640
> URL: https://issues.apache.org/jira/browse/AMBARI-15640
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Dhanya Balasundaran
>Assignee: Jaimin D Jetly
> Fix For: 2.4.0, 2.2.2
>
>
> call 
> /api/v1/clusters/cl1/configurations/service_config_versions?service_name.in(KAFKA)_current=true
> This api will provide the list of properties which need to be shown on the UI.
> Properties retrieved includes, kafka_keytab and kafka_principal_name.
> But these 2 properties are not present on UI at Kafka Configs tab



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

[jira] [Updated] (AMBARI-15383) Cleanup LDAP sync process

[JIRA]

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

Olivér Szabó updated AMBARI-15383:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Cleanup LDAP sync process
> -
>
> Key: AMBARI-15383
> URL: https://issues.apache.org/jira/browse/AMBARI-15383
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 2.4.0
>
> Attachments: AMBARI-15383.patch
>
>
> 1. Skip unnecessary queries during ldap sync (speed up --all)
> 2. Remove membership attribute case sensitivity 
> 3. Skip processing on that group/user which is out of scope of the base DN
> also add additional logging:
> log4j.logger.org.apache.ambari.server.security.ldap.AmbariLdapDataPopulator=TRACE
> in order to log the LDAP queries during sync



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

[jira] [Commented] (AMBARI-15383) Cleanup LDAP sync process

[JIRA]

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

Olivér Szabó commented on AMBARI-15383:
---

committed to trunk:
{code:java}
commit a6f0fbfb48e27e0199ade5eb4d9cfdfb7d5807c5
Author: oleewere 
Date:   Thu Mar 31 19:10:58 2016 +0200

AMBARI-15383. Cleanup Ldap Sync Process (oleewere)
{code}

> Cleanup LDAP sync process
> -
>
> Key: AMBARI-15383
> URL: https://issues.apache.org/jira/browse/AMBARI-15383
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 2.4.0
>
> Attachments: AMBARI-15383.patch
>
>
> 1. Skip unnecessary queries during ldap sync (speed up --all)
> 2. Remove membership attribute case sensitivity 
> 3. Skip processing on that group/user which is out of scope of the base DN
> also add additional logging:
> log4j.logger.org.apache.ambari.server.security.ldap.AmbariLdapDataPopulator=TRACE
> in order to log the LDAP queries during sync



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

[jira] [Updated] (AMBARI-15383) Cleanup LDAP sync process

[JIRA]

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

Olivér Szabó updated AMBARI-15383:
--
Description: 
1. Skip unnecessary queries during ldap sync (speed up --all)
2. Remove membership attribute case sensitivity 
3. Skip processing on that group/user which is out of scope of the base DN

also add additional logging:
log4j.logger.org.apache.ambari.server.security.ldap.AmbariLdapDataPopulator=TRACE
in order to log the LDAP queries during sync

  was:
1. Skip unnecessary queries during ldap sync (speed up --all)
2. Remove membership attribute case sensitivity 


> Cleanup LDAP sync process
> -
>
> Key: AMBARI-15383
> URL: https://issues.apache.org/jira/browse/AMBARI-15383
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 2.4.0
>
> Attachments: AMBARI-15383.patch
>
>
> 1. Skip unnecessary queries during ldap sync (speed up --all)
> 2. Remove membership attribute case sensitivity 
> 3. Skip processing on that group/user which is out of scope of the base DN
> also add additional logging:
> log4j.logger.org.apache.ambari.server.security.ldap.AmbariLdapDataPopulator=TRACE
> in order to log the LDAP queries during sync



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

[jira] [Commented] (AMBARI-15389) Intermittent YARN service check failures during and post EU

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15389:
-

SUCCESS: Integrated in Ambari-trunk-Commit #4572 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4572/])
AMBARI-15389. Intermittent YARN service check failures during and post (hiveww: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=1fb2aab41c35cbe85fbb9545505872199fef8822])
* ambari-web/app/utils/configs/mount_points_based_initializer_mixin.js


> Intermittent YARN service check failures during and post EU
> ---
>
> Key: AMBARI-15389
> URL: https://issues.apache.org/jira/browse/AMBARI-15389
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Dmitry Lysnichenko
>Assignee: Antonenko Alexander
> Fix For: 2.2.2
>
> Attachments: AMBARI-15389.patch, AMBARI-15389.patch, 
> AMBARI-15389_2.2.patch
>
>
> Build # - Ambari 2.2.1.1 - #63
> Observed this issue in a couple of EU runs recently where YARN service check 
> reports failure
> a. In one test, the EU ran from HDP 2.3.4.0 to 2.4.0.0 and YARN service check 
> reported failure during EU itself; a retry of the operation led to service 
> check being successful
> b. In another test post EU when YARN service check was run, it reported 
> failure; afterwards when I ran it again - success
> Looks like there is some corner condition which causes this issue to be hit
> {code}
> stderr:   /var/lib/ambari-agent/data/errors-822.txt
> Traceback (most recent call last):
> File 
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/service_check.py",
>  line 142, in 
> ServiceCheck().execute()
> File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 219, in execute
> method(env)
> File 
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/service_check.py",
>  line 104, in service_check
> user=params.smokeuser,
> 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 '/usr/bin/kinit -kt 
> /etc/security/keytabs/smokeuser.headless.keytab ambari...@example.com; yarn 
> org.apache.hadoop.yarn.applications.distributedshell.Client -shell_command ls 
> -num_containers 1 -jar 
> /usr/hdp/current/hadoop-yarn-client/hadoop-yarn-applications-distributedshell.jar'
>  returned 2.  Hortonworks #
> This is MOTD message, added for testing in qe infra
> 16/03/03 02:33:51 INFO impl.TimelineClientImpl: Timeline service address: 
> http://host:8188/ws/v1/timeline/
> 16/03/03 02:33:51 INFO distributedshell.Client: Initializing Client
> 16/03/03 02:33:51 INFO distributedshell.Client: Running Client
> 16/03/03 02:33:51 INFO client.RMProxy: Connecting to ResourceManager at 
> host-9-5.test/127.0.0.254:8050
> 16/03/03 02:33:53 INFO distributedshell.Client: Got Cluster metric info from 
> ASM, numNodeManagers=3
> 16/03/03 02:33:53 INFO distributedshell.Client: Got Cluster node info from ASM
> 16/03/03 02:33:53 INFO distributedshell.Client: Got node report from ASM for, 
> nodeId=host:25454, nodeAddresshost:8042, nodeRackName/default-rack, 
> nodeNumContainers1
> 16/03/03 02:33:53 INFO distributedshell.Client: Got node report from ASM for, 
> nodeId=host-9-5.test:25454, nodeAddresshost-9-5.test:8042, 
> nodeRackName/default-rack, nodeNumContainers0
> 16/03/03 02:33:53 INFO distributedshell.Client: Got node report from ASM for, 
> nodeId=host-9-1.test:25454, nodeAddresshost-9-1.test:8042, 
> nodeRackName/default-rack, nodeNumContainers0
> 16/03/03 02:33:53 INFO distributedshell.Client: Queue info, 
> queueName=default, queueCurrentCapacity=0.08336, queueMaxCapacity=1.0, 
> queueApplicationCount=0, queueChildQueueCount=0
> 16/03/03 02:33:53 INFO distributedshell.Client: User ACL Info for Queue, 
> queueName=root, userAcl=SUBMIT_APPLICATIONS
> 16/03/03 02:33:53 INFO distributedshell.Client: User ACL Info for Queue, 
> queueName=default, userAcl=SUBMIT_APPLICATIONS
> 16/03/03 02:33:53 INFO distributedshell.Client: Max mem capabililty of 
> resources in this cluster 10240
> 16/03/03 02:33:53 INFO distributedshell.Client: Max virtual cores capabililty 
> of resources in this cluster 1
> 16/03/03 

[jira] [Commented] (AMBARI-15620) Orphaned Host Alerts Cause Stale Alert Notifications After Removing Hosts

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15620:
-

SUCCESS: Integrated in Ambari-trunk-Commit #4572 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4572/])
AMBARI-15620 - Orphaned Host Alerts Cause Stale Alert Notifications (jhurley: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=7a909ade91da851d3b6910fe4f724f2dc23009c8])
* 
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClustersImpl.java


> Orphaned Host Alerts Cause Stale Alert Notifications After Removing Hosts
> -
>
> Key: AMBARI-15620
> URL: https://issues.apache.org/jira/browse/AMBARI-15620
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.0.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15620.patch
>
>
> Host-level alerts from {{AMBARI}}/{{AMBARI_AGENT}} are orphaned after 
> removing a host because they are always considered valid. 
> STR
> - Deploy cluster 
> - Add/Remove nodes a few times 
> - Removed all aded nodes
> {code}
>  There are 4 stale alerts from 4 host(s): 
> amb-roll-workflow1458640758-5.novalocal[Host Disk Usage (3h 52m)], 
> amb-roll-workflow1458640758-2.novalocal[Host Disk Usage (3h 52m)], 
> amb-roll-workflow1458640758-3.novalocal[Host Disk Usage (3h 52m)], 
> amb-roll-workflow1458640758-4.novalocal[Host Disk Usage (3h 52m)]
> {code}



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

[jira] [Commented] (AMBARI-15643) During cluster creation using Blueprints the cluster creation request has incorrect COMPLETED state instead of PENDING.

[Sebastian Toader (JIRA)]

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

Sebastian Toader commented on AMBARI-15643:
---

Committed to trunk:
{code}
commit 6f61de093943a75868925cb7f76cbceea6215ae9
Author: Toader, Sebastian 
Date:   Thu Mar 31 16:39:29 2016 +0200

AMBARI-15643. During cluster creation using Blueprints the cluster creation 
request has incorrect COMPLETED state instead of PENDING. (stoader)
{code}

> During cluster creation using Blueprints the cluster creation request has 
> incorrect COMPLETED state instead of PENDING.
> ---
>
> Key: AMBARI-15643
> URL: https://issues.apache.org/jira/browse/AMBARI-15643
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15643.v1.patch
>
>
> After the cluster creation template posted to Ambari (via the REST Api) to 
> provision a cluster using Blueprints is accepted for processing Ambari 
> returns in the response the url of the request through which the 
> status/progress of the cluster creation can be tracked.
> When querying the status of the request it erroneously returns "COMPLETED" 
> instead of returning "PENDING" until the first task of the cluster creation 
> is scheduled to be executed on one of the cluster nodes. Once at least one 
> task is scheduled to be executed the status of the request should change to 
> "IN_PROGRESS". The "COMPLETED" state should be reached when all tasks 
> completed succesfully.



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

[jira] [Updated] (AMBARI-15653) Blueprint installation with Hive without Atlas fails

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk updated AMBARI-15653:
-
Status: Patch Available  (was: Open)

> Blueprint installation with Hive without Atlas fails 
> -
>
> Key: AMBARI-15653
> URL: https://issues.apache.org/jira/browse/AMBARI-15653
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15653.patch
>
>
> 31 Mar 2016 15:55:55,479  INFO [qtp-ambari-client-22] 
> AmbariManagementControllerImpl:1445 - Received a updateCluster request, 
> clusterId=null, clusterName=c1, securityType=null, request={ clusterName=c1, 
> clusterId=null, provisioningState=INSTALLED, securityType=null, 
> stackVersion=HDP-2.4, desired_scv=null, hosts=[] }
> 31 Mar 2016 15:55:55,502 ERROR [pool-11-thread-1] TopologyManager:762 - 
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting 
> to process cluster configs and set on cluster: 
> java.lang.IllegalArgumentException: Unable to update configuration 
> property 'atlas.rest.address' with topology information. Component 
> 'ATLAS_SERVER' is mapped to an invalid number of hosts '0'.
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor$SingleHostTopologyUpdater.updateForClusterCreate(BlueprintConfigurationProcessor.java:1328)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForClusterCreate(BlueprintConfigurationProcessor.java:263)
> at 
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:150)
> at 
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:760)
> at 
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:734)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 31 Mar 2016 15:55:55,502  INFO [pool-2-thread-1] AsyncCallableService:111 
> - Exception during task execution: 
> java.util.concurrent.ExecutionException: java.lang.Exception: 
> java.lang.IllegalArgumentException: Unable to update configuration property 
> 'atlas.rest.address' with topology information. Component 'ATLAS_SERVER' is 
> mapped to an invalid number of hosts '0'.
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at 
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at 
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at 
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.Exception: java.lang.IllegalArgumentException: 
> Unable to update configuration property 'atlas.rest.address' with topology 
> information. Component 'ATLAS_SERVER' is mapped to an invalid number of hosts 
> '0'.
> at 
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:766)
> at 
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:734)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> ... 3 more
> Caused by: java.lang.IllegalArgumentException: Unable to update 
> configuration property 'atlas.rest.address' with topology information. 
> Component 'ATLAS_SERVER' is 

[jira] [Created] (AMBARI-15653) Blueprint installation with Hive without Atlas fails

[Andrew Onischuk (JIRA)]

Andrew Onischuk created AMBARI-15653:


 Summary: Blueprint installation with Hive without Atlas fails 
 Key: AMBARI-15653
 URL: https://issues.apache.org/jira/browse/AMBARI-15653
 Project: Ambari
  Issue Type: Bug
Reporter: Andrew Onischuk
Assignee: Andrew Onischuk
 Fix For: 2.4.0
 Attachments: AMBARI-15653.patch


31 Mar 2016 15:55:55,479  INFO [qtp-ambari-client-22] 
AmbariManagementControllerImpl:1445 - Received a updateCluster request, 
clusterId=null, clusterName=c1, securityType=null, request={ clusterName=c1, 
clusterId=null, provisioningState=INSTALLED, securityType=null, 
stackVersion=HDP-2.4, desired_scv=null, hosts=[] }
31 Mar 2016 15:55:55,502 ERROR [pool-11-thread-1] TopologyManager:762 - 
TopologyManager.ConfigureClusterTask: An exception occurred while attempting to 
process cluster configs and set on cluster: 
java.lang.IllegalArgumentException: Unable to update configuration property 
'atlas.rest.address' with topology information. Component 'ATLAS_SERVER' is 
mapped to an invalid number of hosts '0'.
at 
org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor$SingleHostTopologyUpdater.updateForClusterCreate(BlueprintConfigurationProcessor.java:1328)
at 
org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForClusterCreate(BlueprintConfigurationProcessor.java:263)
at 
org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:150)
at 
org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:760)
at 
org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:734)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
31 Mar 2016 15:55:55,502  INFO [pool-2-thread-1] AsyncCallableService:111 - 
Exception during task execution: 
java.util.concurrent.ExecutionException: java.lang.Exception: 
java.lang.IllegalArgumentException: Unable to update configuration property 
'atlas.rest.address' with topology information. Component 'ATLAS_SERVER' is 
mapped to an invalid number of hosts '0'.
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:206)
at 
org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
at 
org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
at 
org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.Exception: java.lang.IllegalArgumentException: Unable 
to update configuration property 'atlas.rest.address' with topology 
information. Component 'ATLAS_SERVER' is mapped to an invalid number of hosts 
'0'.
at 
org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:766)
at 
org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:734)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
... 3 more
Caused by: java.lang.IllegalArgumentException: Unable to update 
configuration property 'atlas.rest.address' with topology information. 
Component 'ATLAS_SERVER' is mapped to an invalid number of hosts '0'.
at 
org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor$SingleHostTopologyUpdater.updateForClusterCreate(BlueprintConfigurationProcessor.java:1328)
at 

[jira] [Commented] (AMBARI-15389) Intermittent YARN service check failures during and post EU

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15389:
-

SUCCESS: Integrated in Ambari-branch-2.2 #575 (See 
[https://builds.apache.org/job/Ambari-branch-2.2/575/])
AMBARI-15389. Intermittent YARN service check failures during and post (hiveww: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=78eafc7b4a7b189ef895fad1e500d84d30c4c0c4])
* ambari-web/app/utils/configs/config_property_helper.js


> Intermittent YARN service check failures during and post EU
> ---
>
> Key: AMBARI-15389
> URL: https://issues.apache.org/jira/browse/AMBARI-15389
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Dmitry Lysnichenko
>Assignee: Antonenko Alexander
> Fix For: 2.2.2
>
> Attachments: AMBARI-15389.patch, AMBARI-15389.patch, 
> AMBARI-15389_2.2.patch
>
>
> Build # - Ambari 2.2.1.1 - #63
> Observed this issue in a couple of EU runs recently where YARN service check 
> reports failure
> a. In one test, the EU ran from HDP 2.3.4.0 to 2.4.0.0 and YARN service check 
> reported failure during EU itself; a retry of the operation led to service 
> check being successful
> b. In another test post EU when YARN service check was run, it reported 
> failure; afterwards when I ran it again - success
> Looks like there is some corner condition which causes this issue to be hit
> {code}
> stderr:   /var/lib/ambari-agent/data/errors-822.txt
> Traceback (most recent call last):
> File 
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/service_check.py",
>  line 142, in 
> ServiceCheck().execute()
> File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 219, in execute
> method(env)
> File 
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/service_check.py",
>  line 104, in service_check
> user=params.smokeuser,
> 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 '/usr/bin/kinit -kt 
> /etc/security/keytabs/smokeuser.headless.keytab ambari...@example.com; yarn 
> org.apache.hadoop.yarn.applications.distributedshell.Client -shell_command ls 
> -num_containers 1 -jar 
> /usr/hdp/current/hadoop-yarn-client/hadoop-yarn-applications-distributedshell.jar'
>  returned 2.  Hortonworks #
> This is MOTD message, added for testing in qe infra
> 16/03/03 02:33:51 INFO impl.TimelineClientImpl: Timeline service address: 
> http://host:8188/ws/v1/timeline/
> 16/03/03 02:33:51 INFO distributedshell.Client: Initializing Client
> 16/03/03 02:33:51 INFO distributedshell.Client: Running Client
> 16/03/03 02:33:51 INFO client.RMProxy: Connecting to ResourceManager at 
> host-9-5.test/127.0.0.254:8050
> 16/03/03 02:33:53 INFO distributedshell.Client: Got Cluster metric info from 
> ASM, numNodeManagers=3
> 16/03/03 02:33:53 INFO distributedshell.Client: Got Cluster node info from ASM
> 16/03/03 02:33:53 INFO distributedshell.Client: Got node report from ASM for, 
> nodeId=host:25454, nodeAddresshost:8042, nodeRackName/default-rack, 
> nodeNumContainers1
> 16/03/03 02:33:53 INFO distributedshell.Client: Got node report from ASM for, 
> nodeId=host-9-5.test:25454, nodeAddresshost-9-5.test:8042, 
> nodeRackName/default-rack, nodeNumContainers0
> 16/03/03 02:33:53 INFO distributedshell.Client: Got node report from ASM for, 
> nodeId=host-9-1.test:25454, nodeAddresshost-9-1.test:8042, 
> nodeRackName/default-rack, nodeNumContainers0
> 16/03/03 02:33:53 INFO distributedshell.Client: Queue info, 
> queueName=default, queueCurrentCapacity=0.08336, queueMaxCapacity=1.0, 
> queueApplicationCount=0, queueChildQueueCount=0
> 16/03/03 02:33:53 INFO distributedshell.Client: User ACL Info for Queue, 
> queueName=root, userAcl=SUBMIT_APPLICATIONS
> 16/03/03 02:33:53 INFO distributedshell.Client: User ACL Info for Queue, 
> queueName=default, userAcl=SUBMIT_APPLICATIONS
> 16/03/03 02:33:53 INFO distributedshell.Client: Max mem capabililty of 
> resources in this cluster 10240
> 16/03/03 02:33:53 INFO distributedshell.Client: Max virtual cores capabililty 
> of resources in this cluster 1
> 16/03/03 02:33:53 INFO 

[jira] [Updated] (AMBARI-15651) Sqoop client install

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk updated AMBARI-15651:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to trunk

> Sqoop client install
> 
>
> Key: AMBARI-15651
> URL: https://issues.apache.org/jira/browse/AMBARI-15651
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15651.patch
>
>




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

[jira] [Updated] (AMBARI-15650) Output short logs summary on start/stop failure

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk updated AMBARI-15650:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to trunk

> Output short logs summary on start/stop failure
> ---
>
> Key: AMBARI-15650
> URL: https://issues.apache.org/jira/browse/AMBARI-15650
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15650.patch
>
>
> There were tons of situations when we had only output of task failure, when a 
> certain service failed to start/stop/restart, but couldn't get the logs of 
> services.
> Which makes fixing those bugs pretty problematic or even impossible if no 
> reproduce is available.
> This jira aims to output a short tail of service logs on start/stop failures, 
> this should cover a big part of such a scenarios.



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

[jira] [Commented] (AMBARI-15651) Sqoop client install

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-15651:


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

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

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

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

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

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

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

This message is automatically generated.

> Sqoop client install
> 
>
> Key: AMBARI-15651
> URL: https://issues.apache.org/jira/browse/AMBARI-15651
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15651.patch
>
>




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

[jira] [Resolved] (AMBARI-10519) Ambari 2.0 stack upgrade HDP 2.2.0.0 => 2.2.4.0 breaks on HDFS HA JournalNode rollEdits: "Access denied for user jn. Superuser privilege is required"

[Robert Levas (JIRA)]

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

Robert Levas resolved AMBARI-10519.
---
Resolution: Duplicate

> Ambari 2.0 stack upgrade HDP 2.2.0.0 => 2.2.4.0 breaks on HDFS HA JournalNode 
> rollEdits: "Access denied for user jn. Superuser privilege is required"
> -
>
> Key: AMBARI-10519
> URL: https://issues.apache.org/jira/browse/AMBARI-10519
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, stacks
>Affects Versions: 2.0.0
> Environment: HDP 2.2.0.0 => 2.2.4.0
>Reporter: Hari Sekhon
>Assignee: Robert Levas
> Attachments: errors-5550.txt, output-5550.txt
>
>
> During upgrade of HDP stack 2.2.0.0 => 2.2.4.0 with Ambari 2.0 the procedure 
> fails with the following error:
> {code}
> 2015-04-16 11:56:02,083 - Ensuring Journalnode quorum is established
> 2015-04-16 11:56:02,083 - u"Execute['/usr/bin/kinit -kt 
> /etc/security/keytabs/jn.service.keytab 
> jn/lonsl1101978-data-dr.uk.net.intra@LOCALDOMAIN;']" {'user': 'hdfs'}
> 2015-04-16 11:56:07,320 - u"Execute['hdfs dfsadmin -rollEdits']" {'tries': 1, 
> 'user': 'hdfs'}
> 2015-04-16 11:56:13,198 - Error while executing command 'restart':
> Traceback (most recent call last):
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 214, in execute
> method(env)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 374, in restart
> self.post_rolling_restart(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HDFS/2.1.0.2.0/package/scripts/journalnode.py",
>  line 72, in post_rolling_restart
> journalnode_upgrade.post_upgrade_check()
>   File 
> "/var/lib/ambari-agent/cache/common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py",
>  line 42, in post_upgrade_check
> hdfs_roll_edits()
>   File 
> "/var/lib/ambari-agent/cache/common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py",
>  line 83, in hdfs_roll_edits
> Execute(command, user=params.hdfs_user, tries=1)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
> line 148, 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 274, in action_run
> raise ex
> Fail: Execution of 'hdfs dfsadmin -rollEdits' returned 255. rollEdits: Access 
> denied for user jn. Superuser privilege is required
>   at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkSuperuserPrivilege(FSPermissionChecker.java:109)
>   at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.checkSuperuserPrivilege(FSNamesystem.java:6484)
>   at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.rollEditLog(FSNamesystem.java:6338)
>   at 
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.rollEdits(NameNodeRpcServer.java:907)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.rollEdits(ClientNamenodeProtocolServerSideTranslatorPB.java:741)
>   at 
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:619)
>   at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:962)
>   at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2039)
>   at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2035)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:415)
>   at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628)
>   at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2033)
> 2015-04-16 11:56:13,291 - Command: /usr/bin/hdp-select status 
> hadoop-hdfs-journalnode > /tmp/tmprZ57xv
> Output: hadoop-hdfs-journalnode - 2.2.4.0-2633
> {code}
> Hari Sekhon
> http://www.linkedin.com/in/harisekhon



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

[jira] [Updated] (AMBARI-15645) Upgrading Kerberized JournalNode requires HDFS principal to perform 'role edits' task

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-15645:
--
Attachment: AMBARI-15645_branch-2.2_01.patch

> Upgrading Kerberized JournalNode requires HDFS principal to perform 'role 
> edits' task
> -
>
> Key: AMBARI-15645
> URL: https://issues.apache.org/jira/browse/AMBARI-15645
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.2.2
>
> Attachments: AMBARI-15645_branch-2.2_01.patch, 
> AMBARI-15645_trunk_01.patch
>
>
> After upgrading HDP in Ambari version 2.1.2.1 a task a performed to _role 
> edits_ while restarting JournalNodes. If Kerberos is enabled, the JN Kerberos 
> identity is established before making this call when really the HDFS identity 
> should be established - since this is an administrative HDFS call that 
> requires the HDFS administrator user to perform.
> Because of this, the following error is generated and seen in the :
> {noformat}
> Fail: Execution of 'hdfs dfsadmin -rollEdits' returned 255. rollEdits: Access 
> denied for user jn. Superuser privilege is required
> {noformat}
> The offending code is
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
>   if params.security_enabled:
> Execute(params.jn_kinit_cmd, user=params.hdfs_user)
>   time.sleep(5)
>   hdfs_roll_edits()
>   time.sleep(5)
> {code}
> It should probably be something like:
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
>   if params.security_enabled:
> Execute(params.hdfs_kinit_cmd, user=params.hdfs_user)
>   time.sleep(5)
>   hdfs_roll_edits()
>   time.sleep(5)
> {code}
> *Note the change from jn to hdfs in the kinit command line.*
> This issue has also been posted in 
> https://issues.apache.org/jira/browse/AMBARI-10519.



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

[jira] [Updated] (AMBARI-15645) Upgrading Kerberized JournalNode requires HDFS principal to perform 'role edits' task

[Robert Levas (JIRA)]

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

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

> Upgrading Kerberized JournalNode requires HDFS principal to perform 'role 
> edits' task
> -
>
> Key: AMBARI-15645
> URL: https://issues.apache.org/jira/browse/AMBARI-15645
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.2.2
>
> Attachments: AMBARI-15645_trunk_01.patch
>
>
> After upgrading HDP in Ambari version 2.1.2.1 a task a performed to _role 
> edits_ while restarting JournalNodes. If Kerberos is enabled, the JN Kerberos 
> identity is established before making this call when really the HDFS identity 
> should be established - since this is an administrative HDFS call that 
> requires the HDFS administrator user to perform.
> Because of this, the following error is generated and seen in the :
> {noformat}
> Fail: Execution of 'hdfs dfsadmin -rollEdits' returned 255. rollEdits: Access 
> denied for user jn. Superuser privilege is required
> {noformat}
> The offending code is
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
>   if params.security_enabled:
> Execute(params.jn_kinit_cmd, user=params.hdfs_user)
>   time.sleep(5)
>   hdfs_roll_edits()
>   time.sleep(5)
> {code}
> It should probably be something like:
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
>   if params.security_enabled:
> Execute(params.hdfs_kinit_cmd, user=params.hdfs_user)
>   time.sleep(5)
>   hdfs_roll_edits()
>   time.sleep(5)
> {code}
> *Note the change from jn to hdfs in the kinit command line.*
> This issue has also been posted in 
> https://issues.apache.org/jira/browse/AMBARI-10519.



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

[jira] [Updated] (AMBARI-15645) Upgrading Kerberized JournalNode requires HDFS principal to perform 'role edits' task

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-15645:
--
Attachment: AMBARI-15645_trunk_01.patch

> Upgrading Kerberized JournalNode requires HDFS principal to perform 'role 
> edits' task
> -
>
> Key: AMBARI-15645
> URL: https://issues.apache.org/jira/browse/AMBARI-15645
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.2.2
>
> Attachments: AMBARI-15645_trunk_01.patch
>
>
> After upgrading HDP in Ambari version 2.1.2.1 a task a performed to _role 
> edits_ while restarting JournalNodes. If Kerberos is enabled, the JN Kerberos 
> identity is established before making this call when really the HDFS identity 
> should be established - since this is an administrative HDFS call that 
> requires the HDFS administrator user to perform.
> Because of this, the following error is generated and seen in the :
> {noformat}
> Fail: Execution of 'hdfs dfsadmin -rollEdits' returned 255. rollEdits: Access 
> denied for user jn. Superuser privilege is required
> {noformat}
> The offending code is
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
>   if params.security_enabled:
> Execute(params.jn_kinit_cmd, user=params.hdfs_user)
>   time.sleep(5)
>   hdfs_roll_edits()
>   time.sleep(5)
> {code}
> It should probably be something like:
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
>   if params.security_enabled:
> Execute(params.hdfs_kinit_cmd, user=params.hdfs_user)
>   time.sleep(5)
>   hdfs_roll_edits()
>   time.sleep(5)
> {code}
> *Note the change from jn to hdfs in the kinit command line.*
> This issue has also been posted in 
> https://issues.apache.org/jira/browse/AMBARI-10519.



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

[jira] [Updated] (AMBARI-15645) Upgrading Kerberized JournalNode requires HDFS principal to perform 'role edits' task

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-15645:
--
Attachment: (was: AMBARI-15645_trunk_01.patch)

> Upgrading Kerberized JournalNode requires HDFS principal to perform 'role 
> edits' task
> -
>
> Key: AMBARI-15645
> URL: https://issues.apache.org/jira/browse/AMBARI-15645
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.2.2
>
> Attachments: AMBARI-15645_trunk_01.patch
>
>
> After upgrading HDP in Ambari version 2.1.2.1 a task a performed to _role 
> edits_ while restarting JournalNodes. If Kerberos is enabled, the JN Kerberos 
> identity is established before making this call when really the HDFS identity 
> should be established - since this is an administrative HDFS call that 
> requires the HDFS administrator user to perform.
> Because of this, the following error is generated and seen in the :
> {noformat}
> Fail: Execution of 'hdfs dfsadmin -rollEdits' returned 255. rollEdits: Access 
> denied for user jn. Superuser privilege is required
> {noformat}
> The offending code is
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
>   if params.security_enabled:
> Execute(params.jn_kinit_cmd, user=params.hdfs_user)
>   time.sleep(5)
>   hdfs_roll_edits()
>   time.sleep(5)
> {code}
> It should probably be something like:
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
>   if params.security_enabled:
> Execute(params.hdfs_kinit_cmd, user=params.hdfs_user)
>   time.sleep(5)
>   hdfs_roll_edits()
>   time.sleep(5)
> {code}
> *Note the change from jn to hdfs in the kinit command line.*
> This issue has also been posted in 
> https://issues.apache.org/jira/browse/AMBARI-10519.



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

[jira] [Updated] (AMBARI-15645) Upgrading Kerberized JournalNode requires HDFS principal to perform 'role edits' task

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-15645:
--
Attachment: AMBARI-15645_trunk_01.patch

> Upgrading Kerberized JournalNode requires HDFS principal to perform 'role 
> edits' task
> -
>
> Key: AMBARI-15645
> URL: https://issues.apache.org/jira/browse/AMBARI-15645
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.2.2
>
> Attachments: AMBARI-15645_trunk_01.patch
>
>
> After upgrading HDP in Ambari version 2.1.2.1 a task a performed to _role 
> edits_ while restarting JournalNodes. If Kerberos is enabled, the JN Kerberos 
> identity is established before making this call when really the HDFS identity 
> should be established - since this is an administrative HDFS call that 
> requires the HDFS administrator user to perform.
> Because of this, the following error is generated and seen in the :
> {noformat}
> Fail: Execution of 'hdfs dfsadmin -rollEdits' returned 255. rollEdits: Access 
> denied for user jn. Superuser privilege is required
> {noformat}
> The offending code is
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
>   if params.security_enabled:
> Execute(params.jn_kinit_cmd, user=params.hdfs_user)
>   time.sleep(5)
>   hdfs_roll_edits()
>   time.sleep(5)
> {code}
> It should probably be something like:
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
>   if params.security_enabled:
> Execute(params.hdfs_kinit_cmd, user=params.hdfs_user)
>   time.sleep(5)
>   hdfs_roll_edits()
>   time.sleep(5)
> {code}
> *Note the change from jn to hdfs in the kinit command line.*
> This issue has also been posted in 
> https://issues.apache.org/jira/browse/AMBARI-10519.



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

[jira] [Commented] (AMBARI-15650) Output short logs summary on start/stop failure

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-15650:


{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12796313/AMBARI-15650.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:green}+1 core tests{color}.  The patch passed unit tests in 
ambari-server.

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

This message is automatically generated.

> Output short logs summary on start/stop failure
> ---
>
> Key: AMBARI-15650
> URL: https://issues.apache.org/jira/browse/AMBARI-15650
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15650.patch
>
>
> There were tons of situations when we had only output of task failure, when a 
> certain service failed to start/stop/restart, but couldn't get the logs of 
> services.
> Which makes fixing those bugs pretty problematic or even impossible if no 
> reproduce is available.
> This jira aims to output a short tail of service logs on start/stop failures, 
> this should cover a big part of such a scenarios.



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

[jira] [Updated] (AMBARI-15651) Sqoop client install

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk updated AMBARI-15651:
-
Attachment: AMBARI-15651.patch

> Sqoop client install
> 
>
> Key: AMBARI-15651
> URL: https://issues.apache.org/jira/browse/AMBARI-15651
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15651.patch
>
>




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

[jira] [Updated] (AMBARI-15651) Sqoop client install

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk updated AMBARI-15651:
-
Status: Patch Available  (was: Open)

> Sqoop client install
> 
>
> Key: AMBARI-15651
> URL: https://issues.apache.org/jira/browse/AMBARI-15651
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15651.patch
>
>




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

[jira] [Created] (AMBARI-15651) Sqoop client install

[Andrew Onischuk (JIRA)]

Andrew Onischuk created AMBARI-15651:


 Summary: Sqoop client install
 Key: AMBARI-15651
 URL: https://issues.apache.org/jira/browse/AMBARI-15651
 Project: Ambari
  Issue Type: Bug
Reporter: Andrew Onischuk
Assignee: Andrew Onischuk
 Fix For: 2.4.0
 Attachments: AMBARI-15651.patch





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

[jira] [Updated] (AMBARI-15592) Auto-start services: Support blueprint deployment

[Nahappan Somasundaram (JIRA)]

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

Nahappan Somasundaram updated AMBARI-15592:
---
Attachment: rb45347.patch

> Auto-start services: Support blueprint deployment
> -
>
> Key: AMBARI-15592
> URL: https://issues.apache.org/jira/browse/AMBARI-15592
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.4.0
>
> Attachments: rb45347.patch
>
>
> Add support to blueprint to enable auto start of services.



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

[jira] [Updated] (AMBARI-15592) Auto-start services: Support blueprint deployment

[Nahappan Somasundaram (JIRA)]

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

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

> Auto-start services: Support blueprint deployment
> -
>
> Key: AMBARI-15592
> URL: https://issues.apache.org/jira/browse/AMBARI-15592
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.4.0
>
> Attachments: rb45347.patch
>
>
> Add support to blueprint to enable auto start of services.



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

[jira] [Updated] (AMBARI-15592) Auto-start services: Support blueprint deployment

[Nahappan Somasundaram (JIRA)]

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

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

> Auto-start services: Support blueprint deployment
> -
>
> Key: AMBARI-15592
> URL: https://issues.apache.org/jira/browse/AMBARI-15592
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.4.0
>
> Attachments: rb45347.patch
>
>
> Add support to blueprint to enable auto start of services.



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

[jira] [Commented] (AMBARI-15649) Service Actions button is missing

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-15649:


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

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

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

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

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

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

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

This message is automatically generated.

> Service Actions button is missing
> -
>
> Key: AMBARI-15649
> URL: https://issues.apache.org/jira/browse/AMBARI-15649
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-15649.patch
>
>
> After couple of seconds Service Actions button is hidden



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

[jira] [Updated] (AMBARI-15650) Output short logs summary on start/stop failure

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk updated AMBARI-15650:
-
Attachment: AMBARI-15650.patch

> Output short logs summary on start/stop failure
> ---
>
> Key: AMBARI-15650
> URL: https://issues.apache.org/jira/browse/AMBARI-15650
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15650.patch
>
>




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

[jira] [Updated] (AMBARI-15650) Output short logs summary on start/stop failure

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk updated AMBARI-15650:
-
Description: 
There were tons of situations when we had only output of task failure, when a 
certain service failed to start/stop/restart, but couldn't get the logs of 
services.
Which makes fixing those bugs pretty problematic or even impossible if no 
reproduce is available.
This jira aims to output a short tail of service logs on start/stop failures, 
this should cover a big part of such a scenarios.

> Output short logs summary on start/stop failure
> ---
>
> Key: AMBARI-15650
> URL: https://issues.apache.org/jira/browse/AMBARI-15650
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15650.patch
>
>
> There were tons of situations when we had only output of task failure, when a 
> certain service failed to start/stop/restart, but couldn't get the logs of 
> services.
> Which makes fixing those bugs pretty problematic or even impossible if no 
> reproduce is available.
> This jira aims to output a short tail of service logs on start/stop failures, 
> this should cover a big part of such a scenarios.



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

[jira] [Commented] (AMBARI-15644) Dev Deploy: stack_advisor failed to recommend Hive Configurations (secured cluster)

[Hudson (JIRA)]

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

Hudson commented on AMBARI-15644:
-

ABORTED: Integrated in Ambari-trunk-Commit #4571 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4571/])
AMBARI-15644. Dev Deploy: stack_advisor failed to recommend Hive (aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=a88f8cba3d2f825fb608e299d9467a6bf292423f])
* ambari-server/src/main/resources/stacks/HDP/2.1/services/stack_advisor.py


> Dev Deploy: stack_advisor failed to recommend Hive Configurations (secured 
> cluster)
> ---
>
> Key: AMBARI-15644
> URL: https://issues.apache.org/jira/browse/AMBARI-15644
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-15644.patch
>
>
> Traceback (most recent call last):
>   File "/var/lib/ambari-server/resources/scripts/stack_advisor.py", line 
> 158, in 
> main(sys.argv)
>   File "/var/lib/ambari-server/resources/scripts/stack_advisor.py", line 
> 109, in main
> result = stackAdvisor.recommendConfigurations(services, hosts)
>   File 
> "/var/lib/ambari-server/resources/scripts/../stacks/stack_advisor.py", line 
> 570, in recommendConfigurations
> calculation(configurations, clusterSummary, services, hosts)
>   File 
> "/var/lib/ambari-server/resources/scripts/./../stacks/HDP/2.3/services/stack_advisor.py",
>  line 283, in recommendHIVEConfigurations
> super(HDP23StackAdvisor, 
> self).recommendHIVEConfigurations(configurations, clusterData, services, 
> hosts)
>   File 
> "/var/lib/ambari-server/resources/scripts/./../stacks/HDP/2.2/services/stack_advisor.py",
>  line 257, in recommendHIVEConfigurations
> super(HDP22StackAdvisor, 
> self).recommendHiveConfigurations(configurations, clusterData, services, 
> hosts)
>   File 
> "/var/lib/ambari-server/resources/scripts/./../stacks/HDP/2.1/services/stack_advisor.py",
>  line 104, in recommendHiveConfigurations
> webHcatSitePropertyAttributes = 
> self.putPropertyAttribute(configurations, "webhcat-site", services)
> TypeError: putPropertyAttribute() takes exactly 3 arguments (4 given)
> 



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