[jira] [Updated] (AMBARI-18101) Update zeppelin shiro.ini template with ActiveDirectoryGroupRealm info

[Sumit Mohanty (JIRA)]

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

Sumit Mohanty updated AMBARI-18101:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

committed to trunk and branch-2.4

> Update zeppelin shiro.ini template with ActiveDirectoryGroupRealm info
> --
>
> Key: AMBARI-18101
> URL: https://issues.apache.org/jira/browse/AMBARI-18101
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18101_trunk+branch-2.4_v1.patch, 
> AMBARI-18101_trunk+branch-2.4_v2.patch
>
>




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

[jira] [Created] (AMBARI-18113) Installing ambari-metrics-grafana fails due to lack of conf directory

[Masahiro Tanaka (JIRA)]

Masahiro Tanaka created AMBARI-18113:


 Summary: Installing ambari-metrics-grafana fails due to lack of 
conf directory
 Key: AMBARI-18113
 URL: https://issues.apache.org/jira/browse/AMBARI-18113
 Project: Ambari
  Issue Type: Bug
  Components: ambari-metrics
Affects Versions: trunk
 Environment: Ambari trunk, Centos 6.7
Reporter: Masahiro Tanaka
Assignee: Masahiro Tanaka
 Fix For: 2.5.0


When installing Ambari Metrics, I got an error:

Stderr
{code}
Traceback (most recent call last):
  File 
"/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana.py",
 line 67, in 
AmsGrafana().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/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana.py",
 line 32, in install
self.configure(env) # for security
  File 
"/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana.py",
 line 37, in configure
ams(name='grafana', action=action)
  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/AMBARI_METRICS/0.1.0/package/scripts/ams.py",
 line 413, in ams
recursive_ownership = True
  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 189, in action_create
raise Fail("Applying %s failed, parent directory %s doesn't exist" % 
(self.resource, dirname))
resource_management.core.exceptions.Fail: Applying 
Directory['/etc/ambari-metrics-grafana/conf'] failed, parent directory 
/etc/ambari-metrics-grafana doesn't exist
{code}

Stdout
{code}
2016-08-11 13:38:44,481 - Group['hadoop'] {}
2016-08-11 13:38:44,483 - Adding group Group['hadoop']
2016-08-11 13:38:44,499 - User['zookeeper'] {'gid': 'hadoop', 
'fetch_nonlocal_groups': True, 'groups': ['hadoop']}
2016-08-11 13:38:44,499 - Adding user User['zookeeper']
2016-08-11 13:38:44,555 - User['ams'] {'gid': 'hadoop', 
'fetch_nonlocal_groups': True, 'groups': ['hadoop']}
2016-08-11 13:38:44,556 - Adding user User['ams']
2016-08-11 13:38:44,582 - User['ambari-qa'] {'gid': 'hadoop', 
'fetch_nonlocal_groups': True, 'groups': ['users']}
2016-08-11 13:38:44,582 - Adding user User['ambari-qa']
2016-08-11 13:38:44,616 - File['/var/lib/ambari-agent/tmp/changeUid.sh'] 
{'content': StaticFile('changeToSecureUid.sh'), 'mode': 0555}
2016-08-11 13:38:44,622 - Writing 
File['/var/lib/ambari-agent/tmp/changeUid.sh'] because it doesn't exist
2016-08-11 13:38:44,622 - Changing permission for 
/var/lib/ambari-agent/tmp/changeUid.sh from 644 to 555
2016-08-11 13:38:44,622 - Execute['/var/lib/ambari-agent/tmp/changeUid.sh 
ambari-qa 
/tmp/hadoop-ambari-qa,/tmp/hsperfdata_ambari-qa,/home/ambari-qa,/tmp/ambari-qa,/tmp/sqoop-ambari-qa']
 {'not_if': '(test $(id -u ambari-qa) -gt 1000) || (false)'}
2016-08-11 13:38:44,666 - Initializing 2 repositories
2016-08-11 13:38:44,666 - Repository['HDP-2.5'] {'base_url': 
'http://s3.amazonaws.com/dev.hortonworks.com/HDP/centos6/2.x/BUILDS/2.5.0.0-1181',
 'action': ['create'], 'components': ['HDP', 'main'], 'repo_template': 
'[{{repo_id}}]\nname={{repo_id}}\n{% if mirror_list 
%}mirrorlist={{mirror_list}}{% else %}baseurl={{base_url}}{% endif 
%}\n\npath=/\nenabled=1\ngpgcheck=0', 'repo_file_name': 'HDP', 'mirror_list': 
None}
2016-08-11 13:38:44,684 - File['/etc/yum.repos.d/HDP.repo'] {'content': 
InlineTemplate(...)}
2016-08-11 13:38:44,685 - Writing File['/etc/yum.repos.d/HDP.repo'] because it 
doesn't exist
2016-08-11 13:38:44,686 - Repository['HDP-UTILS-1.1.0.21'] {'base_url': 
'http://s3.amazonaws.com/dev.hortonworks.com/HDP-UTILS-1.1.0.21/repos/centos6', 
'action': ['create'], 'components': ['HDP-UTILS', 'main'], 'repo_template': 
'[{{repo_id}}]\nname={{repo_id}}\n{% if mirror_list 
%}mirrorlist={{mirror_list}}{% else %}baseurl={{base_url}}{% endif 
%}\n\npath=/\nenabled=1\ngpgcheck=0', 'repo_file_name': 'HDP-UTILS', 
'mirror_list': None}
2016-08-11 13:38:44,692 - File['/etc/yum.repos.d/HDP-UTILS.repo'] {'content': 
InlineTemplate(...)}
2016-08-11 13:38:44,693 - Writing File['/etc/yum.repos.d/HDP-UTILS.repo'] 
because it doesn't exist
2016-08-11 13:38:44,694 - Package['unzip'] {'retry_on_repo_unavailability': 
False, 'retry_count': 5}
2016-08-11 13:38:44,851 - Skipping 

[jira] [Updated] (AMBARI-18095) Use Zookeeper *.log file instead of *.out (in Logfeeder too)

[Dharmesh Makwana (JIRA)]

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

Dharmesh Makwana updated AMBARI-18095:
--
Status: Patch Available  (was: Open)

> Use Zookeeper *.log file instead of *.out (in Logfeeder too)
> 
>
> Key: AMBARI-18095
> URL: https://issues.apache.org/jira/browse/AMBARI-18095
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dharmesh Makwana
>Assignee: Dharmesh Makwana
> Fix For: 2.5.0
>
> Attachments: AMBARI-18095.patch
>
>
> *.out file is not rotated, log4j of zookeeper is configured wrongly inside 
> ambari (by default), so zookeeper.log is not generated at all. also *.out 
> file is not rotated, which is also a problem



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

[jira] [Updated] (AMBARI-18095) Use Zookeeper *.log file instead of *.out (in Logfeeder too)

[Dharmesh Makwana (JIRA)]

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

Dharmesh Makwana updated AMBARI-18095:
--
Attachment: AMBARI-18095.patch

> Use Zookeeper *.log file instead of *.out (in Logfeeder too)
> 
>
> Key: AMBARI-18095
> URL: https://issues.apache.org/jira/browse/AMBARI-18095
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dharmesh Makwana
>Assignee: Dharmesh Makwana
> Fix For: 2.5.0
>
> Attachments: AMBARI-18095.patch
>
>
> *.out file is not rotated, log4j of zookeeper is configured wrongly inside 
> ambari (by default), so zookeeper.log is not generated at all. also *.out 
> file is not rotated, which is also a problem



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

[jira] [Updated] (AMBARI-18111) Interactive Query configs are not reset after refresh/back on Install Wizard

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-18111:

Attachment: (was: AMBARI-18111.patch)

> Interactive Query configs are not reset after refresh/back on Install Wizard
> 
>
> Key: AMBARI-18111
> URL: https://issues.apache.org/jira/browse/AMBARI-18111
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18111.patch
>
>




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

[jira] [Updated] (AMBARI-18111) Interactive Query configs are not reset after refresh/back on Install Wizard

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-18111:

Status: Patch Available  (was: Open)

> Interactive Query configs are not reset after refresh/back on Install Wizard
> 
>
> Key: AMBARI-18111
> URL: https://issues.apache.org/jira/browse/AMBARI-18111
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18111.patch
>
>




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

[jira] [Updated] (AMBARI-18111) Interactive Query configs are not reset after refresh/back on Install Wizard

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-18111:

Attachment: AMBARI-18111.patch

> Interactive Query configs are not reset after refresh/back on Install Wizard
> 
>
> Key: AMBARI-18111
> URL: https://issues.apache.org/jira/browse/AMBARI-18111
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18111.patch
>
>




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

[jira] [Updated] (AMBARI-18111) Interactive Query configs are not reset after refresh/back on Install Wizard

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-18111:

Attachment: AMBARI-18111.patch

> Interactive Query configs are not reset after refresh/back on Install Wizard
> 
>
> Key: AMBARI-18111
> URL: https://issues.apache.org/jira/browse/AMBARI-18111
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18111.patch
>
>




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

[jira] [Updated] (AMBARI-18112) Fix spark.driver.extraLibraryPath to include native gpl library

[Weiqing Yang (JIRA)]

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

Weiqing Yang updated AMBARI-18112:
--
Description: 
When spark applications run in yarn cluster mode, there is an error from 
executors:
-
java.lang.UnsatisfiedLinkError: no gplcompression in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1889)
at java.lang.Runtime.loadLibrary0(Runtime.java:849)
at java.lang.System.loadLibrary(System.java:1088)
at 
com.hadoop.compression.lzo.GPLNativeCodeLoader.(GPLNativeCodeLoader.java:32)
at com.hadoop.compression.lzo.LzoCodec.(LzoCodec.java:71)
at java.lang.Class.forName0(Native Method)
...
org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:274)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
16/08/08 12:59:03 ERROR LzoCodec: Cannot load native-lzo without native-hadoop.

In the patch, it will set “spark.executor.extraLibraryPath 
/usr/hdp/current/hadoop-client/lib/native:/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64”
 in spark-defaults.conf.

  was:
When spark applications run in yarn cluster mode, there is an exception from 
executors:
-
java.lang.UnsatisfiedLinkError: no gplcompression in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1889)
at java.lang.Runtime.loadLibrary0(Runtime.java:849)
at java.lang.System.loadLibrary(System.java:1088)
at 
com.hadoop.compression.lzo.GPLNativeCodeLoader.(GPLNativeCodeLoader.java:32)
at com.hadoop.compression.lzo.LzoCodec.(LzoCodec.java:71)
at java.lang.Class.forName0(Native Method)
...
org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:274)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
16/08/08 12:59:03 ERROR LzoCodec: Cannot load native-lzo without native-hadoop.

In the patch, it will set “spark.executor.extraLibraryPath 
/usr/hdp/current/hadoop-client/lib/native:/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64”
 in spark-defaults.conf.


> Fix spark.driver.extraLibraryPath to include native gpl library
> ---
>
> Key: AMBARI-18112
> URL: https://issues.apache.org/jira/browse/AMBARI-18112
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.5.0
>Reporter: Weiqing Yang
>
> When spark applications run in yarn cluster mode, there is an error from 
> executors:
> -
> java.lang.UnsatisfiedLinkError: no gplcompression in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1889)
> at java.lang.Runtime.loadLibrary0(Runtime.java:849)
> at java.lang.System.loadLibrary(System.java:1088)
> at 
> com.hadoop.compression.lzo.GPLNativeCodeLoader.(GPLNativeCodeLoader.java:32)
> at com.hadoop.compression.lzo.LzoCodec.(LzoCodec.java:71)
> at java.lang.Class.forName0(Native Method)
> ...
> org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:274)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 16/08/08 12:59:03 ERROR LzoCodec: Cannot load native-lzo without 
> native-hadoop.
> In the patch, it will set “spark.executor.extraLibraryPath 
> /usr/hdp/current/hadoop-client/lib/native:/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64”
>  in spark-defaults.conf.



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

[jira] [Assigned] (AMBARI-18112) Fix spark.driver.extraLibraryPath to include native gpl library

[Weiqing Yang (JIRA)]

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

Weiqing Yang reassigned AMBARI-18112:
-

Assignee: Weiqing Yang

> Fix spark.driver.extraLibraryPath to include native gpl library
> ---
>
> Key: AMBARI-18112
> URL: https://issues.apache.org/jira/browse/AMBARI-18112
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.5.0
>Reporter: Weiqing Yang
>Assignee: Weiqing Yang
>
> When spark applications run in yarn cluster mode, there is an error from 
> executors:
> -
> java.lang.UnsatisfiedLinkError: no gplcompression in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1889)
> at java.lang.Runtime.loadLibrary0(Runtime.java:849)
> at java.lang.System.loadLibrary(System.java:1088)
> at 
> com.hadoop.compression.lzo.GPLNativeCodeLoader.(GPLNativeCodeLoader.java:32)
> at com.hadoop.compression.lzo.LzoCodec.(LzoCodec.java:71)
> at java.lang.Class.forName0(Native Method)
> ...
> org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:274)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 16/08/08 12:59:03 ERROR LzoCodec: Cannot load native-lzo without 
> native-hadoop.
> In the patch, it will set “spark.executor.extraLibraryPath 
> /usr/hdp/current/hadoop-client/lib/native:/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64”
>  in spark-defaults.conf.



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

[jira] [Updated] (AMBARI-18112) Fix spark.driver.extraLibraryPath to include native gpl library

[Weiqing Yang (JIRA)]

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

