[jira] [Created] (AMBARI-20061) Should allow the alert Instance Response dialog embedded the super link to other product

[Zhao Yi Ming (JIRA)]

Zhao Yi Ming created AMBARI-20061:
-

 Summary: Should allow the alert Instance Response dialog embedded 
the super link to other product
 Key: AMBARI-20061
 URL: https://issues.apache.org/jira/browse/AMBARI-20061
 Project: Ambari
  Issue Type: Improvement
  Components: alerts
Reporter: Zhao Yi Ming


We create a knowledge base to make the user can easily yo find out an alert 
solution, then we want to link the knowledge base URL with Ambari alter  
Instance Response dialog content. But the  Instance Response dialog content js 
code replace the <> with , so we want to not replace the <>, the easy 
way it use Handlebars.SafeString to make the string is safe string, so the js 
will not replace the <>. here is 2 scenarios
1. Want to super link, so user can add string like "aaa" in 
his alert py
2. Did not use super link but the Instance Response dialog content include the 
<>, user can add a string like "aa" in his alert py scripts.

Anyone can help improve this fix? Thanks a lot!






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-19646) AMBARI Java services do not resolve localhost FQDN properly in some cases

[kevin.chen (JIRA)]

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

kevin.chen commented on AMBARI-19646:
-

hi Piotr Tylenda

I don't think this is a problem,  the standard configuration is like this 

127.0.0.1   some-ambari-server.org   localhost



> AMBARI Java services do not resolve localhost FQDN properly in some cases
> -
>
> Key: AMBARI-19646
> URL: https://issues.apache.org/jira/browse/AMBARI-19646
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.2
> Environment: Ubuntu 14 LTS
> HDP 2.5.3.0-37
>Reporter: Piotr Tylenda
>Assignee: kevin.chen
>Priority: Minor
>
> When installing hive client I have noticed the following problem in the logs:
> {code}
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_client.py",
>  line 68, in 
> HiveClient().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 280, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_client.py",
>  line 35, in install
> self.configure(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_client.py",
>  line 43, in configure
> hive(name='client')
>   File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py", 
> line 89, in thunk
> return fn(*args, **kwargs)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive.py",
>  line 282, in hive
> mode = 0644,
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
> line 155, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 160, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 124, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 123, in action_create
> content = self._get_content()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 160, in _get_content
> return content()
>   File "/usr/lib/python2.6/site-packages/resource_management/core/source.py", 
> line 51, in __call__
> return self.get_content()
>   File "/usr/lib/python2.6/site-packages/resource_management/core/source.py", 
> line 193, in get_content
> web_file = opener.open(req)
>   File "/usr/lib/python2.7/urllib2.py", line 404, in open
> response = self._open(req, data)
>   File "/usr/lib/python2.7/urllib2.py", line 422, in _open
> '_open', req)
>   File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
> result = func(*args)
>   File "/usr/lib/python2.7/urllib2.py", line 1214, in http_open
> return self.do_open(httplib.HTTPConnection, req)
>   File "/usr/lib/python2.7/urllib2.py", line 1184, in do_open
> raise URLError(err)
> urllib2.URLError: 
> {code}
> Which was caused by:
> {code}
> 2017-01-19 16:00:55,016 - 
> File['/usr/lib/ambari-agent/DBConnectionVerification.jar'] {'content': 
> DownloadSource('http://localhost:8080/resources/DBConnectionVerification.jar'),
>  'mode': 0644}
> {code}
> I have searched through the python files and have found that jdk_location in 
> ambari properties is set to "http://localhost:8080/resources;.
> This property is resolved in this file 
> https://github.com/apache/ambari/blob/ddcc13b40902f7fc9144bcaa2af5b54d85442dfa/ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
> After that I have tested how this java code behaves on the ambari server 
> machine:
> {code}
> InetAddress.getLocalHost().getCanonicalHostName();
> {code}
> The result is "localhost" (not as expected)
> For command
> {code}
> hostname -f
> {code}
> returns "some-ambari-server.org" (as expected)
> Python code
> {code}
> python -c 'import socket; print(socket.getfqdn())'
> {code}
> returns "some-ambari-server.org" (as expected)
> It seems that such entry in /etc/hosts
> {code}
> 127.0.0.1   localhost   some-ambari-server.org
> {code}
> causes this situation and changing this to
> {code}
> 127.0.0.1   some-ambari-server.org   localhost
> {code}
> fixed the issue.
> I am not sure if it is actually something that should be fixed in code or 
> mentioned in docs - it makes the ambari environment partially stable, apart 
> from the parts which require jdk_location property.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (AMBARI-19646) AMBARI Java services do not resolve localhost FQDN properly in some cases

[kevin.chen (JIRA)]

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

kevin.chen reassigned AMBARI-19646:
---

Assignee: kevin.chen

> AMBARI Java services do not resolve localhost FQDN properly in some cases
> -
>
> Key: AMBARI-19646
> URL: https://issues.apache.org/jira/browse/AMBARI-19646
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.2
> Environment: Ubuntu 14 LTS
> HDP 2.5.3.0-37
>Reporter: Piotr Tylenda
>Assignee: kevin.chen
>Priority: Minor
>
> When installing hive client I have noticed the following problem in the logs:
> {code}
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_client.py",
>  line 68, in 
> HiveClient().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 280, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_client.py",
>  line 35, in install
> self.configure(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_client.py",
>  line 43, in configure
> hive(name='client')
>   File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py", 
> line 89, in thunk
> return fn(*args, **kwargs)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive.py",
>  line 282, in hive
> mode = 0644,
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
> line 155, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 160, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 124, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 123, in action_create
> content = self._get_content()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 160, in _get_content
> return content()
>   File "/usr/lib/python2.6/site-packages/resource_management/core/source.py", 
> line 51, in __call__
> return self.get_content()
>   File "/usr/lib/python2.6/site-packages/resource_management/core/source.py", 
> line 193, in get_content
> web_file = opener.open(req)
>   File "/usr/lib/python2.7/urllib2.py", line 404, in open
> response = self._open(req, data)
>   File "/usr/lib/python2.7/urllib2.py", line 422, in _open
> '_open', req)
>   File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
> result = func(*args)
>   File "/usr/lib/python2.7/urllib2.py", line 1214, in http_open
> return self.do_open(httplib.HTTPConnection, req)
>   File "/usr/lib/python2.7/urllib2.py", line 1184, in do_open
> raise URLError(err)
> urllib2.URLError: 
> {code}
> Which was caused by:
> {code}
> 2017-01-19 16:00:55,016 - 
> File['/usr/lib/ambari-agent/DBConnectionVerification.jar'] {'content': 
> DownloadSource('http://localhost:8080/resources/DBConnectionVerification.jar'),
>  'mode': 0644}
> {code}
> I have searched through the python files and have found that jdk_location in 
> ambari properties is set to "http://localhost:8080/resources;.
> This property is resolved in this file 
> https://github.com/apache/ambari/blob/ddcc13b40902f7fc9144bcaa2af5b54d85442dfa/ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
> After that I have tested how this java code behaves on the ambari server 
> machine:
> {code}
> InetAddress.getLocalHost().getCanonicalHostName();
> {code}
> The result is "localhost" (not as expected)
> For command
> {code}
> hostname -f
> {code}
> returns "some-ambari-server.org" (as expected)
> Python code
> {code}
> python -c 'import socket; print(socket.getfqdn())'
> {code}
> returns "some-ambari-server.org" (as expected)
> It seems that such entry in /etc/hosts
> {code}
> 127.0.0.1   localhost   some-ambari-server.org
> {code}
> causes this situation and changing this to
> {code}
> 127.0.0.1   some-ambari-server.org   localhost
> {code}
> fixed the issue.
> I am not sure if it is actually something that should be fixed in code or 
> mentioned in docs - it makes the ambari environment partially stable, apart 
> from the parts which require jdk_location property.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20060) update the headroom for llap - hdp stack

[Siddharth Seth (JIRA)]

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

Siddharth Seth updated AMBARI-20060:

Attachment: AMBARI-20060.01.patch

cc [~sumitmohanty], [~swapanshridhar] for review.

> update the headroom for llap - hdp stack
> 
>
> Key: AMBARI-20060
> URL: https://issues.apache.org/jira/browse/AMBARI-20060
> Project: Ambari
>  Issue Type: Task
>  Components: stacks
>Reporter: Siddharth Seth
>Assignee: Siddharth Seth
> Fix For: 2.5.0
>
> Attachments: AMBARI-20060.01.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20060) update the headroom for llap - hdp stack

[Siddharth Seth (JIRA)]

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

Siddharth Seth updated AMBARI-20060:

Status: Patch Available  (was: Open)

> update the headroom for llap - hdp stack
> 
>
> Key: AMBARI-20060
> URL: https://issues.apache.org/jira/browse/AMBARI-20060
> Project: Ambari
>  Issue Type: Task
>  Components: stacks
>Reporter: Siddharth Seth
>Assignee: Siddharth Seth
> Fix For: 2.5.0
>
> Attachments: AMBARI-20060.01.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20060) update the headroom for llap - hdp stack

[Siddharth Seth (JIRA)]

Siddharth Seth created AMBARI-20060:
---

 Summary: update the headroom for llap - hdp stack
 Key: AMBARI-20060
 URL: https://issues.apache.org/jira/browse/AMBARI-20060
 Project: Ambari
  Issue Type: Task
  Components: stacks
Reporter: Siddharth Seth
Assignee: Siddharth Seth
 Fix For: 2.5.0






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20058) 'Final' is not shown correctly in config diff tool and in older versions

[Richard Zang (JIRA)]

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

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

> 'Final' is not shown correctly in config diff tool and in older versions  
> -
>
> Key: AMBARI-20058
> URL: https://issues.apache.org/jira/browse/AMBARI-20058
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Dhanya Balasundaran
>Assignee: Richard Zang
> Fix For: 2.5.0
>
> Attachments: AMBARI-20058.patch
>
>
> - Issue1
> From api call we can see that fs.defaultFS is set to final in version 2 where 
> as we cant see that on UI when we navigate to V2
> - Issue2
> Compare V6 to V2
> V2 shows final for fs.defaultFS
> Compare V2 to V6
> V2 doesnt show final for the property
> - Issue3
> Set final to any of the properties
> Make sure its shown on UI
> Compare it with an older version
> Diff doesnt show final for this property



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20058) 'Final' is not shown correctly in config diff tool and in older versions

[Richard Zang (JIRA)]

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

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

> 'Final' is not shown correctly in config diff tool and in older versions  
> -
>
> Key: AMBARI-20058
> URL: https://issues.apache.org/jira/browse/AMBARI-20058
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Dhanya Balasundaran
>Assignee: Richard Zang
> Fix For: 2.5.0
>
> Attachments: AMBARI-20058.patch
>
>
> - Issue1
> From api call we can see that fs.defaultFS is set to final in version 2 where 
> as we cant see that on UI when we navigate to V2
> - Issue2
> Compare V6 to V2
> V2 shows final for fs.defaultFS
> Compare V2 to V6
> V2 doesnt show final for the property
> - Issue3
> Set final to any of the properties
> Make sure its shown on UI
> Compare it with an older version
> Diff doesnt show final for this property



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (AMBARI-20058) 'Final' is not shown correctly in config diff tool and in older versions

[Richard Zang (JIRA)]

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

Richard Zang reassigned AMBARI-20058:
-

Assignee: Richard Zang

> 'Final' is not shown correctly in config diff tool and in older versions  
> -
>
> Key: AMBARI-20058
> URL: https://issues.apache.org/jira/browse/AMBARI-20058
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Dhanya Balasundaran
>Assignee: Richard Zang
> Fix For: 2.5.0
>
>
> - Issue1
> From api call we can see that fs.defaultFS is set to final in version 2 where 
> as we cant see that on UI when we navigate to V2
> - Issue2
> Compare V6 to V2
> V2 shows final for fs.defaultFS
> Compare V2 to V6
> V2 doesnt show final for the property
> - Issue3
> Set final to any of the properties
> Make sure its shown on UI
> Compare it with an older version
> Diff doesnt show final for this property



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20059) Storm config change results in Consistency check failed

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20059:


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

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

This message is automatically generated.

> Storm config change results in Consistency check failed
> ---
>
> Key: AMBARI-20059
> URL: https://issues.apache.org/jira/browse/AMBARI-20059
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Denys Buzhor
>Assignee: Denys Buzhor
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20059.patch
>
>
> steps to reproduce:
> # install cluster with Storm and Ranger
> # go to Services -> Storm -> Configs
> # change any config
> # save configs
> observes configuration validation failure due to absent Yarn configs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20051) Hosts filter component list is not sorted so it is difficult to use

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20051:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6770 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6770/])
AMBARI-20051. Hosts filter component list is not sorted so it is (akovalenko: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=ce404d640e930b7326dc1857ac1ae6ce03b2884e])
* (edit) ambari-web/test/views/main/host/combo_search_box_test.js
* (edit) ambari-web/app/views/main/host/combo_search_box.js


