[jira] [Commented] (AMBARI-13024) Disable MetricsDataTransferMethodFactory for AMS

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13024:
-

FAILURE: Integrated in Ambari-branch-2.1 #526 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/526/])
AMBARI-13024 Disable MetricsDataTransferMethodFactory for AMS (dsen) (dsen: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=cba000d2da06443f7de3446d6c2368c839d4e08c)
* ambari-server/src/test/resources/ams/single_host_metric.json
* ambari-server/src/test/resources/ams/multiple_host_metrics.json
* 
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/core/host_info.py
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/metrics/MetricsDataTransferMethodFactory.java
* 
ambari-metrics/ambari-metrics-host-monitoring/src/test/python/core/TestHostInfo.py


> Disable MetricsDataTransferMethodFactory for AMS
> 
>
> Key: AMBARI-13024
> URL: https://issues.apache.org/jira/browse/AMBARI-13024
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, ambari-server
>Affects Versions: 2.1.1
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
> Fix For: 2.1.2
>
> Attachments: AMBARI-13024_4.patch
>
>
> Some metrics are double-edited(on MetricsDataTransferMethodFactory and 
> sink/monitor side)
> For instance, cpu-metrics are multiplied by 100 on monitor side, but divided 
> by MetricsDataTransferMethodFactory



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

Re: Review Request 38220: [Preview] Stop-and-Start Upgrade: apply configs after all services have been stopped

[Dmitro Lisnichenko]

> On Sept. 11, 2015, 2:51 p.m., Jonathan Hurley wrote:
> > Why is this change needed for stop-the-world? You've already stopped the 
> > hive server and prevented clients from draining. You should not need to 
> > adjust the ports like we do for normal rolling upgrades.
> 
> Alejandro Fernandez wrote:
> You're right. Stop-the-World Upgrade doesn't need to temporarily change 
> the hive port.

Ok, I'll not include that into the final patch. But I still need some place to 
debug application of config changes during the SWU. As of now, 2.2->2.2+ SWU is 
the ony upgrade available, and that is the only config change for this patch.


- Dmitro


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38220/#review98609
---


On Sept. 9, 2015, 2:52 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38220/
> ---
> 
> (Updated Sept. 9, 2015, 2:52 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Dmytro Grinenko, Jonathan 
> Hurley, and Nate Cole.
> 
> 
> Bugs: AMBARI-13048
> https://issues.apache.org/jira/browse/AMBARI-13048
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Goal:
> for STW Upgrade, we'll need to apply configs after all services have been 
> stopped, and before calling hdp-select set all.
> 
> I think, we have to add separate groups before and after restart of HIVE 
> server to enforce config application order during UPGRADE and DONGRADE. Looks 
> like that is the only config change required for 2.2->2.2+ upgrade. Does such 
> upgrade pack definition look good?
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.2.xml
>  01022b8 
> 
> Diff: https://reviews.apache.org/r/38220/diff/
> 
> 
> Testing
> ---
> 
> Preview
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

[jira] [Commented] (AMBARI-13084) Ambari UI issues in SAPHD builds

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13084:
-

FAILURE: Integrated in Ambari-trunk-Commit #3436 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3436/])
AMBARI-13084 Ambari UI issues in SAPHD builds.  (ababiichuk) (ababiichuk: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=63dded51d90d06f1ca7e55e6b756a5343c22659e)
* ambari-web/app/data/HDP2/site_properties.js
* ambari-web/app/data/HDP2.3/site_properties.js
* ambari-web/app/views/common/controls_view.js
* ambari-web/app/messages.js


> Ambari UI issues in SAPHD builds
> 
>
> Key: AMBARI-13084
> URL: https://issues.apache.org/jira/browse/AMBARI-13084
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13084.patch
>
>
> 1. We should NOT show SQLAnywhere as an option for any builds except for SAP; 
> show SQLAnywhere as an option if the stack name is SAPHD.
> 2. SQLAnywhere requires HDP 2.3.2 or greater message, therefore, does not 
> make sense. Let's get rid of that.



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

[jira] [Commented] (AMBARI-13024) Disable MetricsDataTransferMethodFactory for AMS

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13024:
-

FAILURE: Integrated in Ambari-trunk-Commit #3436 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3436/])
AMBARI-13024 Disable MetricsDataTransferMethodFactory for AMS (dsen) (dsen: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=e837d4f082d32a69bd345ba805ee1d96b8981296)
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/metrics/MetricsDataTransferMethodFactory.java
* ambari-server/src/test/resources/ams/multiple_host_metrics.json
* ambari-server/src/test/resources/ams/single_host_metric.json
* 
ambari-metrics/ambari-metrics-host-monitoring/src/test/python/core/TestHostInfo.py
* 
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/core/host_info.py


> Disable MetricsDataTransferMethodFactory for AMS
> 
>
> Key: AMBARI-13024
> URL: https://issues.apache.org/jira/browse/AMBARI-13024
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, ambari-server
>Affects Versions: 2.1.1
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
> Fix For: 2.1.2
>
> Attachments: AMBARI-13024_4.patch
>
>
> Some metrics are double-edited(on MetricsDataTransferMethodFactory and 
> sink/monitor side)
> For instance, cpu-metrics are multiplied by 100 on monitor side, but divided 
> by MetricsDataTransferMethodFactory



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

[jira] [Commented] (AMBARI-13083) Use recommendedValue instead of defaultDirectory attribute for site properties

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13083:
-

FAILURE: Integrated in Ambari-trunk-Commit #3436 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3436/])
AMBARI-13083 Use recommendedValue instead of defaultDirectory attribute for 
site properties. (ababiichuk) (ababiichuk: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=0c77e3d2392323ec6f8b206427db0eca4217b7ea)
* ambari-web/app/utils/configs/config_property_helper.js
* ambari-web/app/data/HDP2/ha_properties.js
* ambari-web/test/utils/config_test.js
* ambari-web/app/data/HDP2.2/site_properties.js
* ambari-web/app/data/HDP2/site_properties.js
* ambari-web/app/models/configs/objects/service_config_property.js
* ambari-web/app/data/BIGTOP/site_properties.js
* ambari-web/app/utils/config.js
* ambari-web/test/utils/configs/config_property_helper_test.js


> Use recommendedValue instead of defaultDirectory attribute for site properties
> --
>
> Key: AMBARI-13083
> URL: https://issues.apache.org/jira/browse/AMBARI-13083
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
> Fix For: 2.2.0
>
> Attachments: AMBARI-13083.patch
>
>
> Lets remove 'defaultDirectory' attribute and instead use the recommendedValue 
> that we get from stack or recommendation endpoint API. 



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

[jira] [Commented] (AMBARI-13082) Devdeploy: Hdfs components install fails with lzo enabled

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13082:
-

ABORTED: Integrated in Ambari-trunk-Commit #3435 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3435/])
AMBARI-13082. Devdeploy: Hdfs components install fails with lzo enabled 
(aonishuk) (aonishuk: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=25de1567acad680b8d5fd025b26b5082796609bf)
* 
ambari-common/src/main/python/resource_management/libraries/functions/get_lzo_packages.py
* 
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/params_linux.py
* ambari-common/src/main/python/resource_management/libraries/script/script.py


> Devdeploy: Hdfs components install fails with lzo enabled
> -
>
> Key: AMBARI-13082
> URL: https://issues.apache.org/jira/browse/AMBARI-13082
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.1.2
>
>
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/HDFS/2.1.0.2.0/package/scripts/hdfs_client.py",
>  line 120, in 
> HdfsClient().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 219, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HDFS/2.1.0.2.0/package/scripts/hdfs_client.py",
>  line 36, in install
> self.configure(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HDFS/2.1.0.2.0/package/scripts/hdfs_client.py",
>  line 41, in configure
> hdfs()
>   File 
> "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py", line 89, 
> in thunk
> return fn(*args, **kwargs)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HDFS/2.1.0.2.0/package/scripts/hdfs.py",
>  line 120, in hdfs
> Package(params.lzo_packages)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/base.py", line 
> 154, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 152, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 118, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/package/__init__.py",
>  line 45, in action_install
> self.install_package(package_name, self.resource.use_repos, 
> self.resource.skip_repos)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/package/yumrpm.py",
>  line 49, in install_package
> shell.checked_call(cmd, sudo=True, logoutput=self.get_logoutput())
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 70, in inner
> result = function(command, **kwargs)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 92, in checked_call
> tries=tries, try_sleep=try_sleep)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 291, in _call
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of '/usr/bin/yum -d 0 
> -e 0 -y install hadooplzo_2_3_.+' returned 1. Error: Nothing to do
> 



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

[jira] [Created] (AMBARI-13086) 500 error for API calls to /api/v1/clusters/

[Vitaly Brodetskyi (JIRA)]

Vitaly Brodetskyi created AMBARI-13086:
--

 Summary: 500 error for API calls to /api/v1/clusters/
 Key: AMBARI-13086
 URL: https://issues.apache.org/jira/browse/AMBARI-13086
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.1.2
Reporter: Vitaly Brodetskyi
Assignee: Vitaly Brodetskyi
Priority: Blocker
 Fix For: 2.1.2


Steps:
# Deploy cluster.
# Execute GET request to :8080/api/v1/clusters/.

Result: was returned response:
{code}
{
  "status": 500,
  "message": "Server Error"
}
{code}

*Ambari DB: :SQLAnywhere*
*Oozie/Hive DB: SQLAnywhere/SQLAnywhere*

>From ambari-server.log:
{code}
09 Sep 2015 11:01:04,490  WARN [qtp-client-210] ServletHandler:563 - 
/api/v1/clusters/cl1
java.lang.ClassCastException: java.lang.Boolean cannot be cast to 
java.lang.Number
at 
org.apache.ambari.server.orm.dao.AlertsDAO.findCurrentHostCounts(AlertsDAO.java:476)
at 
org.apache.ambari.server.orm.AmbariLocalSessionInterceptor.invoke(AmbariLocalSessionInterceptor.java:53)
at 
org.apache.ambari.server.controller.internal.AlertSummaryPropertyProvider.populateResource(AlertSummaryPropertyProvider.java:133)
at 
org.apache.ambari.server.controller.internal.AlertSummaryPropertyProvider.populateResources(AlertSummaryPropertyProvider.java:97)
at 
org.apache.ambari.server.controller.internal.ClusterControllerImpl.populateResources(ClusterControllerImpl.java:146)
at 
org.apache.ambari.server.api.query.QueryImpl.queryForResources(QueryImpl.java:407)
at 
org.apache.ambari.server.api.query.QueryImpl.execute(QueryImpl.java:217)
at 
org.apache.ambari.server.api.handlers.ReadHandler.handleRequest(ReadHandler.java:68)
at 
org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:135)
at 
org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:105)
at 
org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:74)
at 
org.apache.ambari.server.api.services.ClusterService.getCluster(ClusterService.java:94)
at sun.reflect.GeneratedMethodAccessor240.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at 
com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at 
com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at 
com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
at 
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at 
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at 
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at 
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at 
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
at 
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
at 
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
at 
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
at 
com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
at 
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:540)
at 
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:715)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at 
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:118)
at 
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:84)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at 

[jira] [Created] (AMBARI-13088) Kafka LogFlushStats metrics are missing

[Andrii Tkach (JIRA)]

Andrii Tkach created AMBARI-13088:
-

 Summary: Kafka LogFlushStats metrics are missing
 Key: AMBARI-13088
 URL: https://issues.apache.org/jira/browse/AMBARI-13088
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.1.2
Reporter: Andrii Tkach
Assignee: Andrii Tkach
Priority: Critical
 Fix For: 2.1.2


Respond on request 
{code}http://172.22.72.96:8080/api/v1/clusters/cl1/services/KAFKA/components/KAFKA_BROKER?fields=metrics/kafka/log/LogFlushStats/LogFlushRateAndTimeMs/1MinuteRate[1441953819,1441957419,15]{code}
 doesn't contain any metrics {code}{
  "href" : 
"http://172.22.72.96:8080/api/v1/clusters/cl1/services/KAFKA/components/KAFKA_BROKER?fields=metrics/kafka/log/LogFlushStats/LogFlushRateAndTimeMs/1MinuteRate[1441953819,1441957419,15];,
  "ServiceComponentInfo" : {
"cluster_name" : "cl1",
"component_name" : "KAFKA_BROKER",
"service_name" : "KAFKA"
  }
}{code}



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

Review Request 38354: Ambari seems to strip %Y %M %D, etc partitioning options from Flume output paths

[Vitalyi Brodetskyi]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38354/
---

Review request for Ambari, Andrew Onischuk, Dmitro Lisnichenko, and Dmytro Sen.


Bugs: AMBARI-13089
https://issues.apache.org/jira/browse/AMBARI-13089


Repository: ambari


Description
---

Ambari seems to strip %Y %M %D, etc partitioning options from Flume output 
paths.


Diffs
-

  
ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/package/scripts/flume.py
 cff969f 

Diff: https://reviews.apache.org/r/38354/diff/


Testing
---

mvn clean test


Thanks,

Vitalyi Brodetskyi

Review Request 38351: 500 error for API calls to /api/v1/clusters/

[Vitalyi Brodetskyi]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38351/
---

Review request for Ambari, Myroslav Papirkovskyy and Sumit Mohanty.


Bugs: AMBARI-13086
https://issues.apache.org/jira/browse/AMBARI-13086


Repository: ambari


Description
---

Steps:
# Deploy cluster.
# Execute GET request to :8080/api/v1/clusters/.

Result: was returned response:
{code}
{
  "status": 500,
  "message": "Server Error"
}
{code}

*Ambari DB: :SQLAnywhere*
*Oozie/Hive DB: SQLAnywhere/SQLAnywhere*

>From ambari-server.log:
{code}
09 Sep 2015 11:01:04,490  WARN [qtp-client-210] ServletHandler:563 - 
/api/v1/clusters/cl1
java.lang.ClassCastException: java.lang.Boolean cannot be cast to 
java.lang.Number
at 
org.apache.ambari.server.orm.dao.AlertsDAO.findCurrentHostCounts(AlertsDAO.java:476)
at 
org.apache.ambari.server.orm.AmbariLocalSessionInterceptor.invoke(AmbariLocalSessionInterceptor.java:53)
at 
org.apache.ambari.server.controller.internal.AlertSummaryPropertyProvider.populateResource(AlertSummaryPropertyProvider.java:133)
at 
org.apache.ambari.server.controller.internal.AlertSummaryPropertyProvider.populateResources(AlertSummaryPropertyProvider.java:97)
at 
org.apache.ambari.server.controller.internal.ClusterControllerImpl.populateResources(ClusterControllerImpl.java:146)
at 
org.apache.ambari.server.api.query.QueryImpl.queryForResources(QueryImpl.java:407)
at 
org.apache.ambari.server.api.query.QueryImpl.execute(QueryImpl.java:217)
at 
org.apache.ambari.server.api.handlers.ReadHandler.handleRequest(ReadHandler.java:68)
at 
org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:135)
at 
org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:105)
at 
org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:74)
at 
org.apache.ambari.server.api.services.ClusterService.getCluster(ClusterService.java:94)
at sun.reflect.GeneratedMethodAccessor240.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at 
com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at 
com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at 
com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
at 
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at 
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at 
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at 
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at 
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
at 
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
at 
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
at 
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
at 
com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
at 
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:540)
at 
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:715)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at 
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:118)
at 
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:84)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at 
org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113)
at 