Weiqing Yang updated AMBARI-18112:
--
Description: 
When spark applications run in yarn cluster mode, there is an exception from 
executors:
-
java.lang.UnsatisfiedLinkError: no gplcompression in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1889)
at java.lang.Runtime.loadLibrary0(Runtime.java:849)
at java.lang.System.loadLibrary(System.java:1088)
at 
com.hadoop.compression.lzo.GPLNativeCodeLoader.(GPLNativeCodeLoader.java:32)
at com.hadoop.compression.lzo.LzoCodec.(LzoCodec.java:71)
at java.lang.Class.forName0(Native Method)
...
org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:274)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
16/08/08 12:59:03 ERROR LzoCodec: Cannot load native-lzo without native-hadoop.

In the patch, it will set “spark.executor.extraLibraryPath 
/usr/hdp/current/hadoop-client/lib/native:/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64”
 in spark-defaults.conf.

  was:
When spark applications run in yarn cluster mode, there is an exception from 
executors as following:
-
java.lang.UnsatisfiedLinkError: no gplcompression in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1889)
at java.lang.Runtime.loadLibrary0(Runtime.java:849)
at java.lang.System.loadLibrary(System.java:1088)
at 
com.hadoop.compression.lzo.GPLNativeCodeLoader.(GPLNativeCodeLoader.java:32)
at com.hadoop.compression.lzo.LzoCodec.(LzoCodec.java:71)
at java.lang.Class.forName0(Native Method)
...
org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:274)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
16/08/08 12:59:03 ERROR LzoCodec: Cannot load native-lzo without native-hadoop.

In the patch, it will set “spark.executor.extraLibraryPath 
/usr/hdp/current/hadoop-client/lib/native:/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64”
 in spark-defaults.conf.


> Fix spark.driver.extraLibraryPath to include native gpl library
> ---
>
> Key: AMBARI-18112
> URL: https://issues.apache.org/jira/browse/AMBARI-18112
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.5.0
>Reporter: Weiqing Yang
>
> When spark applications run in yarn cluster mode, there is an exception from 
> executors:
> -
> java.lang.UnsatisfiedLinkError: no gplcompression in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1889)
> at java.lang.Runtime.loadLibrary0(Runtime.java:849)
> at java.lang.System.loadLibrary(System.java:1088)
> at 
> com.hadoop.compression.lzo.GPLNativeCodeLoader.(GPLNativeCodeLoader.java:32)
> at com.hadoop.compression.lzo.LzoCodec.(LzoCodec.java:71)
> at java.lang.Class.forName0(Native Method)
> ...
> org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:274)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 16/08/08 12:59:03 ERROR LzoCodec: Cannot load native-lzo without 
> native-hadoop.
> In the patch, it will set “spark.executor.extraLibraryPath 
> /usr/hdp/current/hadoop-client/lib/native:/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64”
>  in spark-defaults.conf.



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

[jira] [Updated] (AMBARI-18112) Fix spark.driver.extraLibraryPath to include native gpl library

[Weiqing Yang (JIRA)]

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

Weiqing Yang updated AMBARI-18112:
--
Description: 
When spark applications run in yarn cluster mode, there is an exception from 
executors as following:
-
java.lang.UnsatisfiedLinkError: no gplcompression in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1889)
at java.lang.Runtime.loadLibrary0(Runtime.java:849)
at java.lang.System.loadLibrary(System.java:1088)
at 
com.hadoop.compression.lzo.GPLNativeCodeLoader.(GPLNativeCodeLoader.java:32)
at com.hadoop.compression.lzo.LzoCodec.(LzoCodec.java:71)
at java.lang.Class.forName0(Native Method)
...
org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:274)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
16/08/08 12:59:03 ERROR LzoCodec: Cannot load native-lzo without native-hadoop.

In the patch, it will set “spark.executor.extraLibraryPath 
/usr/hdp/current/hadoop-client/lib/native:/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64”
 in spark-defaults.conf.

  was:
When spark applications run in yarn cluster, there is an exception from 
executors as following:
-
java.lang.UnsatisfiedLinkError: no gplcompression in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1889)
at java.lang.Runtime.loadLibrary0(Runtime.java:849)
at java.lang.System.loadLibrary(System.java:1088)
at 
com.hadoop.compression.lzo.GPLNativeCodeLoader.(GPLNativeCodeLoader.java:32)
at com.hadoop.compression.lzo.LzoCodec.(LzoCodec.java:71)
at java.lang.Class.forName0(Native Method)
...
org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:274)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
16/08/08 12:59:03 ERROR LzoCodec: Cannot load native-lzo without native-hadoop.

In the patch, it will set “spark.executor.extraLibraryPath 
/usr/hdp/current/hadoop-client/lib/native:/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64”
 in spark-defaults.conf.


> Fix spark.driver.extraLibraryPath to include native gpl library
> ---
>
> Key: AMBARI-18112
> URL: https://issues.apache.org/jira/browse/AMBARI-18112
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.5.0
>Reporter: Weiqing Yang
>
> When spark applications run in yarn cluster mode, there is an exception from 
> executors as following:
> -
> java.lang.UnsatisfiedLinkError: no gplcompression in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1889)
> at java.lang.Runtime.loadLibrary0(Runtime.java:849)
> at java.lang.System.loadLibrary(System.java:1088)
> at 
> com.hadoop.compression.lzo.GPLNativeCodeLoader.(GPLNativeCodeLoader.java:32)
> at com.hadoop.compression.lzo.LzoCodec.(LzoCodec.java:71)
> at java.lang.Class.forName0(Native Method)
> ...
> org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:274)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 16/08/08 12:59:03 ERROR LzoCodec: Cannot load native-lzo without 
> native-hadoop.
> In the patch, it will set “spark.executor.extraLibraryPath 
> /usr/hdp/current/hadoop-client/lib/native:/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64”
>  in spark-defaults.conf.



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

[jira] [Created] (AMBARI-18112) Fix spark.driver.extraLibraryPath to include native gpl library

[Weiqing Yang (JIRA)]

Weiqing Yang created AMBARI-18112:
-

 Summary: Fix spark.driver.extraLibraryPath to include native gpl 
library
 Key: AMBARI-18112
 URL: https://issues.apache.org/jira/browse/AMBARI-18112
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: trunk, 2.5.0
Reporter: Weiqing Yang


When spark applications run in yarn cluster, there is an exception from 
executors as following:
-
java.lang.UnsatisfiedLinkError: no gplcompression in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1889)
at java.lang.Runtime.loadLibrary0(Runtime.java:849)
at java.lang.System.loadLibrary(System.java:1088)
at 
com.hadoop.compression.lzo.GPLNativeCodeLoader.(GPLNativeCodeLoader.java:32)
at com.hadoop.compression.lzo.LzoCodec.(LzoCodec.java:71)
at java.lang.Class.forName0(Native Method)
...
org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:274)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
16/08/08 12:59:03 ERROR LzoCodec: Cannot load native-lzo without native-hadoop.

In the patch, it will set “spark.executor.extraLibraryPath 
/usr/hdp/current/hadoop-client/lib/native:/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64”
 in spark-defaults.conf.



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

[jira] [Created] (AMBARI-18111) Interactive Query configs are not reset after refresh/back on Install Wizard

[Jaimin D Jetly (JIRA)]

Jaimin D Jetly created AMBARI-18111:
---

 Summary: Interactive Query configs are not reset after 
refresh/back on Install Wizard
 Key: AMBARI-18111
 URL: https://issues.apache.org/jira/browse/AMBARI-18111
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.4.0
Reporter: Jaimin D Jetly
Assignee: Jaimin D Jetly
Priority: Critical
 Fix For: 2.4.0






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

[jira] [Commented] (AMBARI-18070) Calculation of versionAdvertised in is incorrect in metainfo.xml when parent is false and current ComponentInfo is true

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18070:
-

FAILURE: Integrated in Ambari-trunk-Commit #5503 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5503/])
AMBARI-18070. Calculation of versionAdvertised in is incorrect in (afernandez: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=a4a0ca0b414fa9f30e1b3c4405d283c666c41010])
* 
ambari-server/src/main/java/org/apache/ambari/server/stack/ComponentModule.java
* ambari-server/src/main/java/org/apache/ambari/server/state/ComponentInfo.java
* ambari-server/src/test/resources/stacks/HDP/2.2.0/services/HDFS/metainfo.xml
* ambari-server/src/main/resources/common-services/ATLAS/0.7.0.2.5/metainfo.xml
* 
ambari-server/src/test/java/org/apache/ambari/server/stack/ComponentModuleTest.java


> Calculation of versionAdvertised in is incorrect in metainfo.xml when parent 
> is false and current ComponentInfo is true
> ---
>
> Key: AMBARI-18070
> URL: https://issues.apache.org/jira/browse/AMBARI-18070
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18070.patch
>
>
> Fresh install of HDP 2.5 does not have a version for ATLAS_SERVER or 
> ATLAS_CLIENT in the database (hostcomponentstate table) because ATLAS has 
> advertise_version as "false".
> Atlas in common-services for has the following,
> 0.1.0.2.3 has versionAdvertised=false
> 0.7.0.2.5 has versionAdvertised=true
> However, the current logic in ComponentModule always take the value of the 
> parent, which is incorrect.
> To fix this, if the current component has false, then take the value of the 
> parent.
> The ideal way to do this is to use another variable (a string) to read from 
> the xml file so we can store "true", "false", null. If that variable is null, 
> then inherit from the parent.



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

[jira] [Updated] (AMBARI-16278) Give more time for HBase system tables to be assigned

[Ted Yu (JIRA)]

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

Ted Yu updated AMBARI-16278:

Description: 
We have observed extended cluster downtime due to HBase system tables not being 
assigned at cluster start up.

The default values for the following two parameters are too low:

hbase.regionserver.executor.openregion.threads (default: 3)
hbase.master.namespace.init.timeout (default: 30)

We set hbase.regionserver.executor.openregion.threads=200 and 
hbase.master.namespace.init.timeout=240 in some case to work around 
HBASE-14190.

Ambari can use 20 for hbase.regionserver.executor.openregion.threads and 
240 for hbase.master.namespace.init.timeout as default value.

  was:
We have observed extended cluster downtime due to HBase system tables not being 
assigned at cluster start up.

The default values for the following two parameters are too low:

hbase.regionserver.executor.openregion.threads (default: 3)
hbase.master.namespace.init.timeout (default: 30)

We set hbase.regionserver.executor.openregion.threads=200 and 
hbase.master.namespace.init.timeout=240 in some case to work around 
HBASE-14190.


Ambari can use 20 for hbase.regionserver.executor.openregion.threads and 
240 for hbase.master.namespace.init.timeout as default value.


> Give more time for HBase system tables to be assigned
> -
>
> Key: AMBARI-16278
> URL: https://issues.apache.org/jira/browse/AMBARI-16278
> Project: Ambari
>  Issue Type: Improvement
>Reporter: Ted Yu
>
> We have observed extended cluster downtime due to HBase system tables not 
> being assigned at cluster start up.
> The default values for the following two parameters are too low:
> hbase.regionserver.executor.openregion.threads (default: 3)
> hbase.master.namespace.init.timeout (default: 30)
> We set hbase.regionserver.executor.openregion.threads=200 and 
> hbase.master.namespace.init.timeout=240 in some case to work around 
> HBASE-14190.
> Ambari can use 20 for hbase.regionserver.executor.openregion.threads and 
> 240 for hbase.master.namespace.init.timeout as default value.



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

[jira] [Updated] (AMBARI-17346) Dependent components should be shutdown before stopping hdfs

[Ted Yu (JIRA)]

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

Ted Yu updated AMBARI-17346:

Description: 
Sometimes admin shuts down hdfs first, then hbase. 

By the time hbase is shutdown, no data can be persisted (including metadata). 
This results in large number of inconsistencies when hbase cluster is brought 
back up.


Before hdfs is shutdown, the components dependent on hdfs should be shutdown 
first.

  was:
Sometimes admin shuts down hdfs first, then hbase. 

By the time hbase is shutdown, no data can be persisted (including metadata). 
This results in large number of inconsistencies when hbase cluster is brought 
back up.

Before hdfs is shutdown, the components dependent on hdfs should be shutdown 
first.


> Dependent components should be shutdown before stopping hdfs
> 
>
> Key: AMBARI-17346
> URL: https://issues.apache.org/jira/browse/AMBARI-17346
> Project: Ambari
>  Issue Type: Bug
>Reporter: Ted Yu
>
> Sometimes admin shuts down hdfs first, then hbase. 
> By the time hbase is shutdown, no data can be persisted (including metadata). 
> This results in large number of inconsistencies when hbase cluster is brought 
> back up.
> Before hdfs is shutdown, the components dependent on hdfs should be shutdown 
> first.



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

[jira] [Updated] (AMBARI-18110) Ambari unit tests for HAWQ are not being called

[Lav Jain (JIRA)]

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

Lav Jain updated AMBARI-18110:
--
Status: In Progress  (was: Patch Available)

> Ambari unit tests for HAWQ are not being called
> ---
>
> Key: AMBARI-18110
> URL: https://issues.apache.org/jira/browse/AMBARI-18110
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.4.0
>Reporter: Lav Jain
> Fix For: 2.4.0
>
> Attachments: AMBARI-18110.patch, AMBARI-18110.v2.patch
>
>
> Ambari build jobs are not running the unit tests for HAWQ.
> HAWQ (and PXF) unit tests in the new common-services directory under test is 
> being ignored during maven's test phase.



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

[jira] [Updated] (AMBARI-18110) Ambari unit tests for HAWQ are not being called

[Lav Jain (JIRA)]

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

Lav Jain updated AMBARI-18110:
--
Fix Version/s: trunk
   Status: Patch Available  (was: In Progress)

> Ambari unit tests for HAWQ are not being called
> ---
>
> Key: AMBARI-18110
> URL: https://issues.apache.org/jira/browse/AMBARI-18110
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.4.0
>Reporter: Lav Jain
>Assignee: Lav Jain
> Fix For: trunk, 2.4.0
>
> Attachments: AMBARI-18110.patch, AMBARI-18110.v2.patch
>
>
> Ambari build jobs are not running the unit tests for HAWQ.
> HAWQ (and PXF) unit tests in the new common-services directory under test is 
> being ignored during maven's test phase.



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