> Hosts filter component list is not sorted so it is difficult to use
> ---
>
> Key: AMBARI-20051
> URL: https://issues.apache.org/jira/browse/AMBARI-20051
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Aleksandr Kovalenko
>Assignee: Aleksandr Kovalenko
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20051_branch-2.5.patch, AMBARI-20051.patch, 
> Screen Shot 2017-02-15 at 6.32.34 PM.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20051) Hosts filter component list is not sorted so it is difficult to use

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20051:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1020 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1020/])
AMBARI-20051. Hosts filter component list is not sorted so it is (akovalenko: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=924f9964a2f67642591a28006b5a30fe6e4b7919])
* (edit) ambari-web/app/views/main/host/combo_search_box.js


> Hosts filter component list is not sorted so it is difficult to use
> ---
>
> Key: AMBARI-20051
> URL: https://issues.apache.org/jira/browse/AMBARI-20051
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Aleksandr Kovalenko
>Assignee: Aleksandr Kovalenko
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20051_branch-2.5.patch, AMBARI-20051.patch, 
> Screen Shot 2017-02-15 at 6.32.34 PM.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20059) Storm config change results in Consistency check failed

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20059:


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

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

This message is automatically generated.

> Storm config change results in Consistency check failed
> ---
>
> Key: AMBARI-20059
> URL: https://issues.apache.org/jira/browse/AMBARI-20059
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Denys Buzhor
>Assignee: Denys Buzhor
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20059.patch
>
>
> steps to reproduce:
> # install cluster with Storm and Ranger
> # go to Services -> Storm -> Configs
> # change any config
> # save configs
> observes configuration validation failure due to absent Yarn configs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20051) Hosts filter component list is not sorted so it is difficult to use

[Aleksandr Kovalenko (JIRA)]

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

Aleksandr Kovalenko commented on AMBARI-20051:
--

committed to trunk and branch-2.5

> Hosts filter component list is not sorted so it is difficult to use
> ---
>
> Key: AMBARI-20051
> URL: https://issues.apache.org/jira/browse/AMBARI-20051
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Aleksandr Kovalenko
>Assignee: Aleksandr Kovalenko
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20051_branch-2.5.patch, AMBARI-20051.patch, 
> Screen Shot 2017-02-15 at 6.32.34 PM.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20051) Hosts filter component list is not sorted so it is difficult to use

[Aleksandr Kovalenko (JIRA)]

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

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

> Hosts filter component list is not sorted so it is difficult to use
> ---
>
> Key: AMBARI-20051
> URL: https://issues.apache.org/jira/browse/AMBARI-20051
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Aleksandr Kovalenko
>Assignee: Aleksandr Kovalenko
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20051_branch-2.5.patch, AMBARI-20051.patch, 
> Screen Shot 2017-02-15 at 6.32.34 PM.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20051) Hosts filter component list is not sorted so it is difficult to use

[Aleksandr Kovalenko (JIRA)]

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

Aleksandr Kovalenko commented on AMBARI-20051:
--

Actually patch includes changes to unit tests.

> Hosts filter component list is not sorted so it is difficult to use
> ---
>
> Key: AMBARI-20051
> URL: https://issues.apache.org/jira/browse/AMBARI-20051
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Aleksandr Kovalenko
>Assignee: Aleksandr Kovalenko
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20051_branch-2.5.patch, AMBARI-20051.patch, 
> Screen Shot 2017-02-15 at 6.32.34 PM.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20056) FIFO compaction resulting in too many store files on large cluster

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20056:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12853131/AMBARI-20056.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:red}-1 javac{color}.  The applied patch generated 115 javac 
compiler warnings (more than the trunk's current 113 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/10627//testReport/
Javac warnings: 
https://builds.apache.org/job/Ambari-trunk-test-patch/10627//artifact/trunk/patchprocess/diffJavacWarnings.txt
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/10627//console

This message is automatically generated.

> FIFO compaction resulting in too many store files on large cluster
> --
>
> Key: AMBARI-20056
> URL: https://issues.apache.org/jira/browse/AMBARI-20056
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20056.patch
>
>
> Set Data Tiered compaction for all tables except METRIC_RECORD
> This will allow number of store files to go down over time.  On a 500 node 
> cluster AMS can become in-operational after creating 18K store files and no 
> compaction.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20054) Remove Entities Associated With clusterconfigmapping

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20054:


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

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

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

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

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

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

  
org.apache.ambari.server.checks.DatabaseConsistencyCheckHelperTest
  org.apache.ambari.server.agent.TestHeartbeatHandler
  
org.apache.ambari.server.controller.metrics.RestMetricsPropertyProviderTest

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

This message is automatically generated.

> Remove Entities Associated With clusterconfigmapping
> 
>
> Key: AMBARI-20054
> URL: https://issues.apache.org/jira/browse/AMBARI-20054
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-20054.patch
>
>
> - Remove the {{clusterconfigmapping}} table, which has redundant columns and 
> causes nothing but headaches when it becomes out of sync with 
> {{clusterconfig}}
> - Change {{clusterconfig}} to track which configuration is selected and when 
> the last time it was selected was



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20036) Side Nav: implement the Services Actions

[Xi Wang (JIRA)]

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

Xi Wang updated AMBARI-20036:
-
Summary: Side Nav: implement the Services Actions   (was: UX: design new 
Services Actions )

> Side Nav: implement the Services Actions 
> -
>
> Key: AMBARI-20036
> URL: https://issues.apache.org/jira/browse/AMBARI-20036
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Xi Wang
>Assignee: Xi Wang
> Fix For: 3.0.0
>
> Attachments: AMBARI-20036.patch
>
>
> Now we have a button "Actions" with dropdown on the old service menu to 
> trigger actions to all services. 
> Need a new design and location of them.
> Maybe on the new Side Nav or "Services" page.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20059) Storm config change results in Consistency check failed

[Denys Buzhor (JIRA)]

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

Denys Buzhor updated AMBARI-20059:
--
Attachment: AMBARI-20059.patch

> Storm config change results in Consistency check failed
> ---
>
> Key: AMBARI-20059
> URL: https://issues.apache.org/jira/browse/AMBARI-20059
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Denys Buzhor
>Assignee: Denys Buzhor
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20059.patch
>
>
> steps to reproduce:
> # install cluster with Storm and Ranger
> # go to Services -> Storm -> Configs
> # change any config
> # save configs
> observes configuration validation failure due to absent Yarn configs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20059) Storm config change results in Consistency check failed

[Denys Buzhor (JIRA)]

Denys Buzhor created AMBARI-20059:
-

 Summary: Storm config change results in Consistency check failed
 Key: AMBARI-20059
 URL: https://issues.apache.org/jira/browse/AMBARI-20059
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.5.0
Reporter: Denys Buzhor
Assignee: Denys Buzhor
Priority: Critical
 Fix For: 2.5.0


steps to reproduce:
# install cluster with Storm and Ranger
# go to Services -> Storm -> Configs
# change any config
# save configs

observes configuration validation failure due to absent Yarn configs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20058) 'Final' is not shown correctly in config diff tool and in older versions

[Dhanya Balasundaran (JIRA)]

Dhanya Balasundaran created AMBARI-20058:


 Summary: 'Final' is not shown correctly in config diff tool and in 
older versions  
 Key: AMBARI-20058
 URL: https://issues.apache.org/jira/browse/AMBARI-20058
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.5.0
Reporter: Dhanya Balasundaran
 Fix For: 2.5.0


- Issue1
>From api call we can see that fs.defaultFS is set to final in version 2 where 
>as we cant see that on UI when we navigate to V2

- Issue2
Compare V6 to V2
V2 shows final for fs.defaultFS
Compare V2 to V6
V2 doesnt show final for the property

- Issue3
Set final to any of the properties
Make sure its shown on UI
Compare it with an older version
Diff doesnt show final for this property




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20017) PixieDust - Decrease Service Check running time under 3 mins

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20017:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6769 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6769/])
AMBARI-20017. PixieDust - Decrease Service Check running time under 3 
(dlysnichenko: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=18fc2586fa7410823b3d7a9354cf5b10be0dc2e0])
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.0.6/configuration/cluster-env.xml
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/state/ConfigHelper.java


> PixieDust - Decrease Service Check running time under 3 mins
> 
>
> Key: AMBARI-20017
> URL: https://issues.apache.org/jira/browse/AMBARI-20017
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-20017.2.patch, AMBARI-20017.3.patch, 
> AMBARI-20017.patch
>
>
> Right now, Ambari has a timeout of 5-10 mins for Service Checks.
> We need to ensure service checks pass in less than 3 mins for all services.
> This means we need to potentially use a different configuration property if 
> one doesn't exist already so that QE can set it during the Ambari devdeploy 
> tests (in order to speed up the tests).
> This will likely result in bugs in either the Ambari python scripts or the 
> actual services, for which we will create Jiras and assign to the appropriate 
> stack team.
> This patch implements cluster_env/strict_service_check_type property. 
> Possible values are minimal (handled inside service check, runs shorter 
> service check action) and full (default action). If value is minimal, I also 
> reduce service check timeout when generating command on server in 2 times. 
> This way we adapt to service check timeouts that may be different for 
> different services. If service check takes 9 minutes of 10-minute timeout to 
> pass on our non-busy cluster, then it will probably take more then 10 minutes 
> on customers real cluster, and that is bad thing (bug)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-15232) Provide details on the JCE policy installed in the JVM used by Ambari

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-15232:
--
Description: 
Provide details on the JCE policy installed in the JVM used by Ambari. This 
data should be retrievable when querying the REST API 

{code:title=GET 
/api/v1/services/AMBARI/components/AMBARI_SERVER?fields=RootServiceComponents/jce_policy}
{
  ...
  "RootServiceComponents" : {
"component_name" : "AMBARI_SERVER",
"service_name" : "AMBARI",
"jce_policy" : {
  "unlimited_key" : true
}
  }
  ...
}
{code}

{code:title=GET 
/api/v1/services/AMBARI/components/AMBARI_SERVER?fields=RootServiceComponents/ciphers}
{
  ...
  "RootServiceComponents" : {
"component_name" : "AMBARI_SERVER",
"service_name" : "AMBARI",
"ciphers" : {
  "sunjce.aes" : 2147483647,
  "sunjce.aeswrap" : 2147483647,
  "sunjce.aeswrap_128" : 2147483647,
  "sunjce.aeswrap_192" : 2147483647,
  "sunjce.aeswrap_256" : 2147483647,
  "sunjce.arcfour" : 2147483647,
  "sunjce.blowfish" : 2147483647,
  ...
}
  }
  ...
}
{code}

  was:
Provide details on the JCE policy installed in the JVM used by Ambari. This 
data should be retrievable when querying the REST API 

{code:title=GET 
/api/v1/services/AMBARI/components/AMBARI_SERVER?fields=RootServiceComponents/jce_policy}
{
  ...
  "RootServiceComponents" : {
"component_name" : "AMBARI_SERVER",
"service_name" : "AMBARI",
"jce_policy" : {
  "unlimited_key" : true
}
  }
  ...
}
{code}

{code:title=GET 
/api/v1/services/AMBARI/components/AMBARI_SERVER?fields=RootServiceComponents/ciphers}
{
  ...
  "RootServiceComponents" : {
"component_name" : "AMBARI_SERVER",
"service_name" : "AMBARI",
"ciphers" : {
  "sunjce.aes" : 2147483647,
  "sunjce.aeswrap" : 2147483647,
  "sunjce.aeswrap_128" : 2147483647,
  "sunjce.aeswrap_192" : 2147483647,
  "sunjce.aeswrap_256" : 2147483647,
  "sunjce.arcfour" : 2147483647,
  "sunjce.blowfish" : 2147483647,
  ...
}
  }
  ...
}
{code}


> Provide details on the JCE policy installed in the JVM used by Ambari
> -
>
> Key: AMBARI-15232
> URL: https://issues.apache.org/jira/browse/AMBARI-15232
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.4.0
>
> Attachments: AMBARI-15232_trunk_01.patch, AMBARI-15232_trunk_02.patch
>
>
> Provide details on the JCE policy installed in the JVM used by Ambari. This 
> data should be retrievable when querying the REST API 
> {code:title=GET 
> /api/v1/services/AMBARI/components/AMBARI_SERVER?fields=RootServiceComponents/jce_policy}
> {
>   ...
>   "RootServiceComponents" : {
> "component_name" : "AMBARI_SERVER",
> "service_name" : "AMBARI",
> "jce_policy" : {
>   "unlimited_key" : true
> }
>   }
>   ...
> }
> {code}
> {code:title=GET 
> /api/v1/services/AMBARI/components/AMBARI_SERVER?fields=RootServiceComponents/ciphers}
> {
>   ...
>   "RootServiceComponents" : {
> "component_name" : "AMBARI_SERVER",
> "service_name" : "AMBARI",
> "ciphers" : {
>   "sunjce.aes" : 2147483647,
>   "sunjce.aeswrap" : 2147483647,
>   "sunjce.aeswrap_128" : 2147483647,
>   "sunjce.aeswrap_192" : 2147483647,
>   "sunjce.aeswrap_256" : 2147483647,
>   "sunjce.arcfour" : 2147483647,
>   "sunjce.blowfish" : 2147483647,
>   ...
> }
>   }
>   ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-15232) Provide details on the JCE policy installed in the JVM used by Ambari

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-15232:
--
Description: 
Provide details on the JCE policy installed in the JVM used by Ambari. This 
data should be retrievable when querying the REST API 