[jira] [Updated] (AMBARI-13087) Verify if restricting acls on /var/lib/ambari-agent/data will be OK

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk updated AMBARI-13087:
-
Description: (was: **DO NOT CREATE AN EXTERNAL APACHE JIRA**  
Add the findings to this JIRA. This is a potential security issue and hence a
different process needs to be followed.

1\. the permissions of the /var/lib/ambari-agent/data folder is 0744. The data
folder contains output and error streams from all ambari agents’ commands. If
a script prints any of its parameters to the screen, such as passwords, either
while succeeding, or when an exception is thrown, then all users on the system
are able to read this data. Unless we’re mistaken, the correct permissions on
this folder should be 0700.

2\. The permissions of the /var/lib/ambari-agent/keys/.key private
key is set to 0644. This makes the private key of the ambari agent publically
readable. As far as we know, ambari agents talk to the server with SSL using
the key placed here (if SSL is enabled). We think that within a short amount
of time it is possible for any user on the system to craft the call to the
ambari server pretending to be the ambari agent heartbeat, and intercept all
configurations being sent to the ambari agent. These configurations contain
all parameters of the cluster, and are therefore prone to containing admin
passwords, it undermines the SSL encryption completely. Unless we’re mistaken,
the correct permissions should be 0600.

Further suggestions:  
chmod -R 0600 /var/lib/ambari-agent/data  
chmod -R a+X /var/lib/ambari-agent/data  
chmod -R a+rx /var/lib/ambari-agent/data/tmp  
chmod 0600 /var/lib/ambari-agent/keys/*.key

Ideally ambari would separate out this temporary directory and even smartly
review creation of files to be chowned to the correct user. These scripts
often are created from templates and may then also possibly contain passwords.

**DO NOT CREATE AN EXTERNAL APACHE JIRA**

)

> Verify if restricting acls on /var/lib/ambari-agent/data will be OK
> ---
>
> Key: AMBARI-13087
> URL: https://issues.apache.org/jira/browse/AMBARI-13087
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.1.2
>
>




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

[jira] [Updated] (AMBARI-13087) test

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk updated AMBARI-13087:
-
Summary: test  (was: Verify if restricting acls on 
/var/lib/ambari-agent/data will be OK)

> test
> 
>
> Key: AMBARI-13087
> URL: https://issues.apache.org/jira/browse/AMBARI-13087
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.1.2
>
>




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

[jira] [Updated] (AMBARI-13088) Kafka LogFlushStats metrics are missing

[Andrii Tkach (JIRA)]

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

Andrii Tkach updated AMBARI-13088:
--
Attachment: AMBARI-13088.patch

> Kafka LogFlushStats metrics are missing
> ---
>
> Key: AMBARI-13088
> URL: https://issues.apache.org/jira/browse/AMBARI-13088
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13088.patch
>
>
> Respond on request 
> {code}http://172.22.72.96:8080/api/v1/clusters/cl1/services/KAFKA/components/KAFKA_BROKER?fields=metrics/kafka/log/LogFlushStats/LogFlushRateAndTimeMs/1MinuteRate[1441953819,1441957419,15]{code}
>  doesn't contain any metrics {code}{
>   "href" : 
> "http://172.22.72.96:8080/api/v1/clusters/cl1/services/KAFKA/components/KAFKA_BROKER?fields=metrics/kafka/log/LogFlushStats/LogFlushRateAndTimeMs/1MinuteRate[1441953819,1441957419,15];,
>   "ServiceComponentInfo" : {
> "cluster_name" : "cl1",
> "component_name" : "KAFKA_BROKER",
> "service_name" : "KAFKA"
>   }
> }{code}



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

[jira] [Updated] (AMBARI-13038) Define ephemeral port range for Ambari agents

[JIRA]

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

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

> Define ephemeral port range for Ambari agents
> -
>
> Key: AMBARI-13038
> URL: https://issues.apache.org/jira/browse/AMBARI-13038
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: 2.1.0
> Environment: All
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Attachments: AMBARI-13038.patch
>
>
> Problem: 
> When Ambari agent starts,it tries to use an ephemeral port that is already in 
> use by another component.
> Steps to Reproduce:
> 1. Install a cluster with Ambari
> 2. Restart the Ambari agent until it takes a port in use by another service
> Solution:
> Range of ephemeral ports used by Ambari should be narrowed. (configurable)



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

Re: Review Request 38351: 500 error for API calls to /api/v1/clusters/

[Myroslav Papirkovskyy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38351/#review98836
---

Ship it!


Ship It!

- Myroslav Papirkovskyy


On Вер. 14, 2015, 2:15 після полудня, Vitalyi Brodetskyi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38351/
> ---
> 
> (Updated Вер. 14, 2015, 2:15 після полудня)
> 
> 
> Review request for Ambari, Myroslav Papirkovskyy and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-13086
> https://issues.apache.org/jira/browse/AMBARI-13086
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Steps:
> # Deploy cluster.
> # Execute GET request to :8080/api/v1/clusters/.
> 
> Result: was returned response:
> {code}
> {
>   "status": 500,
>   "message": "Server Error"
> }
> {code}
> 
> *Ambari DB: :SQLAnywhere*
> *Oozie/Hive DB: SQLAnywhere/SQLAnywhere*
> 
> From ambari-server.log:
> {code}
> 09 Sep 2015 11:01:04,490  WARN [qtp-client-210] ServletHandler:563 - 
> /api/v1/clusters/cl1
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to 
> java.lang.Number
> at 
> org.apache.ambari.server.orm.dao.AlertsDAO.findCurrentHostCounts(AlertsDAO.java:476)
> at 
> org.apache.ambari.server.orm.AmbariLocalSessionInterceptor.invoke(AmbariLocalSessionInterceptor.java:53)
> at 
> org.apache.ambari.server.controller.internal.AlertSummaryPropertyProvider.populateResource(AlertSummaryPropertyProvider.java:133)
> at 
> org.apache.ambari.server.controller.internal.AlertSummaryPropertyProvider.populateResources(AlertSummaryPropertyProvider.java:97)
> at 
> org.apache.ambari.server.controller.internal.ClusterControllerImpl.populateResources(ClusterControllerImpl.java:146)
> at 
> org.apache.ambari.server.api.query.QueryImpl.queryForResources(QueryImpl.java:407)
> at 
> org.apache.ambari.server.api.query.QueryImpl.execute(QueryImpl.java:217)
> at 
> org.apache.ambari.server.api.handlers.ReadHandler.handleRequest(ReadHandler.java:68)
> at 
> org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:135)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:105)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:74)
> at 
> org.apache.ambari.server.api.services.ClusterService.getCluster(ClusterService.java:94)
> at sun.reflect.GeneratedMethodAccessor240.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
> at 
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at 
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at 
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
> at 
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
> at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:540)
> at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:715)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)
> at 
> 

[jira] [Created] (AMBARI-13089) Ambari seems to strip %Y %M %D, etc partitioning options from Flume output paths

[Vitaly Brodetskyi (JIRA)]

Vitaly Brodetskyi created AMBARI-13089:
--

 Summary: Ambari seems to strip %Y %M %D, etc partitioning options 
from Flume output paths
 Key: AMBARI-13089
 URL: https://issues.apache.org/jira/browse/AMBARI-13089
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.0.0
Reporter: Vitaly Brodetskyi
Assignee: Vitaly Brodetskyi
Priority: Critical
 Fix For: 2.1.2


Ambari seems to strip %Y %M %D, etc partitioning options from Flume output 
paths.



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

[jira] [Updated] (AMBARI-13085) Ambari fails to install Ranger, UI hangs, logs StackAdvisorRunner advisor script error

[Hari Sekhon (JIRA)]

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

Hari Sekhon updated AMBARI-13085:
-
Attachment: Screen Shot 2015-09-14 at 11.37.08.png

> Ambari fails to install Ranger, UI hangs, logs StackAdvisorRunner advisor 
> script error
> --
>
> Key: AMBARI-13085
> URL: https://issues.apache.org/jira/browse/AMBARI-13085
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, ambari-web, security, stacks
>Affects Versions: 2.1.0
> Environment: HDP 2.3 + Kerberos + Ranger 0.5
>Reporter: Hari Sekhon
>Priority: Blocker
> Attachments: Screen Shot 2015-09-14 at 11.37.08.png
>
>
> When trying to deploy Ranger via Ambari after entering the red config 
> settings until the Next button ungreys and clicking "next", and then "proceed 
> anyway" (it recommended higher yarn memory settings which I had reduced to 
> co-locate some other software) the Ambari UI returns to the config screen 
> with the next button greyed out but no services show configuration requiring 
> changes.
> The ambari server log shows only:
> {code}14 Sep 2015 10:32:08,337  INFO [qtp-client-5982] StackAdvisorRunner:71 
> - advisor script stderr: {code}
> But it doesn't show what the error was.
> I'm attaching a screenshot showing there are no outstanding configs and yet 
> the next button remains greyed out and nothing happens, Ambari just hangs.



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

Re: Review Request 38353: Verify if restricting acls on /var/lib/ambari-agent/data will be OK

[Andrew Onischuk]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38353/
---

(Updated Sept. 14, 2015, 11:58 a.m.)


Review request for Ambari and Dmitro Lisnichenko.


Bugs: AMBARI-13087
https://issues.apache.org/jira/browse/AMBARI-13087


Repository: ambari


Description (updated)
---

-


Diffs
-

  ambari-agent/conf/unix/ambari-agent.ini abfde62 
  ambari-agent/conf/unix/install-helper.sh 48391d5 
  ambari-agent/pom.xml c2bee4a 
  ambari-agent/src/main/python/ambari_agent/Constants.py PRE-CREATION 
  ambari-agent/src/main/python/ambari_agent/CustomServiceOrchestrator.py 
6ee929cb 
  ambari-agent/src/main/python/ambari_agent/alerts/metric_alert.py aa4ad75 
  ambari-agent/src/main/python/ambari_agent/alerts/script_alert.py 76afbc9 
  ambari-agent/src/main/python/ambari_agent/alerts/web_alert.py b76d5e0 
  ambari-agent/src/main/python/ambari_agent/security.py bfaf134 
  ambari-agent/src/test/python/ambari_agent/TestCertGeneration.py d188dbd 
  ambari-agent/src/test/python/ambari_agent/TestCustomServiceOrchestrator.py 
831ecce 
  ambari-agent/src/test/python/ambari_agent/TestSecurity.py c47172a 
  ambari-common/src/main/python/resource_management/libraries/script/script.py 
a2c0c45 
  ambari-server/src/main/python/bootstrap.py 98a3a93 
  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/namenode.py
 1415367 
  ambari-server/src/test/python/TestBootstrap.py 1fcb3ad 

Diff: https://reviews.apache.org/r/38353/diff/


Testing
---

mvn clean test


Thanks,

Andrew Onischuk

Re: Review Request 38353: Verify if restricting acls on /var/lib/ambari-agent/data will be OK

[Dmitro Lisnichenko]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38353/#review98833
---

Ship it!


Ship It!

- Dmitro Lisnichenko


On Sept. 14, 2015, 11:55 a.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38353/
> ---
> 
> (Updated Sept. 14, 2015, 11:55 a.m.)
> 
> 
> Review request for Ambari and Dmitro Lisnichenko.
> 
> 
> Bugs: AMBARI-13087
> https://issues.apache.org/jira/browse/AMBARI-13087
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> **DO NOT CREATE AN EXTERNAL APACHE JIRA**  
> Add the findings to this JIRA. This is a potential security issue and hence a
> different process needs to be followed.
> 
> 1\. the permissions of the /var/lib/ambari-agent/data folder is 0744. The data
> folder contains output and error streams from all ambari agents’ commands. If
> a script prints any of its parameters to the screen, such as passwords, either
> while succeeding, or when an exception is thrown, then all users on the system
> are able to read this data. Unless we’re mistaken, the correct permissions on
> this folder should be 0700.
> 
> 2\. The permissions of the /var/lib/ambari-agent/keys/.key private
> key is set to 0644. This makes the private key of the ambari agent publically
> readable. As far as we know, ambari agents talk to the server with SSL using
> the key placed here (if SSL is enabled). We think that within a short amount
> of time it is possible for any user on the system to craft the call to the
> ambari server pretending to be the ambari agent heartbeat, and intercept all
> configurations being sent to the ambari agent. These configurations contain
> all parameters of the cluster, and are therefore prone to containing admin
> passwords, it undermines the SSL encryption completely. Unless we’re mistaken,
> the correct permissions should be 0600.
> 
> Further suggestions:  
> chmod -R 0600 /var/lib/ambari-agent/data  
> chmod -R a+X /var/lib/ambari-agent/data  
> chmod -R a+rx /var/lib/ambari-agent/data/tmp  
> chmod 0600 /var/lib/ambari-agent/keys/*.key
> 
> Ideally ambari would separate out this temporary directory and even smartly
> review creation of files to be chowned to the correct user. These scripts
> often are created from templates and may then also possibly contain passwords.
> 
> **DO NOT CREATE AN EXTERNAL APACHE JIRA**
> 
> 
> Diffs
> -
> 
>   ambari-agent/conf/unix/ambari-agent.ini abfde62 
>   ambari-agent/conf/unix/install-helper.sh 48391d5 
>   ambari-agent/pom.xml c2bee4a 
>   ambari-agent/src/main/python/ambari_agent/Constants.py PRE-CREATION 
>   ambari-agent/src/main/python/ambari_agent/CustomServiceOrchestrator.py 
> 6ee929cb 
>   ambari-agent/src/main/python/ambari_agent/alerts/metric_alert.py aa4ad75 
>   ambari-agent/src/main/python/ambari_agent/alerts/script_alert.py 76afbc9 
>   ambari-agent/src/main/python/ambari_agent/alerts/web_alert.py b76d5e0 
>   ambari-agent/src/main/python/ambari_agent/security.py bfaf134 
>   ambari-agent/src/test/python/ambari_agent/TestCertGeneration.py d188dbd 
>   ambari-agent/src/test/python/ambari_agent/TestCustomServiceOrchestrator.py 
> 831ecce 
>   ambari-agent/src/test/python/ambari_agent/TestSecurity.py c47172a 
>   
> ambari-common/src/main/python/resource_management/libraries/script/script.py 
> a2c0c45 
>   ambari-server/src/main/python/bootstrap.py 98a3a93 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/namenode.py
>  1415367 
>   ambari-server/src/test/python/TestBootstrap.py 1fcb3ad 
> 
> Diff: https://reviews.apache.org/r/38353/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Andrew Onischuk
> 
>

[jira] [Resolved] (AMBARI-13087) test

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk resolved AMBARI-13087.
--
Resolution: Incomplete

> test
> 
>
> Key: AMBARI-13087
> URL: https://issues.apache.org/jira/browse/AMBARI-13087
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.1.2
>
>




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

[jira] [Created] (AMBARI-13085) Ambari fails to install Ranger, UI hangs, logs StackAdvisorRunner advisor script error

[Hari Sekhon (JIRA)]

Hari Sekhon created AMBARI-13085:


 Summary: Ambari fails to install Ranger, UI hangs, logs 
StackAdvisorRunner advisor script error
 Key: AMBARI-13085
 URL: https://issues.apache.org/jira/browse/AMBARI-13085
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server, ambari-web, security, stacks
Affects Versions: 2.1.0
 Environment: HDP 2.3 + Kerberos + Ranger 0.5
Reporter: Hari Sekhon
Priority: Blocker


When trying to deploy Ranger via Ambari after entering the red config settings 
until the Next button ungreys and clicking "next", and then "proceed anyway" 
(it recommended higher yarn memory settings which I had reduced to co-locate 
some other software) the Ambari UI returns to the config screen with the next 
button greyed out but no services show configuration requiring changes.

The ambari server log shows only:
{code}14 Sep 2015 10:32:08,337  INFO [qtp-client-5982] StackAdvisorRunner:71 -  
   advisor script stderr: {code}

But it doesn't show what the error was.

I'm attaching a screenshot showing there are no outstanding configs and yet the 
next button remains greyed out and nothing happens, Ambari just hangs.



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

[jira] [Resolved] (AMBARI-13073) Backport Request - Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in Kerberized cluster

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko resolved AMBARI-13073.
-
Resolution: Fixed

Committed to branch-2.0.maint

> Backport Request - Ambari is overwriting ownership of yarn.local.dir with 
> yarn:hadoop in Kerberized cluster
> ---
>
> Key: AMBARI-13073
> URL: https://issues.apache.org/jira/browse/AMBARI-13073
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.1.2
>
> Attachments: AMBARI-13073.patch
>
>
>  Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in 
> Kerberized cluster when it should be owned by running user . This happens at 
> restart of a nodemanager through Ambari. Only solution was to recreate 
> yarn.local.dir at which point it makes correct ownership of files. Restart 
> via Ambari then overwrites
> Need to backport AMBARI-12935 to 2.0.maint



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

[jira] [Commented] (AMBARI-13036) Enable JPA statement caching (internal/external)

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-13036:


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

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

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

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

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

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

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

This message is automatically generated.

> Enable JPA statement caching (internal/external)
> 
>
> Key: AMBARI-13036
> URL: https://issues.apache.org/jira/browse/AMBARI-13036
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: 2.1.1
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Attachments: AMBARI-13036.patch
>
>




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

[jira] [Commented] (AMBARI-13088) Kafka LogFlushStats metrics are missing

[Aleksandr Kovalenko (JIRA)]

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

Aleksandr Kovalenko commented on AMBARI-13088:
--

+1 for the patch

> Kafka LogFlushStats metrics are missing
> ---
>
> Key: AMBARI-13088
> URL: https://issues.apache.org/jira/browse/AMBARI-13088
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13088.patch
>
>
> Respond on request 
> {code}http://172.22.72.96:8080/api/v1/clusters/cl1/services/KAFKA/components/KAFKA_BROKER?fields=metrics/kafka/log/LogFlushStats/LogFlushRateAndTimeMs/1MinuteRate[1441953819,1441957419,15]{code}
>  doesn't contain any metrics {code}{
>   "href" : 
> "http://172.22.72.96:8080/api/v1/clusters/cl1/services/KAFKA/components/KAFKA_BROKER?fields=metrics/kafka/log/LogFlushStats/LogFlushRateAndTimeMs/1MinuteRate[1441953819,1441957419,15];,
>   "ServiceComponentInfo" : {
> "cluster_name" : "cl1",
> "component_name" : "KAFKA_BROKER",
> "service_name" : "KAFKA"
>   }
> }{code}



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

[jira] [Updated] (AMBARI-13089) Ambari seems to strip %Y %M %D, etc partitioning options from Flume output paths

[Vitaly Brodetskyi (JIRA)]

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

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

> Ambari seems to strip %Y %M %D, etc partitioning options from Flume output 
> paths
> 
>
> Key: AMBARI-13089
> URL: https://issues.apache.org/jira/browse/AMBARI-13089
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.0.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13089.patch
>
>
> Ambari seems to strip %Y %M %D, etc partitioning options from Flume output 
> paths.



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

[jira] [Updated] (AMBARI-13086) 500 error for API calls to /api/v1/clusters/

[Vitaly Brodetskyi (JIRA)]

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

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

> 500 error for API calls to /api/v1/clusters/
> -
>
> Key: AMBARI-13086
> URL: https://issues.apache.org/jira/browse/AMBARI-13086
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Blocker
> Fix For: 2.1.2
>
> Attachments: AMBARI-13086.patch
>
>
> Steps:
> # Deploy cluster.
> # Execute GET request to :8080/api/v1/clusters/.
> Result: was returned response:
> {code}
> {
>   "status": 500,
>   "message": "Server Error"
> }
> {code}
> *Ambari DB: :SQLAnywhere*
> *Oozie/Hive DB: SQLAnywhere/SQLAnywhere*
> From ambari-server.log:
> {code}
> 09 Sep 2015 11:01:04,490  WARN [qtp-client-210] ServletHandler:563 - 
> /api/v1/clusters/cl1
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to 
> java.lang.Number
> at 
> org.apache.ambari.server.orm.dao.AlertsDAO.findCurrentHostCounts(AlertsDAO.java:476)
> at 
> org.apache.ambari.server.orm.AmbariLocalSessionInterceptor.invoke(AmbariLocalSessionInterceptor.java:53)
> at 
> org.apache.ambari.server.controller.internal.AlertSummaryPropertyProvider.populateResource(AlertSummaryPropertyProvider.java:133)
> at 
> org.apache.ambari.server.controller.internal.AlertSummaryPropertyProvider.populateResources(AlertSummaryPropertyProvider.java:97)
> at 
> org.apache.ambari.server.controller.internal.ClusterControllerImpl.populateResources(ClusterControllerImpl.java:146)
> at 
> org.apache.ambari.server.api.query.QueryImpl.queryForResources(QueryImpl.java:407)
> at 
> org.apache.ambari.server.api.query.QueryImpl.execute(QueryImpl.java:217)
> at 
> org.apache.ambari.server.api.handlers.ReadHandler.handleRequest(ReadHandler.java:68)
> at 
> org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:135)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:105)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:74)
> at 
> org.apache.ambari.server.api.services.ClusterService.getCluster(ClusterService.java:94)
> at sun.reflect.GeneratedMethodAccessor240.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
> at 
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at 
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at 
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
> at 
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
> at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:540)
> at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:715)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)
> at 
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> at 
> 

Review Request 38353: Verify if restricting acls on /var/lib/ambari-agent/data will be OK

[Andrew Onischuk]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38353/
---

Review request for Ambari and Dmitro Lisnichenko.


Bugs: AMBARI-13087
https://issues.apache.org/jira/browse/AMBARI-13087


Repository: ambari


Description
---

**DO NOT CREATE AN EXTERNAL APACHE JIRA**  
Add the findings to this JIRA. This is a potential security issue and hence a
different process needs to be followed.

1\. the permissions of the /var/lib/ambari-agent/data folder is 0744. The data
folder contains output and error streams from all ambari agents’ commands. If
a script prints any of its parameters to the screen, such as passwords, either
while succeeding, or when an exception is thrown, then all users on the system
are able to read this data. Unless we’re mistaken, the correct permissions on
this folder should be 0700.

2\. The permissions of the /var/lib/ambari-agent/keys/.key private
key is set to 0644. This makes the private key of the ambari agent publically
readable. As far as we know, ambari agents talk to the server with SSL using
the key placed here (if SSL is enabled). We think that within a short amount
of time it is possible for any user on the system to craft the call to the
ambari server pretending to be the ambari agent heartbeat, and intercept all
configurations being sent to the ambari agent. These configurations contain
all parameters of the cluster, and are therefore prone to containing admin
passwords, it undermines the SSL encryption completely. Unless we’re mistaken,
the correct permissions should be 0600.

Further suggestions:  
chmod -R 0600 /var/lib/ambari-agent/data  
chmod -R a+X /var/lib/ambari-agent/data  
chmod -R a+rx /var/lib/ambari-agent/data/tmp  
chmod 0600 /var/lib/ambari-agent/keys/*.key

Ideally ambari would separate out this temporary directory and even smartly
review creation of files to be chowned to the correct user. These scripts
often are created from templates and may then also possibly contain passwords.

**DO NOT CREATE AN EXTERNAL APACHE JIRA**


Diffs
-

  ambari-agent/conf/unix/ambari-agent.ini abfde62 
  ambari-agent/conf/unix/install-helper.sh 48391d5 
  ambari-agent/pom.xml c2bee4a 
  ambari-agent/src/main/python/ambari_agent/Constants.py PRE-CREATION 
  ambari-agent/src/main/python/ambari_agent/CustomServiceOrchestrator.py 
6ee929cb 
  ambari-agent/src/main/python/ambari_agent/alerts/metric_alert.py aa4ad75 
  ambari-agent/src/main/python/ambari_agent/alerts/script_alert.py 76afbc9 
  ambari-agent/src/main/python/ambari_agent/alerts/web_alert.py b76d5e0 
  ambari-agent/src/main/python/ambari_agent/security.py bfaf134 
  ambari-agent/src/test/python/ambari_agent/TestCertGeneration.py d188dbd 
  ambari-agent/src/test/python/ambari_agent/TestCustomServiceOrchestrator.py 
831ecce 
  ambari-agent/src/test/python/ambari_agent/TestSecurity.py c47172a 
  ambari-common/src/main/python/resource_management/libraries/script/script.py 
a2c0c45 
  ambari-server/src/main/python/bootstrap.py 98a3a93 
  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/namenode.py
 1415367 
  ambari-server/src/test/python/TestBootstrap.py 1fcb3ad 

Diff: https://reviews.apache.org/r/38353/diff/


Testing
---

mvn clean test


Thanks,

Andrew Onischuk

[jira] [Created] (AMBARI-13087) Verify if restricting acls on /var/lib/ambari-agent/data will be OK

[Andrew Onischuk (JIRA)]

Andrew Onischuk created AMBARI-13087:


 Summary: Verify if restricting acls on /var/lib/ambari-agent/data 
will be OK
 Key: AMBARI-13087
 URL: https://issues.apache.org/jira/browse/AMBARI-13087
 Project: Ambari
  Issue Type: Bug
Reporter: Andrew Onischuk
Assignee: Andrew Onischuk
 Fix For: 2.1.2


**DO NOT CREATE AN EXTERNAL APACHE JIRA**  
Add the findings to this JIRA. This is a potential security issue and hence a
different process needs to be followed.

1\. the permissions of the /var/lib/ambari-agent/data folder is 0744. The data
folder contains output and error streams from all ambari agents’ commands. If
a script prints any of its parameters to the screen, such as passwords, either
while succeeding, or when an exception is thrown, then all users on the system
are able to read this data. Unless we’re mistaken, the correct permissions on
this folder should be 0700.

2\. The permissions of the /var/lib/ambari-agent/keys/.key private
key is set to 0644. This makes the private key of the ambari agent publically
readable. As far as we know, ambari agents talk to the server with SSL using
the key placed here (if SSL is enabled). We think that within a short amount
of time it is possible for any user on the system to craft the call to the
ambari server pretending to be the ambari agent heartbeat, and intercept all
configurations being sent to the ambari agent. These configurations contain
all parameters of the cluster, and are therefore prone to containing admin
passwords, it undermines the SSL encryption completely. Unless we’re mistaken,
the correct permissions should be 0600.

Further suggestions:  
chmod -R 0600 /var/lib/ambari-agent/data  
chmod -R a+X /var/lib/ambari-agent/data  
chmod -R a+rx /var/lib/ambari-agent/data/tmp  
chmod 0600 /var/lib/ambari-agent/keys/*.key

Ideally ambari would separate out this temporary directory and even smartly
review creation of files to be chowned to the correct user. These scripts
often are created from templates and may then also possibly contain passwords.

**DO NOT CREATE AN EXTERNAL APACHE JIRA**





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

[jira] [Commented] (AMBARI-13088) Kafka LogFlushStats metrics are missing

[Andrii Tkach (JIRA)]

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

Andrii Tkach commented on AMBARI-13088:
---

 6748 tests complete (12 seconds)
  94 tests pending

> Kafka LogFlushStats metrics are missing
> ---
>
> Key: AMBARI-13088
> URL: https://issues.apache.org/jira/browse/AMBARI-13088
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13088.patch
>
>
> Respond on request 
> {code}http://172.22.72.96:8080/api/v1/clusters/cl1/services/KAFKA/components/KAFKA_BROKER?fields=metrics/kafka/log/LogFlushStats/LogFlushRateAndTimeMs/1MinuteRate[1441953819,1441957419,15]{code}
>  doesn't contain any metrics {code}{
>   "href" : 
> "http://172.22.72.96:8080/api/v1/clusters/cl1/services/KAFKA/components/KAFKA_BROKER?fields=metrics/kafka/log/LogFlushStats/LogFlushRateAndTimeMs/1MinuteRate[1441953819,1441957419,15];,
>   "ServiceComponentInfo" : {
> "cluster_name" : "cl1",
> "component_name" : "KAFKA_BROKER",
> "service_name" : "KAFKA"
>   }
> }{code}



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

[jira] [Commented] (AMBARI-13088) Kafka LogFlushStats metrics are missing

[Andrii Tkach (JIRA)]

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

Andrii Tkach commented on AMBARI-13088:
---

committed to trunk and branch-2.1

> Kafka LogFlushStats metrics are missing
> ---
>
> Key: AMBARI-13088
> URL: https://issues.apache.org/jira/browse/AMBARI-13088
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13088.patch
>
>
> Respond on request 
> {code}http://172.22.72.96:8080/api/v1/clusters/cl1/services/KAFKA/components/KAFKA_BROKER?fields=metrics/kafka/log/LogFlushStats/LogFlushRateAndTimeMs/1MinuteRate[1441953819,1441957419,15]{code}
>  doesn't contain any metrics {code}{
>   "href" : 
> "http://172.22.72.96:8080/api/v1/clusters/cl1/services/KAFKA/components/KAFKA_BROKER?fields=metrics/kafka/log/LogFlushStats/LogFlushRateAndTimeMs/1MinuteRate[1441953819,1441957419,15];,
>   "ServiceComponentInfo" : {
> "cluster_name" : "cl1",
> "component_name" : "KAFKA_BROKER",
> "service_name" : "KAFKA"
>   }
> }{code}



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

[jira] [Updated] (AMBARI-13090) Ambari UI doesn't show correct cluster info

[Antonenko Alexander (JIRA)]

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

Antonenko Alexander updated AMBARI-13090:
-
Attachment: no-cluster-name.jpg
noclusternamepopup.jpg
reload-popup.jpg

> Ambari UI doesn't show correct cluster info
> ---
>
> Key: AMBARI-13090
> URL: https://issues.apache.org/jira/browse/AMBARI-13090
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 1.6.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: no-cluster-name.jpg, noclusternamepopup.jpg, 
> reload-popup.jpg
>
>
> PROBLEM: In versizon, after they fail to add some hosts to the cluster, they 
> cannot browse the cluster info in Ambari WebUI. It shows a page with only 
> cluster name and empty cluster info. The cluster name is not correct either, 
> it's my_cluster. But in the database, the cluster info is correct. 
> - We clear the web browser cache, and use different web browser IE, ff from 
> one host, it didn't help. 
> - But if someone from other host launch the Ambari UI with Chrome, it shows 
> correct info. 
> - Then we come back to the original host and launch the web UI using ff, it 
> shows the correct info again. 
> - I cannot reproduce this issue. 



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

[jira] [Updated] (AMBARI-13090) Ambari UI doesn't show correct cluster info

[Antonenko Alexander (JIRA)]

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

Antonenko Alexander updated AMBARI-13090:
-
Attachment: AMBARI-13090.patch

> Ambari UI doesn't show correct cluster info
> ---
>
> Key: AMBARI-13090
> URL: https://issues.apache.org/jira/browse/AMBARI-13090
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 1.6.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: AMBARI-13090.patch, no-cluster-name.jpg, 
> noclusternamepopup.jpg, reload-popup.jpg
>
>
> PROBLEM: In versizon, after they fail to add some hosts to the cluster, they 
> cannot browse the cluster info in Ambari WebUI. It shows a page with only 
> cluster name and empty cluster info. The cluster name is not correct either, 
> it's my_cluster. But in the database, the cluster info is correct. 
> - We clear the web browser cache, and use different web browser IE, ff from 
> one host, it didn't help. 
> - But if someone from other host launch the Ambari UI with Chrome, it shows 
> correct info. 
> - Then we come back to the original host and launch the web UI using ff, it 
> shows the correct info again. 
> - I cannot reproduce this issue. 



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

Re: Review Request 38354: Ambari seems to strip %Y %M %D, etc partitioning options from Flume output paths

[Andrew Onischuk]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38354/#review98841
---

Ship it!


Ship It!

- Andrew Onischuk


On Sept. 14, 2015, 1:17 p.m., Vitalyi Brodetskyi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38354/
> ---
> 
> (Updated Sept. 14, 2015, 1:17 p.m.)
> 
> 
> Review request for Ambari, Andrew Onischuk, Dmitro Lisnichenko, and Dmytro 
> Sen.
> 
> 
> Bugs: AMBARI-13089
> https://issues.apache.org/jira/browse/AMBARI-13089
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Ambari seems to strip %Y %M %D, etc partitioning options from Flume output 
> paths.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/package/scripts/flume.py
>  cff969f 
> 
> Diff: https://reviews.apache.org/r/38354/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Vitalyi Brodetskyi
> 
>

[jira] [Created] (AMBARI-13090) Ambari UI doesn't show correct cluster info

[Antonenko Alexander (JIRA)]

Antonenko Alexander created AMBARI-13090:


 Summary: Ambari UI doesn't show correct cluster info
 Key: AMBARI-13090
 URL: https://issues.apache.org/jira/browse/AMBARI-13090
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 1.6.1
Reporter: Antonenko Alexander
Assignee: Antonenko Alexander
Priority: Critical
 Fix For: 2.2.0


PROBLEM: In versizon, after they fail to add some hosts to the cluster, they 
cannot browse the cluster info in Ambari WebUI. It shows a page with only 
cluster name and empty cluster info. The cluster name is not correct either, 
it's my_cluster. But in the database, the cluster info is correct. 

- We clear the web browser cache, and use different web browser IE, ff from one 
host, it didn't help. 

- But if someone from other host launch the Ambari UI with Chrome, it shows 
correct info. 

- Then we come back to the original host and launch the web UI using ff, it 
shows the correct info again. 

- I cannot reproduce this issue. 



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

Re: Review Request 38314: leverage atlas configured port properties for server

[Sumit Mohanty]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38314/#review98846
---



ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py
 (line 66)


Probably works fine but wanted to make sure that True and False are indeed 
read as boolean and not string


- Sumit Mohanty


On Sept. 11, 2015, 8 p.m., Jonathan Maron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38314/
> ---
> 
> (Updated Sept. 11, 2015, 8 p.m.)
> 
> 
> Review request for Ambari, Erik Bergenholtz, Sumit Mohanty, and Srimanth 
> Gunturi.
> 
> 
> Bugs: AMBARI-12410
> https://issues.apache.org/jira/browse/AMBARI-12410
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Atlas now has persisted properties for both the HTTP and HTTPS listener 
> ports.  Rather than using the command line port option, change the service 
> definition to leverage these persisted properties.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/alerts.json 
> f324707 
>   
> ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/configuration/application-properties.xml
>  386fbdc 
>   
> ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/configuration/atlas-env.xml
>  991d7fe 
>   
> ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata_server.py
>  6c5a87e 
>   
> ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py
>  a7c6d7a 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
>  2783b78 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/services/HIVE/configuration/hive-site.xml
>  5811e4f 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py 
> dd287b2 
>   ambari-server/src/test/python/stacks/2.3/ATLAS/test_metadata_server.py 
> cff446f 
>   ambari-server/src/test/python/stacks/2.3/configs/default.json 688065c 
>   ambari-web/app/models/quick_links.js b1f95d6 
> 
> Diff: https://reviews.apache.org/r/38314/diff/
> 
> 
> Testing
> ---
> 
> python unit tests:
> 
> --
> Ran 230 tests in 6.879s
> 
> OK
> --
> Total run:784
> Total errors:0
> Total failures:0
> OK
> 
> Tested property change in an installed ambari cluster.
> 
> 
> Thanks,
> 
> Jonathan Maron
> 
>

[jira] [Commented] (AMBARI-13086) 500 error for API calls to /api/v1/clusters/

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13086:
-

FAILURE: Integrated in Ambari-branch-2.1 #528 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/528/])
AMBARI-13086. 500 error for API calls to 
/api/v1/clusters/.(vbrodetskyi) (vbrodetskyi: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=67d96d6d80d4443f7725931ea6062c3653f9d3d0)
* ambari-server/src/main/java/org/apache/ambari/server/orm/dao/AlertsDAO.java


> 500 error for API calls to /api/v1/clusters/
> -
>
> Key: AMBARI-13086
> URL: https://issues.apache.org/jira/browse/AMBARI-13086
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Blocker
> Fix For: 2.1.2
>
> Attachments: AMBARI-13086.patch
>
>
> Steps:
> # Deploy cluster.
> # Execute GET request to :8080/api/v1/clusters/.
> Result: was returned response:
> {code}
> {
>   "status": 500,
>   "message": "Server Error"
> }
> {code}
> *Ambari DB: :SQLAnywhere*
> *Oozie/Hive DB: SQLAnywhere/SQLAnywhere*
> From ambari-server.log:
> {code}
> 09 Sep 2015 11:01:04,490  WARN [qtp-client-210] ServletHandler:563 - 
> /api/v1/clusters/cl1
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to 
> java.lang.Number
> at 
> org.apache.ambari.server.orm.dao.AlertsDAO.findCurrentHostCounts(AlertsDAO.java:476)
> at 
> org.apache.ambari.server.orm.AmbariLocalSessionInterceptor.invoke(AmbariLocalSessionInterceptor.java:53)
> at 
> org.apache.ambari.server.controller.internal.AlertSummaryPropertyProvider.populateResource(AlertSummaryPropertyProvider.java:133)
> at 
> org.apache.ambari.server.controller.internal.AlertSummaryPropertyProvider.populateResources(AlertSummaryPropertyProvider.java:97)
> at 
> org.apache.ambari.server.controller.internal.ClusterControllerImpl.populateResources(ClusterControllerImpl.java:146)
> at 
> org.apache.ambari.server.api.query.QueryImpl.queryForResources(QueryImpl.java:407)
> at 
> org.apache.ambari.server.api.query.QueryImpl.execute(QueryImpl.java:217)
> at 
> org.apache.ambari.server.api.handlers.ReadHandler.handleRequest(ReadHandler.java:68)
> at 
> org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:135)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:105)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:74)
> at 
> org.apache.ambari.server.api.services.ClusterService.getCluster(ClusterService.java:94)
> at sun.reflect.GeneratedMethodAccessor240.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
> at 
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at 
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at 
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
> at 
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
> at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:540)
> at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:715)
> at 

[jira] [Commented] (AMBARI-13089) Ambari seems to strip %Y %M %D, etc partitioning options from Flume output paths

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13089:
-

FAILURE: Integrated in Ambari-branch-2.1 #528 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/528/])
AMBARI-13089. Ambari seems to strip %Y %M %D, etc partitioning options from 
Flume output paths.(vbrodetskyi) (vbrodetskyi: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=16713b8969cddfc74c5c412e120ae443b5283606)
* 
ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/package/scripts/flume.py


> Ambari seems to strip %Y %M %D, etc partitioning options from Flume output 
> paths
> 
>
> Key: AMBARI-13089
> URL: https://issues.apache.org/jira/browse/AMBARI-13089
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.0.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13089.patch
>
>
> Ambari seems to strip %Y %M %D, etc partitioning options from Flume output 
> paths.



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

Re: Review Request 38065: leverage stack advisor to manifest config changes in hive due to atlas availability

[John Speidel]

> On Sept. 14, 2015, 3:53 p.m., John Speidel wrote:
> > ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml,
> >  line 376
> > 
> >
> > this will require that this property is set by the user when deploying 
> > via a blueprint even if Atlas isn't installed.

just noticed that this has been closed.  I will file an Ambari Jira for this 
matter.


- John


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38065/#review98855
---


On Sept. 10, 2015, 9:59 p.m., Jonathan Maron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38065/
> ---
> 
> (Updated Sept. 10, 2015, 9:59 p.m.)
> 
> 
> Review request for Ambari, John Speidel, Sumit Mohanty, and Srimanth Gunturi.
> 
> 
> Bugs: AMBARI-12978
> https://issues.apache.org/jira/browse/AMBARI-12978
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Rather than make modifications that are not visible to the user via the 
> service scripts, the config changes that are required for hive when atlas is 
> available in the cluster have been moved to the stack advisor.  Some 
> important points:
> 
> 1)  atlas.cluster.name and atlas.rest.address are now configuration 
> properties that are defined in the service's hive-site.xml.  They therefore 
> appear as advanced hive-site properties in the UI.
> 2)  When atlas is not installed, these two properties are set to a space so 
> that hopefully no values are seen in the UI and the 'require-input' attribute 
> of atlas.cluster.name does not trigger a requirement to specify a value.
> 3)  When atlas is installed, the atlas.cluster.name is set to a null string 
> and the 'require-input' property appears to trigger the expected "value 
> required" logic in the UI.  This is important since the cluster name property 
> defines the namespace for the atlas queries associated with the given cluster 
> (atlas supports multiple hive instances).
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
>  f4e4b25 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
>  affee98 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py 
> c65e110 
>   ambari-server/src/test/python/stacks/2.3/common/test_stack_advisor.py 
> bea7d60 
> 
> Diff: https://reviews.apache.org/r/38065/diff/
> 
> 
> Testing
> ---
> 
> - python unit tests
> - installation of clusters:
> 1)  Hive only followed by addition of atlas
> 2)  hive and atlas together
> 
> (NOTE:  still working thru some of the functional cluster test scenarios but 
> wanted to proceed with a review process in parallel)
> 
> 
> Thanks,
> 
> Jonathan Maron
> 
>

[jira] [Resolved] (AMBARI-12410) atlas service definition needs to leverage persistent http/https port properties

[Sumit Mohanty (JIRA)]

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

Sumit Mohanty resolved AMBARI-12410.

Resolution: Fixed

Committed to trunk and branch-2.1

> atlas service definition needs to leverage persistent http/https port 
> properties
> 
>
> Key: AMBARI-12410
> URL: https://issues.apache.org/jira/browse/AMBARI-12410
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Reporter: Jonathan Maron
>Assignee: Jonathan Maron
> Fix For: 2.1.2
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> There are now persistent port properties for atlas.  Instead of leveraging 
> the '--port' command line option, the atlas scripts should be modified to 
> leverage these properties for designating the port to be leveraged.



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

[jira] [Commented] (AMBARI-13088) Kafka LogFlushStats metrics are missing

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13088:
-

SUCCESS: Integrated in Ambari-trunk-Commit #3438 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3438/])
AMBARI-13088 Kafka LogFlushStats metrics are missing. (atkach) (atkach: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=8aac1802ad3aa62666f99cc558b892b45efadfbc)
* ambari-web/app/views/main/service/info/metrics/kafka/kafka_log_flush.js
* ambari-web/app/data/service_graph_config.js
* ambari-server/src/main/resources/stacks/HDP/2.3/services/KAFKA/metrics.json
* ambari-web/app/views.js


> Kafka LogFlushStats metrics are missing
> ---
>
> Key: AMBARI-13088
> URL: https://issues.apache.org/jira/browse/AMBARI-13088
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13088.patch
>
>
> Respond on request 
> {code}http://172.22.72.96:8080/api/v1/clusters/cl1/services/KAFKA/components/KAFKA_BROKER?fields=metrics/kafka/log/LogFlushStats/LogFlushRateAndTimeMs/1MinuteRate[1441953819,1441957419,15]{code}
>  doesn't contain any metrics {code}{
>   "href" : 
> "http://172.22.72.96:8080/api/v1/clusters/cl1/services/KAFKA/components/KAFKA_BROKER?fields=metrics/kafka/log/LogFlushStats/LogFlushRateAndTimeMs/1MinuteRate[1441953819,1441957419,15];,
>   "ServiceComponentInfo" : {
> "cluster_name" : "cl1",
> "component_name" : "KAFKA_BROKER",
> "service_name" : "KAFKA"
>   }
> }{code}



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

[jira] [Commented] (AMBARI-13089) Ambari seems to strip %Y %M %D, etc partitioning options from Flume output paths

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13089:
-

SUCCESS: Integrated in Ambari-trunk-Commit #3438 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3438/])
AMBARI-13089. Ambari seems to strip %Y %M %D, etc partitioning options from 
Flume output paths.(vbrodetskyi) (vbrodetskyi: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=0397d527fb527535cfa0a27b114c93a3d96685fb)
* 
ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/package/scripts/flume.py


> Ambari seems to strip %Y %M %D, etc partitioning options from Flume output 
> paths
> 
>
> Key: AMBARI-13089
> URL: https://issues.apache.org/jira/browse/AMBARI-13089
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.0.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13089.patch
>
>
> Ambari seems to strip %Y %M %D, etc partitioning options from Flume output 
> paths.



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

[jira] [Commented] (AMBARI-13038) Define ephemeral port range for Ambari agents

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-13038:


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

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

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

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

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

{color:green}+1 core tests{color}.  The patch passed unit tests in .

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

This message is automatically generated.

> Define ephemeral port range for Ambari agents
> -
>
> Key: AMBARI-13038
> URL: https://issues.apache.org/jira/browse/AMBARI-13038
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: 2.1.0
> Environment: All
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Attachments: AMBARI-13038.patch
>
>
> Problem: 
> When Ambari agent starts,it tries to use an ephemeral port that is already in 
> use by another component.
> Steps to Reproduce:
> 1. Install a cluster with Ambari
> 2. Restart the Ambari agent until it takes a port in use by another service
> Solution:
> Range of ephemeral ports used by Ambari should be narrowed. (configurable)



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

[jira] [Commented] (AMBARI-13086) 500 error for API calls to /api/v1/clusters/

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13086:
-

SUCCESS: Integrated in Ambari-trunk-Commit #3438 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3438/])
AMBARI-13086. 500 error for API calls to 
/api/v1/clusters/.(vbrodetskyi) (vbrodetskyi: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=f68b0f0251e52d1a5dbd58e0fdc88aae1c940f75)
* ambari-server/src/main/java/org/apache/ambari/server/orm/dao/AlertsDAO.java


> 500 error for API calls to /api/v1/clusters/
> -
>
> Key: AMBARI-13086
> URL: https://issues.apache.org/jira/browse/AMBARI-13086
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Blocker
> Fix For: 2.1.2
>
> Attachments: AMBARI-13086.patch
>
>
> Steps:
> # Deploy cluster.
> # Execute GET request to :8080/api/v1/clusters/.
> Result: was returned response:
> {code}
> {
>   "status": 500,
>   "message": "Server Error"
> }
> {code}
> *Ambari DB: :SQLAnywhere*
> *Oozie/Hive DB: SQLAnywhere/SQLAnywhere*
> From ambari-server.log:
> {code}
> 09 Sep 2015 11:01:04,490  WARN [qtp-client-210] ServletHandler:563 - 
> /api/v1/clusters/cl1
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to 
> java.lang.Number
> at 
> org.apache.ambari.server.orm.dao.AlertsDAO.findCurrentHostCounts(AlertsDAO.java:476)
> at 
> org.apache.ambari.server.orm.AmbariLocalSessionInterceptor.invoke(AmbariLocalSessionInterceptor.java:53)
> at 
> org.apache.ambari.server.controller.internal.AlertSummaryPropertyProvider.populateResource(AlertSummaryPropertyProvider.java:133)
> at 
> org.apache.ambari.server.controller.internal.AlertSummaryPropertyProvider.populateResources(AlertSummaryPropertyProvider.java:97)
> at 
> org.apache.ambari.server.controller.internal.ClusterControllerImpl.populateResources(ClusterControllerImpl.java:146)
> at 
> org.apache.ambari.server.api.query.QueryImpl.queryForResources(QueryImpl.java:407)
> at 
> org.apache.ambari.server.api.query.QueryImpl.execute(QueryImpl.java:217)
> at 
> org.apache.ambari.server.api.handlers.ReadHandler.handleRequest(ReadHandler.java:68)
> at 
> org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:135)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:105)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:74)
> at 
> org.apache.ambari.server.api.services.ClusterService.getCluster(ClusterService.java:94)
> at sun.reflect.GeneratedMethodAccessor240.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
> at 
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at 
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at 
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
> at 
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
> at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:540)
> at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:715)
> at 

[jira] [Commented] (AMBARI-13088) Kafka LogFlushStats metrics are missing

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13088:
-

FAILURE: Integrated in Ambari-branch-2.1 #528 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/528/])
AMBARI-13088 Kafka LogFlushStats metrics are missing. (atkach) (atkach: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=8630725ca66d8aee480f1a6e2c04ca5788ff953d)
* ambari-server/src/main/resources/stacks/HDP/2.3/services/KAFKA/metrics.json
* ambari-web/app/views/main/service/info/metrics/kafka/kafka_log_flush.js
* ambari-web/app/data/service_graph_config.js
* ambari-web/app/views.js


> Kafka LogFlushStats metrics are missing
> ---
>
> Key: AMBARI-13088
> URL: https://issues.apache.org/jira/browse/AMBARI-13088
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13088.patch
>
>
> Respond on request 
> {code}http://172.22.72.96:8080/api/v1/clusters/cl1/services/KAFKA/components/KAFKA_BROKER?fields=metrics/kafka/log/LogFlushStats/LogFlushRateAndTimeMs/1MinuteRate[1441953819,1441957419,15]{code}
>  doesn't contain any metrics {code}{
>   "href" : 
> "http://172.22.72.96:8080/api/v1/clusters/cl1/services/KAFKA/components/KAFKA_BROKER?fields=metrics/kafka/log/LogFlushStats/LogFlushRateAndTimeMs/1MinuteRate[1441953819,1441957419,15];,
>   "ServiceComponentInfo" : {
> "cluster_name" : "cl1",
> "component_name" : "KAFKA_BROKER",
> "service_name" : "KAFKA"
>   }
> }{code}



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

Review Request 38356: Upgrade AMS Phoenix + HBase to HDP-2.3.2.0

[Dmytro Sen]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38356/
---

Review request for Ambari, Myroslav Papirkovskyy and Sid Wagle.


Bugs: AMBARI-13091
https://issues.apache.org/jira/browse/AMBARI-13091


Repository: ambari


Description
---

AMS still uses HDP-2.2 bits for HBase, Phoenix and Hadoop Common.
Several important fixes specially perf related went into Phoenix and HBase 
during HDP-2.3.2.0 time frame.


Diffs
-

  ambari-metrics/ambari-metrics-timelineservice/pom.xml 705ea0f 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/ApplicationHistoryClientService.java
 a12e373 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/ApplicationHistoryManager.java
 db25d29 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/ApplicationHistoryManagerImpl.java
 386a9f1 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/ApplicationHistoryServer.java
 24223a5 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/AHSWebApp.java
 8cff741 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/AHSWebServices.java
 2040f57 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/TestApplicationHistoryManagerOnTimelineStore.java
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/AbstractMiniHBaseClusterTest.java
 442dbf5 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TestAHSWebApp.java
 5f23f83 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TestAHSWebServices.java
 7ca5a03 
  ambari-metrics/pom.xml 27d8347 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/metrics.json
 6131606 

Diff: https://reviews.apache.org/r/38356/diff/


Testing
---

In progress


Thanks,

Dmytro Sen

Re: Review Request 38065: leverage stack advisor to manifest config changes in hive due to atlas availability

[John Speidel]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38065/#review98855
---



ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
 (line 376)


this will require that this property is set by the user when deploying via 
a blueprint even if Atlas isn't installed.


- John Speidel


On Sept. 10, 2015, 9:59 p.m., Jonathan Maron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38065/
> ---
> 
> (Updated Sept. 10, 2015, 9:59 p.m.)
> 
> 
> Review request for Ambari, John Speidel, Sumit Mohanty, and Srimanth Gunturi.
> 
> 
> Bugs: AMBARI-12978
> https://issues.apache.org/jira/browse/AMBARI-12978
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Rather than make modifications that are not visible to the user via the 
> service scripts, the config changes that are required for hive when atlas is 
> available in the cluster have been moved to the stack advisor.  Some 
> important points:
> 
> 1)  atlas.cluster.name and atlas.rest.address are now configuration 
> properties that are defined in the service's hive-site.xml.  They therefore 
> appear as advanced hive-site properties in the UI.
> 2)  When atlas is not installed, these two properties are set to a space so 
> that hopefully no values are seen in the UI and the 'require-input' attribute 
> of atlas.cluster.name does not trigger a requirement to specify a value.
> 3)  When atlas is installed, the atlas.cluster.name is set to a null string 
> and the 'require-input' property appears to trigger the expected "value 
> required" logic in the UI.  This is important since the cluster name property 
> defines the namespace for the atlas queries associated with the given cluster 
> (atlas supports multiple hive instances).
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
>  f4e4b25 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
>  affee98 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py 
> c65e110 
>   ambari-server/src/test/python/stacks/2.3/common/test_stack_advisor.py 
> bea7d60 
> 
> Diff: https://reviews.apache.org/r/38065/diff/
> 
> 
> Testing
> ---
> 
> - python unit tests
> - installation of clusters:
> 1)  Hive only followed by addition of atlas
> 2)  hive and atlas together
> 
> (NOTE:  still working thru some of the functional cluster test scenarios but 
> wanted to proceed with a review process in parallel)
> 
> 
> Thanks,
> 
> Jonathan Maron
> 
>

[jira] [Updated] (AMBARI-13091) Upgrade AMS Phoenix + HBase to HDP-2.3.2.0

[Dmytro Sen (JIRA)]

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

Dmytro Sen updated AMBARI-13091:

Attachment: AMBARI-13091.patch

> Upgrade AMS Phoenix + HBase to HDP-2.3.2.0
> --
>
> Key: AMBARI-13091
> URL: https://issues.apache.org/jira/browse/AMBARI-13091
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-metrics
>Affects Versions: 2.1.2
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13091.patch
>
>
> AMS still uses HDP-2.2 bits for HBase, Phoenix and Hadoop Common.
> Several important fixes specially perf related went into Phoenix and HBase 
> during HDP-2.3.2.0 time frame.



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

[jira] [Created] (AMBARI-13091) Upgrade AMS Phoenix + HBase to HDP-2.3.2.0

[Dmytro Sen (JIRA)]

Dmytro Sen created AMBARI-13091:
---

 Summary: Upgrade AMS Phoenix + HBase to HDP-2.3.2.0
 Key: AMBARI-13091
 URL: https://issues.apache.org/jira/browse/AMBARI-13091
 Project: Ambari
  Issue Type: Task
  Components: ambari-metrics
Affects Versions: 2.1.2
Reporter: Dmytro Sen
Assignee: Dmytro Sen
Priority: Critical
 Fix For: 2.1.2


AMS still uses HDP-2.2 bits for HBase, Phoenix and Hadoop Common.
Several important fixes specially perf related went into Phoenix and HBase 
during HDP-2.3.2.0 time frame.



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

Re: Review Request 38318: Kerberos: Allow user to specify additional realms for auth-to-local rules

[Robert Nettleton]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38318/#review98864
---

Ship it!


Looks fine to me.  Just a minor issue below.


ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/kerberos.json 


Why is this property being removed from the HDFS kerberos.json?  Is this 
related to the support for multiple realms described above?


- Robert Nettleton


On Sept. 13, 2015, 11:31 a.m., Robert Levas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38318/
> ---
> 
> (Updated Sept. 13, 2015, 11:31 a.m.)
> 
> 
> Review request for Ambari, Jaimin Jetly, Jonathan Hurley, and Robert 
> Nettleton.
> 
> 
> Bugs: AMBARI-13060
> https://issues.apache.org/jira/browse/AMBARI-13060
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Allow user to specify additional realms for auth-to-local rules. This will 
> add _default_ rules for the specified realm(s) to the generated auth-to-local 
> rule sets. For example:
> 
> ```
> RULE:[1:$1@$0](.*@USER_REALM.COM)s/@.*//
> ```
> 
> The value should be a (comma) delimited list of realm names set in set of 
> global properties in the Kerberos Descriptor.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AuthToLocalBuilder.java
>  00e8291 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
>  11f578f 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/kerberos.json 
> df99bce 
>   ambari-server/src/main/resources/stacks/HDP/2.0.6/kerberos.json 03198dc 
>   
> ambari-server/src/test/java/org/apache/ambari/server/api/services/AmbariMetaInfoTest.java
>  14c66a2 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/AuthToLocalBuilderTest.java
>  9e65b5e 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
>  f28a19b 
>   ambari-server/src/test/resources/stacks/HDP/2.0.8/kerberos.json cf49786 
>   ambari-web/app/mixins/wizard/addSecurityConfigs.js d14d09e 
> 
> Diff: https://reviews.apache.org/r/38318/diff/
> 
> 
> Testing
> ---
> 
> Manually tested existing KDC and manual options, both with various additional 
> realm specifications (empty, single, multiple, multiple with random spaces 
> between). Updated realms after enabling Kerberos.
> 
> Local test results: PASSED
> 
> Jenkins test results:
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 02:03 h
> [INFO] Finished at: 2015-09-12T00:12:36+00:00
> [INFO] Final Memory: 50M/555M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Robert Levas
> 
>

[jira] [Commented] (AMBARI-13090) Ambari UI doesn't show correct cluster info

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13090:
-

FAILURE: Integrated in Ambari-trunk-Commit #3439 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3439/])
AMBARI-13090. Ambari UI doesn't show correct cluster info (alexantonenko) 
(hiveww: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=a7152651ba1e4bb5b6ae201d62491e2f944f9f8f)
* ambari-web/test/mixins/common/reload_popup_test.js
* ambari-web/app/mixins/common/reload_popup.js
* ambari-web/app/messages.js
* ambari-web/app/controllers/global/cluster_controller.js
* ambari-web/test/controllers/global/cluster_controller_test.js


> Ambari UI doesn't show correct cluster info
> ---
>
> Key: AMBARI-13090
> URL: https://issues.apache.org/jira/browse/AMBARI-13090
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 1.6.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: AMBARI-13090.patch, no-cluster-name.jpg, 
> noclusternamepopup.jpg, reload-popup.jpg
>
>
> PROBLEM: In versizon, after they fail to add some hosts to the cluster, they 
> cannot browse the cluster info in Ambari WebUI. It shows a page with only 
> cluster name and empty cluster info. The cluster name is not correct either, 
> it's my_cluster. But in the database, the cluster info is correct. 
> - We clear the web browser cache, and use different web browser IE, ff from 
> one host, it didn't help. 
> - But if someone from other host launch the Ambari UI with Chrome, it shows 
> correct info. 
> - Then we come back to the original host and launch the web UI using ff, it 
> shows the correct info again. 
> - I cannot reproduce this issue. 



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

[jira] [Commented] (AMBARI-12410) atlas service definition needs to leverage persistent http/https port properties

[Hudson (JIRA)]

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

Hudson commented on AMBARI-12410:
-

FAILURE: Integrated in Ambari-trunk-Commit #3439 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3439/])
AMBARI-12410. Leverage atlas configured port properties for server (Jon Maron 
via smohanty) (smohanty: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=91885add8113782a3c399fca8715065d02419d4e)
* ambari-server/src/test/python/stacks/2.3/ATLAS/test_metadata_server.py
* ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/HIVE/configuration/hive-site.xml
* ambari-web/app/models/quick_links.js
* ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/alerts.json
* 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/configuration/atlas-env.xml
* ambari-server/src/test/python/stacks/2.3/configs/default.json
* 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata_server.py
* 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py
* 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/configuration/application-properties.xml
* 
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml


> atlas service definition needs to leverage persistent http/https port 
> properties
> 
>
> Key: AMBARI-12410
> URL: https://issues.apache.org/jira/browse/AMBARI-12410
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Reporter: Jonathan Maron
>Assignee: Jonathan Maron
> Fix For: 2.1.2
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> There are now persistent port properties for atlas.  Instead of leveraging 
> the '--port' command line option, the atlas scripts should be modified to 
> leverage these properties for designating the port to be leveraged.



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

[jira] [Created] (AMBARI-13092) After page refresh created config groups are showed with delay

[Antonenko Alexander (JIRA)]

Antonenko Alexander created AMBARI-13092:


 Summary: After page refresh created config groups are showed with 
delay
 Key: AMBARI-13092
 URL: https://issues.apache.org/jira/browse/AMBARI-13092
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.2.0
Reporter: Antonenko Alexander
Assignee: Antonenko Alexander
Priority: Critical
 Fix For: 2.1.2


STR:
 Create config group
 Refresh page
 Click to change config group

Config groups that you created are missing in the list. They will be loaded 
with delay (couple of seconds)





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

[jira] [Updated] (AMBARI-13092) After page refresh created config groups are showed with delay

[Antonenko Alexander (JIRA)]

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

Antonenko Alexander updated AMBARI-13092:
-
Affects Version/s: (was: 2.2.0)
   2.1.2

> After page refresh created config groups are showed with delay
> --
>
> Key: AMBARI-13092
> URL: https://issues.apache.org/jira/browse/AMBARI-13092
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.1.2
>
>
> STR:
>  Create config group
>  Refresh page
>  Click to change config group
> Config groups that you created are missing in the list. They will be loaded 
> with delay (couple of seconds)



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

[jira] [Commented] (AMBARI-13092) After page refresh created config groups are showed with delay

[Aleksandr Kovalenko (JIRA)]

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

Aleksandr Kovalenko commented on AMBARI-13092:
--

+1 for the patch

> After page refresh created config groups are showed with delay
> --
>
> Key: AMBARI-13092
> URL: https://issues.apache.org/jira/browse/AMBARI-13092
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13092.patch
>
>
> STR:
>  Create config group
>  Refresh page
>  Click to change config group
> Config groups that you created are missing in the list. They will be loaded 
> with delay (couple of seconds)



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

[jira] [Updated] (AMBARI-13092) After page refresh created config groups are showed with delay

[Antonenko Alexander (JIRA)]

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

Antonenko Alexander updated AMBARI-13092:
-
Attachment: AMBARI-13092.patch

> After page refresh created config groups are showed with delay
> --
>
> Key: AMBARI-13092
> URL: https://issues.apache.org/jira/browse/AMBARI-13092
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13092.patch
>
>
> STR:
>  Create config group
>  Refresh page
>  Click to change config group
> Config groups that you created are missing in the list. They will be loaded 
> with delay (couple of seconds)



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

Re: Review Request 38318: Kerberos: Allow user to specify additional realms for auth-to-local rules

[Robert Levas]

> On Sept. 14, 2015, 12:56 p.m., Robert Nettleton wrote:
> > ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/kerberos.json,
> >  line 48
> > 
> >
> > Why is this property being removed from the HDFS kerberos.json?  Is 
> > this related to the support for multiple realms described above?

`hadoop.security.auth_to_local` is being removed from the kerberos.json file 
becuase it was the reason this issue exists.  It's existance was causing 
confusion on the front-end since it appeared that the auth-to-local propery was 
to be set to "" rathen than to its actual value (which was to get generated by 
Ambari).  It's use was to set some initial value so that Ambari would include 
it when generating the `core-site/hadoop.security.auth_to_local` value. 
Generally that value was default rules for addtional realms needed in a 
multiple realm scenario - for example, MIT KDC and Active Directory 
cross-realm-trust. Though this worked fine, it had 2 problems: confusion (as 
previously mentioned), and it's scope was limited to 
`core-site/hadoop.security.auth_to_local`.

This patch solves the 2 issues by removing the field in the UI and adding a new 
property to collect the additional realms. Using the additional realms data, 
the default rules can be generated and used for any property that is tagged as 
being an _auth-to-local rule_ (this is done on the Kerberos Descriptor for each 
service).


- Robert


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38318/#review98864
---


On Sept. 13, 2015, 7:31 a.m., Robert Levas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38318/
> ---
> 
> (Updated Sept. 13, 2015, 7:31 a.m.)
> 
> 
> Review request for Ambari, Jaimin Jetly, Jonathan Hurley, and Robert 
> Nettleton.
> 
> 
> Bugs: AMBARI-13060
> https://issues.apache.org/jira/browse/AMBARI-13060
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Allow user to specify additional realms for auth-to-local rules. This will 
> add _default_ rules for the specified realm(s) to the generated auth-to-local 
> rule sets. For example:
> 
> ```
> RULE:[1:$1@$0](.*@USER_REALM.COM)s/@.*//
> ```
> 
> The value should be a (comma) delimited list of realm names set in set of 
> global properties in the Kerberos Descriptor.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AuthToLocalBuilder.java
>  00e8291 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
>  11f578f 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/kerberos.json 
> df99bce 
>   ambari-server/src/main/resources/stacks/HDP/2.0.6/kerberos.json 03198dc 
>   
> ambari-server/src/test/java/org/apache/ambari/server/api/services/AmbariMetaInfoTest.java
>  14c66a2 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/AuthToLocalBuilderTest.java
>  9e65b5e 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
>  f28a19b 
>   ambari-server/src/test/resources/stacks/HDP/2.0.8/kerberos.json cf49786 
>   ambari-web/app/mixins/wizard/addSecurityConfigs.js d14d09e 
> 
> Diff: https://reviews.apache.org/r/38318/diff/
> 
> 
> Testing
> ---
> 
> Manually tested existing KDC and manual options, both with various additional 
> realm specifications (empty, single, multiple, multiple with random spaces 
> between). Updated realms after enabling Kerberos.
> 
> Local test results: PASSED
> 
> Jenkins test results:
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 02:03 h
> [INFO] Finished at: 2015-09-12T00:12:36+00:00
> [INFO] Final Memory: 50M/555M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Robert Levas
> 
>

[jira] [Commented] (AMBARI-12410) atlas service definition needs to leverage persistent http/https port properties

[Hudson (JIRA)]

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

Hudson commented on AMBARI-12410:
-

FAILURE: Integrated in Ambari-branch-2.1 #529 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/529/])
AMBARI-12410. Leverage atlas configured port properties for server (Jon Maron 
via smohanty) (smohanty: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=973831b1ddd16bee25b5bfef4099817a8a14eece)
* ambari-server/src/test/python/stacks/2.3/configs/default.json
* ambari-server/src/test/python/stacks/2.3/ATLAS/test_metadata_server.py
* 
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/HIVE/configuration/hive-site.xml
* 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata_server.py
* 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/configuration/atlas-env.xml
* 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/configuration/application-properties.xml
* ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py
* ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/alerts.json
* ambari-web/app/models/quick_links.js
* 
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py


> atlas service definition needs to leverage persistent http/https port 
> properties
> 
>
> Key: AMBARI-12410
> URL: https://issues.apache.org/jira/browse/AMBARI-12410
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Reporter: Jonathan Maron
>Assignee: Jonathan Maron
> Fix For: 2.1.2
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> There are now persistent port properties for atlas.  Instead of leveraging 
> the '--port' command line option, the atlas scripts should be modified to 
> leverage these properties for designating the port to be leveraged.



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

Re: Review Request 38269: AMBARI-12949: Downgrade fails with err: 500 status code received on POST method for API: /api/vi/clusters/mycluster/upgrades

[Alejandro Fernandez]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38269/#review98871
---


This looks good. Thank you for the contribution.
Please also include Nate Cole and Jonathan Hurley in the code review.


ambari-server/src/main/java/org/apache/ambari/server/orm/dao/ClusterDAO.java 
(line 190)


If this is no longer used, can remove it.



ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ClusterConfigEntity.java
 (line 54)


If this is no longer used, can remove it.



ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
 (line 2845)


Can remove this.



ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
 (line 2867)


Typo, has => have.
Let's change the logging level to ERROR, and note that it was in the 
"applyLatestConfigurations" method.



ambari-server/src/test/java/org/apache/ambari/server/orm/dao/ServiceConfigDAOTest.java
 (line 346)


Please add some doc outlining the situation this is testing.


- Alejandro Fernandez


On Sept. 10, 2015, 9:37 p.m., Di Li wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38269/
> ---
> 
> (Updated Sept. 10, 2015, 9:37 p.m.)
> 
> 
> Review request for Ambari and Alejandro Fernandez.
> 
> 
> Bugs: AMBARI-12949
> https://issues.apache.org/jira/browse/AMBARI-12949
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This seems to be an issue that happens when the "latest" configuration stored 
> in the "clusterconfig" table is for a conf group instead of the default 
> configurations. The named query 
> "ClusterConfigEntity.findLatestConfigsByStack" returns the latest 
> configuration to be set with "selected = 1" in the clusterconfigmapping 
> table. When the "latest" config is for a conf group, this record will not 
> have a corresponding entry in the clusterconfigmapping table. So the 
> clusterconfigmapping table is left with a type that does not have the 
> selected column set to 1.
> 
> My proposed fix is the new named query 
> "ClusterConfigEntity.findLatestConfigsOfClusterConfigMappingEntriesByStack" 
> in ClusterConfigEntity.java, which searches the clusterconfig table for the 
> latest version of a type_name and version_tag specified in the 
> clusterconfigmapping table. This is different from the current 
> "ClusterConfigEntity.findLatestConfigsByStack" query, which simply pulls the 
> latest config of a type_name from the clusterconfig table regardless whether 
> the corresponding version_tag is in the clusterconfigmapping table or not.
> 
> 
> Investigation:
> 
> I used Oozie for debugging.
> 
> When a user clicks the Downgrade button from the Finalize page. The request 
> eventually hits ClusterImpl.applyLatestConfigurations method where the Ambari 
> server updates the database to reverse back to the "latest" configuration of 
> each type for the older stack (HDP 2.2)
> 
> The workflow goes as
> 1. Set ALL entries in clusterconfigmapping table to have selected value set 
> to 0
> 2. Ambari server uses ClusterImpl.applyLatestConfigurations method to get the 
> "latest" configuration of each type for the older stack (HDP 2.2)
> 3. Loop through all the entries in the clusterconfigmapping table, and set 
> the selected to 1 if this entry also happens to be in the "latest" 
> configuration returned in step 2.
> 
> The ClusterImpl.applyLatestConfigurations method calls ClusterDAO.java 
> getLatestConfigurations to get the latest configuration for each type for the 
> older stack. The DAO class simply runs the following SQL query (cluster id 
> and stack id are the parameters) and passes the results back.
> 
> SELECT clusterConfig1 FROM clusterconfig clusterConfig1 WHERE 
> clusterConfig1.cluster_id='2' AND clusterConfig1.create_timestamp = (SELECT 
> MAX(clusterConfig2.create_timestamp) FROM clusterconfig clusterConfig2 WHERE 
> clusterConfig2.cluster_id='2' AND clusterConfig2.stack_id= '3' AND 
> clusterConfig2.type_name = clusterConfig1.type_name);
> 
> For downgrade, in our particular use case, the oozie-env configuration stored 
> in the clusterconfig table, when the stack id is the HDP 2.2 version, only 
> contains TWO conf, the original version1 and the one for the config group.
> 
> The query above will return the entry corresponding to the oozie config 
> group, as it was the last configuration entry added to the clusterconfig 
> table for oozie-site with stack id = 3. 

Re: Review Request 38356: Upgrade AMS Phoenix + HBase to HDP-2.3.2.0

[Sid Wagle]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38356/#review98873
---

Ship it!



ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/TestApplicationHistoryManagerOnTimelineStore.java
 (line 1)


Are these test ported over from YARN - ATS code?
The intention is to turn off any feature we do not use for AMS that could 
cause overhead. Unit tests are harmless but something like a TimelineStore 
would be. In the current impl we make sure to turn off the LevelDB store, is 
that still the case?


- Sid Wagle


On Sept. 14, 2015, 4:02 p.m., Dmytro Sen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38356/
> ---
> 
> (Updated Sept. 14, 2015, 4:02 p.m.)
> 
> 
> Review request for Ambari, Myroslav Papirkovskyy and Sid Wagle.
> 
> 
> Bugs: AMBARI-13091
> https://issues.apache.org/jira/browse/AMBARI-13091
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> AMS still uses HDP-2.2 bits for HBase, Phoenix and Hadoop Common.
> Several important fixes specially perf related went into Phoenix and HBase 
> during HDP-2.3.2.0 time frame.
> 
> 
> Diffs
> -
> 
>   ambari-metrics/ambari-metrics-timelineservice/pom.xml 705ea0f 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/ApplicationHistoryClientService.java
>  a12e373 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/ApplicationHistoryManager.java
>  db25d29 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/ApplicationHistoryManagerImpl.java
>  386a9f1 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/ApplicationHistoryServer.java
>  24223a5 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/AHSWebApp.java
>  8cff741 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/AHSWebServices.java
>  2040f57 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/TestApplicationHistoryManagerOnTimelineStore.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/AbstractMiniHBaseClusterTest.java
>  442dbf5 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TestAHSWebApp.java
>  5f23f83 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TestAHSWebServices.java
>  7ca5a03 
>   ambari-metrics/pom.xml 27d8347 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/metrics.json
>  6131606 
> 
> Diff: https://reviews.apache.org/r/38356/diff/
> 
> 
> Testing
> ---
> 
> In progress
> 
> 
> Thanks,
> 
> Dmytro Sen
> 
>

[jira] [Updated] (AMBARI-12877) File Browser view - Downloading a directory always creates a zip with name hdfs.zip

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-12877:
-
Assignee: Nitiraj Singh Rathore

> File Browser view - Downloading a directory always creates a zip with name 
> hdfs.zip
> ---
>
> Key: AMBARI-12877
> URL: https://issues.apache.org/jira/browse/AMBARI-12877
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.1.0
>Reporter: Nitiraj Singh Rathore
>Assignee: Nitiraj Singh Rathore
>  Labels: patch
> Fix For: 2.1.2
>
> Attachments: zipfile_name_file_view.patch
>
>
> Create a directory using FIle browser view. Try to download it , it always 
> gets downloaded with hdfs.zip -- instead of the file name. 
> It is much better if the zip is named after the directory that gets zipped 
> instead of the user how owns it.
> Repro:
> 1) create test1 and test2 directories
> 2) click on download icon
> 3) both directories will be downloaded as hdfs.zip
> Resolution : 
> If multiple files/folders are downloaded then the zip file name should be 
> hdfs.zip . But if single file or folder is downloaded then it should be named 
> after the downloaded file.



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

[jira] [Updated] (AMBARI-12967) Make HDFS username portion of the checkpoint command description dynamic

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-12967:
-
Assignee: Xi Wang

> Make HDFS username portion of the checkpoint command description dynamic
> 
>
> Key: AMBARI-12967
> URL: https://issues.apache.org/jira/browse/AMBARI-12967
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-12967.patch
>
>
> In AMBARI-12951, a list of commands will show up if the last check point is 
> too old.
> In the command to create new check point, the HDFS username portion should be 
> dynamic because user can customize HDFS username.



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

[jira] [Updated] (AMBARI-12538) Attempting to access the Ambari Dashboard results in an HTTP 500 Error after changing cluster name and restarting the Ambari server

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-12538:
-
Assignee: Andrew Onischuk

> Attempting to access the Ambari Dashboard results in an HTTP 500 Error after 
> changing cluster name and restarting the Ambari server
> ---
>
> Key: AMBARI-12538
> URL: https://issues.apache.org/jira/browse/AMBARI-12538
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.1.0
> Environment: SLES11 SP3
>Reporter: Zack Marsh
>Assignee: Andrew Onischuk
>Priority: Critical
> Fix For: 2.1.2
>
>
> Steps to reproduce:
> * Login to Ambari Web UI
> * Rename cluster  (Admin -> Manage Ambari -> Rename Cluister -> Enter new 
> name )
> * Restart Ambari Server via CLI (ambari-server restart)
> * Login to Ambari Web UI again
> * When attempting to access the Ambari Dashboard an HTTP 500 Error will occur:
> {code}
> Error
> 500 status code received on GET method for API: 
> /api/v1/clusters//requests?to=end_size=10=Requests 
> Error message: Server Error
> {code}
> Excerpt from the Ambari Server log:
> {code}
> 24 Jul 2015 16:40:41,013 ERROR [qtp-client-25] ReadHandler:91 - Caught a 
> runtime exception executing a query
> java.lang.RuntimeException: Failed to construct logical request during 
> replay: org.apache.ambari.server.ClusterNotFoundException: Cluster not found, 
> clusterName=PIRIPIRI
> at 
> org.apache.ambari.server.topology.PersistedStateImpl.getAllRequests(PersistedStateImpl.java:167)
> at 
> org.apache.ambari.server.topology.TopologyManager.ensureInitialized(TopologyManager.java:91)
> at 
> org.apache.ambari.server.topology.TopologyManager.getRequests(TopologyManager.java:198)
> at 
> org.apache.ambari.server.actionmanager.ActionManager.getRequestsByStatus(ActionManager.java:232)
> at 
> org.apache.ambari.server.controller.internal.RequestResourceProvider.getRequestResources(RequestResourceProvider.java:414)
> at 
> org.apache.ambari.server.controller.internal.RequestResourceProvider.getResources(RequestResourceProvider.java:200)
> at 
> org.apache.ambari.server.controller.internal.ClusterControllerImpl$ExtendedResourceProviderWrapper.queryForResources(ClusterControllerImpl.java:945)
> at 
> org.apache.ambari.server.controller.internal.ClusterControllerImpl.getResources(ClusterControllerImpl.java:132)
> at 
> org.apache.ambari.server.api.query.QueryImpl.doQuery(QueryImpl.java:482)
> at 
> org.apache.ambari.server.api.query.QueryImpl.queryForResources(QueryImpl.java:381)
> at 
> org.apache.ambari.server.api.query.QueryImpl.execute(QueryImpl.java:217)
> at 
> org.apache.ambari.server.api.handlers.ReadHandler.handleRequest(ReadHandler.java:68)
> at 
> org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:135)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:105)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:74)
> at 
> org.apache.ambari.server.api.services.RequestService.getRequests(RequestService.java:95)
> at sun.reflect.GeneratedMethodAccessor112.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at 
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
> at 
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
> at 
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at 
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at 
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
> at 
> 

[jira] [Updated] (AMBARI-12667) Saved Hive queries can not to be sorted by title

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-12667:
-
Assignee: DIPAYAN BHOWMICK

> Saved Hive queries can not to be sorted by title
> 
>
> Key: AMBARI-12667
> URL: https://issues.apache.org/jira/browse/AMBARI-12667
> Project: Ambari
>  Issue Type: Bug
>  Components: contrib
>Affects Versions: 2.1.0
>Reporter: DIPAYAN BHOWMICK
>Assignee: DIPAYAN BHOWMICK
>Priority: Critical
> Fix For: 2.1.1
>
> Attachments: AMBARI-12667_branch-2.1.patch
>
>
> Steps:
> Create Hive View.
> Go to created hive view.
> Create some queries and save them.
> Go to Saved Queries tab and try to sort queries by title.
> Result: queries do not sorted.



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

[jira] [Updated] (AMBARI-10417) Flume fails to restart on ubuntu 12.04 after system restart because /var/run/flume is deleted

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-10417:
-
Assignee: Andrew Onischuk

> Flume fails to restart on ubuntu 12.04 after system restart because 
> /var/run/flume is deleted
> -
>
> Key: AMBARI-10417
> URL: https://issues.apache.org/jira/browse/AMBARI-10417
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.0.0, 2.1.0
>Reporter: David McWhorter
>Assignee: Andrew Onischuk
> Fix For: 2.1.0
>
>
> Very similar issue to AMBARI-10317, but for flume:
> 2015-04-09 17:22:09,647 - Error while executing command 'restart':
> Traceback (most recent call last):
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 214, in execute
> method(env)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 362, in restart
> self.stop(env)
>   File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py", 
> line 89, in thunk
> return fn(*args, **kwargs)
>   File 
> "/var/lib/ambari-agent/cache/common-services/FLUME/1.4.0.2.0/package/scripts/flume_handler.py",
>  line 70, in stop
> flume(action='stop')
>   File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py", 
> line 89, in thunk
> return fn(*args, **kwargs)
>   File 
> "/var/lib/ambari-agent/cache/common-services/FLUME/1.4.0.2.0/package/scripts/flume.py",
>  line 167, in flume
> _set_desired_state('INSTALLED')
>   File 
> "/var/lib/ambari-agent/cache/common-services/FLUME/1.4.0.2.0/package/scripts/flume.py",
>  line 244, in _set_desired_state
> content = state,
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
> line 148, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 152, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 118, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 105, in action_create
> raise Fail("Applying %s failed, parent directory %s doesn't exist" % 
> (self.resource, dirname))
> Fail: Applying u"File['/var/run/flume/ambari-state.txt']" failed, parent 
> directory /var/run/flume doesn't exist
> stdout:   /var/lib/ambari-agent/data/output-270.txt
> 2015-04-09 17:22:05,187 - u"Group['hadoop']" {'ignore_failures': False}
> 2015-04-09 17:22:05,187 - Modifying group hadoop
> 2015-04-09 17:22:05,238 - u"Group['users']" {'ignore_failures': False}
> 2015-04-09 17:22:05,238 - Modifying group users
> 2015-04-09 17:22:05,283 - u"Group['knox']" {'ignore_failures': False}
> 2015-04-09 17:22:05,283 - Modifying group knox
> 2015-04-09 17:22:05,326 - u"Group['ranger']" {'ignore_failures': False}
> 2015-04-09 17:22:05,326 - Modifying group ranger
> 2015-04-09 17:22:05,369 - u"User['hive']" {'gid': 'hadoop', 
> 'ignore_failures': False, 'groups': [u'hadoop']}
> 2015-04-09 17:22:05,370 - Modifying user hive
> 2015-04-09 17:22:05,412 - u"User['oozie']" {'gid': 'hadoop', 
> 'ignore_failures': False, 'groups': [u'users']}
> 2015-04-09 17:22:05,413 - Modifying user oozie
> 2015-04-09 17:22:05,458 - u"User['root']" {'gid': 'hadoop', 
> 'ignore_failures': False, 'groups': [u'hadoop']}
> 2015-04-09 17:22:05,458 - Modifying user root
> 2015-04-09 17:22:05,502 - u"User['ambari-qa']" {'gid': 'hadoop', 
> 'ignore_failures': False, 'groups': [u'users']}
> 2015-04-09 17:22:05,502 - Modifying user ambari-qa
> 2015-04-09 17:22:05,545 - u"User['flume']" {'gid': 'hadoop', 
> 'ignore_failures': False, 'groups': [u'hadoop']}
> 2015-04-09 17:22:05,545 - Modifying user flume
> 2015-04-09 17:22:05,588 - u"User['hdfs']" {'gid': 'hadoop', 
> 'ignore_failures': False, 'groups': [u'hadoop']}
> 2015-04-09 17:22:05,589 - Modifying user hdfs
> 2015-04-09 17:22:05,633 - u"User['knox']" {'gid': 'hadoop', 
> 'ignore_failures': False, 'groups': [u'hadoop']}
> 2015-04-09 17:22:05,633 - Modifying user knox
> 2015-04-09 17:22:05,676 - u"User['ranger']" {'gid': 'hadoop', 
> 'ignore_failures': False, 'groups': [u'hadoop']}
> 2015-04-09 17:22:05,677 - Modifying user ranger
> 2015-04-09 17:22:05,722 - u"User['mapred']" {'gid': 'hadoop', 
> 'ignore_failures': False, 'groups': [u'hadoop']}
> 2015-04-09 17:22:05,723 - Modifying user mapred
> 2015-04-09 17:22:05,766 - u"User['tez']" {'gid': 'hadoop', 'ignore_failures': 
> False, 'groups': [u'users']}
> 2015-04-09 17:22:05,766 - Modifying user tez
> 2015-04-09 17:22:05,810 - u"User['zookeeper']" {'gid': 'hadoop', 
> 'ignore_failures': False, 'groups': [u'hadoop']}
> 2015-04-09 17:22:05,810 

[jira] [Resolved] (AMBARI-10598) ambari 2.0 – Ranger plugins

[Yusaku Sako (JIRA)]

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

Yusaku Sako resolved AMBARI-10598.
--
Resolution: Done

> ambari 2.0 – Ranger plugins
> ---
>
> Key: AMBARI-10598
> URL: https://issues.apache.org/jira/browse/AMBARI-10598
> Project: Ambari
>  Issue Type: Bug
>Reporter: Arti Wadhwani
>
> After installing ambari 2.0 and adding Ranger service to it, I am unable to 
> enable/diable plugins via UI. I do not see that option.
> Also I tried to enable hdfs plugin via command line but the UI still shows 
> this as disabled. As such, my policies are not working.
> Could you please help or refer me to Ambari 2.0 Ranger user guide?



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

[jira] [Updated] (AMBARI-4573) Write unnitests for NAGIOS install script on HDP1 and HDP2

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-4573:

Assignee: Iryna Kuzmenko

> Write unnitests for NAGIOS install script on HDP1 and HDP2
> --
>
> Key: AMBARI-4573
> URL: https://issues.apache.org/jira/browse/AMBARI-4573
> Project: Ambari
>  Issue Type: Bug
>Reporter: Iryna Kuzmenko
>Assignee: Iryna Kuzmenko
> Fix For: 1.5.0
>
> Attachments: AMBARI-4573.patch
>
>




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

[jira] [Updated] (AMBARI-4525) Fix Ambari MSI build process

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-4525:

Assignee: Ivan Malamen

> Fix Ambari MSI build process
> 
>
> Key: AMBARI-4525
> URL: https://issues.apache.org/jira/browse/AMBARI-4525
> Project: Ambari
>  Issue Type: Bug
>  Components: contrib
>Reporter: Ivan Malamen
>Assignee: Ivan Malamen
> Fix For: 1.4.4
>
> Attachments: 0001-AMBARI-4525-Fix-Ambari-MSI-build-process.patch, 
> 0001-AMBARI-4525-Fix-Ambari-MSI-build-process.patch, 
> 0001-AMBARI-4525-Fix-Ambari-MSI-build-process.patch, 
> 0001-Fixing-MSI-build.patch, 0002-Fixing-MSI-build.patch
>
>
> Ambari-SCOM MSI is not built during overall build process. Need to fix build 
> scripts.



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

[jira] [Updated] (AMBARI-8960) Separate AlertConfig logic from AlertConfigsController

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-8960:

Assignee: Oleg Nechiporenko

> Separate AlertConfig logic from AlertConfigsController
> --
>
> Key: AMBARI-8960
> URL: https://issues.apache.org/jira/browse/AMBARI-8960
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.0.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 2.0.0
>
> Attachments: AMBARI-8960.patch
>
>




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

[jira] [Updated] (AMBARI-11908) ResourceManager fails initial start when not colocated with Namenode

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-11908:
-
Assignee: Vitaly Brodetskyi

> ResourceManager fails initial start when not colocated with Namenode
> 
>
> Key: AMBARI-11908
> URL: https://issues.apache.org/jira/browse/AMBARI-11908
> Project: Ambari
>  Issue Type: Bug
> Environment: sles11sp3
> hdp-2.3.0.0-2346
> ambari-2.1.0-1064
>Reporter: Michael Harp
>Assignee: Vitaly Brodetskyi
> Fix For: 2.1.0
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> Deploying with blueprint and Namenode-HA and Yarn-HA enabled resoucemanager 
> fails initial start. Subsequent starts succeed.
> {code}
> 2015-06-13 03:41:24,922 - Getting jmx metrics from NN failed. URL: 
> http://helios1.labs.teradata.com:50070/jmx?qry=Hadoop:service=NameNode,name=NameNodeStatus
> Traceback (most recent call last):
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/functions/jmx.py",
>  line 37, in get_value_from_jmx
> _, data = shell.checked_call(cmd, user=run_user, quiet=False)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 70, in inner
> result = function(command, **kwargs)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 92, in checked_call
> tries=tries, try_sleep=try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 282, in _call
> raise Fail(err_msg)
> Fail: Execution of 'curl -s 
> 'http://helios1.labs.teradata.com:50070/jmx?qry=Hadoop:service=NameNode,name=NameNodeStatus''
>  returned 7. 
> 2015-06-13 03:41:25,000 - Getting jmx metrics from NN failed. URL: 
> http://helios2.labs.teradata.com:50070/jmx?qry=Hadoop:service=NameNode,name=NameNodeStatus
> {code}



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

[jira] [Updated] (AMBARI-11903) metrics-collector in distributed mode fails to stop

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-11903:
-
Assignee: Andrew Onischuk

> metrics-collector in distributed mode fails to stop
> ---
>
> Key: AMBARI-11903
> URL: https://issues.apache.org/jira/browse/AMBARI-11903
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
> Environment: sles11sp3
> ambari-server-2.1.0-1064
> 2.3.0.0-2346
>Reporter: Michael Harp
>Assignee: Andrew Onischuk
>Priority: Critical
> Fix For: 2.1.0
>
>
> Stopping metrics-collector is  slow and mostly fails when configured in 
> distributed mode. I believe the reason is the hbase stop order is the same as 
> start order which results in zookeeper stopping fist instead of last.
> {code}
> # ams_service.py
> if params.is_hbase_distributed:
>   hbase_service('zookeeper', action=action)
>   hbase_service('master', action=action)
>   hbase_service('regionserver', action=action)
>   cmd = format("{cmd} --distributed")
> {code}



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

[jira] [Updated] (AMBARI-11907) Active hbase-master takes 20 minutes to stop from "Stop All"

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-11907:
-
Assignee: Andrew Onischuk

> Active hbase-master takes 20 minutes to stop from "Stop All"
> 
>
> Key: AMBARI-11907
> URL: https://issues.apache.org/jira/browse/AMBARI-11907
> Project: Ambari
>  Issue Type: Bug
> Environment: sles11sp3
> hdp-2.3.0.0-2346
> ambari-2.1.0-1064
>Reporter: Michael Harp
>Assignee: Andrew Onischuk
>Priority: Critical
> Fix For: 2.1.0
>
>
> When Namenode HA and Hbase HA are enabled the active hbase-master takes 20 
> plus minutes to stop.
> {code}
> 2015-06-13 14:16:06,183 - 
> Execute['/usr/hdp/current/hbase-master/bin/hbase-daemon.sh --config 
> /usr/hdp/current/hbase-master/conf stop master'] {'on_timeout': '! ( ls 
> /var/run/hbase/hbase-hbase-master.pid >/dev/null 2>&1 && ps -p `cat 
> /var/run/hbase/hbase-hbase-master.pid` >/dev/null 2>&1 ) || ambari-sudo.sh -H 
> -E kill -9 `cat /var/run/hbase/hbase-hbase-master.pid`', 'timeout': 30, 
> 'user': 'hbase'}
> 2015-06-13 14:36:13,274 - 
> Execute['/usr/hdp/current/hbase-master/bin/hbase-daemon.sh --config 
> /usr/hdp/current/hbase-master/conf stop master'] {'on_timeout': '! ( ls 
> /var/run/hbase/hbase-hbase-master.pid >/dev/null 2>&1 && ps -p `cat 
> /var/run/hbase/hbase-hbase-master.pid` >/dev/null 2>&1 ) || ambari-sudo.sh -H 
> -E kill -9 `cat /var/run/hbase/hbase-hbase-master.pid`', 'timeout': 30, 
> 'user': 'hbase'}
> 2015-06-13 14:36:13,340 - Execute['rm -f 
> /var/run/hbase/hbase-hbase-master.pid'] {}
> {code}



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

[jira] [Updated] (AMBARI-9784) Update Ambari JDK Support, including JDK 1.8

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-9784:

Assignee: Jeff Sposetti  (was: Jeff Markham)

> Update Ambari JDK Support, including JDK 1.8
> 
>
> Key: AMBARI-9784
> URL: https://issues.apache.org/jira/browse/AMBARI-9784
> Project: Ambari
>  Issue Type: Epic
>  Components: ambari-server
>Affects Versions: 2.1.0
>Reporter: Jeff Sposetti
>Assignee: Jeff Sposetti
> Fix For: 2.1.0
>
>
> Update JDK support for Ambari
> - Add support for Oracle JDK 1.8 (default)
> - Add support for OpenJDK 8 (via Custom JDK setup option)
> - Mark Oracle JDK 1.7 as deprecated
> - Remove support for Oracle JDK 1.6



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

[jira] [Reopened] (AMBARI-9466) In-correct entry - Need to delete

[Yusaku Sako (JIRA)]

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

Yusaku Sako reopened AMBARI-9466:
-

> In-correct entry - Need to delete
> -
>
> Key: AMBARI-9466
> URL: https://issues.apache.org/jira/browse/AMBARI-9466
> Project: Ambari
>  Issue Type: Bug
> Environment: RHEL 6 (64-bit)
>Reporter: Sai Nukavarapu
>Priority: Trivial
>
> In-correct entry - Need to delete



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

[jira] [Resolved] (AMBARI-9466) In-correct entry - Need to delete

[Yusaku Sako (JIRA)]

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

Yusaku Sako resolved AMBARI-9466.
-
Resolution: Invalid

> In-correct entry - Need to delete
> -
>
> Key: AMBARI-9466
> URL: https://issues.apache.org/jira/browse/AMBARI-9466
> Project: Ambari
>  Issue Type: Bug
> Environment: RHEL 6 (64-bit)
>Reporter: Sai Nukavarapu
>Priority: Trivial
>
> In-correct entry - Need to delete



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

[jira] [Commented] (AMBARI-13060) Kerberos: Allow user to specify additional realms for auth-to-local rules

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13060:
-

SUCCESS: Integrated in Ambari-trunk-Commit #3441 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3441/])
AMBARI-13060. Kerberos: Allow user to specify additional realms for 
auth-to-local rules (rlevas) (rlevas: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=9b6d33d0cb8635ca13f23b468c32bb31c30bd966)
* ambari-server/src/test/resources/stacks/HDP/2.0.8/kerberos.json
* ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/kerberos.json
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
* ambari-server/src/main/resources/stacks/HDP/2.0.6/kerberos.json
* ambari-web/app/mixins/wizard/addSecurityConfigs.js
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/AuthToLocalBuilder.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/AuthToLocalBuilderTest.java
* 
ambari-server/src/test/java/org/apache/ambari/server/api/services/AmbariMetaInfoTest.java


> Kerberos: Allow user to specify additional realms for auth-to-local rules
> -
>
> Key: AMBARI-13060
> URL: https://issues.apache.org/jira/browse/AMBARI-13060
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, ambari-web
>Affects Versions: 2.0.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>  Labels: kerberos, kerberos-wizard
> Fix For: 2.1.2
>
> Attachments: AMBARI-13060_branch-2.1_01.patch, 
> AMBARI-13060_trunk_01.patch
>
>
> Allow user to specify additional realms for auth-to-local rules. This will 
> add _default_ rules for the specified realm(s) to the generated auth-to-local 
> rule sets. For example:
> {noformat}
> RULE:[1:$1@$0](.*@USER_REALM.COM)s/@.*//
> {noformat}
> The value should be a (comma) delimited list of realm names set in set of 
> global properties in the Kerberos Descriptor.



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

[jira] [Commented] (AMBARI-13040) Improve help text description for Ranger properties in Ambari

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13040:
-

SUCCESS: Integrated in Ambari-trunk-Commit #3441 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3441/])
AMBARI-13040. Improve help text description for Ranger properties in Ambari. 
(Gautam Board via jaimin) (jaimin: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=c6e61d8bb5ce97926a2d68bc08a134f80c9769ba)
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/STORM/configuration/ranger-storm-audit.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/KNOX/configuration/ranger-knox-audit.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/KAFKA/configuration/ranger-kafka-policymgr-ssl.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/HDFS/configuration/ranger-hdfs-policymgr-ssl.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/STORM/configuration/ranger-storm-plugin-properties.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/STORM/configuration/ranger-storm-policymgr-ssl.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/RANGER/configuration/ranger-ugsync-site.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/YARN/configuration/ranger-yarn-policymgr-ssl.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/KAFKA/configuration/ranger-kafka-plugin-properties.xml
* 
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/configuration/ranger-kms-audit.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/HIVE/configuration/ranger-hive-plugin-properties.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/RANGER/configuration/ranger-admin-site.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/HBASE/configuration/ranger-hbase-audit.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/HIVE/configuration/ranger-hive-audit.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/YARN/configuration/ranger-yarn-plugin-properties.xml
* 
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/configuration/ranger-knox-plugin-properties.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/HIVE/configuration/ranger-hive-policymgr-ssl.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/HDFS/configuration/ranger-hdfs-plugin-properties.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/KNOX/configuration/ranger-knox-policymgr-ssl.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/HBASE/configuration/ranger-hbase-plugin-properties.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/YARN/configuration/ranger-yarn-audit.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/HBASE/configuration/ranger-hbase-policymgr-ssl.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/HDFS/configuration/ranger-hdfs-audit.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/HIVE/configuration/ranger-hive-security.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/KAFKA/configuration/ranger-kafka-audit.xml
* 
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/configuration/ranger-kms-policymgr-ssl.xml


> Improve help text description for Ranger properties in Ambari
> -
>
> Key: AMBARI-13040
> URL: https://issues.apache.org/jira/browse/AMBARI-13040
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.2.0, 2.1.2
>
> Attachments: AMBARI-13040-trunk.patch, AMBARI-13040.patch
>
>
> Improve help text description for Ranger properties in Ambari.



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

[jira] [Created] (AMBARI-13093) hiveserver2 crashes due to incorrect property "datanucleus.rdbms.datastoreAdapterClassName" in hive-site.xml

[Michael Harp (JIRA)]

Michael Harp created AMBARI-13093:
-

 Summary: hiveserver2 crashes due to incorrect property 
"datanucleus.rdbms.datastoreAdapterClassName" in hive-site.xml
 Key: AMBARI-13093
 URL: https://issues.apache.org/jira/browse/AMBARI-13093
 Project: Ambari
  Issue Type: Bug
 Environment: sles11sp3
ambari-2.1.2 (63691daa649c824fe95c27c6ce246f7d6fdb67a9)
hdp-2.3.2-2826
Reporter: Michael Harp
Priority: Critical
 Fix For: 2.1.2
 Attachments: hiveserver2.log.gz

Steps to reproduce;
# Deploy with Blueprint, 
[3-master-HDP-2.3.json|http://td-ape-tigereye/hadoopBuilder/src/config/ambari/3-master-HDP-2.3.json]
 which uses Postgres for hivemetastore.
# Check /etc/hive/conf/hive-site.xml for property 
datanucleus.rdbms.datastoreAdapterClassName=org.datanucleus.store.rdbms.adapter.SQLAnywhereAdapter

This causes hiverserver2 to fail with error:
{code}
2015-09-14 14:14:41,559 ERROR [main]: DataNucleus.Datastore 
(Log4JLogger.java:error(115)) - Error : An er
ror occurred trying to instantiate an instance of the adapter 
"org.datanucleus.store.rdbms.adapter.SQLAny
whereAdapter" for this JDBC driver : Class 
"org.datanucleus.store.rdbms.adapter.SQLAnywhereAdapter" was n
ot found in the CLASSPATH. Please check your specification and your 
CLASSPATH.{code}
Full log is attached.



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

[jira] [Updated] (AMBARI-12408) Add Host and Add Service Wizards do not contain a Download CSV button when Kerberos is enabled

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-12408:
-
Assignee: Antonenko Alexander

> Add Host and Add Service Wizards do not contain a Download CSV button when 
> Kerberos is enabled
> --
>
> Key: AMBARI-12408
> URL: https://issues.apache.org/jira/browse/AMBARI-12408
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.0
>Reporter: Robert Levas
>Assignee: Antonenko Alexander
>  Labels: kerberos
> Fix For: 2.1.1
>
> Attachments: AMBARI-12408.patch, AMBARI-12408_additional.patch, 
> Ambari - Add Host Wizard - Review.png, Ambari - Add Service Wizard - 
> Review.png, Ambari - Enable Kerberos Wizard - Confirmation Configuration.png
>
>
> Add Host and Add Service Wizards do not contain a Download CSV button when 
> Kerberos is enabled.
> !Ambari - Add Service Wizard - Review.png!
> !Ambari - Add Host Wizard - Review.png!



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

[jira] [Resolved] (AMBARI-10115) Ambari 2.0 branch build failed

[Yusaku Sako (JIRA)]

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

Yusaku Sako resolved AMBARI-10115.
--
Resolution: Done

> Ambari 2.0 branch build failed
> --
>
> Key: AMBARI-10115
> URL: https://issues.apache.org/jira/browse/AMBARI-10115
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.0.0
> Environment: CentOS 6.6
> Oracle JDK1.7
> Maven 3.0.5
> Python 2.6
> Eclipse Luna
>Reporter: robinlin
> Fix For: 2.0.0
>
>
> Hi all:
> I am trying to build branch 2.0, and I follow the document
> https://cwiki.apache.org/confluence/display/AMBARI/Ambari+Development
> But it failed at the Ambari-server building.
> {noformat}
> [INFO] Checking for unpackaged file(s): /usr/lib/rpm/check-files 
> /root/git/ambari_2_0/ambari-admin/target/rpm/ambari-admin/buildroot
> [INFO] Wrote: 
> /root/git/ambari_2_0/ambari-admin/target/rpm/ambari-admin/RPMS/noarch/ambari-admin-2.0.0-0.noarch.rpm
> [INFO] Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.vPw43Z
> [WARNING] + umask 022
> [WARNING] + cd /root/git/ambari_2_0/ambari-admin/target/rpm/ambari-admin/BUILD
> [WARNING] + /bin/rm -rf 
> /root/git/ambari_2_0/ambari-admin/target/rpm/ambari-admin/buildroot
> [WARNING] + exit 0
> [INFO]
>  
> [INFO] 
> 
> [INFO] Building Ambari Server 2.0.0.0
> [INFO] 
> 
> [WARNING] The POM for org.apache.ambari:ambari-metrics-common:jar:2.0.0.0 is 
> missing, no dependency information available
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] Ambari Main ... SUCCESS [  9.631 s]
> [INFO] Apache Ambari Project POM . SUCCESS [  0.370 s]
> [INFO] Ambari Web  SUCCESS [02:40 min]
> [INFO] Ambari Views .. SUCCESS [  2.539 s]
> [INFO] Ambari Admin View . SUCCESS [ 31.006 s]
> [INFO] Ambari Server . FAILURE [  1.208 s]
> [INFO] Ambari Agent .. SKIPPED
> [INFO] Ambari Client . SKIPPED
> [INFO] Ambari Python Client .. SKIPPED
> [INFO] Ambari Groovy Client .. SKIPPED
> [INFO] Ambari Shell .. SKIPPED
> [INFO] Ambari Python Shell ... SKIPPED
> [INFO] Ambari Groovy Shell ... SKIPPED
> [INFO] Ambari Metrics Common . SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 03:26 min
> [INFO] Finished at: 2015-03-18T14:57:10+08:00
> [INFO] Final Memory: 32M/190M
> [INFO] 
> 
> [ERROR] Failed to execute goal on project ambari-server: Could not resolve 
> dependencies for project org.apache.ambari:ambari-server:jar:2.0.0.0: Failure 
> to find org.apache.ambari:ambari-metrics-common:jar:2.0.0.0 in 
> https://oss.sonatype.org/content/groups/staging was cached in the local 
> repository, resolution will not be reattempted until the update interval of 
> oss.sonatype.org has elapsed or updates are forced -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> [ERROR] 
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :ambari-server
> {noformat}
> Any help would be greatly appreciated.



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

[jira] [Updated] (AMBARI-10237) 'Reload Page' popup issues: multiple instances, broken reload link, displaying popup after connection is established

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-10237:
-
Assignee: Oleg Nechiporenko

> 'Reload Page' popup issues: multiple instances, broken reload link, 
> displaying popup after connection is established
> 
>
> Key: AMBARI-10237
> URL: https://issues.apache.org/jira/browse/AMBARI-10237
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 2.1.0
>
> Attachments: AMBARI-10237.patch
>
>
> If connection with Ambari server is lost during hosts bootstrap (Install/Add 
> Host Wizard) or deploy (Install/Add Service/Add Host Wizard), UI displays 
> multiple instances of 'Reload Page' popup with message about attempting to 
> reconnect (new instances appear periodically, so their number increases with 
> time).
> Also:
> - 'Reload page' link doesn't work.
> - Popup is not closed after connection is established.



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

[jira] [Reopened] (AMBARI-10115) Ambari 2.0 branch build failed

[Yusaku Sako (JIRA)]

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

Yusaku Sako reopened AMBARI-10115:
--

> Ambari 2.0 branch build failed
> --
>
> Key: AMBARI-10115
> URL: https://issues.apache.org/jira/browse/AMBARI-10115
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.0.0
> Environment: CentOS 6.6
> Oracle JDK1.7
> Maven 3.0.5
> Python 2.6
> Eclipse Luna
>Reporter: robinlin
> Fix For: 2.0.0
>
>
> Hi all:
> I am trying to build branch 2.0, and I follow the document
> https://cwiki.apache.org/confluence/display/AMBARI/Ambari+Development
> But it failed at the Ambari-server building.
> {noformat}
> [INFO] Checking for unpackaged file(s): /usr/lib/rpm/check-files 
> /root/git/ambari_2_0/ambari-admin/target/rpm/ambari-admin/buildroot
> [INFO] Wrote: 
> /root/git/ambari_2_0/ambari-admin/target/rpm/ambari-admin/RPMS/noarch/ambari-admin-2.0.0-0.noarch.rpm
> [INFO] Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.vPw43Z
> [WARNING] + umask 022
> [WARNING] + cd /root/git/ambari_2_0/ambari-admin/target/rpm/ambari-admin/BUILD
> [WARNING] + /bin/rm -rf 
> /root/git/ambari_2_0/ambari-admin/target/rpm/ambari-admin/buildroot
> [WARNING] + exit 0
> [INFO]
>  
> [INFO] 
> 
> [INFO] Building Ambari Server 2.0.0.0
> [INFO] 
> 
> [WARNING] The POM for org.apache.ambari:ambari-metrics-common:jar:2.0.0.0 is 
> missing, no dependency information available
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] Ambari Main ... SUCCESS [  9.631 s]
> [INFO] Apache Ambari Project POM . SUCCESS [  0.370 s]
> [INFO] Ambari Web  SUCCESS [02:40 min]
> [INFO] Ambari Views .. SUCCESS [  2.539 s]
> [INFO] Ambari Admin View . SUCCESS [ 31.006 s]
> [INFO] Ambari Server . FAILURE [  1.208 s]
> [INFO] Ambari Agent .. SKIPPED
> [INFO] Ambari Client . SKIPPED
> [INFO] Ambari Python Client .. SKIPPED
> [INFO] Ambari Groovy Client .. SKIPPED
> [INFO] Ambari Shell .. SKIPPED
> [INFO] Ambari Python Shell ... SKIPPED
> [INFO] Ambari Groovy Shell ... SKIPPED
> [INFO] Ambari Metrics Common . SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 03:26 min
> [INFO] Finished at: 2015-03-18T14:57:10+08:00
> [INFO] Final Memory: 32M/190M
> [INFO] 
> 
> [ERROR] Failed to execute goal on project ambari-server: Could not resolve 
> dependencies for project org.apache.ambari:ambari-server:jar:2.0.0.0: Failure 
> to find org.apache.ambari:ambari-metrics-common:jar:2.0.0.0 in 
> https://oss.sonatype.org/content/groups/staging was cached in the local 
> repository, resolution will not be reattempted until the update interval of 
> oss.sonatype.org has elapsed or updates are forced -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> [ERROR] 
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :ambari-server
> {noformat}
> Any help would be greatly appreciated.



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

[jira] [Updated] (AMBARI-9981) Ambari storm logviewer in secure mode doesn't work

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-9981:

Assignee: Robert Levas

> Ambari storm logviewer in secure mode doesn't work
> --
>
> Key: AMBARI-9981
> URL: https://issues.apache.org/jira/browse/AMBARI-9981
> Project: Ambari
>  Issue Type: Bug
>Reporter: Robert Levas
>Assignee: Robert Levas
>  Labels: kerberos
> Attachments: AMBARI-9981_01.patch
>
>
> Storm logviewer uses the same UI.filter config thats being used for Storm UI.
> In secure mode storm UI uses SPENGO to authenticate user to access the UI.
> Similarly logviewer also does the same .
> But in Ambari 1.7 we advise user to create HTTP/storm-ui@REALM and this gets 
> added to storm.yaml.
> As this is bound to a host storm logviewers which are running one per 
> supervisor won't be able to use this key .
> Solution:
> There is a configuration problem in the {{/etc/storm/conf/storm.yaml}} file.  
> In particular the issue is here:
> {code:title=/etc/storm/conf/storm.yaml:109}
> ui.filter.params:
>   "type": "kerberos"
>   "kerberos.principal": "HTTP/host-2.inter...@example.com"
>   "kerberos.keytab": "/etc/security/keytabs/spnego.service.keytab"
>   "kerberos.name.rules": "DEFAULT"
> {code}
> The {{kerberos.principal}} value should be the SPNEGO principal for the 
> localhost, not the host where the UI server is running.  In this example, the 
> localhost is *host-4.internal*  so the {{kerberos.principal}} value should be 
> *HTTP/host-4.inter...@example.com* not *HTTP/host-2.inter...@example.com*.  
> The Storm UI server is running on *host-2.internal*
> The fix for this should be in the code around 
> {code:title=common-services/STORM/0.9.1.2.1/package/scripts/params.py:103} 
> _storm_ui_jaas_principal_name = 
> config['configurations']['storm-env']['storm_ui_principal_name']
> storm_ui_host = default("/clusterHostInfo/storm_ui_server_hosts", [])
> storm_ui_jaas_principal = 
> _storm_ui_jaas_principal_name.replace('_HOST',storm_ui_host[0].lower())
> {code}
> {{storm_ui_jaas_principal}} is then used in the template to build the 
> storm.yaml file.  



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

[jira] [Updated] (AMBARI-5617) Ambari Views: FileBrowser view

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-5617:

Assignee: Roman Rader

> Ambari Views: FileBrowser view
> --
>
> Key: AMBARI-5617
> URL: https://issues.apache.org/jira/browse/AMBARI-5617
> Project: Ambari
>  Issue Type: Task
>Reporter: Roman Rader
>Assignee: Roman Rader
> Fix For: 1.6.0
>
> Attachments: files.patch
>
>
> Create back-end and front-end for FileBrowser View



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

[jira] [Updated] (AMBARI-9186) Blueprint contains password fields in "cluster-env" (hadoop.user.password, sink.dbpassword)

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-9186:

Assignee: Jayush Luniya

> Blueprint contains password fields in "cluster-env" (hadoop.user.password, 
> sink.dbpassword)
> ---
>
> Key: AMBARI-9186
> URL: https://issues.apache.org/jira/browse/AMBARI-9186
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server, ambari-web
>Affects Versions: 2.0.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
> Fix For: 2.0.0
>
> Attachments: AMBARI-9186.patch
>
>
> STR:
> 1)Deploy cluster
> 2)Check blueprints 
> (http://ec2-54-173-17-59.compute-1.amazonaws.com:8080/api/v1/clusters/cl1?format=blueprint)
>  -> cluster-env
> Actual result:
> Blueprint contains password fields in "cluster-env" (hadoop.user.password, 
> sink.dbpassword). No matter that they are empty.
> Expected result:
> Blueprint does not contain password fields.



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

[jira] [Updated] (AMBARI-13052) Stop-and-Start Upgrade: HDP 2.1->2.3 needs to stop services using 2.1, and start using 2.3

[Alejandro Fernandez (JIRA)]

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

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

> Stop-and-Start Upgrade: HDP 2.1->2.3 needs to stop services using 2.1, and 
> start using 2.3
> --
>
> Key: AMBARI-13052
> URL: https://issues.apache.org/jira/browse/AMBARI-13052
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.2.0
>
> Attachments: AMBARI-13052.patch
>
>
> For a Stop-and-Start Upgrade from HDP 2.1 -> 2.3, we need to stop all 
> services using the scripts for HDP 2.1, and then start them using HDP 2.3.
> Today, during an Upgrade, we currently set the desired stack id when we 
> process Upgrade Pack and insert the upgrade record. That means that all 
> start/stop commands use the scripts from the desired stack.
> Instead, we need a Server Side Action to be called right before we run 
> "hdp-select set all" that will change the desired stack id to the new 
> version; this will permit stopping on the old version, and starting on the 
> new version.
> When we downgrade, we commence the orchestration again, and we again call the 
> Server Side Action to change the desired stack id, this time to the starting 
> version.



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

Ambari Custom Alerts Question

[Arun Patel]

Have couple of questions on Ambari custom alerts.

1) I developed a python script to check the znodes of zookeeper.  I used
the option "ignore_host": true and its working fine.  Now, in this case,
the script will run on which host?  any one of the 3 zookeeper hosts?

2) I would like to pass a custom parameter to the script from Ambari Alert
page.  The user should click edit to change the parameter as needed.  How
do I provide this option in alerts.json?

Regards,
Arun

[jira] [Updated] (AMBARI-13093) hiveserver2 crashes due to incorrect property "datanucleus.rdbms.datastoreAdapterClassName" in hive-site.xml

[Michael Harp (JIRA)]

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

Michael Harp updated AMBARI-13093:
--
Attachment: hiveserver2.log.gz

> hiveserver2 crashes due to incorrect property 
> "datanucleus.rdbms.datastoreAdapterClassName" in hive-site.xml
> 
>
> Key: AMBARI-13093
> URL: https://issues.apache.org/jira/browse/AMBARI-13093
> Project: Ambari
>  Issue Type: Bug
> Environment: sles11sp3
> ambari-2.1.2 (63691daa649c824fe95c27c6ce246f7d6fdb67a9)
> hdp-2.3.2-2826
>Reporter: Michael Harp
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: hiveserver2.log.gz
>
>
> Steps to reproduce;
> # Deploy with Blueprint, 
> [3-master-HDP-2.3.json|http://td-ape-tigereye/hadoopBuilder/src/config/ambari/3-master-HDP-2.3.json]
>  which uses Postgres for hivemetastore.
> # Check /etc/hive/conf/hive-site.xml for property 
> datanucleus.rdbms.datastoreAdapterClassName=org.datanucleus.store.rdbms.adapter.SQLAnywhereAdapter
> This causes hiverserver2 to fail with error:
> {code}
> 2015-09-14 14:14:41,559 ERROR [main]: DataNucleus.Datastore 
> (Log4JLogger.java:error(115)) - Error : An er
> ror occurred trying to instantiate an instance of the adapter 
> "org.datanucleus.store.rdbms.adapter.SQLAny
> whereAdapter" for this JDBC driver : Class 
> "org.datanucleus.store.rdbms.adapter.SQLAnywhereAdapter" was n
> ot found in the CLASSPATH. Please check your specification and your 
> CLASSPATH.{code}
> Full log is attached.



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

[jira] [Resolved] (AMBARI-3409) MSI have to do full rollback in case of interrupted installation

[Yusaku Sako (JIRA)]

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

Yusaku Sako resolved AMBARI-3409.
-
Resolution: Duplicate

> MSI have to do full rollback in case of interrupted installation
> 
>
> Key: AMBARI-3409
> URL: https://issues.apache.org/jira/browse/AMBARI-3409
> Project: Ambari
>  Issue Type: Improvement
>  Components: contrib
>Reporter: Dmitriy Balykin
>




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

[jira] [Updated] (AMBARI-12671) Progress bar in Hive view shows 100% but job is still running

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-12671:
-
Assignee: Rohit Choudhary

> Progress bar in Hive view shows 100% but job is still running
> -
>
> Key: AMBARI-12671
> URL: https://issues.apache.org/jira/browse/AMBARI-12671
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.1.1
>Reporter: Rohit Choudhary
>Assignee: Rohit Choudhary
>Priority: Critical
> Fix For: 2.1.1
>
> Attachments: AMBARI-12671_branch-2.1.patch
>
>
> PROBLEM: Progress bar in Hive view shows 100% but job is still running
> IMPACT:  confusion to customers and don't know if it ran or not hence 
> critical since it affects user experience. 
> -download this file on your machine 
> https://s3.amazonaws.com/hw-sandbox/tutorial1/NYSE-2000-2001.tsv.gz
> -now go to ambari hive views and execute to create the table: 
> CREATE TABLE `nyse_stocks`(
> `exchange` string,
> `stock_symbol` string,
> `date` string,
> `stock_price_open` float,
> `stock_price_high` float,
> `stock_price_low` float,
> `stock_price_close` float,
> `stock_volume` bigint,
> `stock_price_adj_close` float)
> ROW FORMAT DELIMITED
> FIELDS TERMINATED BY '\t'
> STORED AS INPUTFORMAT
> 'org.apache.hadoop.mapred.TextInputFormat'
> OUTPUTFORMAT
> 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
> -now upload file as mentioned above, using the files browser view and place 
> it in the newly created path: 
> /apps/hive/warehouse/nyse_stocks/
> -go to hive view and execute select count(*) from nyse_stocks;
> it should error
> then execute it again after you should see the attached screenshot. 



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

[jira] [Updated] (AMBARI-12225) Unable to initialize Slider View on secure cluster with Wire Encryption

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-12225:
-
Assignee: Gour Saha

> Unable to initialize Slider View on secure cluster with Wire Encryption
> ---
>
> Key: AMBARI-12225
> URL: https://issues.apache.org/jira/browse/AMBARI-12225
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views, security
>Affects Versions: 2.1.0
> Environment: secured with wire encryption on, redhat 6.5
>Reporter: Gour Saha
>Assignee: Gour Saha
> Attachments: AMBARI-12225.patch
>
>
> Throws the following exception -
> {code}
> Unable to initialize Slider view: javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
> {code}



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

[jira] [Updated] (AMBARI-12747) Ambari server upgrade does not re-extract the jar content of the views

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-12747:
-
Assignee: Rohit Choudhary

> Ambari server upgrade does not re-extract the jar content of the views
> --
>
> Key: AMBARI-12747
> URL: https://issues.apache.org/jira/browse/AMBARI-12747
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.0
>Reporter: Rohit Choudhary
>Assignee: Rohit Choudhary
>Priority: Critical
> Fix For: 2.0.0, 2.1.0, 2.1.1
>
> Attachments: AMBARI-12747_branch-2.1.patch
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> *STR:*
> # Upgrade ambari-server from 2.0.0 to 2.1.0
> # Start ambari-server
> *Actual Result:* All view's jar are updated but previously extracted web 
> resources are not updated
> *Expected Result:* All view's jar should be updated and views resources 
> should be explicitly extracted to update the web content
> Due to this issue, user gets in a situation where views backend is updated 
> but frontend is still using stale bits of earlier version which results in 
> completely broken view in some cases.
> *workaround:*
> Manually stop ambari-server.
> Move the web resources of view to another location
> Start ambari-server back. This will re-extract the jar content and new web 
> resources of the updated ambari version will be then used.



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

[jira] [Updated] (AMBARI-9894) Alerts: YARN YM HA Alerts Are UNKNOWN Due to HA Redirects

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-9894:

Assignee: Jonathan Hurley

> Alerts: YARN YM HA Alerts Are UNKNOWN Due to HA Redirects
> -
>
> Key: AMBARI-9894
> URL: https://issues.apache.org/jira/browse/AMBARI-9894
> Project: Ambari
>  Issue Type: Bug
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: AMBARI-9894.patch
>
>
> 3-node cluster
> Configured ResourceManager HA. Three alerts are now Unknown:
> - ResourceManager RPC Latency. Has two instances as expected but each is 
> unknown "No JSON object could be decoded".
> - NodeManger Health Summary. Has two instances as expected but each is 
> unknown "No JSON object could be decoded".
> - ResourceManager CPU Utiliz. Has two instances as expected but each is 
> unknown "No JSON object could be decoded".
> Both RMs are running and I can quick llink over to RMUI + JMX.
> The reason this fails is because YARN forwards requests for the standby RM to 
> the active one. In this scenario, the alert gets back an HTTP 200 response 
> that looks like:
> {noformat}
> This is standby RM. Redirecting to the current active RM: 
> http://c6403.ambari.apache.org:8088/
> {noformat}
> Unfortunately, this is a refresh header redirect which is not able to be 
> handled by the metric alert. The reason that the alerts work is that after 
> the VMs restarted, the original RM became active again. 
> There are a few issues here:
> - YARN doesn't do HA in the same way that other services like HDFS do. As a 
> result, there's no config property that could let the alert know what to do 
> or which hosts to contact.
> - YARN actually forwards after an HTTP 200 to the active node, which doesn't 
> jive with how alerts works.
> This is a definite problem and requires some further investigation.



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

[jira] [Updated] (AMBARI-9894) Alerts: YARN YM HA Alerts Are UNKNOWN Due to HA Redirects

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-9894:

Fix Version/s: 2.0.0

> Alerts: YARN YM HA Alerts Are UNKNOWN Due to HA Redirects
> -
>
> Key: AMBARI-9894
> URL: https://issues.apache.org/jira/browse/AMBARI-9894
> Project: Ambari
>  Issue Type: Bug
>Reporter: Jonathan Hurley
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: AMBARI-9894.patch
>
>
> 3-node cluster
> Configured ResourceManager HA. Three alerts are now Unknown:
> - ResourceManager RPC Latency. Has two instances as expected but each is 
> unknown "No JSON object could be decoded".
> - NodeManger Health Summary. Has two instances as expected but each is 
> unknown "No JSON object could be decoded".
> - ResourceManager CPU Utiliz. Has two instances as expected but each is 
> unknown "No JSON object could be decoded".
> Both RMs are running and I can quick llink over to RMUI + JMX.
> The reason this fails is because YARN forwards requests for the standby RM to 
> the active one. In this scenario, the alert gets back an HTTP 200 response 
> that looks like:
> {noformat}
> This is standby RM. Redirecting to the current active RM: 
> http://c6403.ambari.apache.org:8088/
> {noformat}
> Unfortunately, this is a refresh header redirect which is not able to be 
> handled by the metric alert. The reason that the alerts work is that after 
> the VMs restarted, the original RM became active again. 
> There are a few issues here:
> - YARN doesn't do HA in the same way that other services like HDFS do. As a 
> result, there's no config property that could let the alert know what to do 
> or which hosts to contact.
> - YARN actually forwards after an HTTP 200 to the active node, which doesn't 
> jive with how alerts works.
> This is a definite problem and requires some further investigation.



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

[jira] [Updated] (AMBARI-10006) Create Upgrade Pack For HDP 2.2 to 2.3

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-10006:
-
Assignee: Jonathan Hurley

> Create Upgrade Pack For HDP 2.2 to 2.3
> --
>
> Key: AMBARI-10006
> URL: https://issues.apache.org/jira/browse/AMBARI-10006
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-server
>Affects Versions: 2.1.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.1.0
>
>
> Create an upgrade pack that contains the necessary steps to upgrade from HDP 
> 2.2 to HDP 2.3.



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

[jira] [Updated] (AMBARI-9817) Deliver set of Views with Ambari 2.1

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-9817:

Assignee: Jeff Sposetti

> Deliver set of Views with Ambari 2.1
> 
>
> Key: AMBARI-9817
> URL: https://issues.apache.org/jira/browse/AMBARI-9817
> Project: Ambari
>  Issue Type: Epic
>  Components: ambari-views
>Affects Versions: 2.1.0
>Reporter: Jeff Sposetti
>Assignee: Jeff Sposetti
> Fix For: 2.1.0
>
>
> Include the following contrib views with Ambari:
> - Pig
> - Hive
> - Files
> - CapScheduler
> This is in addition to the Views already delivered with Ambari:
> - Jobs
> - Slider
> - TezUI



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

[jira] [Reopened] (AMBARI-13039) Optimize precision table Region split policy for AMS

[Siddharth Wagle (JIRA)]

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

Siddharth Wagle reopened AMBARI-13039:
--

Stack advisor script does not execute on changing the memory params.

> Optimize precision table Region split policy for AMS
> 
>
> Key: AMBARI-13039
> URL: https://issues.apache.org/jira/browse/AMBARI-13039
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-metrics
>Affects Versions: 2.1.2
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
>Priority: Critical
> Fix For: 2.1.2
>
>
> - In light of AMBARI-12983, performance would be seen if the precision table 
> can fully utilize the allocated memstore heap.
> - With the single table getting most of the high volume reads and all of the 
> high volume writes it is important to define a policy for splitting the 
> Region in order to optimize performance of the scans.



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

Review Request 38388: Stop-and-Start Upgrade: HDP 2.1->2.3 needs to stop services using 2.1, and start using 2.3

[Alejandro Fernandez]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38388/
---

Review request for Ambari.


Bugs: AMBARI-13052
https://issues.apache.org/jira/browse/AMBARI-13052


Repository: ambari


Description
---

For a Stop-and-Start Upgrade from HDP 2.1 -> 2.3, we need to stop all services 
using the scripts for HDP 2.1, and then start them using HDP 2.3.

Today, during an Upgrade, we currently set the desired stack id when we process 
Upgrade Pack and insert the upgrade record. That means that all start/stop 
commands use the scripts from the desired stack.

Instead, we need a Server Side Action to be called right before we run 
"hdp-select set all" that will change the desired stack id to the new version; 
this will permit stopping on the old version, and starting on the new version.

When we downgrade, we commence the orchestration again, and we again call the 
Server Side Action to change the desired stack id, this time to the starting 
version.


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
 6ac3ed7 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
 a7f206a 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java
 6133885 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
 c73f9d4 
  
ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/UpdateDesiredStackAction.java
 PRE-CREATION 
  
ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeContext.java 
d86210a 
  
ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/Grouping.java
 ec0fabf 
  
ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/ServerActionTask.java
 ea59d65 
  
ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
 c55e1a8 
  
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.2.xml
 01022b8 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UpgradeResourceProviderTest.java
 6708422 

Diff: https://reviews.apache.org/r/38388/diff/


Testing
---

Verified it worked during a Stop-the-World Upgrade.
Waiting for unit test results.


Thanks,

Alejandro Fernandez

[jira] [Reopened] (AMBARI-3409) MSI have to do full rollback in case of interrupted installation

[Yusaku Sako (JIRA)]

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

Yusaku Sako reopened AMBARI-3409:
-

> MSI have to do full rollback in case of interrupted installation
> 
>
> Key: AMBARI-3409
> URL: https://issues.apache.org/jira/browse/AMBARI-3409
> Project: Ambari
>  Issue Type: Improvement
>  Components: contrib
>Reporter: Dmitriy Balykin
>




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

[jira] [Resolved] (AMBARI-11765) Wizard - Confirm Hosts stuck in "Preparing"

[Yusaku Sako (JIRA)]

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

Yusaku Sako resolved AMBARI-11765.
--
Resolution: Invalid

> Wizard - Confirm Hosts stuck in "Preparing"
> ---
>
> Key: AMBARI-11765
> URL: https://issues.apache.org/jira/browse/AMBARI-11765
> Project: Ambari
>  Issue Type: Test
>  Components: ambari-server
>Affects Versions: 2.0.1
> Environment: Ubuntu 12.04 64 bits - HortonWorks Installation
>Reporter: John Robson
>Priority: Trivial
>
> I'm using Ubuntu 12.04 64 bits, my cluster has 4 servers: 00-03; I installed 
> Ambari in the server 00 and I'm trying install the HDP in all servers.
> The problem is in the "Cluster Install Wizard" > "Confirm Hosts". The Wizard 
> is stuck there for hours... only show the Status message: "Preparing" and 
> nothing happen.
> https://i.imgur.com/06M8wm3.png?1



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

[jira] [Updated] (AMBARI-11844) HBase service: Open Connections and Request Handlers widgets does not display with HDP 2.2 stack deployment

[Yusaku Sako (JIRA)]

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

Yusaku Sako updated AMBARI-11844:
-
Assignee: Ivan Kozlov

> HBase service: Open Connections and Request Handlers widgets does not display 
> with HDP 2.2 stack deployment
> ---
>
> Key: AMBARI-11844
> URL: https://issues.apache.org/jira/browse/AMBARI-11844
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.0
>Reporter: Siddharth Wagle
>Assignee: Ivan Kozlov
> Fix For: 2.1.0
>
>
> Looks like metrics regionserver.RegionServer.numOpenConnections, 
> regionserver.RegionServer.numActiveHandler and 
> regionserver.RegionServer.numCallsInGeneralQueue as stated in metrics.json 
> and widget.json for HBase have different names for HDP-2.2 and older stacks 
> (ipc.IPC.numOpenConnections, ipc.IPC.numActiveHandler and 
> ipc.IPC.numCallsInGeneralQueue).
> This will require duplicating present metrics.json file for HBase in HDP-2.3 
> stack HBase service package, then making necessary changes in metrics.json 
> file of common-services HBase in accordance with HDP-2.2 stack.



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