[jira] [Updated] (AMBARI-18110) Ambari unit tests for HAWQ are not being called

[Lav Jain (JIRA)]

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

Lav Jain updated AMBARI-18110:
--
Attachment: AMBARI-18110.v2.patch

> Ambari unit tests for HAWQ are not being called
> ---
>
> Key: AMBARI-18110
> URL: https://issues.apache.org/jira/browse/AMBARI-18110
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.4.0
>Reporter: Lav Jain
> Fix For: trunk, 2.4.0
>
> Attachments: AMBARI-18110.patch, AMBARI-18110.v2.patch
>
>
> Ambari build jobs are not running the unit tests for HAWQ.
> HAWQ (and PXF) unit tests in the new common-services directory under test is 
> being ignored during maven's test phase.



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

[jira] [Assigned] (AMBARI-18110) Ambari unit tests for HAWQ are not being called

[Lav Jain (JIRA)]

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

Lav Jain reassigned AMBARI-18110:
-

Assignee: Lav Jain

> Ambari unit tests for HAWQ are not being called
> ---
>
> Key: AMBARI-18110
> URL: https://issues.apache.org/jira/browse/AMBARI-18110
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.4.0
>Reporter: Lav Jain
>Assignee: Lav Jain
> Fix For: trunk, 2.4.0
>
> Attachments: AMBARI-18110.patch, AMBARI-18110.v2.patch
>
>
> Ambari build jobs are not running the unit tests for HAWQ.
> HAWQ (and PXF) unit tests in the new common-services directory under test is 
> being ignored during maven's test phase.



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

[jira] [Updated] (AMBARI-1) Initial code import

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-1:

Assignee: Owen O'Malley  (was: Jaimin D Jetly)

> Initial code import
> ---
>
> Key: AMBARI-1
> URL: https://issues.apache.org/jira/browse/AMBARI-1
> Project: Ambari
>  Issue Type: Task
>Reporter: Owen O'Malley
>Assignee: Owen O'Malley
> Fix For: 0.1.0
>
>
> Initial code import



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

[jira] [Assigned] (AMBARI-1) Initial code import

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly reassigned AMBARI-1:
---

Assignee: Jaimin D Jetly  (was: Owen O'Malley)

> Initial code import
> ---
>
> Key: AMBARI-1
> URL: https://issues.apache.org/jira/browse/AMBARI-1
> Project: Ambari
>  Issue Type: Task
>Reporter: Owen O'Malley
>Assignee: Jaimin D Jetly
> Fix For: 0.1.0
>
>
> Initial code import



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

[jira] [Commented] (AMBARI-18110) Ambari unit tests for HAWQ are not being called

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18110:


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

{color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

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

This message is automatically generated.

> Ambari unit tests for HAWQ are not being called
> ---
>
> Key: AMBARI-18110
> URL: https://issues.apache.org/jira/browse/AMBARI-18110
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.4.0
>Reporter: Lav Jain
> Fix For: 2.4.0
>
> Attachments: AMBARI-18110.patch
>
>
> Ambari build jobs are not running the unit tests for HAWQ.
> HAWQ (and PXF) unit tests in the new common-services directory under test is 
> being ignored during maven's test phase.



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

[jira] [Commented] (AMBARI-18099) Ranger policies not syncing when Hive-server-Hive2 is installed on a seperate host.

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18099:
-

FAILURE: Integrated in Ambari-trunk-Commit #5502 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5502/])
AMBARI-18099. Ranger policies not syncing when Hive-server-Hive2 is (smohanty: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=c59b056b657f2754d705db279b657dff4217ba09])
* 
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
* 
ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/ranger-hive-security.xml


> Ranger policies not syncing when Hive-server-Hive2 is installed on a seperate 
> host.
> ---
>
> Key: AMBARI-18099
> URL: https://issues.apache.org/jira/browse/AMBARI-18099
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vishal Suvagia
>Assignee: Vishal Suvagia
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18099.1.patch, AMBARI-18099.patch
>
>
> Ranger policies not syncing when Hive-server-Hive2 is installed on a seperate 
> host and is SSL enabled



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

[jira] [Updated] (AMBARI-18070) Calculation of versionAdvertised in is incorrect in metainfo.xml when parent is false and current ComponentInfo is true

[Alejandro Fernandez (JIRA)]

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

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

Pushed to trunk, a4a0ca0b414fa9f30e1b3c4405d283c666c41010
branch-2.4, 5ebdedd3f00cf637013cbd4fd47d867d49542094

> Calculation of versionAdvertised in is incorrect in metainfo.xml when parent 
> is false and current ComponentInfo is true
> ---
>
> Key: AMBARI-18070
> URL: https://issues.apache.org/jira/browse/AMBARI-18070
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18070.patch
>
>
> Fresh install of HDP 2.5 does not have a version for ATLAS_SERVER or 
> ATLAS_CLIENT in the database (hostcomponentstate table) because ATLAS has 
> advertise_version as "false".
> Atlas in common-services for has the following,
> 0.1.0.2.3 has versionAdvertised=false
> 0.7.0.2.5 has versionAdvertised=true
> However, the current logic in ComponentModule always take the value of the 
> parent, which is incorrect.
> To fix this, if the current component has false, then take the value of the 
> parent.
> The ideal way to do this is to use another variable (a string) to read from 
> the xml file so we can store "true", "false", null. If that variable is null, 
> then inherit from the parent.



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

[jira] [Updated] (AMBARI-18070) Calculation of versionAdvertised in is incorrect in metainfo.xml when parent is false and current ComponentInfo is true

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-18070:
-
Status: Patch Available  (was: Open)

> Calculation of versionAdvertised in is incorrect in metainfo.xml when parent 
> is false and current ComponentInfo is true
> ---
>
> Key: AMBARI-18070
> URL: https://issues.apache.org/jira/browse/AMBARI-18070
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18070.patch
>
>
> Fresh install of HDP 2.5 does not have a version for ATLAS_SERVER or 
> ATLAS_CLIENT in the database (hostcomponentstate table) because ATLAS has 
> advertise_version as "false".
> Atlas in common-services for has the following,
> 0.1.0.2.3 has versionAdvertised=false
> 0.7.0.2.5 has versionAdvertised=true
> However, the current logic in ComponentModule always take the value of the 
> parent, which is incorrect.
> To fix this, if the current component has false, then take the value of the 
> parent.
> The ideal way to do this is to use another variable (a string) to read from 
> the xml file so we can store "true", "false", null. If that variable is null, 
> then inherit from the parent.



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

[jira] [Updated] (AMBARI-18070) Calculation of versionAdvertised in is incorrect in metainfo.xml when parent is false and current ComponentInfo is true

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-18070:
-
Attachment: AMBARI-18070.patch

> Calculation of versionAdvertised in is incorrect in metainfo.xml when parent 
> is false and current ComponentInfo is true
> ---
>
> Key: AMBARI-18070
> URL: https://issues.apache.org/jira/browse/AMBARI-18070
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18070.patch
>
>
> Fresh install of HDP 2.5 does not have a version for ATLAS_SERVER or 
> ATLAS_CLIENT in the database (hostcomponentstate table) because ATLAS has 
> advertise_version as "false".
> Atlas in common-services for has the following,
> 0.1.0.2.3 has versionAdvertised=false
> 0.7.0.2.5 has versionAdvertised=true
> However, the current logic in ComponentModule always take the value of the 
> parent, which is incorrect.
> To fix this, if the current component has false, then take the value of the 
> parent.
> The ideal way to do this is to use another variable (a string) to read from 
> the xml file so we can store "true", "false", null. If that variable is null, 
> then inherit from the parent.



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

[jira] [Updated] (AMBARI-18070) Calculation of versionAdvertised in is incorrect in metainfo.xml when parent is false and current ComponentInfo is true

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-18070:
-
Status: Open  (was: Patch Available)

> Calculation of versionAdvertised in is incorrect in metainfo.xml when parent 
> is false and current ComponentInfo is true
> ---
>
> Key: AMBARI-18070
> URL: https://issues.apache.org/jira/browse/AMBARI-18070
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
>
> Fresh install of HDP 2.5 does not have a version for ATLAS_SERVER or 
> ATLAS_CLIENT in the database (hostcomponentstate table) because ATLAS has 
> advertise_version as "false".
> Atlas in common-services for has the following,
> 0.1.0.2.3 has versionAdvertised=false
> 0.7.0.2.5 has versionAdvertised=true
> However, the current logic in ComponentModule always take the value of the 
> parent, which is incorrect.
> To fix this, if the current component has false, then take the value of the 
> parent.
> The ideal way to do this is to use another variable (a string) to read from 
> the xml file so we can store "true", "false", null. If that variable is null, 
> then inherit from the parent.



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

[jira] [Updated] (AMBARI-18070) Calculation of versionAdvertised in is incorrect in metainfo.xml when parent is false and current ComponentInfo is true

[Alejandro Fernandez (JIRA)]

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

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

> Calculation of versionAdvertised in is incorrect in metainfo.xml when parent 
> is false and current ComponentInfo is true
> ---
>
> Key: AMBARI-18070
> URL: https://issues.apache.org/jira/browse/AMBARI-18070
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
>
> Fresh install of HDP 2.5 does not have a version for ATLAS_SERVER or 
> ATLAS_CLIENT in the database (hostcomponentstate table) because ATLAS has 
> advertise_version as "false".
> Atlas in common-services for has the following,
> 0.1.0.2.3 has versionAdvertised=false
> 0.7.0.2.5 has versionAdvertised=true
> However, the current logic in ComponentModule always take the value of the 
> parent, which is incorrect.
> To fix this, if the current component has false, then take the value of the 
> parent.
> The ideal way to do this is to use another variable (a string) to read from 
> the xml file so we can store "true", "false", null. If that variable is null, 
> then inherit from the parent.



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

[jira] [Commented] (AMBARI-18099) Ranger policies not syncing when Hive-server-Hive2 is installed on a seperate host.

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18099:


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

{color:red}-1 patch{color}.  The patch command could not apply the patch.

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

This message is automatically generated.

> Ranger policies not syncing when Hive-server-Hive2 is installed on a seperate 
> host.
> ---
>
> Key: AMBARI-18099
> URL: https://issues.apache.org/jira/browse/AMBARI-18099
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vishal Suvagia
>Assignee: Vishal Suvagia
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18099.1.patch, AMBARI-18099.patch
>
>
> Ranger policies not syncing when Hive-server-Hive2 is installed on a seperate 
> host and is SSL enabled



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

[jira] [Commented] (AMBARI-17285) Custom service repos in repoinfo.xml got overwritten by public VDFs

[Alexander Denissov (JIRA)]

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

Alexander Denissov commented on AMBARI-17285:
-

[~jluniya] -- I'm afraid we can not have this delayed as the fix is critical, 
otherwise HAWQ installation will not work with Ambari 2.4

> Custom service repos in repoinfo.xml got overwritten by public VDFs
> ---
>
> Key: AMBARI-17285
> URL: https://issues.apache.org/jira/browse/AMBARI-17285
> Project: Ambari
>  Issue Type: Bug
>Reporter: Alexander Denissov
>Assignee: Nate Cole
>Priority: Critical
> Fix For: 2.4.0
>
>
> Ambari 2.4 introduced Version Definition Files that break the functionality 
> of adding a custom service repo, since custom services do not have an entry 
> in the public VDF.
> In the case of HAWQ, the plugin is installed on Ambari host and it adds the 
> new repo information to the repoinfo.xml of all available stacks on the file 
> system. Once Ambari cluster creation wizard queries the latest repo info from 
> the public URLs, it will get the info for all stack repos, but not the custom 
> ones. 
> So, the logic should be:
> 1. Use default repoinfo (from file system) as the base
> 2. Query public VDF, if available
> 3. For each entry in public VDF overwrite values in the default repoinfo
> 4. Entries in default repoinfo that do not have corresponding entries in VDF 
> should stay intact
> This way custom services can be added via file edit and the latest 
> information can still be retrieved and applied for the standard stack.



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

[jira] [Commented] (AMBARI-17951) Introduce validation of hostgroup mapping for active/standby namenode

[Amruta Borkar (JIRA)]

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

Amruta Borkar commented on AMBARI-17951:


Thanks Di.

> Introduce validation of hostgroup mapping for active/standby namenode
> -
>
> Key: AMBARI-17951
> URL: https://issues.apache.org/jira/browse/AMBARI-17951
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, blueprints
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-17951-v2, AMBARI-17951-v3.patch, 
> AMBARI-17951-v4.patch
>
>
> Ambari allows user to specify following properties when Namenode HA is 
> enabled, but does not validate for correct mapping.
>   "dfs_ha_initial_namenode_active" : "hostname or hostgroup reference",
>   "dfs_ha_initial_namenode_standby" : "hostname or hostgroup reference”
> If the values for above properties are mentioned incorrectly following 
> exception is thrown and NAMENODE fails to start.
> 2016-07-27 18:54:43,522 WARN  namenode.FSNamesystem 
> (FSNamesystem.java:loadFromDisk(692)) - Encountered exception loading fsimage
> java.io.IOException: NameNode is not formatted.
> at 
> org.apache.hadoop.hdfs.server.namenode.FSImage.recoverTransitionRead(FSImage.java:225)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFSImage(FSNamesystem.java:1015)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:690)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:688)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:752)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:992)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:976)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1686)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1754)



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

[jira] [Updated] (AMBARI-18099) Ranger policies not syncing when Hive-server-Hive2 is installed on a seperate host.

[Jayush Luniya (JIRA)]

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

Jayush Luniya updated AMBARI-18099:
---
Priority: Blocker  (was: Major)