{code:title=GET 
/api/v1/services/AMBARI/components/AMBARI_SERVER?fields=RootServiceComponents/jce_policy}
{
  ...
  "RootServiceComponents" : {
"component_name" : "AMBARI_SERVER",
"service_name" : "AMBARI",
"jce_policy" : {
  "unlimited_key" : true
}
  }
  ...
}
{code}

{code:title=GET 
/api/v1/services/AMBARI/components/AMBARI_SERVER?fields=RootServiceComponents/ciphers}
{
  ...
  "RootServiceComponents" : {
"component_name" : "AMBARI_SERVER",
"service_name" : "AMBARI",
"ciphers" : {
  "sunjce.aes" : 2147483647,
  "sunjce.aeswrap" : 2147483647,
  "sunjce.aeswrap_128" : 2147483647,
  "sunjce.aeswrap_192" : 2147483647,
  "sunjce.aeswrap_256" : 2147483647,
  "sunjce.arcfour" : 2147483647,
  "sunjce.blowfish" : 2147483647,
  ...
}
  }
  ...
}
{code}

  was:
Provide details on the JCE policy installed in the JVM used by Ambari. This 
data should be retrievable when querying the REST API 

{code:title=GET 
/api/v1/services/AMBARI/components/AMBARI_SERVER?fields=RootServiceComponents/jce_policy}
  ...
  "jce_policy" : {
"unlimited_key": "true",
...
  },
  "ciphers" : {
...
  }
  ...
{code}


> Provide details on the JCE policy installed in the JVM used by Ambari
> -
>
> Key: AMBARI-15232
> URL: https://issues.apache.org/jira/browse/AMBARI-15232
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.4.0
>
> Attachments: AMBARI-15232_trunk_01.patch, AMBARI-15232_trunk_02.patch
>
>
> Provide details on the JCE policy installed in the JVM used by Ambari. This 
> data should be retrievable when querying the REST API 
> {code:title=GET 
> /api/v1/services/AMBARI/components/AMBARI_SERVER?fields=RootServiceComponents/jce_policy}
> {
>   ...
>   "RootServiceComponents" : {
> "component_name" : "AMBARI_SERVER",
> "service_name" : "AMBARI",
> "jce_policy" : {
>   "unlimited_key" : true
> }
>   }
>   ...
> }
> {code}
> {code:title=GET 
> /api/v1/services/AMBARI/components/AMBARI_SERVER?fields=RootServiceComponents/ciphers}
> {
>   ...
>   "RootServiceComponents" : {
> "component_name" : "AMBARI_SERVER",
> "service_name" : "AMBARI",
> "ciphers" : {
>   "sunjce.aes" : 2147483647,
>   "sunjce.aeswrap" : 2147483647,
>   "sunjce.aeswrap_128" : 2147483647,
>   "sunjce.aeswrap_192" : 2147483647,
>   "sunjce.aeswrap_256" : 2147483647,
>   "sunjce.arcfour" : 2147483647,
>   "sunjce.blowfish" : 2147483647,
>   ...
> }
>   }
>   ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-15232) Provide details on the JCE policy installed in the JVM used by Ambari

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-15232:
--
Description: 
Provide details on the JCE policy installed in the JVM used by Ambari. This 
data should be retrievable when querying the REST API 

{code:title=GET 
/api/v1/services/AMBARI/components/AMBARI_SERVER?fields=RootServiceComponents/jce_policy}
  ...
  "jce_policy" : {
"unlimited_key": "true",
...
  },
  "ciphers" : {
...
  }
  ...
{code}

  was:
Provide details on the JCE policy installed in the JVM used by Ambari. This 
data should be retrievable when querying the REST API 

{code:title=GET /api/v1/services/AMBARI/components/AMBARI_SERVER}
  ...
  "jce_policy" : {
"unlimited_key": "true",
...
  },
  "ciphers" : {
...
  }
  ...
{code}


> Provide details on the JCE policy installed in the JVM used by Ambari
> -
>
> Key: AMBARI-15232
> URL: https://issues.apache.org/jira/browse/AMBARI-15232
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.4.0
>
> Attachments: AMBARI-15232_trunk_01.patch, AMBARI-15232_trunk_02.patch
>
>
> Provide details on the JCE policy installed in the JVM used by Ambari. This 
> data should be retrievable when querying the REST API 
> {code:title=GET 
> /api/v1/services/AMBARI/components/AMBARI_SERVER?fields=RootServiceComponents/jce_policy}
>   ...
>   "jce_policy" : {
> "unlimited_key": "true",
> ...
>   },
>   "ciphers" : {
> ...
>   }
>   ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20057) "NodeManagers Status" value is empty in Yarn Summary page

[Yesha Vora (JIRA)]

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

Yesha Vora updated AMBARI-20057:

Attachment: Screen Shot 2017-02-16 at 1.36.27 PM.png

> "NodeManagers Status" value is empty in Yarn Summary page
> -
>
> Key: AMBARI-20057
> URL: https://issues.apache.org/jira/browse/AMBARI-20057
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Reporter: Yesha Vora
> Attachments: Screen Shot 2017-02-16 at 1.36.27 PM.png
>
>
> The value of "NodeManagers Status" is empty in Yarn Summary page. It should 
> have printed node manager status such as "3 live/0 dead/0 decommissioned".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20057) "NodeManagers Status" value is empty in Yarn Summary page

[Yesha Vora (JIRA)]

Yesha Vora created AMBARI-20057:
---

 Summary: "NodeManagers Status" value is empty in Yarn Summary page
 Key: AMBARI-20057
 URL: https://issues.apache.org/jira/browse/AMBARI-20057
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Reporter: Yesha Vora


The value of "NodeManagers Status" is empty in Yarn Summary page. It should 
have printed node manager status such as "3 live/0 dead/0 decommissioned".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20017) PixieDust - Decrease Service Check running time under 3 mins

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-20017:

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

Committed
To https://git-wip-us.apache.org/repos/asf/ambari.git
   347ba2a..18fc258  trunk -> trunk


> PixieDust - Decrease Service Check running time under 3 mins
> 
>
> Key: AMBARI-20017
> URL: https://issues.apache.org/jira/browse/AMBARI-20017
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-20017.2.patch, AMBARI-20017.3.patch, 
> AMBARI-20017.patch
>
>
> Right now, Ambari has a timeout of 5-10 mins for Service Checks.
> We need to ensure service checks pass in less than 3 mins for all services.
> This means we need to potentially use a different configuration property if 
> one doesn't exist already so that QE can set it during the Ambari devdeploy 
> tests (in order to speed up the tests).
> This will likely result in bugs in either the Ambari python scripts or the 
> actual services, for which we will create Jiras and assign to the appropriate 
> stack team.
> This patch implements cluster_env/strict_service_check_type property. 
> Possible values are minimal (handled inside service check, runs shorter 
> service check action) and full (default action). If value is minimal, I also 
> reduce service check timeout when generating command on server in 2 times. 
> This way we adapt to service check timeouts that may be different for 
> different services. If service check takes 9 minutes of 10-minute timeout to 
> pass on our non-busy cluster, then it will probably take more then 10 minutes 
> on customers real cluster, and that is bad thing (bug)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20056) FIFO compaction resulting in too many store files on large cluster

[Aravindan Vijayan (JIRA)]

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

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

> FIFO compaction resulting in too many store files on large cluster
> --
>
> Key: AMBARI-20056
> URL: https://issues.apache.org/jira/browse/AMBARI-20056
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20056.patch
>
>
> Set Data Tiered compaction for all tables except METRIC_RECORD
> This will allow number of store files to go down over time.  On a 500 node 
> cluster AMS can become in-operational after creating 18K store files and no 
> compaction.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20054) Remove Entities Associated With clusterconfigmapping

[Jonathan Hurley (JIRA)]

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

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

> Remove Entities Associated With clusterconfigmapping
> 
>
> Key: AMBARI-20054
> URL: https://issues.apache.org/jira/browse/AMBARI-20054
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-20054.patch
>
>
> - Remove the {{clusterconfigmapping}} table, which has redundant columns and 
> causes nothing but headaches when it becomes out of sync with 
> {{clusterconfig}}
> - Change {{clusterconfig}} to track which configuration is selected and when 
> the last time it was selected was



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20054) Remove Entities Associated With clusterconfigmapping

[Jonathan Hurley (JIRA)]

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

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

> Remove Entities Associated With clusterconfigmapping
> 
>
> Key: AMBARI-20054
> URL: https://issues.apache.org/jira/browse/AMBARI-20054
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-20054.patch
>
>
> - Remove the {{clusterconfigmapping}} table, which has redundant columns and 
> causes nothing but headaches when it becomes out of sync with 
> {{clusterconfig}}
> - Change {{clusterconfig}} to track which configuration is selected and when 
> the last time it was selected was



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20056) FIFO compaction resulting in too many store files on large cluster

[Aravindan Vijayan (JIRA)]

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

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

> FIFO compaction resulting in too many store files on large cluster
> --
>
> Key: AMBARI-20056
> URL: https://issues.apache.org/jira/browse/AMBARI-20056
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20056.patch
>
>
> Set Data Tiered compaction for all tables except METRIC_RECORD
> This will allow number of store files to go down over time.  On a 500 node 
> cluster AMS can become in-operational after creating 18K store files and no 
> compaction.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20017) PixieDust - Decrease Service Check running time under 3 mins

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-20017:

Attachment: AMBARI-20017.3.patch

> PixieDust - Decrease Service Check running time under 3 mins
> 
>
> Key: AMBARI-20017
> URL: https://issues.apache.org/jira/browse/AMBARI-20017
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-20017.2.patch, AMBARI-20017.3.patch, 
> AMBARI-20017.patch
>
>
> Right now, Ambari has a timeout of 5-10 mins for Service Checks.
> We need to ensure service checks pass in less than 3 mins for all services.
> This means we need to potentially use a different configuration property if 
> one doesn't exist already so that QE can set it during the Ambari devdeploy 
> tests (in order to speed up the tests).
> This will likely result in bugs in either the Ambari python scripts or the 
> actual services, for which we will create Jiras and assign to the appropriate 
> stack team.
> This patch implements cluster_env/strict_service_check_type property. 
> Possible values are minimal (handled inside service check, runs shorter 
> service check action) and full (default action). If value is minimal, I also 
> reduce service check timeout when generating command on server in 2 times. 
> This way we adapt to service check timeouts that may be different for 
> different services. If service check takes 9 minutes of 10-minute timeout to 
> pass on our non-busy cluster, then it will probably take more then 10 minutes 
> on customers real cluster, and that is bad thing (bug)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20056) FIFO compaction resulting in too many store files on large cluster

[Aravindan Vijayan (JIRA)]

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

Aravindan Vijayan updated AMBARI-20056:
---
Description: 
Set Data Tiered compaction for all tables except METRIC_RECORD
This will allow number of store files to go down over time.  On a 500 node 
cluster AMS can become in-operational after creating 18K store files and no 
compaction.

  was:
Set Data Tiered compaction for all tables except METRIC_RECORD
This will allow number of store files to go down over time. Linked an EAR where 
500 node cluster AMS became in-operational after creating 18K store files and 
no compaction.


> FIFO compaction resulting in too many store files on large cluster
> --
>
> Key: AMBARI-20056
> URL: https://issues.apache.org/jira/browse/AMBARI-20056
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.5.0
>
>
> Set Data Tiered compaction for all tables except METRIC_RECORD
> This will allow number of store files to go down over time.  On a 500 node 
> cluster AMS can become in-operational after creating 18K store files and no 
> compaction.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20056) FIFO compaction resulting in too many store files on large cluster

[Aravindan Vijayan (JIRA)]

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

Aravindan Vijayan commented on AMBARI-20056:


Refined the part of the code where AMS HBase tables policies are set such that 
any compaction policy can be set for precision and aggregate tables. 

Defaults

Precision Table (METRIC_RECORD)
hbase.hstore.defaultengine.compactionpolicy.class : 
org.apache.hadoop.hbase.regionserver.compactions.FIFOCompactionPolicy

Aggregate Tables
hbase.hstore.engine.class : 
org.apache.hadoop.hbase.regionserver.DateTieredStoreEngine





> FIFO compaction resulting in too many store files on large cluster
> --
>
> Key: AMBARI-20056
> URL: https://issues.apache.org/jira/browse/AMBARI-20056
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.5.0
>
>
> Set Data Tiered compaction for all tables except METRIC_RECORD
> This will allow number of store files to go down over time. Linked an EAR 
> where 500 node cluster AMS became in-operational after creating 18K store 
> files and no compaction.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20056) FIFO compaction resulting in too many store files on large cluster

[Aravindan Vijayan (JIRA)]

Aravindan Vijayan created AMBARI-20056:
--

 Summary: FIFO compaction resulting in too many store files on 
large cluster
 Key: AMBARI-20056
 URL: https://issues.apache.org/jira/browse/AMBARI-20056
 Project: Ambari
  Issue Type: Bug
  Components: ambari-metrics
Affects Versions: 2.5.0
Reporter: Aravindan Vijayan
Assignee: Aravindan Vijayan
Priority: Critical
 Fix For: 2.5.0


Set Data Tiered compaction for all tables except METRIC_RECORD
This will allow number of store files to go down over time. Linked an EAR where 
500 node cluster AMS became in-operational after creating 18K store files and 
no compaction.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20054) Remove Entities Associated With clusterconfigmapping

[Jonathan Hurley (JIRA)]

