[jira] [Commented] (AMBARI-17489) Remove spark.yarn.max.executor.failures configuration in Spark Ambari definition
[ https://issues.apache.org/jira/browse/AMBARI-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590859#comment-15590859 ] Hudson commented on AMBARI-17489: - FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #174 (See [https://builds.apache.org/job/Ambari-branch-2.5/174/]) AMBARI-17489. Remove spark.yarn.max.executor.failures configuration in (smohanty: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=6d3ad5adf0020bc3dc3d872d6fea7595adcbd16c]) * (edit) ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/config-upgrade.xml * (edit) ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/config-upgrade.xml * (edit) ambari-server/src/main/resources/common-services/SPARK/1.6.0/configuration/spark-defaults.xml * (edit) ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.5.xml * (edit) ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.5.xml > Remove spark.yarn.max.executor.failures configuration in Spark Ambari > definition > > > Key: AMBARI-17489 > URL: https://issues.apache.org/jira/browse/AMBARI-17489 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Saisai Shao >Assignee: Saisai Shao > Fix For: 2.4.2 > > Attachments: AMBARI-17489-branch-2.4.patch > > > Currently spark.yarn.max.executor.failures should be configured in Ambari web > UI, which makes it inflexible to change, actually the default default in > Spark is more reasonable than here as "3", so propose to remove this > configuration starting from Spark 1.6.0. > CC [~zjffdu], please suggest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-17489) Remove spark.yarn.max.executor.failures configuration in Spark Ambari definition
[ https://issues.apache.org/jira/browse/AMBARI-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty resolved AMBARI-17489. Resolution: Fixed > Remove spark.yarn.max.executor.failures configuration in Spark Ambari > definition > > > Key: AMBARI-17489 > URL: https://issues.apache.org/jira/browse/AMBARI-17489 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Saisai Shao >Assignee: Saisai Shao > Fix For: 2.4.2 > > Attachments: AMBARI-17489-branch-2.4.patch > > > Currently spark.yarn.max.executor.failures should be configured in Ambari web > UI, which makes it inflexible to change, actually the default default in > Spark is more reasonable than here as "3", so propose to remove this > configuration starting from Spark 1.6.0. > CC [~zjffdu], please suggest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17105) Ambari Server Unit Test failures on trunk
[
https://issues.apache.org/jira/browse/AMBARI-17105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated AMBARI-17105:
---
Attachment: AMBARI-17105.patch
> Ambari Server Unit Test failures on trunk
> -
>
> Key: AMBARI-17105
> URL: https://issues.apache.org/jira/browse/AMBARI-17105
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17105.patch
>
>
> These errors are gone in the latest runs.
> Now the latest shows a failure for
> *org.apache.ambari.server.controller.internal.HostResourceProviderTest.testUpdateResourcesAsServiceAdministrator*:
> https://builds.apache.org/job/Ambari-trunk-Commit/5023/testReport/org.apache.ambari.server.controller.internal/HostResourceProviderTest/testUpdateResourcesAsServiceAdministrator/
> {code}
> Error Message
> Unexpected exception,
> expected
> but was
> Stacktrace
> java.lang.Exception: Unexpected exception,
> expected
> but was
> at
> org.apache.ambari.server.controller.internal.HostResourceProviderTest.testUpdateResources(HostResourceProviderTest.java:1036)
> at
> org.apache.ambari.server.controller.internal.HostResourceProviderTest.testUpdateResourcesAsServiceAdministrator(HostResourceProviderTest.java:966)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (AMBARI-18291) Ambari tempory path configuration
[ https://issues.apache.org/jira/browse/AMBARI-18291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty reopened AMBARI-18291: > Ambari tempory path configuration > - > > Key: AMBARI-18291 > URL: https://issues.apache.org/jira/browse/AMBARI-18291 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 > Environment: all >Reporter: amarnathreddy >Assignee: amarnathreddy >Priority: Trivial > Fix For: 2.4.0 > > > By default Ambari uses "/tmp" as temporary path, > 1. while using Ambari-server it creates so many temporary files under /tmp > path. > 2. While doing the file upload in the File View, Ambari uses /tmp path during > the file upload and if there is no enough space left then file upload would > fail. > Proposing solution: > path should be configurable in ambari.properties -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-18291) Ambari tempory path configuration
[ https://issues.apache.org/jira/browse/AMBARI-18291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty resolved AMBARI-18291. Resolution: Duplicate > Ambari tempory path configuration > - > > Key: AMBARI-18291 > URL: https://issues.apache.org/jira/browse/AMBARI-18291 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 > Environment: all >Reporter: amarnathreddy >Assignee: amarnathreddy >Priority: Trivial > Fix For: 2.4.0 > > > By default Ambari uses "/tmp" as temporary path, > 1. while using Ambari-server it creates so many temporary files under /tmp > path. > 2. While doing the file upload in the File View, Ambari uses /tmp path during > the file upload and if there is no enough space left then file upload would > fail. > Proposing solution: > path should be configurable in ambari.properties -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18038) HBase start failing with API
[
https://issues.apache.org/jira/browse/AMBARI-18038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sumit Mohanty updated AMBARI-18038:
---
Attachment: rb50849.patch
> HBase start failing with API
>
>
> Key: AMBARI-18038
> URL: https://issues.apache.org/jira/browse/AMBARI-18038
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Shreya Bhat
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Labels: system_test
> Fix For: 2.4.0
>
> Attachments: rb50849.patch
>
>
> UrlPath : /api/v1/clusters/cl1
> Using username : admin
> Request body : {"RequestInfo":{"command":"RESTART","context":"Restart all
> required
> services","operation_level":"host_component"},"Requests/resource_filters":[{"hosts_predicate":"HostRoles/stale_configs=true"}]}
> Failed task :
> {code}
> "Traceback (most recent call last):\n File
> \"/var/lib/ambari-agent/cache/common-services/HBASE/0.96.0.2.0/package/scripts/hbase_regionserver.py\",
> line 194, in \nHbaseRegionServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 280, in execute\nmethod(env)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 720, in restart\nself.start(env, upgrade_type=upgrade_type)\n File
> \"/var/lib/ambari-agent/cache/common-services/HBASE/0.96.0.2.0/package/scripts/hbase_regionserver.py\",
> line 120, in start\nself.post_start(env, upgrade_type=upgrade_type)\n
> File
> \"/var/lib/ambari-agent/cache/common-services/HBASE/0.96.0.2.0/package/scripts/hbase_regionserver.py\",
> line 89, in post_start\nself.apply_atlas_acl(params.hbase_user)\n File
> \"/var/lib/ambari-agent/cache/common-services/HBASE/0.96.0.2.0/package/scripts/hbase_regionserver.py\",
> line 110, in apply_atlas_acl\nshell.checked_call(format(\"{kinit_cmd};
> {permissions_cmd}\"), tries=10, try_sleep=10)\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
> '/usr/bin/kinit -kt /etc/security/keytabs/hbase.service.keytab
> hbase/nat-r6-ohis-ambari-api-rbac-6-2.openstacklo...@example.com; echo
> \"grant 'atlas', 'RWXCA'\" | hbase shell -n' returned 1. kinit: Permission
> denied while getting initial credentials\n2016-08-05 04:29:14,573 FATAL
> [main] conf.Configuration: error parsing conf
> core-site.xml\njava.io.FileNotFoundException:
> /etc/hbase/2.5.0.0-1145/0/core-site.xml (Permission denied)\n\tat
> java.io.FileInputStream.open0(Native Method)\n\tat
> java.io.FileInputStream.open(FileInputStream.java:195)\n\tat
> java.io.FileInputStream.(FileInputStream.java:138)\n\tat
> java.io.FileInputStream.(FileInputStream.java:93)\n\tat
> sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:90)\n\tat
>
> sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:188)\n\tat
> java.net.URL.openStream(URL.java:1045)\n\tat
> org.apache.hadoop.conf.Configuration.parse(Configuration.java:2502)\n\tat
> org.apache.hadoop.conf.Configuration.loadResource(Configuration.java:2573)\n\tat
>
> org.apache.hadoop.conf.Configuration.loadResources(Configuration.java:2526)\n\tat
> org.apache.hadoop.conf.Configuration.getProps(Configuration.java:2418)\n\tat
> org.apache.hadoop.conf.Configuration.set(Configuration.java:1143)\n\tat
> org.apache.hadoop.conf.Configuration.set(Configuration.java:1115)\n\tat
> org.apache.hadoop.conf.Configuration.setBoolean(Configuration.java:1451)\n\tat
>
> org.apache.hadoop.hbase.io.compress.Compression$Algorithm.(Compression.java:249)\n\tat
>
> org.apache.hadoop.hbase.io.compress.Compression$Algorithm.(Compression.java:105)\n\tat
>
> org.apache.hadoop.hbase.io.compress.Compression$Algorithm$1.(Compression.java:106)\n\tat
>
> org.apache.hadoop.hbase.io.compress.Compression$Algorithm.(Compression.java:106)\n\tat
>
> org.apache.hadoop.hbase.HColumnDescriptor.(HColumnDescriptor.java:135)\n\tat
> java.lang.Class.forName0(Native Method)\n\tat
> java.lang.Class.forName(Class.java:348)\n\tat
> org.jruby.javasupport.JavaSupport.loadJavaClass(JavaSupport.java:136)\n\tat
>
[jira] [Updated] (AMBARI-18475) Remove Global Cluster Lock Shared Between Business Objects
[
https://issues.apache.org/jira/browse/AMBARI-18475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sumit Mohanty updated AMBARI-18475:
---
Attachment: AMBARI-18475.patch
> Remove Global Cluster Lock Shared Between Business Objects
> --
>
> Key: AMBARI-18475
> URL: https://issues.apache.org/jira/browse/AMBARI-18475
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18475.patch
>
>
> Remove shared instances of the shared {{ReadWriteLock}} found in
> {{ClusterImpl}}. For now, the lock can remain private and full encapsulated
> inside of {{ClusterImpl}}, but it's use and reference across the rest of
> Ambari should be removed.
> This is part of the effort to refactor/remove the (mostly) unnecessary locks
> in memory. The shared instance of this lock is the number one reason that
> Ambari "deadlocks" when under load.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18393) Hive Server Interactive (HSI) fails to start with 'Permission denied' for User Hive, if HSI starts before HS2.
[
https://issues.apache.org/jira/browse/AMBARI-18393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sumit Mohanty updated AMBARI-18393:
---
Attachment: AMBARI-18393.patch
> Hive Server Interactive (HSI) fails to start with 'Permission denied' for
> User Hive, if HSI starts before HS2.
> --
>
> Key: AMBARI-18393
> URL: https://issues.apache.org/jira/browse/AMBARI-18393
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.5.0
>
> Attachments: AMBARI-18393.patch
>
>
> - Install Cluster using Blueprint including HiveServerInteractive
> - Start services fail at Hive interactive start, with below error:
> {code}
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_interactive.py",
> line 535, in
> HiveServerInteractive().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 280, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_interactive.py",
> line 115, in start
> self.setup_security()
> File
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_interactive.py",
> line 335, in setup_security
> Execute(slider_keytab_install_cmd, user=params.hive_user)
> File "/usr/lib/python2.6/site-packages/resource_management/core/base.py",
> line 155, in __init__
> self.env.run()
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 160, in run
> self.run_action(resource, action)
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 124, in run_action
> provider_action()
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
> line 273, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 71, in inner
> result = function(command, **kwargs)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 93, in checked_call
> tries=tries, try_sleep=try_sleep)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 141, in _call_wrapper
> result = _call(command, **kwargs_copy)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 294, in _call
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'slider install-keytab
> --keytab /etc/security/keytabs/hive.llap.zk.sm.keytab --folder hive
> --overwrite' returned 56. 2016-08-15 23:47:57,518 [main] INFO
> tools.SliderUtils - JVM initialized into secure mode with kerberos realm
> HWQE.HORTONWORKS.COM
> 2016-08-15 23:47:59,108 [main] INFO impl.TimelineClientImpl - Timeline
> service address:
> http://nat-s11-4-lkws-stackdeploy-3.openstacklocal:8188/ws/v1/timeline/
> 2016-08-15 23:48:01,584 [main] WARN shortcircuit.DomainSocketFactory - The
> short-circuit local reads feature cannot be used because libhadoop cannot be
> loaded.
> 2016-08-15 23:48:01,633 [main] INFO client.RMProxy - Connecting to
> ResourceManager at
> nat-s11-4-lkws-stackdeploy-5.openstacklocal/172.22.71.181:8050
> 2016-08-15 23:48:01,983 [main] INFO client.AHSProxy - Connecting to
> Application History server at
> nat-s11-4-lkws-stackdeploy-3.openstacklocal/172.22.71.168:10200
> 2016-08-15 23:48:03,297 [main] WARN client.SliderClient - The
> 'install-keytab' option has been deprecated. Please use 'keytab --install'.
> 2016-08-15 23:48:03,440 [main] WARN retry.RetryInvocationHandler - Exception
> while invoking ClientNamenodeProtocolTranslatorPB.mkdirs over null. Not
> retrying because try once and fail.
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
> Permission denied: user=hive, access=WRITE,
> inode="/user/hive/.slider/keytabs/hive":hdfs:hdfs:drwxr-xr-x
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:319)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:292)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:213)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:190)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1827)
>
[jira] [Updated] (AMBARI-17489) Remove spark.yarn.max.executor.failures configuration in Spark Ambari definition
[ https://issues.apache.org/jira/browse/AMBARI-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-17489: --- Attachment: AMBARI-17489-branch-2.4.patch > Remove spark.yarn.max.executor.failures configuration in Spark Ambari > definition > > > Key: AMBARI-17489 > URL: https://issues.apache.org/jira/browse/AMBARI-17489 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Saisai Shao >Assignee: Saisai Shao > Fix For: 2.4.2 > > Attachments: AMBARI-17489-branch-2.4.patch > > > Currently spark.yarn.max.executor.failures should be configured in Ambari web > UI, which makes it inflexible to change, actually the default default in > Spark is more reasonable than here as "3", so propose to remove this > configuration starting from Spark 1.6.0. > CC [~zjffdu], please suggest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17489) Remove spark.yarn.max.executor.failures configuration in Spark Ambari definition
[ https://issues.apache.org/jira/browse/AMBARI-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590615#comment-15590615 ] Saisai Shao commented on AMBARI-17489: -- [~sumitmohanty], I've rebased this patch to branch-2.4 and 2.5 (https://reviews.apache.org/r/49484/), looks like branch 2.5 can be auto merged, so one patch is enough. Please review. Thanks a lot. > Remove spark.yarn.max.executor.failures configuration in Spark Ambari > definition > > > Key: AMBARI-17489 > URL: https://issues.apache.org/jira/browse/AMBARI-17489 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Saisai Shao >Assignee: Saisai Shao > Fix For: 2.4.2 > > > Currently spark.yarn.max.executor.failures should be configured in Ambari web > UI, which makes it inflexible to change, actually the default default in > Spark is more reasonable than here as "3", so propose to remove this > configuration starting from Spark 1.6.0. > CC [~zjffdu], please suggest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18639) Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
[
https://issues.apache.org/jira/browse/AMBARI-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590355#comment-15590355
]
Jaimin D Jetly commented on AMBARI-18639:
-
+1 for the patch.
> Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
> -
>
> Key: AMBARI-18639
> URL: https://issues.apache.org/jira/browse/AMBARI-18639
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.1, 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18639-2.5.patch, AMBARI-18639-2.5.patch,
> AMBARI-18639.patch
>
>
> Ambari UI does not allow to modify threshold of *'OK'* and *'WARNING'* in
> ResourceManager WEB UI alert.
> *Steps to reproduce:*
> 1. Remove threshold from WARNING/OK at alert of ResourceManager WEB UI
> 2. Save
> 3. Refresh Ambari UI and and the field is blank *- Expected*
> 4. Add any threshold string (may be the one that you removed) to WARNING/OK
> and then save
> 5. Refresh Ambari UI. _Here is the problem._ *It shows just blank.*
> 6. API /api/v1/clusters/young-hdp250/alert_definitions/44 shows blank too.
> - It's happening because the PUT call is sent empty.
> !RM Web UI- Alert Definitioni.jpg|thumbnail!
> {code}
> "critical" : {
> "text" : "Connection failed to {1} ({3})"
> },
> "ok" : {
> "text" : "HTTP {0} response in {2:.3f}s"
> },
> "warning" : {
> "text" : ""
> }
> {code}
> *Workaround:*
> Manual update using curl command works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18639) Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
[
https://issues.apache.org/jira/browse/AMBARI-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xi Wang updated AMBARI-18639:
-
Attachment: AMBARI-18639-2.5.patch
> Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
> -
>
> Key: AMBARI-18639
> URL: https://issues.apache.org/jira/browse/AMBARI-18639
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.1, 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18639-2.5.patch, AMBARI-18639-2.5.patch,
> AMBARI-18639.patch
>
>
> Ambari UI does not allow to modify threshold of *'OK'* and *'WARNING'* in
> ResourceManager WEB UI alert.
> *Steps to reproduce:*
> 1. Remove threshold from WARNING/OK at alert of ResourceManager WEB UI
> 2. Save
> 3. Refresh Ambari UI and and the field is blank *- Expected*
> 4. Add any threshold string (may be the one that you removed) to WARNING/OK
> and then save
> 5. Refresh Ambari UI. _Here is the problem._ *It shows just blank.*
> 6. API /api/v1/clusters/young-hdp250/alert_definitions/44 shows blank too.
> - It's happening because the PUT call is sent empty.
> !RM Web UI- Alert Definitioni.jpg|thumbnail!
> {code}
> "critical" : {
> "text" : "Connection failed to {1} ({3})"
> },
> "ok" : {
> "text" : "HTTP {0} response in {2:.3f}s"
> },
> "warning" : {
> "text" : ""
> }
> {code}
> *Workaround:*
> Manual update using curl command works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (AMBARI-17489) Remove spark.yarn.max.executor.failures configuration in Spark Ambari definition
[ https://issues.apache.org/jira/browse/AMBARI-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590303#comment-15590303 ] Sumit Mohanty edited comment on AMBARI-17489 at 10/20/16 12:05 AM: --- [~jerryshao] can you rebase the patch for branch-2.4/branch-2.5? was (Author: sumitmohanty): [~jerryshao] can you rebase the patch for branch-2.4? > Remove spark.yarn.max.executor.failures configuration in Spark Ambari > definition > > > Key: AMBARI-17489 > URL: https://issues.apache.org/jira/browse/AMBARI-17489 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Saisai Shao >Assignee: Saisai Shao > Fix For: 2.4.2 > > > Currently spark.yarn.max.executor.failures should be configured in Ambari web > UI, which makes it inflexible to change, actually the default default in > Spark is more reasonable than here as "3", so propose to remove this > configuration starting from Spark 1.6.0. > CC [~zjffdu], please suggest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17489) Remove spark.yarn.max.executor.failures configuration in Spark Ambari definition
[ https://issues.apache.org/jira/browse/AMBARI-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590303#comment-15590303 ] Sumit Mohanty commented on AMBARI-17489: [~jerryshao] can you rebase the patch for branch-2.4? > Remove spark.yarn.max.executor.failures configuration in Spark Ambari > definition > > > Key: AMBARI-17489 > URL: https://issues.apache.org/jira/browse/AMBARI-17489 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Saisai Shao >Assignee: Saisai Shao > Fix For: 2.4.2 > > > Currently spark.yarn.max.executor.failures should be configured in Ambari web > UI, which makes it inflexible to change, actually the default default in > Spark is more reasonable than here as "3", so propose to remove this > configuration starting from Spark 1.6.0. > CC [~zjffdu], please suggest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17489) Remove spark.yarn.max.executor.failures configuration in Spark Ambari definition
[ https://issues.apache.org/jira/browse/AMBARI-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-17489: --- Fix Version/s: (was: 2.4.0) 2.4.2 > Remove spark.yarn.max.executor.failures configuration in Spark Ambari > definition > > > Key: AMBARI-17489 > URL: https://issues.apache.org/jira/browse/AMBARI-17489 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Saisai Shao >Assignee: Saisai Shao > Fix For: 2.4.2 > > > Currently spark.yarn.max.executor.failures should be configured in Ambari web > UI, which makes it inflexible to change, actually the default default in > Spark is more reasonable than here as "3", so propose to remove this > configuration starting from Spark 1.6.0. > CC [~zjffdu], please suggest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17489) Remove spark.yarn.max.executor.failures configuration in Spark Ambari definition
[ https://issues.apache.org/jira/browse/AMBARI-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-17489: --- Fix Version/s: 2.4.0 > Remove spark.yarn.max.executor.failures configuration in Spark Ambari > definition > > > Key: AMBARI-17489 > URL: https://issues.apache.org/jira/browse/AMBARI-17489 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.4.0 >Reporter: Saisai Shao >Assignee: Saisai Shao > Fix For: 2.4.0 > > > Currently spark.yarn.max.executor.failures should be configured in Ambari web > UI, which makes it inflexible to change, actually the default default in > Spark is more reasonable than here as "3", so propose to remove this > configuration starting from Spark 1.6.0. > CC [~zjffdu], please suggest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17981) Integrate Druid With Ambari
[ https://issues.apache.org/jira/browse/AMBARI-17981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590257#comment-15590257 ] slim bouguerra commented on AMBARI-17981: - this is suppose to go against ambari stack 2.6 not 2.5 thought ? > Integrate Druid With Ambari > --- > > Key: AMBARI-17981 > URL: https://issues.apache.org/jira/browse/AMBARI-17981 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.5.0 >Reporter: Nishant Bangarwa > Labels: features > Attachments: ambari-17981.patch > > > This task includes adding support for druid cluster provisioning via Ambari. > Details about Druid cluster design and different node types are present here > - > http://druid.io/docs/latest/design/design.html > In general, Druid can be defined as a service in HDP which has following > components - > 1) Coordinator > 2) Overlord > 3) Historical > 4) Broker > 5) Middlemanager > > Druid also has external dependencies on following > 1) Zookeeper - Ambari should be able to pass in zk configs to druid cluster > 2) Deep storage - A distributed FS, can be one of HDFS/S3 or any other NFS. > 3) Metadata Store - Mysql/Postgres. can be either provided by the user or a > mysql instance provisioned by ambari itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18639) Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
[
https://issues.apache.org/jira/browse/AMBARI-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590215#comment-15590215
]
Jaimin D Jetly commented on AMBARI-18639:
-
Ember.isEmpty takes account for null, undefined and empty string values. If any
of the input value is among these three then the tweaked logic converts it to
null using ternary operator
If we still want null and undefined values to be converted to null then lets
just change Ember.isEmpty to Ember.isNone
Current change
{code}
return warning && warning.get(property) != null ? warning.get(property) : null;
{code}
is same as
{code}
return warning ? warning.get(property) : null;
{code}
Lets make it
{code}
return warning && !Ember.isNone(warning.get(property)) ? warning.get(property)
: null;
{code}
> Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
> -
>
> Key: AMBARI-18639
> URL: https://issues.apache.org/jira/browse/AMBARI-18639
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.1, 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18639-2.5.patch, AMBARI-18639.patch
>
>
> Ambari UI does not allow to modify threshold of *'OK'* and *'WARNING'* in
> ResourceManager WEB UI alert.
> *Steps to reproduce:*
> 1. Remove threshold from WARNING/OK at alert of ResourceManager WEB UI
> 2. Save
> 3. Refresh Ambari UI and and the field is blank *- Expected*
> 4. Add any threshold string (may be the one that you removed) to WARNING/OK
> and then save
> 5. Refresh Ambari UI. _Here is the problem._ *It shows just blank.*
> 6. API /api/v1/clusters/young-hdp250/alert_definitions/44 shows blank too.
> - It's happening because the PUT call is sent empty.
> !RM Web UI- Alert Definitioni.jpg|thumbnail!
> {code}
> "critical" : {
> "text" : "Connection failed to {1} ({3})"
> },
> "ok" : {
> "text" : "HTTP {0} response in {2:.3f}s"
> },
> "warning" : {
> "text" : ""
> }
> {code}
> *Workaround:*
> Manual update using curl command works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16969) Provide ability in AMS to filter tracked metrics through a whitelist metic file.
[ https://issues.apache.org/jira/browse/AMBARI-16969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravindan Vijayan updated AMBARI-16969: --- Description: The file should contain a list of metrics that will be the only metrics stored and aggregated in AMS. Config to use for specifying whitelisted metric file. ams-site : timeline.metrics.whitelist.file Additional change - Ability to specifiy different durability settings for precision/aggregate tables. ams-site : timeline.metrics.precision.table.durability ams-site : timeline.metrics.aggregate.tables.durability Valid values it can take : SKIP_WAL / SYNC_WAL / ASYNC_WAL / FSYNC_WAL was: The file should contain a list of metrics that will be the only metrics stored and aggregated in AMS. Config to use for specifying metric file. ams-site : timeline.metrics.whitelist.file Additional change - Ability to specifiy different durability settings for precision/aggregate tables. ams-site : timeline.metrics.precision.table.durability ams-site : timeline.metrics.aggregate.tables.durability Valid values it can take : SKIP_WAL / SYNC_WAL / ASYNC_WAL / FSYNC_WAL > Provide ability in AMS to filter tracked metrics through a whitelist metic > file. > > > Key: AMBARI-16969 > URL: https://issues.apache.org/jira/browse/AMBARI-16969 > Project: Ambari > Issue Type: Task >Affects Versions: 2.4.0 >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan > Fix For: 2.4.0 > > Attachments: AMBARI-16969-trunk.patch, AMBARI-16969.patch > > > The file should contain a list of metrics that will be the only metrics > stored and aggregated in AMS. > Config to use for specifying whitelisted metric file. > ams-site : timeline.metrics.whitelist.file > Additional change - Ability to specifiy different durability settings for > precision/aggregate tables. > ams-site : timeline.metrics.precision.table.durability > ams-site : timeline.metrics.aggregate.tables.durability > Valid values it can take : SKIP_WAL / SYNC_WAL / ASYNC_WAL / FSYNC_WAL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (AMBARI-18633) Mapreduce 'Config group' changes YARN Config Group overrides and vice versa.
[ https://issues.apache.org/jira/browse/AMBARI-18633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yusaku Sako updated AMBARI-18633: - Comment: was deleted (was: Committed to branch 2.2.2-maint) > Mapreduce 'Config group' changes YARN Config Group overrides and vice versa. > > > Key: AMBARI-18633 > URL: https://issues.apache.org/jira/browse/AMBARI-18633 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk >Priority: Blocker > Attachments: AMBARI-18633_branch-2.2.2.patch > > > *STR:* > # Change a config (Memory allocated for all YARN containers on a node) from > non-default service group in YARN service and save. > # Navigate to MapReduce service and choose a non-default service group to > make config changes (Map Memory) and save > *Expected Result:* MapReduce config for non-default service group should get > successfully saved > *Actual Result:* Along wth the MapReduce config changes, non-default service > group of YARN that was previously tweaked gets reset to empty bag of > properties. > It is noticed that while saving configs of non-default group of MapReduce > service, two PUT API calls are made: one for MapReduce which is expected but > one more for YARN non-default service group with empty array for desired > configs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18245) Upgrade node to version 4.x
[ https://issues.apache.org/jira/browse/AMBARI-18245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhe (Joe) Wang updated AMBARI-18245: Fix Version/s: (was: trunk) 2.5.0 > Upgrade node to version 4.x > --- > > Key: AMBARI-18245 > URL: https://issues.apache.org/jira/browse/AMBARI-18245 > Project: Ambari > Issue Type: Task > Components: ambari-admin, ambari-views, ambari-web >Affects Versions: trunk >Reporter: Yusaku Sako >Assignee: Zhe (Joe) Wang > Fix For: 2.5.0 > > Attachments: AMBARI-18245.v0.patch, AMBARI-18245.v1.patch > > > We are currently using 0.10, which is very old and going EOL 2016-10-01: > https://github.com/nodejs/LTS > We should look into upgrading to Node 4.x: > * Upgrade Node on Ambari Web > * Upgrade Node on Ambari Admin > * Upgrade Node on contrib/views/* modules -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18245) Upgrade node to version 4.x
[ https://issues.apache.org/jira/browse/AMBARI-18245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhe (Joe) Wang updated AMBARI-18245: Resolution: Fixed Status: Resolved (was: Patch Available) Patch committed to branch-2.5 1b32cd0427e4a7de0cc5af65746d620cb2db448c and trunk 7be041894a6384a211aee965be36b1d429103fb3 > Upgrade node to version 4.x > --- > > Key: AMBARI-18245 > URL: https://issues.apache.org/jira/browse/AMBARI-18245 > Project: Ambari > Issue Type: Task > Components: ambari-admin, ambari-views, ambari-web >Affects Versions: trunk >Reporter: Yusaku Sako >Assignee: Zhe (Joe) Wang > Fix For: 2.5.0 > > Attachments: AMBARI-18245.v0.patch, AMBARI-18245.v1.patch > > > We are currently using 0.10, which is very old and going EOL 2016-10-01: > https://github.com/nodejs/LTS > We should look into upgrading to Node 4.x: > * Upgrade Node on Ambari Web > * Upgrade Node on Ambari Admin > * Upgrade Node on contrib/views/* modules -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18641) When the value "Audit to DB/Audit to Solr/Audit to HDFS" is turned to ON, Ambari should automatically set ranger.audit.source.type to the right value
[ https://issues.apache.org/jira/browse/AMBARI-18641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chun Tam updated AMBARI-18641: -- Description: PROBLEM: When the value "Audit to DB/Audit to Solr/Audit to HDFS" is turned to ON, Ambari should automatically set ranger.audit.source.type to the right value. Either one of the properties should be deprecated BUSINESS IMPACT: This is confusing Reproduced on Ambari 2.2.2 > When the value "Audit to DB/Audit to Solr/Audit to HDFS" is turned to ON, > Ambari should automatically set ranger.audit.source.type to the right value > - > > Key: AMBARI-18641 > URL: https://issues.apache.org/jira/browse/AMBARI-18641 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Chun Tam > > PROBLEM: When the value "Audit to DB/Audit to Solr/Audit to HDFS" is turned > to ON, Ambari should automatically set ranger.audit.source.type to the right > value. Either one of the properties should be deprecated > BUSINESS IMPACT: This is confusing > Reproduced on Ambari 2.2.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18641) When the value "Audit to DB/Audit to Solr/Audit to HDFS" is turned to ON, Ambari should automatically set ranger.audit.source.type to the right value
Chun Tam created AMBARI-18641: - Summary: When the value "Audit to DB/Audit to Solr/Audit to HDFS" is turned to ON, Ambari should automatically set ranger.audit.source.type to the right value Key: AMBARI-18641 URL: https://issues.apache.org/jira/browse/AMBARI-18641 Project: Ambari Issue Type: Bug Components: ambari-server Reporter: Chun Tam -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18639) Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
[
https://issues.apache.org/jira/browse/AMBARI-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xi Wang updated AMBARI-18639:
-
Status: Patch Available (was: Open)
> Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
> -
>
> Key: AMBARI-18639
> URL: https://issues.apache.org/jira/browse/AMBARI-18639
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.1, 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18639-2.5.patch, AMBARI-18639.patch
>
>
> Ambari UI does not allow to modify threshold of *'OK'* and *'WARNING'* in
> ResourceManager WEB UI alert.
> *Steps to reproduce:*
> 1. Remove threshold from WARNING/OK at alert of ResourceManager WEB UI
> 2. Save
> 3. Refresh Ambari UI and and the field is blank *- Expected*
> 4. Add any threshold string (may be the one that you removed) to WARNING/OK
> and then save
> 5. Refresh Ambari UI. _Here is the problem._ *It shows just blank.*
> 6. API /api/v1/clusters/young-hdp250/alert_definitions/44 shows blank too.
> - It's happening because the PUT call is sent empty.
> !RM Web UI- Alert Definitioni.jpg|thumbnail!
> {code}
> "critical" : {
> "text" : "Connection failed to {1} ({3})"
> },
> "ok" : {
> "text" : "HTTP {0} response in {2:.3f}s"
> },
> "warning" : {
> "text" : ""
> }
> {code}
> *Workaround:*
> Manual update using curl command works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18636) Remove "hbase.rpc.controllerfactory.class" from hbase-site.xml
[ https://issues.apache.org/jira/browse/AMBARI-18636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589730#comment-15589730 ] Enis Soztutar commented on AMBARI-18636: LGTM. > Remove "hbase.rpc.controllerfactory.class" from hbase-site.xml > -- > > Key: AMBARI-18636 > URL: https://issues.apache.org/jira/browse/AMBARI-18636 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.0 >Reporter: Sandor Magyari >Assignee: Sandor Magyari >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18636.patch > > > Do not set "hbase.rpc.controllerfactory.class" property even if Phoenix is > deployed as it causes problem on a cluster with HBASE & Phoenix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18636) Remove "hbase.rpc.controllerfactory.class" from hbase-site.xml
[
https://issues.apache.org/jira/browse/AMBARI-18636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589694#comment-15589694
]
Hadoop QA commented on AMBARI-18636:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834199/AMBARI-18636.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/8923//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8923//console
This message is automatically generated.
> Remove "hbase.rpc.controllerfactory.class" from hbase-site.xml
> --
>
> Key: AMBARI-18636
> URL: https://issues.apache.org/jira/browse/AMBARI-18636
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18636.patch
>
>
> Do not set "hbase.rpc.controllerfactory.class" property even if Phoenix is
> deployed as it causes problem on a cluster with HBASE & Phoenix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18456) Refactor Unnecessary In-Memory Locks Around Business Objects
[
https://issues.apache.org/jira/browse/AMBARI-18456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589696#comment-15589696
]
Jonathan Hurley commented on AMBARI-18456:
--
{noformat}
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 28:57 min
[INFO] Finished at: 2016-10-19T14:20:53-04:00
[INFO] Final Memory: 45M/359M
[INFO]
{noformat}
> Refactor Unnecessary In-Memory Locks Around Business Objects
>
>
> Key: AMBARI-18456
> URL: https://issues.apache.org/jira/browse/AMBARI-18456
> Project: Ambari
> Issue Type: Epic
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
> Labels: branch-feature-AMBARI-18456
> Fix For: 2.5.0
>
>
> The top 4 business objects in Ambari:
> - ClusterImpl
> - ServiceImpl
> - ServiceComponentImpl
> - ServiceComponentHostImpl
> All use {{ReadWriteLock}} implementations to prevent dirty reads and
> concurrent writes. However, {{ClusterImpl}} exposes a "global"
> {{ReadWriteLock}} which the other business objects share. This causes
> tremendous problems with deadlocks, especially on slow databases.
> Consider the case where you have 3 threads:
> # thread-1 acquires {{ClusterReadLock}}
> # thread-2 acquires {{ServiceComponenWriteLock}}
> # thread-3 tries to get {{ClusterWriteLock}} and is blocked by {{thread-1}}
> # thread-2 tries to get {{ClusterReadLock}} and is blocked by {{thread-3}}
> # thread-1 tries to get {{ServiceComponentReadLock}} and is blocked by
> {{thread-2}}
> Essentially, the exposure of the "cluster global lock" causes problems since
> multiple threads can acquire other internal locks and be blocked waiting on
> the global lock.
> In general, I don't believe that the read locks help at all. Ambari usually
> encounters these locks while try to display web page information. Once
> displayed, the locks are removed and the information is already stale if
> there were write threads waiting.
> These locks should be investigated and, for the most part, except in some
> cases involving concurrent writes, removed.
> Part of the problem revolves around our assumption about how the
> ReadWriteLock works. The issue in the above scenario is that the
> clusterWriteLock request is pending. This actually blocks all subsequent
> readers even though the lock is not fair.
> FYI, this code shows that a reader, in unfair mode, will wait when there is a
> waiting writer:
> {noformat:title=Output}
> Waiting for a read lock...
> Read lock acquired!
> Waiting for a write lock...
> Trying to acquire a second read lock...
> {noformat}
> {code}
> import java.util.concurrent.locks.ReentrantReadWriteLock;
> public class Test {
> private static ReentrantReadWriteLock lock = new
> ReentrantReadWriteLock(false);
> public static void main(String[] args) throws InterruptedException {
> // A reader which takes too long to finish
> new Thread() {
> @Override
> public void run() {
> System.out.println("Waiting for a read lock...");
> lock.readLock().lock();
> System.out.println("Read lock acquired!");
> try {
> try {
> Thread.sleep(1000 * 60 * 60);
> } catch (InterruptedException e) {
> }
> } finally {
> lock.readLock().unlock();
> }
> }
> }.start();
> Thread.sleep(3000);
> // A writer which will be waiting
> new Thread() {
> @Override
> public void run() {
> System.out.println("Waiting for a write lock...");
> lock.writeLock().lock();
> System.out.println("Write lock acquired!");
> lock.writeLock().unlock();
> }
> }.start();
> Thread.sleep(3000);
> // Another reader
> new Thread() {
> @Override
> public void run() {
> System.out.println("Trying to acquire a second read lock...");
> lock.readLock().lock();
> try {
> System.out.println("Second read lock acquired successfully!!");
> } finally {
> lock.readLock().unlock();
> }
> }
> }.start();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18639) Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
[
https://issues.apache.org/jira/browse/AMBARI-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xi Wang updated AMBARI-18639:
-
Attachment: AMBARI-18639-2.5.patch
> Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
> -
>
> Key: AMBARI-18639
> URL: https://issues.apache.org/jira/browse/AMBARI-18639
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.1, 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18639-2.5.patch, AMBARI-18639.patch
>
>
> Ambari UI does not allow to modify threshold of *'OK'* and *'WARNING'* in
> ResourceManager WEB UI alert.
> *Steps to reproduce:*
> 1. Remove threshold from WARNING/OK at alert of ResourceManager WEB UI
> 2. Save
> 3. Refresh Ambari UI and and the field is blank *- Expected*
> 4. Add any threshold string (may be the one that you removed) to WARNING/OK
> and then save
> 5. Refresh Ambari UI. _Here is the problem._ *It shows just blank.*
> 6. API /api/v1/clusters/young-hdp250/alert_definitions/44 shows blank too.
> - It's happening because the PUT call is sent empty.
> !RM Web UI- Alert Definitioni.jpg|thumbnail!
> {code}
> "critical" : {
> "text" : "Connection failed to {1} ({3})"
> },
> "ok" : {
> "text" : "HTTP {0} response in {2:.3f}s"
> },
> "warning" : {
> "text" : ""
> }
> {code}
> *Workaround:*
> Manual update using curl command works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18639) Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
[
https://issues.apache.org/jira/browse/AMBARI-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589691#comment-15589691
]
Xi Wang commented on AMBARI-18639:
--
Patches uploaded for 2.4.2 and 2.5
> Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
> -
>
> Key: AMBARI-18639
> URL: https://issues.apache.org/jira/browse/AMBARI-18639
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.1, 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18639-2.5.patch, AMBARI-18639.patch
>
>
> Ambari UI does not allow to modify threshold of *'OK'* and *'WARNING'* in
> ResourceManager WEB UI alert.
> *Steps to reproduce:*
> 1. Remove threshold from WARNING/OK at alert of ResourceManager WEB UI
> 2. Save
> 3. Refresh Ambari UI and and the field is blank *- Expected*
> 4. Add any threshold string (may be the one that you removed) to WARNING/OK
> and then save
> 5. Refresh Ambari UI. _Here is the problem._ *It shows just blank.*
> 6. API /api/v1/clusters/young-hdp250/alert_definitions/44 shows blank too.
> - It's happening because the PUT call is sent empty.
> !RM Web UI- Alert Definitioni.jpg|thumbnail!
> {code}
> "critical" : {
> "text" : "Connection failed to {1} ({3})"
> },
> "ok" : {
> "text" : "HTTP {0} response in {2:.3f}s"
> },
> "warning" : {
> "text" : ""
> }
> {code}
> *Workaround:*
> Manual update using curl command works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18639) Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
[
https://issues.apache.org/jira/browse/AMBARI-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xi Wang updated AMBARI-18639:
-
Attachment: AMBARI-18639.patch
> Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
> -
>
> Key: AMBARI-18639
> URL: https://issues.apache.org/jira/browse/AMBARI-18639
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.1, 2.5.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18639.patch
>
>
> Ambari UI does not allow to modify threshold of *'OK'* and *'WARNING'* in
> ResourceManager WEB UI alert.
> *Steps to reproduce:*
> 1. Remove threshold from WARNING/OK at alert of ResourceManager WEB UI
> 2. Save
> 3. Refresh Ambari UI and and the field is blank *- Expected*
> 4. Add any threshold string (may be the one that you removed) to WARNING/OK
> and then save
> 5. Refresh Ambari UI. _Here is the problem._ *It shows just blank.*
> 6. API /api/v1/clusters/young-hdp250/alert_definitions/44 shows blank too.
> - It's happening because the PUT call is sent empty.
> !RM Web UI- Alert Definitioni.jpg|thumbnail!
> {code}
> "critical" : {
> "text" : "Connection failed to {1} ({3})"
> },
> "ok" : {
> "text" : "HTTP {0} response in {2:.3f}s"
> },
> "warning" : {
> "text" : ""
> }
> {code}
> *Workaround:*
> Manual update using curl command works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18456) Refactor Unnecessary In-Memory Locks Around Business Objects
[ https://issues.apache.org/jira/browse/AMBARI-18456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589667#comment-15589667 ] Hudson commented on AMBARI-18456: - FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #173 (See [https://builds.apache.org/job/Ambari-branch-2.5/173/]) Merge branch 'branch-feature-AMBARI-18456' into trunk (jhurley: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=f64fa722024a8be76415efd5c8cec7fc7fe13c18]) * (edit) ambari-server/src/test/java/org/apache/ambari/server/orm/dao/ClusterVersionDAOTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/ConfigGroupTest.java * (edit) ambari-project/pom.xml * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/utilities/state/HDFSServiceCalculatedStateTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/orm/OrmTestHelper.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ConcurrentServiceConfigVersionTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterEffectiveVersionTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostComponentStateDAO.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/agent/HeartbeatTestHelper.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/alerts/InitialAlertEventTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterImplTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/actionmanager/ExecutionCommandWrapperTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/orm/dao/HostComponentStateDAOTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ClusterResourceProviderTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/StackDefinedPropertyProviderTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostComponentStateEntity.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/ConfigImpl.java * (edit) ambari-funtest/src/test/java/org/apache/ambari/funtest/server/utils/ClusterUtils.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/host/HostTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ClusterServiceEntity.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/agent/TestHeartbeatHandler.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/api/services/AmbariMetaInfoTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/orm/dao/ConfigGroupDAOTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/agent/TestHeartbeatMonitor.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/alerts/AlertEventPublisherTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/ConfigHelperTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/checks/InstallPackagesCheckTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/ServiceImpl.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/utilities/state/DefaultServiceCalculatedStateTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostDAO.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionDBAccessorImpl.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/orm/dao/SettingDAOTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/BackgroundCustomCommandExecutionTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/utils/StageUtilsTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/RefreshYarnCapacitySchedulerReleaseConfigTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/agent/AgentResourceTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/utilities/state/FlumeServiceCalculatedStateTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/events/listeners/alerts/AlertServiceStateListener.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/Host.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/configgroup/ConfigGroupImpl.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UpgradeSummaryResourceProviderTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/UpgradeActionTest.java * (edit)
[jira] [Commented] (AMBARI-18633) Mapreduce 'Config group' changes YARN Config Group overrides and vice versa.
[ https://issues.apache.org/jira/browse/AMBARI-18633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589658#comment-15589658 ] Andrii Babiichuk commented on AMBARI-18633: --- Committed to branch 2.2.2-maint > Mapreduce 'Config group' changes YARN Config Group overrides and vice versa. > > > Key: AMBARI-18633 > URL: https://issues.apache.org/jira/browse/AMBARI-18633 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk >Priority: Blocker > Attachments: AMBARI-18633_branch-2.2.2.patch > > > *STR:* > # Change a config (Memory allocated for all YARN containers on a node) from > non-default service group in YARN service and save. > # Navigate to MapReduce service and choose a non-default service group to > make config changes (Map Memory) and save > *Expected Result:* MapReduce config for non-default service group should get > successfully saved > *Actual Result:* Along wth the MapReduce config changes, non-default service > group of YARN that was previously tweaked gets reset to empty bag of > properties. > It is noticed that while saving configs of non-default group of MapReduce > service, two PUT API calls are made: one for MapReduce which is expected but > one more for YARN non-default service group with empty array for desired > configs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18636) Remove "hbase.rpc.controllerfactory.class" from hbase-site.xml
[ https://issues.apache.org/jira/browse/AMBARI-18636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Magyari updated AMBARI-18636: Attachment: AMBARI-18636.patch > Remove "hbase.rpc.controllerfactory.class" from hbase-site.xml > -- > > Key: AMBARI-18636 > URL: https://issues.apache.org/jira/browse/AMBARI-18636 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.0 >Reporter: Sandor Magyari >Assignee: Sandor Magyari >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18636.patch > > > Do not set "hbase.rpc.controllerfactory.class" property even if Phoenix is > deployed as it causes problem on a cluster with HBASE & Phoenix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18636) Remove "hbase.rpc.controllerfactory.class" from hbase-site.xml
[ https://issues.apache.org/jira/browse/AMBARI-18636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Magyari updated AMBARI-18636: Attachment: (was: AMBARI-18636.patch) > Remove "hbase.rpc.controllerfactory.class" from hbase-site.xml > -- > > Key: AMBARI-18636 > URL: https://issues.apache.org/jira/browse/AMBARI-18636 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.0 >Reporter: Sandor Magyari >Assignee: Sandor Magyari >Priority: Critical > Fix For: 2.5.0 > > > Do not set "hbase.rpc.controllerfactory.class" property even if Phoenix is > deployed as it causes problem on a cluster with HBASE & Phoenix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18640) Ambari upgrade failed while running 'Alter Table blueprint' - blueprint_name column
[
https://issues.apache.org/jira/browse/AMBARI-18640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaly Brodetskyi updated AMBARI-18640:
---
Status: Patch Available (was: Open)
> Ambari upgrade failed while running 'Alter Table blueprint' - blueprint_name
> column
> ---
>
> Key: AMBARI-18640
> URL: https://issues.apache.org/jira/browse/AMBARI-18640
> Project: Ambari
> Issue Type: Bug
> Components: ambari-upgrade
>Affects Versions: 2.4.2
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Blocker
> Fix For: 2.4.2
>
> Attachments: AMBARI-18640.patch
>
>
> Observed errors in today's run during Ambari upgrade from 2.2.1.1 to
> 2.4.2.0-36
> ambari-server --hash
> c6da6776f029f15d3a7d6009697371eee4e5f4c5
> Ambari DB - MySQL; Secure HDP-2.4.0.0 cluster deployed via UI
> *Upgrade Log indicates below:*
> {code}
> 18 Oct 2016 14:17:59,115 INFO [main] DBAccessorImpl:824 - Executing query:
> ALTER TABLE users MODIFY user_name VARCHAR(100)
> 18 Oct 2016 14:17:59,154 INFO [main] DBAccessorImpl:824 - Executing query:
> ALTER TABLE users MODIFY user_name VARCHAR(100) NOT NULL
> 18 Oct 2016 14:17:59,191 INFO [main] DBAccessorImpl:824 - Executing query:
> ALTER TABLE host_role_command MODIFY role VARCHAR(100)
> 18 Oct 2016 14:17:59,428 INFO [main] DBAccessorImpl:824 - Executing query:
> ALTER TABLE host_role_command MODIFY status VARCHAR(100)
> 18 Oct 2016 14:17:59,656 INFO [main] DBAccessorImpl:824 - Executing query:
> ALTER TABLE blueprint MODIFY blueprint_name VARCHAR(100)
> 18 Oct 2016 14:17:59,678 ERROR [main] DBAccessorImpl:830 - Error executing
> query: ALTER TABLE blueprint MODIFY blueprint_name VARCHAR(100)
> java.sql.SQLException: Cannot change column 'blueprint_name': used in a
> foreign key constraint 'FK_blueprint_setting_name' of table
> 'ambaricustom.blueprint_setting'
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:996)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3887)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3823)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2526)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2484)
> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:848)
> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:742)
> at
> org.apache.ambari.server.orm.DBAccessorImpl.executeQuery(DBAccessorImpl.java:827)
> at
> org.apache.ambari.server.orm.DBAccessorImpl.executeQuery(DBAccessorImpl.java:819)
> at
> org.apache.ambari.server.orm.DBAccessorImpl.alterColumn(DBAccessorImpl.java:610)
> at
> org.apache.ambari.server.upgrade.UpgradeCatalog242.updateTablesForMysql(UpgradeCatalog242.java:120)
> at
> org.apache.ambari.server.upgrade.UpgradeCatalog242.executeDDLUpdates(UpgradeCatalog242.java:95)
> at
> org.apache.ambari.server.upgrade.AbstractUpgradeCatalog.upgradeSchema(AbstractUpgradeCatalog.java:889)
> at
> org.apache.ambari.server.upgrade.SchemaUpgradeHelper.executeUpgrade(SchemaUpgradeHelper.java:206)
> at
> org.apache.ambari.server.upgrade.SchemaUpgradeHelper.main(SchemaUpgradeHelper.java:349)
> 18 Oct 2016 14:17:59,680 ERROR [main] SchemaUpgradeHelper:208 - Upgrade
> failed.
> java.sql.SQLException: Cannot change column 'blueprint_name': used in a
> foreign key constraint 'FK_blueprint_setting_name' of table
> 'ambaricustom.blueprint_setting'
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:996)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3887)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3823)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2526)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2484)
> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:848)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18640) Ambari upgrade failed while running 'Alter Table blueprint' - blueprint_name column
[
https://issues.apache.org/jira/browse/AMBARI-18640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaly Brodetskyi updated AMBARI-18640:
---
Attachment: AMBARI-18640.patch
> Ambari upgrade failed while running 'Alter Table blueprint' - blueprint_name
> column
> ---
>
> Key: AMBARI-18640
> URL: https://issues.apache.org/jira/browse/AMBARI-18640
> Project: Ambari
> Issue Type: Bug
> Components: ambari-upgrade
>Affects Versions: 2.4.2
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Blocker
> Fix For: 2.4.2
>
> Attachments: AMBARI-18640.patch
>
>
> Observed errors in today's run during Ambari upgrade from 2.2.1.1 to
> 2.4.2.0-36
> ambari-server --hash
> c6da6776f029f15d3a7d6009697371eee4e5f4c5
> Ambari DB - MySQL; Secure HDP-2.4.0.0 cluster deployed via UI
> *Upgrade Log indicates below:*
> {code}
> 18 Oct 2016 14:17:59,115 INFO [main] DBAccessorImpl:824 - Executing query:
> ALTER TABLE users MODIFY user_name VARCHAR(100)
> 18 Oct 2016 14:17:59,154 INFO [main] DBAccessorImpl:824 - Executing query:
> ALTER TABLE users MODIFY user_name VARCHAR(100) NOT NULL
> 18 Oct 2016 14:17:59,191 INFO [main] DBAccessorImpl:824 - Executing query:
> ALTER TABLE host_role_command MODIFY role VARCHAR(100)
> 18 Oct 2016 14:17:59,428 INFO [main] DBAccessorImpl:824 - Executing query:
> ALTER TABLE host_role_command MODIFY status VARCHAR(100)
> 18 Oct 2016 14:17:59,656 INFO [main] DBAccessorImpl:824 - Executing query:
> ALTER TABLE blueprint MODIFY blueprint_name VARCHAR(100)
> 18 Oct 2016 14:17:59,678 ERROR [main] DBAccessorImpl:830 - Error executing
> query: ALTER TABLE blueprint MODIFY blueprint_name VARCHAR(100)
> java.sql.SQLException: Cannot change column 'blueprint_name': used in a
> foreign key constraint 'FK_blueprint_setting_name' of table
> 'ambaricustom.blueprint_setting'
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:996)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3887)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3823)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2526)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2484)
> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:848)
> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:742)
> at
> org.apache.ambari.server.orm.DBAccessorImpl.executeQuery(DBAccessorImpl.java:827)
> at
> org.apache.ambari.server.orm.DBAccessorImpl.executeQuery(DBAccessorImpl.java:819)
> at
> org.apache.ambari.server.orm.DBAccessorImpl.alterColumn(DBAccessorImpl.java:610)
> at
> org.apache.ambari.server.upgrade.UpgradeCatalog242.updateTablesForMysql(UpgradeCatalog242.java:120)
> at
> org.apache.ambari.server.upgrade.UpgradeCatalog242.executeDDLUpdates(UpgradeCatalog242.java:95)
> at
> org.apache.ambari.server.upgrade.AbstractUpgradeCatalog.upgradeSchema(AbstractUpgradeCatalog.java:889)
> at
> org.apache.ambari.server.upgrade.SchemaUpgradeHelper.executeUpgrade(SchemaUpgradeHelper.java:206)
> at
> org.apache.ambari.server.upgrade.SchemaUpgradeHelper.main(SchemaUpgradeHelper.java:349)
> 18 Oct 2016 14:17:59,680 ERROR [main] SchemaUpgradeHelper:208 - Upgrade
> failed.
> java.sql.SQLException: Cannot change column 'blueprint_name': used in a
> foreign key constraint 'FK_blueprint_setting_name' of table
> 'ambaricustom.blueprint_setting'
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:996)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3887)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3823)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2526)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2484)
> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:848)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18637) Management pack purge option should warn user and ask for confirmation before purging
[
https://issues.apache.org/jira/browse/AMBARI-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589571#comment-15589571
]
Hadoop QA commented on AMBARI-18637:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834204/AMBARI-18637.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
ambari-server:
org.apache.ambari.server.agent.TestHeartbeatHandler
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8922//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8922//console
This message is automatically generated.
> Management pack purge option should warn user and ask for confirmation before
> purging
> -
>
> Key: AMBARI-18637
> URL: https://issues.apache.org/jira/browse/AMBARI-18637
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.4.2
>
> Attachments: AMBARI-18637.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18640) Ambari upgrade failed while running 'Alter Table blueprint' - blueprint_name column
Vitaly Brodetskyi created AMBARI-18640:
--
Summary: Ambari upgrade failed while running 'Alter Table
blueprint' - blueprint_name column
Key: AMBARI-18640
URL: https://issues.apache.org/jira/browse/AMBARI-18640
Project: Ambari
Issue Type: Bug
Components: ambari-upgrade
Affects Versions: 2.4.2
Reporter: Vitaly Brodetskyi
Assignee: Vitaly Brodetskyi
Priority: Blocker
Fix For: 2.4.2
Observed errors in today's run during Ambari upgrade from 2.2.1.1 to 2.4.2.0-36
ambari-server --hash
c6da6776f029f15d3a7d6009697371eee4e5f4c5
Ambari DB - MySQL; Secure HDP-2.4.0.0 cluster deployed via UI
*Upgrade Log indicates below:*
{code}
18 Oct 2016 14:17:59,115 INFO [main] DBAccessorImpl:824 - Executing query:
ALTER TABLE users MODIFY user_name VARCHAR(100)
18 Oct 2016 14:17:59,154 INFO [main] DBAccessorImpl:824 - Executing query:
ALTER TABLE users MODIFY user_name VARCHAR(100) NOT NULL
18 Oct 2016 14:17:59,191 INFO [main] DBAccessorImpl:824 - Executing query:
ALTER TABLE host_role_command MODIFY role VARCHAR(100)
18 Oct 2016 14:17:59,428 INFO [main] DBAccessorImpl:824 - Executing query:
ALTER TABLE host_role_command MODIFY status VARCHAR(100)
18 Oct 2016 14:17:59,656 INFO [main] DBAccessorImpl:824 - Executing query:
ALTER TABLE blueprint MODIFY blueprint_name VARCHAR(100)
18 Oct 2016 14:17:59,678 ERROR [main] DBAccessorImpl:830 - Error executing
query: ALTER TABLE blueprint MODIFY blueprint_name VARCHAR(100)
java.sql.SQLException: Cannot change column 'blueprint_name': used in a foreign
key constraint 'FK_blueprint_setting_name' of table
'ambaricustom.blueprint_setting'
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:996)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3887)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3823)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2526)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2484)
at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:848)
at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:742)
at
org.apache.ambari.server.orm.DBAccessorImpl.executeQuery(DBAccessorImpl.java:827)
at
org.apache.ambari.server.orm.DBAccessorImpl.executeQuery(DBAccessorImpl.java:819)
at
org.apache.ambari.server.orm.DBAccessorImpl.alterColumn(DBAccessorImpl.java:610)
at
org.apache.ambari.server.upgrade.UpgradeCatalog242.updateTablesForMysql(UpgradeCatalog242.java:120)
at
org.apache.ambari.server.upgrade.UpgradeCatalog242.executeDDLUpdates(UpgradeCatalog242.java:95)
at
org.apache.ambari.server.upgrade.AbstractUpgradeCatalog.upgradeSchema(AbstractUpgradeCatalog.java:889)
at
org.apache.ambari.server.upgrade.SchemaUpgradeHelper.executeUpgrade(SchemaUpgradeHelper.java:206)
at
org.apache.ambari.server.upgrade.SchemaUpgradeHelper.main(SchemaUpgradeHelper.java:349)
18 Oct 2016 14:17:59,680 ERROR [main] SchemaUpgradeHelper:208 - Upgrade failed.
java.sql.SQLException: Cannot change column 'blueprint_name': used in a foreign
key constraint 'FK_blueprint_setting_name' of table
'ambaricustom.blueprint_setting'
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:996)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3887)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3823)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2526)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2484)
at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:848)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18619) Optimize Service Checks to it picks a random host and prefers hosts with 0 active commands
[ https://issues.apache.org/jira/browse/AMBARI-18619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589512#comment-15589512 ] Hudson commented on AMBARI-18619: - FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #172 (See [https://builds.apache.org/job/Ambari-branch-2.5/172/]) AMBARI-18619. Optimize Service Checks to it picks a random host and (afernandez: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=68d4da47b84301b4688fce5eef1360a779f1849a]) * (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelperTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UserAuthorizationResourceProviderTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ActiveWidgetLayoutResourceProviderTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementController.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandDAO.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UserResourceProviderTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java > Optimize Service Checks to it picks a random host and prefers hosts with 0 > active commands > -- > > Key: AMBARI-18619 > URL: https://issues.apache.org/jira/browse/AMBARI-18619 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18619.branch-2.5.patch, AMBARI-18619.trunk.patch > > > STR: > * Deploy a 3-node cluster with Ambari 2.4 and HDP 2.5 with clients on every > host. > * Run multiple service checks in parallel, but notice that they typically run > on the same 1 or 2 hosts. > Currently, Ambari relies on getting the list of candidate hosts from the DB > and excludes all hosts that are in maintenance mode. From that list, it picks > the first host that is healthy (i.e., heartbeating). This means that the > logic does not pick a random host. > Instead, Ambari should always pick a random host and prefer to schedule on > hosts that have 0 in-progress commands. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18619) Optimize Service Checks to it picks a random host and prefers hosts with 0 active commands
[ https://issues.apache.org/jira/browse/AMBARI-18619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589467#comment-15589467 ] Hudson commented on AMBARI-18619: - FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5828 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5828/]) AMBARI-18619. Optimize Service Checks to it picks a random host and (afernandez: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=365a5d638fb7edcd4ff5561b29f0efb66fa5b881]) * (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandDAO.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UserResourceProviderTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelperTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ActiveWidgetLayoutResourceProviderTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementController.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UserAuthorizationResourceProviderTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java > Optimize Service Checks to it picks a random host and prefers hosts with 0 > active commands > -- > > Key: AMBARI-18619 > URL: https://issues.apache.org/jira/browse/AMBARI-18619 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18619.branch-2.5.patch, AMBARI-18619.trunk.patch > > > STR: > * Deploy a 3-node cluster with Ambari 2.4 and HDP 2.5 with clients on every > host. > * Run multiple service checks in parallel, but notice that they typically run > on the same 1 or 2 hosts. > Currently, Ambari relies on getting the list of candidate hosts from the DB > and excludes all hosts that are in maintenance mode. From that list, it picks > the first host that is healthy (i.e., heartbeating). This means that the > logic does not pick a random host. > Instead, Ambari should always pick a random host and prefer to schedule on > hosts that have 0 in-progress commands. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18639) Ambari UI does not allow to modify EMPTY threshold text of 'OK' and 'WARNING'
Xi Wang created AMBARI-18639:
Summary: Ambari UI does not allow to modify EMPTY threshold text
of 'OK' and 'WARNING'
Key: AMBARI-18639
URL: https://issues.apache.org/jira/browse/AMBARI-18639
Project: Ambari
Issue Type: Bug
Components: ambari-web
Affects Versions: 2.4.1, 2.5.0
Reporter: Xi Wang
Assignee: Xi Wang
Priority: Critical
Fix For: 2.5.0, 2.4.2
Ambari UI does not allow to modify threshold of *'OK'* and *'WARNING'* in
ResourceManager WEB UI alert.
*Steps to reproduce:*
1. Remove threshold from WARNING/OK at alert of ResourceManager WEB UI
2. Save
3. Refresh Ambari UI and and the field is blank *- Expected*
4. Add any threshold string (may be the one that you removed) to WARNING/OK and
then save
5. Refresh Ambari UI. _Here is the problem._ *It shows just blank.*
6. API /api/v1/clusters/young-hdp250/alert_definitions/44 shows blank too.
- It's happening because the PUT call is sent empty.
!RM Web UI- Alert Definitioni.jpg|thumbnail!
{code}
"critical" : {
"text" : "Connection failed to {1} ({3})"
},
"ok" : {
"text" : "HTTP {0} response in {2:.3f}s"
},
"warning" : {
"text" : ""
}
{code}
*Workaround:*
Manual update using curl command works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18619) Optimize Service Checks to it picks a random host and prefers hosts with 0 active commands
[ https://issues.apache.org/jira/browse/AMBARI-18619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-18619: - Resolution: Fixed Status: Resolved (was: Patch Available) Pushed to trunk, commit 365a5d638fb7edcd4ff5561b29f0efb66fa5b881 branch-2.5, commit 68d4da47b84301b4688fce5eef1360a779f1849a > Optimize Service Checks to it picks a random host and prefers hosts with 0 > active commands > -- > > Key: AMBARI-18619 > URL: https://issues.apache.org/jira/browse/AMBARI-18619 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18619.branch-2.5.patch, AMBARI-18619.trunk.patch > > > STR: > * Deploy a 3-node cluster with Ambari 2.4 and HDP 2.5 with clients on every > host. > * Run multiple service checks in parallel, but notice that they typically run > on the same 1 or 2 hosts. > Currently, Ambari relies on getting the list of candidate hosts from the DB > and excludes all hosts that are in maintenance mode. From that list, it picks > the first host that is healthy (i.e., heartbeating). This means that the > logic does not pick a random host. > Instead, Ambari should always pick a random host and prefer to schedule on > hosts that have 0 in-progress commands. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18619) Optimize Service Checks to it picks a random host and prefers hosts with 0 active commands
[ https://issues.apache.org/jira/browse/AMBARI-18619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-18619: - Attachment: (was: AMBARI-18619.trunk.patch) > Optimize Service Checks to it picks a random host and prefers hosts with 0 > active commands > -- > > Key: AMBARI-18619 > URL: https://issues.apache.org/jira/browse/AMBARI-18619 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18619.branch-2.5.patch, AMBARI-18619.trunk.patch > > > STR: > * Deploy a 3-node cluster with Ambari 2.4 and HDP 2.5 with clients on every > host. > * Run multiple service checks in parallel, but notice that they typically run > on the same 1 or 2 hosts. > Currently, Ambari relies on getting the list of candidate hosts from the DB > and excludes all hosts that are in maintenance mode. From that list, it picks > the first host that is healthy (i.e., heartbeating). This means that the > logic does not pick a random host. > Instead, Ambari should always pick a random host and prefer to schedule on > hosts that have 0 in-progress commands. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18619) Optimize Service Checks to it picks a random host and prefers hosts with 0 active commands
[ https://issues.apache.org/jira/browse/AMBARI-18619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-18619: - Attachment: AMBARI-18619.branch-2.5.patch AMBARI-18619.trunk.patch > Optimize Service Checks to it picks a random host and prefers hosts with 0 > active commands > -- > > Key: AMBARI-18619 > URL: https://issues.apache.org/jira/browse/AMBARI-18619 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18619.branch-2.5.patch, AMBARI-18619.trunk.patch > > > STR: > * Deploy a 3-node cluster with Ambari 2.4 and HDP 2.5 with clients on every > host. > * Run multiple service checks in parallel, but notice that they typically run > on the same 1 or 2 hosts. > Currently, Ambari relies on getting the list of candidate hosts from the DB > and excludes all hosts that are in maintenance mode. From that list, it picks > the first host that is healthy (i.e., heartbeating). This means that the > logic does not pick a random host. > Instead, Ambari should always pick a random host and prefer to schedule on > hosts that have 0 in-progress commands. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18619) Optimize Service Checks to it picks a random host and prefers hosts with 0 active commands
[ https://issues.apache.org/jira/browse/AMBARI-18619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-18619: - Attachment: (was: AMBARI-18619.branch-2.5.patch) > Optimize Service Checks to it picks a random host and prefers hosts with 0 > active commands > -- > > Key: AMBARI-18619 > URL: https://issues.apache.org/jira/browse/AMBARI-18619 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18619.branch-2.5.patch, AMBARI-18619.trunk.patch > > > STR: > * Deploy a 3-node cluster with Ambari 2.4 and HDP 2.5 with clients on every > host. > * Run multiple service checks in parallel, but notice that they typically run > on the same 1 or 2 hosts. > Currently, Ambari relies on getting the list of candidate hosts from the DB > and excludes all hosts that are in maintenance mode. From that list, it picks > the first host that is healthy (i.e., heartbeating). This means that the > logic does not pick a random host. > Instead, Ambari should always pick a random host and prefer to schedule on > hosts that have 0 in-progress commands. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18619) Optimize Service Checks to it picks a random host and prefers hosts with 0 active commands
[ https://issues.apache.org/jira/browse/AMBARI-18619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-18619: - Attachment: AMBARI-18619.branch-2.5.patch AMBARI-18619.trunk.patch > Optimize Service Checks to it picks a random host and prefers hosts with 0 > active commands > -- > > Key: AMBARI-18619 > URL: https://issues.apache.org/jira/browse/AMBARI-18619 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18619.branch-2.5.patch, AMBARI-18619.trunk.patch > > > STR: > * Deploy a 3-node cluster with Ambari 2.4 and HDP 2.5 with clients on every > host. > * Run multiple service checks in parallel, but notice that they typically run > on the same 1 or 2 hosts. > Currently, Ambari relies on getting the list of candidate hosts from the DB > and excludes all hosts that are in maintenance mode. From that list, it picks > the first host that is healthy (i.e., heartbeating). This means that the > logic does not pick a random host. > Instead, Ambari should always pick a random host and prefer to schedule on > hosts that have 0 in-progress commands. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18619) Optimize Service Checks to it picks a random host and prefers hosts with 0 active commands
[ https://issues.apache.org/jira/browse/AMBARI-18619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-18619: - Attachment: (was: AMBARI-18619.branch-2.5.patch) > Optimize Service Checks to it picks a random host and prefers hosts with 0 > active commands > -- > > Key: AMBARI-18619 > URL: https://issues.apache.org/jira/browse/AMBARI-18619 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18619.branch-2.5.patch, AMBARI-18619.trunk.patch > > > STR: > * Deploy a 3-node cluster with Ambari 2.4 and HDP 2.5 with clients on every > host. > * Run multiple service checks in parallel, but notice that they typically run > on the same 1 or 2 hosts. > Currently, Ambari relies on getting the list of candidate hosts from the DB > and excludes all hosts that are in maintenance mode. From that list, it picks > the first host that is healthy (i.e., heartbeating). This means that the > logic does not pick a random host. > Instead, Ambari should always pick a random host and prefer to schedule on > hosts that have 0 in-progress commands. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18456) Refactor Unnecessary In-Memory Locks Around Business Objects
[
https://issues.apache.org/jira/browse/AMBARI-18456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589324#comment-15589324
]
Hudson commented on AMBARI-18456:
-
FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5827 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5827/])
Merge branch 'branch-feature-AMBARI-18456' into trunk (jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=b236ef4d7bdfb4dbc388eb9cdc87af846f9bc89e])
* (edit)
ambari-funtest/src/test/java/org/apache/ambari/funtest/server/utils/ClusterUtils.java
> Refactor Unnecessary In-Memory Locks Around Business Objects
>
>
> Key: AMBARI-18456
> URL: https://issues.apache.org/jira/browse/AMBARI-18456
> Project: Ambari
> Issue Type: Epic
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
> Labels: branch-feature-AMBARI-18456
> Fix For: 2.5.0
>
>
> The top 4 business objects in Ambari:
> - ClusterImpl
> - ServiceImpl
> - ServiceComponentImpl
> - ServiceComponentHostImpl
> All use {{ReadWriteLock}} implementations to prevent dirty reads and
> concurrent writes. However, {{ClusterImpl}} exposes a "global"
> {{ReadWriteLock}} which the other business objects share. This causes
> tremendous problems with deadlocks, especially on slow databases.
> Consider the case where you have 3 threads:
> # thread-1 acquires {{ClusterReadLock}}
> # thread-2 acquires {{ServiceComponenWriteLock}}
> # thread-3 tries to get {{ClusterWriteLock}} and is blocked by {{thread-1}}
> # thread-2 tries to get {{ClusterReadLock}} and is blocked by {{thread-3}}
> # thread-1 tries to get {{ServiceComponentReadLock}} and is blocked by
> {{thread-2}}
> Essentially, the exposure of the "cluster global lock" causes problems since
> multiple threads can acquire other internal locks and be blocked waiting on
> the global lock.
> In general, I don't believe that the read locks help at all. Ambari usually
> encounters these locks while try to display web page information. Once
> displayed, the locks are removed and the information is already stale if
> there were write threads waiting.
> These locks should be investigated and, for the most part, except in some
> cases involving concurrent writes, removed.
> Part of the problem revolves around our assumption about how the
> ReadWriteLock works. The issue in the above scenario is that the
> clusterWriteLock request is pending. This actually blocks all subsequent
> readers even though the lock is not fair.
> FYI, this code shows that a reader, in unfair mode, will wait when there is a
> waiting writer:
> {noformat:title=Output}
> Waiting for a read lock...
> Read lock acquired!
> Waiting for a write lock...
> Trying to acquire a second read lock...
> {noformat}
> {code}
> import java.util.concurrent.locks.ReentrantReadWriteLock;
> public class Test {
> private static ReentrantReadWriteLock lock = new
> ReentrantReadWriteLock(false);
> public static void main(String[] args) throws InterruptedException {
> // A reader which takes too long to finish
> new Thread() {
> @Override
> public void run() {
> System.out.println("Waiting for a read lock...");
> lock.readLock().lock();
> System.out.println("Read lock acquired!");
> try {
> try {
> Thread.sleep(1000 * 60 * 60);
> } catch (InterruptedException e) {
> }
> } finally {
> lock.readLock().unlock();
> }
> }
> }.start();
> Thread.sleep(3000);
> // A writer which will be waiting
> new Thread() {
> @Override
> public void run() {
> System.out.println("Waiting for a write lock...");
> lock.writeLock().lock();
> System.out.println("Write lock acquired!");
> lock.writeLock().unlock();
> }
> }.start();
> Thread.sleep(3000);
> // Another reader
> new Thread() {
> @Override
> public void run() {
> System.out.println("Trying to acquire a second read lock...");
> lock.readLock().lock();
> try {
> System.out.println("Second read lock acquired successfully!!");
> } finally {
> lock.readLock().unlock();
> }
> }
> }.start();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18627) Add service wizard hung at Choose services page as no ClusterStackVersion is available with state=CURRENT
[ https://issues.apache.org/jira/browse/AMBARI-18627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589315#comment-15589315 ] Hudson commented on AMBARI-18627: - SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #171 (See [https://builds.apache.org/job/Ambari-branch-2.5/171/]) AMBARI-18627. Add service wizard hung at Choose services page as no (hiveww: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=17069e8a1c9c385503bb9510aed9882fbbb95a72]) * (edit) ambari-web/test/controllers/global/cluster_controller_test.js * (edit) ambari-web/app/controllers/global/cluster_controller.js * (edit) ambari-web/app/controllers/main/admin/stack_and_upgrade_controller.js * (edit) ambari-web/app/controllers/wizard.js * (edit) ambari-web/app/utils/ajax/ajax.js * (edit) ambari-web/test/controllers/main/admin/stack_and_upgrade_controller_test.js > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT > - > > Key: AMBARI-18627 > URL: https://issues.apache.org/jira/browse/AMBARI-18627 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander > Fix For: 2.5.0 > > Attachments: AMBARI-18627.patch, AMBARI-18627.patch > > > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18637) Management pack purge option should warn user and ask for confirmation before purging
[ https://issues.apache.org/jira/browse/AMBARI-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-18637: --- Attachment: AMBARI-18637.patch > Management pack purge option should warn user and ask for confirmation before > purging > - > > Key: AMBARI-18637 > URL: https://issues.apache.org/jira/browse/AMBARI-18637 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya > Fix For: 2.4.2 > > Attachments: AMBARI-18637.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18637) Management pack purge option should warn user and ask for confirmation before purging
[ https://issues.apache.org/jira/browse/AMBARI-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-18637: --- Status: Patch Available (was: In Progress) > Management pack purge option should warn user and ask for confirmation before > purging > - > > Key: AMBARI-18637 > URL: https://issues.apache.org/jira/browse/AMBARI-18637 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya > Fix For: 2.4.2 > > Attachments: AMBARI-18637.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18637) Management pack purge option should warn user and ask for confirmation before purging
[ https://issues.apache.org/jira/browse/AMBARI-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-18637: --- Attachment: (was: AMBARI-18637.patch) > Management pack purge option should warn user and ask for confirmation before > purging > - > > Key: AMBARI-18637 > URL: https://issues.apache.org/jira/browse/AMBARI-18637 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya > Fix For: 2.4.2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18638) Include an option to upload query in hive-view
Anita Gnanamalar Jebaraj created AMBARI-18638: - Summary: Include an option to upload query in hive-view Key: AMBARI-18638 URL: https://issues.apache.org/jira/browse/AMBARI-18638 Project: Ambari Issue Type: Improvement Components: ambari-views Affects Versions: trunk Reporter: Anita Gnanamalar Jebaraj Assignee: Anita Gnanamalar Jebaraj Priority: Minor Fix For: trunk An option to upload the hive query into the worksheet from the UI can be included. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18637) Management pack purge option should warn user and ask for confirmation before purging
[ https://issues.apache.org/jira/browse/AMBARI-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-18637: --- Attachment: AMBARI-18637.patch > Management pack purge option should warn user and ask for confirmation before > purging > - > > Key: AMBARI-18637 > URL: https://issues.apache.org/jira/browse/AMBARI-18637 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya > Fix For: 2.4.2 > > Attachments: AMBARI-18637.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18637) Management pack purge option should warn user and ask for confirmation before purging
Jayush Luniya created AMBARI-18637: -- Summary: Management pack purge option should warn user and ask for confirmation before purging Key: AMBARI-18637 URL: https://issues.apache.org/jira/browse/AMBARI-18637 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.4.0 Reporter: Jayush Luniya Assignee: Jayush Luniya Fix For: 2.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18495) Remove Unnecessary Locks Inside Of Cluster Business Object Implementations
[
https://issues.apache.org/jira/browse/AMBARI-18495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589232#comment-15589232
]
Hudson commented on AMBARI-18495:
-
FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5826 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5826/])
AMBARI-18495 - Remove Unnecessary Locks Inside Of Cluster Business (jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=d53c9e2ee99c046ae5b37b531419549397f4aea1])
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/orm/dao/SettingDAOTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/utils/RetryHelper.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterTest.java
* (edit) ambari-project/pom.xml
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/Clusters.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/orm/OrmTestHelper.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/utils/StageUtilsTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/orm/dao/RepositoryVersionDAOTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/agent/HeartbeatTestHelper.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/configuration/RecoveryConfigHelperTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterDeadlockTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/ConfigHelperTest.java
* (edit) ambari-server/src/main/java/org/apache/ambari/server/state/Cluster.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/orm/dao/ClusterVersionDAOTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/orm/dao/WidgetLayoutDAOTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/agent/AgentResourceTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClustersImpl.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/ConfigGroupTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/agent/TestHeartbeatHandler.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterEffectiveVersionTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/agent/HeartbeatProcessorTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/orm/dao/ConfigGroupDAOTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/api/services/ClusterServiceTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ClusterResourceProviderTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/orm/dao/WidgetDAOTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/RequestExecutionTest.java
> Remove Unnecessary Locks Inside Of Cluster Business Object Implementations
> --
>
> Key: AMBARI-18495
> URL: https://issues.apache.org/jira/browse/AMBARI-18495
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18495.patch
>
>
> Many of the business object implementations include needless locks which
> simply add the overhead and contention in larger clusters. Some examples of
> these are :
> - HostImpl
> -- get/set DisksInfo()
> -- get/set TotalMemBytes()
> - ServiceComponentHostImpl
> -- get/set MaintenanceState()
> -- get/set LastOpLastUpdateTime()
> These types of methods are found on other business classes as well, like
> {{ClusterImpl}} and {{ServiceImpl}}. Additionally, methods like
> {{convertToResponse()}} and {{debugDump()}} need not acquire locks since they
> are used mostly for serialization of data to the web client where the data
> will then immediately become stale anyway.
> The {{Clusters}} and {{Cluster}} business objects should have the following
> work performed:
> - Remove locking around areas where its no longer required
> - Replace collections with thread-safe concurrent versions
> - Remove some reliance on state-full business objects (caches)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18614) Remove Unnecessary Locks Inside Of SCH Business Object Implementations
[
https://issues.apache.org/jira/browse/AMBARI-18614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589229#comment-15589229
]
Hudson commented on AMBARI-18614:
-
FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5826 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5826/])
AMBARI-18614 - Remove Unnecessary Locks Inside Of SCH Business Object (jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=2c6008293a664ab3b0f24a3f22be54fe0e5f1faf])
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/ComponentVersionCheckActionTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/agent/TestHeartbeatHandler.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/HostConfig.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ServiceComponentHostConcurrentWriteDeadlockTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClustersTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterDeadlockTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/agent/TestHeartbeatMonitor.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/agent/HeartbeatProcessorTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/orm/OrmTestHelper.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/ServiceComponentTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClustersDeadlockTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ConcurrentServiceConfigVersionTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/events/EventsTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/ServiceComponentHost.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterImplTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/configuration/RecoveryConfigHelperTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/UpgradeActionTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterTest.java
> Remove Unnecessary Locks Inside Of SCH Business Object Implementations
> --
>
> Key: AMBARI-18614
> URL: https://issues.apache.org/jira/browse/AMBARI-18614
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18614.patch
>
>
> Many of the business object implementations include needless locks which
> simply add the overhead and contention in larger clusters. Some examples of
> these are :
> - HostImpl
> -- get/set DisksInfo()
> -- get/set TotalMemBytes()
> - ServiceComponentHostImpl
> -- get/set MaintenanceState()
> -- get/set LastOpLastUpdateTime()
> These types of methods are found on other business classes as well, like
> {{ClusterImpl}} and {{ServiceImpl}}. Additionally, methods like
> {{convertToResponse()}} and {{debugDump()}} need not acquire locks since they
> are used mostly for serialization of data to the web client where the data
> will then immediately become stale anyway.
> The {{ServiceComponentHost}} business object should have the following work
> performed:
> - Remove locking around areas where its no longer required
> - Replace collections with thread-safe concurrent versions
> - Remove some reliance on state-full business objects (caches)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18539) Remove Unnecessary Locks Inside Of Host Business Object Implementations
[ https://issues.apache.org/jira/browse/AMBARI-18539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589231#comment-15589231 ] Hudson commented on AMBARI-18539: - FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5826 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5826/]) AMBARI-18539 - Remove Unnecessary Locks Inside Of Host Business Object (jhurley: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=38700445bd793d27a8747d4c1d06b70f531ab677]) * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/ServiceTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/ConfigGroupTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UpgradeSummaryResourceProviderTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionManager.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterImplTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/ConfigureActionTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/topology/TopologyManager.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/ServiceComponentTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ServiceComponentHostConcurrentWriteDeadlockTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/agent/HeartbeatProcessorTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/utilities/state/DefaultServiceCalculatedStateTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/checks/InstallPackagesCheckTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/RefreshYarnCapacitySchedulerReleaseConfigTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/UpgradeHelperTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UpgradeResourceProviderTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/utilities/state/FlumeServiceCalculatedStateTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/utilities/state/YarnServiceCalculatedStateTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/host/HostImpl.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/events/EventsTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/utilities/state/HBaseServiceCalculatedStateTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelperTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClustersImpl.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/events/listeners/upgrade/HostVersionOutOfSyncListenerTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/host/HostImplTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/utilities/state/HiveServiceCalculatedStateTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/dao/ConfigGroupHostMappingDAO.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/JMXHostProviderTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/UpgradeActionTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/BackgroundCustomCommandExecutionTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/host/HostTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/agent/TestHeartbeatMonitor.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/utilities/state/HDFSServiceCalculatedStateTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UpgradeResourceProviderHDP22Test.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClustersTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/host/HostFactory.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/actionmanager/ExecutionCommandWrapperTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/ConfigHelperTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ConcurrentServiceConfigVersionTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterDeadlockTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/StackDefinedPropertyProviderTest.java * (edit)
[jira] [Commented] (AMBARI-18556) Remove Unnecessary Locks Inside Of Service Business Object Implementations
[ https://issues.apache.org/jira/browse/AMBARI-18556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589230#comment-15589230 ] Hudson commented on AMBARI-18556: - FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5826 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5826/]) AMBARI-18556 - Remove Unnecessary Locks Inside Of Service Business (jhurley: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=0de69e10b30a1dadf6f508170548cd347095193a]) * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/Host.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClustersImpl.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClustersDeadlockTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClustersTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostComponentStateDAO.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostComponentStateEntity.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostDAO.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/ServiceImpl.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterImplTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/PreUpgradeCheckResourceProviderTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/orm/dao/HostComponentDesiredStateDAOTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/agent/HeartbeatProcessorTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/agent/TestHeartbeatHandler.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/alerts/AlertEventPublisherTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/configuration/RecoveryConfigHelperTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/alerts/InitialAlertEventTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/UpgradeActionTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/ComponentVersionCheckActionTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ServiceComponentHostConcurrentWriteDeadlockTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/api/services/BaseRequest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/ServiceComponentTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/api/services/AmbariMetaInfoTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/utilities/state/GeneralServiceCalculatedStateTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostComponentDesiredStateDAO.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterDeadlockTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ClusterServiceEntity.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UpgradeSummaryResourceProviderTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/ServiceTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostComponentDesiredStateEntity.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/utils/RetryHelper.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/agent/TestHeartbeatMonitor.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ConcurrentServiceConfigVersionTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/Service.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/orm/dao/HostComponentStateDAOTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ServiceResourceProvider.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ServiceResourceProviderTest.java * (edit) ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UpgradeResourceProviderTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementController.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/host/HostImpl.java * (edit)
[jira] [Commented] (AMBARI-18475) Remove Global Cluster Lock Shared Between Business Objects
[
https://issues.apache.org/jira/browse/AMBARI-18475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589228#comment-15589228
]
Hudson commented on AMBARI-18475:
-
FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5826 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5826/])
AMBARI-18475 - Remove Global Cluster Lock Shared Between Business (jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=561c6f2f38f9b262dda4acd7ff0526b7caf55bce])
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/ServiceComponent.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
* (edit) ambari-server/src/main/java/org/apache/ambari/server/state/Cluster.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/ConfigImpl.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/update/HostUpdateHelperTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/ServiceImpl.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/events/listeners/alerts/AlertServiceStateListener.java
* (edit) ambari-server/src/main/java/org/apache/ambari/server/state/Service.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/configgroup/ConfigGroupImpl.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/annotations/ExperimentalFeature.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/ServiceComponentImpl.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java
> Remove Global Cluster Lock Shared Between Business Objects
> --
>
> Key: AMBARI-18475
> URL: https://issues.apache.org/jira/browse/AMBARI-18475
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.5.0
>
>
> Remove shared instances of the shared {{ReadWriteLock}} found in
> {{ClusterImpl}}. For now, the lock can remain private and full encapsulated
> inside of {{ClusterImpl}}, but it's use and reference across the rest of
> Ambari should be removed.
> This is part of the effort to refactor/remove the (mostly) unnecessary locks
> in memory. The shared instance of this lock is the number one reason that
> Ambari "deadlocks" when under load.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18456) Refactor Unnecessary In-Memory Locks Around Business Objects
[
https://issues.apache.org/jira/browse/AMBARI-18456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589226#comment-15589226
]
Hudson commented on AMBARI-18456:
-
FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5826 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5826/])
AMBARI-18456 - Refactor Unnecessary In-Memory Locks Around Business (jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=d6a847154e80158a0be0a26ee7dfc0d6dccac686])
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/ServiceComponent.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/events/EventsTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClustersImpl.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/ServiceImpl.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/orm/OrmTestHelper.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ConcurrentServiceConfigVersionTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClustersDeadlockTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/agent/TestHeartbeatMonitor.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClustersTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/agent/TestHeartbeatHandler.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/UpgradeActionTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/ComponentVersionCheckActionTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterImplTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/ServiceComponentImpl.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ServiceComponentHostConcurrentWriteDeadlockTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/configuration/RecoveryConfigHelperTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterDeadlockTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/ServiceComponentTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/annotations/ExperimentalFeature.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/host/HostImpl.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ComponentResourceProvider.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/agent/HeartbeatProcessorTest.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/state/ServiceTest.java
> Refactor Unnecessary In-Memory Locks Around Business Objects
>
>
> Key: AMBARI-18456
> URL: https://issues.apache.org/jira/browse/AMBARI-18456
> Project: Ambari
> Issue Type: Epic
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
> Labels: branch-feature-AMBARI-18456
> Fix For: 2.5.0
>
>
> The top 4 business objects in Ambari:
> - ClusterImpl
> - ServiceImpl
> - ServiceComponentImpl
> - ServiceComponentHostImpl
> All use {{ReadWriteLock}} implementations to prevent dirty reads and
> concurrent writes. However, {{ClusterImpl}} exposes a "global"
> {{ReadWriteLock}} which the other business objects share. This causes
> tremendous problems with deadlocks, especially on slow databases.
> Consider the case where you have 3 threads:
> # thread-1 acquires {{ClusterReadLock}}
> # thread-2 acquires {{ServiceComponenWriteLock}}
> # thread-3 tries to get {{ClusterWriteLock}} and is blocked by {{thread-1}}
> # thread-2 tries to get {{ClusterReadLock}} and is blocked by {{thread-3}}
> # thread-1 tries to get {{ServiceComponentReadLock}} and is blocked by
> {{thread-2}}
> Essentially, the exposure of the "cluster global lock" causes problems since
> multiple threads can acquire other internal locks and be blocked waiting on
> the global lock.
> In general, I don't believe that the read locks help at all. Ambari usually
> encounters these locks while try to display web page information. Once
>
[jira] [Updated] (AMBARI-18636) Remove "hbase.rpc.controllerfactory.class" from hbase-site.xml
[ https://issues.apache.org/jira/browse/AMBARI-18636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Magyari updated AMBARI-18636: Status: Patch Available (was: Open) > Remove "hbase.rpc.controllerfactory.class" from hbase-site.xml > -- > > Key: AMBARI-18636 > URL: https://issues.apache.org/jira/browse/AMBARI-18636 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.0 >Reporter: Sandor Magyari >Assignee: Sandor Magyari >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18636.patch > > > Do not set "hbase.rpc.controllerfactory.class" property even if Phoenix is > deployed as it causes problem on a cluster with HBASE & Phoenix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18636) Remove "hbase.rpc.controllerfactory.class" from hbase-site.xml
[ https://issues.apache.org/jira/browse/AMBARI-18636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Magyari updated AMBARI-18636: Attachment: AMBARI-18636.patch > Remove "hbase.rpc.controllerfactory.class" from hbase-site.xml > -- > > Key: AMBARI-18636 > URL: https://issues.apache.org/jira/browse/AMBARI-18636 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.0 >Reporter: Sandor Magyari >Assignee: Sandor Magyari >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18636.patch > > > Do not set "hbase.rpc.controllerfactory.class" property even if Phoenix is > deployed as it causes problem on a cluster with HBASE & Phoenix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-18627) Add service wizard hung at Choose services page as no ClusterStackVersion is available with state=CURRENT
[ https://issues.apache.org/jira/browse/AMBARI-18627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander resolved AMBARI-18627. -- Resolution: Fixed additional patch committed to 2.5 and trunk > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT > - > > Key: AMBARI-18627 > URL: https://issues.apache.org/jira/browse/AMBARI-18627 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander > Fix For: 2.5.0 > > Attachments: AMBARI-18627.patch, AMBARI-18627.patch > > > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18627) Add service wizard hung at Choose services page as no ClusterStackVersion is available with state=CURRENT
[ https://issues.apache.org/jira/browse/AMBARI-18627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-18627: - Attachment: AMBARI-18627.patch > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT > - > > Key: AMBARI-18627 > URL: https://issues.apache.org/jira/browse/AMBARI-18627 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander > Fix For: 2.5.0 > > Attachments: AMBARI-18627.patch, AMBARI-18627.patch > > > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18636) Remove "hbase.rpc.controllerfactory.class" from hbase-site.xml
Sandor Magyari created AMBARI-18636: --- Summary: Remove "hbase.rpc.controllerfactory.class" from hbase-site.xml Key: AMBARI-18636 URL: https://issues.apache.org/jira/browse/AMBARI-18636 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.2.0 Reporter: Sandor Magyari Assignee: Sandor Magyari Priority: Critical Fix For: 2.5.0 Do not set "hbase.rpc.controllerfactory.class" property even if Phoenix is deployed as it causes problem on a cluster with HBASE & Phoenix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18628) Usability: Ability to run host checks post-install on the Host page
[ https://issues.apache.org/jira/browse/AMBARI-18628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589149#comment-15589149 ] Hudson commented on AMBARI-18628: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #5825 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5825/]) AMBARI-18628. Usability: Ability to run host checks post-install on the (hiveww: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=dedcdf9aff6da5d63debf82cb713eaa9eb268618]) * (edit) ambari-web/app/controllers/main/host/details.js * (add) ambari-web/app/mixins/main/host/details/actions/check_host.js * (edit) ambari-web/app/mixins.js * (edit) ambari-web/app/views/main/host/details.js * (edit) ambari-web/app/templates/wizard/step3/step3_host_warnings_popup.hbs * (edit) ambari-web/app/controllers/wizard/step3_controller.js * (edit) ambari-web/app/messages.js > Usability: Ability to run host checks post-install on the Host page > --- > > Key: AMBARI-18628 > URL: https://issues.apache.org/jira/browse/AMBARI-18628 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 3.0.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander > Fix For: 3.0.0 > > Attachments: AMBARI-18628.patch > > > Provide ability to run Host Checks against a given host in an already > installed cluster. > Currently, Host Checks are only performed during Confirm Hosts (New Install > or Add Hosts). We should give users an ability to run Hosts Checks against an > already existing host in the cluster. > Hosts > Host1 > Host Actions menu > Run Host Checks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18628) Usability: Ability to run host checks post-install on the Host page
[ https://issues.apache.org/jira/browse/AMBARI-18628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-18628: - Resolution: Fixed Status: Resolved (was: Patch Available) committed to trunk > Usability: Ability to run host checks post-install on the Host page > --- > > Key: AMBARI-18628 > URL: https://issues.apache.org/jira/browse/AMBARI-18628 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 3.0.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander > Fix For: 3.0.0 > > Attachments: AMBARI-18628.patch > > > Provide ability to run Host Checks against a given host in an already > installed cluster. > Currently, Host Checks are only performed during Confirm Hosts (New Install > or Add Hosts). We should give users an ability to run Hosts Checks against an > already existing host in the cluster. > Hosts > Host1 > Host Actions menu > Run Host Checks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18635) Authorizations given to roles, should use generic role-based principals rather than hard-coded pseudo-role-based principals
Robert Levas created AMBARI-18635:
-
Summary: Authorizations given to roles, should use generic
role-based principals rather than hard-coded pseudo-role-based principals
Key: AMBARI-18635
URL: https://issues.apache.org/jira/browse/AMBARI-18635
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Robert Levas
Assignee: Robert Levas
Fix For: 2.5.0
Authorizations given to roles, should use generic role-based principals rather
than hard-coded resource types.
Access to views can be assigned to all users with a given role. The
implementation for this lead to the creation of hard-coded principals that
represent the current set of roles. This is not dynamic enough for possibly
future enhancements where new roles may be created by administrators.
This needs to be changed such that rather that using the hard-coded
pseudo-role-principals, the dynamically generated role-principals are to be
used.
The hard-coded pseudo-role-principals have the following {{adminprincipaltype}}
values as opposed to "ROLE":
* ALL.CLUSTER.ADMINISTRATOR
* ALL.CLUSTER.OPERATOR
* ALL.SERVICE.ADMINISTRATOR
* ALL.SERVICE.OPERATOR
* ALL.CLUSTER.USER
These should be removed along with the associated {{adminprincipal}} records.
Also, the FE should be updated to set permissions using the dynamic
role-principals.
Finally, code should be cleaned up to remove unneeded code in
*
org.apache.ambari.server.security.authorization.ClusterInheritedPermissionHelper
*
org.apache.ambari.server.controller.internal.GroupPrivilegeResourceProvider#getResources
*
org.apache.ambari.server.controller.internal.PrivilegeResourceProvider#toEntity
*
org.apache.ambari.server.controller.internal.UserPrivilegeResourceProvider#getResources
*
org.apache.ambari.server.security.authorization.AuthorizationHelper#isAuthorized
* org.apache.ambari.server.view.ViewRegistry#addClusterInheritedPermissions
* ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18548) Declarative Logsearch/Logfeeder Component Metadata for Stack Component
[ https://issues.apache.org/jira/browse/AMBARI-18548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivér Szabó updated AMBARI-18548: -- Attachment: AMBARI-18548.patch > Declarative Logsearch/Logfeeder Component Metadata for Stack Component > -- > > Key: AMBARI-18548 > URL: https://issues.apache.org/jira/browse/AMBARI-18548 > Project: Ambari > Issue Type: Bug > Components: ambari-logsearch >Affects Versions: 2.4.0 >Reporter: Olivér Szabó >Assignee: Olivér Szabó > Fix For: 2.5.0 > > Attachments: AMBARI-18548.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18456) Refactor Unnecessary In-Memory Locks Around Business Objects
[
https://issues.apache.org/jira/browse/AMBARI-18456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-18456:
-
Epic Name: Ambari: Concurrency Refactor (was: Concurrency Refactor)
> Refactor Unnecessary In-Memory Locks Around Business Objects
>
>
> Key: AMBARI-18456
> URL: https://issues.apache.org/jira/browse/AMBARI-18456
> Project: Ambari
> Issue Type: Epic
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
> Labels: branch-feature-AMBARI-18456
> Fix For: 2.5.0
>
>
> The top 4 business objects in Ambari:
> - ClusterImpl
> - ServiceImpl
> - ServiceComponentImpl
> - ServiceComponentHostImpl
> All use {{ReadWriteLock}} implementations to prevent dirty reads and
> concurrent writes. However, {{ClusterImpl}} exposes a "global"
> {{ReadWriteLock}} which the other business objects share. This causes
> tremendous problems with deadlocks, especially on slow databases.
> Consider the case where you have 3 threads:
> # thread-1 acquires {{ClusterReadLock}}
> # thread-2 acquires {{ServiceComponenWriteLock}}
> # thread-3 tries to get {{ClusterWriteLock}} and is blocked by {{thread-1}}
> # thread-2 tries to get {{ClusterReadLock}} and is blocked by {{thread-3}}
> # thread-1 tries to get {{ServiceComponentReadLock}} and is blocked by
> {{thread-2}}
> Essentially, the exposure of the "cluster global lock" causes problems since
> multiple threads can acquire other internal locks and be blocked waiting on
> the global lock.
> In general, I don't believe that the read locks help at all. Ambari usually
> encounters these locks while try to display web page information. Once
> displayed, the locks are removed and the information is already stale if
> there were write threads waiting.
> These locks should be investigated and, for the most part, except in some
> cases involving concurrent writes, removed.
> Part of the problem revolves around our assumption about how the
> ReadWriteLock works. The issue in the above scenario is that the
> clusterWriteLock request is pending. This actually blocks all subsequent
> readers even though the lock is not fair.
> FYI, this code shows that a reader, in unfair mode, will wait when there is a
> waiting writer:
> {noformat:title=Output}
> Waiting for a read lock...
> Read lock acquired!
> Waiting for a write lock...
> Trying to acquire a second read lock...
> {noformat}
> {code}
> import java.util.concurrent.locks.ReentrantReadWriteLock;
> public class Test {
> private static ReentrantReadWriteLock lock = new
> ReentrantReadWriteLock(false);
> public static void main(String[] args) throws InterruptedException {
> // A reader which takes too long to finish
> new Thread() {
> @Override
> public void run() {
> System.out.println("Waiting for a read lock...");
> lock.readLock().lock();
> System.out.println("Read lock acquired!");
> try {
> try {
> Thread.sleep(1000 * 60 * 60);
> } catch (InterruptedException e) {
> }
> } finally {
> lock.readLock().unlock();
> }
> }
> }.start();
> Thread.sleep(3000);
> // A writer which will be waiting
> new Thread() {
> @Override
> public void run() {
> System.out.println("Waiting for a write lock...");
> lock.writeLock().lock();
> System.out.println("Write lock acquired!");
> lock.writeLock().unlock();
> }
> }.start();
> Thread.sleep(3000);
> // Another reader
> new Thread() {
> @Override
> public void run() {
> System.out.println("Trying to acquire a second read lock...");
> lock.readLock().lock();
> try {
> System.out.println("Second read lock acquired successfully!!");
> } finally {
> lock.readLock().unlock();
> }
> }
> }.start();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18634) Support Mixed Component Versions In a Cluster
Jonathan Hurley created AMBARI-18634: Summary: Support Mixed Component Versions In a Cluster Key: AMBARI-18634 URL: https://issues.apache.org/jira/browse/AMBARI-18634 Project: Ambari Issue Type: Epic Components: ambari-agent, ambari-server Affects Versions: 2.5.0 Reporter: Jonathan Hurley Assignee: Nate Cole Priority: Critical Fix For: 2.5.0 This is a subset of the work defined in AMBARI-12556 which allows for Ambari to understand and support a cluster which has been patched manually and has components on different versions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18633) Mapreduce 'Config group' changes YARN Config Group overrides and vice versa.
[ https://issues.apache.org/jira/browse/AMBARI-18633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589026#comment-15589026 ] Aleksandr Kovalenko commented on AMBARI-18633: -- +1 for the patch > Mapreduce 'Config group' changes YARN Config Group overrides and vice versa. > > > Key: AMBARI-18633 > URL: https://issues.apache.org/jira/browse/AMBARI-18633 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk >Priority: Blocker > Attachments: AMBARI-18633_branch-2.2.2.patch > > > *STR:* > # Change a config (Memory allocated for all YARN containers on a node) from > non-default service group in YARN service and save. > # Navigate to MapReduce service and choose a non-default service group to > make config changes (Map Memory) and save > *Expected Result:* MapReduce config for non-default service group should get > successfully saved > *Actual Result:* Along wth the MapReduce config changes, non-default service > group of YARN that was previously tweaked gets reset to empty bag of > properties. > It is noticed that while saving configs of non-default group of MapReduce > service, two PUT API calls are made: one for MapReduce which is expected but > one more for YARN non-default service group with empty array for desired > configs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18628) Usability: Ability to run host checks post-install on the Host page
[
https://issues.apache.org/jira/browse/AMBARI-18628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589014#comment-15589014
]
Hadoop QA commented on AMBARI-18628:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834143/AMBARI-18628.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8921//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8921//console
This message is automatically generated.
> Usability: Ability to run host checks post-install on the Host page
> ---
>
> Key: AMBARI-18628
> URL: https://issues.apache.org/jira/browse/AMBARI-18628
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 3.0.0
>
> Attachments: AMBARI-18628.patch
>
>
> Provide ability to run Host Checks against a given host in an already
> installed cluster.
> Currently, Host Checks are only performed during Confirm Hosts (New Install
> or Add Hosts). We should give users an ability to run Hosts Checks against an
> already existing host in the cluster.
> Hosts > Host1 > Host Actions menu > Run Host Checks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18630) For rolling upgrade of Kafka 0.10.0.1, set configs for backward compatibility
[
https://issues.apache.org/jira/browse/AMBARI-18630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15588957#comment-15588957
]
Hudson commented on AMBARI-18630:
-
SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #170 (See
[https://builds.apache.org/job/Ambari-branch-2.5/170/])
AMBARI-18630. For rolling upgrade of Kafka 0.10.0.1, set configs for (ncole:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=342a088d555ca9808167a3e4ed4dec98ff04e415])
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/config-upgrade.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.5.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/config-upgrade.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.5.xml
> For rolling upgrade of Kafka 0.10.0.1, set configs for backward compatibility
> -
>
> Key: AMBARI-18630
> URL: https://issues.apache.org/jira/browse/AMBARI-18630
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Nate Cole
>Assignee: Nate Cole
>Priority: Critical
> Fix For: trunk, 2.5.0, 2.4.2
>
> Attachments: AMBARI-18630.patch
>
>
> In the 2.5 upgrade pack, the following properties need to be set
> {code}
> inter.broker.protocol.version=0.9.0.0
> log.message.format.version=0.9.0.0
> {code}
> after upgrade is done we should delete the inter.broker.protocol.version.
> Users should remove log.message.format.version once they update their clients.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18630) For rolling upgrade of Kafka 0.10.0.1, set configs for backward compatibility
[
https://issues.apache.org/jira/browse/AMBARI-18630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15588948#comment-15588948
]
Hudson commented on AMBARI-18630:
-
FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5824 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5824/])
AMBARI-18630. For rolling upgrade of Kafka 0.10.0.1, set configs for (ncole:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=3d6ddc2af5de4c489f651eb61984e44e0eb5d04d])
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/config-upgrade.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.5.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/config-upgrade.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.5.xml
> For rolling upgrade of Kafka 0.10.0.1, set configs for backward compatibility
> -
>
> Key: AMBARI-18630
> URL: https://issues.apache.org/jira/browse/AMBARI-18630
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Nate Cole
>Assignee: Nate Cole
>Priority: Critical
> Fix For: trunk, 2.5.0, 2.4.2
>
> Attachments: AMBARI-18630.patch
>
>
> In the 2.5 upgrade pack, the following properties need to be set
> {code}
> inter.broker.protocol.version=0.9.0.0
> log.message.format.version=0.9.0.0
> {code}
> after upgrade is done we should delete the inter.broker.protocol.version.
> Users should remove log.message.format.version once they update their clients.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18630) For rolling upgrade of Kafka 0.10.0.1, set configs for backward compatibility
[
https://issues.apache.org/jira/browse/AMBARI-18630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15588840#comment-15588840
]
Nate Cole commented on AMBARI-18630:
Upgrade pack changes only, no need for additional tests.
> For rolling upgrade of Kafka 0.10.0.1, set configs for backward compatibility
> -
>
> Key: AMBARI-18630
> URL: https://issues.apache.org/jira/browse/AMBARI-18630
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Nate Cole
>Assignee: Nate Cole
>Priority: Critical
> Fix For: trunk, 2.5.0, 2.4.2
>
> Attachments: AMBARI-18630.patch
>
>
> In the 2.5 upgrade pack, the following properties need to be set
> {code}
> inter.broker.protocol.version=0.9.0.0
> log.message.format.version=0.9.0.0
> {code}
> after upgrade is done we should delete the inter.broker.protocol.version.
> Users should remove log.message.format.version once they update their clients.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18630) For rolling upgrade of Kafka 0.10.0.1, set configs for backward compatibility
[
https://issues.apache.org/jira/browse/AMBARI-18630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nate Cole updated AMBARI-18630:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
> For rolling upgrade of Kafka 0.10.0.1, set configs for backward compatibility
> -
>
> Key: AMBARI-18630
> URL: https://issues.apache.org/jira/browse/AMBARI-18630
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Nate Cole
>Assignee: Nate Cole
>Priority: Critical
> Fix For: trunk, 2.5.0, 2.4.2
>
> Attachments: AMBARI-18630.patch
>
>
> In the 2.5 upgrade pack, the following properties need to be set
> {code}
> inter.broker.protocol.version=0.9.0.0
> log.message.format.version=0.9.0.0
> {code}
> after upgrade is done we should delete the inter.broker.protocol.version.
> Users should remove log.message.format.version once they update their clients.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18628) Usability: Ability to run host checks post-install on the Host page
[
https://issues.apache.org/jira/browse/AMBARI-18628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15588474#comment-15588474
]
Hadoop QA commented on AMBARI-18628:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834143/AMBARI-18628.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8920//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8920//console
This message is automatically generated.
> Usability: Ability to run host checks post-install on the Host page
> ---
>
> Key: AMBARI-18628
> URL: https://issues.apache.org/jira/browse/AMBARI-18628
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 3.0.0
>
> Attachments: AMBARI-18628.patch
>
>
> Provide ability to run Host Checks against a given host in an already
> installed cluster.
> Currently, Host Checks are only performed during Confirm Hosts (New Install
> or Add Hosts). We should give users an ability to run Hosts Checks against an
> already existing host in the cluster.
> Hosts > Host1 > Host Actions menu > Run Host Checks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18619) Optimize Service Checks to it picks a random host and prefers hosts with 0 active commands
[
https://issues.apache.org/jira/browse/AMBARI-18619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15588428#comment-15588428
]
Hadoop QA commented on AMBARI-18619:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834079/AMBARI-18619.branch-2.5.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:red}-1 core tests{color}. The patch failed these unit tests in
ambari-server:
org.apache.ambari.server.controller.internal.ActiveWidgetLayoutResourceProviderTest
org.apache.ambari.server.controller.internal.UserAuthorizationResourceProviderTest
org.apache.ambari.server.controller.internal.UserResourceProviderTest
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8919//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8919//console
This message is automatically generated.
> Optimize Service Checks to it picks a random host and prefers hosts with 0
> active commands
> --
>
> Key: AMBARI-18619
> URL: https://issues.apache.org/jira/browse/AMBARI-18619
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18619.branch-2.5.patch, AMBARI-18619.trunk.patch
>
>
> STR:
> * Deploy a 3-node cluster with Ambari 2.4 and HDP 2.5 with clients on every
> host.
> * Run multiple service checks in parallel, but notice that they typically run
> on the same 1 or 2 hosts.
> Currently, Ambari relies on getting the list of candidate hosts from the DB
> and excludes all hosts that are in maintenance mode. From that list, it picks
> the first host that is healthy (i.e., heartbeating). This means that the
> logic does not pick a random host.
> Instead, Ambari should always pick a random host and prefer to schedule on
> hosts that have 0 in-progress commands.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18628) Usability: Ability to run host checks post-install on the Host page
[ https://issues.apache.org/jira/browse/AMBARI-18628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-18628: - Status: Patch Available (was: Open) > Usability: Ability to run host checks post-install on the Host page > --- > > Key: AMBARI-18628 > URL: https://issues.apache.org/jira/browse/AMBARI-18628 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 3.0.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander > Fix For: 3.0.0 > > Attachments: AMBARI-18628.patch > > > Provide ability to run Host Checks against a given host in an already > installed cluster. > Currently, Host Checks are only performed during Confirm Hosts (New Install > or Add Hosts). We should give users an ability to run Hosts Checks against an > already existing host in the cluster. > Hosts > Host1 > Host Actions menu > Run Host Checks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18628) Usability: Ability to run host checks post-install on the Host page
[ https://issues.apache.org/jira/browse/AMBARI-18628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-18628: - Attachment: AMBARI-18628.patch > Usability: Ability to run host checks post-install on the Host page > --- > > Key: AMBARI-18628 > URL: https://issues.apache.org/jira/browse/AMBARI-18628 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 3.0.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander > Fix For: 3.0.0 > > Attachments: AMBARI-18628.patch > > > Provide ability to run Host Checks against a given host in an already > installed cluster. > Currently, Host Checks are only performed during Confirm Hosts (New Install > or Add Hosts). We should give users an ability to run Hosts Checks against an > already existing host in the cluster. > Hosts > Host1 > Host Actions menu > Run Host Checks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18633) Mapreduce 'Config group' changes YARN Config Group overrides and vice versa.
[
https://issues.apache.org/jira/browse/AMBARI-18633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15588308#comment-15588308
]
Hadoop QA commented on AMBARI-18633:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834131/AMBARI-18633_branch-2.2.2.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8918//console
This message is automatically generated.
> Mapreduce 'Config group' changes YARN Config Group overrides and vice versa.
>
>
> Key: AMBARI-18633
> URL: https://issues.apache.org/jira/browse/AMBARI-18633
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Blocker
> Attachments: AMBARI-18633_branch-2.2.2.patch
>
>
> *STR:*
> # Change a config (Memory allocated for all YARN containers on a node) from
> non-default service group in YARN service and save.
> # Navigate to MapReduce service and choose a non-default service group to
> make config changes (Map Memory) and save
> *Expected Result:* MapReduce config for non-default service group should get
> successfully saved
> *Actual Result:* Along wth the MapReduce config changes, non-default service
> group of YARN that was previously tweaked gets reset to empty bag of
> properties.
> It is noticed that while saving configs of non-default group of MapReduce
> service, two PUT API calls are made: one for MapReduce which is expected but
> one more for YARN non-default service group with empty array for desired
> configs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18633) Mapreduce 'Config group' changes YARN Config Group overrides and vice versa.
[ https://issues.apache.org/jira/browse/AMBARI-18633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Babiichuk updated AMBARI-18633: -- Status: Patch Available (was: Open) > Mapreduce 'Config group' changes YARN Config Group overrides and vice versa. > > > Key: AMBARI-18633 > URL: https://issues.apache.org/jira/browse/AMBARI-18633 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk >Priority: Blocker > Attachments: AMBARI-18633_branch-2.2.2.patch > > > *STR:* > # Change a config (Memory allocated for all YARN containers on a node) from > non-default service group in YARN service and save. > # Navigate to MapReduce service and choose a non-default service group to > make config changes (Map Memory) and save > *Expected Result:* MapReduce config for non-default service group should get > successfully saved > *Actual Result:* Along wth the MapReduce config changes, non-default service > group of YARN that was previously tweaked gets reset to empty bag of > properties. > It is noticed that while saving configs of non-default group of MapReduce > service, two PUT API calls are made: one for MapReduce which is expected but > one more for YARN non-default service group with empty array for desired > configs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18633) Mapreduce 'Config group' changes YARN Config Group overrides and vice versa.
[ https://issues.apache.org/jira/browse/AMBARI-18633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Babiichuk updated AMBARI-18633: -- Attachment: AMBARI-18633_branch-2.2.2.patch > Mapreduce 'Config group' changes YARN Config Group overrides and vice versa. > > > Key: AMBARI-18633 > URL: https://issues.apache.org/jira/browse/AMBARI-18633 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk >Priority: Blocker > Attachments: AMBARI-18633_branch-2.2.2.patch > > > *STR:* > # Change a config (Memory allocated for all YARN containers on a node) from > non-default service group in YARN service and save. > # Navigate to MapReduce service and choose a non-default service group to > make config changes (Map Memory) and save > *Expected Result:* MapReduce config for non-default service group should get > successfully saved > *Actual Result:* Along wth the MapReduce config changes, non-default service > group of YARN that was previously tweaked gets reset to empty bag of > properties. > It is noticed that while saving configs of non-default group of MapReduce > service, two PUT API calls are made: one for MapReduce which is expected but > one more for YARN non-default service group with empty array for desired > configs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18633) Mapreduce 'Config group' changes YARN Config Group overrides and vice versa.
Andrii Babiichuk created AMBARI-18633: - Summary: Mapreduce 'Config group' changes YARN Config Group overrides and vice versa. Key: AMBARI-18633 URL: https://issues.apache.org/jira/browse/AMBARI-18633 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.2.2 Reporter: Andrii Babiichuk Assignee: Andrii Babiichuk Priority: Blocker *STR:* # Change a config (Memory allocated for all YARN containers on a node) from non-default service group in YARN service and save. # Navigate to MapReduce service and choose a non-default service group to make config changes (Map Memory) and save *Expected Result:* MapReduce config for non-default service group should get successfully saved *Actual Result:* Along wth the MapReduce config changes, non-default service group of YARN that was previously tweaked gets reset to empty bag of properties. It is noticed that while saving configs of non-default group of MapReduce service, two PUT API calls are made: one for MapReduce which is expected but one more for YARN non-default service group with empty array for desired configs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18625) Can't open Hive view in Internet explorer 11 in HDP 2.5
[ https://issues.apache.org/jira/browse/AMBARI-18625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pallav Kulshreshtha updated AMBARI-18625: - Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk, branch-2.5 and branch-2.4 > Can't open Hive view in Internet explorer 11 in HDP 2.5 > --- > > Key: AMBARI-18625 > URL: https://issues.apache.org/jira/browse/AMBARI-18625 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.4.0 >Reporter: Pallav Kulshreshtha >Assignee: Pallav Kulshreshtha > Fix For: 2.5.0 > > Attachments: AMBARI-18625_trunk.patch > > > Hive view from Internet explorer. It doesn't show anything. > RCA: > The bug got introduced in https://issues.apache.org/jira/browse/AMBARI-17482. > Hive View does not use Babel hence ES6 syntax are not transpiled into ES5 > syntax and IE 11 does not support ES6(most of the features). AMBARI-17482 > introduces some arrow functions in the JS code(ES6 syntax) which are not > compatible with IE and hence hive view breaks down. > Code Location: > https://github.com/apache/ambari/blob/trunk/contrib/views/hive-next/src/main/resources/ui/hive-web/app/components/date-range-widget.js#L84 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18625) Can't open Hive view in Internet explorer 11 in HDP 2.5
[ https://issues.apache.org/jira/browse/AMBARI-18625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15588048#comment-15588048 ] Hudson commented on AMBARI-18625: - FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5823 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5823/]) AMBARI-18625. Can't open Hive view in Internet explorer 11 in HDP 2.5 (pallavkul: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=2a2c557f126e9cdf148e4ebf9c2b375c66c346df]) * (edit) contrib/views/hive-next/src/main/resources/ui/hive-web/app/components/date-range-widget.js * (edit) contrib/views/hive/src/main/resources/ui/hive-web/app/components/date-range-widget.js > Can't open Hive view in Internet explorer 11 in HDP 2.5 > --- > > Key: AMBARI-18625 > URL: https://issues.apache.org/jira/browse/AMBARI-18625 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.4.0 >Reporter: Pallav Kulshreshtha >Assignee: Pallav Kulshreshtha > Fix For: 2.5.0 > > Attachments: AMBARI-18625_trunk.patch > > > Hive view from Internet explorer. It doesn't show anything. > RCA: > The bug got introduced in https://issues.apache.org/jira/browse/AMBARI-17482. > Hive View does not use Babel hence ES6 syntax are not transpiled into ES5 > syntax and IE 11 does not support ES6(most of the features). AMBARI-17482 > introduces some arrow functions in the JS code(ES6 syntax) which are not > compatible with IE and hence hive view breaks down. > Code Location: > https://github.com/apache/ambari/blob/trunk/contrib/views/hive-next/src/main/resources/ui/hive-web/app/components/date-range-widget.js#L84 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18625) Can't open Hive view in Internet explorer 11 in HDP 2.5
[ https://issues.apache.org/jira/browse/AMBARI-18625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15588043#comment-15588043 ] Hudson commented on AMBARI-18625: - SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #169 (See [https://builds.apache.org/job/Ambari-branch-2.5/169/]) AMBARI-18625. Can't open Hive view in Internet explorer 11 in HDP 2.5 (pallavkul: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=05ee056c1b0e5d982e47eacf06e4db8a4305cf53]) * (edit) contrib/views/hive-next/src/main/resources/ui/hive-web/app/components/date-range-widget.js * (edit) contrib/views/hive/src/main/resources/ui/hive-web/app/components/date-range-widget.js > Can't open Hive view in Internet explorer 11 in HDP 2.5 > --- > > Key: AMBARI-18625 > URL: https://issues.apache.org/jira/browse/AMBARI-18625 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.4.0 >Reporter: Pallav Kulshreshtha >Assignee: Pallav Kulshreshtha > Fix For: 2.5.0 > > Attachments: AMBARI-18625_trunk.patch > > > Hive view from Internet explorer. It doesn't show anything. > RCA: > The bug got introduced in https://issues.apache.org/jira/browse/AMBARI-17482. > Hive View does not use Babel hence ES6 syntax are not transpiled into ES5 > syntax and IE 11 does not support ES6(most of the features). AMBARI-17482 > introduces some arrow functions in the JS code(ES6 syntax) which are not > compatible with IE and hence hive view breaks down. > Code Location: > https://github.com/apache/ambari/blob/trunk/contrib/views/hive-next/src/main/resources/ui/hive-web/app/components/date-range-widget.js#L84 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