> Ranger policies not syncing when Hive-server-Hive2 is installed on a seperate 
> host.
> ---
>
> Key: AMBARI-18099
> URL: https://issues.apache.org/jira/browse/AMBARI-18099
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vishal Suvagia
>Assignee: Vishal Suvagia
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18099.1.patch, AMBARI-18099.patch
>
>
> Ranger policies not syncing when Hive-server-Hive2 is installed on a seperate 
> host and is SSL enabled



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

[jira] [Commented] (AMBARI-17951) Introduce validation of hostgroup mapping for active/standby namenode

[Di Li (JIRA)]

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

Di Li commented on AMBARI-17951:


Previous trunk builds also failed on test:  
org.apache.ambari.server.controller.AmbariManagementControllerTest.testScheduleSmokeTest

> Introduce validation of hostgroup mapping for active/standby namenode
> -
>
> Key: AMBARI-17951
> URL: https://issues.apache.org/jira/browse/AMBARI-17951
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, blueprints
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-17951-v2, AMBARI-17951-v3.patch, 
> AMBARI-17951-v4.patch
>
>
> Ambari allows user to specify following properties when Namenode HA is 
> enabled, but does not validate for correct mapping.
>   "dfs_ha_initial_namenode_active" : "hostname or hostgroup reference",
>   "dfs_ha_initial_namenode_standby" : "hostname or hostgroup reference”
> If the values for above properties are mentioned incorrectly following 
> exception is thrown and NAMENODE fails to start.
> 2016-07-27 18:54:43,522 WARN  namenode.FSNamesystem 
> (FSNamesystem.java:loadFromDisk(692)) - Encountered exception loading fsimage
> java.io.IOException: NameNode is not formatted.
> at 
> org.apache.hadoop.hdfs.server.namenode.FSImage.recoverTransitionRead(FSImage.java:225)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFSImage(FSNamesystem.java:1015)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:690)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:688)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:752)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:992)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:976)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1686)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1754)



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

[jira] [Updated] (AMBARI-15900) Bulk Delete Support through API

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-15900:
-
Fix Version/s: (was: 2.5.0)
   trunk

> Bulk Delete Support through API
> ---
>
> Key: AMBARI-15900
> URL: https://issues.apache.org/jira/browse/AMBARI-15900
> Project: Ambari
>  Issue Type: Epic
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Ajit Kumar
>Assignee: Ajit Kumar
> Fix For: trunk
>
>
> Currently Ambari API doesn't support bulk delete. Client needs to call delete 
> api multiple times to delete multiple resources. For example, if client has 
> to delete 10 hosts, it will call delete host API 10 times, one for each host. 
> It will be good to have a standard support for bulk delete API



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

[jira] [Commented] (AMBARI-18031) [Grafana] Update HDFS Users dashboard

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18031:
-

FAILURE: Integrated in Ambari-trunk-Commit #5501 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5501/])
AMBARI-18031. [Grafana] Update HDFS Users dashboard. (Prajwal Rao via (yusaku: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=9fd39e3bc81ef672f4141c747f837bb27b7ea915])
* 
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/files/grafana-dashboards/HDP/grafana-hdfs-users.json


> [Grafana] Update HDFS Users dashboard
> -
>
> Key: AMBARI-18031
> URL: https://issues.apache.org/jira/browse/AMBARI-18031
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Prajwal Rao
>Assignee: Prajwal Rao
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18031.patch
>
>
> Update HDFS - Users dashboard to include a link on how-to enable HDFS 
> per-user metrics.



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

[jira] [Updated] (AMBARI-18083) Service and component lists are not cut by max-height

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-18083:
-
Fix Version/s: (was: 2.5.0)
   trunk

> Service and component lists are not cut by max-height
> -
>
> Key: AMBARI-18083
> URL: https://issues.apache.org/jira/browse/AMBARI-18083
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-18083.patch
>
>
> See screenshot attached



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

[jira] [Commented] (AMBARI-17951) Introduce validation of hostgroup mapping for active/standby namenode

[Hudson (JIRA)]

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

Hudson commented on AMBARI-17951:
-

FAILURE: Integrated in Ambari-trunk-Commit #5501 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5501/])
AMBARI-17951: Introduce validation of hostgroup mapping for (dili: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=e1fc6821ddb7dfe9961bb54015d53b619db3b1f2])
* 
ambari-server/src/test/java/org/apache/ambari/server/topology/BlueprintImplTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/topology/BlueprintValidatorImpl.java
* 
ambari-server/src/main/java/org/apache/ambari/server/topology/HostGroupImpl.java
* ambari-server/src/main/java/org/apache/ambari/server/topology/HostGroup.java
* 
ambari-server/src/test/java/org/apache/ambari/server/topology/ClusterTopologyImplTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/topology/ClusterTopologyImpl.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java


> Introduce validation of hostgroup mapping for active/standby namenode
> -
>
> Key: AMBARI-17951
> URL: https://issues.apache.org/jira/browse/AMBARI-17951
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, blueprints
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-17951-v2, AMBARI-17951-v3.patch, 
> AMBARI-17951-v4.patch
>
>
> Ambari allows user to specify following properties when Namenode HA is 
> enabled, but does not validate for correct mapping.
>   "dfs_ha_initial_namenode_active" : "hostname or hostgroup reference",
>   "dfs_ha_initial_namenode_standby" : "hostname or hostgroup reference”
> If the values for above properties are mentioned incorrectly following 
> exception is thrown and NAMENODE fails to start.
> 2016-07-27 18:54:43,522 WARN  namenode.FSNamesystem 
> (FSNamesystem.java:loadFromDisk(692)) - Encountered exception loading fsimage
> java.io.IOException: NameNode is not formatted.
> at 
> org.apache.hadoop.hdfs.server.namenode.FSImage.recoverTransitionRead(FSImage.java:225)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFSImage(FSNamesystem.java:1015)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:690)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:688)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:752)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:992)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:976)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1686)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1754)



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

[jira] [Updated] (AMBARI-18110) Ambari unit tests for HAWQ are not being called

[Lav Jain (JIRA)]

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

Lav Jain updated AMBARI-18110:
--
Fix Version/s: 2.4.0
   Status: Patch Available  (was: Open)

> Ambari unit tests for HAWQ are not being called
> ---
>
> Key: AMBARI-18110
> URL: https://issues.apache.org/jira/browse/AMBARI-18110
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.4.0
>Reporter: Lav Jain
> Fix For: 2.4.0
>
> Attachments: AMBARI-18110.patch
>
>
> Ambari build jobs are not running the unit tests for HAWQ.
> HAWQ (and PXF) unit tests in the new common-services directory under test is 
> being ignored during maven's test phase.



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

[jira] [Updated] (AMBARI-18110) Ambari unit tests for HAWQ are not being called

[Lav Jain (JIRA)]

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

Lav Jain updated AMBARI-18110:
--
Attachment: AMBARI-18110.patch

> Ambari unit tests for HAWQ are not being called
> ---
>
> Key: AMBARI-18110
> URL: https://issues.apache.org/jira/browse/AMBARI-18110
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.4.0
>Reporter: Lav Jain
> Attachments: AMBARI-18110.patch
>
>
> Ambari build jobs are not running the unit tests for HAWQ.
> HAWQ (and PXF) unit tests in the new common-services directory under test is 
> being ignored during maven's test phase.



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

[jira] [Created] (AMBARI-18110) Ambari unit tests for HAWQ are not being called

[Lav Jain (JIRA)]

Lav Jain created AMBARI-18110:
-

 Summary: Ambari unit tests for HAWQ are not being called
 Key: AMBARI-18110
 URL: https://issues.apache.org/jira/browse/AMBARI-18110
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: trunk, 2.4.0
Reporter: Lav Jain


Ambari build jobs are not running the unit tests for HAWQ.

HAWQ (and PXF) unit tests in the new common-services directory under test is 
being ignored during maven's test phase.



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

[jira] [Commented] (AMBARI-18091) Use https url for Spark2 Service check when WireEncryption is enabled

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18091:
-

FAILURE: Integrated in Ambari-trunk-Commit #5500 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5500/])
AMBARI-18091: Fix Spark2 service check failure when WE is enabled (jluniya: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=4e41ec399fdf15da6879feda9cc124eec24f76ef])
* 
ambari-server/src/main/resources/common-services/SPARK2/2.0.0/package/scripts/service_check.py
* 
ambari-server/src/main/resources/common-services/SPARK2/2.0.0/package/scripts/params.py


> Use https url for Spark2 Service check when WireEncryption is enabled
> -
>
> Key: AMBARI-18091
> URL: https://issues.apache.org/jira/browse/AMBARI-18091
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Yesha Vora
>Assignee: Saisai Shao
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18091.patch
>
>
> When Wire encryption is enabled, https://:/ should be used 
> as spark2 history server url. 
> Port 18481 can be used as default port for spark2 History.



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

[jira] [Commented] (AMBARI-18081) EU/RU merges empty storm.topology.submission.notifier.plugin.class which cause service check to fail

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18081:
-

FAILURE: Integrated in Ambari-trunk-Commit #5500 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5500/])
AMBARI-18081. EU/RU merges empty (dlysnichenko: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=bb28c53260fac9be20cd9e99a8fdb6f1b29dff96])
* ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.5.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.5.xml
* ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/config-upgrade.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.4.xml
* ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.4.xml
* ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/config-upgrade.xml
* ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.4.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.5.xml
* ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.4.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml
* ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.5.xml
* ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/config-upgrade.xml
* ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml
* ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.5.xml
* ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/config-upgrade.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.4.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.5.xml
* ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.4.xml


> EU/RU merges empty storm.topology.submission.notifier.plugin.class which 
> cause service check to fail
> 
>
> Key: AMBARI-18081
> URL: https://issues.apache.org/jira/browse/AMBARI-18081
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmytro Grinenko
>Assignee: Dmitry Lysnichenko
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18081.patch
>
>
> *Steps:*
> # Deploy HDP-2.2.9.0 cluster with Ambari 2.2.1.1
> # Upgrade Ambari to 2.4.0.0 (at this point 
> storm.topology.submission.notifier.plugin.class does not exist)
> # Perform EU to HDP-2.4.2.0 (this is where 
> storm.topology.submission.notifier.plugin.class gets added)
> # Perform another EU to 2.5.0.0 and observed same error during Storm service 
> check



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

[jira] [Commented] (AMBARI-18055) service config page load takes long time on cluster with large number of service config versions

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18055:
-

FAILURE: Integrated in Ambari-trunk-Commit #5500 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5500/])
AMBARI-18055. service config page load takes long time on cluster with (jaimin: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=073b09f24b8aff610a23162b63d76b3cb659688d])
* ambari-server/src/main/java/org/apache/ambari/server/state/Cluster.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ServiceConfigVersionResourceProvider.java
* 
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/ServiceConfigDAO.java
* ambari-web/app/utils/ajax/ajax.js
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/ServiceConfigVersionRequest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
* 
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
* 
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ServiceConfigEntity.java
* 
ambari-server/src/test/java/org/apache/ambari/server/orm/dao/ServiceConfigDAOTest.java