Jonathan Hurley created AMBARI-20054:


 Summary: Remove Entities Associated With clusterconfigmapping
 Key: AMBARI-20054
 URL: https://issues.apache.org/jira/browse/AMBARI-20054
 Project: Ambari
  Issue Type: Task
  Components: ambari-server
Affects Versions: trunk
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
Priority: Critical
 Fix For: trunk


- Remove the {{clusterconfigmapping}} table, which has redundant columns and 
causes nothing but headaches when it becomes out of sync with {{clusterconfig}}

- Change {{clusterconfig}} to track which configuration is selected and when 
the last time it was selected was



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20053) Remove the clusterconfigmapping Table

[Jonathan Hurley (JIRA)]

Jonathan Hurley created AMBARI-20053:


 Summary: Remove the clusterconfigmapping Table
 Key: AMBARI-20053
 URL: https://issues.apache.org/jira/browse/AMBARI-20053
 Project: Ambari
  Issue Type: Epic
  Components: ambari-server
Affects Versions: trunk
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
Priority: Critical
 Fix For: trunk


The {{clusterconfigmapping}} table seems to serve no purpose any longer now 
that we track service versions via the {{serviceconfig}} table. 

Take the following workflow:
- Create a new cluster; {{foo-site}} is created in {{clusterconfig}} at version 
1 with tag {{INITIAL}}.
- Modify {{foo-site}}, creating a version 2. New entries are also created in 
both {{clusterconfig}} and {{clusterconfigmapping}}. The {{serviceconfig}} 
table updated to show v2.
- Revert back to v1 for the FOO service:
-- A new entry *is not* created in {{clusterconfig}} - in fact this table isn't 
touched.
-- A new entry *is* created in {{clusterconfigmapping}} which points to the 
original tag in {{clusterconfig}}
-- The {{serviceconfig}} table is updated to reflect v3, including the mappings 
back to the configs in {{clusterconfig}}.

In fact, it seems as though _nothing_ references {{clusterconfigmapping}}. 
There are two columns of interest in this table:
- {{selected}} - simply marks which config is active.
- {{user}} - the user who performed the action.

{{selected}} can be moved to {{clusterconfig}}, in addition to a new field to 
indicate the last time that a config was selected (for reversion of 
configurations). {{user}} is not used and the {{user}} column from the 
{{serviceconfig}} table can be used instead.

The proposal is to remove {{clusterconfigmapping}} entirely. When retrieving 
data from {{clusterconfig}}, the heavy columns which contain config data are 
lazily loaded from JPA, so there's no penalty for using this table as the 
source of truth for currently selected desired configs.

To Summarize:
- Remove the {{clusterconfigmapping}} table, which has redundant columns and 
causes nothing but headaches when it becomes out of sync with {{clusterconfig}}
- Change {{clusterconfig}} to track which configuration is selected and when 
the last time it was selected was
- Provide database upgrade scripts to convert existing databases

Some Thoughts:
- Configuration groups are problematic since they create configurations which 
are never "selected". They lack an entry in the {{clusterconfigmapping}} table. 
 These new configurations can also can problems when applying the "latest" 
configurations from a stack since they would appear newer than other 
configurations. For this reason, we'll keep track of if/when a configuration 
was selected.
- The heavy fields on {{ClusterConfigEntity}} must remain lazily loaded. More 
documentation should be added to cover this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20013) Add Solr authorization settings during LogSearch/Atlas/Ranger startup

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20013:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1019 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1019/])
AMBARI-20013. Add Solr authorization settings during (oleewere: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=be18ae1bc541474829f7a693b7249a41f2fb0fa5])
* (edit) ambari-server/src/test/python/stacks/2.3/ATLAS/test_metadata_server.py
* (edit) ambari-server/src/test/python/stacks/2.3/configs/secure.json
* (edit) 
ambari-server/src/test/python/stacks/2.4/AMBARI_INFRA/test_infra_solr.py
* (edit) ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logsearch.py
* (edit) 
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/package/scripts/setup_infra_solr.py
* (edit) ambari-server/src/test/python/stacks/2.6/RANGER/test_ranger_admin.py
* (edit) 
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/configuration/infra-solr-security-json.xml
* (edit) 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/params.py
* (edit) ambari-server/src/test/python/stacks/2.5/RANGER/test_ranger_admin.py
* (add) 
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/package/templates/infra-solr-security.json.j2
* (edit) 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata.py
* (edit) 
ambari-server/src/main/resources/common-services/ATLAS/0.7.0.2.5/kerberos.json
* (edit) 
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/package/scripts/params.py
* (edit) 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py
* (delete) 
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/properties/infra-solr-security.json.j2
* (edit) 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/params.py
* (edit) 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/setup_ranger_xml.py
* (edit) 
ambari-server/src/main/resources/common-services/RANGER/0.6.0/kerberos.json
* (edit) 
ambari-common/src/main/python/resource_management/libraries/functions/solr_cloud_util.py
* (edit) 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logsearch.py
* (edit) 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/kerberos.json


> Add Solr authorization settings during LogSearch/Atlas/Ranger startup
> -
>
> Key: AMBARI-20013
> URL: https://issues.apache.org/jira/browse/AMBARI-20013
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 2.5.0
>
> Attachments: AMBARI-20013.patch
>
>
> During ranger/logsearch/atlas startup, we need to make sure these services 
> have permission to access for specific collections.
> Also ranger plugins should be able to write into ranger collection as well.
> There will be a new solr_cloud_util function to add user-roles to solr, which 
> will update security.json on the zookeeper znode.
> For newly added services with ranger plugins, solr will need to be restarted 
> to generate the correct security.json on zookeeper.
> Also this task will introduce a new custom security.json which can override 
> that is used by default.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20013) Add Solr authorization settings during LogSearch/Atlas/Ranger startup

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20013:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6768 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6768/])
AMBARI-20013. Add Solr authorization settings during (oleewere: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=347ba2a9983d400cddf4d888e7f8c15d72b71d5a])
* (edit) 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/params.py
* (edit) 
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/configuration/infra-solr-security-json.xml
* (edit) 
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/package/scripts/setup_infra_solr.py
* (edit) 
ambari-server/src/main/resources/common-services/ATLAS/0.7.0.2.5/kerberos.json
* (edit) ambari-server/src/test/python/stacks/2.3/ATLAS/test_metadata_server.py
* (edit) 
ambari-server/src/test/python/stacks/2.4/AMBARI_INFRA/test_infra_solr.py
* (add) 
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/package/templates/infra-solr-security.json.j2
* (edit) 
ambari-common/src/main/python/resource_management/libraries/functions/solr_cloud_util.py
* (delete) 
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/properties/infra-solr-security.json.j2
* (edit) 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/kerberos.json
* (edit) 
ambari-server/src/main/resources/common-services/RANGER/0.6.0/kerberos.json
* (edit) ambari-server/src/test/python/stacks/2.3/configs/secure.json
* (edit) 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py
* (edit) 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logsearch.py
* (edit) ambari-server/src/test/python/stacks/2.5/RANGER/test_ranger_admin.py
* (edit) 
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/package/scripts/params.py
* (edit) ambari-server/src/test/python/stacks/2.6/RANGER/test_ranger_admin.py
* (edit) 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata.py
* (edit) 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/setup_ranger_xml.py
* (edit) ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logsearch.py
* (edit) 
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/params.py


> Add Solr authorization settings during LogSearch/Atlas/Ranger startup
> -
>
> Key: AMBARI-20013
> URL: https://issues.apache.org/jira/browse/AMBARI-20013
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 2.5.0
>
> Attachments: AMBARI-20013.patch
>
>
> During ranger/logsearch/atlas startup, we need to make sure these services 
> have permission to access for specific collections.
> Also ranger plugins should be able to write into ranger collection as well.
> There will be a new solr_cloud_util function to add user-roles to solr, which 
> will update security.json on the zookeeper znode.
> For newly added services with ranger plugins, solr will need to be restarted 
> to generate the correct security.json on zookeeper.
> Also this task will introduce a new custom security.json which can override 
> that is used by default.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-18868) Stage and Request status should be persisted in the database

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18868:


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

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

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

{color:red}-1 javac{color:red}.  The patch appears to cause the build to 
fail.

Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/10625//console

This message is automatically generated.

> Stage and Request status should be persisted in the database
> 
>
> Key: AMBARI-18868
> URL: https://issues.apache.org/jira/browse/AMBARI-18868
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Jaimin Jetly
>Assignee: Jaimin Jetly
> Fix For: 3.0.0
>
> Attachments: AMBARI-18868.2.patch, AMBARI-18868.3.patch, 
> AMBARI-18868.4.patch, AMBARI-18868.5.patch, AMBARI-18868.6.patch, 
> AMBARI-18868.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20044) NullPointerException after server restart in case not all hosts were joined

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20044:


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

This message is automatically generated.

> NullPointerException after server restart in case not all hosts were joined
> ---
>
> Key: AMBARI-20044
> URL: https://issues.apache.org/jira/browse/AMBARI-20044
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
> Fix For: 2.5.0
>
> Attachments: AMBARI-20044.patch
>
>
> NullPointerException after server restart in case not all hosts mentioned in 
> Cluster template were joined the cluster.
> The issue happens when TopologyManager tries to reconstruct requests for 
> hosts.
> {code}
> java.lang.NullPointerException
>   at java.lang.String.replace(String.java:2180)
>   at 
> org.apache.ambari.server.topology.HostRequest.getLogicalTasks(HostRequest.java:317)
>   at 
> org.apache.ambari.server.topology.LogicalRequest.getCommands(LogicalRequest.java:157)
>   at 
> org.apache.ambari.server.topology.LogicalRequest.getRequestStatus(LogicalRequest.java:230)
>   at 
> org.apache.ambari.server.topology.TopologyManager.isLogicalRequestFinished(TopologyManager.java:903)
>   at 
> org.apache.ambari.server.topology.TopologyManager.replayRequests(TopologyManager.java:857)
>   at 
> org.apache.ambari.server.topology.TopologyManager.ensureInitialized(TopologyManager.java:176)
>   at 
> org.apache.ambari.server.topology.TopologyManager.onHostRegistered(TopologyManager.java:477)
>   at 
> org.apache.ambari.server.state.host.HostImpl$HostRegistrationReceived.transition(HostImpl.java:34
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (AMBARI-20013) Add Solr authorization settings during LogSearch/Atlas/Ranger startup

[JIRA]

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

Olivér Szabó resolved AMBARI-20013.
---
Resolution: Fixed

committed to branch-2.5:
{code:java}
commit be18ae1bc541474829f7a693b7249a41f2fb0fa5
Author: oleewere 
Date:   Mon Feb 13 18:34:50 2017 +0100

AMBARI-20013. Add Solr authorization settings during LogSearch/Atlas/Ranger 
startup (oleewere)
{code}

committed to trunk:
{code:java}
commit 347ba2a9983d400cddf4d888e7f8c15d72b71d5a
Author: oleewere 
Date:   Mon Feb 13 18:34:50 2017 +0100

AMBARI-20013. Add Solr authorization settings during LogSearch/Atlas/Ranger 
startup (oleewere)
{code}

> Add Solr authorization settings during LogSearch/Atlas/Ranger startup
> -
>
> Key: AMBARI-20013
> URL: https://issues.apache.org/jira/browse/AMBARI-20013
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 2.5.0
>
> Attachments: AMBARI-20013.patch
>
>
> During ranger/logsearch/atlas startup, we need to make sure these services 
> have permission to access for specific collections.
> Also ranger plugins should be able to write into ranger collection as well.
> There will be a new solr_cloud_util function to add user-roles to solr, which 
> will update security.json on the zookeeper znode.
> For newly added services with ranger plugins, solr will need to be restarted 
> to generate the correct security.json on zookeeper.
> Also this task will introduce a new custom security.json which can override 
> that is used by default.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20013) Add Solr authorization settings during LogSearch/Atlas/Ranger startup

[JIRA]

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

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

> Add Solr authorization settings during LogSearch/Atlas/Ranger startup
> -
>
> Key: AMBARI-20013
> URL: https://issues.apache.org/jira/browse/AMBARI-20013
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 2.5.0
>
> Attachments: AMBARI-20013.patch
>
>
> During ranger/logsearch/atlas startup, we need to make sure these services 
> have permission to access for specific collections.
> Also ranger plugins should be able to write into ranger collection as well.
> There will be a new solr_cloud_util function to add user-roles to solr, which 
> will update security.json on the zookeeper znode.
> For newly added services with ranger plugins, solr will need to be restarted 
> to generate the correct security.json on zookeeper.
> Also this task will introduce a new custom security.json which can override 
> that is used by default.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20013) Add Solr authorization settings during LogSearch/Atlas/Ranger startup

[JIRA]

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

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

> Add Solr authorization settings during LogSearch/Atlas/Ranger startup
> -
>
> Key: AMBARI-20013
> URL: https://issues.apache.org/jira/browse/AMBARI-20013
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 2.5.0
>
> Attachments: AMBARI-20013.patch
>
>
> During ranger/logsearch/atlas startup, we need to make sure these services 
> have permission to access for specific collections.
> Also ranger plugins should be able to write into ranger collection as well.
> There will be a new solr_cloud_util function to add user-roles to solr, which 
> will update security.json on the zookeeper znode.
> For newly added services with ranger plugins, solr will need to be restarted 
> to generate the correct security.json on zookeeper.
> Also this task will introduce a new custom security.json which can override 
> that is used by default.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20008) Add "Manage alert notifications" authorization

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20008:
-

SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #1018 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1018/])
AMBARI-20008. Add "Manage alert notifications" authorization (Eugene (rlevas: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=85602eb6286f01c419504ae41629a3bfaa51962f])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/AlertTargetResourceProvider.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/security/authorization/RoleAuthorization.java
* (edit) ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog250Test.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog250.java
* (edit) ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql
* (edit) ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql
* (edit) ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql
* (edit) ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql
* (edit) ambari-server/src/main/resources/Ambari-DDL-Derby-CREATE.sql


> Add  "Manage alert notifications" authorization
> ---
>
> Key: AMBARI-20008
> URL: https://issues.apache.org/jira/browse/AMBARI-20008
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Eugene Chekanskiy
>Assignee: Eugene Chekanskiy
> Fix For: 2.5.0
>
> Attachments: AMBARI-20008.2.5-2.patch, AMBARI-20008.2.5.patch, 
> AMBARI-20008.trunk-2.patch, AMBARI-20008.trunk.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20008) Add "Manage alert notifications" authorization

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20008:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6767 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6767/])
AMBARI-20008. Add "Manage alert notifications" authorization (Eugene (rlevas: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=bfaaba2fa2ce0c271c5fa3de3c4b1134715407df])
* (edit) ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql
* (edit) ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog250.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/security/authorization/RoleAuthorization.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/AlertTargetResourceProvider.java
* (edit) ambari-server/src/main/resources/Ambari-DDL-Derby-CREATE.sql
* (edit) ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql
* (edit) ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql
* (edit) ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog250Test.java


> Add  "Manage alert notifications" authorization
> ---
>
> Key: AMBARI-20008
> URL: https://issues.apache.org/jira/browse/AMBARI-20008
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Eugene Chekanskiy
>Assignee: Eugene Chekanskiy
> Fix For: 2.5.0
>
> Attachments: AMBARI-20008.2.5-2.patch, AMBARI-20008.2.5.patch, 
> AMBARI-20008.trunk-2.patch, AMBARI-20008.trunk.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20052) Spark2 service check is failing in secure cluster

[Yesha Vora (JIRA)]

Yesha Vora created AMBARI-20052:
---

 Summary: Spark2 service check is failing in secure cluster
 Key: AMBARI-20052
 URL: https://issues.apache.org/jira/browse/AMBARI-20052
 Project: Ambari
  Issue Type: Bug
Reporter: Yesha Vora


Spark2 Service check is failing in secure cluster.

{code:title=errors-411.txt}
Traceback (most recent call last):
  File 
"/var/lib/ambari-agent/cache/common-services/SPARK2/2.0.0/package/scripts/service_check.py",
 line 62, in 
SparkServiceCheck().execute()
  File 
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
 line 313, in execute
method(env)
  File 
"/var/lib/ambari-agent/cache/common-services/SPARK2/2.0.0/package/scripts/service_check.py",
 line 36, in service_check
livy_kinit_cmd = format("{kinit_path_local} -kt {smoke_user_keytab} 
{smokeuser_principal}; ")
  File 
"/usr/lib/python2.6/site-packages/resource_management/libraries/functions/format.py",
 line 95, in format
return ConfigurationFormatter().format(format_string, args, **result)
  File 
"/usr/lib/python2.6/site-packages/resource_management/libraries/functions/format.py",
 line 59, in format
result_protected = self.vformat(format_string, args, all_params)
  File "/usr/lib64/python2.7/string.py", line 549, in vformat
result = self._vformat(format_string, args, kwargs, used_args, 2)
  File "/usr/lib64/python2.7/string.py", line 571, in _vformat
obj, arg_used = self.get_field(field_name, args, kwargs)
  File "/usr/lib64/python2.7/string.py", line 632, in get_field
obj = self.get_value(first, args, kwargs)
  File "/usr/lib64/python2.7/string.py", line 591, in get_value
return kwargs[key]
  File "/usr/lib/python2.6/site-packages/resource_management/core/utils.py", 
line 57, in __getitem__
return self._convert_value(self._dict[name])
KeyError: 'smoke_user_keytab'{code}

{code:title=output-411.txt}
2017-02-16 18:52:44,887 - Using hadoop conf dir: 
/usr/hdp/current/hadoop-client/conf
2017-02-16 18:52:44,904 - Execute['/usr/bin/kinit -kt 
/etc/security/keytabs/spark2.headless.keytab sp...@example.com; '] {'user': 
'spark'}

Command failed after 1 tries{code}

As per above logs, kinit operation failed on a host. I was able to run same 
kinit command successfully from same host manually.
{code}
[root@xxx ~]$ sudo su spark
bash-4.2$ /usr/bin/kinit -kt /etc/security/keytabs/spark2.headless.keytab 
sp...@example.com
bash-4.2$ echo $?
0
{code}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20047) Repository config user needs to set customized service user in Ranger when service plugin is enabled

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20047:


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

This message is automatically generated.

> Repository config user needs to set customized service user in Ranger when 
> service plugin is enabled
> 
>
> Key: AMBARI-20047
> URL: https://issues.apache.org/jira/browse/AMBARI-20047
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vishal Suvagia
>Assignee: Vishal Suvagia
> Fix For: 2.5.0
>
> Attachments: AMBARI-20047.patch
>
>
> The property {{REPOSITORY_CONFIG_USERNAME}} in Advanced 
> ranger-*-plugin-properties is not updated to the custom user-name when 
> services are using custom users.
> This causes issues especially in cases of Test connection, and policy user 
> which is given default permissions in Ranger.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20045) More than one version of jetty jars found in Ambari rpm

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20045:
-

SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #6766 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6766/])
AMBARI-20045 More than one version of jetty jars found in Ambari rpm (dsen: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=1f1bfb8e7b847300f2ec8b10fc9e2269f042f18b])
* (edit) ambari-server/pom.xml


> More than one version of jetty jars found in Ambari rpm
> ---
>
> Key: AMBARI-20045
> URL: https://issues.apache.org/jira/browse/AMBARI-20045
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20045.patch
>
>
> Got a warning on restart of my cluster:
> {code}
> Ambari Server running with administrator privileges.
> Organizing resource files at /var/lib/ambari-server/resources...
> WARNING: Multiple versions of jetty-util.jar found in java class path 
> (/usr/lib/ambari-server/jetty-util-6.1.26.jar and 
> /usr/lib/ambari-server/jetty-util-8.1.19.v20160209.jar).
>  Make sure that you include only one jetty-util.jar in the java class path 
> '/etc/ambari-server/conf:/usr/lib/ambari-server/*:/usr/share/java/mysql-connector-java.jar'.
> Ambari database consistency check started...
> {code}
> Noticed there are older jetty jars packaged with the rpm:
> {code}
> [root@perf-a-1 ~]# rpm -ql ambari-server-2.5.0.0-914.x86_64 | grep jetty
> /usr/lib/ambari-server/jetty-6.1.26.jar
> /usr/lib/ambari-server/jetty-util-6.1.26.jar
> /usr/lib/ambari-server/jetty-util-8.1.19.v20160209.jar
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20045) More than one version of jetty jars found in Ambari rpm

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20045:
-

SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #1017 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1017/])
AMBARI-20045 More than one version of jetty jars found in Ambari rpm (dsen: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=bb870a91228a7a146dd49162aea23dd25b7731db])
* (edit) ambari-server/pom.xml


> More than one version of jetty jars found in Ambari rpm
> ---
>
> Key: AMBARI-20045
> URL: https://issues.apache.org/jira/browse/AMBARI-20045
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20045.patch
>
>
> Got a warning on restart of my cluster:
> {code}
> Ambari Server running with administrator privileges.
> Organizing resource files at /var/lib/ambari-server/resources...
> WARNING: Multiple versions of jetty-util.jar found in java class path 
> (/usr/lib/ambari-server/jetty-util-6.1.26.jar and 
> /usr/lib/ambari-server/jetty-util-8.1.19.v20160209.jar).
>  Make sure that you include only one jetty-util.jar in the java class path 
> '/etc/ambari-server/conf:/usr/lib/ambari-server/*:/usr/share/java/mysql-connector-java.jar'.
> Ambari database consistency check started...
> {code}
> Noticed there are older jetty jars packaged with the rpm:
> {code}
> [root@perf-a-1 ~]# rpm -ql ambari-server-2.5.0.0-914.x86_64 | grep jetty
> /usr/lib/ambari-server/jetty-6.1.26.jar
> /usr/lib/ambari-server/jetty-util-6.1.26.jar
> /usr/lib/ambari-server/jetty-util-8.1.19.v20160209.jar
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20051) Hosts filter component list is not sorted so it is difficult to use

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20051:


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

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

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

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

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

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

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

This message is automatically generated.

> Hosts filter component list is not sorted so it is difficult to use
> ---
>
> Key: AMBARI-20051
> URL: https://issues.apache.org/jira/browse/AMBARI-20051
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Aleksandr Kovalenko
>Assignee: Aleksandr Kovalenko
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20051_branch-2.5.patch, AMBARI-20051.patch, 
> Screen Shot 2017-02-15 at 6.32.34 PM.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-18868) Stage and Request status should be persisted in the database

[Jaimin Jetly (JIRA)]

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

Jaimin Jetly updated AMBARI-18868:
--
Attachment: AMBARI-18868.6.patch

> Stage and Request status should be persisted in the database
> 
>
> Key: AMBARI-18868
> URL: https://issues.apache.org/jira/browse/AMBARI-18868
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Jaimin Jetly
>Assignee: Jaimin Jetly
> Fix For: 3.0.0
>
> Attachments: AMBARI-18868.2.patch, AMBARI-18868.3.patch, 
> AMBARI-18868.4.patch, AMBARI-18868.5.patch, AMBARI-18868.6.patch, 
> AMBARI-18868.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20048) Hive View 2.0: Visual Explain-The operators are being shown out of order.

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20048:


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

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

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

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

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

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

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

This message is automatically generated.

> Hive View 2.0: Visual Explain-The operators are being shown out of order.
> -
>
> Key: AMBARI-20048
> URL: https://issues.apache.org/jira/browse/AMBARI-20048
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: Abhishek Kumar
>Assignee: Abhishek Kumar
> Fix For: 2.5.0
>
> Attachments: AMBARI-20048_trunk.patch
>
>
> The operators are being shown out of order. It’s hard to think about what to 
> do with the plan output when the operators are out of order, so this needs to 
> be fixed first.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20049) One way SSL fallback logic can cause some agents to be connected with 2-way SSL

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20049:
-

SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #6765 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6765/])
AMBARI-20049. One way SSL fallback logic can cause some agents to be (aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=4eaec8eab5175303d8ba39439ac60f3deec25f19])
* (edit) ambari-agent/src/main/python/ambari_agent/security.py
* (edit) ambari-agent/src/test/python/ambari_agent/TestSecurity.py


> One way SSL fallback logic can cause some agents to be connected with 2-way 
> SSL
> ---
>
> Key: AMBARI-20049
> URL: https://issues.apache.org/jira/browse/AMBARI-20049
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-20049.patch
>
>
> We have fallback logic since a long time in the agent to try to connect to the
> server with 2-way SSL if one-way SSL throws an exception. This can cause some
> agents to connect with 2-way SSL (connection timeout exception for one-way
> SSL) and thereby a cluster having a mix of agents, some connected with one-way
> SSL and some connected with 2-way SSL.
> Investigate why we have had this logic and if it is no longer appropriate,
> remove this fallback logic.
>  agent/src/main/python/ambari_agent/security.py#L57-L67>
> 
> 
> 
> if not self.two_way_ssl_required:
>   try:
> sock = self.create_connection()
> self.sock = ssl.wrap_socket(sock, cert_reqs=ssl.CERT_NONE)
> logger.info('SSL connection established. Two-way SSL 
> authentication is '
> 'turned off on the server.')
>   except (ssl.SSLError, AttributeError):
> self.two_way_ssl_required = True
> logger.info(
>   'Insecure connection to https://' + self.host + ':' + self.port 
> +
>   '/ failed. Reconnecting using two-way SSL authentication..')
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20049) One way SSL fallback logic can cause some agents to be connected with 2-way SSL

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20049:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1016 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1016/])
AMBARI-20049. One way SSL fallback logic can cause some agents to be (aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=4379aea0b947bca6e9a0de0927335139892aaec9])
* (edit) ambari-agent/src/main/python/ambari_agent/security.py
* (edit) ambari-agent/src/test/python/ambari_agent/TestSecurity.py


