[jira] [Updated] (AMBARI-17415) Ambari configuration for ranger-tagsync needs to support property for atlas keystore filename
[ https://issues.apache.org/jira/browse/AMBARI-17415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-17415: --- Attachment: AMBARI-17415.2.patch > Ambari configuration for ranger-tagsync needs to support property for atlas > keystore filename > - > > Key: AMBARI-17415 > URL: https://issues.apache.org/jira/browse/AMBARI-17415 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Abhay Kulkarni >Assignee: Mugdha Varadkar > Fix For: 2.4.0 > > Attachments: AMBARI-17415.1.patch, AMBARI-17415.2.patch, > AMBARI-17415.patch > > > Ranger-Tagsync configuration with Ambari needs to : > 1. Provide reasonable defaults for Atlas Endpoint (from Atlas URL) and > Atlas-source-download-interval (6) when Atlasrest is selected as > tag-source. > 2. Support properties ranger.tagsync.source.atlasrest.username (default: > admin) and ranger.tagsync.source.atlasrest.keystore.filename(default: > /usr/hdp/current/ranger-tagsync/conf/atlasuser.jceks) in the Advanced > ranger-tagsync-site tab. Without these properties, updatetagadminpassword.py > script fails. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (AMBARI-17632) Issues observed with Zeppelin JDBC interpreter configurations
[ https://issues.apache.org/jira/browse/AMBARI-17632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Renjith Kamath reassigned AMBARI-17632: --- Assignee: Renjith Kamath > Issues observed with Zeppelin JDBC interpreter configurations > - > > Key: AMBARI-17632 > URL: https://issues.apache.org/jira/browse/AMBARI-17632 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Kshitij Badani >Assignee: Renjith Kamath > Fix For: 2.4.0 > > > It is observed that the dependencies for phoenix are not configured in JDBC > interpreter out-of-the-box. A user has to manually configure it > (org.apache.phoenix:phoenix-core:4.4.0-HBase-1.0) and save the interpreter > configurations. > After configuring dependency, Zeppelin does not work with phoenix . > My Zeppelin JDBC interpreter configs corresponding to pheonix are > phoenix.driverorg.apache.phoenix.jdbc.PhoenixDriver > phoenix.hbase.client.retries.number 1 > phoenix.password > phoenix.url jdbc:phoenix::2181:/hbase-unsecure > phoenix.user phoenixuser > When I try to run query: > %jdbc(phoenix) > create table if not exists PRICES ( > SYMBOL varchar(10), > DATE varchar(10), > TIME varchar(10), > OPEN varchar(10), > HIGH varchar(10), > LOWvarchar(10), > CLOSE varchar(10), > VOLUME varchar(30), > CONSTRAINT pk PRIMARY KEY (SYMBOL, DATE, TIME) > ) > It gives PhoenixIOException > class org.apache.phoenix.exception.PhoenixIOException > org.apache.phoenix.util.ServerUtil.parseServerException(ServerUtil.java:108) > org.apache.phoenix.query.ConnectionQueryServicesImpl.ensureTableCreated(ConnectionQueryServicesImpl.java:879) > org.apache.phoenix.query.ConnectionQueryServicesImpl.createTable(ConnectionQueryServicesImpl.java:1213) > org.apache.phoenix.query.DelegateConnectionQueryServices.createTable(DelegateConnectionQueryServices.java:112) > org.apache.phoenix.schema.MetaDataClient.createTableInternal(MetaDataClient.java:1902) > org.apache.phoenix.schema.MetaDataClient.createTable(MetaDataClient.java:744) > org.apache.phoenix.compile.CreateTableCompiler$2.execute(CreateTableCompiler.java:186) > org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:303) > org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:295) > org.apache.phoenix.call.CallRunner.run(CallRunner.java:53) > org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:293) > org.apache.phoenix.jdbc.PhoenixStatement.executeUpdate(PhoenixStatement.java:1236) > org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(ConnectionQueryServicesImpl.java:1891) > org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(ConnectionQueryServicesImpl.java:1860) > org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:77) > org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:1860) > org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:162) > org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.connect(PhoenixEmbeddedDriver.java:131) > org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:133) > java.sql.DriverManager.getConnection(DriverManager.java:571) > java.sql.DriverManager.getConnection(DriverManager.java:187) > org.apache.zeppelin.jdbc.JDBCInterpreter.getConnection(JDBCInterpreter.java:222) > org.apache.zeppelin.jdbc.JDBCInterpreter.getStatement(JDBCInterpreter.java:233) > org.apache.zeppelin.jdbc.JDBCInterpreter.executeSql(JDBCInterpreter.java:292) > org.apache.zeppelin.jdbc.JDBCInterpreter.interpret(JDBCInterpreter.java:396) > org.apache.zeppelin.interpreter.LazyOpenInterpreter.interpret(LazyOpenInterpreter.java:94) > org.apache.zeppelin.interpreter.remote.RemoteInterpreterServer$InterpretJob.jobRun(RemoteInterpreterServer.java:341) > org.apache.zeppelin.scheduler.Job.run(Job.java:176) > org.apache.zeppelin.scheduler.ParallelScheduler$JobRunner.run(ParallelScheduler.java:162) > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > java.util.concurrent.FutureTask.run(FutureTask.java:262) > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17633) yarn.nodemanager.remote-app-log-dir should be added stickybit.
[
https://issues.apache.org/jira/browse/AMBARI-17633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masahiro Tanaka updated AMBARI-17633:
-
Attachment: AMBARI-17633.patch
> yarn.nodemanager.remote-app-log-dir should be added stickybit.
> --
>
> Key: AMBARI-17633
> URL: https://issues.apache.org/jira/browse/AMBARI-17633
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: trunk
> Environment: CentOS7.2 Ambari2.4, HDP2.4
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
> Attachments: AMBARI-17633.patch
>
>
> When installing YARN+MapReduce2, I got a WARN message in nodemanager log(in
> Log Search View) like below
> {code}
> 2016-07-09 06:30:21,865 WARN logaggregation.LogAggregationService
> LogAggregationService.java:230 - Remote Root Log Dir [/app-logs] already
> exist, but with incorrect permissions. Expected: [rwxrwxrwt], Found:
> [rwxrwxrwx]. The cluster may have problems with multiple users.
> {code}
> I think the cause of this WARN is
> [this](https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py#L115).
> We should add stickybit to {{yarn.nodemanager.remote-app-log-dir}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17633) yarn.nodemanager.remote-app-log-dir should be added stickybit.
[
https://issues.apache.org/jira/browse/AMBARI-17633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masahiro Tanaka updated AMBARI-17633:
-
Status: Patch Available (was: Open)
> yarn.nodemanager.remote-app-log-dir should be added stickybit.
> --
>
> Key: AMBARI-17633
> URL: https://issues.apache.org/jira/browse/AMBARI-17633
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: trunk
> Environment: CentOS7.2 Ambari2.4, HDP2.4
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
> Attachments: AMBARI-17633.patch
>
>
> When installing YARN+MapReduce2, I got a WARN message in nodemanager log(in
> Log Search View) like below
> {code}
> 2016-07-09 06:30:21,865 WARN logaggregation.LogAggregationService
> LogAggregationService.java:230 - Remote Root Log Dir [/app-logs] already
> exist, but with incorrect permissions. Expected: [rwxrwxrwt], Found:
> [rwxrwxrwx]. The cluster may have problems with multiple users.
> {code}
> I think the cause of this WARN is
> [this](https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py#L115).
> We should add stickybit to {{yarn.nodemanager.remote-app-log-dir}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17633) yarn.nodemanager.remote-app-log-dir should be added stickybit.
[
https://issues.apache.org/jira/browse/AMBARI-17633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368912#comment-15368912
]
Masahiro Tanaka commented on AMBARI-17633:
--
Submit a patch
> yarn.nodemanager.remote-app-log-dir should be added stickybit.
> --
>
> Key: AMBARI-17633
> URL: https://issues.apache.org/jira/browse/AMBARI-17633
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: trunk
> Environment: CentOS7.2 Ambari2.4, HDP2.4
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
> Attachments: AMBARI-17633.patch
>
>
> When installing YARN+MapReduce2, I got a WARN message in nodemanager log(in
> Log Search View) like below
> {code}
> 2016-07-09 06:30:21,865 WARN logaggregation.LogAggregationService
> LogAggregationService.java:230 - Remote Root Log Dir [/app-logs] already
> exist, but with incorrect permissions. Expected: [rwxrwxrwt], Found:
> [rwxrwxrwx]. The cluster may have problems with multiple users.
> {code}
> I think the cause of this WARN is
> [this](https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py#L115).
> We should add stickybit to {{yarn.nodemanager.remote-app-log-dir}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17631) preinstall-check script should use AMBARI-AGENT REST API for the list of agents
[
https://issues.apache.org/jira/browse/AMBARI-17631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368901#comment-15368901
]
Hadoop QA commented on AMBARI-17631:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12816920/AMBARI-17631.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7754//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7754//console
This message is automatically generated.
> preinstall-check script should use AMBARI-AGENT REST API for the list of
> agents
> ---
>
> Key: AMBARI-17631
> URL: https://issues.apache.org/jira/browse/AMBARI-17631
> Project: Ambari
> Issue Type: Bug
> Components: contrib
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
>Priority: Minor
> Fix For: trunk
>
> Attachments: AMBARI-17631.patch
>
>
> it should use the existing services/AMBARI/components/AMBARI-AGENT rest api
> for the list of agents
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17625) Ambari server log flooded with error messages related to LogSearch service
[
https://issues.apache.org/jira/browse/AMBARI-17625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368892#comment-15368892
]
Hadoop QA commented on AMBARI-17625:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12816925/AMBARI-17625.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
ambari-server:
org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProviderTest
org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProviderForDuplicateUserTest
org.apache.ambari.server.state.ServicePropertiesTest
org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProviderForDNWithSpaceTest
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7753//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7753//console
This message is automatically generated.
> Ambari server log flooded with error messages related to LogSearch service
> --
>
> Key: AMBARI-17625
> URL: https://issues.apache.org/jira/browse/AMBARI-17625
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Miklos Gergely
>Assignee: Miklos Gergely
> Fix For: 2.4.0
>
> Attachments: AMBARI-17625.patch
>
>
> {code:title=ambari-server.log}
> 06 Jul 2016 19:26:28,798 ERROR [ambari-client-thread-2843]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> 06 Jul 2016 19:27:26,865 ERROR [ambari-client-thread-2842]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> 06 Jul 2016 19:28:22,756 ERROR [ambari-client-thread-2699]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> 06 Jul 2016 19:29:10,988 ERROR [ambari-client-thread-2816]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> 06 Jul 2016 19:29:24,700 ERROR [ambari-client-thread-2699]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> {code}
> LogSearch service was not installed on this cluster. But it seems that Ambari
> makes client requests against Logsearch service even when it is not installed
> and keeps logging ERROR messages in ambari-server log
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17633) yarn.nodemanager.remote-app-log-dir should be added stickybit.
[
https://issues.apache.org/jira/browse/AMBARI-17633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masahiro Tanaka updated AMBARI-17633:
-
Description:
When installing YARN+MapReduce2, I got a WARN message in nodemanager log(in Log
Search View) like below
{code}
2016-07-09 06:30:21,865 WARN logaggregation.LogAggregationService
LogAggregationService.java:230 - Remote Root Log Dir [/app-logs] already exist,
but with incorrect permissions. Expected: [rwxrwxrwt], Found: [rwxrwxrwx]. The
cluster may have problems with multiple users.
{code}
I think the cause of this WARN is
[this](https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py#L115).
We should add stickybit to {{yarn.nodemanager.remote-app-log-dir}}.
was:
When installing YARN+MapReduce2, I got a WARN message in nodemanager log like
below
{code}
2016-07-09 06:30:21,865 WARN logaggregation.LogAggregationService
LogAggregationService.java:230 - Remote Root Log Dir [/app-logs] already exist,
but with incorrect permissions. Expected: [rwxrwxrwt], Found: [rwxrwxrwx]. The
cluster may have problems with multiple users.
{code}
I think the cause of this WARN is
[this](https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py#L115).
We should add stickybit to {{yarn.nodemanager.remote-app-log-dir}}.
> yarn.nodemanager.remote-app-log-dir should be added stickybit.
> --
>
> Key: AMBARI-17633
> URL: https://issues.apache.org/jira/browse/AMBARI-17633
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: trunk
> Environment: CentOS7.2 Ambari2.4, HDP2.4
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
>
> When installing YARN+MapReduce2, I got a WARN message in nodemanager log(in
> Log Search View) like below
> {code}
> 2016-07-09 06:30:21,865 WARN logaggregation.LogAggregationService
> LogAggregationService.java:230 - Remote Root Log Dir [/app-logs] already
> exist, but with incorrect permissions. Expected: [rwxrwxrwt], Found:
> [rwxrwxrwx]. The cluster may have problems with multiple users.
> {code}
> I think the cause of this WARN is
> [this](https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py#L115).
> We should add stickybit to {{yarn.nodemanager.remote-app-log-dir}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17623) nimbus.monitor.freq.secs should be 10 sec
[ https://issues.apache.org/jira/browse/AMBARI-17623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satish Duggana updated AMBARI-17623: Status: Patch Available (was: In Progress) > nimbus.monitor.freq.secs should be 10 sec > - > > Key: AMBARI-17623 > URL: https://issues.apache.org/jira/browse/AMBARI-17623 > Project: Ambari > Issue Type: Bug >Reporter: Raghav Kumar Gautam >Assignee: Satish Duggana > Attachments: AMBARI-17623.patch > > > We want value of nimbus.monitor.freq.secs to be set to 10, but the current > value is 120 > https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/STORM/0.9.1/configuration/storm-site.xml#L210 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (AMBARI-17623) nimbus.monitor.freq.secs should be 10 sec
[ https://issues.apache.org/jira/browse/AMBARI-17623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satish Duggana updated AMBARI-17623: Comment: was deleted (was: Patch for this JIRA.) > nimbus.monitor.freq.secs should be 10 sec > - > > Key: AMBARI-17623 > URL: https://issues.apache.org/jira/browse/AMBARI-17623 > Project: Ambari > Issue Type: Bug >Reporter: Raghav Kumar Gautam >Assignee: Satish Duggana > Attachments: AMBARI-17623.patch > > > We want value of nimbus.monitor.freq.secs to be set to 10, but the current > value is 120 > https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/STORM/0.9.1/configuration/storm-site.xml#L210 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17623) nimbus.monitor.freq.secs should be 10 sec
[ https://issues.apache.org/jira/browse/AMBARI-17623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satish Duggana updated AMBARI-17623: Attachment: AMBARI-17623.patch Patch for this JIRA. > nimbus.monitor.freq.secs should be 10 sec > - > > Key: AMBARI-17623 > URL: https://issues.apache.org/jira/browse/AMBARI-17623 > Project: Ambari > Issue Type: Bug >Reporter: Raghav Kumar Gautam >Assignee: Satish Duggana > Attachments: AMBARI-17623.patch > > > We want value of nimbus.monitor.freq.secs to be set to 10, but the current > value is 120 > https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/STORM/0.9.1/configuration/storm-site.xml#L210 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17614) Clean up import * for AMBARI_METRICS services
[
https://issues.apache.org/jira/browse/AMBARI-17614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368831#comment-15368831
]
Hadoop QA commented on AMBARI-17614:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12816904/AMBARI-17614.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The test build failed in ambari-server
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7749//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7749//console
This message is automatically generated.
> Clean up import * for AMBARI_METRICS services
> -
>
> Key: AMBARI-17614
> URL: https://issues.apache.org/jira/browse/AMBARI-17614
> Project: Ambari
> Issue Type: Improvement
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
> Attachments: AMBARI-17614.patch
>
>
> {{ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/status.py}}
> and
> {{ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_monitor.py}}
> uses {{from resource_management import *}}. It increases code tracking
> difficulty.
> I think this is related to AMBARI-16101
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17562) Adding single stack, extension and service should be removed from management pack support
[
https://issues.apache.org/jira/browse/AMBARI-17562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368805#comment-15368805
]
Hadoop QA commented on AMBARI-17562:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12816914/AMBARI-17562.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The test build failed in ambari-server
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7748//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7748//console
This message is automatically generated.
> Adding single stack, extension and service should be removed from management
> pack support
> -
>
> Key: AMBARI-17562
> URL: https://issues.apache.org/jira/browse/AMBARI-17562
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Tim Thorpe
>Assignee: Tim Thorpe
> Attachments: AMBARI-17562.patch
>
>
> This code is duplicated by the ability to add multiple stacks, extensions and
> addon services. There is no reason to maintain both code paths.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368777#comment-15368777
]
Hadoop QA commented on AMBARI-17041:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12816912/AMBARI-17041-trunk-July08.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
ambari-server ambari-web:
org.apache.ambari.server.state.ServicePropertiesTest
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7747//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7747//console
This message is automatically generated.
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17580) Ambari-web unable to automatically add MASTER component with cardinality ALL on all nodes
[ https://issues.apache.org/jira/browse/AMBARI-17580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368771#comment-15368771 ] Hudson commented on AMBARI-17580: - FAILURE: Integrated in Ambari-trunk-Commit #5259 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5259/]) AMBARI-17580. Ambari-web unable to automatically add MASTER component (jaimin: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=93ee6e9af043c4bad4423d47bbed768d7304ef00]) * ambari-web/app/controllers/wizard/step8_controller.js * ambari-web/test/controllers/wizard/step8_test.js > Ambari-web unable to automatically add MASTER component with cardinality ALL > on all nodes > - > > Key: AMBARI-17580 > URL: https://issues.apache.org/jira/browse/AMBARI-17580 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.3.0 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Labels: patch > Fix For: 2.4.0 > > Attachments: AMBARI-17580_branch-2.4.patch > > > While trying to add a MASTER component with cardinality ALL: > org.apache.ambari.server.controller.spi.ResourceAlreadyExistsException: > Attempted to create a host_component which already exists: [clusterName=HDP, > hostName=node1.mydomain.com, componentName=SERVICE_MASTER] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17619) Apply stack advisor result only applicable for the changes being done
[ https://issues.apache.org/jira/browse/AMBARI-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368774#comment-15368774 ] Hudson commented on AMBARI-17619: - FAILURE: Integrated in Ambari-trunk-Commit #5259 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5259/]) AMBARI-17619. Apply stack advisor result only applicable for the changes (hiveww: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=7ab2c06b98af0c3cae7bf77c1f17671b31d25f52]) * ambari-web/app/controllers/wizard/step7_controller.js * ambari-web/app/controllers/main/service/add_controller.js * ambari-web/test/controllers/main/service/add_controller_test.js > Apply stack advisor result only applicable for the changes being done > - > > Key: AMBARI-17619 > URL: https://issues.apache.org/jira/browse/AMBARI-17619 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17619.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17616) Multiple fixes for Atlas integration in versions 0.1.0 and 0.7.0
[
https://issues.apache.org/jira/browse/AMBARI-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368773#comment-15368773
]
Hudson commented on AMBARI-17616:
-
FAILURE: Integrated in Ambari-trunk-Commit #5259 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5259/])
AMBARI-17616. Multiple fixes for Atlas integration in versions 0.1.0 and
(afernandez:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=97b8bb62922b91951bc4a487bd01c8da53288aa2])
*
ambari-server/src/main/resources/stacks/HDP/2.5/services/ATLAS/configuration/application-properties.xml
*
ambari-server/src/main/resources/common-services/ATLAS/0.7.0.2.5/quicklinks/quicklinks.json
*
ambari-common/src/main/python/resource_management/libraries/functions/setup_atlas_hook.py
*
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/themes/theme.json
*
ambari-server/src/main/resources/common-services/ATLAS/0.7.0.2.5/configuration/application-properties.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.5/services/ATLAS/kerberos.json
*
ambari-server/src/main/resources/common-services/ATLAS/0.7.0.2.5/configuration/application-properties.xml.orig
* ambari-server/src/main/resources/stacks/HDP/2.5/services/ATLAS/metainfo.xml
* ambari-server/src/main/resources/common-services/ATLAS/0.7.0.2.5/metainfo.xml
*
ambari-server/src/main/resources/common-services/ATLAS/0.7.0.2.5/themes/theme.json
*
ambari-server/src/main/resources/stacks/HDP/2.5/services/ATLAS/quicklinks/quicklinks.json
* ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py
* ambari-server/src/main/resources/common-services/ATLAS/0.7.0.2.5/kerberos.json
> Multiple fixes for Atlas integration in versions 0.1.0 and 0.7.0
>
>
> Key: AMBARI-17616
> URL: https://issues.apache.org/jira/browse/AMBARI-17616
> Project: Ambari
> Issue Type: Bug
> Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17616.branch-2.4.patch, AMBARI-17616.trunk.patch
>
>
> This Jira contains several fixes.
> 1. Separate Atlas versions 0.1.0 (HDP 2.3 and 2.4), and 0.7.0 (HDP 2.5) for
> Atlas.
> This way, all of the LDAP/AD changes only affect HDP 2.5.
> This means that HDP 2.5 will have the smart configs theme.
> 2. Allow atlas.authentication.method.ldap.type to contain the value "none"
> If the value is none, then do not require any of the LDAP or AD configs.
> Stack advisor must support this change.
> 3. For the LDAP and AD configs that are required, do not allow an empty
> value. Only these 4 LDAP/AD properties can be optional:
> atlas.authentication.method.ldap.referral
> atlas.authentication.method.ldap.default.role
> atlas.authentication.method.ldap.ad.referral
> atlas.authentication.method.ldap.ad.default.role
> 4. Set all of the configs in atlas-application.properties to have,
> {code}
>
> {code}
> 5. When generating the file atlas-application.properties.xml for Hive,
> Falcon, Storm, and Sqoop, only copy a subset of the configs from Atlas'
> application.properties, these configs are
> {code}
> "atlas.kafka.zookeeper.connect",
> "atlas.kafka.bootstrap.servers",
> "atlas.kafka.zookeeper.session.timeout.ms",
> "atlas.kafka.zookeeper.connection.timeout.ms",
> "atlas.kafka.zookeeper.sync.time.ms",
> "atlas.kafka.hook.group.id",
> "atlas.notification.create.topics",
> "atlas.notification.replicas",
> "atlas.notification.topics",
> "atlas.notification.kafka.service.principal",
> "atlas.notification.kafka.keytab.location",
> "atlas.jaas.KafkaClient.loginModuleName",
> "atlas.jaas.KafkaClient.loginModuleControlFlag",
> "atlas.jaas.KafkaClient.option.useKeyTab",
> "atlas.jaas.KafkaClient.option.storeKey",
> "atlas.jaas.KafkaClient.option.serviceName",
> "atlas.jaas.KafkaClient.option.keyTab",
> "atlas.jaas.KafkaClient.option.principal",
> "atlas.cluster.name"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17613) Alerts ordering works incorrect in some cases on Host Alerts page
[ https://issues.apache.org/jira/browse/AMBARI-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368772#comment-15368772 ] Hudson commented on AMBARI-17613: - FAILURE: Integrated in Ambari-trunk-Commit #5259 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5259/]) AMBARI-17613. Alerts ordering works incorrect in some cases on Host (xiwang: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=5bd13d1a2f83422112243e3afc27aba7e66c831a]) * ambari-web/app/views/main/host/host_alerts_view.js * ambari-web/test/views/main/host/host_alerts_view_test.js * ambari-web/app/views/main/alert_definitions_view.js * ambari-web/test/views/main/alert_definitions_view_test.js > Alerts ordering works incorrect in some cases on Host Alerts page > - > > Key: AMBARI-17613 > URL: https://issues.apache.org/jira/browse/AMBARI-17613 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Xi Wang >Assignee: Xi Wang >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17613.patch > > > STR: > # Go to one of hosts > # Navigate to Alerts page (alerts should be sorted by Status) > # Refresh page (sometimes need to refresh page couple times. > Result: alerts does not sorted by Status > Look at the attached video -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
[ https://issues.apache.org/jira/browse/AMBARI-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanth Jayachandran updated AMBARI-17635: --- Status: Open (was: Patch Available) > Disable async logging for HiveServer2 + Hive 2.x > > > Key: AMBARI-17635 > URL: https://issues.apache.org/jira/browse/AMBARI-17635 > Project: Ambari > Issue Type: Bug > Components: HiveServer2, Metastore, and Client Heap Sizes to Smart > Configs, ambari-server, stacks >Affects Versions: 2.4.0 >Reporter: Prasanth Jayachandran >Assignee: Prasanth Jayachandran > Attachments: AMBARI-17635.1.patch, AMBARI-17635.2.patch > > > Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's > use of custom log divert appender. We should disable async logging for HS2 > until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17636) Service Configs page: can't see all config versions in dropdown
[ https://issues.apache.org/jira/browse/AMBARI-17636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vivek Ratnavel Subramanian updated AMBARI-17636: Attachment: AMBARI-17636.v0.patch Local Ambari web test passed. 28944 tests complete (25 seconds) 154 tests pending Manual testing done. > Service Configs page: can't see all config versions in dropdown > --- > > Key: AMBARI-17636 > URL: https://issues.apache.org/jira/browse/AMBARI-17636 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Vivek Ratnavel Subramanian >Assignee: Vivek Ratnavel Subramanian > Fix For: 2.5.0 > > Attachments: AMBARI-17636.v0.patch > > > * Go to Service->Configs page (that have more than ~ 30 versions) > * Open versions dropdown > *Result:* > Number of visible versions limited by window height. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-17636) Service Configs page: can't see all config versions in dropdown
Vivek Ratnavel Subramanian created AMBARI-17636: --- Summary: Service Configs page: can't see all config versions in dropdown Key: AMBARI-17636 URL: https://issues.apache.org/jira/browse/AMBARI-17636 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.4.0 Reporter: Vivek Ratnavel Subramanian Assignee: Vivek Ratnavel Subramanian Fix For: 2.5.0 * Go to Service->Configs page (that have more than ~ 30 versions) * Open versions dropdown *Result:* Number of visible versions limited by window height. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
[ https://issues.apache.org/jira/browse/AMBARI-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanth Jayachandran updated AMBARI-17635: --- Attachment: AMBARI-17635.2.patch > Disable async logging for HiveServer2 + Hive 2.x > > > Key: AMBARI-17635 > URL: https://issues.apache.org/jira/browse/AMBARI-17635 > Project: Ambari > Issue Type: Bug > Components: HiveServer2, Metastore, and Client Heap Sizes to Smart > Configs, ambari-server, stacks >Affects Versions: 2.4.0 >Reporter: Prasanth Jayachandran >Assignee: Prasanth Jayachandran > Attachments: AMBARI-17635.1.patch, AMBARI-17635.2.patch > > > Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's > use of custom log divert appender. We should disable async logging for HS2 > until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
[ https://issues.apache.org/jira/browse/AMBARI-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-17635: Assignee: Prasanth Jayachandran > Disable async logging for HiveServer2 + Hive 2.x > > > Key: AMBARI-17635 > URL: https://issues.apache.org/jira/browse/AMBARI-17635 > Project: Ambari > Issue Type: Bug > Components: HiveServer2, Metastore, and Client Heap Sizes to Smart > Configs, ambari-server, stacks >Affects Versions: 2.4.0 >Reporter: Prasanth Jayachandran >Assignee: Prasanth Jayachandran > Attachments: AMBARI-17635.1.patch > > > Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's > use of custom log divert appender. We should disable async logging for HS2 > until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
[ https://issues.apache.org/jira/browse/AMBARI-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanth Jayachandran updated AMBARI-17635: --- Status: Patch Available (was: Open) > Disable async logging for HiveServer2 + Hive 2.x > > > Key: AMBARI-17635 > URL: https://issues.apache.org/jira/browse/AMBARI-17635 > Project: Ambari > Issue Type: Bug > Components: HiveServer2, Metastore, and Client Heap Sizes to Smart > Configs, ambari-server, stacks >Affects Versions: 2.4.0 >Reporter: Prasanth Jayachandran > Attachments: AMBARI-17635.1.patch > > > Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's > use of custom log divert appender. We should disable async logging for HS2 > until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
[ https://issues.apache.org/jira/browse/AMBARI-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanth Jayachandran updated AMBARI-17635: --- Attachment: AMBARI-17635.1.patch [~jaimin] Can you please review this patch? > Disable async logging for HiveServer2 + Hive 2.x > > > Key: AMBARI-17635 > URL: https://issues.apache.org/jira/browse/AMBARI-17635 > Project: Ambari > Issue Type: Bug > Components: HiveServer2, Metastore, and Client Heap Sizes to Smart > Configs, ambari-server, stacks >Affects Versions: 2.4.0 >Reporter: Prasanth Jayachandran > Attachments: AMBARI-17635.1.patch > > > Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's > use of custom log divert appender. We should disable async logging for HS2 > until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
Prasanth Jayachandran created AMBARI-17635: -- Summary: Disable async logging for HiveServer2 + Hive 2.x Key: AMBARI-17635 URL: https://issues.apache.org/jira/browse/AMBARI-17635 Project: Ambari Issue Type: Bug Components: HiveServer2, Metastore, and Client Heap Sizes to Smart Configs Affects Versions: 2.4.0 Reporter: Prasanth Jayachandran Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's use of custom log divert appender. We should disable async logging for HS2 until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17635) Disable async logging for HiveServer2 + Hive 2.x
[ https://issues.apache.org/jira/browse/AMBARI-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanth Jayachandran updated AMBARI-17635: --- Component/s: stacks ambari-server > Disable async logging for HiveServer2 + Hive 2.x > > > Key: AMBARI-17635 > URL: https://issues.apache.org/jira/browse/AMBARI-17635 > Project: Ambari > Issue Type: Bug > Components: HiveServer2, Metastore, and Client Heap Sizes to Smart > Configs, ambari-server, stacks >Affects Versions: 2.4.0 >Reporter: Prasanth Jayachandran > > Async logging for HS2 is known to have issues (HIVE-14183) because of HS2's > use of custom log divert appender. We should disable async logging for HS2 > until we have a proper fix in hive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17633) yarn.nodemanager.remote-app-log-dir should be added stickybit.
[
https://issues.apache.org/jira/browse/AMBARI-17633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masahiro Tanaka updated AMBARI-17633:
-
Summary: yarn.nodemanager.remote-app-log-dir should be added stickybit.
(was: yarn.nodemanager.remote-app-log-dir)
> yarn.nodemanager.remote-app-log-dir should be added stickybit.
> --
>
> Key: AMBARI-17633
> URL: https://issues.apache.org/jira/browse/AMBARI-17633
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: trunk
> Environment: CentOS7.2 Ambari2.4, HDP2.4
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
>
> When installing YARN+MapReduce2, I got a WARN message in nodemanager log like
> below
> {code}
> 2016-07-09 06:30:21,865 WARN logaggregation.LogAggregationService
> LogAggregationService.java:230 - Remote Root Log Dir [/app-logs] already
> exist, but with incorrect permissions. Expected: [rwxrwxrwt], Found:
> [rwxrwxrwx]. The cluster may have problems with multiple users.
> {code}
> I think the cause of this WARN is
> [this](https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py#L115).
> We should add stickybit to {{yarn.nodemanager.remote-app-log-dir}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17627) Enable Zeppelin authentication via Ambari by default for secure cluster
[ https://issues.apache.org/jira/browse/AMBARI-17627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yesha Vora updated AMBARI-17627: Summary: Enable Zeppelin authentication via Ambari by default for secure cluster (was: Enable Zeppelin authentication via Ambari by default for secure clu) > Enable Zeppelin authentication via Ambari by default for secure cluster > --- > > Key: AMBARI-17627 > URL: https://issues.apache.org/jira/browse/AMBARI-17627 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Yesha Vora > > Ambari should setup zeppelin authentication by default for secure clusters. > In secure env, > * Ambari should setup zeppelin authentication by default. > * Zeppelin quick link should automatically login in Zeppelin UI as Ambari > user. > * If Ambari user do not have view permission for Zeppelin UI, Quick link for > Zeppelin UI should be disabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17634) Logfeeder is not starting with non-root agent install
[ https://issues.apache.org/jira/browse/AMBARI-17634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivér Szabó updated AMBARI-17634: -- Summary: Logfeeder is not starting with non-root agent install (was: Logfeeder is not starting with non-root install) > Logfeeder is not starting with non-root agent install > - > > Key: AMBARI-17634 > URL: https://issues.apache.org/jira/browse/AMBARI-17634 > Project: Ambari > Issue Type: Bug > Components: ambari-logsearch >Affects Versions: 2.4.0 >Reporter: Olivér Szabó >Assignee: Olivér Szabó >Priority: Critical > Fix For: 2.4.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-17634) Logfeeder is not starting with non-root install
Olivér Szabó created AMBARI-17634: - Summary: Logfeeder is not starting with non-root install Key: AMBARI-17634 URL: https://issues.apache.org/jira/browse/AMBARI-17634 Project: Ambari Issue Type: Bug Components: ambari-logsearch Affects Versions: 2.4.0 Reporter: Olivér Szabó Assignee: Olivér Szabó Priority: Critical Fix For: 2.4.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-17633) yarn.nodemanager.remote-app-log-dir
Masahiro Tanaka created AMBARI-17633:
Summary: yarn.nodemanager.remote-app-log-dir
Key: AMBARI-17633
URL: https://issues.apache.org/jira/browse/AMBARI-17633
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: trunk
Environment: CentOS7.2 Ambari2.4, HDP2.4
Reporter: Masahiro Tanaka
Assignee: Masahiro Tanaka
When installing YARN+MapReduce2, I got a WARN message in nodemanager log like
below
{{
2016-07-09 06:30:21,865 WARN logaggregation.LogAggregationService
LogAggregationService.java:230 - Remote Root Log Dir [/app-logs] already exist,
but with incorrect permissions. Expected: [rwxrwxrwt], Found: [rwxrwxrwx]. The
cluster may have problems with multiple users.
}}
I think the cause of this WARN is
[this](https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py#L115).
We should add stickybit to {{yarn.nodemanager.remote-app-log-dir}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17633) yarn.nodemanager.remote-app-log-dir
[
https://issues.apache.org/jira/browse/AMBARI-17633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masahiro Tanaka updated AMBARI-17633:
-
Description:
When installing YARN+MapReduce2, I got a WARN message in nodemanager log like
below
{code}
2016-07-09 06:30:21,865 WARN logaggregation.LogAggregationService
LogAggregationService.java:230 - Remote Root Log Dir [/app-logs] already exist,
but with incorrect permissions. Expected: [rwxrwxrwt], Found: [rwxrwxrwx]. The
cluster may have problems with multiple users.
{code}
I think the cause of this WARN is
[this](https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py#L115).
We should add stickybit to {{yarn.nodemanager.remote-app-log-dir}}.
was:
When installing YARN+MapReduce2, I got a WARN message in nodemanager log like
below
{{
2016-07-09 06:30:21,865 WARN logaggregation.LogAggregationService
LogAggregationService.java:230 - Remote Root Log Dir [/app-logs] already exist,
but with incorrect permissions. Expected: [rwxrwxrwt], Found: [rwxrwxrwx]. The
cluster may have problems with multiple users.
}}
I think the cause of this WARN is
[this](https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py#L115).
We should add stickybit to {{yarn.nodemanager.remote-app-log-dir}}.
> yarn.nodemanager.remote-app-log-dir
> ---
>
> Key: AMBARI-17633
> URL: https://issues.apache.org/jira/browse/AMBARI-17633
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: trunk
> Environment: CentOS7.2 Ambari2.4, HDP2.4
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
>
> When installing YARN+MapReduce2, I got a WARN message in nodemanager log like
> below
> {code}
> 2016-07-09 06:30:21,865 WARN logaggregation.LogAggregationService
> LogAggregationService.java:230 - Remote Root Log Dir [/app-logs] already
> exist, but with incorrect permissions. Expected: [rwxrwxrwt], Found:
> [rwxrwxrwx]. The cluster may have problems with multiple users.
> {code}
> I think the cause of this WARN is
> [this](https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py#L115).
> We should add stickybit to {{yarn.nodemanager.remote-app-log-dir}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368586#comment-15368586
]
Keta Patel commented on AMBARI-17626:
-
Updated the patch "AMBARI-17626-July08.patch" to include fix for the tests
failing in the last Hadoop QA run.
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Patch Available (was: Open)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Open (was: Patch Available)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Attachment: AMBARI-17626-July08.patch
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-17632) Issues observed with Zeppelin JDBC interpreter configurations
Kshitij Badani created AMBARI-17632: --- Summary: Issues observed with Zeppelin JDBC interpreter configurations Key: AMBARI-17632 URL: https://issues.apache.org/jira/browse/AMBARI-17632 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.4.0 Reporter: Kshitij Badani Fix For: 2.4.0 It is observed that the dependencies for phoenix are not configured in JDBC interpreter out-of-the-box. A user has to manually configure it (org.apache.phoenix:phoenix-core:4.4.0-HBase-1.0) and save the interpreter configurations. After configuring dependency, Zeppelin does not work with phoenix . My Zeppelin JDBC interpreter configs corresponding to pheonix are phoenix.driver org.apache.phoenix.jdbc.PhoenixDriver phoenix.hbase.client.retries.number 1 phoenix.password phoenix.url jdbc:phoenix::2181:/hbase-unsecure phoenix.userphoenixuser When I try to run query: %jdbc(phoenix) create table if not exists PRICES ( SYMBOL varchar(10), DATE varchar(10), TIME varchar(10), OPEN varchar(10), HIGH varchar(10), LOWvarchar(10), CLOSE varchar(10), VOLUME varchar(30), CONSTRAINT pk PRIMARY KEY (SYMBOL, DATE, TIME) ) It gives PhoenixIOException class org.apache.phoenix.exception.PhoenixIOException org.apache.phoenix.util.ServerUtil.parseServerException(ServerUtil.java:108) org.apache.phoenix.query.ConnectionQueryServicesImpl.ensureTableCreated(ConnectionQueryServicesImpl.java:879) org.apache.phoenix.query.ConnectionQueryServicesImpl.createTable(ConnectionQueryServicesImpl.java:1213) org.apache.phoenix.query.DelegateConnectionQueryServices.createTable(DelegateConnectionQueryServices.java:112) org.apache.phoenix.schema.MetaDataClient.createTableInternal(MetaDataClient.java:1902) org.apache.phoenix.schema.MetaDataClient.createTable(MetaDataClient.java:744) org.apache.phoenix.compile.CreateTableCompiler$2.execute(CreateTableCompiler.java:186) org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:303) org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:295) org.apache.phoenix.call.CallRunner.run(CallRunner.java:53) org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:293) org.apache.phoenix.jdbc.PhoenixStatement.executeUpdate(PhoenixStatement.java:1236) org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(ConnectionQueryServicesImpl.java:1891) org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(ConnectionQueryServicesImpl.java:1860) org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:77) org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:1860) org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:162) org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.connect(PhoenixEmbeddedDriver.java:131) org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:133) java.sql.DriverManager.getConnection(DriverManager.java:571) java.sql.DriverManager.getConnection(DriverManager.java:187) org.apache.zeppelin.jdbc.JDBCInterpreter.getConnection(JDBCInterpreter.java:222) org.apache.zeppelin.jdbc.JDBCInterpreter.getStatement(JDBCInterpreter.java:233) org.apache.zeppelin.jdbc.JDBCInterpreter.executeSql(JDBCInterpreter.java:292) org.apache.zeppelin.jdbc.JDBCInterpreter.interpret(JDBCInterpreter.java:396) org.apache.zeppelin.interpreter.LazyOpenInterpreter.interpret(LazyOpenInterpreter.java:94) org.apache.zeppelin.interpreter.remote.RemoteInterpreterServer$InterpretJob.jobRun(RemoteInterpreterServer.java:341) org.apache.zeppelin.scheduler.Job.run(Job.java:176) org.apache.zeppelin.scheduler.ParallelScheduler$JobRunner.run(ParallelScheduler.java:162) java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) java.util.concurrent.FutureTask.run(FutureTask.java:262) java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17625) Ambari server log flooded with error messages related to LogSearch service
[
https://issues.apache.org/jira/browse/AMBARI-17625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Miklos Gergely updated AMBARI-17625:
Status: Patch Available (was: In Progress)
> Ambari server log flooded with error messages related to LogSearch service
> --
>
> Key: AMBARI-17625
> URL: https://issues.apache.org/jira/browse/AMBARI-17625
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Miklos Gergely
>Assignee: Miklos Gergely
> Fix For: 2.4.0
>
> Attachments: AMBARI-17625.patch
>
>
> {code:title=ambari-server.log}
> 06 Jul 2016 19:26:28,798 ERROR [ambari-client-thread-2843]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> 06 Jul 2016 19:27:26,865 ERROR [ambari-client-thread-2842]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> 06 Jul 2016 19:28:22,756 ERROR [ambari-client-thread-2699]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> 06 Jul 2016 19:29:10,988 ERROR [ambari-client-thread-2816]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> 06 Jul 2016 19:29:24,700 ERROR [ambari-client-thread-2699]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> {code}
> LogSearch service was not installed on this cluster. But it seems that Ambari
> makes client requests against Logsearch service even when it is not installed
> and keeps logging ERROR messages in ambari-server log
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17625) Ambari server log flooded with error messages related to LogSearch service
[
https://issues.apache.org/jira/browse/AMBARI-17625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Miklos Gergely updated AMBARI-17625:
Attachment: AMBARI-17625.patch
> Ambari server log flooded with error messages related to LogSearch service
> --
>
> Key: AMBARI-17625
> URL: https://issues.apache.org/jira/browse/AMBARI-17625
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Miklos Gergely
>Assignee: Miklos Gergely
> Fix For: 2.4.0
>
> Attachments: AMBARI-17625.patch
>
>
> {code:title=ambari-server.log}
> 06 Jul 2016 19:26:28,798 ERROR [ambari-client-thread-2843]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> 06 Jul 2016 19:27:26,865 ERROR [ambari-client-thread-2842]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> 06 Jul 2016 19:28:22,756 ERROR [ambari-client-thread-2699]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> 06 Jul 2016 19:29:10,988 ERROR [ambari-client-thread-2816]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> 06 Jul 2016 19:29:24,700 ERROR [ambari-client-thread-2699]
> LoggingSearchPropertyProvider:59 - Error occurred while making request to
> LogSearch service, unable to populate logging properties on this resource
> {code}
> LogSearch service was not installed on this cluster. But it seems that Ambari
> makes client requests against Logsearch service even when it is not installed
> and keeps logging ERROR messages in ambari-server log
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17623) nimbus.monitor.freq.secs should be 10 sec
[ https://issues.apache.org/jira/browse/AMBARI-17623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated AMBARI-17623: --- Assignee: Satish Duggana > nimbus.monitor.freq.secs should be 10 sec > - > > Key: AMBARI-17623 > URL: https://issues.apache.org/jira/browse/AMBARI-17623 > Project: Ambari > Issue Type: Bug >Reporter: Raghav Kumar Gautam >Assignee: Satish Duggana > > We want value of nimbus.monitor.freq.secs to be set to 10, but the current > value is 120 > https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/STORM/0.9.1/configuration/storm-site.xml#L210 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368528#comment-15368528
]
Hadoop QA commented on AMBARI-17626:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12816874/AMBARI-17626.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
ambari-server:
org.apache.ambari.server.controller.internal.ProvisionClusterRequestTest
org.apache.ambari.server.state.ServicePropertiesTest
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7746//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7746//console
This message is automatically generated.
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17465) Management packs should be able to install extensions
[
https://issues.apache.org/jira/browse/AMBARI-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368536#comment-15368536
]
Hudson commented on AMBARI-17465:
-
ABORTED: Integrated in Ambari-trunk-Commit #5258 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5258/])
AMBARI-17465: Management packs should be able to install extensions (Tim
(jluniya:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=587050eacfca697eeecb55be238823f7843eb003])
* ambari-server/src/test/python/TestMpacks.py
* ambari-server/src/test/python/mpacks/myservice-ambari-mpack-1.0.0.0/mpack.json
* ambari-server/conf/unix/ambari.properties
* ambari-server/src/main/python/ambari_server/setupMpacks.py
*
ambari-server/src/test/python/mpacks/myextension-ambari-mpack-1.0.0.0/extensions/MYEXTENSION/1.1/metainfo.xml
*
ambari-server/src/test/python/mpacks/myextension-ambari-mpack-1.0.0.0/mpack.json
* ambari-server/src/main/python/ambari_server/serverConfiguration.py
*
ambari-server/src/test/python/mpacks/myextension-ambari-mpack-1.0.0.0/extensions/MYEXTENSION/1.0/metainfo.xml
> Management packs should be able to install extensions
> -
>
> Key: AMBARI-17465
> URL: https://issues.apache.org/jira/browse/AMBARI-17465
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Tim Thorpe
>Assignee: Tim Thorpe
> Fix For: 2.4.0
>
> Attachments: AMBARI-17465.patch
>
>
> Currently management packs (AMBARI-14854) can only add stacks and addon
> services. Now that AMBARI-12885 has been resolved, the management packs
> should be able to add extensions as well. This would allow the following
> mpack.json:
> {
> "type" : "fullrelease",
> "name" : "MyExtension",
> "version": "1.0.0.0",
> "description" : "My Management Pack",
> "prerequisites": {
> "minambariversion" : "2.4"
> },
> "artifacts": [
> {
> "name" : "EXT-extension",
> "type" : "extension-definition",
> "source_dir": "extensions/EXT/1.0",
> "extension_name" : "EXT",
> "extension_version" : "1.0"
> }
> ]
> }
> or alternately with extension-definitions (which will include all extensions
> listed in the extensions directory):
> "artifacts": [
> {
> "name" : "MyExtensions",
> "type" : "extension-definitions",
> "source_dir": "extensions"
> }
> ]
> myext-mpack1.0.0.0
> ├── mpack.json
> └── extensions
> └── EXT
> └── 1.0
> └── metainfo.xml
> └── services
> └── HAWQ
> └── metainfo.xml
> └── PXF
> └── metainfo.xml
> It could then be installed with the following command:
> ambari-server install-mpack --mpack=/tmp/myext-mpack1.0.0.0.tar.gz -v
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17631) preinstall-check script should use AMBARI-AGENT REST API for the list of agents
[ https://issues.apache.org/jira/browse/AMBARI-17631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Di Li updated AMBARI-17631: --- Status: Patch Available (was: Open) > preinstall-check script should use AMBARI-AGENT REST API for the list of > agents > --- > > Key: AMBARI-17631 > URL: https://issues.apache.org/jira/browse/AMBARI-17631 > Project: Ambari > Issue Type: Bug > Components: contrib >Affects Versions: trunk >Reporter: Di Li >Assignee: Di Li >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-17631.patch > > > it should use the existing services/AMBARI/components/AMBARI-AGENT rest api > for the list of agents -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17631) preinstall-check script should use AMBARI-AGENT REST API for the list of agents
[ https://issues.apache.org/jira/browse/AMBARI-17631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Di Li updated AMBARI-17631: --- Attachment: AMBARI-17631.patch > preinstall-check script should use AMBARI-AGENT REST API for the list of > agents > --- > > Key: AMBARI-17631 > URL: https://issues.apache.org/jira/browse/AMBARI-17631 > Project: Ambari > Issue Type: Bug > Components: contrib >Affects Versions: trunk >Reporter: Di Li >Assignee: Di Li >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-17631.patch > > > it should use the existing services/AMBARI/components/AMBARI-AGENT rest api > for the list of agents -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-17631) preinstall-check script should use AMBARI-AGENT REST API for the list of agents
Di Li created AMBARI-17631: -- Summary: preinstall-check script should use AMBARI-AGENT REST API for the list of agents Key: AMBARI-17631 URL: https://issues.apache.org/jira/browse/AMBARI-17631 Project: Ambari Issue Type: Bug Components: contrib Affects Versions: trunk Reporter: Di Li Assignee: Di Li Priority: Minor Fix For: trunk it should use the existing services/AMBARI/components/AMBARI-AGENT rest api for the list of agents -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368487#comment-15368487
]
Keta Patel commented on AMBARI-17041:
-
Uploaded new patch "AMBARI-17041-trunk-July08.patch" to include the feature of
selecting multiple values for the custom property.
For Password type custom properties, the blueprints will be contain these
custom properties with their values masked. The blueprint would have to be
updated to replace the masking with their desired values (similar to how it
happens currently for Password properties present in the XML properties files).
Installation of new cluster using this modified blueprint should show the
Password custom properties masked on the UI. This currently doesn't happen due
to a bug with blueprint registration. AMBARI-17626 tracks this issue.
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17562) Adding single stack, extension and service should be removed from management pack support
[ https://issues.apache.org/jira/browse/AMBARI-17562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Thorpe updated AMBARI-17562: Status: Patch Available (was: Open) > Adding single stack, extension and service should be removed from management > pack support > - > > Key: AMBARI-17562 > URL: https://issues.apache.org/jira/browse/AMBARI-17562 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Tim Thorpe >Assignee: Tim Thorpe > Attachments: AMBARI-17562.patch > > > This code is duplicated by the ability to add multiple stacks, extensions and > addon services. There is no reason to maintain both code paths. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17562) Adding single stack, extension and service should be removed from management pack support
[ https://issues.apache.org/jira/browse/AMBARI-17562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Thorpe updated AMBARI-17562: Attachment: AMBARI-17562.patch > Adding single stack, extension and service should be removed from management > pack support > - > > Key: AMBARI-17562 > URL: https://issues.apache.org/jira/browse/AMBARI-17562 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Tim Thorpe >Assignee: Tim Thorpe > Attachments: AMBARI-17562.patch > > > This code is duplicated by the ability to add multiple stacks, extensions and > addon services. There is no reason to maintain both code paths. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Attachment: AMBARI-17041-trunk-July08.patch
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Status: Patch Available (was: Open)
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Status: Open (was: Patch Available)
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17614) Clean up import * for AMBARI_METRICS services
[
https://issues.apache.org/jira/browse/AMBARI-17614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masahiro Tanaka updated AMBARI-17614:
-
Status: Patch Available (was: Open)
> Clean up import * for AMBARI_METRICS services
> -
>
> Key: AMBARI-17614
> URL: https://issues.apache.org/jira/browse/AMBARI-17614
> Project: Ambari
> Issue Type: Improvement
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
> Attachments: AMBARI-17614.patch
>
>
> {{ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/status.py}}
> and
> {{ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_monitor.py}}
> uses {{from resource_management import *}}. It increases code tracking
> difficulty.
> I think this is related to AMBARI-16101
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17614) Clean up import * for AMBARI_METRICS services
[
https://issues.apache.org/jira/browse/AMBARI-17614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368437#comment-15368437
]
Masahiro Tanaka commented on AMBARI-17614:
--
Submit a patch
> Clean up import * for AMBARI_METRICS services
> -
>
> Key: AMBARI-17614
> URL: https://issues.apache.org/jira/browse/AMBARI-17614
> Project: Ambari
> Issue Type: Improvement
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
> Attachments: AMBARI-17614.patch
>
>
> {{ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/status.py}}
> and
> {{ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_monitor.py}}
> uses {{from resource_management import *}}. It increases code tracking
> difficulty.
> I think this is related to AMBARI-16101
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17614) Clean up import * for AMBARI_METRICS services
[
https://issues.apache.org/jira/browse/AMBARI-17614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masahiro Tanaka updated AMBARI-17614:
-
Attachment: AMBARI-17614.patch
> Clean up import * for AMBARI_METRICS services
> -
>
> Key: AMBARI-17614
> URL: https://issues.apache.org/jira/browse/AMBARI-17614
> Project: Ambari
> Issue Type: Improvement
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
> Attachments: AMBARI-17614.patch
>
>
> {{ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/status.py}}
> and
> {{ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_monitor.py}}
> uses {{from resource_management import *}}. It increases code tracking
> difficulty.
> I think this is related to AMBARI-16101
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17580) Ambari-web unable to automatically add MASTER component with cardinality ALL on all nodes
[ https://issues.apache.org/jira/browse/AMBARI-17580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-17580: Resolution: Fixed Status: Resolved (was: Patch Available) Patch committed to trunk and branch-2.4 > Ambari-web unable to automatically add MASTER component with cardinality ALL > on all nodes > - > > Key: AMBARI-17580 > URL: https://issues.apache.org/jira/browse/AMBARI-17580 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.3.0 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Labels: patch > Fix For: 2.4.0 > > Attachments: AMBARI-17580_branch-2.4.patch > > > While trying to add a MASTER component with cardinality ALL: > org.apache.ambari.server.controller.spi.ResourceAlreadyExistsException: > Attempted to create a host_component which already exists: [clusterName=HDP, > hostName=node1.mydomain.com, componentName=SERVICE_MASTER] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17580) Ambari-web unable to automatically add MASTER component with cardinality ALL on all nodes
[ https://issues.apache.org/jira/browse/AMBARI-17580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-17580: Summary: Ambari-web unable to automatically add MASTER component with cardinality ALL on all nodes (was: Unable to add MASTER component on all nodes) > Ambari-web unable to automatically add MASTER component with cardinality ALL > on all nodes > - > > Key: AMBARI-17580 > URL: https://issues.apache.org/jira/browse/AMBARI-17580 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.3.0 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Labels: patch > Fix For: 2.4.0 > > Attachments: AMBARI-17580_branch-2.4.patch > > > While trying to add a MASTER component with cardinality ALL: > org.apache.ambari.server.controller.spi.ResourceAlreadyExistsException: > Attempted to create a host_component which already exists: [clusterName=HDP, > hostName=node1.mydomain.com, componentName=SERVICE_MASTER] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17253) Ambari Alert causes too many wanings in ZooKeeper logs.
[
https://issues.apache.org/jira/browse/AMBARI-17253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masahiro Tanaka updated AMBARI-17253:
-
Attachment: AMBARI-17253.5.patch
> Ambari Alert causes too many wanings in ZooKeeper logs.
> ---
>
> Key: AMBARI-17253
> URL: https://issues.apache.org/jira/browse/AMBARI-17253
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent
>Affects Versions: trunk
>Reporter: Masahiro Tanaka
>Assignee: Masahiro Tanaka
> Attachments: AMBARI-17253.1.patch, AMBARI-17253.2.patch,
> AMBARI-17253.3.patch, AMBARI-17253.4.patch, AMBARI-17253.5.patch,
> AMBARI-17253.patch
>
>
> There are too many WARNING in ZooKeeper log.
> {code}
> 2016-06-15 21:02:15,405 - WARN
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@357] - caught end of
> stream exception
> EndOfStreamException: Unable to read additional data from client sessionid
> 0x0, likely client has closed socket
> at
> org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:228)
> at
> org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> It may be because of Ambari Alert. Ambari Alert pings to the zookeeper port
> to do monitoring.
> We should use 'ruok' to monitor zookeepers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-17630) CSS Issue preventing mobile device control
Mark Cohen created AMBARI-17630: --- Summary: CSS Issue preventing mobile device control Key: AMBARI-17630 URL: https://issues.apache.org/jira/browse/AMBARI-17630 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.2.1 Reporter: Mark Cohen I'm unable to click elements in drop-down menus in Ambari on any mobile device. Tested Devices : Apple iPad Pro, Apple iPhone 6, Google Nexus 6p Browsers tested : Mobile Safari, Mobile Chrome, Mobile Firefox This makes remote management impossible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17616) Multiple fixes for Atlas integration in versions 0.1.0 and 0.7.0
[
https://issues.apache.org/jira/browse/AMBARI-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Fernandez updated AMBARI-17616:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
Pushed to trunk, commit 97b8bb62922b91951bc4a487bd01c8da53288aa2
branch-2.4, commit 43785d4183a50f1094708185bd6622789a56c9d1
> Multiple fixes for Atlas integration in versions 0.1.0 and 0.7.0
>
>
> Key: AMBARI-17616
> URL: https://issues.apache.org/jira/browse/AMBARI-17616
> Project: Ambari
> Issue Type: Bug
> Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17616.branch-2.4.patch, AMBARI-17616.trunk.patch
>
>
> This Jira contains several fixes.
> 1. Separate Atlas versions 0.1.0 (HDP 2.3 and 2.4), and 0.7.0 (HDP 2.5) for
> Atlas.
> This way, all of the LDAP/AD changes only affect HDP 2.5.
> This means that HDP 2.5 will have the smart configs theme.
> 2. Allow atlas.authentication.method.ldap.type to contain the value "none"
> If the value is none, then do not require any of the LDAP or AD configs.
> Stack advisor must support this change.
> 3. For the LDAP and AD configs that are required, do not allow an empty
> value. Only these 4 LDAP/AD properties can be optional:
> atlas.authentication.method.ldap.referral
> atlas.authentication.method.ldap.default.role
> atlas.authentication.method.ldap.ad.referral
> atlas.authentication.method.ldap.ad.default.role
> 4. Set all of the configs in atlas-application.properties to have,
> {code}
>
> {code}
> 5. When generating the file atlas-application.properties.xml for Hive,
> Falcon, Storm, and Sqoop, only copy a subset of the configs from Atlas'
> application.properties, these configs are
> {code}
> "atlas.kafka.zookeeper.connect",
> "atlas.kafka.bootstrap.servers",
> "atlas.kafka.zookeeper.session.timeout.ms",
> "atlas.kafka.zookeeper.connection.timeout.ms",
> "atlas.kafka.zookeeper.sync.time.ms",
> "atlas.kafka.hook.group.id",
> "atlas.notification.create.topics",
> "atlas.notification.replicas",
> "atlas.notification.topics",
> "atlas.notification.kafka.service.principal",
> "atlas.notification.kafka.keytab.location",
> "atlas.jaas.KafkaClient.loginModuleName",
> "atlas.jaas.KafkaClient.loginModuleControlFlag",
> "atlas.jaas.KafkaClient.option.useKeyTab",
> "atlas.jaas.KafkaClient.option.storeKey",
> "atlas.jaas.KafkaClient.option.serviceName",
> "atlas.jaas.KafkaClient.option.keyTab",
> "atlas.jaas.KafkaClient.option.principal",
> "atlas.cluster.name"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17616) Multiple fixes for Atlas integration in versions 0.1.0 and 0.7.0
[
https://issues.apache.org/jira/browse/AMBARI-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Fernandez updated AMBARI-17616:
-
Attachment: AMBARI-17616.branch-2.4.patch
AMBARI-17616.trunk.patch
> Multiple fixes for Atlas integration in versions 0.1.0 and 0.7.0
>
>
> Key: AMBARI-17616
> URL: https://issues.apache.org/jira/browse/AMBARI-17616
> Project: Ambari
> Issue Type: Bug
> Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17616.branch-2.4.patch, AMBARI-17616.trunk.patch
>
>
> This Jira contains several fixes.
> 1. Separate Atlas versions 0.1.0 (HDP 2.3 and 2.4), and 0.7.0 (HDP 2.5) for
> Atlas.
> This way, all of the LDAP/AD changes only affect HDP 2.5.
> This means that HDP 2.5 will have the smart configs theme.
> 2. Allow atlas.authentication.method.ldap.type to contain the value "none"
> If the value is none, then do not require any of the LDAP or AD configs.
> Stack advisor must support this change.
> 3. For the LDAP and AD configs that are required, do not allow an empty
> value. Only these 4 LDAP/AD properties can be optional:
> atlas.authentication.method.ldap.referral
> atlas.authentication.method.ldap.default.role
> atlas.authentication.method.ldap.ad.referral
> atlas.authentication.method.ldap.ad.default.role
> 4. Set all of the configs in atlas-application.properties to have,
> {code}
>
> {code}
> 5. When generating the file atlas-application.properties.xml for Hive,
> Falcon, Storm, and Sqoop, only copy a subset of the configs from Atlas'
> application.properties, these configs are
> {code}
> "atlas.kafka.zookeeper.connect",
> "atlas.kafka.bootstrap.servers",
> "atlas.kafka.zookeeper.session.timeout.ms",
> "atlas.kafka.zookeeper.connection.timeout.ms",
> "atlas.kafka.zookeeper.sync.time.ms",
> "atlas.kafka.hook.group.id",
> "atlas.notification.create.topics",
> "atlas.notification.replicas",
> "atlas.notification.topics",
> "atlas.notification.kafka.service.principal",
> "atlas.notification.kafka.keytab.location",
> "atlas.jaas.KafkaClient.loginModuleName",
> "atlas.jaas.KafkaClient.loginModuleControlFlag",
> "atlas.jaas.KafkaClient.option.useKeyTab",
> "atlas.jaas.KafkaClient.option.storeKey",
> "atlas.jaas.KafkaClient.option.serviceName",
> "atlas.jaas.KafkaClient.option.keyTab",
> "atlas.jaas.KafkaClient.option.principal",
> "atlas.cluster.name"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17616) Multiple fixes for Atlas integration in versions 0.1.0 and 0.7.0
[
https://issues.apache.org/jira/browse/AMBARI-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Fernandez updated AMBARI-17616:
-
Status: Patch Available (was: Open)
> Multiple fixes for Atlas integration in versions 0.1.0 and 0.7.0
>
>
> Key: AMBARI-17616
> URL: https://issues.apache.org/jira/browse/AMBARI-17616
> Project: Ambari
> Issue Type: Bug
> Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17616.branch-2.4.patch, AMBARI-17616.trunk.patch
>
>
> This Jira contains several fixes.
> 1. Separate Atlas versions 0.1.0 (HDP 2.3 and 2.4), and 0.7.0 (HDP 2.5) for
> Atlas.
> This way, all of the LDAP/AD changes only affect HDP 2.5.
> This means that HDP 2.5 will have the smart configs theme.
> 2. Allow atlas.authentication.method.ldap.type to contain the value "none"
> If the value is none, then do not require any of the LDAP or AD configs.
> Stack advisor must support this change.
> 3. For the LDAP and AD configs that are required, do not allow an empty
> value. Only these 4 LDAP/AD properties can be optional:
> atlas.authentication.method.ldap.referral
> atlas.authentication.method.ldap.default.role
> atlas.authentication.method.ldap.ad.referral
> atlas.authentication.method.ldap.ad.default.role
> 4. Set all of the configs in atlas-application.properties to have,
> {code}
>
> {code}
> 5. When generating the file atlas-application.properties.xml for Hive,
> Falcon, Storm, and Sqoop, only copy a subset of the configs from Atlas'
> application.properties, these configs are
> {code}
> "atlas.kafka.zookeeper.connect",
> "atlas.kafka.bootstrap.servers",
> "atlas.kafka.zookeeper.session.timeout.ms",
> "atlas.kafka.zookeeper.connection.timeout.ms",
> "atlas.kafka.zookeeper.sync.time.ms",
> "atlas.kafka.hook.group.id",
> "atlas.notification.create.topics",
> "atlas.notification.replicas",
> "atlas.notification.topics",
> "atlas.notification.kafka.service.principal",
> "atlas.notification.kafka.keytab.location",
> "atlas.jaas.KafkaClient.loginModuleName",
> "atlas.jaas.KafkaClient.loginModuleControlFlag",
> "atlas.jaas.KafkaClient.option.useKeyTab",
> "atlas.jaas.KafkaClient.option.storeKey",
> "atlas.jaas.KafkaClient.option.serviceName",
> "atlas.jaas.KafkaClient.option.keyTab",
> "atlas.jaas.KafkaClient.option.principal",
> "atlas.cluster.name"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17616) Multiple fixes for Atlas integration in versions 0.1.0 and 0.7.0
[
https://issues.apache.org/jira/browse/AMBARI-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Fernandez updated AMBARI-17616:
-
Status: Open (was: Patch Available)
> Multiple fixes for Atlas integration in versions 0.1.0 and 0.7.0
>
>
> Key: AMBARI-17616
> URL: https://issues.apache.org/jira/browse/AMBARI-17616
> Project: Ambari
> Issue Type: Bug
> Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
>
> This Jira contains several fixes.
> 1. Separate Atlas versions 0.1.0 (HDP 2.3 and 2.4), and 0.7.0 (HDP 2.5) for
> Atlas.
> This way, all of the LDAP/AD changes only affect HDP 2.5.
> This means that HDP 2.5 will have the smart configs theme.
> 2. Allow atlas.authentication.method.ldap.type to contain the value "none"
> If the value is none, then do not require any of the LDAP or AD configs.
> Stack advisor must support this change.
> 3. For the LDAP and AD configs that are required, do not allow an empty
> value. Only these 4 LDAP/AD properties can be optional:
> atlas.authentication.method.ldap.referral
> atlas.authentication.method.ldap.default.role
> atlas.authentication.method.ldap.ad.referral
> atlas.authentication.method.ldap.ad.default.role
> 4. Set all of the configs in atlas-application.properties to have,
> {code}
>
> {code}
> 5. When generating the file atlas-application.properties.xml for Hive,
> Falcon, Storm, and Sqoop, only copy a subset of the configs from Atlas'
> application.properties, these configs are
> {code}
> "atlas.kafka.zookeeper.connect",
> "atlas.kafka.bootstrap.servers",
> "atlas.kafka.zookeeper.session.timeout.ms",
> "atlas.kafka.zookeeper.connection.timeout.ms",
> "atlas.kafka.zookeeper.sync.time.ms",
> "atlas.kafka.hook.group.id",
> "atlas.notification.create.topics",
> "atlas.notification.replicas",
> "atlas.notification.topics",
> "atlas.notification.kafka.service.principal",
> "atlas.notification.kafka.keytab.location",
> "atlas.jaas.KafkaClient.loginModuleName",
> "atlas.jaas.KafkaClient.loginModuleControlFlag",
> "atlas.jaas.KafkaClient.option.useKeyTab",
> "atlas.jaas.KafkaClient.option.storeKey",
> "atlas.jaas.KafkaClient.option.serviceName",
> "atlas.jaas.KafkaClient.option.keyTab",
> "atlas.jaas.KafkaClient.option.principal",
> "atlas.cluster.name"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17616) Multiple fixes for Atlas integration in versions 0.1.0 and 0.7.0
[
https://issues.apache.org/jira/browse/AMBARI-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Fernandez updated AMBARI-17616:
-
Attachment: (was: AMBARI-17616.trunk.patch)
> Multiple fixes for Atlas integration in versions 0.1.0 and 0.7.0
>
>
> Key: AMBARI-17616
> URL: https://issues.apache.org/jira/browse/AMBARI-17616
> Project: Ambari
> Issue Type: Bug
> Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
>
> This Jira contains several fixes.
> 1. Separate Atlas versions 0.1.0 (HDP 2.3 and 2.4), and 0.7.0 (HDP 2.5) for
> Atlas.
> This way, all of the LDAP/AD changes only affect HDP 2.5.
> This means that HDP 2.5 will have the smart configs theme.
> 2. Allow atlas.authentication.method.ldap.type to contain the value "none"
> If the value is none, then do not require any of the LDAP or AD configs.
> Stack advisor must support this change.
> 3. For the LDAP and AD configs that are required, do not allow an empty
> value. Only these 4 LDAP/AD properties can be optional:
> atlas.authentication.method.ldap.referral
> atlas.authentication.method.ldap.default.role
> atlas.authentication.method.ldap.ad.referral
> atlas.authentication.method.ldap.ad.default.role
> 4. Set all of the configs in atlas-application.properties to have,
> {code}
>
> {code}
> 5. When generating the file atlas-application.properties.xml for Hive,
> Falcon, Storm, and Sqoop, only copy a subset of the configs from Atlas'
> application.properties, these configs are
> {code}
> "atlas.kafka.zookeeper.connect",
> "atlas.kafka.bootstrap.servers",
> "atlas.kafka.zookeeper.session.timeout.ms",
> "atlas.kafka.zookeeper.connection.timeout.ms",
> "atlas.kafka.zookeeper.sync.time.ms",
> "atlas.kafka.hook.group.id",
> "atlas.notification.create.topics",
> "atlas.notification.replicas",
> "atlas.notification.topics",
> "atlas.notification.kafka.service.principal",
> "atlas.notification.kafka.keytab.location",
> "atlas.jaas.KafkaClient.loginModuleName",
> "atlas.jaas.KafkaClient.loginModuleControlFlag",
> "atlas.jaas.KafkaClient.option.useKeyTab",
> "atlas.jaas.KafkaClient.option.storeKey",
> "atlas.jaas.KafkaClient.option.serviceName",
> "atlas.jaas.KafkaClient.option.keyTab",
> "atlas.jaas.KafkaClient.option.principal",
> "atlas.cluster.name"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17616) Multiple fixes for Atlas integration in versions 0.1.0 and 0.7.0
[
https://issues.apache.org/jira/browse/AMBARI-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Fernandez updated AMBARI-17616:
-
Attachment: (was: AMBARI-17616.branch-2.4.patch)
> Multiple fixes for Atlas integration in versions 0.1.0 and 0.7.0
>
>
> Key: AMBARI-17616
> URL: https://issues.apache.org/jira/browse/AMBARI-17616
> Project: Ambari
> Issue Type: Bug
> Components: stacks
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
>Priority: Blocker
> Fix For: 2.4.0
>
>
> This Jira contains several fixes.
> 1. Separate Atlas versions 0.1.0 (HDP 2.3 and 2.4), and 0.7.0 (HDP 2.5) for
> Atlas.
> This way, all of the LDAP/AD changes only affect HDP 2.5.
> This means that HDP 2.5 will have the smart configs theme.
> 2. Allow atlas.authentication.method.ldap.type to contain the value "none"
> If the value is none, then do not require any of the LDAP or AD configs.
> Stack advisor must support this change.
> 3. For the LDAP and AD configs that are required, do not allow an empty
> value. Only these 4 LDAP/AD properties can be optional:
> atlas.authentication.method.ldap.referral
> atlas.authentication.method.ldap.default.role
> atlas.authentication.method.ldap.ad.referral
> atlas.authentication.method.ldap.ad.default.role
> 4. Set all of the configs in atlas-application.properties to have,
> {code}
>
> {code}
> 5. When generating the file atlas-application.properties.xml for Hive,
> Falcon, Storm, and Sqoop, only copy a subset of the configs from Atlas'
> application.properties, these configs are
> {code}
> "atlas.kafka.zookeeper.connect",
> "atlas.kafka.bootstrap.servers",
> "atlas.kafka.zookeeper.session.timeout.ms",
> "atlas.kafka.zookeeper.connection.timeout.ms",
> "atlas.kafka.zookeeper.sync.time.ms",
> "atlas.kafka.hook.group.id",
> "atlas.notification.create.topics",
> "atlas.notification.replicas",
> "atlas.notification.topics",
> "atlas.notification.kafka.service.principal",
> "atlas.notification.kafka.keytab.location",
> "atlas.jaas.KafkaClient.loginModuleName",
> "atlas.jaas.KafkaClient.loginModuleControlFlag",
> "atlas.jaas.KafkaClient.option.useKeyTab",
> "atlas.jaas.KafkaClient.option.storeKey",
> "atlas.jaas.KafkaClient.option.serviceName",
> "atlas.jaas.KafkaClient.option.keyTab",
> "atlas.jaas.KafkaClient.option.principal",
> "atlas.cluster.name"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17618) Fix ConcurrentModificationException in Resource.Type
[
https://issues.apache.org/jira/browse/AMBARI-17618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368273#comment-15368273
]
Hadoop QA commented on AMBARI-17618:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12816844/AMBARI-17618.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
ambari-server:
org.apache.ambari.server.state.ServicePropertiesTest
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7745//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7745//console
This message is automatically generated.
> Fix ConcurrentModificationException in Resource.Type
>
>
> Key: AMBARI-17618
> URL: https://issues.apache.org/jira/browse/AMBARI-17618
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17618.patch
>
>
> Resource.Type is not thread-safe, sometimes ConcurrentModificationException
> may occur when for. ex Ambari is extracting a new view and adding a new view
> resource type call Resource.Type.setType()), meanwhile on a separate incoming
> request processing thread iterating through resource types calling
> Resource.type.values().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17629) AUTH_TO_LOCAL rules are not updated when adding services to a Blueprint-installed cluster
[
https://issues.apache.org/jira/browse/AMBARI-17629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-17629:
--
Attachment: AMBARI-17629_trunk_01.patch
AMBARI-17629_branch-2.4_01.patch
> AUTH_TO_LOCAL rules are not updated when adding services to a
> Blueprint-installed cluster
> -
>
> Key: AMBARI-17629
> URL: https://issues.apache.org/jira/browse/AMBARI-17629
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Labels: auth_to_local, kerberos
> Fix For: 2.4.0
>
> Attachments: AMBARI-17629_branch-2.4_01.patch,
> AMBARI-17629_trunk_01.patch
>
>
> When adding new services and components to a cluster that was initially
> created via Blueprints (rather than via the Ambari UI), auth-to-local rules
> that are expected to be created as indicated by the Kerberos descriptor are
> not.
> It occurs because the components being installed are in the {{INIT}} state
> where the logic to determine whether to include the new auth-to-local rules
> or not expects the components to be in either the {{INSTALLED}} or
> {{STARTED}} states. This is due to logic added when resolving AMBARI-14232.
> *Solution*:
> Allow for auth-to-local rules for new services and components to be added
> when the state of the components are {{INIT}} as well as {{INSTALLED}} and
> {{STARTED}}, when the cluster was installed via Blueprints.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17629) AUTH_TO_LOCAL rules are not updated when adding services to a Blueprint-installed cluster
[
https://issues.apache.org/jira/browse/AMBARI-17629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-17629:
--
Status: Patch Available (was: In Progress)
> AUTH_TO_LOCAL rules are not updated when adding services to a
> Blueprint-installed cluster
> -
>
> Key: AMBARI-17629
> URL: https://issues.apache.org/jira/browse/AMBARI-17629
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Labels: auth_to_local, kerberos
> Fix For: 2.4.0
>
> Attachments: AMBARI-17629_branch-2.4_01.patch,
> AMBARI-17629_trunk_01.patch
>
>
> When adding new services and components to a cluster that was initially
> created via Blueprints (rather than via the Ambari UI), auth-to-local rules
> that are expected to be created as indicated by the Kerberos descriptor are
> not.
> It occurs because the components being installed are in the {{INIT}} state
> where the logic to determine whether to include the new auth-to-local rules
> or not expects the components to be in either the {{INSTALLED}} or
> {{STARTED}} states. This is due to logic added when resolving AMBARI-14232.
> *Solution*:
> Allow for auth-to-local rules for new services and components to be added
> when the state of the components are {{INIT}} as well as {{INSTALLED}} and
> {{STARTED}}, when the cluster was installed via Blueprints.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17629) AUTH_TO_LOCAL rules are not updated when adding services to a Blueprint-installed cluster
[
https://issues.apache.org/jira/browse/AMBARI-17629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-17629:
--
Description:
When adding new services and components to a cluster that was initially created
via Blueprints (rather than via the Ambari UI), auth-to-local rules that are
expected to be created as indicated by the Kerberos descriptor are not.
It occurs because the components being installed are in the {{INIT}} state
where the logic to determine whether to include the new auth-to-local rules or
not expects the components to be in either the {{INSTALLED}} or {{STARTED}}
states. This is due to logic added when resolving AMBARI-14232.
*Solution*:
Allow for auth-to-local rules for new services and components to be added when
the state of the components are {{INIT}} as well as {{INSTALLED}} and
{{STARTED}}, when the cluster was installed via Blueprints.
was:
When adding new services and components to a cluster that was initially created
via Blueprints (rather than via the Ambari UI), auth-to-local rules that are
expected to be created as indicated by the Kerberos descriptor are not.
It occurs because the components being installed are in the {{INIT}} state
where the logic to determine whether to include the new auth-to-local rules or
not expects the components to be in either the {{INSTALLED}} or {{STARTED}}
states. This is due to logic added when resolving AMBARI-14232.
#Solution:
Allow for auth-to-local rules for new services and components to be added when
the state of the components are {{INIT}} as well as {{INSTALLED}} and
{{STARTED}}, when the cluster was installed via Blueprints.
> AUTH_TO_LOCAL rules are not updated when adding services to a
> Blueprint-installed cluster
> -
>
> Key: AMBARI-17629
> URL: https://issues.apache.org/jira/browse/AMBARI-17629
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Labels: auth_to_local, kerberos
> Fix For: 2.4.0
>
>
> When adding new services and components to a cluster that was initially
> created via Blueprints (rather than via the Ambari UI), auth-to-local rules
> that are expected to be created as indicated by the Kerberos descriptor are
> not.
> It occurs because the components being installed are in the {{INIT}} state
> where the logic to determine whether to include the new auth-to-local rules
> or not expects the components to be in either the {{INSTALLED}} or
> {{STARTED}} states. This is due to logic added when resolving AMBARI-14232.
> *Solution*:
> Allow for auth-to-local rules for new services and components to be added
> when the state of the components are {{INIT}} as well as {{INSTALLED}} and
> {{STARTED}}, when the cluster was installed via Blueprints.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17628) Enable writing container metrics
[ https://issues.apache.org/jira/browse/AMBARI-17628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddharth Wagle updated AMBARI-17628: - Resolution: Fixed Status: Resolved (was: Patch Available) Pushed to branch 2.4 > Enable writing container metrics > > > Key: AMBARI-17628 > URL: https://issues.apache.org/jira/browse/AMBARI-17628 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Siddharth Wagle >Assignee: Siddharth Wagle > Fix For: 2.4.0 > > Attachments: AMBARI-17628.patch > > > Right now, the container metrics is skipped in hadoop-metrics2.properties. We > should enable these since the patch for writing to separate tables in HBase > has already been committed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-17629) AUTH_TO_LOCAL rules are not updated when adding services to a Blueprint-installed cluster
Robert Levas created AMBARI-17629:
-
Summary: AUTH_TO_LOCAL rules are not updated when adding services
to a Blueprint-installed cluster
Key: AMBARI-17629
URL: https://issues.apache.org/jira/browse/AMBARI-17629
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Robert Levas
Assignee: Robert Levas
Priority: Critical
Fix For: 2.4.0
When adding new services and components to a cluster that was initially created
via Blueprints (rather than via the Ambari UI), auth-to-local rules that are
expected to be created as indicated by the Kerberos descriptor are not.
It occurs because the components being installed are in the {{INIT}} state
where the logic to determine whether to include the new auth-to-local rules or
not expects the components to be in either the {{INSTALLED}} or {{STARTED}}
states. This is due to logic added when resolving AMBARI-14232.
#Solution:
Allow for auth-to-local rules for new services and components to be added when
the state of the components are {{INIT}} as well as {{INSTALLED}} and
{{STARTED}}, when the cluster was installed via Blueprints.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17628) Enable writing container metrics
[ https://issues.apache.org/jira/browse/AMBARI-17628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368172#comment-15368172 ] Aravindan Vijayan commented on AMBARI-17628: LGTM +1 > Enable writing container metrics > > > Key: AMBARI-17628 > URL: https://issues.apache.org/jira/browse/AMBARI-17628 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Siddharth Wagle >Assignee: Siddharth Wagle > Fix For: 2.4.0 > > Attachments: AMBARI-17628.patch > > > Right now, the container metrics is skipped in hadoop-metrics2.properties. We > should enable these since the patch for writing to separate tables in HBase > has already been committed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17628) Enable writing container metrics
[ https://issues.apache.org/jira/browse/AMBARI-17628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddharth Wagle updated AMBARI-17628: - Attachment: AMBARI-17628.patch > Enable writing container metrics > > > Key: AMBARI-17628 > URL: https://issues.apache.org/jira/browse/AMBARI-17628 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Siddharth Wagle >Assignee: Siddharth Wagle > Fix For: 2.4.0 > > Attachments: AMBARI-17628.patch > > > Right now, the container metrics is skipped in hadoop-metrics2.properties. We > should enable these since the patch for writing to separate tables in HBase > has already been committed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17628) Enable writing container metrics
[ https://issues.apache.org/jira/browse/AMBARI-17628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddharth Wagle updated AMBARI-17628: - Status: Patch Available (was: Open) > Enable writing container metrics > > > Key: AMBARI-17628 > URL: https://issues.apache.org/jira/browse/AMBARI-17628 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Siddharth Wagle >Assignee: Siddharth Wagle > Fix For: 2.4.0 > > Attachments: AMBARI-17628.patch > > > Right now, the container metrics is skipped in hadoop-metrics2.properties. We > should enable these since the patch for writing to separate tables in HBase > has already been committed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-17628) Enable writing container metrics
Siddharth Wagle created AMBARI-17628: Summary: Enable writing container metrics Key: AMBARI-17628 URL: https://issues.apache.org/jira/browse/AMBARI-17628 Project: Ambari Issue Type: Task Components: ambari-server Affects Versions: 2.4.0 Reporter: Siddharth Wagle Assignee: Siddharth Wagle Fix For: 2.4.0 Right now, the container metrics is skipped in hadoop-metrics2.properties. We should enable these since the patch for writing to separate tables in HBase has already been committed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-17350) If two users are created differing in case then no users are shown due to error
[
https://issues.apache.org/jira/browse/AMBARI-17350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nahappan Somasundaram resolved AMBARI-17350.
Resolution: Duplicate
> If two users are created differing in case then no users are shown due to
> error
> ---
>
> Key: AMBARI-17350
> URL: https://issues.apache.org/jira/browse/AMBARI-17350
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: Screen Shot 2016-06-11 at 9.17.12 PM.png
>
>
> When usernames that differ only by case are created, no users are show in the
> when clicking the Users link in Ambari Management page due to the following
> error.
> The fix is to block creating usernames that differ only by case.
> {code}
> 12 Jun 2016 03:59:28,569 WARN [ambari-client-thread-559] ServletHandler:628
> - /api/v1/users/
> javax.persistence.NonUniqueResultException: More than one result was returned
> from Query.getSingleResult()
> at
> org.eclipse.persistence.internal.jpa.QueryImpl.throwNonUniqueResultException(QueryImpl.java:980)
> at
> org.eclipse.persistence.internal.jpa.QueryImpl.getSingleResult(QueryImpl.java:529)
> at
> org.eclipse.persistence.internal.jpa.EJBQueryImpl.getSingleResult(EJBQueryImpl.java:400)
> at
> org.apache.ambari.server.orm.dao.UserDAO.findUserByName(UserDAO.java:69)
> at
> org.apache.ambari.server.orm.AmbariLocalSessionInterceptor.invoke(AmbariLocalSessionInterceptor.java:53)
> at
> org.apache.ambari.server.controller.internal.ActiveWidgetLayoutResourceProvider.getResources(ActiveWidgetLayoutResourceProvider.java:161)
> at
> org.apache.ambari.server.controller.internal.ClusterControllerImpl$ExtendedResourceProviderWrapper.queryForResources(ClusterControllerImpl.java:966)
> at
> org.apache.ambari.server.controller.internal.ClusterControllerImpl.getResources(ClusterControllerImpl.java:141)
> at
> org.apache.ambari.server.api.query.QueryImpl.doQuery(QueryImpl.java:512)
> at
> org.apache.ambari.server.api.query.QueryImpl.queryForSubResources(QueryImpl.java:464)
> ...
> {code}
> {code}
> select * from users ;
> ***(press return to proceed or enter x and return to
> cancel)
> user_id | principal_id | ldap_user | user_name | user_type |
> create_time | user_password
> | active | active
> _widget_layouts
> -+--+---+---+---++--++---
>
>1 |1 | 0 | admin | LOCAL | 2016-06-11
> 16:08:51.300678 |
> 538916f8943ec225d97a9a86a2c6ec0818c1cd400e09e03b660fdaaec4af29ddbb6f2b1033b81b00
> | 1 | [{"id"
> :"6"}]
>3 | 14 | 0 | Abcd | LOCAL | 2016-06-12
> 03:58:38.944|
> ee677dc216a63092fd1e4dbb56c3661dcca0053feae5968bdf82e15cb95e9b83747f1b7d25c3badc
> | 1 |
>4 | 15 | 0 | abcd | LOCAL | 2016-06-12
> 03:58:49.32 |
> f941a9570f1b42f2f74b164e9e419fb7d63660681e3ccd9e9313f0369c6d5d03e3249fcfc1fd835e
> | 1 |
> (3 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17613) Alerts ordering works incorrect in some cases on Host Alerts page
[ https://issues.apache.org/jira/browse/AMBARI-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xi Wang updated AMBARI-17613: - Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk and branch-2.4 > Alerts ordering works incorrect in some cases on Host Alerts page > - > > Key: AMBARI-17613 > URL: https://issues.apache.org/jira/browse/AMBARI-17613 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Xi Wang >Assignee: Xi Wang >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17613.patch > > > STR: > # Go to one of hosts > # Navigate to Alerts page (alerts should be sorted by Status) > # Refresh page (sometimes need to refresh page couple times. > Result: alerts does not sorted by Status > Look at the attached video -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Patch Available (was: In Progress)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Attachment: AMBARI-17626.patch
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17613) Alerts ordering works incorrect in some cases on Host Alerts page
[ https://issues.apache.org/jira/browse/AMBARI-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368102#comment-15368102 ] Richard Zang commented on AMBARI-17613: --- +1 for patch. > Alerts ordering works incorrect in some cases on Host Alerts page > - > > Key: AMBARI-17613 > URL: https://issues.apache.org/jira/browse/AMBARI-17613 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Xi Wang >Assignee: Xi Wang >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17613.patch > > > STR: > # Go to one of hosts > # Navigate to Alerts page (alerts should be sorted by Status) > # Refresh page (sometimes need to refresh page couple times. > Result: alerts does not sorted by Status > Look at the attached video -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17619) Apply stack advisor result only applicable for the changes being done
[ https://issues.apache.org/jira/browse/AMBARI-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-17619: - Resolution: Fixed Status: Resolved (was: Patch Available) committed to trunk and branch-2.4 > Apply stack advisor result only applicable for the changes being done > - > > Key: AMBARI-17619 > URL: https://issues.apache.org/jira/browse/AMBARI-17619 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17619.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-17627) Enable Zeppelin authentication via Ambari by default for secure clu
Yesha Vora created AMBARI-17627: --- Summary: Enable Zeppelin authentication via Ambari by default for secure clu Key: AMBARI-17627 URL: https://issues.apache.org/jira/browse/AMBARI-17627 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.4.0 Reporter: Yesha Vora Ambari should setup zeppelin authentication by default for secure clusters. In secure env, * Ambari should setup zeppelin authentication by default. * Zeppelin quick link should automatically login in Zeppelin UI as Ambari user. * If Ambari user do not have view permission for Zeppelin UI, Quick link for Zeppelin UI should be disabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17624) Host service mapping has incorrect default mapping
[
https://issues.apache.org/jira/browse/AMBARI-17624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368052#comment-15368052
]
Hadoop QA commented on AMBARI-17624:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12816845/AMBARI-17624.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The test build failed in ambari-server
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7744//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7744//console
This message is automatically generated.
> Host service mapping has incorrect default mapping
> --
>
> Key: AMBARI-17624
> URL: https://issues.apache.org/jira/browse/AMBARI-17624
> Project: Ambari
> Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-17624.patch
>
>
> Activity Analyzer and Explorer are salves with cardinality
> [0-1].
> However the default selection maps to all hosts. This used to work fine in
> previous builds, but seems to be broken recently
> Ambari version:
>
>
> [root@cn030 ~]# rpm -qa | grep ambari
> ambari-agent-2.4.0.0-764.x86_64
> ambari-server-2.4.0.0-764.x86_64
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17620) Syntax error in 'setup_ranger_xml.py' logging.
[
https://issues.apache.org/jira/browse/AMBARI-17620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368043#comment-15368043
]
Hudson commented on AMBARI-17620:
-
FAILURE: Integrated in Ambari-trunk-Commit #5257 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5257/])
AMBARI-17620. Syntax error in 'setup_ranger_xml.py' logging. (aonishuk)
(aonishuk:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=7df5b8203c8bd598d8aaa751137917a380110d64])
*
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/setup_ranger_xml.py
> Syntax error in 'setup_ranger_xml.py' logging.
> --
>
> Key: AMBARI-17620
> URL: https://issues.apache.org/jira/browse/AMBARI-17620
> Project: Ambari
> Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-17620.patch
>
>
> File "/var/lib/ambari-agent/cache/common-
> services/RANGER/0.4.0/package/scripts/setup_ranger_xml.py", line 291, in
> copy_jdbc_connector
> Please run 'ambari-server setup --jdbc-db=
> {db_name}
> \--jdbc-driver=
> {path_to_jdbc}
> on server host.'".format(params.db_flavor, params.jdk_location)
> KeyError: 'db_name'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17619) Apply stack advisor result only applicable for the changes being done
[
https://issues.apache.org/jira/browse/AMBARI-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368032#comment-15368032
]
Hadoop QA commented on AMBARI-17619:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12816855/AMBARI-17619.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7743//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7743//console
This message is automatically generated.
> Apply stack advisor result only applicable for the changes being done
> -
>
> Key: AMBARI-17619
> URL: https://issues.apache.org/jira/browse/AMBARI-17619
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17619.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17623) nimbus.monitor.freq.secs should be 10 sec
[ https://issues.apache.org/jira/browse/AMBARI-17623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368025#comment-15368025 ] Satish Duggana commented on AMBARI-17623: - Pl give access to edit this bug and add patch with the fix. > nimbus.monitor.freq.secs should be 10 sec > - > > Key: AMBARI-17623 > URL: https://issues.apache.org/jira/browse/AMBARI-17623 > Project: Ambari > Issue Type: Bug >Reporter: Raghav Kumar Gautam > > We want value of nimbus.monitor.freq.secs to be set to 10, but the current > value is 120 > https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/STORM/0.9.1/configuration/storm-site.xml#L210 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17619) Apply stack advisor result only applicable for the changes being done
[
https://issues.apache.org/jira/browse/AMBARI-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368001#comment-15368001
]
Hadoop QA commented on AMBARI-17619:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12816855/AMBARI-17619.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7742//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7742//console
This message is automatically generated.
> Apply stack advisor result only applicable for the changes being done
> -
>
> Key: AMBARI-17619
> URL: https://issues.apache.org/jira/browse/AMBARI-17619
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-17619.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Attachment: cluster_with_defect_installed_from_blueprint.tiff
original_cluster_used_to_create_blueprint.tiff
cluster_with_fix_insatlled_from_blueprint.tiff
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17465) Management packs should be able to install extensions
[
https://issues.apache.org/jira/browse/AMBARI-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Thorpe updated AMBARI-17465:
Fix Version/s: 2.4.0
> Management packs should be able to install extensions
> -
>
> Key: AMBARI-17465
> URL: https://issues.apache.org/jira/browse/AMBARI-17465
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Tim Thorpe
>Assignee: Tim Thorpe
> Fix For: 2.4.0
>
> Attachments: AMBARI-17465.patch
>
>
> Currently management packs (AMBARI-14854) can only add stacks and addon
> services. Now that AMBARI-12885 has been resolved, the management packs
> should be able to add extensions as well. This would allow the following
> mpack.json:
> {
> "type" : "fullrelease",
> "name" : "MyExtension",
> "version": "1.0.0.0",
> "description" : "My Management Pack",
> "prerequisites": {
> "minambariversion" : "2.4"
> },
> "artifacts": [
> {
> "name" : "EXT-extension",
> "type" : "extension-definition",
> "source_dir": "extensions/EXT/1.0",
> "extension_name" : "EXT",
> "extension_version" : "1.0"
> }
> ]
> }
> or alternately with extension-definitions (which will include all extensions
> listed in the extensions directory):
> "artifacts": [
> {
> "name" : "MyExtensions",
> "type" : "extension-definitions",
> "source_dir": "extensions"
> }
> ]
> myext-mpack1.0.0.0
> ├── mpack.json
> └── extensions
> └── EXT
> └── 1.0
> └── metainfo.xml
> └── services
> └── HAWQ
> └── metainfo.xml
> └── PXF
> └── metainfo.xml
> It could then be installed with the following command:
> ambari-server install-mpack --mpack=/tmp/myext-mpack1.0.0.0.tar.gz -v
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Description:
Blueprints make use of a population strategy in the registration step to create
JSON objects for properties and property-attributes. These properties and
property-attributes get stored in the database (DB) in the "clusterconfig"
table under "config_data" and "config_attributes" respectively. Format of these
JSON objects is critical as the UI parses these objects assuming them to be in
a certain format.
At present property-attributes like "final" get stored in "clusterconfig" table
in the format shown in attachment
"original_cluster_used_to_create_blueprint.tiff".
i.e. "final": {"attr1":"val1", "attr2":"val2"}
When a new cluster is to be installed using a blueprint, after the blueprint is
registered and the new cluster is installed using the registered blueprint, the
format of "property-attributes" is as shown in attachment
"cluster_with_defect_installed_from_blueprint.tiff".
i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
"final":{"attr1":"val1", "attr2":"val2"}
The population strategy is responsible for the "attr1":{"final":"val1"} and
"attr2":{"final":"val2"}.
The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
with the Parent Configuration during blueprint registration. This Parent
Configuration comes from Stack using the XML files of the service properties.
Because of this "final" attribute, the UI still shows the properties correctly
and hence it went undetected.
Proposed fix involves correcting the population strategy so that the attributes
are placed in the correct format. After the fix, the new cluster installed via
blueprint shows "property-attributes" as shown in attachment
"cluster_with_fix_insatlled_from_blueprint.tiff"
i.e. "final":{"attr1":"val1", "attr2":"val2"}
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17619) Apply stack advisor result only applicable for the changes being done
[ https://issues.apache.org/jira/browse/AMBARI-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15367973#comment-15367973 ] Aleksandr Kovalenko commented on AMBARI-17619: -- +1 for the patch > Apply stack advisor result only applicable for the changes being done > - > > Key: AMBARI-17619 > URL: https://issues.apache.org/jira/browse/AMBARI-17619 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17619.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17465) Management packs should be able to install extensions
[
https://issues.apache.org/jira/browse/AMBARI-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-17465:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Management packs should be able to install extensions
> -
>
> Key: AMBARI-17465
> URL: https://issues.apache.org/jira/browse/AMBARI-17465
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Tim Thorpe
>Assignee: Tim Thorpe
> Attachments: AMBARI-17465.patch
>
>
> Currently management packs (AMBARI-14854) can only add stacks and addon
> services. Now that AMBARI-12885 has been resolved, the management packs
> should be able to add extensions as well. This would allow the following
> mpack.json:
> {
> "type" : "fullrelease",
> "name" : "MyExtension",
> "version": "1.0.0.0",
> "description" : "My Management Pack",
> "prerequisites": {
> "minambariversion" : "2.4"
> },
> "artifacts": [
> {
> "name" : "EXT-extension",
> "type" : "extension-definition",
> "source_dir": "extensions/EXT/1.0",
> "extension_name" : "EXT",
> "extension_version" : "1.0"
> }
> ]
> }
> or alternately with extension-definitions (which will include all extensions
> listed in the extensions directory):
> "artifacts": [
> {
> "name" : "MyExtensions",
> "type" : "extension-definitions",
> "source_dir": "extensions"
> }
> ]
> myext-mpack1.0.0.0
> ├── mpack.json
> └── extensions
> └── EXT
> └── 1.0
> └── metainfo.xml
> └── services
> └── HAWQ
> └── metainfo.xml
> └── PXF
> └── metainfo.xml
> It could then be installed with the following command:
> ambari-server install-mpack --mpack=/tmp/myext-mpack1.0.0.0.tar.gz -v
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17619) Apply stack advisor result only applicable for the changes being done
[ https://issues.apache.org/jira/browse/AMBARI-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-17619: - Status: Patch Available (was: Open) > Apply stack advisor result only applicable for the changes being done > - > > Key: AMBARI-17619 > URL: https://issues.apache.org/jira/browse/AMBARI-17619 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17619.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17465) Management packs should be able to install extensions
[
https://issues.apache.org/jira/browse/AMBARI-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15367971#comment-15367971
]
Jayush Luniya commented on AMBARI-17465:
Branch-2.4
commit c990c41804204ee883225f6fe88eb289d4f4a38e
Author: Jayush Luniya
Date: Fri Jul 8 09:52:54 2016 -0700
AMBARI-17465: Management packs should be able to install extensions (Tim
Thorpe via jluniya)
> Management packs should be able to install extensions
> -
>
> Key: AMBARI-17465
> URL: https://issues.apache.org/jira/browse/AMBARI-17465
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Tim Thorpe
>Assignee: Tim Thorpe
> Attachments: AMBARI-17465.patch
>
>
> Currently management packs (AMBARI-14854) can only add stacks and addon
> services. Now that AMBARI-12885 has been resolved, the management packs
> should be able to add extensions as well. This would allow the following
> mpack.json:
> {
> "type" : "fullrelease",
> "name" : "MyExtension",
> "version": "1.0.0.0",
> "description" : "My Management Pack",
> "prerequisites": {
> "minambariversion" : "2.4"
> },
> "artifacts": [
> {
> "name" : "EXT-extension",
> "type" : "extension-definition",
> "source_dir": "extensions/EXT/1.0",
> "extension_name" : "EXT",
> "extension_version" : "1.0"
> }
> ]
> }
> or alternately with extension-definitions (which will include all extensions
> listed in the extensions directory):
> "artifacts": [
> {
> "name" : "MyExtensions",
> "type" : "extension-definitions",
> "source_dir": "extensions"
> }
> ]
> myext-mpack1.0.0.0
> ├── mpack.json
> └── extensions
> └── EXT
> └── 1.0
> └── metainfo.xml
> └── services
> └── HAWQ
> └── metainfo.xml
> └── PXF
> └── metainfo.xml
> It could then be installed with the following command:
> ambari-server install-mpack --mpack=/tmp/myext-mpack1.0.0.0.tar.gz -v
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17619) Apply stack advisor result only applicable for the changes being done
[ https://issues.apache.org/jira/browse/AMBARI-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-17619: - Attachment: AMBARI-17619.patch > Apply stack advisor result only applicable for the changes being done > - > > Key: AMBARI-17619 > URL: https://issues.apache.org/jira/browse/AMBARI-17619 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17619.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17465) Management packs should be able to install extensions
[
https://issues.apache.org/jira/browse/AMBARI-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15367965#comment-15367965
]
Jayush Luniya commented on AMBARI-17465:
Trunk
commit 587050eacfca697eeecb55be238823f7843eb003
Author: Jayush Luniya
Date: Fri Jul 8 09:52:54 2016 -0700
AMBARI-17465: Management packs should be able to install extensions (Tim
Thorpe via jluniya)
> Management packs should be able to install extensions
> -
>
> Key: AMBARI-17465
> URL: https://issues.apache.org/jira/browse/AMBARI-17465
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Tim Thorpe
>Assignee: Tim Thorpe
> Attachments: AMBARI-17465.patch
>
>
> Currently management packs (AMBARI-14854) can only add stacks and addon
> services. Now that AMBARI-12885 has been resolved, the management packs
> should be able to add extensions as well. This would allow the following
> mpack.json:
> {
> "type" : "fullrelease",
> "name" : "MyExtension",
> "version": "1.0.0.0",
> "description" : "My Management Pack",
> "prerequisites": {
> "minambariversion" : "2.4"
> },
> "artifacts": [
> {
> "name" : "EXT-extension",
> "type" : "extension-definition",
> "source_dir": "extensions/EXT/1.0",
> "extension_name" : "EXT",
> "extension_version" : "1.0"
> }
> ]
> }
> or alternately with extension-definitions (which will include all extensions
> listed in the extensions directory):
> "artifacts": [
> {
> "name" : "MyExtensions",
> "type" : "extension-definitions",
> "source_dir": "extensions"
> }
> ]
> myext-mpack1.0.0.0
> ├── mpack.json
> └── extensions
> └── EXT
> └── 1.0
> └── metainfo.xml
> └── services
> └── HAWQ
> └── metainfo.xml
> └── PXF
> └── metainfo.xml
> It could then be installed with the following command:
> ambari-server install-mpack --mpack=/tmp/myext-mpack1.0.0.0.tar.gz -v
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17465) Management packs should be able to install extensions
[
https://issues.apache.org/jira/browse/AMBARI-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15367963#comment-15367963
]
Jayush Luniya commented on AMBARI-17465:
Following unit test failure is not related to this change. TestMpacks unit
tests are passing. Committing this change and following up on the below unit
test failure separately.
--
Failed tests:
ERROR: test_validateStormRangerPluginConfigurations
(test_stack_advisor.TestHDP22StackAdvisor)
--
Traceback (most recent call last):
File
"/Users/jluniya/release/trunk2/ambari/ambari-server/src/test/python/stacks/2.2/common/test_stack_advisor.py",
line 3947, in test_validateStormRangerPluginConfigurations
res = self.stackAdvisor.validateStormRangerPluginConfigurations(properties,
recommendedDefaults, configurations, services, {})
File
"/Users/jluniya/release/trunk2/ambari/ambari-server/src/test/python/stacks/2.2/common/../../../../../main/resources/stacks/HDP/2.2/services/stack_advisor.py",
line 1508, in validateStormRangerPluginConfigurations
servicesList = [service["StackServices"]["service_name"] for service in
services["services"]]
KeyError: 'services'
--
Total run:1017
Total errors:1
Total failures:0
ERROR
INFO: AMBARI_SERVER_LIB is not set, using default /usr/lib/ambari-server
INFO: Return code from stack upgrade command, retcode = 0
StackAdvisor implementation for stack HDP1, version 2.0.6 was not found
Returning DefaultStackAdvisor implementation
StackAdvisor implementation for stack XYZ, version 1.0.0 was loaded
StackAdvisor implementation for stack XYZ, version 1.0.1 was loaded
Returning XYZ101StackAdvisor implementation
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1:09.528s
[INFO] Finished at: Fri Jul 08 09:43:19 PDT 2016
[INFO] Final Memory: 58M/1027M
[INFO]
> Management packs should be able to install extensions
> -
>
> Key: AMBARI-17465
> URL: https://issues.apache.org/jira/browse/AMBARI-17465
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Tim Thorpe
>Assignee: Tim Thorpe
> Attachments: AMBARI-17465.patch
>
>
> Currently management packs (AMBARI-14854) can only add stacks and addon
> services. Now that AMBARI-12885 has been resolved, the management packs
> should be able to add extensions as well. This would allow the following
> mpack.json:
> {
> "type" : "fullrelease",
> "name" : "MyExtension",
> "version": "1.0.0.0",
> "description" : "My Management Pack",
> "prerequisites": {
> "minambariversion" : "2.4"
> },
> "artifacts": [
> {
> "name" : "EXT-extension",
> "type" : "extension-definition",
> "source_dir": "extensions/EXT/1.0",
> "extension_name" : "EXT",
> "extension_version" : "1.0"
> }
> ]
> }
> or alternately with extension-definitions (which will include all extensions
> listed in the extensions directory):
> "artifacts": [
> {
> "name" : "MyExtensions",
> "type" : "extension-definitions",
> "source_dir": "extensions"
> }
> ]
> myext-mpack1.0.0.0
> ├── mpack.json
> └── extensions
> └── EXT
> └── 1.0
> └── metainfo.xml
> └── services
> └── HAWQ
> └── metainfo.xml
> └── PXF
> └── metainfo.xml
> It could then be installed with the following command:
> ambari-server install-mpack --mpack=/tmp/myext-mpack1.0.0.0.tar.gz -v
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
Keta Patel created AMBARI-17626: --- Summary: Blueprint registration step uses wrong format for property-attributes in Configuration Key: AMBARI-17626 URL: https://issues.apache.org/jira/browse/AMBARI-17626 Project: Ambari Issue Type: Bug Components: blueprints Affects Versions: trunk Reporter: Keta Patel Assignee: Keta Patel -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17624) Host service mapping has incorrect default mapping
[
https://issues.apache.org/jira/browse/AMBARI-17624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15367955#comment-15367955
]
Hadoop QA commented on AMBARI-17624:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12816845/AMBARI-17624.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The test build failed in ambari-server
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7741//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7741//console
This message is automatically generated.
> Host service mapping has incorrect default mapping
> --
>
> Key: AMBARI-17624
> URL: https://issues.apache.org/jira/browse/AMBARI-17624
> Project: Ambari
> Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-17624.patch
>
>
> Activity Analyzer and Explorer are salves with cardinality
> [0-1].
> However the default selection maps to all hosts. This used to work fine in
> previous builds, but seems to be broken recently
> Ambari version:
>
>
> [root@cn030 ~]# rpm -qa | grep ambari
> ambari-agent-2.4.0.0-764.x86_64
> ambari-server-2.4.0.0-764.x86_64
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17622) Ambari server schema upgrade failed from 2.1.1 with ORA-12516 error
[
https://issues.apache.org/jira/browse/AMBARI-17622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15367926#comment-15367926
]
Hadoop QA commented on AMBARI-17622:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12816814/AMBARI-17622_2.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
ambari-server:
org.apache.ambari.server.state.ServicePropertiesTest
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/7740//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/7740//console
This message is automatically generated.
> Ambari server schema upgrade failed from 2.1.1 with ORA-12516 error
> ---
>
> Key: AMBARI-17622
> URL: https://issues.apache.org/jira/browse/AMBARI-17622
> Project: Ambari
> Issue Type: Bug
> Components: ambari-upgrade
>Affects Versions: 2.4.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17622_2.patch
>
>
> Steps
> Deploy HDP-2.3.0.0 cluster with Ambari 2.1.1 (Oracle DB, unsecure, HA
> cluster). Note - the DB instance is dedicated for this cluster and Ambari
> server and not shared
> Upgrade Ambari to 2.4.0.0-726.x86_64
> Result
> Error during Ambari DB schema upgrade. Logs show the below
> {code}
> 01 Jul 2016 11:47:17,686 ERROR [main] DBAccessorImpl:107 - Error while
> creating database accessor
> java.sql.SQLException: Listener refused the connection with the following
> error:
> ORA-12516, TNS:listener could not find available handler with matching
> protocol stack
>
> at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:419)
> at
> oracle.jdbc.driver.PhysicalConnection.(PhysicalConnection.java:536)
> at oracle.jdbc.driver.T4CConnection.(T4CConnection.java:228)
> at
> oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32)
> at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:521)
> at java.sql.DriverManager.getConnection(DriverManager.java:571)
> at java.sql.DriverManager.getConnection(DriverManager.java:215)
> at
> org.apache.ambari.server.orm.DBAccessorImpl.(DBAccessorImpl.java:87)
> 01 Jul 2016 11:47:17,697 ERROR [main] DBAccessorImpl:107 - Error while
> creating database accessor
> java.sql.SQLException: Listener refused the connection with the following
> error:
> ORA-12516, TNS:listener could not find available handler with matching
> protocol stack
>
> at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:419)
> at
> oracle.jdbc.driver.PhysicalConnection.(PhysicalConnection.java:536)
> 01 Jul 2016 11:47:17,699 ERROR [main] SchemaUpgradeHelper:369 - Unexpected
> error, upgrade failed
> com.google.inject.ProvisionException: Guice provision errors:
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