> service config page load takes long time on cluster with large number of 
> service config versions
> 
>
> Key: AMBARI-18055
> URL: https://issues.apache.org/jira/browse/AMBARI-18055
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18055.2.patch, AMBARI-18055.patch, 
> AMBARI-18055.trunk.patch
>
>
> It was observed that service config page load time took very long on clusters 
> with 1000 and 4000 config versions. This was mainly because of slowness of 
> below two APIs that are called everytime when user navigates to any service 
> config page
> *1. Get call to get the current service config version for a service along 
> with other dependent services:*
> {code}
> curl --user admin:admin -i  -H "X-Requested-By: ambari" -X GET 
> "http://localhost:8080/api/v1/clusters/c1/configurations/service_config_versions?service_name.in(HIVE,ATLAS,YARN,TEZ,ZOOKEEPER,RANGER,HDFS)_current=true=*"
> {code}
> Above API takes 7-8 seconds when any one of the service in the API has 1000 
> service config versions. As a fix to this issue, Patch uses another 
> namedQuery that precisely queries for only current service config versions of 
> the service rather than all service config versions and then filtering the 
> active ones in the code. With the patch it takes around 100-300ms for the API 
> to complete
> *2. Get call to get metadata for all service config version of a service:*
> {code}
> http://localhost:8080/api/v1/clusters/c1/configurations/service_config_versions?service_name=HDFS=service_config_version,user,hosts,group_id,group_name,is_current,createtime,service_name,service_config_version_note,stack_id,is_cluster_compatible_response=true
> {code}
> It was analyzed that responses of all APIs are sorted by ambari-server either 
> by the sorting parameter specified by user in the API and if not explicitly 
> specifed by the user then default comparator is used for sorting. When 
> default comparator is used, sorting result set takes much longer time. 
> Sorting 1000 service config version took around 6 seconds at [code| 
> https://github.com/apache/ambari/blob/branch-2.4/ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterControllerImpl.java#L204].
>  As a workaround in the patch, I have changed this API to use sorting by 
> appending "=createtime.desc" to the API. After this the API time came 
> down from 6.5 seconds to 500ms for 1000 service config versions. I have 
> created AMBARI-18059 to investigate and work further on this issue. I have 
> also verified that any hosts or service config version API being used by 
> ambari-web that can return large result set uses sortBy parameter in the API. 
> Also created AMBARI-18058 for ambari-web to use pagination for this API.



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

[jira] [Updated] (AMBARI-18099) Ranger policies not syncing when Hive-server-Hive2 is installed on a seperate host.

[Vishal Suvagia (JIRA)]

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

Vishal Suvagia updated AMBARI-18099:

Attachment: AMBARI-18099.1.patch

> Ranger policies not syncing when Hive-server-Hive2 is installed on a seperate 
> host.
> ---
>
> Key: AMBARI-18099
> URL: https://issues.apache.org/jira/browse/AMBARI-18099
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vishal Suvagia
>Assignee: Vishal Suvagia
> Fix For: 2.4.0
>
> Attachments: AMBARI-18099.1.patch, AMBARI-18099.patch
>
>
> Ranger policies not syncing when Hive-server-Hive2 is installed on a seperate 
> host and is SSL enabled



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

[jira] [Commented] (AMBARI-17285) Custom service repos in repoinfo.xml got overwritten by public VDFs

[Jayush Luniya (JIRA)]

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

Jayush Luniya commented on AMBARI-17285:


[~adenissov]
Can this be postponed to a maintenance release of Ambari 2.4? 

> Custom service repos in repoinfo.xml got overwritten by public VDFs
> ---
>
> Key: AMBARI-17285
> URL: https://issues.apache.org/jira/browse/AMBARI-17285
> Project: Ambari
>  Issue Type: Bug
>Reporter: Alexander Denissov
>Assignee: Nate Cole
>Priority: Critical
> Fix For: 2.4.0
>
>
> Ambari 2.4 introduced Version Definition Files that break the functionality 
> of adding a custom service repo, since custom services do not have an entry 
> in the public VDF.
> In the case of HAWQ, the plugin is installed on Ambari host and it adds the 
> new repo information to the repoinfo.xml of all available stacks on the file 
> system. Once Ambari cluster creation wizard queries the latest repo info from 
> the public URLs, it will get the info for all stack repos, but not the custom 
> ones. 
> So, the logic should be:
> 1. Use default repoinfo (from file system) as the base
> 2. Query public VDF, if available
> 3. For each entry in public VDF overwrite values in the default repoinfo
> 4. Entries in default repoinfo that do not have corresponding entries in VDF 
> should stay intact
> This way custom services can be added via file edit and the latest 
> information can still be retrieved and applied for the standard stack.



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

[jira] [Created] (AMBARI-18109) After Enabling NNHA, On restarting HDFS, namenodes are stopped

[Vivek Rathod (JIRA)]

Vivek Rathod created AMBARI-18109:
-

 Summary: After Enabling NNHA, On restarting HDFS, namenodes are 
stopped
 Key: AMBARI-18109
 URL: https://issues.apache.org/jira/browse/AMBARI-18109
 Project: Ambari
  Issue Type: Bug
Affects Versions: 2.4.0
 Environment: ambari-server --hash: 
8f9aa197e2195da95497c8acbc2a39c47431cc6a
Ambari DB: :Oracle
OS: Debian 7
Reporter: Vivek Rathod
Priority: Critical
 Fix For: 2.4.0


STR: 
-> Enable NNHA
-> After NNHA is enabled, there will be a restart icon for HDFS services (is it 
expected)
-> On restarting services requiring restart (from button on Services page), 
restart is successful but both the Namenodes are stopped



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

[jira] [Commented] (AMBARI-18107) Permission denied issue during hive service check

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18107:


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

{color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

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

This message is automatically generated.

> Permission denied issue during hive service check
> -
>
> Key: AMBARI-18107
> URL: https://issues.apache.org/jira/browse/AMBARI-18107
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18107.patch
>
>
> In hive service check we have code for templeton which creates few files 
> like: show_db.post.txt and pig_post.txt. One thing is that these files will 
> not be removed, so next service check should rewrite this files. In case when 
> user changed some permissions/users/umask we will have permission problems 
> like:
> {code}
> /var/lib/ambari-agent/tmp/show_db.post.txt: Permission denied
> {code}



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

[jira] [Commented] (AMBARI-18070) Calculation of versionAdvertised in is incorrect in metainfo.xml when parent is false and current ComponentInfo is true

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18070:


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

{color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

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

This message is automatically generated.

> Calculation of versionAdvertised in is incorrect in metainfo.xml when parent 
> is false and current ComponentInfo is true
> ---
>
> Key: AMBARI-18070
> URL: https://issues.apache.org/jira/browse/AMBARI-18070
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18070.patch
>
>
> Fresh install of HDP 2.5 does not have a version for ATLAS_SERVER or 
> ATLAS_CLIENT in the database (hostcomponentstate table) because ATLAS has 
> advertise_version as "false".
> Atlas in common-services for has the following,
> 0.1.0.2.3 has versionAdvertised=false
> 0.7.0.2.5 has versionAdvertised=true
> However, the current logic in ComponentModule always take the value of the 
> parent, which is incorrect.
> To fix this, if the current component has false, then take the value of the 
> parent.
> The ideal way to do this is to use another variable (a string) to read from 
> the xml file so we can store "true", "false", null. If that variable is null, 
> then inherit from the parent.



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

[jira] [Commented] (AMBARI-18100) Add Kerberos Automation documentation to Ambari source tree so it may be versioned

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18100:


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

{color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

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

This message is automatically generated.

> Add Kerberos Automation documentation to Ambari source tree so it may be 
> versioned 
> ---
>
> Key: AMBARI-18100
> URL: https://issues.apache.org/jira/browse/AMBARI-18100
> Project: Ambari
>  Issue Type: Documentation
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Minor
>  Labels: documentation, kerberos, kerberos_descriptor
> Fix For: 2.4.0
>
> Attachments: AMBARI-18100_branch-2.4_01.patch, 
> AMBARI-18100_trunk_01.patch
>
>
> Add Kerberos Automation documentation to Ambari source tree so it may be 
> versioned.  This documentation should be added as MD (markdown) files to 
> {{.../ambari-server/docs/security/kerberos}}.



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

[jira] [Updated] (AMBARI-18100) Add Kerberos Automation documentation to Ambari source tree so it may be versioned

[Robert Levas (JIRA)]

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

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

> Add Kerberos Automation documentation to Ambari source tree so it may be 
> versioned 
> ---
>
> Key: AMBARI-18100
> URL: https://issues.apache.org/jira/browse/AMBARI-18100
> Project: Ambari
>  Issue Type: Documentation
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Minor
>  Labels: documentation, kerberos, kerberos_descriptor
> Fix For: 2.4.0
>
> Attachments: AMBARI-18100_branch-2.4_01.patch, 
> AMBARI-18100_trunk_01.patch
>
>
> Add Kerberos Automation documentation to Ambari source tree so it may be 
> versioned.  This documentation should be added as MD (markdown) files to 
> {{.../ambari-server/docs/security/kerberos}}.



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

[jira] [Updated] (AMBARI-18100) Add Kerberos Automation documentation to Ambari source tree so it may be versioned

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-18100:
--
Attachment: AMBARI-18100_trunk_01.patch
AMBARI-18100_branch-2.4_01.patch

> Add Kerberos Automation documentation to Ambari source tree so it may be 
> versioned 
> ---
>
> Key: AMBARI-18100
> URL: https://issues.apache.org/jira/browse/AMBARI-18100
> Project: Ambari
>  Issue Type: Documentation
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Minor
>  Labels: documentation, kerberos, kerberos_descriptor
> Fix For: 2.4.0
>
> Attachments: AMBARI-18100_branch-2.4_01.patch, 
> AMBARI-18100_trunk_01.patch
>
>
> Add Kerberos Automation documentation to Ambari source tree so it may be 
> versioned.  This documentation should be added as MD (markdown) files to 
> {{.../ambari-server/docs/security/kerberos}}.



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

[jira] [Updated] (AMBARI-18070) Calculation of versionAdvertised in is incorrect in metainfo.xml when parent is false and current ComponentInfo is true

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-18070:
-
Status: Open  (was: Patch Available)

> Calculation of versionAdvertised in is incorrect in metainfo.xml when parent 
> is false and current ComponentInfo is true
> ---
>
> Key: AMBARI-18070
> URL: https://issues.apache.org/jira/browse/AMBARI-18070
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18070.patch
>
>
> Fresh install of HDP 2.5 does not have a version for ATLAS_SERVER or 
> ATLAS_CLIENT in the database (hostcomponentstate table) because ATLAS has 
> advertise_version as "false".
> Atlas in common-services for has the following,
> 0.1.0.2.3 has versionAdvertised=false
> 0.7.0.2.5 has versionAdvertised=true
> However, the current logic in ComponentModule always take the value of the 
> parent, which is incorrect.
> To fix this, if the current component has false, then take the value of the 
> parent.
> The ideal way to do this is to use another variable (a string) to read from 
> the xml file so we can store "true", "false", null. If that variable is null, 
> then inherit from the parent.



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

[jira] [Updated] (AMBARI-18070) Calculation of versionAdvertised in is incorrect in metainfo.xml when parent is false and current ComponentInfo is true

[Alejandro Fernandez (JIRA)]

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

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

> Calculation of versionAdvertised in is incorrect in metainfo.xml when parent 
> is false and current ComponentInfo is true
> ---
>
> Key: AMBARI-18070
> URL: https://issues.apache.org/jira/browse/AMBARI-18070
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18070.patch
>
>
> Fresh install of HDP 2.5 does not have a version for ATLAS_SERVER or 
> ATLAS_CLIENT in the database (hostcomponentstate table) because ATLAS has 
> advertise_version as "false".
> Atlas in common-services for has the following,
> 0.1.0.2.3 has versionAdvertised=false
> 0.7.0.2.5 has versionAdvertised=true
> However, the current logic in ComponentModule always take the value of the 
> parent, which is incorrect.
> To fix this, if the current component has false, then take the value of the 
> parent.
> The ideal way to do this is to use another variable (a string) to read from 
> the xml file so we can store "true", "false", null. If that variable is null, 
> then inherit from the parent.



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

[jira] [Updated] (AMBARI-18070) Calculation of versionAdvertised in is incorrect in metainfo.xml when parent is false and current ComponentInfo is true

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-18070:
-
Attachment: AMBARI-18070.patch

> Calculation of versionAdvertised in is incorrect in metainfo.xml when parent 
> is false and current ComponentInfo is true
> ---
>
> Key: AMBARI-18070
> URL: https://issues.apache.org/jira/browse/AMBARI-18070
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18070.patch
>
>
> Fresh install of HDP 2.5 does not have a version for ATLAS_SERVER or 
> ATLAS_CLIENT in the database (hostcomponentstate table) because ATLAS has 
> advertise_version as "false".
> Atlas in common-services for has the following,
> 0.1.0.2.3 has versionAdvertised=false
> 0.7.0.2.5 has versionAdvertised=true
> However, the current logic in ComponentModule always take the value of the 
> parent, which is incorrect.
> To fix this, if the current component has false, then take the value of the 
> parent.
> The ideal way to do this is to use another variable (a string) to read from 
> the xml file so we can store "true", "false", null. If that variable is null, 
> then inherit from the parent.



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

[jira] [Updated] (AMBARI-18107) Permission denied issue during hive service check

[Vitaly Brodetskyi (JIRA)]

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

Vitaly Brodetskyi updated AMBARI-18107:
---
Fix Version/s: (was: 2.4.0)
   2.5.0

> Permission denied issue during hive service check
> -
>
> Key: AMBARI-18107
> URL: https://issues.apache.org/jira/browse/AMBARI-18107
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18107.patch
>
>
> In hive service check we have code for templeton which creates few files 
> like: show_db.post.txt and pig_post.txt. One thing is that these files will 
> not be removed, so next service check should rewrite this files. In case when 
> user changed some permissions/users/umask we will have permission problems 
> like:
> {code}
> /var/lib/ambari-agent/tmp/show_db.post.txt: Permission denied
> {code}



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

[jira] [Created] (AMBARI-18108) [BLUEPRINT] hive.metastore.uris contains single entry when deployed with metastore HA enabled

[Michael Harp (JIRA)]

Michael Harp created AMBARI-18108:
-

 Summary: [BLUEPRINT] hive.metastore.uris contains single entry 
when deployed with metastore HA enabled
 Key: AMBARI-18108
 URL: https://issues.apache.org/jira/browse/AMBARI-18108
 Project: Ambari
  Issue Type: Bug
  Components: blueprints
Affects Versions: 2.4.0
Reporter: Michael Harp
Priority: Critical


STR:
1. Deploy using blueprint with Hive HA enabled
2. Verify hive.metastore.uris contains single entry, should contain both 
metastore URIs.



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

[jira] [Updated] (AMBARI-18031) [Grafana] Update HDFS Users dashboard

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-18031:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to trunk and branch-2.4.

> [Grafana] Update HDFS Users dashboard
> -
>
> Key: AMBARI-18031
> URL: https://issues.apache.org/jira/browse/AMBARI-18031
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Prajwal Rao
>Assignee: Prajwal Rao
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18031.patch
>
>
> Update HDFS - Users dashboard to include a link on how-to enable HDFS 
> per-user metrics.



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

[jira] [Commented] (AMBARI-18031) [Grafana] Update HDFS Users dashboard

[Yusaku Sako (JIRA)]

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

Yusaku Sako commented on AMBARI-18031:
--

+1 for the patch.  Hadoop QA failure is not related to this patch as this is 
just an informational text change.

> [Grafana] Update HDFS Users dashboard
> -
>
> Key: AMBARI-18031
> URL: https://issues.apache.org/jira/browse/AMBARI-18031
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Prajwal Rao
>Assignee: Prajwal Rao
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18031.patch
>
>
> Update HDFS - Users dashboard to include a link on how-to enable HDFS 
> per-user metrics.



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

[jira] [Updated] (AMBARI-18107) Permission denied issue during hive service check

[Vitaly Brodetskyi (JIRA)]

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

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

> Permission denied issue during hive service check
> -
>
> Key: AMBARI-18107
> URL: https://issues.apache.org/jira/browse/AMBARI-18107
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18107.patch
>
>
> In hive service check we have code for templeton which creates few files 
> like: show_db.post.txt and pig_post.txt. One thing is that these files will 
> not be removed, so next service check should rewrite this files. In case when 
> user changed some permissions/users/umask we will have permission problems 
> like:
> {code}
> /var/lib/ambari-agent/tmp/show_db.post.txt: Permission denied
> {code}



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

[jira] [Commented] (AMBARI-17951) Introduce validation of hostgroup mapping for active/standby namenode

[Di Li (JIRA)]

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

Di Li commented on AMBARI-17951:


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

> Introduce validation of hostgroup mapping for active/standby namenode
> -
>
> Key: AMBARI-17951
> URL: https://issues.apache.org/jira/browse/AMBARI-17951
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, blueprints
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-17951-v2, AMBARI-17951-v3.patch, 
> AMBARI-17951-v4.patch
>
>
> Ambari allows user to specify following properties when Namenode HA is 
> enabled, but does not validate for correct mapping.
>   "dfs_ha_initial_namenode_active" : "hostname or hostgroup reference",
>   "dfs_ha_initial_namenode_standby" : "hostname or hostgroup reference”
> If the values for above properties are mentioned incorrectly following 
> exception is thrown and NAMENODE fails to start.
> 2016-07-27 18:54:43,522 WARN  namenode.FSNamesystem 
> (FSNamesystem.java:loadFromDisk(692)) - Encountered exception loading fsimage
> java.io.IOException: NameNode is not formatted.
> at 
> org.apache.hadoop.hdfs.server.namenode.FSImage.recoverTransitionRead(FSImage.java:225)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFSImage(FSNamesystem.java:1015)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:690)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:688)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:752)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:992)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:976)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1686)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1754)



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