> One way SSL fallback logic can cause some agents to be connected with 2-way 
> SSL
> ---
>
> Key: AMBARI-20049
> URL: https://issues.apache.org/jira/browse/AMBARI-20049
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-20049.patch
>
>
> We have fallback logic since a long time in the agent to try to connect to the
> server with 2-way SSL if one-way SSL throws an exception. This can cause some
> agents to connect with 2-way SSL (connection timeout exception for one-way
> SSL) and thereby a cluster having a mix of agents, some connected with one-way
> SSL and some connected with 2-way SSL.
> Investigate why we have had this logic and if it is no longer appropriate,
> remove this fallback logic.
>  agent/src/main/python/ambari_agent/security.py#L57-L67>
> 
> 
> 
> if not self.two_way_ssl_required:
>   try:
> sock = self.create_connection()
> self.sock = ssl.wrap_socket(sock, cert_reqs=ssl.CERT_NONE)
> logger.info('SSL connection established. Two-way SSL 
> authentication is '
> 'turned off on the server.')
>   except (ssl.SSLError, AttributeError):
> self.two_way_ssl_required = True
> logger.info(
>   'Insecure connection to https://' + self.host + ':' + self.port 
> +
>   '/ failed. Reconnecting using two-way SSL authentication..')
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20043) Don't rerender all widgets when on of them is changed

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20043:


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

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

This message is automatically generated.

> Don't rerender all widgets when on of them is changed
> -
>
> Key: AMBARI-20043
> URL: https://issues.apache.org/jira/browse/AMBARI-20043
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 3.0.0
>
> Attachments: AMBARI-20043.patch
>
>
> Dashboard widgets are rerendered if some of them is changed. Actually only 
> this one should be updated and not other



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20051) Hosts filter component list is not sorted so it is difficult to use

[Aleksandr Kovalenko (JIRA)]

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

Aleksandr Kovalenko updated AMBARI-20051:
-
Attachment: AMBARI-20051.patch

> Hosts filter component list is not sorted so it is difficult to use
> ---
>
> Key: AMBARI-20051
> URL: https://issues.apache.org/jira/browse/AMBARI-20051
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Aleksandr Kovalenko
>Assignee: Aleksandr Kovalenko
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20051_branch-2.5.patch, AMBARI-20051.patch, 
> Screen Shot 2017-02-15 at 6.32.34 PM.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20051) Hosts filter component list is not sorted so it is difficult to use

[Aleksandr Kovalenko (JIRA)]

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

Aleksandr Kovalenko updated AMBARI-20051:
-
Attachment: AMBARI-20051_branch-2.5.patch

> Hosts filter component list is not sorted so it is difficult to use
> ---
>
> Key: AMBARI-20051
> URL: https://issues.apache.org/jira/browse/AMBARI-20051
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Aleksandr Kovalenko
>Assignee: Aleksandr Kovalenko
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20051_branch-2.5.patch, AMBARI-20051.patch, 
> Screen Shot 2017-02-15 at 6.32.34 PM.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20051) Hosts filter component list is not sorted so it is difficult to use

[Aleksandr Kovalenko (JIRA)]

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

Aleksandr Kovalenko updated AMBARI-20051:
-
Status: Patch Available  (was: Open)

> Hosts filter component list is not sorted so it is difficult to use
> ---
>
> Key: AMBARI-20051
> URL: https://issues.apache.org/jira/browse/AMBARI-20051
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Aleksandr Kovalenko
>Assignee: Aleksandr Kovalenko
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20051_branch-2.5.patch, AMBARI-20051.patch, 
> Screen Shot 2017-02-15 at 6.32.34 PM.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20051) Hosts filter component list is not sorted so it is difficult to use

[Aleksandr Kovalenko (JIRA)]

Aleksandr Kovalenko created AMBARI-20051:


 Summary: Hosts filter component list is not sorted so it is 
difficult to use
 Key: AMBARI-20051
 URL: https://issues.apache.org/jira/browse/AMBARI-20051
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.5.0
Reporter: Aleksandr Kovalenko
Assignee: Aleksandr Kovalenko
Priority: Critical
 Fix For: 2.5.0






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20035) Duration in BGoperation window should display durations in proper time units

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20035:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6764 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6764/])
AMBARI-20035. Duration in BGoperation window should display durations in 
(hiveww: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=ab53946fa63ad209158300ca0907e5a67097e717])
* (edit) ambari-web/test/views/main/dashboard/widgets/uptime_text_widget_test.js
* (edit) ambari-web/test/mappers/service_mapper_test.js
* (edit) ambari-web/test/utils/date/date_test.js
* (edit) 
ambari-web/test/views/main/dashboard/widgets/hbase_master_uptime_test.js
* (edit) ambari-web/test/views/main/dashboard/widgets/namenode_uptime_test.js
* (edit) ambari-web/app/views/main/dashboard/widgets/uptime_text_widget.js
* (edit) 
ambari-web/test/views/main/admin/stack_upgrade/upgrade_history_view_test.js
* (edit) ambari-web/app/utils/date/date.js
* (edit) 
ambari-web/test/views/main/dashboard/widgets/resource_manager_uptime_test.js


> Duration in BGoperation window should display durations in proper time units
> 
>
> Key: AMBARI-20035
> URL: https://issues.apache.org/jira/browse/AMBARI-20035
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 3.0.0
>
> Attachments: AMBARI-20035.patch, Screen Shot 2017-01-30 at 5.08.27 
> PM.png
>
>
> Duration of BG operations which took more than 1 hour is displayed in 
> incorrect time formats.
> For. E.g 1.71 hours
> It should display the duration in appropriate time units like 2.11 hours or 
> 111 mins
> Attaching screenshot



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20051) Hosts filter component list is not sorted so it is difficult to use

[Aleksandr Kovalenko (JIRA)]

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

Aleksandr Kovalenko updated AMBARI-20051:
-
Attachment: Screen Shot 2017-02-15 at 6.32.34 PM.png

> Hosts filter component list is not sorted so it is difficult to use
> ---
>
> Key: AMBARI-20051
> URL: https://issues.apache.org/jira/browse/AMBARI-20051
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Aleksandr Kovalenko
>Assignee: Aleksandr Kovalenko
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: Screen Shot 2017-02-15 at 6.32.34 PM.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20047) Repository config user needs to set customized service user in Ranger when service plugin is enabled

[Vishal Suvagia (JIRA)]

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

Vishal Suvagia updated AMBARI-20047:

Status: Patch Available  (was: In Progress)

> Repository config user needs to set customized service user in Ranger when 
> service plugin is enabled
> 
>
> Key: AMBARI-20047
> URL: https://issues.apache.org/jira/browse/AMBARI-20047
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vishal Suvagia
>Assignee: Vishal Suvagia
> Fix For: 2.5.0
>
> Attachments: AMBARI-20047.patch
>
>
> The property {{REPOSITORY_CONFIG_USERNAME}} in Advanced 
> ranger-*-plugin-properties is not updated to the custom user-name when 
> services are using custom users.
> This causes issues especially in cases of Test connection, and policy user 
> which is given default permissions in Ranger.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20047) Repository config user needs to set customized service user in Ranger when service plugin is enabled

[Vishal Suvagia (JIRA)]

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

Vishal Suvagia updated AMBARI-20047:

Attachment: AMBARI-20047.patch

> Repository config user needs to set customized service user in Ranger when 
> service plugin is enabled
> 
>
> Key: AMBARI-20047
> URL: https://issues.apache.org/jira/browse/AMBARI-20047
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vishal Suvagia
>Assignee: Vishal Suvagia
> Fix For: 2.5.0
>
> Attachments: AMBARI-20047.patch
>
>
> The property {{REPOSITORY_CONFIG_USERNAME}} in Advanced 
> ranger-*-plugin-properties is not updated to the custom user-name when 
> services are using custom users.
> This causes issues especially in cases of Test connection, and policy user 
> which is given default permissions in Ranger.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20049) One way SSL fallback logic can cause some agents to be connected with 2-way SSL

[Andrew Onischuk (JIRA)]

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

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

Committed to trunk and branch-2.5

> One way SSL fallback logic can cause some agents to be connected with 2-way 
> SSL
> ---
>
> Key: AMBARI-20049
> URL: https://issues.apache.org/jira/browse/AMBARI-20049
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-20049.patch
>
>
> We have fallback logic since a long time in the agent to try to connect to the
> server with 2-way SSL if one-way SSL throws an exception. This can cause some
> agents to connect with 2-way SSL (connection timeout exception for one-way
> SSL) and thereby a cluster having a mix of agents, some connected with one-way
> SSL and some connected with 2-way SSL.
> Investigate why we have had this logic and if it is no longer appropriate,
> remove this fallback logic.
>  agent/src/main/python/ambari_agent/security.py#L57-L67>
> 
> 
> 
> if not self.two_way_ssl_required:
>   try:
> sock = self.create_connection()
> self.sock = ssl.wrap_socket(sock, cert_reqs=ssl.CERT_NONE)
> logger.info('SSL connection established. Two-way SSL 
> authentication is '
> 'turned off on the server.')
>   except (ssl.SSLError, AttributeError):
> self.two_way_ssl_required = True
> logger.info(
>   'Insecure connection to https://' + self.host + ':' + self.port 
> +
>   '/ failed. Reconnecting using two-way SSL authentication..')
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20044) NullPointerException after server restart in case not all hosts were joined

[Sandor Magyari (JIRA)]

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

Sandor Magyari updated AMBARI-20044:

Attachment: AMBARI-20044.patch

> NullPointerException after server restart in case not all hosts were joined
> ---
>
> Key: AMBARI-20044
> URL: https://issues.apache.org/jira/browse/AMBARI-20044
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
> Fix For: 2.5.0
>
> Attachments: AMBARI-20044.patch
>
>
> NullPointerException after server restart in case not all hosts mentioned in 
> Cluster template were joined the cluster.
> The issue happens when TopologyManager tries to reconstruct requests for 
> hosts.
> {code}
> java.lang.NullPointerException
>   at java.lang.String.replace(String.java:2180)
>   at 
> org.apache.ambari.server.topology.HostRequest.getLogicalTasks(HostRequest.java:317)
>   at 
> org.apache.ambari.server.topology.LogicalRequest.getCommands(LogicalRequest.java:157)
>   at 
> org.apache.ambari.server.topology.LogicalRequest.getRequestStatus(LogicalRequest.java:230)
>   at 
> org.apache.ambari.server.topology.TopologyManager.isLogicalRequestFinished(TopologyManager.java:903)
>   at 
> org.apache.ambari.server.topology.TopologyManager.replayRequests(TopologyManager.java:857)
>   at 
> org.apache.ambari.server.topology.TopologyManager.ensureInitialized(TopologyManager.java:176)
>   at 
> org.apache.ambari.server.topology.TopologyManager.onHostRegistered(TopologyManager.java:477)
>   at 
> org.apache.ambari.server.state.host.HostImpl$HostRegistrationReceived.transition(HostImpl.java:34
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20044) NullPointerException after server restart in case not all hosts were joined

[Sandor Magyari (JIRA)]

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

Sandor Magyari updated AMBARI-20044:

Status: Patch Available  (was: Open)

> NullPointerException after server restart in case not all hosts were joined
> ---
>
> Key: AMBARI-20044
> URL: https://issues.apache.org/jira/browse/AMBARI-20044
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
> Fix For: 2.5.0
>
>
> NullPointerException after server restart in case not all hosts mentioned in 
> Cluster template were joined the cluster.
> The issue happens when TopologyManager tries to reconstruct requests for 
> hosts.
> {code}
> java.lang.NullPointerException
>   at java.lang.String.replace(String.java:2180)
>   at 
> org.apache.ambari.server.topology.HostRequest.getLogicalTasks(HostRequest.java:317)
>   at 
> org.apache.ambari.server.topology.LogicalRequest.getCommands(LogicalRequest.java:157)
>   at 
> org.apache.ambari.server.topology.LogicalRequest.getRequestStatus(LogicalRequest.java:230)
>   at 
> org.apache.ambari.server.topology.TopologyManager.isLogicalRequestFinished(TopologyManager.java:903)
>   at 
> org.apache.ambari.server.topology.TopologyManager.replayRequests(TopologyManager.java:857)
>   at 
> org.apache.ambari.server.topology.TopologyManager.ensureInitialized(TopologyManager.java:176)
>   at 
> org.apache.ambari.server.topology.TopologyManager.onHostRegistered(TopologyManager.java:477)
>   at 
> org.apache.ambari.server.state.host.HostImpl$HostRegistrationReceived.transition(HostImpl.java:34
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20049) One way SSL fallback logic can cause some agents to be connected with 2-way SSL

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20049:


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

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

This message is automatically generated.

> One way SSL fallback logic can cause some agents to be connected with 2-way 
> SSL
> ---
>
> Key: AMBARI-20049
> URL: https://issues.apache.org/jira/browse/AMBARI-20049
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-20049.patch
>
>
> We have fallback logic since a long time in the agent to try to connect to the
> server with 2-way SSL if one-way SSL throws an exception. This can cause some
> agents to connect with 2-way SSL (connection timeout exception for one-way
> SSL) and thereby a cluster having a mix of agents, some connected with one-way
> SSL and some connected with 2-way SSL.
> Investigate why we have had this logic and if it is no longer appropriate,
> remove this fallback logic.
>  agent/src/main/python/ambari_agent/security.py#L57-L67>
> 
> 
> 
> if not self.two_way_ssl_required:
>   try:
> sock = self.create_connection()
> self.sock = ssl.wrap_socket(sock, cert_reqs=ssl.CERT_NONE)
> logger.info('SSL connection established. Two-way SSL 
> authentication is '
> 'turned off on the server.')
>   except (ssl.SSLError, AttributeError):
> self.two_way_ssl_required = True
> logger.info(
>   'Insecure connection to https://' + self.host + ':' + self.port 
> +
>   '/ failed. Reconnecting using two-way SSL authentication..')
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20035) Duration in BGoperation window should display durations in proper time units

