[jira] [Commented] (AMBARI-18073) Text change of Audit to DB Removal during upgrade for Ranger
[ https://issues.apache.org/jira/browse/AMBARI-18073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414769#comment-15414769 ] Hudson commented on AMBARI-18073: - FAILURE: Integrated in Ambari-trunk-Commit #5493 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5493/]) AMBARI-18073. Text change of Audit to DB Removal during upgrade for (mugdha: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=a427863166da1be15ba39e40fa24db9c24fbb7b6]) * ambari-server/src/main/java/org/apache/ambari/server/checks/CheckDescription.java * ambari-server/src/main/resources/common-services/RANGER/0.5.0/configuration/ranger-admin-site.xml > Text change of Audit to DB Removal during upgrade for Ranger > > > Key: AMBARI-18073 > URL: https://issues.apache.org/jira/browse/AMBARI-18073 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Mugdha Varadkar >Assignee: Mugdha Varadkar > Fix For: 2.4.0 > > Attachments: AMBARI-18073.patch > > > Changing text during upgrade of Ranger for Audit to DB removal -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17997) When i enable kerberos,MapReduce2 and Yarn both faied to start.
[
https://issues.apache.org/jira/browse/AMBARI-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414770#comment-15414770
]
niushuo commented on AMBARI-17997:
--
I have fixed this problem,Just check your dir of "/home/",there could be some
wrong about the dir,change the Group or ID,
The erro becauses of the user also.
> When i enable kerberos,MapReduce2 and Yarn both faied to start.
> ---
>
> Key: AMBARI-17997
> URL: https://issues.apache.org/jira/browse/AMBARI-17997
> Project: Ambari
> Issue Type: Bug
> Components: security
>Affects Versions: 2.2.2
> Environment: Centos6.7
>Reporter: niushuo
>
> No kerberos,the cluster was OK!But,When I enable kerberos,MapReduce2 and Yarn
> both faied to start.The log like this,how can I do to fix the problem?
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/historyserver.py",
> line 182, in
> HistoryServer().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 219, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/historyserver.py",
> line 92, in start
> self.configure(env) # FOR SECURITY
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/historyserver.py",
> line 55, in configure
> yarn(name="historyserver")
> 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/YARN/2.1.0.2.0/package/scripts/yarn.py",
> line 71, in yarn
> recursive_chmod=True
> 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/libraries/providers/hdfs_resource.py",
> line 463, in action_create_on_execute
> self.action_delayed("create")
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 460, in action_delayed
> self.get_hdfs_resource_executor().action_delayed(action_name, self)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 250, in action_delayed
> self._assert_valid()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 234, in _assert_valid
> self.target_status = self._get_file_status(target)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 295, in _get_file_status
> list_status = self.util.run_command(target, 'GETFILESTATUS',
> method='GET', ignore_status_codes=['404'], assertable_result=False)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 195, in run_command
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'curl -sS -L -w
> '%{http_code}' -X GET --negotiate -u :
> 'http://bigdata-32.bigdata:50070/webhdfs/v1/app-logs?op=GETFILESTATUS=hdfs''
> returned status_code=401.
>
>
>
> Error 401 Authentication required
>
> HTTP ERROR 401
> Problem accessing /webhdfs/v1/app-logs. Reason:
> Authentication requiredPowered by
> Jetty://
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMBARI-17998) When I enable Kerberos,the Hive shell faild to access.
[ https://issues.apache.org/jira/browse/AMBARI-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] niushuo resolved AMBARI-17998. -- Resolution: Fixed Fix Version/s: 2.2.2 Nothing but some configuration file should pay attention to. > When I enable Kerberos,the Hive shell faild to access. > -- > > Key: AMBARI-17998 > URL: https://issues.apache.org/jira/browse/AMBARI-17998 > Project: Ambari > Issue Type: Bug > Components: security >Affects Versions: 2.2.2 > Environment: Centos6.7 >Reporter: niushuo > Fix For: 2.2.2 > > > When I enable Kerberos,the serverice of Hive was succeed to start.Bui when I > use the command "hive" to go in the Hive shell,it's show some error,show in > below, > 2016-08-02 21:39:26,620 ERROR [pool-5-thread-183]: server.TThreadPoolServer > (TThreadPoolServer.java:run(296)) - Error occurred during processing of > message. > java.lang.RuntimeException: org.apache.thrift.transport.TTransportException: > Peer indicated failure: GSS initiate failed > at > org.apache.thrift.transport.TSaslServerTransport$Factory.getTransport(TSaslServerTransport.java:219) > at > org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingTransportFactory$1.run(HadoopThriftAuthBridge.java:739) > at > org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingTransportFactory$1.run(HadoopThriftAuthBridge.java:736) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:356) > at > org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1637) > at > org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingTransportFactory.getTransport(HadoopThriftAuthBridge.java:736) > at > org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:268) > 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) > Caused by: org.apache.thrift.transport.TTransportException: Peer indicated > failure: GSS initiate failed > at > org.apache.thrift.transport.TSaslTransport.receiveSaslMessage(TSaslTransport.java:199) > at > org.apache.thrift.transport.TSaslServerTransport.handleSaslStartMessage(TSaslServerTransport.java:125) > at > org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:271) > at > org.apache.thrift.transport.TSaslServerTransport.open(TSaslServerTransport.java:41) > at > org.apache.thrift.transport.TSaslServerTransport$Factory.getTransport(TSaslServerTransport.java:216) > ... 10 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18091) Use https url for Spark2 Service check when WireEncryption is enabled
[ https://issues.apache.org/jira/browse/AMBARI-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-18091: --- Priority: Blocker (was: Critical) > 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 > > > 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-18091) Use https url for Spark2 Service check when WireEncryption is enabled
[ https://issues.apache.org/jira/browse/AMBARI-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-18091: --- Fix Version/s: 2.4.0 > 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: Critical > Fix For: 2.4.0 > > > 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-17998) When I enable Kerberos,the Hive shell faild to access.
[ https://issues.apache.org/jira/browse/AMBARI-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414761#comment-15414761 ] niushuo commented on AMBARI-17998: -- I have fixed this problem,Just check your dir of "/home/",there could be some wrong about the dir,change the Group or ID, > When I enable Kerberos,the Hive shell faild to access. > -- > > Key: AMBARI-17998 > URL: https://issues.apache.org/jira/browse/AMBARI-17998 > Project: Ambari > Issue Type: Bug > Components: security >Affects Versions: 2.2.2 > Environment: Centos6.7 >Reporter: niushuo > > When I enable Kerberos,the serverice of Hive was succeed to start.Bui when I > use the command "hive" to go in the Hive shell,it's show some error,show in > below, > 2016-08-02 21:39:26,620 ERROR [pool-5-thread-183]: server.TThreadPoolServer > (TThreadPoolServer.java:run(296)) - Error occurred during processing of > message. > java.lang.RuntimeException: org.apache.thrift.transport.TTransportException: > Peer indicated failure: GSS initiate failed > at > org.apache.thrift.transport.TSaslServerTransport$Factory.getTransport(TSaslServerTransport.java:219) > at > org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingTransportFactory$1.run(HadoopThriftAuthBridge.java:739) > at > org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingTransportFactory$1.run(HadoopThriftAuthBridge.java:736) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:356) > at > org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1637) > at > org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingTransportFactory.getTransport(HadoopThriftAuthBridge.java:736) > at > org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:268) > 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) > Caused by: org.apache.thrift.transport.TTransportException: Peer indicated > failure: GSS initiate failed > at > org.apache.thrift.transport.TSaslTransport.receiveSaslMessage(TSaslTransport.java:199) > at > org.apache.thrift.transport.TSaslServerTransport.handleSaslStartMessage(TSaslServerTransport.java:125) > at > org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:271) > at > org.apache.thrift.transport.TSaslServerTransport.open(TSaslServerTransport.java:41) > at > org.apache.thrift.transport.TSaslServerTransport$Factory.getTransport(TSaslServerTransport.java:216) > ... 10 more -- 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
[ https://issues.apache.org/jira/browse/AMBARI-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414751#comment-15414751 ] Saisai Shao commented on AMBARI-18091: -- Please help to review, [~sumitmohanty] [~jluniya], thanks a lot. > 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: Critical > > 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] [Assigned] (AMBARI-18091) Use https url for Spark2 Service check when WireEncryption is enabled
[ https://issues.apache.org/jira/browse/AMBARI-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saisai Shao reassigned AMBARI-18091: Assignee: Saisai Shao > 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: Critical > > 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] [Created] (AMBARI-18095) Use Zookeeper *.log file instead of *.out (in Logfeeder too)
Dharmesh Makwana created AMBARI-18095: - Summary: 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 *.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] [Commented] (AMBARI-18070) Calculation of versionAdvertised in is incorrect in metainfo.xml when parent is false and current ComponentInfo is true
[
https://issues.apache.org/jira/browse/AMBARI-18070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414688#comment-15414688
]
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/12822928/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/8350//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-18055) service config page load takes long time on cluster with large number of service config versions
[
https://issues.apache.org/jira/browse/AMBARI-18055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414690#comment-15414690
]
Hadoop QA commented on AMBARI-18055:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12822897/AMBARI-18055.2.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8351//console
This message is automatically generated.
> 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-17805) the history versions of config can't be showed in the screen fully
[
https://issues.apache.org/jira/browse/AMBARI-17805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414687#comment-15414687
]
Hadoop QA commented on AMBARI-17805:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12822929/AMBARI-17805.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/8349//console
This message is automatically generated.
> the history versions of config can't be showed in the screen fully
> --
>
> Key: AMBARI-17805
> URL: https://issues.apache.org/jira/browse/AMBARI-17805
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: wuhui
> Fix For: 2.4.0
>
> Attachments: AMBARI-17805.patch, A_WQ6V3PP70}SPDU09QZG8P.jpg,
> [Q{M}H{{3JVL%U(A8${UMWF.png, page_turn_1.png, page_turn_2.png
>
>
> when the number of config version is more than twenty-one，type the button
> ‘show more config history’，the configs can't be show in the screen fully。
> if you want to show the detail of the bug，please see the picture of below！
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18093) Reduce TTL for high precision tables and remove HBase policy setters in AMS config
[
https://issues.apache.org/jira/browse/AMBARI-18093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414686#comment-15414686
]
Hadoop QA commented on AMBARI-18093:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12822935/AMBARI-18093.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/8348//console
This message is automatically generated.
> Reduce TTL for high precision tables and remove HBase policy setters in AMS
> config
> ---
>
> Key: AMBARI-18093
> URL: https://issues.apache.org/jira/browse/AMBARI-18093
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
> Fix For: 2.5.0
>
> Attachments: AMBARI-18093.patch
>
>
> TTL changes
> {code}
> timeline.metrics.host.aggregator.ttl : 1 day
> timeline.metrics.cluster.aggregator.second.ttl : 3 days
> {code}
> HBase policy changes
> Remove the following
> {code}
> # HBase compaction policy enabled
> export HBASE_NORMALIZATION_ENABLED=True
> # HBase compaction policy enabled
> export HBASE_FIFO_COMPACTION_POLICY_ENABLED=
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18094) Oozie server failed to start with NoClassDefFoundError: org/apache/oozie/cli/CLIParser
Vivek Rathod created AMBARI-18094:
-
Summary: Oozie server failed to start with NoClassDefFoundError:
org/apache/oozie/cli/CLIParser
Key: AMBARI-18094
URL: https://issues.apache.org/jira/browse/AMBARI-18094
Project: Ambari
Issue Type: Bug
Affects Versions: 2.4.0
Environment: ambari-server-2.4.0.0-1121.x86_64
ambari-agent-2.4.0.0-1121.x86_64
Ambari DB: :MariaDB
Oozie/Hive DB: MariaDB/MariaDB
Security:no
Security Type:MIT/MIT
Blueprints: false
Umask:
JDK: OracleJDK7
OS: CentOS 7
Reporter: Vivek Rathod
Priority: Critical
Fix For: 2.4.0
Install cluster with HDFS, Yarn, MR and ZK, and then add
{hive,tez,piz}
and then
{oozie,hbase,sqoop}
Oozie server fails to start on adding oozie.
{code}
Traceback (most recent call last):
File
"/var/lib/ambari-agent/cache/common-services/OOZIE/4.0.0.2.0/package/scripts/oozie_server.py",
line 215, in
OozieServer().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/OOZIE/4.0.0.2.0/package/scripts/oozie_server.py",
line 95, in start
oozie_service(action='start', upgrade_type=upgrade_type)
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/OOZIE/4.0.0.2.0/package/scripts/oozie_service.py",
line 131, in oozie_service
path = params.execute_path
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 273, 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 71, in inner
result = function(command, **kwargs)
File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
line 93, in checked_call
tries=tries, try_sleep=try_sleep)
File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
line 141, in _call_wrapper
result = _call(command, **kwargs_copy)
File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
line 294, in _call
raise Fail(err_msg)
resource_management.core.exceptions.Fail: Execution of
'/usr/hdp/current/oozie-server/bin/oozie-setup.sh sharelib create -fs
hdfs://nat-r7-ifu-ambari-serv-2-1.openstacklocal:8020 -locallib
/usr/hdp/current/oozie-server/share' returned 1. Hortonworks
#
This is MOTD message, added for testing in qe infra
setting OOZIE_CONFIG=${OOZIE_CONFIG:-/usr/hdp/current/oozie-server/conf}
setting
CATALINA_BASE=${CATALINA_BASE:-/usr/hdp/current/oozie-server/oozie-server}
setting CATALINA_TMPDIR=${CATALINA_TMPDIR:-/var/tmp/oozie}
setting OOZIE_CATALINA_HOME=/usr/lib/bigtop-tomcat
setting JAVA_HOME=/usr/jdk64/jdk1.8.0_60
setting JRE_HOME=${JAVA_HOME}
setting CATALINA_OPTS="$CATALINA_OPTS -Xmx2048m"
setting OOZIE_LOG=/grid/0/log/oozie
setting CATALINA_PID=/var/run/oozie/oozie.pid
setting OOZIE_DATA=/grid/0/hadoop/oozie/data
setting OOZIE_HTTP_PORT=11000
setting OOZIE_ADMIN_PORT=11001
setting
JAVA_LIBRARY_PATH=/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64
setting OOZIE_CLIENT_OPTS="${OOZIE_CLIENT_OPTS}
-Doozie.connection.retry.count=5 "
setting OOZIE_CONFIG=${OOZIE_CONFIG:-/usr/hdp/current/oozie-server/conf}
setting
CATALINA_BASE=${CATALINA_BASE:-/usr/hdp/current/oozie-server/oozie-server}
setting CATALINA_TMPDIR=${CATALINA_TMPDIR:-/var/tmp/oozie}
setting OOZIE_CATALINA_HOME=/usr/lib/bigtop-tomcat
setting JAVA_HOME=/usr/jdk64/jdk1.8.0_60
setting JRE_HOME=${JAVA_HOME}
setting CATALINA_OPTS="$CATALINA_OPTS -Xmx2048m"
setting OOZIE_LOG=/grid/0/log/oozie
setting CATALINA_PID=/var/run/oozie/oozie.pid
setting OOZIE_DATA=/grid/0/hadoop/oozie/data
setting OOZIE_HTTP_PORT=11000
setting OOZIE_ADMIN_PORT=11001
setting
JAVA_LIBRARY_PATH=/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64
setting OOZIE_CLIENT_OPTS="${OOZIE_CLIENT_OPTS}
-Doozie.connection.retry.count=5 "
Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/oozie/cli/CLIParser
at org.apache.oozie.tools.OozieSharelibCLI.run(OozieSharelibCLI.java:92)
at
org.apache.oozie.tools.OozieSharelibCLI.main(OozieSharelibCLI.java:67)
Caused by: java.lang.ClassNotFoundException: org.apache.oozie.cli.CLIParser
at
[jira] [Updated] (AMBARI-18093) Reduce TTL for high precision tables and remove HBase policy setters in AMS config
[
https://issues.apache.org/jira/browse/AMBARI-18093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated AMBARI-18093:
---
Summary: Reduce TTL for high precision tables and remove HBase policy
setters in AMS config (was: TTL and HBase policy changes in AMS configs.)
> Reduce TTL for high precision tables and remove HBase policy setters in AMS
> config
> ---
>
> Key: AMBARI-18093
> URL: https://issues.apache.org/jira/browse/AMBARI-18093
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
> Fix For: 2.5.0
>
> Attachments: AMBARI-18093.patch
>
>
> TTL changes
> {code}
> timeline.metrics.host.aggregator.ttl : 1 day
> timeline.metrics.cluster.aggregator.second.ttl : 3 days
> {code}
> HBase policy changes
> Remove the following
> {code}
> # HBase compaction policy enabled
> export HBASE_NORMALIZATION_ENABLED=True
> # HBase compaction policy enabled
> export HBASE_FIFO_COMPACTION_POLICY_ENABLED=
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18093) TTL and HBase policy changes in AMS configs.
[
https://issues.apache.org/jira/browse/AMBARI-18093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated AMBARI-18093:
---
Status: Patch Available (was: Open)
> TTL and HBase policy changes in AMS configs.
>
>
> Key: AMBARI-18093
> URL: https://issues.apache.org/jira/browse/AMBARI-18093
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
> Fix For: 2.5.0
>
> Attachments: AMBARI-18093.patch
>
>
> TTL changes
> {code}
> timeline.metrics.host.aggregator.ttl : 1 day
> timeline.metrics.cluster.aggregator.second.ttl : 3 days
> {code}
> HBase policy changes
> Remove the following
> {code}
> # HBase compaction policy enabled
> export HBASE_NORMALIZATION_ENABLED=True
> # HBase compaction policy enabled
> export HBASE_FIFO_COMPACTION_POLICY_ENABLED=
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18093) TTL and HBase policy changes in AMS configs.
[
https://issues.apache.org/jira/browse/AMBARI-18093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated AMBARI-18093:
---
Attachment: AMBARI-18093.patch
> TTL and HBase policy changes in AMS configs.
>
>
> Key: AMBARI-18093
> URL: https://issues.apache.org/jira/browse/AMBARI-18093
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
> Fix For: 2.5.0
>
> Attachments: AMBARI-18093.patch
>
>
> TTL changes
> {code}
> timeline.metrics.host.aggregator.ttl : 1 day
> timeline.metrics.cluster.aggregator.second.ttl : 3 days
> {code}
> HBase policy changes
> Remove the following
> {code}
> # HBase compaction policy enabled
> export HBASE_NORMALIZATION_ENABLED=True
> # HBase compaction policy enabled
> export HBASE_FIFO_COMPACTION_POLICY_ENABLED=
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18093) TTL and HBase policy changes in AMS configs.
Aravindan Vijayan created AMBARI-18093:
--
Summary: TTL and HBase policy changes in AMS configs.
Key: AMBARI-18093
URL: https://issues.apache.org/jira/browse/AMBARI-18093
Project: Ambari
Issue Type: Bug
Components: ambari-metrics
Affects Versions: 2.4.0
Reporter: Aravindan Vijayan
Assignee: Aravindan Vijayan
Fix For: 2.5.0
TTL changes
{code}
timeline.metrics.host.aggregator.ttl : 1 day
timeline.metrics.cluster.aggregator.second.ttl : 3 days
{code}
HBase policy changes
Remove the following
{code}
# HBase compaction policy enabled
export HBASE_NORMALIZATION_ENABLED=True
# HBase compaction policy enabled
export HBASE_FIFO_COMPACTION_POLICY_ENABLED=
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18092) Fix Spark2 History server quick link when Wire encryption is enabled
Yesha Vora created AMBARI-18092: --- Summary: Fix Spark2 History server quick link when Wire encryption is enabled Key: AMBARI-18092 URL: https://issues.apache.org/jira/browse/AMBARI-18092 Project: Ambari Issue Type: Bug Affects Versions: 2.4.0 Reporter: Yesha Vora Priority: Critical Spark2 quick link should redirect to https://: when spark wire encryption is enabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18091) Use https url for Spark2 Service check when WireEncryption is enabled
Yesha Vora created AMBARI-18091: --- Summary: 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 Priority: Critical 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-17805) the history versions of config can't be showed in the screen fully
[
https://issues.apache.org/jira/browse/AMBARI-17805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414573#comment-15414573
]
wuhui commented on AMBARI-17805:
I have submitted the patch in the attached files titled 'AMBARI-17805.patch'
which I have tested in my local Ambari Ui web.
> the history versions of config can't be showed in the screen fully
> --
>
> Key: AMBARI-17805
> URL: https://issues.apache.org/jira/browse/AMBARI-17805
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: wuhui
> Fix For: 2.4.0
>
> Attachments: AMBARI-17805.patch, A_WQ6V3PP70}SPDU09QZG8P.jpg,
> [Q{M}H{{3JVL%U(A8${UMWF.png, page_turn_1.png, page_turn_2.png
>
>
> when the number of config version is more than twenty-one，type the button
> ‘show more config history’，the configs can't be show in the screen fully。
> if you want to show the detail of the bug，please see the picture of below！
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17805) the history versions of config can't be showed in the screen fully
[
https://issues.apache.org/jira/browse/AMBARI-17805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
wuhui updated AMBARI-17805:
---
Fix Version/s: (was: 2.2.2)
2.4.0
> the history versions of config can't be showed in the screen fully
> --
>
> Key: AMBARI-17805
> URL: https://issues.apache.org/jira/browse/AMBARI-17805
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: wuhui
> Fix For: 2.4.0
>
> Attachments: A_WQ6V3PP70}SPDU09QZG8P.jpg,
> [Q{M}H{{3JVL%U(A8${UMWF.png, page_turn_1.png, page_turn_2.png
>
>
> when the number of config version is more than twenty-one，type the button
> ‘show more config history’，the configs can't be show in the screen fully。
> if you want to show the detail of the bug，please see the picture of below！
--
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
[ 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
[ 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
[ 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
[ 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] [Commented] (AMBARI-17749) Typo "rather then" in spark-default.conf
[ https://issues.apache.org/jira/browse/AMBARI-17749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414448#comment-15414448 ] Masahiro Tanaka commented on AMBARI-17749: -- Thank you [~afernandez]! > Typo "rather then" in spark-default.conf > > > Key: AMBARI-17749 > URL: https://issues.apache.org/jira/browse/AMBARI-17749 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk > Environment: CentOS7.2, HDP2.4, Spark1.6.1 >Reporter: Masahiro Tanaka >Assignee: Masahiro Tanaka >Priority: Trivial > Fix For: trunk > > Attachments: AMBARI-17749.patch, spark-configu-description.PNG > > > There is a typo in Spark config description. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18090) Use optimized jpql query when service config versions for all services is requested
Jaimin D Jetly created AMBARI-18090: --- Summary: Use optimized jpql query when service config versions for all services is requested Key: AMBARI-18090 URL: https://issues.apache.org/jira/browse/AMBARI-18090 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.4.0 Reporter: Jaimin D Jetly Assignee: Jaimin D Jetly Fix For: trunk -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17213) Create ambari workflow designer contrib view
[ https://issues.apache.org/jira/browse/AMBARI-17213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414378#comment-15414378 ] Yusaku Sako commented on AMBARI-17213: -- The UT failure is for Ambari Server and doesn't seem related to this patch. > Create ambari workflow designer contrib view > > > Key: AMBARI-17213 > URL: https://issues.apache.org/jira/browse/AMBARI-17213 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.4.0 >Reporter: Venkat Ranganathan >Assignee: Venkat Ranganathan >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17213.patch > > > Need to provide workflow designer as a contributed view in ambari -- 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
[
https://issues.apache.org/jira/browse/AMBARI-18055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaimin D Jetly updated AMBARI-18055:
Attachment: AMBARI-18055.2.patch
> 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-18086) Falcon Ambari integration should be enabled even if Atlas server and Falcon server are no collocated
[
https://issues.apache.org/jira/browse/AMBARI-18086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414364#comment-15414364
]
Hudson commented on AMBARI-18086:
-
FAILURE: Integrated in Ambari-trunk-Commit #5492 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5492/])
AMBARI-18086. Falcon Ambari integration should be enabled even if Atlas
(smohanty:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=0273c844d3df9a2dce2ba453e4ce2ebec325ff63])
*
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/params_linux.py
*
ambari-common/src/main/python/resource_management/libraries/functions/package_conditions.py
> Falcon Ambari integration should be enabled even if Atlas server and Falcon
> server are no collocated
>
>
> Key: AMBARI-18086
> URL: https://issues.apache.org/jira/browse/AMBARI-18086
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18086.patch
>
>
> Several changes for Falcon Atlas integration.
> In Falcon's params_linux.py for HDP 2.5, set atlas_hook_cp even if Atlas is
> not present on this host since the RPM will install the dependency if Falcon
> is installed.
> {code}
> atlas_hook_cp = ""
> if has_atlas_in_cluster():
> atlas_hook_filename =
> default('/configurations/atlas-env/metadata_conf_file',
> 'atlas-application.properties')
> # Only append /etc/atlas/conf to classpath if on HDP 2.4.* and atlas server
> is running on this host.
> if has_atlas_server_on_host and
> check_stack_feature(StackFeature.ATLAS_CONF_DIR_IN_PATH,
> stack_version_formatted):
> atlas_conf_dir = os.environ['METADATA_CONF'] if 'METADATA_CONF' in
> os.environ else format('{stack_root}/current/atlas-server/conf')
> atlas_home_dir = os.environ['METADATA_HOME_DIR'] if 'METADATA_HOME_DIR'
> in os.environ else format('{stack_root}/current/atlas-server')
> atlas_hook_cp = atlas_conf_dir + os.pathsep +
> os.path.join(atlas_home_dir, "hook", "falcon", "*") + os.pathsep
> #endregion
> {code}
> Further, Stack Advisor in HDP 2.5, plus EU/RU to HDP 2.5 needs to change
> Falcon's falcon-startup.properties "*.application.services" to use
> "org.apache.atlas.falcon.service.AtlasService" instead of
> "org.apache.falcon.atlas.service.AtlasService" since the class was renamed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17213) Create ambari workflow designer contrib view
[ https://issues.apache.org/jira/browse/AMBARI-17213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414365#comment-15414365 ] Hudson commented on AMBARI-17213: - FAILURE: Integrated in Ambari-trunk-Commit #5492 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5492/]) AMBARI-17213. Create ambari workflow designer contrib view. (Venkat (yusaku: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=c7742e7f1e4435bd9d9395a3dce3b36a4bf21896]) * contrib/views/wfmanager/src/main/resources/ui/app/domain/transition.js * contrib/views/wfmanager/src/main/resources/ui/app/templates/components/hive2-action.hbs * contrib/views/wfmanager/src/main/resources/ui/README.md * contrib/views/wfmanager/src/main/resources/ui/tests/helpers/module-for-acceptance.js * contrib/views/wfmanager/src/main/resources/ui/app/components/prepare-config-fs.js * contrib/views/wfmanager/src/main/resources/ui/tests/integration/components/workflow-node-test.js * contrib/views/wfmanager/src/main/resources/ui/app/domain/workflow.js * contrib/views/wfmanager/src/main/resources/ui/tests/integration/components/name-value-config-test.js * contrib/views/wfmanager/src/main/resources/ui/externaladdons/hdfs-directory-viewer/.bowerrc * contrib/views/wfmanager/src/main/resources/ui/app/components/pig-action.js * contrib/views/wfmanager/src/main/resources/ui/app/templates/components/named-properties.hbs * contrib/views/wfmanager/src/main/resources/ui/app/components/prepare-config.js * contrib/views/wfmanager/src/main/resources/ui/tests/integration/components/version-settings-test.js * contrib/views/wfmanager/src/main/resources/ui/tests/integration/components/sqoop-action-test.js * contrib/views/wfmanager/src/main/resources/ui/app/components/arg-config.js * contrib/views/wfmanager/src/main/resources/ui/app/components/map-red-action.js * contrib/views/wfmanager/src/main/resources/ui/app/templates/error-template.hbs * contrib/views/wfmanager/src/assembly/assembly.xml * contrib/views/wfmanager/src/main/resources/ui/tests/integration/components/jobxml-config-test.js * contrib/views/wfmanager/src/main/resources/ui/tests/integration/components/coord-job-details-test.js * contrib/views/wfmanager/src/main/resources/ui/tests/integration/components/workflow-parameters-test.js * contrib/views/wfmanager/src/main/resources/ui/app/domain/layout-manager1.js * contrib/views/wfmanager/src/main/resources/ui/app/components/workflow-node.js * contrib/views/wfmanager/src/main/resources/ui/app/domain/node-handler.js * contrib/views/wfmanager/src/main/resources/ui/proxy.js * contrib/views/wfmanager/src/main/resources/ui/app/routes/job.js * contrib/views/wfmanager/src/main/resources/ui/externaladdons/hdfs-directory-viewer/tests/dummy/app/controllers/application.js * contrib/views/wfmanager/src/main/resources/ui/app/domain/actionjob_hanlder.js * contrib/views/wfmanager/src/main/resources/ui/app/templates/components/file-upload.hbs * contrib/views/wfmanager/src/main/resources/ui/tests/unit/services/file-browser-test.js * contrib/views/wfmanager/src/main/resources/ui/app/templates/components/hdfs-browser.hbs * contrib/views/wfmanager/src/main/resources/ui/app/components/coord-job-details.js * contrib/views/wfmanager/src/main/resources/ui/app/templates/loading.hbs * contrib/views/wfmanager/src/main/resources/ui/app/controllers/design.js * contrib/views/wfmanager/src/main/resources/ui/externaladdons/hdfs-directory-viewer/addon/utils/viewer-config.js * contrib/views/wfmanager/src/main/resources/ui/app/templates/components/distcp-action.hbs * contrib/views/wfmanager/src/main/resources/ui/app/templates/components/jdbc-url.hbs * contrib/views/wfmanager/src/main/resources/ui/app/domain/layout-manager2.js * contrib/views/wfmanager/src/main/resources/ui/app/helpers/date-helper.js * contrib/views/wfmanager/src/main/resources/ui/package.json * contrib/views/wfmanager/src/main/resources/ui/tests/integration/components/archive-config-test.js * contrib/views/wfmanager/src/main/resources/ui/externaladdons/hdfs-directory-viewer/.ember-cli * contrib/views/wfmanager/src/main/resources/ui/app/domain/workflow-importer.js * contrib/views/wfmanager/src/main/resources/ui/tests/integration/components/arg-config-test.js * contrib/views/wfmanager/src/main/resources/ui/app/controllers/dashboard.js * contrib/views/wfmanager/src/main/resources/ui/app/components/global-config.js * contrib/views/wfmanager/src/main/resources/ui/tests/integration/components/action-credential-config-test.js * contrib/views/wfmanager/src/main/resources/ui/tests/integration/components/global-config-test.js * contrib/views/wfmanager/src/main/resources/ui/app/templates/components/designer-errors.hbs * contrib/views/wfmanager/src/main/resources/ui/app/domain/mapping-utils.js * contrib/views/wfmanager/src/main/resources/ui/app/templates/dashboard.hbs * contrib/views/wfmanager/src/main/resources/ui/tests/test-helper.js *
[jira] [Created] (AMBARI-18089) Create Documentation Around All Options In ambari.properties
Jonathan Hurley created AMBARI-18089:
Summary: Create Documentation Around All Options In
ambari.properties
Key: AMBARI-18089
URL: https://issues.apache.org/jira/browse/AMBARI-18089
Project: Ambari
Issue Type: Task
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
Priority: Critical
Fix For: 2.5.0
Ambari Server has "sensible" defaults for many of the configurations in
{{ambari.properties}}. They may work for 5-, 10-, 50-, or even 100-host
clusters. However, they _must_ be properly tuned in any situation which has a
large, production-level topology.
There is currently sparse to no documentation on many of these properties. For
every property, we need to consider:
- The context in which different cluster deployments could be affected by it
-- Cluster Size
-- Cluster History
-- Concurrent Users
- Provide recommendations that are grouped logically, such as (for example)
-- Multiple Concurrent Users
-- 50 to 100 Hosts
-- Ambari Server Hardware
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-14384) Ambari Metrics doesn't use SPNEGO to authenticate
[ https://issues.apache.org/jira/browse/AMBARI-14384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravindan Vijayan updated AMBARI-14384: --- Fix Version/s: 2.5.0 > Ambari Metrics doesn't use SPNEGO to authenticate > - > > Key: AMBARI-14384 > URL: https://issues.apache.org/jira/browse/AMBARI-14384 > Project: Ambari > Issue Type: Improvement > Components: ambari-metrics >Affects Versions: 2.1.2 >Reporter: Ward Viaene >Assignee: Aravindan Vijayan > Fix For: 2.5.0 > > > * Kerberos enabled cluster > * SPNEGO enabled on hadoop APIs > /var/log/ambari-metrics-monitor/ambari-metrics-monitor.out: > 2015-12-15 13:26:30,663 [INFO] emitter.py:101 - server: > http://metrics-collector:6188/ws/v1/timeline/metrics > 2015-12-15 13:26:30,671 [WARNING] emitter.py:84 - Error sending metrics to > server. HTTP Error 401: Authentication required > 2015-12-15 13:26:30,671 [WARNING] emitter.py:90 - Retrying after 5 ... > The same problem appears to be happening on the sinks: > * > ambari/ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/AbstractTimelineMetricsSink.java > ** No SPNEGO support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (AMBARI-14384) Ambari Metrics doesn't use SPNEGO to authenticate
[ https://issues.apache.org/jira/browse/AMBARI-14384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravindan Vijayan reassigned AMBARI-14384: -- Assignee: Aravindan Vijayan > Ambari Metrics doesn't use SPNEGO to authenticate > - > > Key: AMBARI-14384 > URL: https://issues.apache.org/jira/browse/AMBARI-14384 > Project: Ambari > Issue Type: Improvement > Components: ambari-metrics >Affects Versions: 2.1.2 >Reporter: Ward Viaene >Assignee: Aravindan Vijayan > > * Kerberos enabled cluster > * SPNEGO enabled on hadoop APIs > /var/log/ambari-metrics-monitor/ambari-metrics-monitor.out: > 2015-12-15 13:26:30,663 [INFO] emitter.py:101 - server: > http://metrics-collector:6188/ws/v1/timeline/metrics > 2015-12-15 13:26:30,671 [WARNING] emitter.py:84 - Error sending metrics to > server. HTTP Error 401: Authentication required > 2015-12-15 13:26:30,671 [WARNING] emitter.py:90 - Retrying after 5 ... > The same problem appears to be happening on the sinks: > * > ambari/ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/AbstractTimelineMetricsSink.java > ** No SPNEGO support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18087) Fix conf-select for Zeppelin service
[ https://issues.apache.org/jira/browse/AMBARI-18087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414238#comment-15414238 ] Hudson commented on AMBARI-18087: - FAILURE: Integrated in Ambari-trunk-Commit #5491 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5491/]) AMBARI-18087. Fix conf-select for Zeppelin service (Renjith Kamath via (smohanty: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=c2788a4bd0b075a3b9419ab5d44fdc6bd1ee5b9e]) * ambari-common/src/main/python/resource_management/libraries/functions/conf_select.py * ambari-agent/src/main/python/ambari_agent/HostInfo.py * ambari-server/src/main/resources/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py > Fix conf-select for Zeppelin service > > > Key: AMBARI-18087 > URL: https://issues.apache.org/jira/browse/AMBARI-18087 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Renjith Kamath >Assignee: Renjith Kamath >Priority: Blocker > Fix For: 2.4.0 > > Attachments: AMBARI-18087_trunk+branch-2.4_v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18088) Ranger service check does not run during Express Upgrade
[
https://issues.apache.org/jira/browse/AMBARI-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414190#comment-15414190
]
Hadoop QA commented on AMBARI-18088:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12822866/AMBARI-18088.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/8347//console
This message is automatically generated.
> 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] [Updated] (AMBARI-17213) Create ambari workflow designer contrib view
[ https://issues.apache.org/jira/browse/AMBARI-17213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yusaku Sako updated AMBARI-17213: - Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk and branch-2.4. > Create ambari workflow designer contrib view > > > Key: AMBARI-17213 > URL: https://issues.apache.org/jira/browse/AMBARI-17213 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.4.0 >Reporter: Venkat Ranganathan >Assignee: Venkat Ranganathan >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17213.patch > > > Need to provide workflow designer as a contributed view in ambari -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17213) Create ambari workflow designer contrib view
[ https://issues.apache.org/jira/browse/AMBARI-17213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414154#comment-15414154 ] Yusaku Sako commented on AMBARI-17213: -- Hadoop QA job failure above is unrelated to this patch (the Jenkins job could not find the JDK). > Create ambari workflow designer contrib view > > > Key: AMBARI-17213 > URL: https://issues.apache.org/jira/browse/AMBARI-17213 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.4.0 >Reporter: Venkat Ranganathan >Assignee: Venkat Ranganathan >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17213.patch > > > Need to provide workflow designer as a contributed view in ambari -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18088) Ranger service check does not run during Express Upgrade
[ https://issues.apache.org/jira/browse/AMBARI-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hurley updated AMBARI-18088: - Attachment: AMBARI-18088.patch > 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] [Updated] (AMBARI-18088) Ranger service check does not run during Express Upgrade
[ https://issues.apache.org/jira/browse/AMBARI-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hurley updated AMBARI-18088: - Status: Patch Available (was: Open) > 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] [Updated] (AMBARI-18088) Ranger service check does not run during Express Upgrade
[ https://issues.apache.org/jira/browse/AMBARI-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hurley updated AMBARI-18088: - Component/s: ambari-server > 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 > > > 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-17749) Typo "rather then" in spark-default.conf
[ https://issues.apache.org/jira/browse/AMBARI-17749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414105#comment-15414105 ] Hudson commented on AMBARI-17749: - FAILURE: Integrated in Ambari-trunk-Commit #5490 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5490/]) AMBARI-17749. Typo "rather then" in spark-default.conf (Masahiro Tanaka (afernandez: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=aa2930a4a696f721934e0608d1dccf206a2fad9f]) * ambari-server/src/main/resources/common-services/SPARK/1.5.2/configuration/spark-thrift-sparkconf.xml * ambari-server/src/main/resources/common-services/SPARK/1.2.1/configuration/spark-defaults.xml > Typo "rather then" in spark-default.conf > > > Key: AMBARI-17749 > URL: https://issues.apache.org/jira/browse/AMBARI-17749 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk > Environment: CentOS7.2, HDP2.4, Spark1.6.1 >Reporter: Masahiro Tanaka >Assignee: Masahiro Tanaka >Priority: Trivial > Fix For: trunk > > Attachments: AMBARI-17749.patch, spark-configu-description.PNG > > > There is a typo in Spark config description. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18088) Ranger service check does not run during Express Upgrade
Jonathan Hurley created AMBARI-18088: Summary: 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 Reporter: Jonathan Hurley Priority: Blocker 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] [Updated] (AMBARI-18088) Ranger service check does not run during Express Upgrade
[ https://issues.apache.org/jira/browse/AMBARI-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hurley updated AMBARI-18088: - Fix Version/s: 2.4.0 > 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 >Affects Versions: 2.4.0 >Reporter: Jonathan Hurley >Assignee: Jonathan Hurley >Priority: Blocker > Fix For: 2.4.0 > > > 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] [Updated] (AMBARI-18088) Ranger service check does not run during Express Upgrade
[ https://issues.apache.org/jira/browse/AMBARI-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hurley updated AMBARI-18088: - Affects Version/s: 2.4.0 > 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 >Affects Versions: 2.4.0 >Reporter: Jonathan Hurley >Assignee: Jonathan Hurley >Priority: Blocker > Fix For: 2.4.0 > > > 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] [Assigned] (AMBARI-18088) Ranger service check does not run during Express Upgrade
[ https://issues.apache.org/jira/browse/AMBARI-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hurley reassigned AMBARI-18088: Assignee: Jonathan Hurley > 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 >Affects Versions: 2.4.0 >Reporter: Jonathan Hurley >Assignee: Jonathan Hurley >Priority: Blocker > Fix For: 2.4.0 > > > 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-18086) Falcon Ambari integration should be enabled even if Atlas server and Falcon server are no collocated
[
https://issues.apache.org/jira/browse/AMBARI-18086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414101#comment-15414101
]
Hadoop QA commented on AMBARI-18086:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12822857/AMBARI-18086.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/8346//console
This message is automatically generated.
> Falcon Ambari integration should be enabled even if Atlas server and Falcon
> server are no collocated
>
>
> Key: AMBARI-18086
> URL: https://issues.apache.org/jira/browse/AMBARI-18086
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18086.patch
>
>
> Several changes for Falcon Atlas integration.
> In Falcon's params_linux.py for HDP 2.5, set atlas_hook_cp even if Atlas is
> not present on this host since the RPM will install the dependency if Falcon
> is installed.
> {code}
> atlas_hook_cp = ""
> if has_atlas_in_cluster():
> atlas_hook_filename =
> default('/configurations/atlas-env/metadata_conf_file',
> 'atlas-application.properties')
> # Only append /etc/atlas/conf to classpath if on HDP 2.4.* and atlas server
> is running on this host.
> if has_atlas_server_on_host and
> check_stack_feature(StackFeature.ATLAS_CONF_DIR_IN_PATH,
> stack_version_formatted):
> atlas_conf_dir = os.environ['METADATA_CONF'] if 'METADATA_CONF' in
> os.environ else format('{stack_root}/current/atlas-server/conf')
> atlas_home_dir = os.environ['METADATA_HOME_DIR'] if 'METADATA_HOME_DIR'
> in os.environ else format('{stack_root}/current/atlas-server')
> atlas_hook_cp = atlas_conf_dir + os.pathsep +
> os.path.join(atlas_home_dir, "hook", "falcon", "*") + os.pathsep
> #endregion
> {code}
> Further, Stack Advisor in HDP 2.5, plus EU/RU to HDP 2.5 needs to change
> Falcon's falcon-startup.properties "*.application.services" to use
> "org.apache.atlas.falcon.service.AtlasService" instead of
> "org.apache.falcon.atlas.service.AtlasService" since the class was renamed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17951) Introduce validation of hostgroup mapping for active/standby namenode
[ https://issues.apache.org/jira/browse/AMBARI-17951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amruta Borkar updated AMBARI-17951: --- Attachment: (was: AMBARI-17951-v1.patch) > 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-18087) Fix conf-select for Zeppelin service
[ https://issues.apache.org/jira/browse/AMBARI-18087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-18087: --- Resolution: Fixed Status: Resolved (was: Patch Available) committed to trunk and branch-2.4 > Fix conf-select for Zeppelin service > > > Key: AMBARI-18087 > URL: https://issues.apache.org/jira/browse/AMBARI-18087 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Renjith Kamath >Assignee: Renjith Kamath >Priority: Blocker > Fix For: 2.4.0 > > Attachments: AMBARI-18087_trunk+branch-2.4_v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18087) Fix conf-select for Zeppelin service
[
https://issues.apache.org/jira/browse/AMBARI-18087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414045#comment-15414045
]
Sumit Mohanty commented on AMBARI-18087:
Ran unit tests manually.
{code}
--
Ran 267 tests in 6.920s
OK
--
Total run:1034
Total errors:0
Total failures:0
OK
[smohanty@HW12158 python (branch-2.4)]$
{code}
> Fix conf-select for Zeppelin service
>
>
> Key: AMBARI-18087
> URL: https://issues.apache.org/jira/browse/AMBARI-18087
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Renjith Kamath
>Assignee: Renjith Kamath
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18087_trunk+branch-2.4_v1.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18087) Fix conf-select for Zeppelin service
[ https://issues.apache.org/jira/browse/AMBARI-18087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Renjith Kamath updated AMBARI-18087: Attachment: AMBARI-18087_trunk+branch-2.4_v1.patch > Fix conf-select for Zeppelin service > > > Key: AMBARI-18087 > URL: https://issues.apache.org/jira/browse/AMBARI-18087 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Renjith Kamath >Assignee: Renjith Kamath >Priority: Blocker > Fix For: 2.4.0 > > Attachments: AMBARI-18087_trunk+branch-2.4_v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18087) Fix conf-select for Zeppelin service
[ https://issues.apache.org/jira/browse/AMBARI-18087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Renjith Kamath updated AMBARI-18087: Status: Patch Available (was: Open) > Fix conf-select for Zeppelin service > > > Key: AMBARI-18087 > URL: https://issues.apache.org/jira/browse/AMBARI-18087 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Renjith Kamath >Assignee: Renjith Kamath >Priority: Blocker > Fix For: 2.4.0 > > Attachments: AMBARI-18087_trunk+branch-2.4_v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18086) Falcon Ambari integration should be enabled even if Atlas server and Falcon server are no collocated
[
https://issues.apache.org/jira/browse/AMBARI-18086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaly Brodetskyi updated AMBARI-18086:
---
Attachment: AMBARI-18086.patch
> Falcon Ambari integration should be enabled even if Atlas server and Falcon
> server are no collocated
>
>
> Key: AMBARI-18086
> URL: https://issues.apache.org/jira/browse/AMBARI-18086
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18086.patch
>
>
> Several changes for Falcon Atlas integration.
> In Falcon's params_linux.py for HDP 2.5, set atlas_hook_cp even if Atlas is
> not present on this host since the RPM will install the dependency if Falcon
> is installed.
> {code}
> atlas_hook_cp = ""
> if has_atlas_in_cluster():
> atlas_hook_filename =
> default('/configurations/atlas-env/metadata_conf_file',
> 'atlas-application.properties')
> # Only append /etc/atlas/conf to classpath if on HDP 2.4.* and atlas server
> is running on this host.
> if has_atlas_server_on_host and
> check_stack_feature(StackFeature.ATLAS_CONF_DIR_IN_PATH,
> stack_version_formatted):
> atlas_conf_dir = os.environ['METADATA_CONF'] if 'METADATA_CONF' in
> os.environ else format('{stack_root}/current/atlas-server/conf')
> atlas_home_dir = os.environ['METADATA_HOME_DIR'] if 'METADATA_HOME_DIR'
> in os.environ else format('{stack_root}/current/atlas-server')
> atlas_hook_cp = atlas_conf_dir + os.pathsep +
> os.path.join(atlas_home_dir, "hook", "falcon", "*") + os.pathsep
> #endregion
> {code}
> Further, Stack Advisor in HDP 2.5, plus EU/RU to HDP 2.5 needs to change
> Falcon's falcon-startup.properties "*.application.services" to use
> "org.apache.atlas.falcon.service.AtlasService" instead of
> "org.apache.falcon.atlas.service.AtlasService" since the class was renamed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18087) Fix conf-select for Zeppelin service
Renjith Kamath created AMBARI-18087: --- Summary: Fix conf-select for Zeppelin service Key: AMBARI-18087 URL: https://issues.apache.org/jira/browse/AMBARI-18087 Project: Ambari Issue Type: Bug Affects Versions: 2.4.0 Reporter: Renjith Kamath Assignee: Renjith Kamath Priority: Blocker Fix For: 2.4.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18086) Falcon Ambari integration should be enabled even if Atlas server and Falcon server are no collocated
[
https://issues.apache.org/jira/browse/AMBARI-18086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaly Brodetskyi updated AMBARI-18086:
---
Description:
Several changes for Falcon Atlas integration.
In Falcon's params_linux.py for HDP 2.5, set atlas_hook_cp even if Atlas is not
present on this host since the RPM will install the dependency if Falcon is
installed.
{code}
atlas_hook_cp = ""
if has_atlas_in_cluster():
atlas_hook_filename = default('/configurations/atlas-env/metadata_conf_file',
'atlas-application.properties')
# Only append /etc/atlas/conf to classpath if on HDP 2.4.* and atlas server
is running on this host.
if has_atlas_server_on_host and
check_stack_feature(StackFeature.ATLAS_CONF_DIR_IN_PATH,
stack_version_formatted):
atlas_conf_dir = os.environ['METADATA_CONF'] if 'METADATA_CONF' in
os.environ else format('{stack_root}/current/atlas-server/conf')
atlas_home_dir = os.environ['METADATA_HOME_DIR'] if 'METADATA_HOME_DIR' in
os.environ else format('{stack_root}/current/atlas-server')
atlas_hook_cp = atlas_conf_dir + os.pathsep + os.path.join(atlas_home_dir,
"hook", "falcon", "*") + os.pathsep
#endregion
{code}
Further, Stack Advisor in HDP 2.5, plus EU/RU to HDP 2.5 needs to change
Falcon's falcon-startup.properties "*.application.services" to use
"org.apache.atlas.falcon.service.AtlasService" instead of
"org.apache.falcon.atlas.service.AtlasService" since the class was renamed.
was:Falcon Ambari integration should be enabled even if Atlas server and
Falcon server are no collocated
> Falcon Ambari integration should be enabled even if Atlas server and Falcon
> server are no collocated
>
>
> Key: AMBARI-18086
> URL: https://issues.apache.org/jira/browse/AMBARI-18086
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Blocker
> Fix For: 2.4.0
>
>
> Several changes for Falcon Atlas integration.
> In Falcon's params_linux.py for HDP 2.5, set atlas_hook_cp even if Atlas is
> not present on this host since the RPM will install the dependency if Falcon
> is installed.
> {code}
> atlas_hook_cp = ""
> if has_atlas_in_cluster():
> atlas_hook_filename =
> default('/configurations/atlas-env/metadata_conf_file',
> 'atlas-application.properties')
> # Only append /etc/atlas/conf to classpath if on HDP 2.4.* and atlas server
> is running on this host.
> if has_atlas_server_on_host and
> check_stack_feature(StackFeature.ATLAS_CONF_DIR_IN_PATH,
> stack_version_formatted):
> atlas_conf_dir = os.environ['METADATA_CONF'] if 'METADATA_CONF' in
> os.environ else format('{stack_root}/current/atlas-server/conf')
> atlas_home_dir = os.environ['METADATA_HOME_DIR'] if 'METADATA_HOME_DIR'
> in os.environ else format('{stack_root}/current/atlas-server')
> atlas_hook_cp = atlas_conf_dir + os.pathsep +
> os.path.join(atlas_home_dir, "hook", "falcon", "*") + os.pathsep
> #endregion
> {code}
> Further, Stack Advisor in HDP 2.5, plus EU/RU to HDP 2.5 needs to change
> Falcon's falcon-startup.properties "*.application.services" to use
> "org.apache.atlas.falcon.service.AtlasService" instead of
> "org.apache.falcon.atlas.service.AtlasService" since the class was renamed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18086) Falcon Atlas config changes, renamed class org.apache.atlas.falcon.service.AtlasService and add Atlas home to Falcon class path
Vitaly Brodetskyi created AMBARI-18086: -- Summary: Falcon Atlas config changes, renamed class org.apache.atlas.falcon.service.AtlasService and add Atlas home to Falcon class path Key: AMBARI-18086 URL: https://issues.apache.org/jira/browse/AMBARI-18086 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.4.0 Reporter: Vitaly Brodetskyi Assignee: Vitaly Brodetskyi Priority: Blocker Fix For: 2.4.0 Falcon Ambari integration should be enabled even if Atlas server and Falcon server are no collocated -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18086) Falcon Ambari integration should be enabled even if Atlas server and Falcon server are no collocated
[ https://issues.apache.org/jira/browse/AMBARI-18086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaly Brodetskyi updated AMBARI-18086: --- Summary: Falcon Ambari integration should be enabled even if Atlas server and Falcon server are no collocated (was: Falcon Atlas config changes, renamed class org.apache.atlas.falcon.service.AtlasService and add Atlas home to Falcon class path) > Falcon Ambari integration should be enabled even if Atlas server and Falcon > server are no collocated > > > Key: AMBARI-18086 > URL: https://issues.apache.org/jira/browse/AMBARI-18086 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Vitaly Brodetskyi >Assignee: Vitaly Brodetskyi >Priority: Blocker > Fix For: 2.4.0 > > > Falcon Ambari integration should be enabled even if Atlas server and Falcon > server are no collocated -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18012) AMBARI-18012 : AMS Metrics Sink unable to connect to zookeeper to locate collector host.
[
https://issues.apache.org/jira/browse/AMBARI-18012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated AMBARI-18012:
---
Summary: AMBARI-18012 : AMS Metrics Sink unable to connect to zookeeper to
locate collector host. (was: Metrics Sink unable to connect to zookeeper)
> AMBARI-18012 : AMS Metrics Sink unable to connect to zookeeper to locate
> collector host.
>
>
> Key: AMBARI-18012
> URL: https://issues.apache.org/jira/browse/AMBARI-18012
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18012.patch
>
>
> Test and validate sink fallback connect to ZK for finding collector
> {code}
> 2016-07-14 20:37:01,212 INFO timeline.HadoopTimelineMetricsSink
> (AbstractTimelineMetricsSink.java:findPreferredCollectHost(353)) - Collector
> ambari-sid-5.c.pramod-thangali.internal is not longer live. Removing it from
> list of know live collector hosts : []
> 2016-07-14 20:37:03,213 WARN availability.MetricCollectorHAHelper
> (MetricCollectorHAHelper.java:findLiveCollectorHostsFromZNode(83)) - Unable
> to connect to zookeeper.
> java.lang.IllegalStateException: Client is not started
> at
> org.apache.hadoop.metrics2.sink.relocated.google.common.base.Preconditions.checkState(Preconditions.java:149)
> at
> org.apache.hadoop.metrics2.sink.relocated.curator.CuratorZookeeperClient.getZooKeeper(CuratorZookeeperClient.java:113)
> at
> org.apache.hadoop.metrics2.sink.timeline.availability.MetricCollectorHAHelper$1.call(MetricCollectorHAHelper.java:77)
> at
> org.apache.hadoop.metrics2.sink.timeline.availability.MetricCollectorHAHelper$1.call(MetricCollectorHAHelper.java:74)
> at
> org.apache.hadoop.metrics2.sink.relocated.curator.RetryLoop.callWithRetry(RetryLoop.java:107)
> at
> org.apache.hadoop.metrics2.sink.timeline.availability.MetricCollectorHAHelper.findLiveCollectorHostsFromZNode(MetricCollectorHAHelper.java:74)
> at
> org.apache.hadoop.metrics2.sink.timeline.AbstractTimelineMetricsSink.findPreferredCollectHost(AbstractTimelineMetricsSink.java:363)
> at
> org.apache.hadoop.metrics2.sink.timeline.AbstractTimelineMetricsSink.emitMetrics(AbstractTimelineMetricsSink.java:209)
> at
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:315)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> 2016-07-14 20:37:03,245 WARN timeline.HadoopTimelineMetricsSink
> (AbstractTimelineMetricsSink.java:findLiveCollectorHostsFromKnownCollector(433))
> - Unable to conne
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17749) Typo "rather then" in spark-default.conf
[ https://issues.apache.org/jira/browse/AMBARI-17749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-17749: - Resolution: Fixed Status: Resolved (was: Patch Available) Pushed to trunk, commit aa2930a4a696f721934e0608d1dccf206a2fad9f > Typo "rather then" in spark-default.conf > > > Key: AMBARI-17749 > URL: https://issues.apache.org/jira/browse/AMBARI-17749 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk > Environment: CentOS7.2, HDP2.4, Spark1.6.1 >Reporter: Masahiro Tanaka >Assignee: Masahiro Tanaka >Priority: Trivial > Fix For: trunk > > Attachments: AMBARI-17749.patch, spark-configu-description.PNG > > > There is a typo in Spark config description. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17749) Typo "rather then" in spark-default.conf
[ https://issues.apache.org/jira/browse/AMBARI-17749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-17749: - Fix Version/s: (was: 2.5.0) > Typo "rather then" in spark-default.conf > > > Key: AMBARI-17749 > URL: https://issues.apache.org/jira/browse/AMBARI-17749 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk > Environment: CentOS7.2, HDP2.4, Spark1.6.1 >Reporter: Masahiro Tanaka >Assignee: Masahiro Tanaka >Priority: Trivial > Fix For: trunk > > Attachments: AMBARI-17749.patch, spark-configu-description.PNG > > > There is a typo in Spark config description. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17749) Typo "rather then" in spark-default.conf
[ https://issues.apache.org/jira/browse/AMBARI-17749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-17749: - Fix Version/s: trunk > Typo "rather then" in spark-default.conf > > > Key: AMBARI-17749 > URL: https://issues.apache.org/jira/browse/AMBARI-17749 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk > Environment: CentOS7.2, HDP2.4, Spark1.6.1 >Reporter: Masahiro Tanaka >Assignee: Masahiro Tanaka >Priority: Trivial > Fix For: trunk > > Attachments: AMBARI-17749.patch, spark-configu-description.PNG > > > There is a typo in Spark config description. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18084) Install Wizard: Unable to delete custom properties from Misc -> Notifications section
[ https://issues.apache.org/jira/browse/AMBARI-18084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413885#comment-15413885 ] Hudson commented on AMBARI-18084: - FAILURE: Integrated in Ambari-trunk-Commit #5489 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5489/]) AMBARI-18084. Install Wizard: Unable to delete custom properties from (hiveww: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=a1b6d516c136147cb3acaf65dfe85c0abb9d5426]) * ambari-web/app/templates/common/configs/notifications_configs.hbs > Install Wizard: Unable to delete custom properties from Misc -> Notifications > section > - > > Key: AMBARI-18084 > URL: https://issues.apache.org/jira/browse/AMBARI-18084 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Blocker > Fix For: 2.4.0 > > Attachments: AMBARI-18084.patch > > > User can add custom properties to Misc -> Notifications section at configs > step of installer. Delete action doesn't work for them: 'Remove' button click > has no effect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17951) Introduce validation of hostgroup mapping for active/standby namenode
[ https://issues.apache.org/jira/browse/AMBARI-17951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amruta Borkar updated AMBARI-17951: --- Status: Patch Available (was: In Progress) > 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-v1.patch, 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-17951) Introduce validation of hostgroup mapping for active/standby namenode
[ https://issues.apache.org/jira/browse/AMBARI-17951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amruta Borkar updated AMBARI-17951: --- Attachment: AMBARI-17951-v4.patch > 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-v1.patch, 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-17951) Introduce validation of hostgroup mapping for active/standby namenode
[ https://issues.apache.org/jira/browse/AMBARI-17951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amruta Borkar updated AMBARI-17951: --- Status: Open (was: Patch Available) > 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-v1.patch, AMBARI-17951-v2, > AMBARI-17951-v3.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] [Commented] (AMBARI-17785) Provide support for S3 as a first class destination for log events
[ https://issues.apache.org/jira/browse/AMBARI-17785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413762#comment-15413762 ] Hudson commented on AMBARI-17785: - FAILURE: Integrated in Ambari-trunk-Commit #5488 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5488/]) AMBARI-17785. Provide support for S3 as a first class destination for (oleewere: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=6dcf638192e8abff967c405cc9ef01b4dfc3b764]) * ambari-logsearch/ambari-logsearch-logfeeder/src/test/java/org/apache/ambari/logfeeder/output/S3UploaderTest.java * ambari-logsearch/ambari-logsearch-logfeeder/src/test/java/org/apache/ambari/logfeeder/output/OutputS3FileTest.java * ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/output/S3OutputConfiguration.java * ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/s3/S3Util.java * ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/output/OutputS3File.java * ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/output/S3Uploader.java * ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/output/S3LogPathResolver.java * ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/output/spool/LogSpooler.java * ambari-logsearch/ambari-logsearch-logfeeder/src/test/java/org/apache/ambari/logfeeder/output/spool/LogSpoolerTest.java * ambari-logsearch/ambari-logsearch-logfeeder/src/test/java/org/apache/ambari/logfeeder/output/S3LogPathResolverTest.java * ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/input/InputMarker.java > Provide support for S3 as a first class destination for log events > -- > > Key: AMBARI-17785 > URL: https://issues.apache.org/jira/browse/AMBARI-17785 > Project: Ambari > Issue Type: Improvement > Components: ambari-logsearch >Affects Versions: 2.4.0 >Reporter: Hemanth Yamijala >Assignee: Hemanth Yamijala > Fix For: 2.5.0 > > Attachments: AMBARI-17785-1.patch, AMBARI-17785-2.patch, > AMBARI-17785.patch > > > AMBARI-17045 added support for uploading Hadoop service logs from machines to > S3. The intended usage there was as a one time trigger where, on-demand, the > log files matching certain paths can be uploaded to a given S3 bucket and > path. > While useful, there are some use cases where we might need more than this one > time activity, particularly when clusters are deployed on ephemeral machines > such as cloud instances: > * The machines running the logfeeder could be irrevocably lost and in that > case we would not be able to retrieve any logs. > * If we are copying logs at one time, that were generated over a long period > of time, the time to copy all the logs at the end could extend cluster > up-time and cost. > It would be nice to have an ability to support S3 as another output > destination in logsearch just like Kafka, Solr etc. This JIRA is to track > work towards this enhancement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17991) Ambari agent unable to register with server when server response is too big
[
https://issues.apache.org/jira/browse/AMBARI-17991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413737#comment-15413737
]
Hadoop QA commented on AMBARI-17991:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12822807/AMBARI-17991_3-branch-2.4.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/8344//console
This message is automatically generated.
> Ambari agent unable to register with server when server response is too big
> ---
>
> Key: AMBARI-17991
> URL: https://issues.apache.org/jira/browse/AMBARI-17991
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17991.patch, AMBARI-17991_2.patch,
> AMBARI-17991_3-branch-2.4.patch, AMBARI-17991_3-trunk.patch
>
>
> Ambari agent is unable to register with ambari server, failing with:
> {code}
> INFO 2016-06-09 11:22:00,964 security.py:147 - Encountered communication
> error. Details: SSLError('The read operation timed out',)
> ERROR 2016-06-09 11:22:00,965 Controller.py:196 - Unable to connect to:
> https://localhost:8441/agent/v1/register/dvtcbdqd02.corp.cox.com
> Traceback (most recent call last):
> File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line
> 150, in registerWithServer
> ret = self.sendRequest(self.registerUrl, data)
> File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line
> 423, in sendRequest
> raise IOError('Request to {0} failed due to {1}'.format(url,
> str(exception)))
> IOError: Request to https://server1:8441/agent/v1/register/host1 failed due
> to Error occured during connecting to the server: The read operation timed out
> ERROR 2016-06-09 11:22:00,965 Controller.py:197 - Error:Request to
> https://server1:8441/agent/v1/register/host1 failed due to Error occured
> during connecting to the server: The read operation timed out
> {code}
> The problem was fixed by modifying the timeout in
> /usr/lib/python2.6/site-packages/ambari_agent/security.py:
> {code}
> def create_connection(self):
> if self.sock:
> self.sock.close()
> logger.info("SSL Connect being called.. connecting to the server")
> sock = socket.create_connection((self.host, self.port), 120)
> {code}
> Use Jetty 8 instead of 9 in Ambari 2.4.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17991) Ambari agent unable to register with server when server response is too big
[
https://issues.apache.org/jira/browse/AMBARI-17991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmytro Sen updated AMBARI-17991:
Status: Patch Available (was: Reopened)
> Ambari agent unable to register with server when server response is too big
> ---
>
> Key: AMBARI-17991
> URL: https://issues.apache.org/jira/browse/AMBARI-17991
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17991.patch, AMBARI-17991_2.patch,
> AMBARI-17991_3-branch-2.4.patch, AMBARI-17991_3-trunk.patch
>
>
> Ambari agent is unable to register with ambari server, failing with:
> {code}
> INFO 2016-06-09 11:22:00,964 security.py:147 - Encountered communication
> error. Details: SSLError('The read operation timed out',)
> ERROR 2016-06-09 11:22:00,965 Controller.py:196 - Unable to connect to:
> https://localhost:8441/agent/v1/register/dvtcbdqd02.corp.cox.com
> Traceback (most recent call last):
> File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line
> 150, in registerWithServer
> ret = self.sendRequest(self.registerUrl, data)
> File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line
> 423, in sendRequest
> raise IOError('Request to {0} failed due to {1}'.format(url,
> str(exception)))
> IOError: Request to https://server1:8441/agent/v1/register/host1 failed due
> to Error occured during connecting to the server: The read operation timed out
> ERROR 2016-06-09 11:22:00,965 Controller.py:197 - Error:Request to
> https://server1:8441/agent/v1/register/host1 failed due to Error occured
> during connecting to the server: The read operation timed out
> {code}
> The problem was fixed by modifying the timeout in
> /usr/lib/python2.6/site-packages/ambari_agent/security.py:
> {code}
> def create_connection(self):
> if self.sock:
> self.sock.close()
> logger.info("SSL Connect being called.. connecting to the server")
> sock = socket.create_connection((self.host, self.port), 120)
> {code}
> Use Jetty 8 instead of 9 in Ambari 2.4.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18084) Install Wizard: Unable to delete custom properties from Misc -> Notifications section
[ https://issues.apache.org/jira/browse/AMBARI-18084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-18084: - Resolution: Fixed Status: Resolved (was: Patch Available) committed to trunk and branch-2.4 > Install Wizard: Unable to delete custom properties from Misc -> Notifications > section > - > > Key: AMBARI-18084 > URL: https://issues.apache.org/jira/browse/AMBARI-18084 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Blocker > Fix For: 2.4.0 > > Attachments: AMBARI-18084.patch > > > User can add custom properties to Misc -> Notifications section at configs > step of installer. Delete action doesn't work for them: 'Remove' button click > has no effect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18084) Install Wizard: Unable to delete custom properties from Misc -> Notifications section
[ https://issues.apache.org/jira/browse/AMBARI-18084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413698#comment-15413698 ] Antonenko Alexander commented on AMBARI-18084: -- 29495 tests complete (25 seconds) 154 tests pending rat check passed > Install Wizard: Unable to delete custom properties from Misc -> Notifications > section > - > > Key: AMBARI-18084 > URL: https://issues.apache.org/jira/browse/AMBARI-18084 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Blocker > Fix For: 2.4.0 > > Attachments: AMBARI-18084.patch > > > User can add custom properties to Misc -> Notifications section at configs > step of installer. Delete action doesn't work for them: 'Remove' button click > has no effect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18077) Clean up Log Search Appender and improve speed
[
https://issues.apache.org/jira/browse/AMBARI-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413684#comment-15413684
]
Hadoop QA commented on AMBARI-18077:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12822776/AMBARI-18077.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/8343//console
This message is automatically generated.
> Clean up Log Search Appender and improve speed
> --
>
> Key: AMBARI-18077
> URL: https://issues.apache.org/jira/browse/AMBARI-18077
> Project: Ambari
> Issue Type: Task
> Components: ambari-logsearch
>Affects Versions: 2.5.0
>Reporter: Miklos Gergely
>Assignee: Miklos Gergely
> Fix For: 2.5.0
>
> Attachments: AMBARI-18077.patch
>
>
> Log Search appender is a bit messy and it also uses reflection to which is
> slow for something as heavily used as a log appender.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18084) Install Wizard: Unable to delete custom properties from Misc -> Notifications section
[ https://issues.apache.org/jira/browse/AMBARI-18084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-18084: - Status: Patch Available (was: Open) > Install Wizard: Unable to delete custom properties from Misc -> Notifications > section > - > > Key: AMBARI-18084 > URL: https://issues.apache.org/jira/browse/AMBARI-18084 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Blocker > Fix For: 2.4.0 > > Attachments: AMBARI-18084.patch > > > User can add custom properties to Misc -> Notifications section at configs > step of installer. Delete action doesn't work for them: 'Remove' button click > has no effect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18084) Install Wizard: Unable to delete custom properties from Misc -> Notifications section
Antonenko Alexander created AMBARI-18084: Summary: Install Wizard: Unable to delete custom properties from Misc -> Notifications section Key: AMBARI-18084 URL: https://issues.apache.org/jira/browse/AMBARI-18084 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.4.0 Reporter: Antonenko Alexander Assignee: Antonenko Alexander Priority: Blocker Fix For: 2.4.0 User can add custom properties to Misc -> Notifications section at configs step of installer. Delete action doesn't work for them: 'Remove' button click has no effect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18082) Dependent configs disappear without any warning
[ https://issues.apache.org/jira/browse/AMBARI-18082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413528#comment-15413528 ] Andrii Babiichuk commented on AMBARI-18082: --- +1 for the patch > Dependent configs disappear without any warning > --- > > Key: AMBARI-18082 > URL: https://issues.apache.org/jira/browse/AMBARI-18082 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Aleksandr Kovalenko >Assignee: Aleksandr Kovalenko >Priority: Blocker > Fix For: 2.4.0 > > Attachments: AMBARI-18082.patch > > > STR: > 1. Install Ambari with Hive and YARN. > 2. Enable Interactive Query. > 3. Create 2 config groups for YARN. Add some host for first one, second one > leave without hosts. > 4. Create config group with some host for Hive. > 5. Add override for Cluster Capacity for Hive config group, save changes, > apply dependent config for YARN to YARN config group with host. > 6. Go to YARN configs and remove added dependent override. > As a result override for Cluster Capacity disappears. There were no warning > when saving YARN configs, that some Hive configs will be changed. > Options -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18082) Dependent configs disappear without any warning
[
https://issues.apache.org/jira/browse/AMBARI-18082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413515#comment-15413515
]
Hadoop QA commented on AMBARI-18082:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12822790/AMBARI-18082.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/8340//console
This message is automatically generated.
> Dependent configs disappear without any warning
> ---
>
> Key: AMBARI-18082
> URL: https://issues.apache.org/jira/browse/AMBARI-18082
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Aleksandr Kovalenko
>Assignee: Aleksandr Kovalenko
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-18082.patch
>
>
> STR:
> 1. Install Ambari with Hive and YARN.
> 2. Enable Interactive Query.
> 3. Create 2 config groups for YARN. Add some host for first one, second one
> leave without hosts.
> 4. Create config group with some host for Hive.
> 5. Add override for Cluster Capacity for Hive config group, save changes,
> apply dependent config for YARN to YARN config group with host.
> 6. Go to YARN configs and remove added dependent override.
> As a result override for Cluster Capacity disappears. There were no warning
> when saving YARN configs, that some Hive configs will be changed.
> Options
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18082) Dependent configs disappear without any warning
[ https://issues.apache.org/jira/browse/AMBARI-18082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Kovalenko updated AMBARI-18082: - Attachment: AMBARI-18082.patch > Dependent configs disappear without any warning > --- > > Key: AMBARI-18082 > URL: https://issues.apache.org/jira/browse/AMBARI-18082 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Aleksandr Kovalenko >Assignee: Aleksandr Kovalenko >Priority: Blocker > Fix For: 2.4.0 > > Attachments: AMBARI-18082.patch > > > STR: > 1. Install Ambari with Hive and YARN. > 2. Enable Interactive Query. > 3. Create 2 config groups for YARN. Add some host for first one, second one > leave without hosts. > 4. Create config group with some host for Hive. > 5. Add override for Cluster Capacity for Hive config group, save changes, > apply dependent config for YARN to YARN config group with host. > 6. Go to YARN configs and remove added dependent override. > As a result override for Cluster Capacity disappears. There were no warning > when saving YARN configs, that some Hive configs will be changed. > Options -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18082) Dependent configs disappear without any warning
[ https://issues.apache.org/jira/browse/AMBARI-18082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Kovalenko updated AMBARI-18082: - Status: Patch Available (was: Open) > Dependent configs disappear without any warning > --- > > Key: AMBARI-18082 > URL: https://issues.apache.org/jira/browse/AMBARI-18082 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Aleksandr Kovalenko >Assignee: Aleksandr Kovalenko >Priority: Blocker > Fix For: 2.4.0 > > Attachments: AMBARI-18082.patch > > > STR: > 1. Install Ambari with Hive and YARN. > 2. Enable Interactive Query. > 3. Create 2 config groups for YARN. Add some host for first one, second one > leave without hosts. > 4. Create config group with some host for Hive. > 5. Add override for Cluster Capacity for Hive config group, save changes, > apply dependent config for YARN to YARN config group with host. > 6. Go to YARN configs and remove added dependent override. > As a result override for Cluster Capacity disappears. There were no warning > when saving YARN configs, that some Hive configs will be changed. > Options -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18082) Dependent configs disappear without any warning
Aleksandr Kovalenko created AMBARI-18082: Summary: Dependent configs disappear without any warning Key: AMBARI-18082 URL: https://issues.apache.org/jira/browse/AMBARI-18082 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.4.0 Reporter: Aleksandr Kovalenko Assignee: Aleksandr Kovalenko Priority: Blocker Fix For: 2.4.0 STR: 1. Install Ambari with Hive and YARN. 2. Enable Interactive Query. 3. Create 2 config groups for YARN. Add some host for first one, second one leave without hosts. 4. Create config group with some host for Hive. 5. Add override for Cluster Capacity for Hive config group, save changes, apply dependent config for YARN to YARN config group with host. 6. Go to YARN configs and remove added dependent override. As a result override for Cluster Capacity disappears. There were no warning when saving YARN configs, that some Hive configs will be changed. Options -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17785) Provide support for S3 as a first class destination for log events
[
https://issues.apache.org/jira/browse/AMBARI-17785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413495#comment-15413495
]
Olivér Szabó commented on AMBARI-17785:
---
committed to trunk:
{code:java}
commit 6dcf638192e8abff967c405cc9ef01b4dfc3b764
Author: oleewere
Date: Tue Aug 9 15:08:13 2016 +0200
AMBARI-17785. Provide support for S3 as a first class destination for log
events (Hemanth Yamijala via oleewere)
{code}
As the fix version is 2.5 keep this jira open until its not merged into
branch-2.5
> Provide support for S3 as a first class destination for log events
> --
>
> Key: AMBARI-17785
> URL: https://issues.apache.org/jira/browse/AMBARI-17785
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-logsearch
>Affects Versions: 2.4.0
>Reporter: Hemanth Yamijala
>Assignee: Hemanth Yamijala
> Fix For: 2.5.0
>
> Attachments: AMBARI-17785-1.patch, AMBARI-17785-2.patch,
> AMBARI-17785.patch
>
>
> AMBARI-17045 added support for uploading Hadoop service logs from machines to
> S3. The intended usage there was as a one time trigger where, on-demand, the
> log files matching certain paths can be uploaded to a given S3 bucket and
> path.
> While useful, there are some use cases where we might need more than this one
> time activity, particularly when clusters are deployed on ephemeral machines
> such as cloud instances:
> * The machines running the logfeeder could be irrevocably lost and in that
> case we would not be able to retrieve any logs.
> * If we are copying logs at one time, that were generated over a long period
> of time, the time to copy all the logs at the end could extend cluster
> up-time and cost.
> It would be nice to have an ability to support S3 as another output
> destination in logsearch just like Kafka, Solr etc. This JIRA is to track
> work towards this enhancement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18080) EU/RU merges empty storm.topology.submission.notifier.plugin.class which cause service check to fail
Dmytro Grinenko created AMBARI-18080: Summary: EU/RU merges empty storm.topology.submission.notifier.plugin.class which cause service check to fail Key: AMBARI-18080 URL: https://issues.apache.org/jira/browse/AMBARI-18080 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.4.0 Reporter: Dmytro Grinenko Priority: Blocker Fix For: 2.4.0 *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-18077) Clean up Log Search Appender and improve speed
[ https://issues.apache.org/jira/browse/AMBARI-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miklos Gergely updated AMBARI-18077: Status: Patch Available (was: In Progress) > Clean up Log Search Appender and improve speed > -- > > Key: AMBARI-18077 > URL: https://issues.apache.org/jira/browse/AMBARI-18077 > Project: Ambari > Issue Type: Task > Components: ambari-logsearch >Affects Versions: 2.5.0 >Reporter: Miklos Gergely >Assignee: Miklos Gergely > Fix For: 2.5.0 > > Attachments: AMBARI-18077.patch > > > Log Search appender is a bit messy and it also uses reflection to which is > slow for something as heavily used as a log appender. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18081) EU/RU merges empty storm.topology.submission.notifier.plugin.class which cause service check to fail
Dmytro Grinenko created AMBARI-18081: Summary: 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 Priority: Blocker Fix For: 2.4.0 *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-17778) Add usage information in ambari-server script
[
https://issues.apache.org/jira/browse/AMBARI-17778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masahiro Tanaka updated AMBARI-17778:
-
Resolution: Resolved
Fix Version/s: trunk
Status: Resolved (was: Patch Available)
> Add usage information in ambari-server script
> -
>
> Key: AMBARI-17778
> URL: https://issues.apache.org/jira/browse/AMBARI-17778
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: trunk
> Environment: CentOS7.2, Ambari 2.4.0
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
>Priority: Minor
> Fix For: trunk
>
> Attachments: AMBARI-17778.patch
>
>
> In ambari-server script, there are some lacks of usage information (e.g.
> {{install-mpack, upgrade-mpack}}.)
> They should be included in usage information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18079) Update the date range picker with the latest version.
[ https://issues.apache.org/jira/browse/AMBARI-18079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dharmesh Makwana updated AMBARI-18079: -- Description: Updating the daterangepicker with the latest version to fix the issue which was faced lately in https://issues.apache.org/jira/browse/AMBARI-18054. Though it was fixed in that jira but was temp fix in plugin itself. (was: Updating the daterangepicker with the latest version to fix the issue which was faced lately in https://issues.apache.org/jira/browse/AMBARI-18054. Though it was fixed in that jira but was temp fix due to time constraint.) > Update the date range picker with the latest version. > - > > Key: AMBARI-18079 > URL: https://issues.apache.org/jira/browse/AMBARI-18079 > Project: Ambari > Issue Type: Improvement > Components: logsearch >Affects Versions: 2.4.0 >Reporter: Dharmesh Makwana >Assignee: Dharmesh Makwana > Fix For: 2.5.0 > > > Updating the daterangepicker with the latest version to fix the issue which > was faced lately in https://issues.apache.org/jira/browse/AMBARI-18054. > Though it was fixed in that jira but was temp fix in plugin itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18024) Pig view not loading After opening huetoambari view.
[
https://issues.apache.org/jira/browse/AMBARI-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413454#comment-15413454
]
Hadoop QA commented on AMBARI-18024:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12822774/AMBARI-18024.1_trunk.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/8339//console
This message is automatically generated.
> Pig view not loading After opening huetoambari view.
>
>
> Key: AMBARI-18024
> URL: https://issues.apache.org/jira/browse/AMBARI-18024
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.4.0
> Environment: ambari-metrics-hadoop-sink-2.4.0.0-1069.x86_64
> ambari-agent-2.4.0.0-1069.x86_64
> ambari-metrics-monitor-2.4.0.0-1069.x86_64
> Centos 6.4
>Reporter: Pradarttana
> Labels: None
> Fix For: 2.4.0
>
> Attachments: AMBARI-18024.1_trunk.patch, AMBARI-18024_trunk.patch
>
>
> PROBLEM: Pig view not loading
> IMPACT: can't use it
> STEPS TO REPRODUCE:
> 1. create instance of hue to view migration tool
> 2. create instance of pig view
> 3. open pig view
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18073) Text change of Audit to DB Removal during upgrade for Ranger
[
https://issues.apache.org/jira/browse/AMBARI-18073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413452#comment-15413452
]
Hadoop QA commented on AMBARI-18073:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12822781/AMBARI-18073.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/8338//console
This message is automatically generated.
> Text change of Audit to DB Removal during upgrade for Ranger
>
>
> Key: AMBARI-18073
> URL: https://issues.apache.org/jira/browse/AMBARI-18073
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
> Fix For: 2.4.0
>
> Attachments: AMBARI-18073.patch
>
>
> Changing text during upgrade of Ranger for Audit to DB removal
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18079) Update the date range picker with the latest version.
[ https://issues.apache.org/jira/browse/AMBARI-18079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dharmesh Makwana updated AMBARI-18079: -- Fix Version/s: (was: 2.4.0) 2.5.0 > Update the date range picker with the latest version. > - > > Key: AMBARI-18079 > URL: https://issues.apache.org/jira/browse/AMBARI-18079 > Project: Ambari > Issue Type: Improvement > Components: logsearch >Affects Versions: 2.4.0 >Reporter: Dharmesh Makwana >Assignee: Dharmesh Makwana > Fix For: 2.5.0 > > > Updating the daterangepicker with the latest version to fix the issue which > was faced lately in https://issues.apache.org/jira/browse/AMBARI-18054. > Though it was fixed in that jira but was temp fix due to time constraint. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18078) Smartsense start fails after reinstall service
Shreya Bhat created AMBARI-18078:
Summary: Smartsense start fails after reinstall service
Key: AMBARI-18078
URL: https://issues.apache.org/jira/browse/AMBARI-18078
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Shreya Bhat
Priority: Critical
Fix For: 2.4.0
Smartsense service start is failing with :
{code}
"stderr" : "Failed to execute command: export JAVA_HOME=/usr/jdk64/jdk1.7.0_67;
/usr/sbin/hst activity-explorer start ; Exit code: 1; stdout: Std Out: Pid dir
doesn't exist, create /var/run/smartsense-activity\nZeppelin start
\u001B[60G[\u001B[0;32m OK \u001B[0;39m]\r\nZeppelin process died
\u001B[60G[\u001B[0;31mFAILED\u001B[0;39m]\r\n\nStd Err: mkdir: cannot create
directory ‘/var/run/smartsense-activity’: Permission
denied\n/usr/hdp/share/hst/activity-explorer/bin/zeppelin-daemon.sh: line 187:
/var/run/smartsense-activity/activity-explorer.pid: No such file or
directory\ncat: /var/run/smartsense-activity/activity-explorer.pid: No such
file or directory\n\n; stderr: Failed to execute command:
/usr/hdp/share/hst/activity-explorer/bin/zeppelin-daemon.sh --config
/etc/smartsense-activity/conf start ; Exit code: 1; stdout: Pid dir doesn't
exist, create /var/run/smartsense-activity\nZeppelin start
\u001B[60G[\u001B[0;32m OK \u001B[0;39m]\r\nZeppelin process died
\u001B[60G[\u001B[0;31mFAILED\u001B[0;39m]\r\n; stderr: mkdir: cannot create
directory ‘/var/run/smartsense-activity’: Permission
denied\n/usr/hdp/share/hst/activity-explorer/bin/zeppelin-daemon.sh: line 187:
/var/run/smartsense-activity/activity-explorer.pid: No such file or
directory\ncat: /var/run/smartsense-activity/activity-explorer.pid: No such
file or directory",
{code}
STR :
1. Install smartsense
2. Delete smartsense
3. Install smartsense.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18073) Text change of Audit to DB Removal during upgrade for Ranger
[ https://issues.apache.org/jira/browse/AMBARI-18073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mugdha Varadkar updated AMBARI-18073: - Attachment: AMBARI-18073.patch > Text change of Audit to DB Removal during upgrade for Ranger > > > Key: AMBARI-18073 > URL: https://issues.apache.org/jira/browse/AMBARI-18073 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Mugdha Varadkar >Assignee: Mugdha Varadkar > Fix For: 2.4.0 > > Attachments: AMBARI-18073.patch > > > Changing text during upgrade of Ranger for Audit to DB removal -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18073) Text change of Audit to DB Removal during upgrade for Ranger
[ https://issues.apache.org/jira/browse/AMBARI-18073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mugdha Varadkar updated AMBARI-18073: - Attachment: (was: AMBARI-18073.patch) > Text change of Audit to DB Removal during upgrade for Ranger > > > Key: AMBARI-18073 > URL: https://issues.apache.org/jira/browse/AMBARI-18073 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Mugdha Varadkar >Assignee: Mugdha Varadkar > Fix For: 2.4.0 > > > Changing text during upgrade of Ranger for Audit to DB removal -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (AMBARI-17182) App timeline Server start fails on enabling HA because namenode is in safemode
[
https://issues.apache.org/jira/browse/AMBARI-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Onischuk updated AMBARI-17182:
-
Comment: was deleted
(was: Done. Thanks for committing [~smagyari])
> App timeline Server start fails on enabling HA because namenode is in safemode
> --
>
> Key: AMBARI-17182
> URL: https://issues.apache.org/jira/browse/AMBARI-17182
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Victor Galgo
>Priority: Critical
> Labels: ha, namenode
> Fix For: 2.4.0
>
> Attachments: nnha_fix.patch
>
>
> On the last step "Start all" on enabling HA below happens:
> {code}
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/application_timeline_server.py",
> line 147, in
> ApplicationTimelineServer().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 219, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/application_timeline_server.py",
> line 43, in start
> self.configure(env) # FOR SECURITY
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/application_timeline_server.py",
> line 54, in configure
> yarn(name='apptimelineserver')
> 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/YARN/2.1.0.2.0/package/scripts/yarn.py",
> line 276, in yarn
> mode=0755
> 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/libraries/providers/hdfs_resource.py",
> line 463, in action_create_on_execute
> self.action_delayed("create")
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 460, in action_delayed
> self.get_hdfs_resource_executor().action_delayed(action_name, self)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 259, in action_delayed
> self._set_mode(self.target_status)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 366, in _set_mode
> self.util.run_command(self.main_resource.resource.target,
> 'SETPERMISSION', method='PUT', permission=self.mode, assertable_result=False)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 195, in run_command
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'curl -sS -L -w
> '%{http_code}' -X PUT
> 'http://os-s11-3-iavzl-nat-s-ru242to25susesecha-12.openstacklocal:50070/webhdfs/v1/ats/done?op=SETPERMISSION=hdfs=755''
> returned status_code=403.
> {
> "RemoteException": {
> "exception": "RetriableException",
> "javaClassName": "org.apache.hadoop.ipc.RetriableException",
> "message": "org.apache.hadoop.hdfs.server.namenode.SafeModeException:
> Cannot set permission for /ats/done. Name node is in safe mode.\nThe reported
> blocks 675 needs additional 16 blocks to reach the threshold 0.9900 of total
> blocks 697.\nThe number of live datanodes 20 has reached the minimum number
> 0. Safe mode will be turned off automatically once the thresholds have been
> reached."
> }
> }
> {code}
> This happens because NN is not yet out of safemode at the moment of ats
> start, because DNs just started.
> To fix this "stop namenodes" has to be triggered before "start all".
> If this is done, on "Start all" it will be ensured that datanodes start prior
> to NN, and that NN are out of safemode before ATS start.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17182) App timeline Server start fails on enabling HA because namenode is in safemode
[
https://issues.apache.org/jira/browse/AMBARI-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413407#comment-15413407
]
Andrew Onischuk commented on AMBARI-17182:
--
Done. Thanks for committing [~smagyari]
> App timeline Server start fails on enabling HA because namenode is in safemode
> --
>
> Key: AMBARI-17182
> URL: https://issues.apache.org/jira/browse/AMBARI-17182
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Victor Galgo
>Priority: Critical
> Labels: ha, namenode
> Fix For: 2.4.0
>
> Attachments: nnha_fix.patch
>
>
> On the last step "Start all" on enabling HA below happens:
> {code}
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/application_timeline_server.py",
> line 147, in
> ApplicationTimelineServer().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 219, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/application_timeline_server.py",
> line 43, in start
> self.configure(env) # FOR SECURITY
> File
> "/var/lib/ambari-agent/cache/common-services/YARN/2.1.0.2.0/package/scripts/application_timeline_server.py",
> line 54, in configure
> yarn(name='apptimelineserver')
> 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/YARN/2.1.0.2.0/package/scripts/yarn.py",
> line 276, in yarn
> mode=0755
> 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/libraries/providers/hdfs_resource.py",
> line 463, in action_create_on_execute
> self.action_delayed("create")
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 460, in action_delayed
> self.get_hdfs_resource_executor().action_delayed(action_name, self)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 259, in action_delayed
> self._set_mode(self.target_status)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 366, in _set_mode
> self.util.run_command(self.main_resource.resource.target,
> 'SETPERMISSION', method='PUT', permission=self.mode, assertable_result=False)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
> line 195, in run_command
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'curl -sS -L -w
> '%{http_code}' -X PUT
> 'http://os-s11-3-iavzl-nat-s-ru242to25susesecha-12.openstacklocal:50070/webhdfs/v1/ats/done?op=SETPERMISSION=hdfs=755''
> returned status_code=403.
> {
> "RemoteException": {
> "exception": "RetriableException",
> "javaClassName": "org.apache.hadoop.ipc.RetriableException",
> "message": "org.apache.hadoop.hdfs.server.namenode.SafeModeException:
> Cannot set permission for /ats/done. Name node is in safe mode.\nThe reported
> blocks 675 needs additional 16 blocks to reach the threshold 0.9900 of total
> blocks 697.\nThe number of live datanodes 20 has reached the minimum number
> 0. Safe mode will be turned off automatically once the thresholds have been
> reached."
> }
> }
> {code}
> This happens because NN is not yet out of safemode at the moment of ats
> start, because DNs just started.
> To fix this "stop namenodes" has to be triggered before "start all".
> If this is done, on "Start all" it will be ensured that datanodes start prior
> to NN, and that NN are out of safemode before ATS start.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18067) Alert message cut off
[ https://issues.apache.org/jira/browse/AMBARI-18067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413405#comment-15413405 ] Hudson commented on AMBARI-18067: - FAILURE: Integrated in Ambari-trunk-Commit #5486 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5486/]) AMBARI-18067. Alert message cut off (alexantonenko) (hiveww: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=b86cf6e98fd6ccf25e1d776b10f168a73d5a4261]) * ambari-web/app/styles/alerts.less > Alert message cut off > - > > Key: AMBARI-18067 > URL: https://issues.apache.org/jira/browse/AMBARI-18067 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander > Fix For: trunk > > Attachments: AMBARI-18067.patch, Screen Shot 2016-07-12 at 10.07.34 > AM.png > > > Alert message is cut off mid sentence. I cannot scroll or anything to get the > rest of the message. See screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18077) Clean up Log Search Appender and improve speed
[ https://issues.apache.org/jira/browse/AMBARI-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miklos Gergely updated AMBARI-18077: Attachment: AMBARI-18077.patch > Clean up Log Search Appender and improve speed > -- > > Key: AMBARI-18077 > URL: https://issues.apache.org/jira/browse/AMBARI-18077 > Project: Ambari > Issue Type: Task > Components: ambari-logsearch >Affects Versions: 2.5.0 >Reporter: Miklos Gergely >Assignee: Miklos Gergely > Fix For: 2.5.0 > > Attachments: AMBARI-18077.patch > > > Log Search appender is a bit messy and it also uses reflection to which is > slow for something as heavily used as a log appender. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18024) Pig view not loading After opening huetoambari view.
[ https://issues.apache.org/jira/browse/AMBARI-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pradarttana updated AMBARI-18024: - Attachment: AMBARI-18024.1_trunk.patch > Pig view not loading After opening huetoambari view. > > > Key: AMBARI-18024 > URL: https://issues.apache.org/jira/browse/AMBARI-18024 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.4.0 > Environment: ambari-metrics-hadoop-sink-2.4.0.0-1069.x86_64 > ambari-agent-2.4.0.0-1069.x86_64 > ambari-metrics-monitor-2.4.0.0-1069.x86_64 > Centos 6.4 >Reporter: Pradarttana > Labels: None > Fix For: 2.4.0 > > Attachments: AMBARI-18024.1_trunk.patch, AMBARI-18024_trunk.patch > > > PROBLEM: Pig view not loading > IMPACT: can't use it > STEPS TO REPRODUCE: > 1. create instance of hue to view migration tool > 2. create instance of pig view > 3. open pig view -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18077) Clean up Log Search Appender and improve speed
Miklos Gergely created AMBARI-18077: --- Summary: Clean up Log Search Appender and improve speed Key: AMBARI-18077 URL: https://issues.apache.org/jira/browse/AMBARI-18077 Project: Ambari Issue Type: Task Components: ambari-logsearch Affects Versions: 2.5.0 Reporter: Miklos Gergely Assignee: Miklos Gergely Fix For: 2.5.0 Log Search appender is a bit messy and it also uses reflection to which is slow for something as heavily used as a log appender. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18076) JBehave and docker based Integration Test Framework for Log Search components
Olivér Szabó created AMBARI-18076: - Summary: JBehave and docker based Integration Test Framework for Log Search components Key: AMBARI-18076 URL: https://issues.apache.org/jira/browse/AMBARI-18076 Project: Ambari Issue Type: Bug Components: ambari-logsearch Affects Versions: 2.4.0 Reporter: Olivér Szabó Assignee: Olivér Szabó Fix For: 2.5.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18024) Pig view not loading After opening huetoambari view.
[ https://issues.apache.org/jira/browse/AMBARI-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pradarttana updated AMBARI-18024: - Attachment: AMBARI-18024.1_trunk.patch > Pig view not loading After opening huetoambari view. > > > Key: AMBARI-18024 > URL: https://issues.apache.org/jira/browse/AMBARI-18024 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.4.0 > Environment: ambari-metrics-hadoop-sink-2.4.0.0-1069.x86_64 > ambari-agent-2.4.0.0-1069.x86_64 > ambari-metrics-monitor-2.4.0.0-1069.x86_64 > Centos 6.4 >Reporter: Pradarttana > Labels: None > Fix For: 2.4.0 > > Attachments: AMBARI-18024.1_trunk.patch, AMBARI-18024_trunk.patch > > > PROBLEM: Pig view not loading > IMPACT: can't use it > STEPS TO REPRODUCE: > 1. create instance of hue to view migration tool > 2. create instance of pig view > 3. open pig view -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18074) umask value should less than 18 when check hosts in the step 3 of install ambari
[
https://issues.apache.org/jira/browse/AMBARI-18074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413251#comment-15413251
]
Hadoop QA commented on AMBARI-18074:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12822750/AMBARI-18074.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/8337//console
This message is automatically generated.
> umask value should less than 18 when check hosts in the step 3 of install
> ambari
>
>
> Key: AMBARI-18074
> URL: https://issues.apache.org/jira/browse/AMBARI-18074
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: wuhui
> Fix For: 2.4.0
>
> Attachments: AMBARI-18074.patch
>
>
> if umask value big than 18 ,some hdfs user may not have the privilege to
> operate the hdfs system.
> so i suggest to notice people to revise the umask value when the umask value
> it not narmal in the step 3 of host check.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