[jira] [Updated] (AMBARI-18107) Permission denied issue during hive service check

[Vitaly Brodetskyi (JIRA)]

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

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

> Permission denied issue during hive service check
> -
>
> Key: AMBARI-18107
> URL: https://issues.apache.org/jira/browse/AMBARI-18107
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18107.patch
>
>
> In hive service check we have code for templeton which creates few files 
> like: show_db.post.txt and pig_post.txt. One thing is that these files will 
> not be removed, so next service check should rewrite this files. In case when 
> user changed some permissions/users/umask we will have permission problems 
> like:
> {code}
> /var/lib/ambari-agent/tmp/show_db.post.txt: Permission denied
> {code}



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

[jira] [Commented] (AMBARI-18101) Update zeppelin shiro.ini template with ActiveDirectoryGroupRealm info

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18101:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12823081/AMBARI-18101_trunk%2Bbranch-2.4_v2.patch
  against trunk revision .

{color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

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

This message is automatically generated.

> Update zeppelin shiro.ini template with ActiveDirectoryGroupRealm info
> --
>
> Key: AMBARI-18101
> URL: https://issues.apache.org/jira/browse/AMBARI-18101
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18101_trunk+branch-2.4_v1.patch, 
> AMBARI-18101_trunk+branch-2.4_v2.patch
>
>




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

[jira] [Created] (AMBARI-18107) Permission denied issue during hive service check

[Vitaly Brodetskyi (JIRA)]

Vitaly Brodetskyi created AMBARI-18107:
--

 Summary: Permission denied issue during hive service check
 Key: AMBARI-18107
 URL: https://issues.apache.org/jira/browse/AMBARI-18107
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.4.0
Reporter: Vitaly Brodetskyi
Assignee: Vitaly Brodetskyi
Priority: Critical
 Fix For: 2.4.0


In hive service check we have code for templeton which creates few files like: 
show_db.post.txt and pig_post.txt. One thing is that these files will not be 
removed, so next service check should rewrite this files. In case when user 
changed some permissions/users/umask we will have permission problems like:
{code}
/var/lib/ambari-agent/tmp/show_db.post.txt: Permission denied
{code}



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

[jira] [Commented] (AMBARI-18103) Reinstalling or upgrading ambari-server emits a warning

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18103:
-

FAILURE: Integrated in Ambari-trunk-Commit #5499 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5499/])
AMBARI-18103. Reinstalling or upgrading ambari-server emits a warning 
(aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=a7f1231fcdfb0c2529f479058851aa718411b25a])
* ambari-server/src/main/package/rpm/preinstall.sh


> Reinstalling or upgrading ambari-server emits a warning
> ---
>
> Key: AMBARI-18103
> URL: https://issues.apache.org/jira/browse/AMBARI-18103
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-18103.patch
>
>
> cp: cannot stat ‘//var/lib/ambari-server/resources/views/*.jar’: No such 
> file or directory
> 



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

[jira] [Commented] (AMBARI-18098) stack_advisor should recommend AMS cache size and commit frequency

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18098:


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

This message is automatically generated.

> stack_advisor should recommend AMS cache size and commit frequency
> --
>
> Key: AMBARI-18098
> URL: https://issues.apache.org/jira/browse/AMBARI-18098
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-metrics, stacks
>Affects Versions: 2.5.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
> Fix For: 2.5.0
>
> Attachments: AMBARI-18098.patch, cache_size_by_sinks_count.png
>
>
> stack_advisor should recommend AMS cache size and commit frequency depending 
> on cluster size



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

[jira] [Commented] (AMBARI-18091) Use https url for Spark2 Service check when WireEncryption is enabled

[Sumit Mohanty (JIRA)]

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

Sumit Mohanty commented on AMBARI-18091:


Thanks [~jluniya]. Either we were doing it at the same time or I simply forgot 
to commit to trunk.

> Use https url for Spark2 Service check when WireEncryption is enabled
> -
>
> Key: AMBARI-18091
> URL: https://issues.apache.org/jira/browse/AMBARI-18091
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Yesha Vora
>Assignee: Saisai Shao
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18091.patch
>
>
> When Wire encryption is enabled, https://:/ should be used 
> as spark2 history server url. 
> Port 18481 can be used as default port for spark2 History.



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

[jira] [Resolved] (AMBARI-17102) Pig view fails when execute/explain/syntax check in kerberos environment

[Keta Patel (JIRA)]

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

Keta Patel resolved AMBARI-17102.
-
Resolution: Information Provided

> Pig view fails when execute/explain/syntax check in kerberos environment
> 
>
> Key: AMBARI-17102
> URL: https://issues.apache.org/jira/browse/AMBARI-17102
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views, contrib
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
>
> Steps to reproduce the issue:
> 1. Install a cluster containing Pig and Hive services.
> 2. Create a Pig View Instance following the steps from 
> http://docs.hortonworks.com/HDPDocuments/Ambari-2.1.0.0/bk_ambari_views_guide/bk_ambari_views_guide-20150721.pdf
> 3. Go to the Pig View instance and create a new script with some content and 
> save it. I have used the following content in my script:
> A = load '/tmp/passwd' using PigStorage(':');
> 4. Kerberize the Cluster from Admin -> Kerberos page
> 5. Kerberize the ambari-server following the link 
> https://docs.hortonworks.com/HDPDocuments/Ambari-2.1.2.1/bk_Ambari_Security_Guide/content/_optional_set_up_kerberos_for_ambari_server.html
> 6. Make sure to update the Pig View configuration with the correct Settings 
> for "WebHDFS Authentication" and "WebHCat Username". Also ensure that the 
> "Cluster Configuration" is "Custom" with the correct values set for "WebHDFS 
> FileSystem URI*", "WebHCat Hostname" and "WebHCat Port".
> 7. Go to the Pig View instance and open the script created earlier. Click the 
> "Execute" button to run the script.
> 8. The following error shows up:
> java.lang.IllegalArgumentException: Path segment is null
> java.lang.IllegalArgumentException: Path segment is null
>   at 
> com.sun.jersey.api.uri.UriBuilderImpl.appendPath(UriBuilderImpl.java:547)
>   at 
> com.sun.jersey.api.uri.UriBuilderImpl.appendPath(UriBuilderImpl.java:542)
>   at com.sun.jersey.api.uri.UriBuilderImpl.path(UriBuilderImpl.java:267)
>   at com.sun.jersey.api.client.WebResource.path(WebResource.java:390)
>   at 
> org.apache.ambari.view.pig.templeton.client.TempletonApi.checkJob(TempletonApi.java:128)
>   at 
> org.apache.ambari.view.pig.resources.jobs.JobResourceManager.retrieveJobStatus(JobResourceManager.java:245)
>   at 
> org.apache.ambari.view.pig.resources.jobs.JobService.getJob(JobService.java:101)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)



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

[jira] [Commented] (AMBARI-17102) Pig view fails when execute/explain/syntax check in kerberos environment

[Keta Patel (JIRA)]

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

Keta Patel commented on AMBARI-17102:
-

The configuration for Pig View in Kerberized environment is documented in the 
following blog:
https://developer.ibm.com/hadoop/2016/08/08/ambari-pig-view-kerberos-enabled-clusters/

No changes in the code was required for the view to get working, only the 
configuration had to be performed correctly.

> Pig view fails when execute/explain/syntax check in kerberos environment
> 
>
> Key: AMBARI-17102
> URL: https://issues.apache.org/jira/browse/AMBARI-17102
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views, contrib
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
>
> Steps to reproduce the issue:
> 1. Install a cluster containing Pig and Hive services.
> 2. Create a Pig View Instance following the steps from 
> http://docs.hortonworks.com/HDPDocuments/Ambari-2.1.0.0/bk_ambari_views_guide/bk_ambari_views_guide-20150721.pdf
> 3. Go to the Pig View instance and create a new script with some content and 
> save it. I have used the following content in my script:
> A = load '/tmp/passwd' using PigStorage(':');
> 4. Kerberize the Cluster from Admin -> Kerberos page
> 5. Kerberize the ambari-server following the link 
> https://docs.hortonworks.com/HDPDocuments/Ambari-2.1.2.1/bk_Ambari_Security_Guide/content/_optional_set_up_kerberos_for_ambari_server.html
> 6. Make sure to update the Pig View configuration with the correct Settings 
> for "WebHDFS Authentication" and "WebHCat Username". Also ensure that the 
> "Cluster Configuration" is "Custom" with the correct values set for "WebHDFS 
> FileSystem URI*", "WebHCat Hostname" and "WebHCat Port".
> 7. Go to the Pig View instance and open the script created earlier. Click the 
> "Execute" button to run the script.
> 8. The following error shows up:
> java.lang.IllegalArgumentException: Path segment is null
> java.lang.IllegalArgumentException: Path segment is null
>   at 
> com.sun.jersey.api.uri.UriBuilderImpl.appendPath(UriBuilderImpl.java:547)
>   at 
> com.sun.jersey.api.uri.UriBuilderImpl.appendPath(UriBuilderImpl.java:542)
>   at com.sun.jersey.api.uri.UriBuilderImpl.path(UriBuilderImpl.java:267)
>   at com.sun.jersey.api.client.WebResource.path(WebResource.java:390)
>   at 
> org.apache.ambari.view.pig.templeton.client.TempletonApi.checkJob(TempletonApi.java:128)
>   at 
> org.apache.ambari.view.pig.resources.jobs.JobResourceManager.retrieveJobStatus(JobResourceManager.java:245)
>   at 
> org.apache.ambari.view.pig.resources.jobs.JobService.getJob(JobService.java:101)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)



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

[jira] [Assigned] (AMBARI-18081) EU/RU merges empty storm.topology.submission.notifier.plugin.class which cause service check to fail

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko reassigned AMBARI-18081:
---

Assignee: Dmitry Lysnichenko

> EU/RU merges empty storm.topology.submission.notifier.plugin.class which 
> cause service check to fail
> 
>
> Key: AMBARI-18081
> URL: https://issues.apache.org/jira/browse/AMBARI-18081
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmytro Grinenko
>Assignee: Dmitry Lysnichenko
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18081.patch
>
>
> *Steps:*
> # Deploy HDP-2.2.9.0 cluster with Ambari 2.2.1.1
> # Upgrade Ambari to 2.4.0.0 (at this point 
> storm.topology.submission.notifier.plugin.class does not exist)
> # Perform EU to HDP-2.4.2.0 (this is where 
> storm.topology.submission.notifier.plugin.class gets added)
> # Perform another EU to 2.5.0.0 and observed same error during Storm service 
> check



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

[jira] [Updated] (AMBARI-18081) EU/RU merges empty storm.topology.submission.notifier.plugin.class which cause service check to fail

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-18081:

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

Committed
To https://git-wip-us.apache.org/repos/asf/ambari.git
   75fbd64..2a35f04  branch-2.4 -> branch-2.4
   073b09f..bb28c53  trunk -> trunk


> EU/RU merges empty storm.topology.submission.notifier.plugin.class which 
> cause service check to fail
> 
>
> Key: AMBARI-18081
> URL: https://issues.apache.org/jira/browse/AMBARI-18081
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmytro Grinenko
>Assignee: Dmitry Lysnichenko
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18081.patch
>
>
> *Steps:*
> # Deploy HDP-2.2.9.0 cluster with Ambari 2.2.1.1
> # Upgrade Ambari to 2.4.0.0 (at this point 
> storm.topology.submission.notifier.plugin.class does not exist)
> # Perform EU to HDP-2.4.2.0 (this is where 
> storm.topology.submission.notifier.plugin.class gets added)
> # Perform another EU to 2.5.0.0 and observed same error during Storm service 
> check



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

[jira] [Updated] (AMBARI-18055) service config page load takes long time on cluster with large number of service config versions

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-18055:

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

Received +1 on reviewboard.
Patch committed to trunk and branch-2.4

