[jira] [Resolved] (AMBARI-15873) Ambari-Server Unit Test failures in trunk
[
https://issues.apache.org/jira/browse/AMBARI-15873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya resolved AMBARI-15873.
Resolution: Fixed
> Ambari-Server Unit Test failures in trunk
> -
>
> Key: AMBARI-15873
> URL: https://issues.apache.org/jira/browse/AMBARI-15873
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Blocker
> Fix For: 2.4.0
>
>
> Unit test failure in ambari-server in trunk
> https://builds.apache.org/job/Ambari-trunk-Commit/4650/console
> Results :
> Failed tests:
> UpgradeCatalog240Test.testExecuteDDLUpdates:227
> Unexpected method call DBAccessor.addColumn("viewinstanceentity",
> org.apache.ambari.server.orm.DBAccessor$DBColumnInfo@1a3492):
> DBAccessor.addColumn("host_role_command",
> capture(org.apache.ambari.server.orm.DBAccessor$DBColumnInfo@1fbce70)):
> expected: 1, actual: 1
> Tests run: 4225, Failures: 1, Errors: 0, Skipped: 32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17391) Spark thriftserver fails to start when umask = 027 due to permission issues on java-opts
[ https://issues.apache.org/jira/browse/AMBARI-17391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374452#comment-15374452 ] Jayush Luniya commented on AMBARI-17391: Trunk: 0fc5b8fd3c474881cff2eaf2ebdafa91068336ae > Spark thriftserver fails to start when umask = 027 due to permission issues > on java-opts > - > > Key: AMBARI-17391 > URL: https://issues.apache.org/jira/browse/AMBARI-17391 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17391.patch > > > AMBARI-16651 added java-opts config file. SparkThriftServer is started as > hive/hadoop user whereas java-opts file is created as spark/spark user. When > umask is set to 0027 STS fails to start due to permission issues on > java-opts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17391) Spark thriftserver fails to start when umask = 027 due to permission issues on java-opts
[ https://issues.apache.org/jira/browse/AMBARI-17391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-17391: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Spark thriftserver fails to start when umask = 027 due to permission issues > on java-opts > - > > Key: AMBARI-17391 > URL: https://issues.apache.org/jira/browse/AMBARI-17391 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17391.patch > > > AMBARI-16651 added java-opts config file. SparkThriftServer is started as > hive/hadoop user whereas java-opts file is created as spark/spark user. When > umask is set to 0027 STS fails to start due to permission issues on > java-opts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-16434) NFSGateway and Phoenix are getting selected by default
[ https://issues.apache.org/jira/browse/AMBARI-16434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya resolved AMBARI-16434. Resolution: Fixed > NFSGateway and Phoenix are getting selected by default > -- > > Key: AMBARI-16434 > URL: https://issues.apache.org/jira/browse/AMBARI-16434 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Sumit Mohanty >Assignee: Jayush Luniya >Priority: Critical > Fix For: 2.4.0 > > Attachments: NFS-PQS-selected.png, recommendation.txt > > > NFSGateway and PQS are selected by default. Seems to be due to recent stack > advisor refactoring. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-14714) Stacks: Support Service Multi-Version and Multi-Instance
[ https://issues.apache.org/jira/browse/AMBARI-14714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-14714: --- Fix Version/s: (was: 2.4.0) > Stacks: Support Service Multi-Version and Multi-Instance > > > Key: AMBARI-14714 > URL: https://issues.apache.org/jira/browse/AMBARI-14714 > Project: Ambari > Issue Type: Epic > Components: stacks >Affects Versions: 2.4.0 >Reporter: Jeff Sposetti >Assignee: Jayush Luniya >Priority: Critical > Fix For: 3.0.0 > > > Provide an ability to handle multiple instances of a Service in a given > cluster. In addition, provide ability for a Stack definition to handle > multiple versions of a given Service (which than can have 0 or more instances > in a given cluster). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-13896) Disable org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.TestClusterSuite unit test
[ https://issues.apache.org/jira/browse/AMBARI-13896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-13896: --- Fix Version/s: (was: 2.4.0) 2.5.0 > Disable > org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.TestClusterSuite > unit test > --- > > Key: AMBARI-13896 > URL: https://issues.apache.org/jira/browse/AMBARI-13896 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.2.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya >Priority: Blocker > Fix For: 2.5.0 > > Attachments: AMBARI-13896.patch > > > Disable > org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.TestClusterSuite > unit test because of unit test failure in trunk. Reenable the UT once the > issue is addressed. > https://builds.apache.org/job/Ambari-trunk-Commit/3820/consoleFull > Running > org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.TestClusterSuite > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x48aeb654, pid=6607, tid=4136434496 > # > # JRE version: 7.0_25-b15 > # Java VM: Java HotSpot(TM) Server VM (23.25-b01 mixed mode linux-x86 ) > # Problematic frame: > # C [libnet.so+0x14654] _fini+0x1d0c > # > # Failed to write core dump. Core dumps have been disabled. To enable core > dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # > /home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-metrics/ambari-metrics-timelineservice/hs_err_pid6607.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > Aborted -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17672) Zeppelin service: Remove sample notebook downloading shell script
[
https://issues.apache.org/jira/browse/AMBARI-17672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374446#comment-15374446
]
Hadoop QA commented on AMBARI-17672:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12817596/AMBARI-17672_trunk%2Bbranch-2.4_v1.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/7808//console
This message is automatically generated.
> Zeppelin service: Remove sample notebook downloading shell script
> -
>
> Key: AMBARI-17672
> URL: https://issues.apache.org/jira/browse/AMBARI-17672
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Anusha Bilgi
>Assignee: Renjith Kamath
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17672_trunk+branch-2.4_v1.patch
>
>
> Sample notebook download script is failing due to lack of permissions on
> multiple OS
> {code}
> "stderr" : "Traceback (most recent call last):\n File
> \"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\",
> line 266, in \nMaster().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 280, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\",
> line 59, in install\nuser=params.zeppelin_user)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\", line
> 155, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
> line 160, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
> line 124, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
> line 273, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 71, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 93, in checked_call\ntries=tries, try_sleep=try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 141, in _call_wrapper\nresult = _call(command, **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 294, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh
> /usr/hdp/current/zeppelin-server ambari-stackviews-6re-3.openstacklocal 9083
> 10001 ambari-stackviews-6re-2.openstacklocal 9995 True
> /var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package
> /usr/lib/jvm/java-7-openjdk-amd64 >> /var/log/zeppelin/zeppelin-setup.log'
> returned 126. Hortonworks #\nThis is MOTD message, added
> for testing in qe infra\n-su:
> /var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh:
> Permission denied",
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-17682) for hive and hbase two properties are present policy.grantrevoke.auth.users & policy.grant.revoke.auth.users
Deepak Sharma created AMBARI-17682: -- Summary: for hive and hbase two properties are present policy.grantrevoke.auth.users & policy.grant.revoke.auth.users Key: AMBARI-17682 URL: https://issues.apache.org/jira/browse/AMBARI-17682 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.4.0 Reporter: Deepak Sharma Fix For: 2.4.0 for hive and hbase following two properties are present policy.grant.revoke.auth.users policy.grantrevoke.auth.users they both looks for same purpose but they are there two times with two diff. name , this is not impacting any flow , but can be considered as an improvement -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
[ https://issues.apache.org/jira/browse/AMBARI-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374435#comment-15374435 ] Prasanth Jayachandran commented on AMBARI-17635: [~dschorow] I must have cloned from some other BUG. Updated it to ambari-server. > Disable async logging for HiveServer2 + Hive 2.x > > > Key: AMBARI-17635 > URL: https://issues.apache.org/jira/browse/AMBARI-17635 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Prasanth Jayachandran >Assignee: Prasanth Jayachandran > Fix For: 2.4.0 > > Attachments: AMBARI-17635.1.patch, AMBARI-17635.2.patch, > AMBARI-17635.3.patch > > > Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's > use of custom log divert appender. We should disable async logging for HS2 > until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
[ https://issues.apache.org/jira/browse/AMBARI-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanth Jayachandran updated AMBARI-17635: --- Component/s: (was: HiveServer2, Metastore, and Client Heap Sizes to Smart Configs) (was: stacks) > Disable async logging for HiveServer2 + Hive 2.x > > > Key: AMBARI-17635 > URL: https://issues.apache.org/jira/browse/AMBARI-17635 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Prasanth Jayachandran >Assignee: Prasanth Jayachandran > Fix For: 2.4.0 > > Attachments: AMBARI-17635.1.patch, AMBARI-17635.2.patch, > AMBARI-17635.3.patch > > > Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's > use of custom log divert appender. We should disable async logging for HS2 > until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374434#comment-15374434
]
Hadoop QA commented on AMBARI-17626:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12817566/AMBARI-17626-July08.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7807//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7807//console
This message is automatically generated.
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17677) Zeppelin service: wrong principal format in zeppelin kerberos.json
[
https://issues.apache.org/jira/browse/AMBARI-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374418#comment-15374418
]
Hudson commented on AMBARI-17677:
-
FAILURE: Integrated in Ambari-trunk-Commit #5289 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5289/])
AMBARI-17677. Zeppelin service: wrong principal format in zeppelin (smohanty:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=028607ac8fb8f435293529d6706ee2332edbf98a])
*
ambari-server/src/main/resources/common-services/ZEPPELIN/0.6.0.2.5/kerberos.json
> Zeppelin service: wrong principal format in zeppelin kerberos.json
> --
>
> Key: AMBARI-17677
> URL: https://issues.apache.org/jira/browse/AMBARI-17677
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Shraddha Sumit
>Assignee: Renjith Kamath
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17677_trunk+branch-2.4_v1.patch
>
>
> Expected format :
> {{$\{zeppelin-env/zeppelin_user\}-$\{cluster_name|toLower()\}@$\{realm\}}}
> Current format: {{zeppelin/$\{cluster_name\}@$\{realm\}}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
[ https://issues.apache.org/jira/browse/AMBARI-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374409#comment-15374409 ] David Schorow commented on AMBARI-17635: [~prasanth_j] - this Jira has very strange components. > Disable async logging for HiveServer2 + Hive 2.x > > > Key: AMBARI-17635 > URL: https://issues.apache.org/jira/browse/AMBARI-17635 > Project: Ambari > Issue Type: Bug > Components: HiveServer2, Metastore, and Client Heap Sizes to Smart > Configs, ambari-server, stacks >Affects Versions: 2.4.0 >Reporter: Prasanth Jayachandran >Assignee: Prasanth Jayachandran > Fix For: 2.4.0 > > Attachments: AMBARI-17635.1.patch, AMBARI-17635.2.patch, > AMBARI-17635.3.patch > > > Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's > use of custom log divert appender. We should disable async logging for HS2 > until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17672) Zeppelin service: Remove sample notebook downloading shell script
[
https://issues.apache.org/jira/browse/AMBARI-17672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Renjith Kamath updated AMBARI-17672:
Attachment: AMBARI-17672_trunk+branch-2.4_v1.patch
> Zeppelin service: Remove sample notebook downloading shell script
> -
>
> Key: AMBARI-17672
> URL: https://issues.apache.org/jira/browse/AMBARI-17672
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Anusha Bilgi
>Assignee: Renjith Kamath
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17672_trunk+branch-2.4_v1.patch
>
>
> Sample notebook download script is failing due to lack of permissions on
> multiple OS
> {code}
> "stderr" : "Traceback (most recent call last):\n File
> \"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\",
> line 266, in \nMaster().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 280, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\",
> line 59, in install\nuser=params.zeppelin_user)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\", line
> 155, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
> line 160, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
> line 124, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
> line 273, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 71, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 93, in checked_call\ntries=tries, try_sleep=try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 141, in _call_wrapper\nresult = _call(command, **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 294, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh
> /usr/hdp/current/zeppelin-server ambari-stackviews-6re-3.openstacklocal 9083
> 10001 ambari-stackviews-6re-2.openstacklocal 9995 True
> /var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package
> /usr/lib/jvm/java-7-openjdk-amd64 >> /var/log/zeppelin/zeppelin-setup.log'
> returned 126. Hortonworks #\nThis is MOTD message, added
> for testing in qe infra\n-su:
> /var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh:
> Permission denied",
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17672) Zeppelin service: Remove sample notebook downloading shell script
[
https://issues.apache.org/jira/browse/AMBARI-17672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374387#comment-15374387
]
Sumit Mohanty commented on AMBARI-17672:
[~rkamath] can you attach the patch to the JIRA? After that if you do a Submit
Patch it will run unit tests against the patch.
> Zeppelin service: Remove sample notebook downloading shell script
> -
>
> Key: AMBARI-17672
> URL: https://issues.apache.org/jira/browse/AMBARI-17672
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Anusha Bilgi
>Assignee: Renjith Kamath
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17672_trunk+branch-2.4_v1.patch
>
>
> Sample notebook download script is failing due to lack of permissions on
> multiple OS
> {code}
> "stderr" : "Traceback (most recent call last):\n File
> \"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\",
> line 266, in \nMaster().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 280, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\",
> line 59, in install\nuser=params.zeppelin_user)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\", line
> 155, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
> line 160, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
> line 124, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
> line 273, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 71, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 93, in checked_call\ntries=tries, try_sleep=try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 141, in _call_wrapper\nresult = _call(command, **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 294, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh
> /usr/hdp/current/zeppelin-server ambari-stackviews-6re-3.openstacklocal 9083
> 10001 ambari-stackviews-6re-2.openstacklocal 9995 True
> /var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package
> /usr/lib/jvm/java-7-openjdk-amd64 >> /var/log/zeppelin/zeppelin-setup.log'
> returned 126. Hortonworks #\nThis is MOTD message, added
> for testing in qe infra\n-su:
> /var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh:
> Permission denied",
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17672) Zeppelin service: Remove sample notebook downloading shell script
[
https://issues.apache.org/jira/browse/AMBARI-17672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Renjith Kamath updated AMBARI-17672:
Component/s: (was: ambari-views)
ambari-server
> Zeppelin service: Remove sample notebook downloading shell script
> -
>
> Key: AMBARI-17672
> URL: https://issues.apache.org/jira/browse/AMBARI-17672
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Anusha Bilgi
>Assignee: Renjith Kamath
>Priority: Blocker
> Fix For: 2.4.0
>
>
> Sample notebook download script is failing due to lack of permissions on
> multiple OS
> {code}
> "stderr" : "Traceback (most recent call last):\n File
> \"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\",
> line 266, in \nMaster().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 280, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\",
> line 59, in install\nuser=params.zeppelin_user)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\", line
> 155, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
> line 160, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
> line 124, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
> line 273, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 71, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 93, in checked_call\ntries=tries, try_sleep=try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 141, in _call_wrapper\nresult = _call(command, **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 294, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh
> /usr/hdp/current/zeppelin-server ambari-stackviews-6re-3.openstacklocal 9083
> 10001 ambari-stackviews-6re-2.openstacklocal 9995 True
> /var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package
> /usr/lib/jvm/java-7-openjdk-amd64 >> /var/log/zeppelin/zeppelin-setup.log'
> returned 126. Hortonworks #\nThis is MOTD message, added
> for testing in qe infra\n-su:
> /var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh:
> Permission denied",
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17672) Zeppelin service: Remove sample notebook downloading shell script
[
https://issues.apache.org/jira/browse/AMBARI-17672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Renjith Kamath updated AMBARI-17672:
Status: Patch Available (was: Open)
> Zeppelin service: Remove sample notebook downloading shell script
> -
>
> Key: AMBARI-17672
> URL: https://issues.apache.org/jira/browse/AMBARI-17672
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.4.0
>Reporter: Anusha Bilgi
>Assignee: Renjith Kamath
>Priority: Blocker
> Fix For: 2.4.0
>
>
> Sample notebook download script is failing due to lack of permissions on
> multiple OS
> {code}
> "stderr" : "Traceback (most recent call last):\n File
> \"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\",
> line 266, in \nMaster().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 280, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\",
> line 59, in install\nuser=params.zeppelin_user)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\", line
> 155, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
> line 160, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
> line 124, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
> line 273, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 71, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 93, in checked_call\ntries=tries, try_sleep=try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 141, in _call_wrapper\nresult = _call(command, **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
> 294, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh
> /usr/hdp/current/zeppelin-server ambari-stackviews-6re-3.openstacklocal 9083
> 10001 ambari-stackviews-6re-2.openstacklocal 9995 True
> /var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package
> /usr/lib/jvm/java-7-openjdk-amd64 >> /var/log/zeppelin/zeppelin-setup.log'
> returned 126. Hortonworks #\nThis is MOTD message, added
> for testing in qe infra\n-su:
> /var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh:
> Permission denied",
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17672) Zeppelin service: Remove sample notebook downloading shell script
[
https://issues.apache.org/jira/browse/AMBARI-17672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Renjith Kamath updated AMBARI-17672:
Description:
Sample notebook download script is failing due to lack of permissions on
multiple OS
{code}
"stderr" : "Traceback (most recent call last):\n File
\"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\",
line 266, in \nMaster().execute()\n File
\"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
line 280, in execute\nmethod(env)\n File
\"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\",
line 59, in install\nuser=params.zeppelin_user)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/base.py\", line
155, in __init__\nself.env.run()\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
line 160, in run\nself.run_action(resource, action)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
line 124, in run_action\nprovider_action()\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
line 273, in action_run\ntries=self.resource.tries,
try_sleep=self.resource.try_sleep)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
71, in inner\nresult = function(command, **kwargs)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
93, in checked_call\ntries=tries, try_sleep=try_sleep)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
141, in _call_wrapper\nresult = _call(command, **kwargs_copy)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
294, in _call\nraise
Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
'/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh
/usr/hdp/current/zeppelin-server ambari-stackviews-6re-3.openstacklocal 9083
10001 ambari-stackviews-6re-2.openstacklocal 9995 True
/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package
/usr/lib/jvm/java-7-openjdk-amd64 >> /var/log/zeppelin/zeppelin-setup.log'
returned 126. Hortonworks #\nThis is MOTD message, added
for testing in qe infra\n-su:
/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh:
Permission denied",
{code}
was:"stderr" : "Traceback (most recent call last):\n File
\"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\",
line 266, in \nMaster().execute()\n File
\"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
line 280, in execute\nmethod(env)\n File
\"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\",
line 59, in install\nuser=params.zeppelin_user)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/base.py\", line
155, in __init__\nself.env.run()\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
line 160, in run\nself.run_action(resource, action)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
line 124, in run_action\nprovider_action()\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
line 273, in action_run\ntries=self.resource.tries,
try_sleep=self.resource.try_sleep)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
71, in inner\nresult = function(command, **kwargs)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
93, in checked_call\ntries=tries, try_sleep=try_sleep)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
141, in _call_wrapper\nresult = _call(command, **kwargs_copy)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line
294, in _call\nraise
Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
'/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh
/usr/hdp/current/zeppelin-server ambari-stackviews-6re-3.openstacklocal 9083
10001 ambari-stackviews-6re-2.openstacklocal 9995 True
/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package
/usr/lib/jvm/java-7-openjdk-amd64 >> /var/log/zeppelin/zeppelin-setup.log'
returned 126. Hortonworks #\nThis is MOTD message, added
for testing in qe infra\n-su:
/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh:
Permission denied",
> Zeppelin service: Remove sample notebook downloading shell script
[jira] [Updated] (AMBARI-17672) Zeppelin service: Remove sample notebook downloading shell script
[ https://issues.apache.org/jira/browse/AMBARI-17672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Renjith Kamath updated AMBARI-17672: Summary: Zeppelin service: Remove sample notebook downloading shell script (was: Zeppelin installation Fails) > Zeppelin service: Remove sample notebook downloading shell script > - > > Key: AMBARI-17672 > URL: https://issues.apache.org/jira/browse/AMBARI-17672 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.4.0 >Reporter: Anusha Bilgi >Assignee: Renjith Kamath >Priority: Blocker > Fix For: 2.4.0 > > > "stderr" : "Traceback (most recent call last):\n File > \"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\", > line 266, in \nMaster().execute()\n File > \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\", > line 280, in execute\nmethod(env)\n File > \"/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py\", > line 59, in install\nuser=params.zeppelin_user)\n File > \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\", line > 155, in __init__\nself.env.run()\n File > \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\", > line 160, in run\nself.run_action(resource, action)\n File > \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\", > line 124, in run_action\nprovider_action()\n File > \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\", > line 273, in action_run\ntries=self.resource.tries, > try_sleep=self.resource.try_sleep)\n File > \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line > 71, in inner\nresult = function(command, **kwargs)\n File > \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line > 93, in checked_call\ntries=tries, try_sleep=try_sleep)\n File > \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line > 141, in _call_wrapper\nresult = _call(command, **kwargs_copy)\n File > \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\", line > 294, in _call\nraise > Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of > '/var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh > /usr/hdp/current/zeppelin-server ambari-stackviews-6re-3.openstacklocal 9083 > 10001 ambari-stackviews-6re-2.openstacklocal 9995 True > /var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package > /usr/lib/jvm/java-7-openjdk-amd64 >> /var/log/zeppelin/zeppelin-setup.log' > returned 126. Hortonworks #\nThis is MOTD message, added > for testing in qe infra\n-su: > /var/lib/ambari-agent/cache/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/setup_snapshot.sh: > Permission denied", -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17681) Changing settings in advanced-tez-interactive-site did not ask for a HiveServerInteractive restart
[ https://issues.apache.org/jira/browse/AMBARI-17681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374339#comment-15374339 ] Nahappan Somasundaram commented on AMBARI-17681: +1 > Changing settings in advanced-tez-interactive-site did not ask for a > HiveServerInteractive restart > -- > > Key: AMBARI-17681 > URL: https://issues.apache.org/jira/browse/AMBARI-17681 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Sumit Mohanty >Assignee: Sumit Mohanty >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17681.patch > > > Changing settings in advanced-tez-interactive-site did not ask for a > HiveServerInteractive restart. > The config type should be added to the HSI component. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-17681) Changing settings in advanced-tez-interactive-site did not ask for a HiveServerInteractive restart
[ https://issues.apache.org/jira/browse/AMBARI-17681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty resolved AMBARI-17681. Resolution: Fixed committed to trunk and branch-2.4 > Changing settings in advanced-tez-interactive-site did not ask for a > HiveServerInteractive restart > -- > > Key: AMBARI-17681 > URL: https://issues.apache.org/jira/browse/AMBARI-17681 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Sumit Mohanty >Assignee: Sumit Mohanty >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17681.patch > > > Changing settings in advanced-tez-interactive-site did not ask for a > HiveServerInteractive restart. > The config type should be added to the HSI component. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17681) Changing settings in advanced-tez-interactive-site did not ask for a HiveServerInteractive restart
[ https://issues.apache.org/jira/browse/AMBARI-17681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374315#comment-15374315 ] Gautam Borad commented on AMBARI-17681: --- +1 for the patch. > Changing settings in advanced-tez-interactive-site did not ask for a > HiveServerInteractive restart > -- > > Key: AMBARI-17681 > URL: https://issues.apache.org/jira/browse/AMBARI-17681 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Sumit Mohanty >Assignee: Sumit Mohanty >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17681.patch > > > Changing settings in advanced-tez-interactive-site did not ask for a > HiveServerInteractive restart. > The config type should be added to the HSI component. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17681) Changing settings in advanced-tez-interactive-site did not ask for a HiveServerInteractive restart
[ https://issues.apache.org/jira/browse/AMBARI-17681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-17681: --- Attachment: AMBARI-17681.patch > Changing settings in advanced-tez-interactive-site did not ask for a > HiveServerInteractive restart > -- > > Key: AMBARI-17681 > URL: https://issues.apache.org/jira/browse/AMBARI-17681 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Sumit Mohanty >Assignee: Sumit Mohanty >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17681.patch > > > Changing settings in advanced-tez-interactive-site did not ask for a > HiveServerInteractive restart. > The config type should be added to the HSI component. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-17681) Changing settings in advanced-tez-interactive-site did not ask for a HiveServerInteractive restart
Sumit Mohanty created AMBARI-17681: -- Summary: Changing settings in advanced-tez-interactive-site did not ask for a HiveServerInteractive restart Key: AMBARI-17681 URL: https://issues.apache.org/jira/browse/AMBARI-17681 Project: Ambari Issue Type: Bug Components: stacks Affects Versions: 2.4.0 Reporter: Sumit Mohanty Assignee: Sumit Mohanty Priority: Critical Fix For: 2.4.0 Changing settings in advanced-tez-interactive-site did not ask for a HiveServerInteractive restart. The config type should be added to the HSI component. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17677) Zeppelin service: wrong principal format in zeppelin kerberos.json
[
https://issues.apache.org/jira/browse/AMBARI-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sumit Mohanty updated AMBARI-17677:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
committed to trunk and branch-2.4
> Zeppelin service: wrong principal format in zeppelin kerberos.json
> --
>
> Key: AMBARI-17677
> URL: https://issues.apache.org/jira/browse/AMBARI-17677
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Shraddha Sumit
>Assignee: Renjith Kamath
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17677_trunk+branch-2.4_v1.patch
>
>
> Expected format :
> {{$\{zeppelin-env/zeppelin_user\}-$\{cluster_name|toLower()\}@$\{realm\}}}
> Current format: {{zeppelin/$\{cluster_name\}@$\{realm\}}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17677) Zeppelin service: wrong principal format in zeppelin kerberos.json
[
https://issues.apache.org/jira/browse/AMBARI-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Renjith Kamath updated AMBARI-17677:
Component/s: (was: ambari-web)
ambari-server
> Zeppelin service: wrong principal format in zeppelin kerberos.json
> --
>
> Key: AMBARI-17677
> URL: https://issues.apache.org/jira/browse/AMBARI-17677
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Shraddha Sumit
>Assignee: Renjith Kamath
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17677_trunk+branch-2.4_v1.patch
>
>
> Expected format :
> {{$\{zeppelin-env/zeppelin_user\}-$\{cluster_name|toLower()\}@$\{realm\}}}
> Current format: {{zeppelin/$\{cluster_name\}@$\{realm\}}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17677) Zeppelin service: wrong principal format in zeppelin kerberos.json
[
https://issues.apache.org/jira/browse/AMBARI-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Renjith Kamath updated AMBARI-17677:
Attachment: AMBARI-17677_trunk+branch-2.4_v1.patch
> Zeppelin service: wrong principal format in zeppelin kerberos.json
> --
>
> Key: AMBARI-17677
> URL: https://issues.apache.org/jira/browse/AMBARI-17677
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Shraddha Sumit
>Assignee: Renjith Kamath
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17677_trunk+branch-2.4_v1.patch
>
>
> Expected format :
> {{$\{zeppelin-env/zeppelin_user\}-$\{cluster_name|toLower()\}@$\{realm\}}}
> Current format: {{zeppelin/$\{cluster_name\}@$\{realm\}}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17677) Zeppelin service: wrong principal format in zeppelin kerberos.json
[
https://issues.apache.org/jira/browse/AMBARI-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Renjith Kamath updated AMBARI-17677:
Fix Version/s: 2.4.0
Affects Version/s: 2.4.0
Status: Patch Available (was: Open)
> Zeppelin service: wrong principal format in zeppelin kerberos.json
> --
>
> Key: AMBARI-17677
> URL: https://issues.apache.org/jira/browse/AMBARI-17677
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Shraddha Sumit
>Assignee: Renjith Kamath
>Priority: Critical
> Fix For: 2.4.0
>
>
> Expected format :
> {{$\{zeppelin-env/zeppelin_user\}-$\{cluster_name|toLower()\}@$\{realm\}}}
> Current format: {{zeppelin/$\{cluster_name\}@$\{realm\}}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (AMBARI-17677) Zeppelin service: wrong principal format in zeppelin kerberos.json
[
https://issues.apache.org/jira/browse/AMBARI-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Renjith Kamath reassigned AMBARI-17677:
---
Assignee: Renjith Kamath
> Zeppelin service: wrong principal format in zeppelin kerberos.json
> --
>
> Key: AMBARI-17677
> URL: https://issues.apache.org/jira/browse/AMBARI-17677
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Shraddha Sumit
>Assignee: Renjith Kamath
>Priority: Critical
> Fix For: 2.4.0
>
>
> Expected format :
> {{$\{zeppelin-env/zeppelin_user\}-$\{cluster_name|toLower()\}@$\{realm\}}}
> Current format: {{zeppelin/$\{cluster_name\}@$\{realm\}}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17677) Zeppelin service: wrong principal format in zeppelin kerberos.json
[
https://issues.apache.org/jira/browse/AMBARI-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Renjith Kamath updated AMBARI-17677:
Description:
Expected format :
{{$\{zeppelin-env/zeppelin_user\}-$\{cluster_name|toLower()\}@$\{realm\}}}
Current format: {{zeppelin/$\{cluster_name\}@$\{realm\}}}
was:
1. deploy cluster using ambari Ui including zeppelin as service
2. enable kerberos.
On configure identities page verify zeppelin principal
Expected: unique principal of form zeppelin-cl1 to be found
Actual: Found non unique principal: "zeppelin/$
{ cluster_name}
@$
{ realm}
"
> Zeppelin service: wrong principal format in zeppelin kerberos.json
> --
>
> Key: AMBARI-17677
> URL: https://issues.apache.org/jira/browse/AMBARI-17677
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Reporter: Shraddha Sumit
>Priority: Critical
>
> Expected format :
> {{$\{zeppelin-env/zeppelin_user\}-$\{cluster_name|toLower()\}@$\{realm\}}}
> Current format: {{zeppelin/$\{cluster_name\}@$\{realm\}}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17677) Zeppelin service: wrong principal format in zeppelin kerberos.json
[
https://issues.apache.org/jira/browse/AMBARI-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Renjith Kamath updated AMBARI-17677:
Summary: Zeppelin service: wrong principal format in zeppelin kerberos.json
(was: Use "zeppelin-${cluster_name}@${realm}" instead of
"zeppelin/${cluster-name}{realm}" for identity in kerberos.json)
> Zeppelin service: wrong principal format in zeppelin kerberos.json
> --
>
> Key: AMBARI-17677
> URL: https://issues.apache.org/jira/browse/AMBARI-17677
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Reporter: Shraddha Sumit
>Priority: Critical
>
> 1. deploy cluster using ambari Ui including zeppelin as service
> 2. enable kerberos.
> On configure identities page verify zeppelin principal
> Expected: unique principal of form zeppelin-cl1 to be found
> Actual: Found non unique principal: "zeppelin/$
> { cluster_name}
> @$
> { realm}
> "
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
[ https://issues.apache.org/jira/browse/AMBARI-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374168#comment-15374168 ] Hudson commented on AMBARI-17635: - FAILURE: Integrated in Ambari-trunk-Commit #5288 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5288/]) AMBARI-17635. Disable async logging for HiveServer2 + Hive 2.x (Prasanth (smohanty: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=1cdbb353dda0c2100d84335a3cf99f0689eb516e]) * ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hiveserver2-interactive-site.xml > Disable async logging for HiveServer2 + Hive 2.x > > > Key: AMBARI-17635 > URL: https://issues.apache.org/jira/browse/AMBARI-17635 > Project: Ambari > Issue Type: Bug > Components: HiveServer2, Metastore, and Client Heap Sizes to Smart > Configs, ambari-server, stacks >Affects Versions: 2.4.0 >Reporter: Prasanth Jayachandran >Assignee: Prasanth Jayachandran > Fix For: 2.4.0 > > Attachments: AMBARI-17635.1.patch, AMBARI-17635.2.patch, > AMBARI-17635.3.patch > > > Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's > use of custom log divert appender. We should disable async logging for HS2 > until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17600) System "boottime" metric is not being collected by AMS
[
https://issues.apache.org/jira/browse/AMBARI-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374167#comment-15374167
]
Hudson commented on AMBARI-17600:
-
FAILURE: Integrated in Ambari-trunk-Commit #5288 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5288/])
AMBARI-17600. System boottime metric is not being collected by AMS. (swagle:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=df8bc26aef0dde66c5fd1b18a6ce8fa7f3871453])
*
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/core/host_info.py
> System "boottime" metric is not being collected by AMS
> --
>
> Key: AMBARI-17600
> URL: https://issues.apache.org/jira/browse/AMBARI-17600
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.0.0
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
> Fix For: 2.4.0
>
> Attachments: AMBARI-17600-1.patch, AMBARI-17600.patch
>
>
> The System boottime metric used to be collected by AMS. It seems like it is
> no longer collected.
> {code}
> "metrics/boottime":{
> "metric":"boottime",
> "pointInTime":true,
> "temporal":true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Patch Available (was: Open)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Attachment: AMBARI-17626-July08.patch
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Open (was: Patch Available)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Attachment: (was: AMBARI-17626-July08.patch)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17623) nimbus.monitor.freq.secs should be 10 sec
[ https://issues.apache.org/jira/browse/AMBARI-17623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374013#comment-15374013 ] Hudson commented on AMBARI-17623: - FAILURE: Integrated in Ambari-trunk-Commit #5287 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5287/]) AMBARI-17623. Update default values of nimbus.monitor.freq.secs to 10 (smohanty: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=9be254b714dfe6cdbe3baab1b7f0e6ac75f27dd6]) * ambari-server/src/main/resources/common-services/STORM/0.9.1/configuration/storm-site.xml > nimbus.monitor.freq.secs should be 10 sec > - > > Key: AMBARI-17623 > URL: https://issues.apache.org/jira/browse/AMBARI-17623 > Project: Ambari > Issue Type: Bug >Reporter: Raghav Kumar Gautam >Assignee: Satish Duggana > Fix For: 2.4.0 > > Attachments: AMBARI-17623.patch > > > We want value of nimbus.monitor.freq.secs to be set to 10, but the current > value is 120 > https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/STORM/0.9.1/configuration/storm-site.xml#L210 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17667) Storm 1.0 Does Not Support Rolling Upgrades
[
https://issues.apache.org/jira/browse/AMBARI-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374016#comment-15374016
]
Hudson commented on AMBARI-17667:
-
FAILURE: Integrated in Ambari-trunk-Commit #5287 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5287/])
AMBARI-17667 - Storm 1.0 Does Not Support Rolling Upgrades (jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=4a3caaabcce12876a2e6e08f6c80afcb64d4141f])
*
ambari-server/src/test/java/org/apache/ambari/server/checks/StormShutdownWarningTest.java
*
ambari-server/src/test/java/org/apache/ambari/server/state/UpgradeHelperTest.java
* ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeHelper.java
*
ambari-server/src/main/java/org/apache/ambari/server/checks/CheckDescription.java
* ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.5.xml
* ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.5.xml
*
ambari-server/src/test/resources/stacks/HDP/2.1.1/upgrades/upgrade_grouping_rolling.xml
*
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
*
ambari-server/src/main/java/org/apache/ambari/server/checks/StormShutdownWarning.java
> Storm 1.0 Does Not Support Rolling Upgrades
> ---
>
> Key: AMBARI-17667
> URL: https://issues.apache.org/jira/browse/AMBARI-17667
> 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-17667.patch
>
>
> HDP 2.5 includes a new version of Storm where packages named
> {{backtype.storm}} were changed to {{org.apache.storm}}. As a result, Storm
> local data is not compatible between versions earlier versions of HDP and HDP
> 2.5. Consider the following situatio where Nimbus and a Supervisor are
> co-located on the same host:
> - Nimbus deletes local data and restarts on the new version
> - A running 2.4 Supervisor on the same host then re-creates that directory
> and puts 2.4 data back in
> - When the 2.4 Supervisor goes to upgrade and restart, it can't delete that
> data again since Nimbus is already running and would stop.
> When starting the Supevisor, the following error is seen:
> {code}
> 2016-06-21 23:10:48.000 o.a.s.c.f.s.ConnectionStateManager [INFO] State
> change: CONNECTED
> 2016-06-21 23:10:48.058 b.s.d.supervisor [INFO] Starting supervisor with id
> 03d8bceb-0271-4076-810d-04aeaa91533c at host
> nat-os-r6-omns-dgm10toeriedwngdha-r6-2.openstacklocal
> 2016-06-21 23:10:48.785 b.s.event [ERROR] Error when processing event
> java.lang.RuntimeException: java.lang.ClassNotFoundException:
> org.apache.storm.generated.LSSupervisorAssignments
> at backtype.storm.utils.LocalState.deserialize(LocalState.java:83)
> ~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at backtype.storm.utils.LocalState.get(LocalState.java:130)
> ~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at
> backtype.storm.local_state$ls_local_assignments.invoke(local_state.clj:83)
> ~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at
> backtype.storm.daemon.supervisor$sync_processes.invoke(supervisor.clj:323)
> ~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at clojure.lang.AFn.applyToHelper(AFn.java:154) ~[clojure-1.6.0.jar:?]
> at clojure.lang.AFn.applyTo(AFn.java:144) ~[clojure-1.6.0.jar:?]
> at clojure.core$apply.invoke(core.clj:626) ~[clojure-1.6.0.jar:?]
> at clojure.core$partial$fn__4228.doInvoke(core.clj:2468)
> ~[clojure-1.6.0.jar:?]
> at clojure.lang.RestFn.invoke(RestFn.java:397) ~[clojure-1.6.0.jar:?]
> at backtype.storm.event$event_manager$fn__6135.invoke(event.clj:40)
> [storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at clojure.lang.AFn.run(AFn.java:22) [clojure-1.6.0.jar:?]
> at java.lang.Thread.run(Thread.java:745) [?:1.7.0_67]
> Caused by: java.lang.ClassNotFoundException:
> org.apache.storm.generated.LSSupervisorAssignments
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> ~[?:1.7.0_67]
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> ~[?:1.7.0_67]
> at java.security.AccessController.doPrivileged(Native Method)
> ~[?:1.7.0_67]
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> ~[?:1.7.0_67]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425) ~[?:1.7.0_67]
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> ~[?:1.7.0_67]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358) ~[?:1.7.0_67]
> at java.lang.Class.forName0(Native Method) ~[
[jira] [Commented] (AMBARI-17631) preinstall-check script should use AMBARI-AGENT REST API for the list of agents
[ https://issues.apache.org/jira/browse/AMBARI-17631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374015#comment-15374015 ] Hudson commented on AMBARI-17631: - FAILURE: Integrated in Ambari-trunk-Commit #5287 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5287/]) AMBARI-17631: preinstall-check script should use AMBARI-AGENT REST API (dili: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=287df64992ed34537fd9f2d1dad733714e54f925]) * contrib/utils/preinstall-check/src/main/python/preinstall_checker.py > preinstall-check script should use AMBARI-AGENT REST API for the list of > agents > --- > > Key: AMBARI-17631 > URL: https://issues.apache.org/jira/browse/AMBARI-17631 > Project: Ambari > Issue Type: Bug > Components: contrib >Affects Versions: trunk >Reporter: Di Li >Assignee: Di Li >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-17631.patch > > > it should use the existing services/AMBARI/components/AMBARI-AGENT rest api > for the list of agents -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17662) Atlas HA fails to come up with error finding ids
[
https://issues.apache.org/jira/browse/AMBARI-17662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374014#comment-15374014
]
Hudson commented on AMBARI-17662:
-
FAILURE: Integrated in Ambari-trunk-Commit #5287 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5287/])
AMBARI-17662. Atlas HA fails to come up with error finding ids (afernandez:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=01043c0c459d197064f90280892267e191301735])
*
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py
*
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/status_params.py
* ambari-server/src/test/python/stacks/2.5/common/test_stack_advisor.py
*
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
*
ambari-server/src/main/resources/common-services/ATLAS/0.7.0.2.5/configuration/application-properties.xml
*
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
> Atlas HA fails to come up with error finding ids
>
>
> Key: AMBARI-17662
> URL: https://issues.apache.org/jira/browse/AMBARI-17662
> Project: Ambari
> Issue Type: Bug
> Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.4.0
>
> Attachments: AMBARI-17662.branch-2.4.patch, AMBARI-17662.trunk.patch
>
>
> Deploy multiple Atlas servers and one of them will fail since it will be
> missing its ids.
> {noformat}
> 2016-06-14 10:48:23,249 WARN - [main:] ~ Failed startup of context
> o.e.j.w.WebAppContext@2ad31d76{/,file:/grid/0/hdp/2.5.0.0-723/atlas/server/webapp/atlas/,STARTING}{/usr/hdp/current/atlas-server/server/webapp/atlas}
> (WebAppContext:514)
> java.lang.RuntimeException: org.apache.atlas.AtlasException: Could not find
> server id for this instance. Unable to find IDs matching any local host and
> port binding among id1
> at org.apache.atlas.service.Services.start(Services.java:48)
> at
> org.apache.atlas.web.listeners.GuiceServletConfig.startServices(GuiceServletConfig.java:142)
> at
> org.apache.atlas.web.listeners.GuiceServletConfig.contextInitialized(GuiceServletConfig.java:136)
> at
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444)
> at
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
> at org.eclipse.jetty.server.Server.start(Server.java:387)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> at org.eclipse.jetty.server.Server.doStart(Server.java:354)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at
> org.apache.atlas.web.service.EmbeddedServer.start(EmbeddedServer.java:93)
> at org.apache.atlas.Atlas.main(Atlas.java:113)
> Caused by: org.apache.atlas.AtlasException: Could not find server id for this
> instance. Unable to find IDs matching any local host and port binding among
> id1
> at
> org.apache.atlas.ha.AtlasServerIdSelector.selectServerId(AtlasServerIdSelector.java:77)
> at
> org.apache.atlas.web.service.ActiveInstanceElectorService.start(ActiveInstanceElectorService.java:105)
> at org.apache.atlas.service.Services.start(Services.java:45)
> ... 19 more
> 2016-06-14 10:48:23,284 INFO - [main:] ~ Started
> ServerConnector@255af999{HTTP/1.1}{0.0.0.0:21000} (ServerConnector:266)
> {noformat}
> To fix this,
> atlas.server.ha.enabled will not be shown on the UI and instead derived. But
> if for whatever reason we need to do some debugging/troubleshooting on Atlas,
> we may allow the user to override the property.
> * single Atlas Server => write con
[jira] [Created] (AMBARI-17680) Checking znode exists or not on Logsearch server
Olivér Szabó created AMBARI-17680: - Summary: Checking znode exists or not on Logsearch server Key: AMBARI-17680 URL: https://issues.apache.org/jira/browse/AMBARI-17680 Project: Ambari Issue Type: Bug Components: ambari-logsearch, ambari-server Affects Versions: 2.4.0 Reporter: Olivér Szabó Assignee: Olivér Szabó Fix For: 2.4.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17600) System "boottime" metric is not being collected by AMS
[
https://issues.apache.org/jira/browse/AMBARI-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373956#comment-15373956
]
Hadoop QA commented on AMBARI-17600:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12817541/AMBARI-17600-1.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7806//console
This message is automatically generated.
> System "boottime" metric is not being collected by AMS
> --
>
> Key: AMBARI-17600
> URL: https://issues.apache.org/jira/browse/AMBARI-17600
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.0.0
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
> Fix For: 2.4.0
>
> Attachments: AMBARI-17600-1.patch, AMBARI-17600.patch
>
>
> The System boottime metric used to be collected by AMS. It seems like it is
> no longer collected.
> {code}
> "metrics/boottime":{
> "metric":"boottime",
> "pointInTime":true,
> "temporal":true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
[ https://issues.apache.org/jira/browse/AMBARI-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373896#comment-15373896 ] Jaimin D Jetly commented on AMBARI-17635: - +1 for [^AMBARI-17635.3.patch]. Patch adds a property to a xml configuration file and so does not require unit test. > Disable async logging for HiveServer2 + Hive 2.x > > > Key: AMBARI-17635 > URL: https://issues.apache.org/jira/browse/AMBARI-17635 > Project: Ambari > Issue Type: Bug > Components: HiveServer2, Metastore, and Client Heap Sizes to Smart > Configs, ambari-server, stacks >Affects Versions: 2.4.0 >Reporter: Prasanth Jayachandran >Assignee: Prasanth Jayachandran > Fix For: 2.4.0 > > Attachments: AMBARI-17635.1.patch, AMBARI-17635.2.patch, > AMBARI-17635.3.patch > > > Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's > use of custom log divert appender. We should disable async logging for HS2 > until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
[ https://issues.apache.org/jira/browse/AMBARI-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-17635: --- Resolution: Fixed Status: Resolved (was: Patch Available) committed to trunk and branch-2.4 > Disable async logging for HiveServer2 + Hive 2.x > > > Key: AMBARI-17635 > URL: https://issues.apache.org/jira/browse/AMBARI-17635 > Project: Ambari > Issue Type: Bug > Components: HiveServer2, Metastore, and Client Heap Sizes to Smart > Configs, ambari-server, stacks >Affects Versions: 2.4.0 >Reporter: Prasanth Jayachandran >Assignee: Prasanth Jayachandran > Fix For: 2.4.0 > > Attachments: AMBARI-17635.1.patch, AMBARI-17635.2.patch, > AMBARI-17635.3.patch > > > Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's > use of custom log divert appender. We should disable async logging for HS2 > until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
[ https://issues.apache.org/jira/browse/AMBARI-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373889#comment-15373889 ] Sumit Mohanty commented on AMBARI-17635: LGTM, +1 > Disable async logging for HiveServer2 + Hive 2.x > > > Key: AMBARI-17635 > URL: https://issues.apache.org/jira/browse/AMBARI-17635 > Project: Ambari > Issue Type: Bug > Components: HiveServer2, Metastore, and Client Heap Sizes to Smart > Configs, ambari-server, stacks >Affects Versions: 2.4.0 >Reporter: Prasanth Jayachandran >Assignee: Prasanth Jayachandran > Fix For: 2.4.0 > > Attachments: AMBARI-17635.1.patch, AMBARI-17635.2.patch, > AMBARI-17635.3.patch > > > Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's > use of custom log divert appender. We should disable async logging for HS2 > until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17678) Misc Atlas fixes, remove conf dir from classpath of Falcon and Storm in HDP 2.5, add more security properties to Atlas Hooks, and delete deprecated configs
[ https://issues.apache.org/jira/browse/AMBARI-17678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-17678: - Attachment: AMBARI-17678.trunk.patch AMBARI-17678.branch-2.4.patch > Misc Atlas fixes, remove conf dir from classpath of Falcon and Storm in HDP > 2.5, add more security properties to Atlas Hooks, and delete deprecated > configs > --- > > Key: AMBARI-17678 > URL: https://issues.apache.org/jira/browse/AMBARI-17678 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17678.branch-2.4.patch, AMBARI-17678.trunk.patch > > > Miscellaneous fixes for Atlas. > 1. Atlas 0.7.0 in HDP 2.5 no longer needs to add the Atlas conf dir to the > classpath of Falcon and Storm. > This means we need to call check_stack_feature for > StackFeature.ATLAS_CONF_DIR_IN_PATH which allows HDP [2.3, 2.5) > 2. The Atlas Hooks creates the atlas-application.properties.xml file with a > subset of the Atlas application properties, which is missing two properties, > * atlas.kafka.sasl.kerberos.service.name > * atlas.kafka.security.protocol > 3. Change the Atlas log level to info. > Delete the following properties in Atlas 0.7.0: > * atlas.kafka.data > * atlas.graph.index.search.directory > * atlas.graph.index.search.elasticsearch.client-only > * atlas.graph.index.search.elasticsearch.local-mode > * atlas.graph.storage.directory > * atlas.kafka.entities.group.id -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
[ https://issues.apache.org/jira/browse/AMBARI-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated AMBARI-17635: --- Fix Version/s: 2.4.0 > Disable async logging for HiveServer2 + Hive 2.x > > > Key: AMBARI-17635 > URL: https://issues.apache.org/jira/browse/AMBARI-17635 > Project: Ambari > Issue Type: Bug > Components: HiveServer2, Metastore, and Client Heap Sizes to Smart > Configs, ambari-server, stacks >Affects Versions: 2.4.0 >Reporter: Prasanth Jayachandran >Assignee: Prasanth Jayachandran > Fix For: 2.4.0 > > Attachments: AMBARI-17635.1.patch, AMBARI-17635.2.patch, > AMBARI-17635.3.patch > > > Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's > use of custom log divert appender. We should disable async logging for HS2 > until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17600) System "boottime" metric is not being collected by AMS
[
https://issues.apache.org/jira/browse/AMBARI-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373849#comment-15373849
]
Aravindan Vijayan commented on AMBARI-17600:
LGTM +1
> System "boottime" metric is not being collected by AMS
> --
>
> Key: AMBARI-17600
> URL: https://issues.apache.org/jira/browse/AMBARI-17600
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.0.0
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
> Fix For: 2.4.0
>
> Attachments: AMBARI-17600-1.patch, AMBARI-17600.patch
>
>
> The System boottime metric used to be collected by AMS. It seems like it is
> no longer collected.
> {code}
> "metrics/boottime":{
> "metric":"boottime",
> "pointInTime":true,
> "temporal":true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17600) System "boottime" metric is not being collected by AMS
[
https://issues.apache.org/jira/browse/AMBARI-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddharth Wagle updated AMBARI-17600:
-
Attachment: AMBARI-17600-1.patch
> System "boottime" metric is not being collected by AMS
> --
>
> Key: AMBARI-17600
> URL: https://issues.apache.org/jira/browse/AMBARI-17600
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.0.0
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
> Fix For: 2.4.0
>
> Attachments: AMBARI-17600-1.patch, AMBARI-17600.patch
>
>
> The System boottime metric used to be collected by AMS. It seems like it is
> no longer collected.
> {code}
> "metrics/boottime":{
> "metric":"boottime",
> "pointInTime":true,
> "temporal":true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17600) System "boottime" metric is not being collected by AMS
[
https://issues.apache.org/jira/browse/AMBARI-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddharth Wagle updated AMBARI-17600:
-
Status: Patch Available (was: Reopened)
> System "boottime" metric is not being collected by AMS
> --
>
> Key: AMBARI-17600
> URL: https://issues.apache.org/jira/browse/AMBARI-17600
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.0.0
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
> Fix For: 2.4.0
>
> Attachments: AMBARI-17600-1.patch, AMBARI-17600.patch
>
>
> The System boottime metric used to be collected by AMS. It seems like it is
> no longer collected.
> {code}
> "metrics/boottime":{
> "metric":"boottime",
> "pointInTime":true,
> "temporal":true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (AMBARI-17600) System "boottime" metric is not being collected by AMS
[
https://issues.apache.org/jira/browse/AMBARI-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddharth Wagle reopened AMBARI-17600:
--
AMS metrics name should match the Ambari json files spec.
> System "boottime" metric is not being collected by AMS
> --
>
> Key: AMBARI-17600
> URL: https://issues.apache.org/jira/browse/AMBARI-17600
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.0.0
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
> Fix For: 2.4.0
>
> Attachments: AMBARI-17600.patch
>
>
> The System boottime metric used to be collected by AMS. It seems like it is
> no longer collected.
> {code}
> "metrics/boottime":{
> "metric":"boottime",
> "pointInTime":true,
> "temporal":true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17566) Embed related Views from the Service dashboard page
[ https://issues.apache.org/jira/browse/AMBARI-17566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yusaku Sako updated AMBARI-17566: - Description: Today, all of the Views appear under a dropdown menu on the right-hand top of the page. Ideally, the Files View would show up under HDFS, Capacity Scheduler under YARN, etc. 1. We need a way to annotate a View with the service(s) it's associated with, so that any view developer can create this association. The API can then expose endpoints api/v1/views/FILES/ (show service_name: "HDFS") api/v1/clusters/$name/services/HDFS/views (reference to the FILES view) 2. Views that are associated with the service should be available from the service's dashboard page (e.g., next to the Heatmaps and Configs as tabs). These Views should be embedded within the service dashboard page so that they appear as if they are part of the page. This way, the user is not taken out of the current context and provides seamless UX. was: Today, all of the Views appear under a dropdown menu on the right-hand top of the page. Ideally, the Files View would show up under HDFS, Capacity Scheduler under YARN, etc. 1. We need a way to annotate a View with the service(s) it's associated with, so that any view developer can create this association. The API can then expose endpoints api/v1/views/FILES/ (show service_name: "HDFS") api/v1/clusters/$name/services/HDFS/views (reference to the FILES view) 2. The UI should should all of the views that provide hints for the current service from the Dashboard page, next to the Heatmaps and Configs links. > Embed related Views from the Service dashboard page > --- > > Key: AMBARI-17566 > URL: https://issues.apache.org/jira/browse/AMBARI-17566 > Project: Ambari > Issue Type: Epic > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Alejandro Fernandez >Assignee: Manasi Maheshwari > Fix For: trunk > > > Today, all of the Views appear under a dropdown menu on the right-hand top of > the page. > Ideally, the Files View would show up under HDFS, Capacity Scheduler under > YARN, etc. > 1. > We need a way to annotate a View with the service(s) it's associated with, so > that any view developer can create this association. The API can then expose > endpoints > api/v1/views/FILES/ (show service_name: "HDFS") > api/v1/clusters/$name/services/HDFS/views (reference to the FILES view) > 2. Views that are associated with the service should be available from the > service's dashboard page (e.g., next to the Heatmaps and Configs as tabs). > These Views should be embedded within the service dashboard page so that they > appear as if they are part of the page. This way, the user is not taken out > of the current context and provides seamless UX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17615) AMS metrics GET API does not work for same metric with multiple aggregation functions
[
https://issues.apache.org/jira/browse/AMBARI-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373808#comment-15373808
]
Hudson commented on AMBARI-17615:
-
SUCCESS: Integrated in Ambari-trunk-Commit #5286 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5286/])
AMBARI-17615 : AMS metrics GET API does not work for same metric with
(avijayan:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=7a7d757721b277134f73f5664ec8ab909929c84d])
*
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStoreTest.java
*
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java
*
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/ITPhoenixHBaseAccessor.java
*
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java
* ambari-metrics/ambari-metrics-timelineservice/pom.xml
*
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessorTest.java
> AMS metrics GET API does not work for same metric with multiple aggregation
> functions
> -
>
> Key: AMBARI-17615
> URL: https://issues.apache.org/jira/browse/AMBARI-17615
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17615-2.patch
>
>
> AMS API which used to work in previous versions is now broken in 2.4.0 version
> {noformat}
> GET
> http://:6188/ws/v1/timeline/metrics?metricNames=bytes_in._min,bytes_in._max,bytes_in._sum,bytes_in._avg&appId=HOST&precision=hours&startTime=146692800&endTime=146743920&hostname=
> failed. Status:400
> {
> "exception": "BadRequestException",
> "message": "java.lang.Exception: Multiple aggregate functions not supported.",
> "javaClassName": "org.apache.hadoop.yarn.webapp.BadRequestException"
> }
> {noformat}
> This impacts SmartSense capture
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17566) Embed related Views from the Service dashboard page
[ https://issues.apache.org/jira/browse/AMBARI-17566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yusaku Sako updated AMBARI-17566: - Summary: Embed related Views from the Service dashboard page (was: Quicklinks to Views from the Service dashboard page) > Embed related Views from the Service dashboard page > --- > > Key: AMBARI-17566 > URL: https://issues.apache.org/jira/browse/AMBARI-17566 > Project: Ambari > Issue Type: Epic > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Alejandro Fernandez >Assignee: Manasi Maheshwari > Fix For: trunk > > > Today, all of the Views appear under a dropdown menu on the right-hand top of > the page. > Ideally, the Files View would show up under HDFS, Capacity Scheduler under > YARN, etc. > 1. > We need a way to annotate a View with the service(s) it's associated with, so > that any view developer can create this association. The API can then expose > endpoints > api/v1/views/FILES/ (show service_name: "HDFS") > api/v1/clusters/$name/services/HDFS/views (reference to the FILES view) > 2. The UI should should all of the views that provide hints for the current > service from the Dashboard page, next to the Heatmaps and Configs links. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-17679) HAWQ stack: identify properties added to Ambari-2.4.0 and mark appropriate ones to not get added during Ambari upgrade
Sumit Mohanty created AMBARI-17679: -- Summary: HAWQ stack: identify properties added to Ambari-2.4.0 and mark appropriate ones to not get added during Ambari upgrade Key: AMBARI-17679 URL: https://issues.apache.org/jira/browse/AMBARI-17679 Project: Ambari Issue Type: Bug Components: stacks Affects Versions: 2.4.0 Reporter: Sumit Mohanty Assignee: Matt Priority: Critical Fix For: 2.4.0 For any HAWQ config properties that need not be added upon Ambari upgrade, set on-ambari-upgrade attribute add to false. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17633) yarn.nodemanager.remote-app-log-dir should be added stickybit.
[
https://issues.apache.org/jira/browse/AMBARI-17633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373771#comment-15373771
]
Hadoop QA commented on AMBARI-17633:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12817505/AMBARI-17633.2.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7805//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7805//console
This message is automatically generated.
> yarn.nodemanager.remote-app-log-dir should be added stickybit.
> --
>
> Key: AMBARI-17633
> URL: https://issues.apache.org/jira/browse/AMBARI-17633
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: trunk
> Environment: CentOS7.2 Ambari2.4, HDP2.4
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
> Attachments: AMBARI-17633.1.patch, AMBARI-17633.2.patch,
> AMBARI-17633.patch
>
>
> When installing YARN+MapReduce2, I got a WARN message in nodemanager log(in
> Log Search View) like below
> {code}
> 2016-07-09 06:30:21,865 WARN logaggregation.LogAggregationService
> LogAggregationService.java:230 - Remote Root Log Dir [/app-logs] already
> exist, but with incorrect permissions. Expected: [rwxrwxrwt], Found:
> [rwxrwxrwx]. The cluster may have problems with multiple users.
> {code}
> I think the cause of this WARN is
> [this](https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py#L115).
> We should add stickybit to {{yarn.nodemanager.remote-app-log-dir}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-17678) Misc Atlas fixes, remove conf dir from classpath of Falcon and Storm in HDP 2.5, add more security properties to Atlas Hooks, and delete deprecated configs
Alejandro Fernandez created AMBARI-17678: Summary: Misc Atlas fixes, remove conf dir from classpath of Falcon and Storm in HDP 2.5, add more security properties to Atlas Hooks, and delete deprecated configs Key: AMBARI-17678 URL: https://issues.apache.org/jira/browse/AMBARI-17678 Project: Ambari Issue Type: Bug Components: stacks Affects Versions: 2.4.0 Reporter: Alejandro Fernandez Assignee: Alejandro Fernandez Priority: Critical Fix For: 2.4.0 Miscellaneous fixes for Atlas. 1. Atlas 0.7.0 in HDP 2.5 no longer needs to add the Atlas conf dir to the classpath of Falcon and Storm. This means we need to call check_stack_feature for StackFeature.ATLAS_CONF_DIR_IN_PATH which allows HDP [2.3, 2.5) 2. The Atlas Hooks creates the atlas-application.properties.xml file with a subset of the Atlas application properties, which is missing two properties, * atlas.kafka.sasl.kerberos.service.name * atlas.kafka.security.protocol 3. Change the Atlas log level to info. Delete the following properties in Atlas 0.7.0: * atlas.kafka.data * atlas.graph.index.search.directory * atlas.graph.index.search.elasticsearch.client-only * atlas.graph.index.search.elasticsearch.local-mode * atlas.graph.storage.directory * atlas.kafka.entities.group.id -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-17677) Use "zeppelin-${cluster_name}@${realm}" instead of "zeppelin/${cluster-name}{realm}" for identity in kerberos.json
Shraddha Sumit created AMBARI-17677:
---
Summary: Use "zeppelin-${cluster_name}@${realm}" instead of
"zeppelin/${cluster-name}{realm}" for identity in kerberos.json
Key: AMBARI-17677
URL: https://issues.apache.org/jira/browse/AMBARI-17677
Project: Ambari
Issue Type: Bug
Components: ambari-web
Reporter: Shraddha Sumit
Priority: Critical
1. deploy cluster using ambari Ui including zeppelin as service
2. enable kerberos.
On configure identities page verify zeppelin principal
Expected: unique principal of form zeppelin-cl1 to be found
Actual: Found non unique principal: "zeppelin/$
{ cluster_name}
@$
{ realm}
"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17631) preinstall-check script should use AMBARI-AGENT REST API for the list of agents
[ https://issues.apache.org/jira/browse/AMBARI-17631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373741#comment-15373741 ] Di Li commented on AMBARI-17631: pushed to trunk as https://git-wip-us.apache.org/repos/asf?p=ambari.git;a=commit;h=287df64992ed34537fd9f2d1dad733714e54f925 > preinstall-check script should use AMBARI-AGENT REST API for the list of > agents > --- > > Key: AMBARI-17631 > URL: https://issues.apache.org/jira/browse/AMBARI-17631 > Project: Ambari > Issue Type: Bug > Components: contrib >Affects Versions: trunk >Reporter: Di Li >Assignee: Di Li >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-17631.patch > > > it should use the existing services/AMBARI/components/AMBARI-AGENT rest api > for the list of agents -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17631) preinstall-check script should use AMBARI-AGENT REST API for the list of agents
[ https://issues.apache.org/jira/browse/AMBARI-17631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Di Li updated AMBARI-17631: --- Resolution: Fixed Status: Resolved (was: Patch Available) > preinstall-check script should use AMBARI-AGENT REST API for the list of > agents > --- > > Key: AMBARI-17631 > URL: https://issues.apache.org/jira/browse/AMBARI-17631 > Project: Ambari > Issue Type: Bug > Components: contrib >Affects Versions: trunk >Reporter: Di Li >Assignee: Di Li >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-17631.patch > > > it should use the existing services/AMBARI/components/AMBARI-AGENT rest api > for the list of agents -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17675) Ability to execute hooks when a management pack is installed
[
https://issues.apache.org/jira/browse/AMBARI-17675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373739#comment-15373739
]
Hadoop QA commented on AMBARI-17675:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12817509/AMBARI-17675.1.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server contrib/management-packs/microsoft-r_mpack.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7804//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7804//console
This message is automatically generated.
> Ability to execute hooks when a management pack is installed
>
>
> Key: AMBARI-17675
> URL: https://issues.apache.org/jira/browse/AMBARI-17675
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17675.1.patch, AMBARI-17675.patch
>
>
> *Use Case:*
> Apache Ambari release bundles following views
> {code}
> ambari-admin-2.4.0.0.809.jar capacity-scheduler-2.4.0.0.809.jar
> files-2.4.0.0.809.jar hive-2.4.0.0.809.jar hive-jdbc-2.4.0.0.809.jar
> hueambarimigration-2.4.0.0.809.jar pig-2.4.0.0.809.jar
> slider-2.4.0.0.809.jar storm-view-2.4.0.0.809.jar tez-view-2.4.0.0.809.jar
> zeppelin-view-2.4.0.0.809.jar
> {code}
> A custom stack might not have the same services as HDP and thereby we need to
> prune down the list of views. Ideally, we should support adding views as
> another artifact in management pack, but we dont have support for view
> artifacts yet.
> *Solution:*
> Add hooks during management pack installation to execute such custom actions/
> cleanups.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17623) nimbus.monitor.freq.secs should be 10 sec
[ https://issues.apache.org/jira/browse/AMBARI-17623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-17623: --- Resolution: Fixed Status: Resolved (was: Patch Available) committed to trunk and branch-2.4 > nimbus.monitor.freq.secs should be 10 sec > - > > Key: AMBARI-17623 > URL: https://issues.apache.org/jira/browse/AMBARI-17623 > Project: Ambari > Issue Type: Bug >Reporter: Raghav Kumar Gautam >Assignee: Satish Duggana > Fix For: 2.4.0 > > Attachments: AMBARI-17623.patch > > > We want value of nimbus.monitor.freq.secs to be set to 10, but the current > value is 120 > https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/STORM/0.9.1/configuration/storm-site.xml#L210 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-17676) oozie.service.AuthorizationService.security.enabled is invalid as a property name
Masahiro Tanaka created AMBARI-17676:
Summary: oozie.service.AuthorizationService.security.enabled is
invalid as a property name
Key: AMBARI-17676
URL: https://issues.apache.org/jira/browse/AMBARI-17676
Project: Ambari
Issue Type: Bug
Environment: HDP2.4, CentOS7.2, Ambari 2.4
Reporter: Masahiro Tanaka
Assignee: Masahiro Tanaka
When installed oozie service and checked oozie.log, I saw an WARN
{code}
2016-07-13 05:04:53,603 WARN ConfigurationService:523 - SERVER[] Invalid
configuration defined, [oozie.service.AuthorizationService.security.enabled]
{code}
I checked {{/etc/oozie/conf/oozie-site.xml}}, and found the configuration
below:
{code}
oozie.service.AuthorizationService.security.enabled
true
{code}
I guess {{oozie.service.AuthorizationService.security.enabled}} is invalid as a
property name. According to
[oozie-default.xml](https://oozie.apache.org/docs/4.2.0/oozie-default.xml), it
should be like this
{code}
oozie.service.AuthorizationService.authorization.enabled
true
{code}
STR:
1. Install Oozie
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17623) nimbus.monitor.freq.secs should be 10 sec
[ https://issues.apache.org/jira/browse/AMBARI-17623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373725#comment-15373725 ] Sumit Mohanty commented on AMBARI-17623: Sure, the patch looks good - +1. The test failure is unrelated to this patch. > nimbus.monitor.freq.secs should be 10 sec > - > > Key: AMBARI-17623 > URL: https://issues.apache.org/jira/browse/AMBARI-17623 > Project: Ambari > Issue Type: Bug >Reporter: Raghav Kumar Gautam >Assignee: Satish Duggana > Fix For: 2.4.0 > > Attachments: AMBARI-17623.patch > > > We want value of nimbus.monitor.freq.secs to be set to 10, but the current > value is 120 > https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/STORM/0.9.1/configuration/storm-site.xml#L210 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17650) Wire encryption enabled, atlas alerts are failing.
[
https://issues.apache.org/jira/browse/AMBARI-17650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373709#comment-15373709
]
Hadoop QA commented on AMBARI-17650:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12817471/AMBARI-17650.patch.1
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
ambari-server:
org.apache.ambari.server.controller.internal.ConfigGroupResourceProviderTest
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7803//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7803//console
This message is automatically generated.
> Wire encryption enabled, atlas alerts are failing.
> --
>
> Key: AMBARI-17650
> URL: https://issues.apache.org/jira/browse/AMBARI-17650
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmytro Grinenko
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17650.patch, AMBARI-17650.patch.1
>
>
> With wire-encryption enabled, atlas alerts are fired with incorrect port and
> schema resulting in alert failure
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17623) nimbus.monitor.freq.secs should be 10 sec
[ https://issues.apache.org/jira/browse/AMBARI-17623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373704#comment-15373704 ] Mahadev konar commented on AMBARI-17623: [~sumitmohanty]/[~jluniya] can we get this in asap? > nimbus.monitor.freq.secs should be 10 sec > - > > Key: AMBARI-17623 > URL: https://issues.apache.org/jira/browse/AMBARI-17623 > Project: Ambari > Issue Type: Bug >Reporter: Raghav Kumar Gautam >Assignee: Satish Duggana > Fix For: 2.4.0 > > Attachments: AMBARI-17623.patch > > > We want value of nimbus.monitor.freq.secs to be set to 10, but the current > value is 120 > https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/STORM/0.9.1/configuration/storm-site.xml#L210 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17623) nimbus.monitor.freq.secs should be 10 sec
[ https://issues.apache.org/jira/browse/AMBARI-17623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated AMBARI-17623: --- Fix Version/s: 2.4.0 > nimbus.monitor.freq.secs should be 10 sec > - > > Key: AMBARI-17623 > URL: https://issues.apache.org/jira/browse/AMBARI-17623 > Project: Ambari > Issue Type: Bug >Reporter: Raghav Kumar Gautam >Assignee: Satish Duggana > Fix For: 2.4.0 > > Attachments: AMBARI-17623.patch > > > We want value of nimbus.monitor.freq.secs to be set to 10, but the current > value is 120 > https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/STORM/0.9.1/configuration/storm-site.xml#L210 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMBARI-17285) Custom service repos in repoinfo.xml got overwritten by public VDFs
[
https://issues.apache.org/jira/browse/AMBARI-17285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373045#comment-15373045
]
Nate Cole edited comment on AMBARI-17285 at 7/12/16 9:02 PM:
-
I think that we should probably add a directive that will allow preserving of
stack-defined repos when using VDF.
This directive would be used with the following logic: If passing the
directive (to be named) as {{true}}, check if there are any repos that do NOT
match the ids within the VDF, and use them for the repo version.
As an example:
HDP/2.5 defines two repos, name/id'ed by HDP/HDP-2.5 and
HDP-UTILS/HDP-UTILS-1.1.0.21.
||Directive||Stack||VDF||Repo Version||
|false (default)|HDP\\HDP-UTILS|HDP\\HDP-UTILS|HDP\\HDP-UTILS|
|true|HDP \\ HDP-UTILS\\SOME-REPO|HDP \\ HDP-UTILS|HDP \\ HDP-UTILS\\SOME-REPO|
We can default to either {{true}} or {{false}}, I'm not too picky on that
point. Thoughts welcome.
was (Author: nc...@hortonworks.com):
I think that we should probably add a directive that will allow preserving of
stack-defined repos when using VDF. As an example
HDP/2.5 defines two repos, name/id'ed by HDP/HDP-2.5 and
HDP-UTILS/HDP-UTILS-1.1.0.20.
This directive would be used with the following logic: If passing the
directive (to be named) as {{true}}, check if there are any repos that do NOT
match the ids within the VDF, and use them for the repo version. Therefore:
||Directive||Stack||VDF||Repo Version||
|false (default)|HDP\\HDP-UTILS|HDP\\HDP-UTILS|HDP\\HDP-UTILS|
|true|HDP \\ HDP-UTILS\\SOME-REPO|HDP \\ HDP-UTILS|HDP \\ HDP-UTILS\\SOME-REPO|
We can default to either {{true}} or {{false}}, I'm not too picky on that
point. Thoughts welcome.
> Custom service repos in repoinfo.xml got overwritten by public VDFs
> ---
>
> Key: AMBARI-17285
> URL: https://issues.apache.org/jira/browse/AMBARI-17285
> Project: Ambari
> Issue Type: Bug
>Reporter: Alexander Denissov
>Assignee: Nate Cole
>Priority: Critical
> Fix For: 2.4.0
>
>
> Ambari 2.4 introduced Version Definition Files that break the functionality
> of adding a custom service repo, since custom services do not have an entry
> in the public VDF.
> In the case of HAWQ, the plugin is installed on Ambari host and it adds the
> new repo information to the repoinfo.xml of all available stacks on the file
> system. Once Ambari cluster creation wizard queries the latest repo info from
> the public URLs, it will get the info for all stack repos, but not the custom
> ones.
> So, the logic should be:
> 1. Use default repoinfo (from file system) as the base
> 2. Query public VDF, if available
> 3. For each entry in public VDF overwrite values in the default repoinfo
> 4. Entries in default repoinfo that do not have corresponding entries in VDF
> should stay intact
> This way custom services can be added via file edit and the latest
> information can still be retrieved and applied for the standard stack.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17285) Custom service repos in repoinfo.xml got overwritten by public VDFs
[
https://issues.apache.org/jira/browse/AMBARI-17285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373685#comment-15373685
]
Alexander Denissov commented on AMBARI-17285:
-
yes, guarding this logic via such a flag is fine, but where will it be defined
? For this to be useful for 3-rd party repos, such as HAWQ, the flag will need
to be set as to {{true}} for HDP stacks, so defaulting this to {{true}} makes
more sense.
> Custom service repos in repoinfo.xml got overwritten by public VDFs
> ---
>
> Key: AMBARI-17285
> URL: https://issues.apache.org/jira/browse/AMBARI-17285
> Project: Ambari
> Issue Type: Bug
>Reporter: Alexander Denissov
>Assignee: Nate Cole
>Priority: Critical
> Fix For: 2.4.0
>
>
> Ambari 2.4 introduced Version Definition Files that break the functionality
> of adding a custom service repo, since custom services do not have an entry
> in the public VDF.
> In the case of HAWQ, the plugin is installed on Ambari host and it adds the
> new repo information to the repoinfo.xml of all available stacks on the file
> system. Once Ambari cluster creation wizard queries the latest repo info from
> the public URLs, it will get the info for all stack repos, but not the custom
> ones.
> So, the logic should be:
> 1. Use default repoinfo (from file system) as the base
> 2. Query public VDF, if available
> 3. For each entry in public VDF overwrite values in the default repoinfo
> 4. Entries in default repoinfo that do not have corresponding entries in VDF
> should stay intact
> This way custom services can be added via file edit and the latest
> information can still be retrieved and applied for the standard stack.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Patch Available (was: Open)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Open (was: Patch Available)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17662) Atlas HA fails to come up with error finding ids
[
https://issues.apache.org/jira/browse/AMBARI-17662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Fernandez updated AMBARI-17662:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
Pushed to trunk, commit 01043c0c459d197064f90280892267e191301735
branch-2.4, commit 7c809e278e7820e5ff90362209d98bd7d797e086
> Atlas HA fails to come up with error finding ids
>
>
> Key: AMBARI-17662
> URL: https://issues.apache.org/jira/browse/AMBARI-17662
> Project: Ambari
> Issue Type: Bug
> Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.4.0
>
> Attachments: AMBARI-17662.branch-2.4.patch, AMBARI-17662.trunk.patch
>
>
> Deploy multiple Atlas servers and one of them will fail since it will be
> missing its ids.
> {noformat}
> 2016-06-14 10:48:23,249 WARN - [main:] ~ Failed startup of context
> o.e.j.w.WebAppContext@2ad31d76{/,file:/grid/0/hdp/2.5.0.0-723/atlas/server/webapp/atlas/,STARTING}{/usr/hdp/current/atlas-server/server/webapp/atlas}
> (WebAppContext:514)
> java.lang.RuntimeException: org.apache.atlas.AtlasException: Could not find
> server id for this instance. Unable to find IDs matching any local host and
> port binding among id1
> at org.apache.atlas.service.Services.start(Services.java:48)
> at
> org.apache.atlas.web.listeners.GuiceServletConfig.startServices(GuiceServletConfig.java:142)
> at
> org.apache.atlas.web.listeners.GuiceServletConfig.contextInitialized(GuiceServletConfig.java:136)
> at
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444)
> at
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
> at org.eclipse.jetty.server.Server.start(Server.java:387)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> at org.eclipse.jetty.server.Server.doStart(Server.java:354)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at
> org.apache.atlas.web.service.EmbeddedServer.start(EmbeddedServer.java:93)
> at org.apache.atlas.Atlas.main(Atlas.java:113)
> Caused by: org.apache.atlas.AtlasException: Could not find server id for this
> instance. Unable to find IDs matching any local host and port binding among
> id1
> at
> org.apache.atlas.ha.AtlasServerIdSelector.selectServerId(AtlasServerIdSelector.java:77)
> at
> org.apache.atlas.web.service.ActiveInstanceElectorService.start(ActiveInstanceElectorService.java:105)
> at org.apache.atlas.service.Services.start(Services.java:45)
> ... 19 more
> 2016-06-14 10:48:23,284 INFO - [main:] ~ Started
> ServerConnector@255af999{HTTP/1.1}{0.0.0.0:21000} (ServerConnector:266)
> {noformat}
> To fix this,
> atlas.server.ha.enabled will not be shown on the UI and instead derived. But
> if for whatever reason we need to do some debugging/troubleshooting on Atlas,
> we may allow the user to override the property.
> * single Atlas Server => write config with atlas.server.ha.enabled=false (if
> atlas.server.ha.enabled is set to true, still write it out as false)
> * multiple Atlas Servers => write config with atlas.server.ha.enabled=true
> (only if atlas.server.ha.enabled is not a property, otherwise, take its value)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17667) Storm 1.0 Does Not Support Rolling Upgrades
[
https://issues.apache.org/jira/browse/AMBARI-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-17667:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Storm 1.0 Does Not Support Rolling Upgrades
> ---
>
> Key: AMBARI-17667
> URL: https://issues.apache.org/jira/browse/AMBARI-17667
> 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-17667.patch
>
>
> HDP 2.5 includes a new version of Storm where packages named
> {{backtype.storm}} were changed to {{org.apache.storm}}. As a result, Storm
> local data is not compatible between versions earlier versions of HDP and HDP
> 2.5. Consider the following situatio where Nimbus and a Supervisor are
> co-located on the same host:
> - Nimbus deletes local data and restarts on the new version
> - A running 2.4 Supervisor on the same host then re-creates that directory
> and puts 2.4 data back in
> - When the 2.4 Supervisor goes to upgrade and restart, it can't delete that
> data again since Nimbus is already running and would stop.
> When starting the Supevisor, the following error is seen:
> {code}
> 2016-06-21 23:10:48.000 o.a.s.c.f.s.ConnectionStateManager [INFO] State
> change: CONNECTED
> 2016-06-21 23:10:48.058 b.s.d.supervisor [INFO] Starting supervisor with id
> 03d8bceb-0271-4076-810d-04aeaa91533c at host
> nat-os-r6-omns-dgm10toeriedwngdha-r6-2.openstacklocal
> 2016-06-21 23:10:48.785 b.s.event [ERROR] Error when processing event
> java.lang.RuntimeException: java.lang.ClassNotFoundException:
> org.apache.storm.generated.LSSupervisorAssignments
> at backtype.storm.utils.LocalState.deserialize(LocalState.java:83)
> ~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at backtype.storm.utils.LocalState.get(LocalState.java:130)
> ~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at
> backtype.storm.local_state$ls_local_assignments.invoke(local_state.clj:83)
> ~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at
> backtype.storm.daemon.supervisor$sync_processes.invoke(supervisor.clj:323)
> ~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at clojure.lang.AFn.applyToHelper(AFn.java:154) ~[clojure-1.6.0.jar:?]
> at clojure.lang.AFn.applyTo(AFn.java:144) ~[clojure-1.6.0.jar:?]
> at clojure.core$apply.invoke(core.clj:626) ~[clojure-1.6.0.jar:?]
> at clojure.core$partial$fn__4228.doInvoke(core.clj:2468)
> ~[clojure-1.6.0.jar:?]
> at clojure.lang.RestFn.invoke(RestFn.java:397) ~[clojure-1.6.0.jar:?]
> at backtype.storm.event$event_manager$fn__6135.invoke(event.clj:40)
> [storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at clojure.lang.AFn.run(AFn.java:22) [clojure-1.6.0.jar:?]
> at java.lang.Thread.run(Thread.java:745) [?:1.7.0_67]
> Caused by: java.lang.ClassNotFoundException:
> org.apache.storm.generated.LSSupervisorAssignments
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> ~[?:1.7.0_67]
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> ~[?:1.7.0_67]
> at java.security.AccessController.doPrivileged(Native Method)
> ~[?:1.7.0_67]
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> ~[?:1.7.0_67]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425) ~[?:1.7.0_67]
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> ~[?:1.7.0_67]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358) ~[?:1.7.0_67]
> at java.lang.Class.forName0(Native Method) ~[?:1.7.0_67]
> at java.lang.Class.forName(Class.java:190) ~[?:1.7.0_67]
> at backtype.storm.utils.LocalState.deserialize(LocalState.java:78)
> ~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17665) Fix the typo in 'alert_hive_interactive_thrift_port.py' for 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required extra '-' for 'findAppTimeout' pa
[
https://issues.apache.org/jira/browse/AMBARI-17665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373639#comment-15373639
]
Hudson commented on AMBARI-17665:
-
SUCCESS: Integrated in Ambari-trunk-Commit #5285 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5285/])
AMBARI-17665. Fix the typo in 'alert_hive_interactive_thrift_port.py'
(sshridhar:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=f2cf759a5fd1162bc37570b48d2e67494fd070b5])
*
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/alerts/alert_hive_interactive_thrift_port.py
*
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_interactive.py
*
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/alerts/alert_llap_app_status.py
> Fix the typo in 'alert_hive_interactive_thrift_port.py' for
> 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required
> extra '-' for 'findAppTimeout' param in llapstatus comamnd.
>
>
> Key: AMBARI-17665
> URL: https://issues.apache.org/jira/browse/AMBARI-17665
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.4.0
>
> Attachments: AMBARI-17665.patch
>
>
> - Current value : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY =
> '{{hive.server2.transport.mode/hive.server2.authentication}}'
> *Fixed to :* HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY =
> '{{hive-site/hive.server2.authentication}}'
> - Added the required extra '-' for 'findAppTimeout' param in llapstatus
> comamnd.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17615) AMS metrics GET API does not work for same metric with multiple aggregation functions
[
https://issues.apache.org/jira/browse/AMBARI-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated AMBARI-17615:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
Pushed to trunk and branch-2.4
> AMS metrics GET API does not work for same metric with multiple aggregation
> functions
> -
>
> Key: AMBARI-17615
> URL: https://issues.apache.org/jira/browse/AMBARI-17615
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17615-2.patch
>
>
> AMS API which used to work in previous versions is now broken in 2.4.0 version
> {noformat}
> GET
> http://:6188/ws/v1/timeline/metrics?metricNames=bytes_in._min,bytes_in._max,bytes_in._sum,bytes_in._avg&appId=HOST&precision=hours&startTime=146692800&endTime=146743920&hostname=
> failed. Status:400
> {
> "exception": "BadRequestException",
> "message": "java.lang.Exception: Multiple aggregate functions not supported.",
> "javaClassName": "org.apache.hadoop.yarn.webapp.BadRequestException"
> }
> {noformat}
> This impacts SmartSense capture
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17126) Provide Ambari Server HA (active-passive)
[ https://issues.apache.org/jira/browse/AMBARI-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373634#comment-15373634 ] Erik Bergenholtz commented on AMBARI-17126: --- It seems the above describes something that is already possible with capabilities available today in Ambari. It would be desirable to entertain capabilities in Ambari that allow for native functionality that would use [something like] ZK leader election as described in AMBARI-7896. > Provide Ambari Server HA (active-passive) > - > > Key: AMBARI-17126 > URL: https://issues.apache.org/jira/browse/AMBARI-17126 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: 2.5.0 >Reporter: Jeff Sposetti > Fix For: 2.5.0 > > > Ability to configure Ambari Server active-passive setup behind Load balancer. > -Both servers should point to the same database (external to Ambari Server) . > Preferably Server.jdbc.hostname should point to a HA DB Cluster from both > server's ambari.properties. > -Load Balancer (preferably an external solution, like F5, Cisco, Brocade etc) > to create VIP and use the Ambari server as Real to direct traffic to either > host rather than keeping one as Standby (Agent ini file should point to DNS > of VIP rather than to a server directly) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17675) Ability to execute hooks when a management pack is installed
[
https://issues.apache.org/jira/browse/AMBARI-17675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-17675:
---
Attachment: AMBARI-17675.1.patch
> Ability to execute hooks when a management pack is installed
>
>
> Key: AMBARI-17675
> URL: https://issues.apache.org/jira/browse/AMBARI-17675
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17675.1.patch, AMBARI-17675.patch
>
>
> *Use Case:*
> Apache Ambari release bundles following views
> {code}
> ambari-admin-2.4.0.0.809.jar capacity-scheduler-2.4.0.0.809.jar
> files-2.4.0.0.809.jar hive-2.4.0.0.809.jar hive-jdbc-2.4.0.0.809.jar
> hueambarimigration-2.4.0.0.809.jar pig-2.4.0.0.809.jar
> slider-2.4.0.0.809.jar storm-view-2.4.0.0.809.jar tez-view-2.4.0.0.809.jar
> zeppelin-view-2.4.0.0.809.jar
> {code}
> A custom stack might not have the same services as HDP and thereby we need to
> prune down the list of views. Ideally, we should support adding views as
> another artifact in management pack, but we dont have support for view
> artifacts yet.
> *Solution:*
> Add hooks during management pack installation to execute such custom actions/
> cleanups.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17633) yarn.nodemanager.remote-app-log-dir should be added stickybit.
[
https://issues.apache.org/jira/browse/AMBARI-17633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masahiro Tanaka updated AMBARI-17633:
-
Attachment: AMBARI-17633.2.patch
> yarn.nodemanager.remote-app-log-dir should be added stickybit.
> --
>
> Key: AMBARI-17633
> URL: https://issues.apache.org/jira/browse/AMBARI-17633
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: trunk
> Environment: CentOS7.2 Ambari2.4, HDP2.4
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
> Attachments: AMBARI-17633.1.patch, AMBARI-17633.2.patch,
> AMBARI-17633.patch
>
>
> When installing YARN+MapReduce2, I got a WARN message in nodemanager log(in
> Log Search View) like below
> {code}
> 2016-07-09 06:30:21,865 WARN logaggregation.LogAggregationService
> LogAggregationService.java:230 - Remote Root Log Dir [/app-logs] already
> exist, but with incorrect permissions. Expected: [rwxrwxrwt], Found:
> [rwxrwxrwx]. The cluster may have problems with multiple users.
> {code}
> I think the cause of this WARN is
> [this](https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py#L115).
> We should add stickybit to {{yarn.nodemanager.remote-app-log-dir}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17648) EU does not perform service check of all services as part of upgrade
[
https://issues.apache.org/jira/browse/AMBARI-17648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373548#comment-15373548
]
Hadoop QA commented on AMBARI-17648:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12817402/AMBARI-17648.patch.1
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7802//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7802//console
This message is automatically generated.
> EU does not perform service check of all services as part of upgrade
>
>
> Key: AMBARI-17648
> URL: https://issues.apache.org/jira/browse/AMBARI-17648
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Dmytro Grinenko
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17648.patch, AMBARI-17648.patch.1
>
>
> Turns out that during Express Upgrade we run service checks for only four
> services:
> HDFS, YARN, MR2, HBASE
> the service check should be done for all services either after they are
> started or as part of a separate upgrade group before we ask the user to
> finalize
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16665) Cache service advisors when stack advisor is loaded
[ https://issues.apache.org/jira/browse/AMBARI-16665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lav Jain updated AMBARI-16665: -- Resolution: Fixed Fix Version/s: trunk Status: Resolved (was: Patch Available) [~jluniya] It was already checked into trunk and 2.4, but missed changing the status to resolved. > Cache service advisors when stack advisor is loaded > --- > > Key: AMBARI-16665 > URL: https://issues.apache.org/jira/browse/AMBARI-16665 > Project: Ambari > Issue Type: Improvement > Components: stacks >Affects Versions: trunk, 2.4.0 >Reporter: Matt >Assignee: Lav Jain > Fix For: trunk, 2.4.0 > > Attachments: AMBARI-16665.branch24.patch, > AMBARI-16665.branch24.v2.patch, AMBARI-16665.patch, AMBARI-16665.v2.patch > > > With the current implementation, service advisors for the same service are > loaded multiple times in the stack advisor. > The service advisors should be cached when the stack advisor is loaded and > used where necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16665) Cache service advisors when stack advisor is loaded
[ https://issues.apache.org/jira/browse/AMBARI-16665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lav Jain updated AMBARI-16665: -- Fix Version/s: (was: 2.5.0) 2.4.0 > Cache service advisors when stack advisor is loaded > --- > > Key: AMBARI-16665 > URL: https://issues.apache.org/jira/browse/AMBARI-16665 > Project: Ambari > Issue Type: Improvement > Components: stacks >Affects Versions: trunk, 2.4.0 >Reporter: Matt >Assignee: Lav Jain > Fix For: 2.4.0 > > Attachments: AMBARI-16665.branch24.patch, > AMBARI-16665.branch24.v2.patch, AMBARI-16665.patch, AMBARI-16665.v2.patch > > > With the current implementation, service advisors for the same service are > loaded multiple times in the stack advisor. > The service advisors should be cached when the stack advisor is loaded and > used where necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17675) Ability to execute hooks when a management pack is installed
[
https://issues.apache.org/jira/browse/AMBARI-17675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-17675:
---
Status: Patch Available (was: In Progress)
> Ability to execute hooks when a management pack is installed
>
>
> Key: AMBARI-17675
> URL: https://issues.apache.org/jira/browse/AMBARI-17675
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17675.patch
>
>
> *Use Case:*
> Apache Ambari release bundles following views
> {code}
> ambari-admin-2.4.0.0.809.jar capacity-scheduler-2.4.0.0.809.jar
> files-2.4.0.0.809.jar hive-2.4.0.0.809.jar hive-jdbc-2.4.0.0.809.jar
> hueambarimigration-2.4.0.0.809.jar pig-2.4.0.0.809.jar
> slider-2.4.0.0.809.jar storm-view-2.4.0.0.809.jar tez-view-2.4.0.0.809.jar
> zeppelin-view-2.4.0.0.809.jar
> {code}
> A custom stack might not have the same services as HDP and thereby we need to
> prune down the list of views. Ideally, we should support adding views as
> another artifact in management pack, but we dont have support for view
> artifacts yet.
> *Solution:*
> Add hooks during management pack installation to execute such custom actions/
> cleanups.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17667) Storm 1.0 Does Not Support Rolling Upgrades
[
https://issues.apache.org/jira/browse/AMBARI-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373500#comment-15373500
]
Hadoop QA commented on AMBARI-17667:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12817444/AMBARI-17667.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7801//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7801//console
This message is automatically generated.
> Storm 1.0 Does Not Support Rolling Upgrades
> ---
>
> Key: AMBARI-17667
> URL: https://issues.apache.org/jira/browse/AMBARI-17667
> 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-17667.patch
>
>
> HDP 2.5 includes a new version of Storm where packages named
> {{backtype.storm}} were changed to {{org.apache.storm}}. As a result, Storm
> local data is not compatible between versions earlier versions of HDP and HDP
> 2.5. Consider the following situatio where Nimbus and a Supervisor are
> co-located on the same host:
> - Nimbus deletes local data and restarts on the new version
> - A running 2.4 Supervisor on the same host then re-creates that directory
> and puts 2.4 data back in
> - When the 2.4 Supervisor goes to upgrade and restart, it can't delete that
> data again since Nimbus is already running and would stop.
> When starting the Supevisor, the following error is seen:
> {code}
> 2016-06-21 23:10:48.000 o.a.s.c.f.s.ConnectionStateManager [INFO] State
> change: CONNECTED
> 2016-06-21 23:10:48.058 b.s.d.supervisor [INFO] Starting supervisor with id
> 03d8bceb-0271-4076-810d-04aeaa91533c at host
> nat-os-r6-omns-dgm10toeriedwngdha-r6-2.openstacklocal
> 2016-06-21 23:10:48.785 b.s.event [ERROR] Error when processing event
> java.lang.RuntimeException: java.lang.ClassNotFoundException:
> org.apache.storm.generated.LSSupervisorAssignments
> at backtype.storm.utils.LocalState.deserialize(LocalState.java:83)
> ~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at backtype.storm.utils.LocalState.get(LocalState.java:130)
> ~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at
> backtype.storm.local_state$ls_local_assignments.invoke(local_state.clj:83)
> ~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at
> backtype.storm.daemon.supervisor$sync_processes.invoke(supervisor.clj:323)
> ~[storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at clojure.lang.AFn.applyToHelper(AFn.java:154) ~[clojure-1.6.0.jar:?]
> at clojure.lang.AFn.applyTo(AFn.java:144) ~[clojure-1.6.0.jar:?]
> at clojure.core$apply.invoke(core.clj:626) ~[clojure-1.6.0.jar:?]
> at clojure.core$partial$fn__4228.doInvoke(core.clj:2468)
> ~[clojure-1.6.0.jar:?]
> at clojure.lang.RestFn.invoke(RestFn.java:397) ~[clojure-1.6.0.jar:?]
> at backtype.storm.event$event_manager$fn__6135.invoke(event.clj:40)
> [storm-core-0.10.0.2.4.2.0-258.jar:0.10.0.2.4.2.0-258]
> at clojure.lang.AFn.run(AFn.java:22) [clojure-1.6.0.jar:?]
> at java.lang.Thread.run(Thread.java:745) [?:1.7.0_67]
> Caused by: java.lang.ClassNotFoundException:
> org.apache.storm.generated.LSSupervisorAssignments
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> ~[?:1.7.0_67]
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> ~[?:1.7.0_67]
> at java.security.AccessController.doPrivileged(Native Method)
> ~[?:1.7.0_67]
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> ~[?:1.7.0_67]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425) ~[?:1.7.0_67]
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> ~[?:1.7.0_67]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358) ~[?:1.7.0_67]
> at java.lang.Class.forName0(Native Method) ~[?:1.7.0_67]
> at java.lang.Class.forName(Class.java:190) ~[?:1.7.0_67]
> at backtype.storm.utils.LocalState.deseriali
[jira] [Updated] (AMBARI-17675) Ability to execute hooks when a management pack is installed
[
https://issues.apache.org/jira/browse/AMBARI-17675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-17675:
---
Attachment: AMBARI-17675.patch
> Ability to execute hooks when a management pack is installed
>
>
> Key: AMBARI-17675
> URL: https://issues.apache.org/jira/browse/AMBARI-17675
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17675.patch
>
>
> *Use Case:*
> Apache Ambari release bundles following views
> {code}
> ambari-admin-2.4.0.0.809.jar capacity-scheduler-2.4.0.0.809.jar
> files-2.4.0.0.809.jar hive-2.4.0.0.809.jar hive-jdbc-2.4.0.0.809.jar
> hueambarimigration-2.4.0.0.809.jar pig-2.4.0.0.809.jar
> slider-2.4.0.0.809.jar storm-view-2.4.0.0.809.jar tez-view-2.4.0.0.809.jar
> zeppelin-view-2.4.0.0.809.jar
> {code}
> A custom stack might not have the same services as HDP and thereby we need to
> prune down the list of views. Ideally, we should support adding views as
> another artifact in management pack, but we dont have support for view
> artifacts yet.
> *Solution:*
> Add hooks during management pack installation to execute such custom actions/
> cleanups.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17615) AMS metrics GET API does not work for same metric with multiple aggregation functions
[
https://issues.apache.org/jira/browse/AMBARI-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated AMBARI-17615:
---
Status: Patch Available (was: Open)
> AMS metrics GET API does not work for same metric with multiple aggregation
> functions
> -
>
> Key: AMBARI-17615
> URL: https://issues.apache.org/jira/browse/AMBARI-17615
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17615-2.patch
>
>
> AMS API which used to work in previous versions is now broken in 2.4.0 version
> {noformat}
> GET
> http://:6188/ws/v1/timeline/metrics?metricNames=bytes_in._min,bytes_in._max,bytes_in._sum,bytes_in._avg&appId=HOST&precision=hours&startTime=146692800&endTime=146743920&hostname=
> failed. Status:400
> {
> "exception": "BadRequestException",
> "message": "java.lang.Exception: Multiple aggregate functions not supported.",
> "javaClassName": "org.apache.hadoop.yarn.webapp.BadRequestException"
> }
> {noformat}
> This impacts SmartSense capture
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17615) AMS metrics GET API does not work for same metric with multiple aggregation functions
[
https://issues.apache.org/jira/browse/AMBARI-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated AMBARI-17615:
---
Attachment: AMBARI-17615-2.patch
> AMS metrics GET API does not work for same metric with multiple aggregation
> functions
> -
>
> Key: AMBARI-17615
> URL: https://issues.apache.org/jira/browse/AMBARI-17615
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17615-2.patch
>
>
> AMS API which used to work in previous versions is now broken in 2.4.0 version
> {noformat}
> GET
> http://:6188/ws/v1/timeline/metrics?metricNames=bytes_in._min,bytes_in._max,bytes_in._sum,bytes_in._avg&appId=HOST&precision=hours&startTime=146692800&endTime=146743920&hostname=
> failed. Status:400
> {
> "exception": "BadRequestException",
> "message": "java.lang.Exception: Multiple aggregate functions not supported.",
> "javaClassName": "org.apache.hadoop.yarn.webapp.BadRequestException"
> }
> {noformat}
> This impacts SmartSense capture
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17382) Migrate AMS queries to use ROW_TIMESTAMP instead of native timerange hint
[
https://issues.apache.org/jira/browse/AMBARI-17382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated AMBARI-17382:
---
Fix Version/s: (was: 2.4.0)
2.5.0
> Migrate AMS queries to use ROW_TIMESTAMP instead of native timerange hint
> -
>
> Key: AMBARI-17382
> URL: https://issues.apache.org/jira/browse/AMBARI-17382
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Labels: ambari-metrics
> Fix For: 2.5.0
>
> Attachments: AMBARI-17382.patch
>
>
> With PHOENIX-914, there is a change in implementation , As earlier, timestamp
> range was passed as a hint to the query to get advantage of native timerange
> optimization in hbase but with new implementation we can mark the timestamp
> column in the schema as a ROW_TIMESTAMP and pass timestamp range with “where”
> clause only to achieve equivalent performance and better accuracy.
> For eq:-
> With earlier implementation , AMS forms query like this:-
> SELECT /*+ NATIVE_TIME_RANGE(1448029523000) */ METRIC_NAME, APP_ID,
> INSTANCE_ID, SERVER_TIME, UNITS, METRIC_SUM, HOSTS_COUNT, METRIC_MAX,
> METRIC_MIN FROM METRIC_AGGREGATE WHERE (METRIC_NAME IN
> ('regionserver.Server.totalRequestCount',
> 'regionserver.Server.blockCacheCountHitPercent',
> 'regionserver.Server.regionCount',
> 'regionserver.Server.compactionQueueLength',
> 'regionserver.Server.storeFileCount', 'master.Server.averageLoad')) AND
> APP_ID = 'ams-hbase' AND SERVER_TIME >= 1448029643000 AND SERVER_TIME <
> 1448033243 ORDER BY METRIC_NAME, SERVER_TIME LIMIT 11520
> But with PHOENIX-914 :-
> Declare SERVER_TIME as ROW_TIMESTAMP in schema:-
> CREATE TABLE DESTINATION_METRICS_TABLE (SERVER_TIME DATE not null, METRIC_ID
> CHAR(15) not null, METRIC_VALUE bigint … CONSTRAINT PK PRIMARY
> KEY(CREATED_DATE ROW_TIMESTAMP, METRIC_ID…)) …;
> And remove hint from the query:-
> SELECT METRIC_NAME, APP_ID, INSTANCE_ID, SERVER_TIME, UNITS, METRIC_SUM,
> HOSTS_COUNT, METRIC_MAX, METRIC_MIN FROM METRIC_AGGREGATE WHERE (METRIC_NAME
> IN ('regionserver.Server.totalRequestCount',
> 'regionserver.Server.blockCacheCountHitPercent',
> 'regionserver.Server.regionCount',
> 'regionserver.Server.compactionQueueLength',
> 'regionserver.Server.storeFileCount', 'master.Server.averageLoad')) AND
> APP_ID = 'ams-hbase' AND SERVER_TIME >= 1448029643000 AND SERVER_TIME <
> 1448033243 ORDER BY METRIC_NAME, SERVER_TIME LIMIT 11520
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17615) AMS metrics GET API does not work for same metric with multiple aggregation functions
[
https://issues.apache.org/jira/browse/AMBARI-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated AMBARI-17615:
---
Attachment: (was: AMBARI-17615.patch)
> AMS metrics GET API does not work for same metric with multiple aggregation
> functions
> -
>
> Key: AMBARI-17615
> URL: https://issues.apache.org/jira/browse/AMBARI-17615
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.4.0
>
>
> AMS API which used to work in previous versions is now broken in 2.4.0 version
> {noformat}
> GET
> http://:6188/ws/v1/timeline/metrics?metricNames=bytes_in._min,bytes_in._max,bytes_in._sum,bytes_in._avg&appId=HOST&precision=hours&startTime=146692800&endTime=146743920&hostname=
> failed. Status:400
> {
> "exception": "BadRequestException",
> "message": "java.lang.Exception: Multiple aggregate functions not supported.",
> "javaClassName": "org.apache.hadoop.yarn.webapp.BadRequestException"
> }
> {noformat}
> This impacts SmartSense capture
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17382) Migrate AMS queries to use ROW_TIMESTAMP instead of native timerange hint
[
https://issues.apache.org/jira/browse/AMBARI-17382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated AMBARI-17382:
---
Status: Open (was: Patch Available)
> Migrate AMS queries to use ROW_TIMESTAMP instead of native timerange hint
> -
>
> Key: AMBARI-17382
> URL: https://issues.apache.org/jira/browse/AMBARI-17382
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Labels: ambari-metrics
> Fix For: 2.5.0
>
> Attachments: AMBARI-17382.patch
>
>
> With PHOENIX-914, there is a change in implementation , As earlier, timestamp
> range was passed as a hint to the query to get advantage of native timerange
> optimization in hbase but with new implementation we can mark the timestamp
> column in the schema as a ROW_TIMESTAMP and pass timestamp range with “where”
> clause only to achieve equivalent performance and better accuracy.
> For eq:-
> With earlier implementation , AMS forms query like this:-
> SELECT /*+ NATIVE_TIME_RANGE(1448029523000) */ METRIC_NAME, APP_ID,
> INSTANCE_ID, SERVER_TIME, UNITS, METRIC_SUM, HOSTS_COUNT, METRIC_MAX,
> METRIC_MIN FROM METRIC_AGGREGATE WHERE (METRIC_NAME IN
> ('regionserver.Server.totalRequestCount',
> 'regionserver.Server.blockCacheCountHitPercent',
> 'regionserver.Server.regionCount',
> 'regionserver.Server.compactionQueueLength',
> 'regionserver.Server.storeFileCount', 'master.Server.averageLoad')) AND
> APP_ID = 'ams-hbase' AND SERVER_TIME >= 1448029643000 AND SERVER_TIME <
> 1448033243 ORDER BY METRIC_NAME, SERVER_TIME LIMIT 11520
> But with PHOENIX-914 :-
> Declare SERVER_TIME as ROW_TIMESTAMP in schema:-
> CREATE TABLE DESTINATION_METRICS_TABLE (SERVER_TIME DATE not null, METRIC_ID
> CHAR(15) not null, METRIC_VALUE bigint … CONSTRAINT PK PRIMARY
> KEY(CREATED_DATE ROW_TIMESTAMP, METRIC_ID…)) …;
> And remove hint from the query:-
> SELECT METRIC_NAME, APP_ID, INSTANCE_ID, SERVER_TIME, UNITS, METRIC_SUM,
> HOSTS_COUNT, METRIC_MAX, METRIC_MIN FROM METRIC_AGGREGATE WHERE (METRIC_NAME
> IN ('regionserver.Server.totalRequestCount',
> 'regionserver.Server.blockCacheCountHitPercent',
> 'regionserver.Server.regionCount',
> 'regionserver.Server.compactionQueueLength',
> 'regionserver.Server.storeFileCount', 'master.Server.averageLoad')) AND
> APP_ID = 'ams-hbase' AND SERVER_TIME >= 1448029643000 AND SERVER_TIME <
> 1448033243 ORDER BY METRIC_NAME, SERVER_TIME LIMIT 11520
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17615) AMS metrics GET API does not work for same metric with multiple aggregation functions
[
https://issues.apache.org/jira/browse/AMBARI-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated AMBARI-17615:
---
Status: Open (was: Patch Available)
> AMS metrics GET API does not work for same metric with multiple aggregation
> functions
> -
>
> Key: AMBARI-17615
> URL: https://issues.apache.org/jira/browse/AMBARI-17615
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.4.0
>
>
> AMS API which used to work in previous versions is now broken in 2.4.0 version
> {noformat}
> GET
> http://:6188/ws/v1/timeline/metrics?metricNames=bytes_in._min,bytes_in._max,bytes_in._sum,bytes_in._avg&appId=HOST&precision=hours&startTime=146692800&endTime=146743920&hostname=
> failed. Status:400
> {
> "exception": "BadRequestException",
> "message": "java.lang.Exception: Multiple aggregate functions not supported.",
> "javaClassName": "org.apache.hadoop.yarn.webapp.BadRequestException"
> }
> {noformat}
> This impacts SmartSense capture
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (AMBARI-17241) Services should be able to reload configs without requiring restart
[
https://issues.apache.org/jira/browse/AMBARI-17241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373482#comment-15373482
]
Siddharth Wagle edited comment on AMBARI-17241 at 7/12/16 7:05 PM:
---
[~arpitagarwal] has a valid concern, apply configs without restart would
invariably mean triggering some custom command for the service to pick up the
new config changes. The scope of this feature should include the hooks for
specifying what command to run in order to refresh configs for a service before
returning success.
+1 [~tctruong213] suggestion for calling the tag "require-restart", which is
implicitly true by default.
*Note*: The API /stacks, endpoint should support querying of configs that do
not require restart
was (Author: swagle):
[~arpitagarwal] has a valid concern, apply configs without restart would
invariably mean triggering some custom command for the service to pick up the
new config changes. The scope of this feature should include the hooks for
specifying what command to run in order to refresh configs for a service before
returning success.
+1 [~tctruong213] suggestion for calling the tag "require-restart", which is
implicitly true by default. \
*Note*: The API /stacks, endpoint should support querying of configs that do
not require restart
> Services should be able to reload configs without requiring restart
> ---
>
> Key: AMBARI-17241
> URL: https://issues.apache.org/jira/browse/AMBARI-17241
> Project: Ambari
> Issue Type: New Feature
>Reporter: Matt
>Assignee: Matt
>Priority: Minor
> Fix For: trunk
>
> Attachments: AMBARI-17241-Design-Proposal.pdf
>
>
> The current implementation forces users to restart the service if any of the
> configurations have been updated.
> However some of the services support reloading the configuration parameters
> during run-time which does not require restart of the service.
> This behavior should be driven by metadata defined in configuration files.
> {code}
>
> foo-bar
> 0
> true
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17241) Services should be able to reload configs without requiring restart
[
https://issues.apache.org/jira/browse/AMBARI-17241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373482#comment-15373482
]
Siddharth Wagle commented on AMBARI-17241:
--
[~arpitagarwal] has a valid concern, apply configs without restart would
invariably mean triggering some custom command for the service to pick up the
new config changes. The scope of this feature should include the hooks for
specifying what command to run in order to refresh configs for a service before
returning success.
+1 [~tctruong213] suggestion for calling the tag "require-restart", which is
implicitly true by default. \
*Note*: The API /stacks, endpoint should support querying of configs that do
not require restart
> Services should be able to reload configs without requiring restart
> ---
>
> Key: AMBARI-17241
> URL: https://issues.apache.org/jira/browse/AMBARI-17241
> Project: Ambari
> Issue Type: New Feature
>Reporter: Matt
>Assignee: Matt
>Priority: Minor
> Fix For: trunk
>
> Attachments: AMBARI-17241-Design-Proposal.pdf
>
>
> The current implementation forces users to restart the service if any of the
> configurations have been updated.
> However some of the services support reloading the configuration parameters
> during run-time which does not require restart of the service.
> This behavior should be driven by metadata defined in configuration files.
> {code}
>
> foo-bar
> 0
> true
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-17675) Ability to execute hooks when a management pack is installed
Jayush Luniya created AMBARI-17675:
--
Summary: Ability to execute hooks when a management pack is
installed
Key: AMBARI-17675
URL: https://issues.apache.org/jira/browse/AMBARI-17675
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Jayush Luniya
Assignee: Jayush Luniya
Priority: Critical
Fix For: 2.4.0
*Use Case:*
Apache Ambari release bundles following views
{code}
ambari-admin-2.4.0.0.809.jar capacity-scheduler-2.4.0.0.809.jar
files-2.4.0.0.809.jar hive-2.4.0.0.809.jar hive-jdbc-2.4.0.0.809.jar
hueambarimigration-2.4.0.0.809.jar pig-2.4.0.0.809.jar slider-2.4.0.0.809.jar
storm-view-2.4.0.0.809.jar tez-view-2.4.0.0.809.jar
zeppelin-view-2.4.0.0.809.jar
{code}
A custom stack might not have the same services as HDP and thereby we need to
prune down the list of views. Ideally, we should support adding views as
another artifact in management pack, but we dont have support for view
artifacts yet.
*Solution:*
Add hooks during management pack installation to execute such custom actions/
cleanups.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17658) Storm nimbus server fails to come up with CNF backtype.storm.metric.IClusterReporter error
[
https://issues.apache.org/jira/browse/AMBARI-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373454#comment-15373454
]
Hudson commented on AMBARI-17658:
-
SUCCESS: Integrated in Ambari-trunk-Commit #5284 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5284/])
AMBARI-17658 Storm nimbus server fails to come up with CNF (dsen:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=ffb1ae7acbef73ee3fdb7f5176131b8024bb45ce])
* ambari-server/src/test/python/stacks/2.1/configs/default.json
*
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
*
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelperTest.java
*
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
*
ambari-server/src/main/java/org/apache/ambari/server/agent/ExecutionCommand.java
* ambari-server/src/test/python/stacks/2.1/configs/secured.json
*
ambari-server/src/main/resources/common-services/STORM/0.9.1/package/scripts/ui_server.py
*
ambari-server/src/main/resources/common-services/STORM/0.9.1/package/scripts/storm.py
*
ambari-server/src/main/resources/common-services/STORM/0.9.1/package/scripts/params_linux.py
> Storm nimbus server fails to come up with CNF
> backtype.storm.metric.IClusterReporter error
> --
>
> Key: AMBARI-17658
> URL: https://issues.apache.org/jira/browse/AMBARI-17658
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics, stacks
>Affects Versions: 2.4.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17658_2.patch
>
>
> See the following in nimbus log
> {code}
> 2016-07-06 21:41:51.546 o.a.s.d.nimbus [ERROR] Error on initialization of
> server service-handler
> java.lang.NoClassDefFoundError: backtype/storm/metric/IClusterReporter
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at
> org.apache.storm.metric.ClusterMetricsConsumerExecutor.prepare(ClusterMetricsConsumerExecutor.java:48)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
> at
> clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:313)
> at
> org.apache.storm.daemon.nimbus$fn__11247$exec_fn__3182__auto11248.invoke(nimbus.clj:2205)
> at clojure.lang.AFn.applyToHelper(AFn.java:156)
> at clojure.lang.AFn.applyTo(AFn.java:144)
> at clojure.core$apply.invoke(core.clj:630)
> at
> org.apache.storm.daemon.nimbus$fn__11247$service_handler__11283.doInvoke(nimbus.clj:2181)
> at clojure.lang.RestFn.invoke(RestFn.java:421)
> at
> org.apache.storm.daemon.nimbus$launch_server_BANG_.invoke(nimbus.clj:2271)
> at org.apache.storm.daemon.nimbus$_launch.invoke(nimbus.clj:2304)
> at org.apache.storm.daemon.nimbus$_main.invoke(nimbus.clj:2327)
> at clojure.lang.AFn.applyToHelper(AFn.java:152)
> at clojure.lang.AFn.applyTo(AFn.java:144)
> at org.apache.storm.daemon.nimbus.main(Unknown Source)
> Caused by: java.lang.ClassNotFoundException:
> backtype.storm.metric.IClusterReporter
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 33 more
> 2016-
[jira] [Commented] (AMBARI-17674) Installer: Sometimes retry action performs correctly on second try.
[ https://issues.apache.org/jira/browse/AMBARI-17674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373455#comment-15373455 ] Hudson commented on AMBARI-17674: - SUCCESS: Integrated in Ambari-trunk-Commit #5284 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5284/]) AMBARI-17674. Installer: Sometimes retry action performs correctly on (hiveww: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=bf0397d7feda5f5ef06192c2908d221a078fd9af]) * ambari-web/app/controllers/wizard.js > Installer: Sometimes retry action performs correctly on second try. > --- > > Key: AMBARI-17674 > URL: https://issues.apache.org/jira/browse/AMBARI-17674 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17674.patch > > > For some cases retry button works only from the second try. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17665) Fix the typo in 'alert_hive_interactive_thrift_port.py' for 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required extra '-' for 'findAppTimeout' para
[
https://issues.apache.org/jira/browse/AMBARI-17665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapan Shridhar updated AMBARI-17665:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Fix the typo in 'alert_hive_interactive_thrift_port.py' for
> 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required
> extra '-' for 'findAppTimeout' param in llapstatus comamnd.
>
>
> Key: AMBARI-17665
> URL: https://issues.apache.org/jira/browse/AMBARI-17665
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.4.0
>
> Attachments: AMBARI-17665.patch
>
>
> - Current value : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY =
> '{{hive.server2.transport.mode/hive.server2.authentication}}'
> *Fixed to :* HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY =
> '{{hive-site/hive.server2.authentication}}'
> - Added the required extra '-' for 'findAppTimeout' param in llapstatus
> comamnd.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17665) Fix the typo in 'alert_hive_interactive_thrift_port.py' for 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required extra '-' for 'findAppTimeout' pa
[
https://issues.apache.org/jira/browse/AMBARI-17665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373341#comment-15373341
]
Swapan Shridhar commented on AMBARI-17665:
--
commits :
trunk:
{code}
commit f2cf759a5fd1162bc37570b48d2e67494fd070b5
Author: Swapan Shridhar
Date: Mon Jul 11 16:40:36 2016 -0700
AMBARI-17665. Fix the typo in 'alert_hive_interactive_thrift_port.py' for
'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required extra
'-' for 'findAppTimeout' param in llapstatus comamnd.
{code}
branch-2.4:
{code}
commit fadf2d76217b2bf2ed65c05a50faaf333ac3984a
Author: Swapan Shridhar
Date: Tue Jul 12 10:53:48 2016 -0700
AMBARI-17665. Fix the typo in 'alert_hive_interactive_thrift_port.py' for
'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required extra
'-' for 'findAppTimeout' param in llapstatus comamnd.
{code}
> Fix the typo in 'alert_hive_interactive_thrift_port.py' for
> 'HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY'. Also, adding the required
> extra '-' for 'findAppTimeout' param in llapstatus comamnd.
>
>
> Key: AMBARI-17665
> URL: https://issues.apache.org/jira/browse/AMBARI-17665
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.4.0
>
> Attachments: AMBARI-17665.patch
>
>
> - Current value : HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY =
> '{{hive.server2.transport.mode/hive.server2.authentication}}'
> *Fixed to :* HIVE_SERVER2_INTERACTIVE_AUTHENTICATION_KEY =
> '{{hive-site/hive.server2.authentication}}'
> - Added the required extra '-' for 'findAppTimeout' param in llapstatus
> comamnd.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17658) Storm nimbus server fails to come up with CNF backtype.storm.metric.IClusterReporter error
[
https://issues.apache.org/jira/browse/AMBARI-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373303#comment-15373303
]
Hadoop QA commented on AMBARI-17658:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12817413/AMBARI-17658_2.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7800//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7800//console
This message is automatically generated.
> Storm nimbus server fails to come up with CNF
> backtype.storm.metric.IClusterReporter error
> --
>
> Key: AMBARI-17658
> URL: https://issues.apache.org/jira/browse/AMBARI-17658
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics, stacks
>Affects Versions: 2.4.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17658_2.patch
>
>
> See the following in nimbus log
> {code}
> 2016-07-06 21:41:51.546 o.a.s.d.nimbus [ERROR] Error on initialization of
> server service-handler
> java.lang.NoClassDefFoundError: backtype/storm/metric/IClusterReporter
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at
> org.apache.storm.metric.ClusterMetricsConsumerExecutor.prepare(ClusterMetricsConsumerExecutor.java:48)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
> at
> clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:313)
> at
> org.apache.storm.daemon.nimbus$fn__11247$exec_fn__3182__auto11248.invoke(nimbus.clj:2205)
> at clojure.lang.AFn.applyToHelper(AFn.java:156)
> at clojure.lang.AFn.applyTo(AFn.java:144)
> at clojure.core$apply.invoke(core.clj:630)
> at
> org.apache.storm.daemon.nimbus$fn__11247$service_handler__11283.doInvoke(nimbus.clj:2181)
> at clojure.lang.RestFn.invoke(RestFn.java:421)
> at
> org.apache.storm.daemon.nimbus$launch_server_BANG_.invoke(nimbus.clj:2271)
> at org.apache.storm.daemon.nimbus$_launch.invoke(nimbus.clj:2304)
> at org.apache.storm.daemon.nimbus$_main.invoke(nimbus.clj:2327)
> at clojure.lang.AFn.applyToHelper(AFn.java:152)
> at clojure.lang.AFn.applyTo(AFn.java:144)
> at org.apache.storm.daemon.nimbus.main(Unknown Source)
> Caused by: java.lang.ClassNotFoundException:
> backtype.storm.metric.IClusterReporter
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 33 more
> 2016-07-06 21:41:51.564 o.a.s.util [ERROR] Halting process: ("Error on
> initialization")
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17650) Wire encryption enabled, atlas alerts are failing.
[ https://issues.apache.org/jira/browse/AMBARI-17650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmytro Grinenko updated AMBARI-17650: - Attachment: AMBARI-17650.patch.1 > Wire encryption enabled, atlas alerts are failing. > -- > > Key: AMBARI-17650 > URL: https://issues.apache.org/jira/browse/AMBARI-17650 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Dmytro Grinenko >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17650.patch, AMBARI-17650.patch.1 > > > With wire-encryption enabled, atlas alerts are fired with incorrect port and > schema resulting in alert failure -- This message was sent by Atlassian JIRA (v6.3.4#6332)