[Antonenko Alexander (JIRA)]

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

Antonenko Alexander commented on AMBARI-20035:
--

pushed to trunk

> Duration in BGoperation window should display durations in proper time units
> 
>
> Key: AMBARI-20035
> URL: https://issues.apache.org/jira/browse/AMBARI-20035
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 3.0.0
>
> Attachments: AMBARI-20035.patch, Screen Shot 2017-01-30 at 5.08.27 
> PM.png
>
>
> Duration of BG operations which took more than 1 hour is displayed in 
> incorrect time formats.
> For. E.g 1.71 hours
> It should display the duration in appropriate time units like 2.11 hours or 
> 111 mins
> Attaching screenshot



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20043) Don't rerender all widgets when on of them is changed

[Oleg Nechiporenko (JIRA)]

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

Oleg Nechiporenko updated AMBARI-20043:
---
Status: Patch Available  (was: Open)

> Don't rerender all widgets when on of them is changed
> -
>
> Key: AMBARI-20043
> URL: https://issues.apache.org/jira/browse/AMBARI-20043
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 3.0.0
>
> Attachments: AMBARI-20043.patch
>
>
> Dashboard widgets are rerendered if some of them is changed. Actually only 
> this one should be updated and not other



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20046) Fix druid metric_emitter_type when ambari-metrics-server is installed

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20046:


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

This message is automatically generated.

> Fix druid metric_emitter_type when ambari-metrics-server is installed
> -
>
> Key: AMBARI-20046
> URL: https://issues.apache.org/jira/browse/AMBARI-20046
> Project: Ambari
>  Issue Type: Bug
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
> Attachments: ambari-20046.patch
>
>
> In params.py for Druid - 
> {code}
> metric_emitter_type = "ambari-metrics-emitter"
> {code}
> should be spelled correctly as 
> {code}
> metric_emitter_type = "ambari-metrics"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20014) Multiple unit tests accessing same table which causes lock issues

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20014:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6763 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6763/])
AMBARI-20014 Multiple unit tests accessing same table which causes lock (dsen: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=b12ae51dd4a0c745827eea7ceb75c362e00d6f75])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java


> Multiple unit tests accessing same table which causes lock issues
> -
>
> Key: AMBARI-20014
> URL: https://issues.apache.org/jira/browse/AMBARI-20014
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk, 2.5.0
>
> Attachments: AMBARI-20014-branch-2.5.patch, AMBARI-20014.patch
>
>
> STR:
> AmbariManagementControllerTest.java#testCreateHostMultiple -> run test 
> infinitely till it would fail.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20014) Multiple unit tests accessing same table which causes lock issues

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20014:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1015 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1015/])
AMBARI-20014 More than one version of jetty jars found in Ambari rpm (dsen: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=48ea5380806280547056ce409a6a35019beb2514])
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java


> Multiple unit tests accessing same table which causes lock issues
> -
>
> Key: AMBARI-20014
> URL: https://issues.apache.org/jira/browse/AMBARI-20014
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk, 2.5.0
>
> Attachments: AMBARI-20014-branch-2.5.patch, AMBARI-20014.patch
>
>
> STR:
> AmbariManagementControllerTest.java#testCreateHostMultiple -> run test 
> infinitely till it would fail.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-19989) Allow user to view Tez View after executing query

[venkat (JIRA)]

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

venkat updated AMBARI-19989:

Attachment: AMBARI-19989.01.branch-2.5.patch

> Allow user to view Tez View after executing query
> -
>
> Key: AMBARI-19989
> URL: https://issues.apache.org/jira/browse/AMBARI-19989
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: venkat
>Assignee: venkat
>  Labels: hive-view
> Fix For: 2.5.0
>
> Attachments: AMBARI-19989.01.branch-2.5.patch, 
> AMBARI-19989.branch-2.5.patch
>
>
> As per the parity with Hive View 1.5, allow user to traverse to tez view from 
> the query page after executing a query.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20050) Issue while importing workflow with insufficient permissions

[Supreeth Sharma (JIRA)]

Supreeth Sharma created AMBARI-20050:


 Summary: Issue while importing workflow with insufficient 
permissions
 Key: AMBARI-20050
 URL: https://issues.apache.org/jira/browse/AMBARI-20050
 Project: Ambari
  Issue Type: Bug
  Components: ambari-views
Affects Versions: 2.5.0
Reporter: Supreeth Sharma
Priority: Critical
 Fix For: 2.5.0


Facing Issue while importing workflow with insufficient permissions. Though 
/api/v1/views/WORKFLOW_MANAGER/versions/1.0.0/instances/WFM/resources/proxy/readWorkflowDetail?workflowXmlPath=/user/admin/new/email.xml
 is failed with 500 code, its not been handled on the UI.
UI is stuck in import phase.

Steps to reproduce :
1) Login as user1 and submit workflow and save to hdfs location /user/user1 
2) Now login as user2 who doesn't have access to /user/user1 .
Now user2 can view the workflow status in the dashboard.
3) Click on edit workflow and try to navigate to designer page.
4) Due to lack of permission, user is not allowed to import the workflow and UI 
is not handling this error.

This should be properly handled on the UI and appropriate error message need to 
be displayed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20048) Hive View 2.0: Visual Explain-The operators are being shown out of order.

[Abhishek Kumar (JIRA)]

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

Abhishek Kumar updated AMBARI-20048:

Fix Version/s: 2.5.0
   Status: Patch Available  (was: In Progress)

> Hive View 2.0: Visual Explain-The operators are being shown out of order.
> -
>
> Key: AMBARI-20048
> URL: https://issues.apache.org/jira/browse/AMBARI-20048
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: Abhishek Kumar
>Assignee: Abhishek Kumar
> Fix For: 2.5.0
>
> Attachments: AMBARI-20048_trunk.patch
>
>
> The operators are being shown out of order. It’s hard to think about what to 
> do with the plan output when the operators are out of order, so this needs to 
> be fixed first.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20048) Hive View 2.0: Visual Explain-The operators are being shown out of order.

[Abhishek Kumar (JIRA)]

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

Abhishek Kumar updated AMBARI-20048:

Attachment: AMBARI-20048_trunk.patch

> Hive View 2.0: Visual Explain-The operators are being shown out of order.
> -
>
> Key: AMBARI-20048
> URL: https://issues.apache.org/jira/browse/AMBARI-20048
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: Abhishek Kumar
>Assignee: Abhishek Kumar
> Fix For: 2.5.0
>
> Attachments: AMBARI-20048_trunk.patch
>
>
> The operators are being shown out of order. It’s hard to think about what to 
> do with the plan output when the operators are out of order, so this needs to 
> be fixed first.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20041) Custom job.properties are not retained in the workflow designer

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20041:
-

SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #6762 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/6762/])
AMBARI-20041. Custom job.properties are not retained in the workflow (grvngr: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=ea82a59de4b170a10178eb1cc6385a8010e774fc])
* (edit) 
contrib/views/wfmanager/src/main/resources/ui/app/components/job-config.js
* (edit) contrib/views/wfmanager/src/main/resources/ui/app/routes/design.js
* (edit) 
contrib/views/wfmanager/src/main/resources/ui/app/components/designer-workspace.js
* (edit) 
contrib/views/wfmanager/src/main/resources/ui/app/components/job-details.js
* (edit) 
contrib/views/wfmanager/src/main/resources/ui/app/templates/components/flow-designer.hbs


> Custom job.properties are not retained in the workflow designer
> ---
>
> Key: AMBARI-20041
> URL: https://issues.apache.org/jira/browse/AMBARI-20041
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: venkat
>Assignee: venkat
>  Labels: wfd
> Fix For: 2.5.0
>
> Attachments: AMBARI-20041.branch-2.5.patch
>
>
> Custom job.properties are not retained in the workflow designer.
> Steps to reproduce :
> 1) Submit a workflow with custom job properties say 
> oozie.action.sharelib.for.sqoop=sqoop,hive.
> 2) From the dashboard, select this workflow.
> 3) When user tries to submit it again, previously included properties are not 
> visible to the user.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20014) Multiple unit tests accessing same table which causes lock issues

[Dmytro Grinenko (JIRA)]

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

Dmytro Grinenko commented on AMBARI-20014:
--

trunk - b12ae51dd4a0c745827eea7ceb75c362e00d6f75
branch 2.5 - 48ea5380806280547056ce409a6a35019beb2514

> Multiple unit tests accessing same table which causes lock issues
> -
>
> Key: AMBARI-20014
> URL: https://issues.apache.org/jira/browse/AMBARI-20014
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk, 2.5.0
>
> Attachments: AMBARI-20014-branch-2.5.patch, AMBARI-20014.patch
>
>
> STR:
> AmbariManagementControllerTest.java#testCreateHostMultiple -> run test 
> infinitely till it would fail.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20014) Multiple unit tests accessing same table which causes lock issues

[Dmytro Grinenko (JIRA)]

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

Dmytro Grinenko updated AMBARI-20014:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Multiple unit tests accessing same table which causes lock issues
> -
>
> Key: AMBARI-20014
> URL: https://issues.apache.org/jira/browse/AMBARI-20014
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk, 2.5.0
>
> Attachments: AMBARI-20014-branch-2.5.patch, AMBARI-20014.patch
>
>
> STR:
> AmbariManagementControllerTest.java#testCreateHostMultiple -> run test 
> infinitely till it would fail.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-19957) Implement new DB checks for Postgres to prevent cross-schema confusion

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-19957:


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

This message is automatically generated.

> Implement new DB checks for Postgres to prevent cross-schema confusion
> --
>
> Key: AMBARI-19957
> URL: https://issues.apache.org/jira/browse/AMBARI-19957
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Balázs Bence Sári
>Assignee: Balázs Bence Sári
> Fix For: 3.0.0, 2.5.0
>
> Attachments: AMBARI-19957-DB-checks_25_v4_rebase1.patch, 
> AMBARI-19957-DB-checks_trunk_v4.patch
>
>
> Postgres allows multiple schemas on a database user's search path, that is 
> users can query from tables in different schemas without the need of 
> prefixing the tables in the query. 
> This can lead to confusion when after an unsuccessful upgrade DBA's restore 
> the tables into a different schema (e.g. public) to Ambari's configured one. 
> As a result, Ambari server may see corrupt data.
> New consistency checks on server startup should warn the user in such 
> situations.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20042) HiveView2.0 : For large datasets, query results overlaps

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20042:


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

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

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

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

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

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

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

This message is automatically generated.

> HiveView2.0 : For large datasets, query results overlaps
> 
>
> Key: AMBARI-20042
> URL: https://issues.apache.org/jira/browse/AMBARI-20042
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: DIPAYAN BHOWMICK
>Assignee: DIPAYAN BHOWMICK
> Fix For: 2.5.0
>
> Attachments: AMBARI-20042.branch-2.5.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20041) Custom job.properties are not retained in the workflow designer

[Gaurav Nagar (JIRA)]

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

Gaurav Nagar updated AMBARI-20041:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to branch-2.5 and trunk.


> Custom job.properties are not retained in the workflow designer
> ---
>
> Key: AMBARI-20041
> URL: https://issues.apache.org/jira/browse/AMBARI-20041
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: venkat
>Assignee: venkat
>  Labels: wfd
> Fix For: 2.5.0
>
> Attachments: AMBARI-20041.branch-2.5.patch
>
>
> Custom job.properties are not retained in the workflow designer.
> Steps to reproduce :
> 1) Submit a workflow with custom job properties say 
> oozie.action.sharelib.for.sqoop=sqoop,hive.
> 2) From the dashboard, select this workflow.
> 3) When user tries to submit it again, previously included properties are not 
> visible to the user.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-19957) Implement new DB checks for Postgres to prevent cross-schema confusion

[Hudson (JIRA)]

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

Hudson commented on AMBARI-19957:
-

SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #1014 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1014/])
AMBARI-19957. Implement new DB checks for Postgres to prevent (stoader: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=04ec37d24800a78d628920c8a53306f1bc54d5c0])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/checks/DatabaseConsistencyCheckHelper.java
* (add) 
ambari-server/src/main/java/org/apache/ambari/server/checks/DatabaseConsistencyCheckResult.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/checks/DatabaseConsistencyCheckHelperTest.java
* (edit) ambari-server/src/main/python/ambari_server_main.py
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/checks/DatabaseConsistencyChecker.java


> Implement new DB checks for Postgres to prevent cross-schema confusion
> --
>
> Key: AMBARI-19957
> URL: https://issues.apache.org/jira/browse/AMBARI-19957
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Balázs Bence Sári
>Assignee: Balázs Bence Sári
> Fix For: 3.0.0, 2.5.0
>
> Attachments: AMBARI-19957-DB-checks_25_v4_rebase1.patch, 
> AMBARI-19957-DB-checks_trunk_v4.patch
>
>
> Postgres allows multiple schemas on a database user's search path, that is 
> users can query from tables in different schemas without the need of 
> prefixing the tables in the query. 
> This can lead to confusion when after an unsuccessful upgrade DBA's restore 
> the tables into a different schema (e.g. public) to Ambari's configured one. 
> As a result, Ambari server may see corrupt data.
> New consistency checks on server startup should warn the user in such 
> situations.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20040) Workflow Manager workflow rendering is broken in designer page

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20040:
-

SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #1014 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1014/])
AMBARI-20040. Workflow Manager workflow rendering is broken in designer 
(grvngr: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=c69e7607c2bff78afad25d65ffaabff127e56aea])
* (edit) 
contrib/views/wfmanager/src/main/resources/ui/app/domain/cytoscape-flow-renderer.js
* (edit) 
contrib/views/wfmanager/src/main/resources/ui/app/domain/cytoscape-style.js
* (edit) 
contrib/views/wfmanager/src/main/resources/ui/app/validators/duplicate-data-node-name.js


> Workflow Manager workflow rendering is broken in designer page
> --
>
> Key: AMBARI-20040
> URL: https://issues.apache.org/jira/browse/AMBARI-20040
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: Belliraj HB
>Assignee: Belliraj HB
>  Labels: WFD, WFM
> Fix For: 2.5.0
>
> Attachments: AMBARI-20040_trunk.patch, workflow (3).xml
>
>
> Workflow rendering is broken in designer page.
> Steps to reproduce :
> 1) Import the attached workflow and check that rendering of the workflow is 
> broken.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20049) One way SSL fallback logic can cause some agents to be connected with 2-way SSL

[Andrew Onischuk (JIRA)]

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

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

> One way SSL fallback logic can cause some agents to be connected with 2-way 
> SSL
> ---
>
> Key: AMBARI-20049
> URL: https://issues.apache.org/jira/browse/AMBARI-20049
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-20049.patch
>
>
> We have fallback logic since a long time in the agent to try to connect to the
> server with 2-way SSL if one-way SSL throws an exception. This can cause some
> agents to connect with 2-way SSL (connection timeout exception for one-way
> SSL) and thereby a cluster having a mix of agents, some connected with one-way
> SSL and some connected with 2-way SSL.
> Investigate why we have had this logic and if it is no longer appropriate,
> remove this fallback logic.
>  agent/src/main/python/ambari_agent/security.py#L57-L67>
> 
> 
> 
> if not self.two_way_ssl_required:
>   try:
> sock = self.create_connection()
> self.sock = ssl.wrap_socket(sock, cert_reqs=ssl.CERT_NONE)
> logger.info('SSL connection established. Two-way SSL 
> authentication is '
> 'turned off on the server.')
>   except (ssl.SSLError, AttributeError):
> self.two_way_ssl_required = True
> logger.info(
>   'Insecure connection to https://' + self.host + ':' + self.port 
> +
>   '/ failed. Reconnecting using two-way SSL authentication..')
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20049) One way SSL fallback logic can cause some agents to be connected with 2-way SSL

[Andrew Onischuk (JIRA)]

Andrew Onischuk created AMBARI-20049:


 Summary: One way SSL fallback logic can cause some agents to be 
connected with 2-way SSL
 Key: AMBARI-20049
 URL: https://issues.apache.org/jira/browse/AMBARI-20049
 Project: Ambari
  Issue Type: Bug
Reporter: Andrew Onischuk
Assignee: Andrew Onischuk
 Fix For: 2.5.0
 Attachments: AMBARI-20049.patch

We have fallback logic since a long time in the agent to try to connect to the
server with 2-way SSL if one-way SSL throws an exception. This can cause some
agents to connect with 2-way SSL (connection timeout exception for one-way
SSL) and thereby a cluster having a mix of agents, some connected with one-way
SSL and some connected with 2-way SSL.

Investigate why we have had this logic and if it is no longer appropriate,
remove this fallback logic.






if not self.two_way_ssl_required:
  try:
sock = self.create_connection()
self.sock = ssl.wrap_socket(sock, cert_reqs=ssl.CERT_NONE)
logger.info('SSL connection established. Two-way SSL authentication 
is '
'turned off on the server.')
  except (ssl.SSLError, AttributeError):
self.two_way_ssl_required = True
logger.info(
  'Insecure connection to https://' + self.host + ':' + self.port +
  '/ failed. Reconnecting using two-way SSL authentication..')






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20049) One way SSL fallback logic can cause some agents to be connected with 2-way SSL

[Andrew Onischuk (JIRA)]

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

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

> One way SSL fallback logic can cause some agents to be connected with 2-way 
> SSL
> ---
>
> Key: AMBARI-20049
> URL: https://issues.apache.org/jira/browse/AMBARI-20049
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.5.0
>
> Attachments: AMBARI-20049.patch
>
>
> We have fallback logic since a long time in the agent to try to connect to the
> server with 2-way SSL if one-way SSL throws an exception. This can cause some
> agents to connect with 2-way SSL (connection timeout exception for one-way
> SSL) and thereby a cluster having a mix of agents, some connected with one-way
> SSL and some connected with 2-way SSL.
> Investigate why we have had this logic and if it is no longer appropriate,
> remove this fallback logic.
>  agent/src/main/python/ambari_agent/security.py#L57-L67>
> 
> 
> 
> if not self.two_way_ssl_required:
>   try:
> sock = self.create_connection()
> self.sock = ssl.wrap_socket(sock, cert_reqs=ssl.CERT_NONE)
> logger.info('SSL connection established. Two-way SSL 
> authentication is '
> 'turned off on the server.')
>   except (ssl.SSLError, AttributeError):
> self.two_way_ssl_required = True
> logger.info(
>   'Insecure connection to https://' + self.host + ':' + self.port 
> +
>   '/ failed. Reconnecting using two-way SSL authentication..')
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20048) Hive View 2.0: Visual Explain-The operators are being shown out of order.

[Abhishek Kumar (JIRA)]

Abhishek Kumar created AMBARI-20048:
---

 Summary: Hive View 2.0: Visual Explain-The operators are being 
shown out of order.
 Key: AMBARI-20048
 URL: https://issues.apache.org/jira/browse/AMBARI-20048
 Project: Ambari
  Issue Type: Bug
  Components: ambari-views
Affects Versions: 2.5.0
Reporter: Abhishek Kumar
Assignee: Abhishek Kumar


The operators are being shown out of order. It’s hard to think about what to do 
with the plan output when the operators are out of order, so this needs to be 
fixed first.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20045) More than one version of jetty jars found in Ambari rpm

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20045:


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

This message is automatically generated.

> More than one version of jetty jars found in Ambari rpm
> ---
>
> Key: AMBARI-20045
> URL: https://issues.apache.org/jira/browse/AMBARI-20045
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20045.patch
>
>
> Got a warning on restart of my cluster:
> {code}
> Ambari Server running with administrator privileges.
> Organizing resource files at /var/lib/ambari-server/resources...
> WARNING: Multiple versions of jetty-util.jar found in java class path 
> (/usr/lib/ambari-server/jetty-util-6.1.26.jar and 
> /usr/lib/ambari-server/jetty-util-8.1.19.v20160209.jar).
>  Make sure that you include only one jetty-util.jar in the java class path 
> '/etc/ambari-server/conf:/usr/lib/ambari-server/*:/usr/share/java/mysql-connector-java.jar'.
> Ambari database consistency check started...
> {code}
> Noticed there are older jetty jars packaged with the rpm:
> {code}
> [root@perf-a-1 ~]# rpm -ql ambari-server-2.5.0.0-914.x86_64 | grep jetty
> /usr/lib/ambari-server/jetty-6.1.26.jar
> /usr/lib/ambari-server/jetty-util-6.1.26.jar
> /usr/lib/ambari-server/jetty-util-8.1.19.v20160209.jar
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (AMBARI-20047) Repository config user needs to set customized service user in Ranger when service plugin is enabled

[Vishal Suvagia (JIRA)]

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

Vishal Suvagia reassigned AMBARI-20047:
---

Assignee: Vishal Suvagia

> Repository config user needs to set customized service user in Ranger when 
> service plugin is enabled
> 
>
> Key: AMBARI-20047
> URL: https://issues.apache.org/jira/browse/AMBARI-20047
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vishal Suvagia
>Assignee: Vishal Suvagia
> Fix For: 2.5.0
>
>
> The property {{REPOSITORY_CONFIG_USERNAME}} in Advanced 
> ranger-*-plugin-properties is not updated to the custom user-name when 
> services are using custom users.
> This causes issues especially in cases of Test connection, and policy user 
> which is given default permissions in Ranger.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20047) Repository config user needs to set customized service user in Ranger when service plugin is enabled

[Vishal Suvagia (JIRA)]

Vishal Suvagia created AMBARI-20047:
---

 Summary: Repository config user needs to set customized service 
user in Ranger when service plugin is enabled
 Key: AMBARI-20047
 URL: https://issues.apache.org/jira/browse/AMBARI-20047
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.5.0
Reporter: Vishal Suvagia
 Fix For: 2.5.0


The property {{REPOSITORY_CONFIG_USERNAME}} in Advanced 
ranger-*-plugin-properties is not updated to the custom user-name when services 
are using custom users.
This causes issues especially in cases of Test connection, and policy user 
which is given default permissions in Ranger.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20043) Don't rerender all widgets when on of them is changed

[Oleg Nechiporenko (JIRA)]

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

Oleg Nechiporenko commented on AMBARI-20043:


+1 by [~BuzhorDenys] on the review board

> Don't rerender all widgets when on of them is changed
> -
>
> Key: AMBARI-20043
> URL: https://issues.apache.org/jira/browse/AMBARI-20043
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 3.0.0
>
> Attachments: AMBARI-20043.patch
>
>
> Dashboard widgets are rerendered if some of them is changed. Actually only 
> this one should be updated and not other



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-19957) Implement new DB checks for Postgres to prevent cross-schema confusion

[JIRA]

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

Balázs Bence Sári updated AMBARI-19957:
---
Attachment: AMBARI-19957-DB-checks_25_v4_rebase1.patch

> Implement new DB checks for Postgres to prevent cross-schema confusion
> --
>
> Key: AMBARI-19957
> URL: https://issues.apache.org/jira/browse/AMBARI-19957
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Balázs Bence Sári
>Assignee: Balázs Bence Sári
> Fix For: 3.0.0, 2.5.0
>
> Attachments: AMBARI-19957-DB-checks_25_v4_rebase1.patch, 
> AMBARI-19957-DB-checks_trunk_v4.patch
>
>
> Postgres allows multiple schemas on a database user's search path, that is 
> users can query from tables in different schemas without the need of 
> prefixing the tables in the query. 
> This can lead to confusion when after an unsuccessful upgrade DBA's restore 
> the tables into a different schema (e.g. public) to Ambari's configured one. 
> As a result, Ambari server may see corrupt data.
> New consistency checks on server startup should warn the user in such 
> situations.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20040) Workflow Manager workflow rendering is broken in designer page

[Gaurav Nagar (JIRA)]

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

Gaurav Nagar updated AMBARI-20040:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to branch-2.5 and trunk.


> Workflow Manager workflow rendering is broken in designer page
> --
>
> Key: AMBARI-20040
> URL: https://issues.apache.org/jira/browse/AMBARI-20040
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: Belliraj HB
>Assignee: Belliraj HB
>  Labels: WFD, WFM
> Fix For: 2.5.0
>
> Attachments: AMBARI-20040_trunk.patch, workflow (3).xml
>
>
> Workflow rendering is broken in designer page.
> Steps to reproduce :
> 1) Import the attached workflow and check that rendering of the workflow is 
> broken.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20046) Fix druid metric_emitter_type when ambari-metrics-server is installed

[Nishant Bangarwa (JIRA)]

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

Nishant Bangarwa updated AMBARI-20046:
--
Status: Patch Available  (was: Open)

> Fix druid metric_emitter_type when ambari-metrics-server is installed
> -
>
> Key: AMBARI-20046
> URL: https://issues.apache.org/jira/browse/AMBARI-20046
> Project: Ambari
>  Issue Type: Bug
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
> Attachments: ambari-20046.patch
>
>
> In params.py for Druid - 
> {code}
> metric_emitter_type = "ambari-metrics-emitter"
> {code}
> should be spelled correctly as 
> {code}
> metric_emitter_type = "ambari-metrics"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20046) Fix druid metric_emitter_type when ambari-metrics-server is installed

[Nishant Bangarwa (JIRA)]

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

Nishant Bangarwa updated AMBARI-20046:
--
Attachment: ambari-20046.patch

> Fix druid metric_emitter_type when ambari-metrics-server is installed
> -
>
> Key: AMBARI-20046
> URL: https://issues.apache.org/jira/browse/AMBARI-20046
> Project: Ambari
>  Issue Type: Bug
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
> Attachments: ambari-20046.patch
>
>
> In params.py for Druid - 
> {code}
> metric_emitter_type = "ambari-metrics-emitter"
> {code}
> should be spelled correctly as 
> {code}
> metric_emitter_type = "ambari-metrics"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20046) Fix druid metric_emitter_type when ambari-metrics-server is installed

[Nishant Bangarwa (JIRA)]

Nishant Bangarwa created AMBARI-20046:
-

 Summary: Fix druid metric_emitter_type when ambari-metrics-server 
is installed
 Key: AMBARI-20046
 URL: https://issues.apache.org/jira/browse/AMBARI-20046
 Project: Ambari
  Issue Type: Bug
Reporter: Nishant Bangarwa
Assignee: Nishant Bangarwa


In params.py for Druid - 
{code}
metric_emitter_type = "ambari-metrics-emitter"
{code}
should be spelled correctly as 
{code}
metric_emitter_type = "ambari-metrics"
{code}





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)