> service config page load takes long time on cluster with large number of 
> service config versions
> 
>
> Key: AMBARI-18055
> URL: https://issues.apache.org/jira/browse/AMBARI-18055
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18055.2.patch, AMBARI-18055.patch, 
> AMBARI-18055.trunk.patch
>
>
> It was observed that service config page load time took very long on clusters 
> with 1000 and 4000 config versions. This was mainly because of slowness of 
> below two APIs that are called everytime when user navigates to any service 
> config page
> *1. Get call to get the current service config version for a service along 
> with other dependent services:*
> {code}
> curl --user admin:admin -i  -H "X-Requested-By: ambari" -X GET 
> "http://localhost:8080/api/v1/clusters/c1/configurations/service_config_versions?service_name.in(HIVE,ATLAS,YARN,TEZ,ZOOKEEPER,RANGER,HDFS)_current=true=*"
> {code}
> Above API takes 7-8 seconds when any one of the service in the API has 1000 
> service config versions. As a fix to this issue, Patch uses another 
> namedQuery that precisely queries for only current service config versions of 
> the service rather than all service config versions and then filtering the 
> active ones in the code. With the patch it takes around 100-300ms for the API 
> to complete
> *2. Get call to get metadata for all service config version of a service:*
> {code}
> http://localhost:8080/api/v1/clusters/c1/configurations/service_config_versions?service_name=HDFS=service_config_version,user,hosts,group_id,group_name,is_current,createtime,service_name,service_config_version_note,stack_id,is_cluster_compatible_response=true
> {code}
> It was analyzed that responses of all APIs are sorted by ambari-server either 
> by the sorting parameter specified by user in the API and if not explicitly 
> specifed by the user then default comparator is used for sorting. When 
> default comparator is used, sorting result set takes much longer time. 
> Sorting 1000 service config version took around 6 seconds at [code| 
> https://github.com/apache/ambari/blob/branch-2.4/ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterControllerImpl.java#L204].
>  As a workaround in the patch, I have changed this API to use sorting by 
> appending "=createtime.desc" to the API. After this the API time came 
> down from 6.5 seconds to 500ms for 1000 service config versions. I have 
> created AMBARI-18059 to investigate and work further on this issue. I have 
> also verified that any hosts or service config version API being used by 
> ambari-web that can return large result set uses sortBy parameter in the API. 
> Also created AMBARI-18058 for ambari-web to use pagination for this API.



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

[jira] [Created] (AMBARI-18106) Service Check Fails for Hive when run through Ambari

[Aravindh Varadharaju (JIRA)]

Aravindh Varadharaju created AMBARI-18106:
-

 Summary: Service Check Fails for Hive when run through Ambari
 Key: AMBARI-18106
 URL: https://issues.apache.org/jira/browse/AMBARI-18106
 Project: Ambari
  Issue Type: Bug
  Components: ambari-agent
Affects Versions: 2.2.2
Reporter: Aravindh Varadharaju
Priority: Minor


When I run Service Check for Hive through Actions Drop down, it fails with the 
error shown below:

  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/alerts/alert_hive_metastore.py",
 line 190, in execute
timeout=int(check_command_timeout) )
  File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
line 154, in __init__
self.env.run()
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
line 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 238, in action_run
tries=self.resource.tries, try_sleep=self.resource.try_sleep)
  File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
line 70, in inner
result = function(command, **kwargs)
  File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
line 92, in checked_call
tries=tries, try_sleep=try_sleep)
  File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
line 140, in _call_wrapper
result = _call(command, **kwargs_copy)
  File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
line 291, in _call
raise Fail(err_msg)
Fail: Execution of 'export 
HIVE_CONF_DIR='/usr/hdp/current/hive-metastore/conf/conf.server' ; hive 
--hiveconf hive.metastore.uris=thrift://hdfs10.internal.shutterfly.com:9083 
--hiveconf hive.metastore.client.connect.retry.delay=1  
   --hiveconf hive.metastore.failure.retries=1 --hiveconf 
hive.metastore.connect.retries=1 --hiveconf 
hive.metastore.client.socket.timeout=14 --hiveconf 
hive.execution.engine=mr -e 'show databases;'' returned 1. WARNING: Use "yarn 
jar" to launch YARN applications.
log4j:ERROR setFile(null,true) call failed.
java.io.FileNotFoundException: /tmp/ambari-qa/hive.log (Permission denied)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:221)
at java.io.FileOutputStream.(FileOutputStream.java:142)
at org.apache.log4j.FileAppender.setFile(FileAppender.java:294)
at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165)
at 
org.apache.log4j.DailyRollingFileAppender.activateOptions(DailyRollingFileAppender.java:223)
at 
org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307)
at 
org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172)
at 
org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104)
at 
org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842)
at 
org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768)
at 
org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:648)
at 
org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:514)
at 
org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580)
at 
org.apache.log4j.PropertyConfigurator.configure(PropertyConfigurator.java:415)
at 
org.apache.hadoop.hive.common.LogUtils.initHiveLog4jDefault(LogUtils.java:127)
at 
org.apache.hadoop.hive.common.LogUtils.initHiveLog4jCommon(LogUtils.java:77)
at 
org.apache.hadoop.hive.common.LogUtils.initHiveLog4j(LogUtils.java:58)
at org.apache.hadoop.hive.cli.CliDriver.run(CliDriver.java:640)
at org.apache.hadoop.hive.cli.CliDriver.main(CliDriver.java:624)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.hadoop.util.RunJar.run(RunJar.java:221)
at org.apache.hadoop.util.RunJar.main(RunJar.java:136)
log4j:ERROR Either File or DatePattern options are not set for appender [DRFA].

Logging initialized using configuration in 
file:/etc/hive/2.4.2.0-258/0/conf.server/hive-log4j.properties
Exception in thread "main" java.lang.RuntimeException: 
java.lang.RuntimeException: java.io.IOException: Permission denied

[jira] [Commented] (AMBARI-18055) service config page load takes long time on cluster with large number of service config versions

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly commented on AMBARI-18055:
-

It seems that Hadoop QA Jenkins Job is failing for some other reason.
I verified that the patch is applicable on both trunk and branch-2.4


> service config page load takes long time on cluster with large number of 
> service config versions
> 
>
> Key: AMBARI-18055
> URL: https://issues.apache.org/jira/browse/AMBARI-18055
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18055.2.patch, AMBARI-18055.patch, 
> AMBARI-18055.trunk.patch
>
>
> It was observed that service config page load time took very long on clusters 
> with 1000 and 4000 config versions. This was mainly because of slowness of 
> below two APIs that are called everytime when user navigates to any service 
> config page
> *1. Get call to get the current service config version for a service along 
> with other dependent services:*
> {code}
> curl --user admin:admin -i  -H "X-Requested-By: ambari" -X GET 
> "http://localhost:8080/api/v1/clusters/c1/configurations/service_config_versions?service_name.in(HIVE,ATLAS,YARN,TEZ,ZOOKEEPER,RANGER,HDFS)_current=true=*"
> {code}
> Above API takes 7-8 seconds when any one of the service in the API has 1000 
> service config versions. As a fix to this issue, Patch uses another 
> namedQuery that precisely queries for only current service config versions of 
> the service rather than all service config versions and then filtering the 
> active ones in the code. With the patch it takes around 100-300ms for the API 
> to complete
> *2. Get call to get metadata for all service config version of a service:*
> {code}
> http://localhost:8080/api/v1/clusters/c1/configurations/service_config_versions?service_name=HDFS=service_config_version,user,hosts,group_id,group_name,is_current,createtime,service_name,service_config_version_note,stack_id,is_cluster_compatible_response=true
> {code}
> It was analyzed that responses of all APIs are sorted by ambari-server either 
> by the sorting parameter specified by user in the API and if not explicitly 
> specifed by the user then default comparator is used for sorting. When 
> default comparator is used, sorting result set takes much longer time. 
> Sorting 1000 service config version took around 6 seconds at [code| 
> https://github.com/apache/ambari/blob/branch-2.4/ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterControllerImpl.java#L204].
>  As a workaround in the patch, I have changed this API to use sorting by 
> appending "=createtime.desc" to the API. After this the API time came 
> down from 6.5 seconds to 500ms for 1000 service config versions. I have 
> created AMBARI-18059 to investigate and work further on this issue. I have 
> also verified that any hosts or service config version API being used by 
> ambari-web that can return large result set uses sortBy parameter in the API. 
> Also created AMBARI-18058 for ambari-web to use pagination for this API.



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

[jira] [Commented] (AMBARI-18091) Use https url for Spark2 Service check when WireEncryption is enabled

[Jayush Luniya (JIRA)]

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

Jayush Luniya commented on AMBARI-18091:


[~sumitmohanty]
I committed the patch to trunk. Noticed your comment and that the patch is in 
2.4 already after committing.

> Use https url for Spark2 Service check when WireEncryption is enabled
> -
>
> Key: AMBARI-18091
> URL: https://issues.apache.org/jira/browse/AMBARI-18091
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Yesha Vora
>Assignee: Saisai Shao
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18091.patch
>
>
> When Wire encryption is enabled, https://:/ should be used 
> as spark2 history server url. 
> Port 18481 can be used as default port for spark2 History.



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

[jira] [Commented] (AMBARI-18091) Use https url for Spark2 Service check when WireEncryption is enabled

[Jayush Luniya (JIRA)]

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

Jayush Luniya commented on AMBARI-18091:


Trunk
commit 4e41ec399fdf15da6879feda9cc124eec24f76ef
Author: Jayush Luniya 
Date:   Wed Aug 10 09:39:31 2016 -0700

AMBARI-18091: Fix Spark2 service check failure when WE is enabled (Saisai 
Shao via jluniya)

[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 1:47.726s
[INFO] Finished at: Wed Aug 10 09:36:57 PDT 2016
[INFO] Final Memory: 61M/939M
[INFO] 

> Use https url for Spark2 Service check when WireEncryption is enabled
> -
>
> Key: AMBARI-18091
> URL: https://issues.apache.org/jira/browse/AMBARI-18091
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Yesha Vora
>Assignee: Saisai Shao
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18091.patch
>
>
> When Wire encryption is enabled, https://:/ should be used 
> as spark2 history server url. 
> Port 18481 can be used as default port for spark2 History.



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

[jira] [Updated] (AMBARI-18098) stack_advisor should recommend AMS cache size and commit frequency

[Dmytro Sen (JIRA)]

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

Dmytro Sen updated AMBARI-18098:

Attachment: cache_size_by_sinks_count.png

> stack_advisor should recommend AMS cache size and commit frequency
> --
>
> Key: AMBARI-18098
> URL: https://issues.apache.org/jira/browse/AMBARI-18098
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-metrics, stacks
>Affects Versions: 2.5.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
> Fix For: 2.5.0
>
> Attachments: AMBARI-18098.patch, cache_size_by_sinks_count.png
>
>
> stack_advisor should recommend AMS cache size and commit frequency depending 
> on cluster size



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

[jira] [Updated] (AMBARI-18101) Update zeppelin shiro.ini template with ActiveDirectoryGroupRealm info

[Renjith Kamath (JIRA)]

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

Renjith Kamath updated AMBARI-18101:

Attachment: AMBARI-18101_trunk+branch-2.4_v2.patch

> Update zeppelin shiro.ini template with ActiveDirectoryGroupRealm info
> --
>
> Key: AMBARI-18101
> URL: https://issues.apache.org/jira/browse/AMBARI-18101
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18101_trunk+branch-2.4_v1.patch, 
> AMBARI-18101_trunk+branch-2.4_v2.patch
>
>




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

[jira] [Updated] (AMBARI-18083) Service and component lists are not cut by max-height

[Oleg Nechiporenko (JIRA)]

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

Oleg Nechiporenko updated AMBARI-18083:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Service and component lists are not cut by max-height
> -
>
> Key: AMBARI-18083
> URL: https://issues.apache.org/jira/browse/AMBARI-18083
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18083.patch
>
>
> See screenshot attached



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

[jira] [Comment Edited] (AMBARI-18083) Service and component lists are not cut by max-height

[Oleg Nechiporenko (JIRA)]

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

Oleg Nechiporenko edited comment on AMBARI-18083 at 8/10/16 4:03 PM:
-

{noformat}
[INFO] Ambari Web . SUCCESS [01:20 min]
[INFO] Ambari Server .. FAILURE [  01:26 h]
{noformat}


was (Author: onechiporenko):
{noformat}
INFO] Ambari Web . SUCCESS [01:20 min]
[INFO] Ambari Server .. FAILURE [  01:26 h]
{noformat}

> Service and component lists are not cut by max-height
> -
>
> Key: AMBARI-18083
> URL: https://issues.apache.org/jira/browse/AMBARI-18083
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18083.patch
>
>
> See screenshot attached



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

[jira] [Commented] (AMBARI-18083) Service and component lists are not cut by max-height

[Oleg Nechiporenko (JIRA)]

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

Oleg Nechiporenko commented on AMBARI-18083:


{noformat}
INFO] Ambari Web . SUCCESS [01:20 min]
[INFO] Ambari Server .. FAILURE [  01:26 h]
{noformat}

> Service and component lists are not cut by max-height
> -
>
> Key: AMBARI-18083
> URL: https://issues.apache.org/jira/browse/AMBARI-18083
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18083.patch
>
>
> See screenshot attached



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

[jira] [Commented] (AMBARI-18088) Ranger service check does not run during Express Upgrade

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18088:
-

FAILURE: Integrated in Ambari-trunk-Commit #5498 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5498/])
AMBARI-18088 - Ranger service check does not run during Express Upgrade 
(jhurley: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=37e1f5ab2e75c034d9f8b6ff1906f5842b142231])
* 
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.4.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.5.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.5.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.5.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.4.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.4.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.2.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml


> Ranger service check does not run during Express Upgrade
> 
>
> Key: AMBARI-18088
> URL: https://issues.apache.org/jira/browse/AMBARI-18088
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18088.patch
>
>
> As part of the changes to include Service checks for all services during 
> upgrade (AMBARI-17648), found that Ranger service check is not included.



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

[jira] [Commented] (AMBARI-18096) YARN config to fetch new HDFS delegation tokens is not enabled

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18096:
-

FAILURE: Integrated in Ambari-trunk-Commit #5498 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5498/])
AMBARI-18096. YARN config to fetch new HDFS delegation tokens is not (smohanty: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=84609068e03bf0d9a97be15dcc192d734970e512])
* ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py


> YARN config to fetch new HDFS delegation tokens is not enabled
> --
>
> Key: AMBARI-18096
> URL: https://issues.apache.org/jira/browse/AMBARI-18096
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.4.0
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18096.patch
>
>
> Scenario:
> * set dfs.namenode.delegation.token.max-lifetime=4320 and 
> dfs.namenode.delegation.token.renew-interval=2880
> * Start 2 Spark long running Streaming applications (Yarn-client mode : 
> 1470217907078_0001 , Yarn-cluster mode : 1470217907078_0002)
> * Let these application run for ~2 days
> * When application is running, we are injecting RM failover and NN failover 
> randomly.
> * Kill the application
> * try to get application logs for above long running apps.
> Noticing below error message where it complaints that log aggregation service 
> failed to init. Thus, app logs could not be gathered. 
> {code:title=yarn-yarn-nodemanager-u14-spark-lr1-2}
> 2016-08-03 23:01:05,568 ERROR logaggregation.LogAggregationService 
> (LogAggregationService.java:run(338)) - Failed to setup application log 
> directory for application_1470217907078_0002
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.token.SecretManager$InvalidToken):
>  token (HDFS_DELEGATION_TOKEN token 4 for hrt_qa) can't be found in cache
> at org.apache.hadoop.ipc.Client.getRpcResponse(Client.java:1552)
> at org.apache.hadoop.ipc.Client.call(Client.java:1496)
> at org.apache.hadoop.ipc.Client.call(Client.java:1396)
> at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:233)
> at com.sun.proxy.$Proxy86.getFileInfo(Unknown Source)
> at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:816)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:278)
> at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:194)
> at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:176)
> at com.sun.proxy.$Proxy87.getFileInfo(Unknown Source)
> at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:2158)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem$25.doCall(DistributedFileSystem.java:1423)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem$25.doCall(DistributedFileSystem.java:1419)
> at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1419)
> at 
> org.apache.hadoop.yarn.server.nodemanager.containermanager.logaggregation.LogAggregationService.checkExists(LogAggregationService.java:286)
> at 
> org.apache.hadoop.yarn.server.nodemanager.containermanager.logaggregation.LogAggregationService.access$100(LogAggregationService.java:67)
> at 
> org.apache.hadoop.yarn.server.nodemanager.containermanager.logaggregation.LogAggregationService$1.run(LogAggregationService.java:314)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1724)
> at 
> org.apache.hadoop.yarn.server.nodemanager.containermanager.logaggregation.LogAggregationService.createAppDir(LogAggregationService.java:299)
> at 
> org.apache.hadoop.yarn.server.nodemanager.containermanager.logaggregation.LogAggregationService.initAppAggregator(LogAggregationService.java:405)
> at 
> 

[jira] [Commented] (AMBARI-18105) JS error on opening Select Alert Group Definitions dialog

[Andrii Tkach (JIRA)]

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

Andrii Tkach commented on AMBARI-18105:
---

+1 for the patch

> JS error on opening Select Alert Group Definitions dialog
> -
>
> Key: AMBARI-18105
> URL: https://issues.apache.org/jira/browse/AMBARI-18105
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18105.patch
>
>
> {noformat}
> Uncaught Error: assertion failed: Emptying a view in the inBuffer state is 
> not allowed and should not happen under normal circumstances. Most likely 
> there is a bug in your application. This may be due to excessive property 
> change notifications.
> {noformat}



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

[jira] [Updated] (AMBARI-18105) JS error on opening Select Alert Group Definitions dialog

[Oleg Nechiporenko (JIRA)]

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

Oleg Nechiporenko updated AMBARI-18105:
---
Attachment: AMBARI-18105.patch

> JS error on opening Select Alert Group Definitions dialog
> -
>
> Key: AMBARI-18105
> URL: https://issues.apache.org/jira/browse/AMBARI-18105
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18105.patch
>
>
> {noformat}
> Uncaught Error: assertion failed: Emptying a view in the inBuffer state is 
> not allowed and should not happen under normal circumstances. Most likely 
> there is a bug in your application. This may be due to excessive property 
> change notifications.
> {noformat}



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

[jira] [Updated] (AMBARI-18105) JS error on opening Select Alert Group Definitions dialog

[Oleg Nechiporenko (JIRA)]

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

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

Patch added

> JS error on opening Select Alert Group Definitions dialog
> -
>
> Key: AMBARI-18105
> URL: https://issues.apache.org/jira/browse/AMBARI-18105
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18105.patch
>
>
> {noformat}
> Uncaught Error: assertion failed: Emptying a view in the inBuffer state is 
> not allowed and should not happen under normal circumstances. Most likely 
> there is a bug in your application. This may be due to excessive property 
> change notifications.
> {noformat}



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

[jira] [Commented] (AMBARI-18105) JS error on opening Select Alert Group Definitions dialog

[Oleg Nechiporenko (JIRA)]

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

Oleg Nechiporenko commented on AMBARI-18105:


29246 tests complete (26 seconds)
  154 tests pending


> JS error on opening Select Alert Group Definitions dialog
> -
>
> Key: AMBARI-18105
> URL: https://issues.apache.org/jira/browse/AMBARI-18105
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18105.patch
>
>
> {noformat}
> Uncaught Error: assertion failed: Emptying a view in the inBuffer state is 
> not allowed and should not happen under normal circumstances. Most likely 
> there is a bug in your application. This may be due to excessive property 
> change notifications.
> {noformat}



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

[jira] [Created] (AMBARI-18105) JS error on opening Select Alert Group Definitions dialog

[Oleg Nechiporenko (JIRA)]

Oleg Nechiporenko created AMBARI-18105:
--

 Summary: JS error on opening Select Alert Group Definitions dialog
 Key: AMBARI-18105
 URL: https://issues.apache.org/jira/browse/AMBARI-18105
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.4.0
Reporter: Oleg Nechiporenko
Assignee: Oleg Nechiporenko
Priority: Blocker
 Fix For: 2.4.0


{noformat}
Uncaught Error: assertion failed: Emptying a view in the inBuffer state is not 
allowed and should not happen under normal circumstances. Most likely there is 
a bug in your application. This may be due to excessive property change 
notifications.
{noformat}



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

[jira] [Commented] (AMBARI-18103) Reinstalling or upgrading ambari-server emits a warning

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk commented on AMBARI-18103:
--

Ran UT manually:
{noformat}
[INFO] Rat check: Summary of files. Unapproved: 0 unknown: 0 generated: 0 
approved: 148 licence.
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Ambari Views .. SUCCESS [7.111s]
[INFO] Ambari Metrics Common . SUCCESS [1.739s]
[INFO] Ambari Server . SUCCESS [1:33.577s]
[INFO] Ambari Agent .. SUCCESS [13.770s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 1:57.086s
[INFO] Finished at: Wed Aug 10 17:46:59 EEST 2016
[INFO] Final Memory: 70M/1206M
[INFO] 
{noformat}

> Reinstalling or upgrading ambari-server emits a warning
> ---
>
> Key: AMBARI-18103
> URL: https://issues.apache.org/jira/browse/AMBARI-18103
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-18103.patch
>
>
> cp: cannot stat ‘//var/lib/ambari-server/resources/views/*.jar’: No such 
> file or directory
> 



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

[jira] [Updated] (AMBARI-18103) Reinstalling or upgrading ambari-server emits a warning

[Andrew Onischuk (JIRA)]

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

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

Committed to trunk

> Reinstalling or upgrading ambari-server emits a warning
> ---
>
> Key: AMBARI-18103
> URL: https://issues.apache.org/jira/browse/AMBARI-18103
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-18103.patch
>
>
> cp: cannot stat ‘//var/lib/ambari-server/resources/views/*.jar’: No such 
> file or directory
> 



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

[jira] [Updated] (AMBARI-18103) Reinstalling or upgrading ambari-server emits a warning

[Andrew Onischuk (JIRA)]

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

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

> Reinstalling or upgrading ambari-server emits a warning
> ---
>
> Key: AMBARI-18103
> URL: https://issues.apache.org/jira/browse/AMBARI-18103
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-18103.patch
>
>
> cp: cannot stat ‘//var/lib/ambari-server/resources/views/*.jar’: No such 
> file or directory
> 



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

[jira] [Updated] (AMBARI-18103) Reinstalling or upgrading ambari-server emits a warning

[Andrew Onischuk (JIRA)]

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

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

> Reinstalling or upgrading ambari-server emits a warning
> ---
>
> Key: AMBARI-18103
> URL: https://issues.apache.org/jira/browse/AMBARI-18103
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-18103.patch
>
>
> cp: cannot stat ‘//var/lib/ambari-server/resources/views/*.jar’: No such 
> file or directory
> 



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

[jira] [Created] (AMBARI-18103) Reinstalling or upgrading ambari-server emits a warning

[Andrew Onischuk (JIRA)]

Andrew Onischuk created AMBARI-18103:


 Summary: Reinstalling or upgrading ambari-server emits a warning
 Key: AMBARI-18103
 URL: https://issues.apache.org/jira/browse/AMBARI-18103
 Project: Ambari
  Issue Type: Bug
Reporter: Andrew Onischuk
Assignee: Andrew Onischuk
 Fix For: 3.0.0
 Attachments: AMBARI-18103.patch


cp: cannot stat ‘//var/lib/ambari-server/resources/views/*.jar’: No such 
file or directory






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

[jira] [Created] (AMBARI-18102) Preinstall check for blueprint-based cluster deployment

[Di Li (JIRA)]

Di Li created AMBARI-18102:
--

 Summary: Preinstall check for blueprint-based cluster deployment
 Key: AMBARI-18102
 URL: https://issues.apache.org/jira/browse/AMBARI-18102
 Project: Ambari
  Issue Type: New Feature
  Components: ambari-server
Affects Versions: trunk
Reporter: Di Li
 Fix For: trunk
 Attachments: Installation_precheck_blueprint_design_doc.pdf, 
Installation_precheck_blueprint_use_cases.pdf

There are limited validations against blueprint and the cluster creation 
template when a user deploys a cluster via blueprint. 

More host level checks before actually deploying the cluster would be 
beneficial as users do not need to sit thru the deploy only to find out errors 
at the end. Users can rerun the checks multiple times after fixing issues on 
given hosts or correcting configuration values in the blueprint.

This JIRA proposes a Python script based design including a central script on 
the Ambari server and a Custom Action script on each Ambari Agent node to run 
checks based on property values defined in the blueprint. Right now the checks 
are checking ports and directories.



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

[jira] [Updated] (AMBARI-18102) Preinstall check for blueprint-based cluster deployment

[Di Li (JIRA)]

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

Di Li updated AMBARI-18102:
---
Attachment: Installation_precheck_blueprint_design_doc.pdf
Installation_precheck_blueprint_use_cases.pdf

> Preinstall check for blueprint-based cluster deployment
> ---
>
> Key: AMBARI-18102
> URL: https://issues.apache.org/jira/browse/AMBARI-18102
> Project: Ambari
>  Issue Type: New Feature
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Di Li
> Fix For: trunk
>
> Attachments: Installation_precheck_blueprint_design_doc.pdf, 
> Installation_precheck_blueprint_use_cases.pdf
>
>
> There are limited validations against blueprint and the cluster creation 
> template when a user deploys a cluster via blueprint. 
> More host level checks before actually deploying the cluster would be 
> beneficial as users do not need to sit thru the deploy only to find out 
> errors at the end. Users can rerun the checks multiple times after fixing 
> issues on given hosts or correcting configuration values in the blueprint.
> This JIRA proposes a Python script based design including a central script on 
> the Ambari server and a Custom Action script on each Ambari Agent node to run 
> checks based on property values defined in the blueprint. Right now the 
> checks are checking ports and directories.



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

[jira] [Commented] (AMBARI-18101) Update zeppelin shiro.ini template with ActiveDirectoryGroupRealm info

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18101:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12823052/AMBARI-18101_trunk%2Bbranch-2.4_v1.patch
  against trunk revision .

{color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

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

This message is automatically generated.

> Update zeppelin shiro.ini template with ActiveDirectoryGroupRealm info
> --
>
> Key: AMBARI-18101
> URL: https://issues.apache.org/jira/browse/AMBARI-18101
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18101_trunk+branch-2.4_v1.patch
>
>




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

[jira] [Updated] (AMBARI-18101) Update zeppelin shiro.ini template with ActiveDirectoryGroupRealm info

[Renjith Kamath (JIRA)]

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

Renjith Kamath updated AMBARI-18101:

Attachment: AMBARI-18101_trunk+branch-2.4_v1.patch

> Update zeppelin shiro.ini template with ActiveDirectoryGroupRealm info
> --
>
> Key: AMBARI-18101
> URL: https://issues.apache.org/jira/browse/AMBARI-18101
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-18101_trunk+branch-2.4_v1.patch
>
>




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

[jira] [Updated] (AMBARI-18101) Update zeppelin shiro.ini template with ActiveDirectoryGroupRealm info

[Renjith Kamath (JIRA)]

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

Renjith Kamath updated AMBARI-18101:

Status: Patch Available  (was: Open)

> Update zeppelin shiro.ini template with ActiveDirectoryGroupRealm info
> --
>
> Key: AMBARI-18101
> URL: https://issues.apache.org/jira/browse/AMBARI-18101
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
>Priority: Critical
> Fix For: 2.4.0
>
>




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

[jira] [Updated] (AMBARI-18101) Update zeppelin shiro.ini template with ActiveDirectoryGroupRealm info

[Renjith Kamath (JIRA)]

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

Renjith Kamath updated AMBARI-18101:

Priority: Critical  (was: Blocker)

> Update zeppelin shiro.ini template with ActiveDirectoryGroupRealm info
> --
>
> Key: AMBARI-18101
> URL: https://issues.apache.org/jira/browse/AMBARI-18101
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
>Priority: Critical
> Fix For: 2.4.0
>
>




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