[jira] [Updated] (AMBARI-16085) Modify Ambari stacks for Ranger (for enabling plugins) to use service keytab for creating repositories and policies
[ https://issues.apache.org/jira/browse/AMBARI-16085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gautam Borad updated AMBARI-16085: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Modify Ambari stacks for Ranger (for enabling plugins) to use service keytab > for creating repositories and policies > --- > > Key: AMBARI-16085 > URL: https://issues.apache.org/jira/browse/AMBARI-16085 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Gautam Borad >Assignee: Gautam Borad > Fix For: 2.4.0 > > Attachments: AMBARI-16085.2.patch, AMBARI-16085.patch > > > In order to allow Ranger plugins to support Kerberos Authentication. Make > changes in Ranger plugin stacks to create ranger services and policies using > component principal / keytab. Also take care of config changes to support > plugin communication in Kerberos enabled env. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16085) Modify Ambari stacks for Ranger (for enabling plugins) to use service keytab for creating repositories and policies
[ https://issues.apache.org/jira/browse/AMBARI-16085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261543#comment-15261543 ] Gautam Borad commented on AMBARI-16085: --- Committed to trunk : https://github.com/apache/ambari/commit/e74bfa4a4ba7689f7f7d3a363fc817871b32c798 > Modify Ambari stacks for Ranger (for enabling plugins) to use service keytab > for creating repositories and policies > --- > > Key: AMBARI-16085 > URL: https://issues.apache.org/jira/browse/AMBARI-16085 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Gautam Borad >Assignee: Gautam Borad > Fix For: 2.4.0 > > Attachments: AMBARI-16085.2.patch, AMBARI-16085.patch > > > In order to allow Ranger plugins to support Kerberos Authentication. Make > changes in Ranger plugin stacks to create ranger services and policies using > component principal / keytab. Also take care of config changes to support > plugin communication in Kerberos enabled env. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16145) Add dryrun API for host delete
[
https://issues.apache.org/jira/browse/AMBARI-16145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261394#comment-15261394
]
Hudson commented on AMBARI-16145:
-
FAILURE: Integrated in Ambari-trunk-Commit #4752 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/4752/])
AMBARI-16145. Add dryrun API for host delete (ajit) (ajit:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=237a5d6926ddf841859695b4fcc469ab1cc04fcf])
*
ambari-server/src/main/java/org/apache/ambari/server/api/resources/HostResourceDefinition.java
*
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/HostResourceProvider.java
*
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/HostResourceProviderTest.java
> Add dryrun API for host delete
> ---
>
> Key: AMBARI-16145
> URL: https://issues.apache.org/jira/browse/AMBARI-16145
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Ajit Kumar
>Assignee: Ajit Kumar
> Fix For: 2.4.0
>
>
> Add dryrun API for host delete
> API should be take dry_run directive and check if requested host can be
> deleted w/o deleting the host and should return error if any, like host is
> not in delete friendly state.
> {code}
> curl -i -X DELETE -u admin:admin -H 'X-Requested-By:ambari'
> 'http://localhost:8080/api/v1/clusters/c1/hosts?dry_run=true/host_name=c6401.ambari.apache.org'
> {code}
> It should also support bulk delete format
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16142) Add getDeleteDirectives to org.apache.ambari.server.api.resources.ResourceDefinition and use when handling DELETE requests
[ https://issues.apache.org/jira/browse/AMBARI-16142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261395#comment-15261395 ] Hudson commented on AMBARI-16142: - FAILURE: Integrated in Ambari-trunk-Commit #4752 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4752/]) AMBARI-16142. Add getDeleteDirectives to ResourceDefinition (ajit) (ajit: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=80f1beaac13812a5c0f743242247f6b8e6b0aea2]) * ambari-server/src/main/java/org/apache/ambari/server/api/services/RequestFactory.java * ambari-server/src/test/java/org/apache/ambari/server/audit/request/creator/AuditEventCreatorTestHelper.java * ambari-server/src/test/java/org/apache/ambari/server/api/services/RequestFactoryTest.java * ambari-server/src/main/java/org/apache/ambari/server/api/services/BaseRequest.java * ambari-server/src/test/java/org/apache/ambari/server/api/services/BaseRequestTest.java * ambari-server/src/main/java/org/apache/ambari/server/api/resources/BaseResourceDefinition.java * ambari-server/src/main/java/org/apache/ambari/server/api/resources/ResourceDefinition.java > Add getDeleteDirectives to > org.apache.ambari.server.api.resources.ResourceDefinition and use when > handling DELETE requests > -- > > Key: AMBARI-16142 > URL: https://issues.apache.org/jira/browse/AMBARI-16142 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Ajit Kumar >Assignee: Ajit Kumar > Fix For: 2.4.0 > > Attachments: rb46748.patch > > > Add delete directive to RequestDefinition and handle it in Delete requests. > It will be useful for usecases like dry run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16149) Support for LLAP alert in Ambari
Swapan Shridhar created AMBARI-16149: Summary: Support for LLAP alert in Ambari Key: AMBARI-16149 URL: https://issues.apache.org/jira/browse/AMBARI-16149 Project: Ambari Issue Type: Task Components: ambari-server Affects Versions: 2.4.0 Reporter: Swapan Shridhar Assignee: Swapan Shridhar Fix For: 2.4.0 - Checks LLAP app status by running Hive Server2 " --service llapstatus --name " command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16147) Ambari Web Service installation does not comply with Final Attribute. (isFinal is skipped)
[
https://issues.apache.org/jira/browse/AMBARI-16147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261340#comment-15261340
]
Hadoop QA commented on AMBARI-16147:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12801144/AMBARI-16147-trunk.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6696//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6696//console
This message is automatically generated.
> Ambari Web Service installation does not comply with Final Attribute.
> (isFinal is skipped)
> ---
>
> Key: AMBARI-16147
> URL: https://issues.apache.org/jira/browse/AMBARI-16147
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Goutam Tadi
>Assignee: Goutam Tadi
>Priority: Minor
> Fix For: 2.4.0
>
> Attachments: AMBARI-16147-trunk.patch
>
>
> When installing HDFS/HIVE/any service the properties that are marked final
> before installation are marked as de-finalized post installation. This occurs
> at the last step of installation i.e deploy stage.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16144) Stack advisor scripts should handle calls where dependent services do not exist
[ https://issues.apache.org/jira/browse/AMBARI-16144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261280#comment-15261280 ] Hudson commented on AMBARI-16144: - FAILURE: Integrated in Ambari-branch-2.2 #677 (See [https://builds.apache.org/job/Ambari-branch-2.2/677/]) AMBARI-16144. Stack advisor scripts should handle calls where dependent (smohanty: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=735d6ffb7b2a56cdb67549a0574bf2d5826c0dc2]) * ambari-server/src/main/resources/stacks/HDP/2.0.6/services/stack_advisor.py * ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py > Stack advisor scripts should handle calls where dependent services do not > exist > --- > > Key: AMBARI-16144 > URL: https://issues.apache.org/jira/browse/AMBARI-16144 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.2.0 >Reporter: Sumit Mohanty >Assignee: Sumit Mohanty >Priority: Critical > Fix For: 2.2-next > > Attachments: AMBARI-16144.patch > > > Several stack components such as AMS and HAWQ assume that HDFS to be > installed. However, it is possible to deploy cluster that does not have HDFS > deployed. The logic should be robust enough to handle absence of components > such as DATANODE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16144) Stack advisor scripts should handle calls where dependent services do not exist
[ https://issues.apache.org/jira/browse/AMBARI-16144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261258#comment-15261258 ] Hudson commented on AMBARI-16144: - SUCCESS: Integrated in Ambari-trunk-Commit #4751 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4751/]) AMBARI-16144. Stack advisor scripts should handle calls where dependent (smohanty: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=116d9853461c6fc81e32a28c11b73ffb65849d44]) * ambari-server/src/main/resources/stacks/HDP/2.0.6/services/stack_advisor.py * ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py > Stack advisor scripts should handle calls where dependent services do not > exist > --- > > Key: AMBARI-16144 > URL: https://issues.apache.org/jira/browse/AMBARI-16144 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.2.0 >Reporter: Sumit Mohanty >Assignee: Sumit Mohanty >Priority: Critical > Fix For: 2.2-next > > Attachments: AMBARI-16144.patch > > > Several stack components such as AMS and HAWQ assume that HDFS to be > installed. However, it is possible to deploy cluster that does not have HDFS > deployed. The logic should be robust enough to handle absence of components > such as DATANODE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16143) Ambari metrics API call should allow for early failure
[
https://issues.apache.org/jira/browse/AMBARI-16143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261209#comment-15261209
]
Hadoop QA commented on AMBARI-16143:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12801123/AMBARI-16143.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6694//console
This message is automatically generated.
> Ambari metrics API call should allow for early failure
> --
>
> Key: AMBARI-16143
> URL: https://issues.apache.org/jira/browse/AMBARI-16143
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16143.patch
>
>
> In case of a SocketTimeoutException skip populating the resource with metrics
> until the next retry.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMBARI-16145) Add dryrun API for host delete
[
https://issues.apache.org/jira/browse/AMBARI-16145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ajit Kumar resolved AMBARI-16145.
-
Resolution: Fixed
> Add dryrun API for host delete
> ---
>
> Key: AMBARI-16145
> URL: https://issues.apache.org/jira/browse/AMBARI-16145
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Ajit Kumar
>Assignee: Ajit Kumar
> Fix For: 2.4.0
>
>
> Add dryrun API for host delete
> API should be take dry_run directive and check if requested host can be
> deleted w/o deleting the host and should return error if any, like host is
> not in delete friendly state.
> {code}
> curl -i -X DELETE -u admin:admin -H 'X-Requested-By:ambari'
> 'http://localhost:8080/api/v1/clusters/c1/hosts?dry_run=true/host_name=c6401.ambari.apache.org'
> {code}
> It should also support bulk delete format
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16147) Ambari Web Service installation does not comply with Final Attribute. (isFinal is skipped)
[ https://issues.apache.org/jira/browse/AMBARI-16147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goutam Tadi updated AMBARI-16147: - Status: Patch Available (was: In Progress) > Ambari Web Service installation does not comply with Final Attribute. > (isFinal is skipped) > --- > > Key: AMBARI-16147 > URL: https://issues.apache.org/jira/browse/AMBARI-16147 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Goutam Tadi >Assignee: Goutam Tadi >Priority: Minor > Fix For: 2.4.0 > > Attachments: AMBARI-16147-trunk.patch > > > When installing HDFS/HIVE/any service the properties that are marked final > before installation are marked as de-finalized post installation. This occurs > at the last step of installation i.e deploy stage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16147) Ambari Web Service installation does not comply with Final Attribute. (isFinal is skipped)
[ https://issues.apache.org/jira/browse/AMBARI-16147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goutam Tadi updated AMBARI-16147: - Attachment: AMBARI-16147-trunk.patch > Ambari Web Service installation does not comply with Final Attribute. > (isFinal is skipped) > --- > > Key: AMBARI-16147 > URL: https://issues.apache.org/jira/browse/AMBARI-16147 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Goutam Tadi >Assignee: Goutam Tadi >Priority: Minor > Fix For: 2.4.0 > > Attachments: AMBARI-16147-trunk.patch > > > When installing HDFS/HIVE/any service the properties that are marked final > before installation are marked as de-finalized post installation. This occurs > at the last step of installation i.e deploy stage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16147) Ambari Web Service installation does not comply with Final Attribute. (isFinal is skipped)
[ https://issues.apache.org/jira/browse/AMBARI-16147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goutam Tadi updated AMBARI-16147: - Status: In Progress (was: Patch Available) > Ambari Web Service installation does not comply with Final Attribute. > (isFinal is skipped) > --- > > Key: AMBARI-16147 > URL: https://issues.apache.org/jira/browse/AMBARI-16147 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Goutam Tadi >Assignee: Goutam Tadi >Priority: Minor > Fix For: 2.4.0 > > Attachments: AMBARI-16147-trunk.patch > > > When installing HDFS/HIVE/any service the properties that are marked final > before installation are marked as de-finalized post installation. This occurs > at the last step of installation i.e deploy stage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16147) Ambari Web Service installation does not comply with Final Attribute. (isFinal is skipped)
[ https://issues.apache.org/jira/browse/AMBARI-16147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goutam Tadi updated AMBARI-16147: - Attachment: (was: AMBARI-16147-trunk.patch) > Ambari Web Service installation does not comply with Final Attribute. > (isFinal is skipped) > --- > > Key: AMBARI-16147 > URL: https://issues.apache.org/jira/browse/AMBARI-16147 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Goutam Tadi >Assignee: Goutam Tadi >Priority: Minor > Fix For: 2.4.0 > > Attachments: AMBARI-16147-trunk.patch > > > When installing HDFS/HIVE/any service the properties that are marked final > before installation are marked as de-finalized post installation. This occurs > at the last step of installation i.e deploy stage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16142) Add getDeleteDirectives to org.apache.ambari.server.api.resources.ResourceDefinition and use when handling DELETE requests
[ https://issues.apache.org/jira/browse/AMBARI-16142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ajit Kumar updated AMBARI-16142: Resolution: Fixed Status: Resolved (was: Patch Available) > Add getDeleteDirectives to > org.apache.ambari.server.api.resources.ResourceDefinition and use when > handling DELETE requests > -- > > Key: AMBARI-16142 > URL: https://issues.apache.org/jira/browse/AMBARI-16142 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Ajit Kumar >Assignee: Ajit Kumar > Fix For: 2.4.0 > > Attachments: rb46748.patch > > > Add delete directive to RequestDefinition and handle it in Delete requests. > It will be useful for usecases like dry run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16147) Ambari Web Service installation does not comply with Final Attribute. (isFinal is skipped)
[
https://issues.apache.org/jira/browse/AMBARI-16147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261167#comment-15261167
]
Hadoop QA commented on AMBARI-16147:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12801127/AMBARI-16147-trunk.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6693//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6693//console
This message is automatically generated.
> Ambari Web Service installation does not comply with Final Attribute.
> (isFinal is skipped)
> ---
>
> Key: AMBARI-16147
> URL: https://issues.apache.org/jira/browse/AMBARI-16147
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Goutam Tadi
>Assignee: Goutam Tadi
>Priority: Minor
> Fix For: 2.4.0
>
> Attachments: AMBARI-16147-trunk.patch
>
>
> When installing HDFS/HIVE/any service the properties that are marked final
> before installation are marked as de-finalized post installation. This occurs
> at the last step of installation i.e deploy stage.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMBARI-16148) Change storm-kafka KafkaTestBroker to newer api
[ https://issues.apache.org/jira/browse/AMBARI-16148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sriharsha Chintalapani resolved AMBARI-16148. - Resolution: Invalid > Change storm-kafka KafkaTestBroker to newer api > --- > > Key: AMBARI-16148 > URL: https://issues.apache.org/jira/browse/AMBARI-16148 > Project: Ambari > Issue Type: Bug >Reporter: Sriharsha Chintalapani > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16148) Change storm-kafka KafkaTestBroker to newer api
Sriharsha Chintalapani created AMBARI-16148: --- Summary: Change storm-kafka KafkaTestBroker to newer api Key: AMBARI-16148 URL: https://issues.apache.org/jira/browse/AMBARI-16148 Project: Ambari Issue Type: Bug Reporter: Sriharsha Chintalapani -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16139) Duplicate Dashboard metrics API calls should not be made in parallel
[ https://issues.apache.org/jira/browse/AMBARI-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261016#comment-15261016 ] Hudson commented on AMBARI-16139: - SUCCESS: Integrated in Ambari-trunk-Commit #4750 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4750/]) AMBARI-16139. Duplicate Dashboard metrics API calls should not be made (jaimin: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=1c29f1df06db04e744b6a3342f341977442472ae]) * ambari-web/test/views/common/chart/linear_time_test.js * ambari-web/app/views/common/chart/linear_time.js * ambari-web/app/controllers/global/update_controller.js > Duplicate Dashboard metrics API calls should not be made in parallel > > > Key: AMBARI-16139 > URL: https://issues.apache.org/jira/browse/AMBARI-16139 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.1.2 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.4.0, 2.2-next > > Attachments: AMBARI-16139.patch, Screen Shot 2016-04-26 at 1.37.01 > PM.png > > > Graphs on Cluster dashboard page keeps making API calls irrespective of the > previous APIs call have completed or not. Thus on a cluster where AMS is > misbehaving there are multiple same API calls in pending state and results > into ambari-server unresponsive. > For Graph widgets, ajax calls should be made from the complete callback > function of the same ajax call. so until an ajax call is not finished, the > same ajax is not triggered again > we do this in correct way for enhanced service dashboard on service summary > page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16131) Prevent Views From Causing a Loss of Service For Ambari
[
https://issues.apache.org/jira/browse/AMBARI-16131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261014#comment-15261014
]
Hudson commented on AMBARI-16131:
-
SUCCESS: Integrated in Ambari-trunk-Commit #4750 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/4750/])
AMBARI-16131 - Prevent Views From Causing a Loss of Service For Ambari
(jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=85ac3c22ea6aedd4a75e79ee25798677e07a7bdd])
*
ambari-server/src/main/java/org/apache/ambari/server/view/ViewThrottleFilter.java
*
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java
*
ambari-server/src/test/java/org/apache/ambari/server/view/ViewThrottleFilterTest.java
* ambari-server/src/main/java/org/apache/ambari/server/view/ViewRegistry.java
* ambari-server/src/main/java/org/apache/ambari/server/utils/VersionUtils.java
*
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
> Prevent Views From Causing a Loss of Service For Ambari
> ---
>
> Key: AMBARI-16131
> URL: https://issues.apache.org/jira/browse/AMBARI-16131
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.0.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.4.0, 2.2-next
>
> Attachments: AMBARI-16131.patch
>
>
> The underlying problem is that views are accessed off of the REST endpoint
> ({{/api/v1/views}}). This means that the Ambari REST API connector is going
> to handle the request from its own threadpool. There is no way to configure
> Jetty to use a different threadpool for the same connector. As a result, if a
> request to load a view holds the Jetty thread hostage, eventually we will see
> thread starvation and loss of service.
> An example of this situation is a view which makes an innocent request to a
> remote resource. If the view's request has a timeout of 60 seconds, then the
> Jetty thread is going to be held for that amount of time. With concurrent
> users and multiple instances of that view deployed, the Jetty threadpool can
> becomes exhausted quickly.
> Although there are more graceful ways of handling this situation, they mostly
> involve substantial re-architecture and design:
> - The use of a new connector and threadpool would require binding to another
> port for view requests. This will cause problems with "local" views and their
> assumption that if they run on the Ambari server they can share the same
> session.
> - The use of a
> [Continuation|https://wiki.eclipse.org/Jetty/Feature/Continuations] in Jetty
> which can suspend the incoming request. We would need the ability for views
> to signal that they have completed their work in order to proceed with the
> suspended request.
> A quicker and far less invasive fix would be to create a filter which
> intercepts requests for views. It will determine how many executing view
> requests exist and decide if it will allow the new request through. For
> example, if configured to allow a maximum of 10 concurrent view requests,
> then the 11th request would be denied with an {{HTTP 503 - Service
> Unavailable}}. Although the thread is temporarily used while the filter is
> processing, it's quickly returned to the Jetty pool when it's determined
> there are too many other running view requests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16103) Tez View : Equip the tez view shim to work with both version 1 & 2 of Tez UI
[ https://issues.apache.org/jira/browse/AMBARI-16103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261017#comment-15261017 ] Hudson commented on AMBARI-16103: - SUCCESS: Integrated in Ambari-trunk-Commit #4750 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4750/]) AMBARI-16103. Tez View : Equip the tez view shim to work with both (hitesh: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=6a906e6309d634461d683f38badc0b5440cff5e0]) * contrib/views/tez/src/main/resources/ui/scripts/init-ambari-view.js * contrib/views/tez/pom.xml * contrib/views/tez/src/main/resources/ui/ambari-scripts/init-view.js * contrib/views/tez/src/main/resources/ui/index.html > Tez View : Equip the tez view shim to work with both version 1 & 2 of Tez UI > > > Key: AMBARI-16103 > URL: https://issues.apache.org/jira/browse/AMBARI-16103 > Project: Ambari > Issue Type: Task >Affects Versions: 2.4.0 >Reporter: Sreenath Somarajapuram >Assignee: Sreenath Somarajapuram > Fix For: 2.4.0 > > Attachments: AMBARI-16103.1.patch > > > Tez UI 1 would be soon replaced with Tez UI 2, and we need to ensure that the > Ambari view can work with both versions of the UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16128) Ambari 2.2.1.1 reporting ACID off on slider, but actually on
[ https://issues.apache.org/jira/browse/AMBARI-16128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261015#comment-15261015 ] Hudson commented on AMBARI-16128: - SUCCESS: Integrated in Ambari-trunk-Commit #4750 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4750/]) AMBARI-16128. Ambari 2.2.1.1 reporting ACID off on slider, but actually (vbrodetskyi: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=0b02517ad0b44a4b90d2fd856fd86dd61634f4d8]) * ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog240Test.java * ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java > Ambari 2.2.1.1 reporting ACID off on slider, but actually on > > > Key: AMBARI-16128 > URL: https://issues.apache.org/jira/browse/AMBARI-16128 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.1 >Reporter: Vitaly Brodetskyi >Assignee: Vitaly Brodetskyi >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16128.patch > > > PROBLEM: After upgrade of ambari from 2.0.1 to 2.2.1.0 the ACID slider has > gone back to off, even though ACID is on in cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16147) Ambari Web Service installation does not comply with Final Attribute. (isFinal is skipped)
[ https://issues.apache.org/jira/browse/AMBARI-16147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goutam Tadi updated AMBARI-16147: - Attachment: AMBARI-16147-trunk.patch > Ambari Web Service installation does not comply with Final Attribute. > (isFinal is skipped) > --- > > Key: AMBARI-16147 > URL: https://issues.apache.org/jira/browse/AMBARI-16147 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Goutam Tadi >Assignee: Goutam Tadi >Priority: Minor > Fix For: 2.4.0 > > Attachments: AMBARI-16147-trunk.patch > > > When installing HDFS/HIVE/any service the properties that are marked final > before installation are marked as de-finalized post installation. This occurs > at the last step of installation i.e deploy stage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16147) Ambari Web Service installation does not comply with Final Attribute. (isFinal is skipped)
[ https://issues.apache.org/jira/browse/AMBARI-16147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goutam Tadi updated AMBARI-16147: - Status: Patch Available (was: Open) > Ambari Web Service installation does not comply with Final Attribute. > (isFinal is skipped) > --- > > Key: AMBARI-16147 > URL: https://issues.apache.org/jira/browse/AMBARI-16147 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Goutam Tadi >Assignee: Goutam Tadi >Priority: Minor > Fix For: 2.4.0 > > Attachments: AMBARI-16147-trunk.patch > > > When installing HDFS/HIVE/any service the properties that are marked final > before installation are marked as de-finalized post installation. This occurs > at the last step of installation i.e deploy stage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16147) Ambari Web Service installation does not comply with Final Attribute. (isFinal is skipped)
[ https://issues.apache.org/jira/browse/AMBARI-16147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goutam Tadi updated AMBARI-16147: - Affects Version/s: (was: 2.4.0) 2.2.2 > Ambari Web Service installation does not comply with Final Attribute. > (isFinal is skipped) > --- > > Key: AMBARI-16147 > URL: https://issues.apache.org/jira/browse/AMBARI-16147 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Goutam Tadi >Assignee: Goutam Tadi >Priority: Minor > Fix For: 2.4.0 > > > When installing HDFS/HIVE/any service the properties that are marked final > before installation are marked as de-finalized post installation. This occurs > at the last step of installation i.e deploy stage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16147) Ambari Web Service installation does not comply with Final Attribute. (isFinal is skipped)
Goutam Tadi created AMBARI-16147: Summary: Ambari Web Service installation does not comply with Final Attribute. (isFinal is skipped) Key: AMBARI-16147 URL: https://issues.apache.org/jira/browse/AMBARI-16147 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.4.0 Reporter: Goutam Tadi Assignee: Goutam Tadi Priority: Minor Fix For: 2.2.2 When installing HDFS/HIVE/any service the properties that are marked final before installation are marked as de-finalized post installation. This occurs at the last step of installation i.e deploy stage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16139) Duplicate Dashboard metrics API calls should not be made in parallel
[ https://issues.apache.org/jira/browse/AMBARI-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261003#comment-15261003 ] Hudson commented on AMBARI-16139: - SUCCESS: Integrated in Ambari-branch-2.2 #676 (See [https://builds.apache.org/job/Ambari-branch-2.2/676/]) AMBARI-16139. Duplicate Dashboard metrics API calls should not be made (jaimin: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=4bf0400b33a971389ac8851912fc3cfc5eeab028]) * ambari-web/app/controllers/global/update_controller.js * ambari-web/test/views/common/chart/linear_time_test.js * ambari-web/app/views/common/chart/linear_time.js > Duplicate Dashboard metrics API calls should not be made in parallel > > > Key: AMBARI-16139 > URL: https://issues.apache.org/jira/browse/AMBARI-16139 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.1.2 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.4.0, 2.2-next > > Attachments: AMBARI-16139.patch, Screen Shot 2016-04-26 at 1.37.01 > PM.png > > > Graphs on Cluster dashboard page keeps making API calls irrespective of the > previous APIs call have completed or not. Thus on a cluster where AMS is > misbehaving there are multiple same API calls in pending state and results > into ambari-server unresponsive. > For Graph widgets, ajax calls should be made from the complete callback > function of the same ajax call. so until an ajax call is not finished, the > same ajax is not triggered again > we do this in correct way for enhanced service dashboard on service summary > page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16143) Ambari metrics API call should allow for early failure
[ https://issues.apache.org/jira/browse/AMBARI-16143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddharth Wagle updated AMBARI-16143: - Description: In case of a SocketTimeoutException skip populating the resource with metrics until the next retry. (was: In case of a ScoektTimeoutException skip populating the resource with metrics until the next retry.) > Ambari metrics API call should allow for early failure > -- > > Key: AMBARI-16143 > URL: https://issues.apache.org/jira/browse/AMBARI-16143 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: 2.1.2 >Reporter: Siddharth Wagle >Assignee: Siddharth Wagle >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16143.patch > > > In case of a SocketTimeoutException skip populating the resource with metrics > until the next retry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16143) Ambari metrics API call should allow for early failure
[ https://issues.apache.org/jira/browse/AMBARI-16143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddharth Wagle updated AMBARI-16143: - Status: Patch Available (was: Open) > Ambari metrics API call should allow for early failure > -- > > Key: AMBARI-16143 > URL: https://issues.apache.org/jira/browse/AMBARI-16143 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: 2.1.2 >Reporter: Siddharth Wagle >Assignee: Siddharth Wagle >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16143.patch > > > In case of a ScoektTimeoutException skip populating the resource with metrics > until the next retry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16143) Ambari metrics API call should allow for early failure
[ https://issues.apache.org/jira/browse/AMBARI-16143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddharth Wagle updated AMBARI-16143: - Attachment: AMBARI-16143.patch > Ambari metrics API call should allow for early failure > -- > > Key: AMBARI-16143 > URL: https://issues.apache.org/jira/browse/AMBARI-16143 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: 2.1.2 >Reporter: Siddharth Wagle >Assignee: Siddharth Wagle >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16143.patch > > > In case of a ScoektTimeoutException skip populating the resource with metrics > until the next retry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16145) Add dryrun API for host delete
[
https://issues.apache.org/jira/browse/AMBARI-16145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ajit Kumar updated AMBARI-16145:
Affects Version/s: 2.4.0
Fix Version/s: 2.4.0
Component/s: ambari-server
> Add dryrun API for host delete
> ---
>
> Key: AMBARI-16145
> URL: https://issues.apache.org/jira/browse/AMBARI-16145
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Ajit Kumar
>Assignee: Ajit Kumar
> Fix For: 2.4.0
>
>
> Add dryrun API for host delete
> API should be take dry_run directive and check if requested host can be
> deleted w/o deleting the host and should return error if any, like host is
> not in delete friendly state.
> {code}
> curl -i -X DELETE -u admin:admin -H 'X-Requested-By:ambari'
> 'http://localhost:8080/api/v1/clusters/c1/hosts?dry_run=true/host_name=c6401.ambari.apache.org'
> {code}
> It should also support bulk delete format
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16136) Make temp filenames unique when creating files
[ https://issues.apache.org/jira/browse/AMBARI-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-16136: --- Summary: Make temp filenames unique when creating files (was: Make temp filenames more unique when creating files) > Make temp filenames unique when creating files > -- > > Key: AMBARI-16136 > URL: https://issues.apache.org/jira/browse/AMBARI-16136 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.2.1.1 >Reporter: Sandor Magyari >Assignee: Sandor Magyari > Fix For: 2.2-next > > > When creating files on linux, ambari-agent use create_file() in sudo.py. Here > first a temp file created, copied over the right place later. The filename of > this temp file currently is: tmpf_name = tempfile.gettempdir() + os.sep + > tempfile.template + str(time.time()). This may cause problems in case of > parallel executions, thread name or something random should be added to be > more unique. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16145) Add dryrun API for host delete
Ajit Kumar created AMBARI-16145:
---
Summary: Add dryrun API for host delete
Key: AMBARI-16145
URL: https://issues.apache.org/jira/browse/AMBARI-16145
Project: Ambari
Issue Type: Task
Reporter: Ajit Kumar
Assignee: Ajit Kumar
Add dryrun API for host delete
API should be take dry_run directive and check if requested host can be deleted
w/o deleting the host and should return error if any, like host is not in
delete friendly state.
{code}
curl -i -X DELETE -u admin:admin -H 'X-Requested-By:ambari'
'http://localhost:8080/api/v1/clusters/c1/hosts?dry_run=true/host_name=c6401.ambari.apache.org'
{code}
It should also support bulk delete format
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16094) Improvements to DB consistency check
[
https://issues.apache.org/jira/browse/AMBARI-16094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260939#comment-15260939
]
Hadoop QA commented on AMBARI-16094:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12801088/AMBARI-16094.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
ambari-server:
org.apache.ambari.server.controller.utilities.DatabaseCheckerTest
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6692//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6692//console
This message is automatically generated.
> Improvements to DB consistency check
>
>
> Key: AMBARI-16094
> URL: https://issues.apache.org/jira/browse/AMBARI-16094
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16094.patch
>
>
> * disable (we can remove later) DatabaseCheck
> * Have CheckDatabaseHelper be called as part of ambari-server start
> ** Modify {{ambari-server start}} to so that it calls {{ambari-server
> check-database}}
> *ambari-server check-database improvements*
> * On the output modify {{Ambari Server 'check-database' completed
> successfully.}} to {{Ambari Server 'check-database' completed.}} - _remove
> successfully_
> * Use “--skip-database-check” (not skip-database-validation) to force
> ambari-server to start despite error
> * If there is error when check-database is run then use the following text
> {code}
> DB configs consistency check failed. Run “ambari-server start
> --skip-database-check” to skip. If you use this “--skip-database-check”
> option, do not make any changes to your cluster topology or perform a cluster
> upgrade until you correct the database consistency issues. See
> "/var/log/ambari-server/ambari-check-database.log" for more details on the
> consistency issues.
> {code}
> *ambari-server start improvements*
> * On Ambari Server start, the output failure text to should mention
> ambari-server.log (in addition to .out file it does today)
> * If user has not specified {{--skip-database-check}} fail start command if
> check-database reports error
> * When user starts server with --skip-database-check, if there are DB check
> errors, print message:
> {code}
> Ambari Server is starting with the database consistency check skipped. Do not
> make any changes to your cluster topology or perform a cluster upgrade until
> you correct the database consistency issues. See
> "/var/log/ambari-server/ambari-check-database.log" for more details on the
> consistency issues.
> {code}
> When using log file paths, make sure to use the right path from log4j.
> *Optional*
> Modify ambari.properties to add {{database_check_error_skipped=true}} if user
> started with {{--skip-database-check}} and there were errors due to
> database-check. If there are no errors then store
> {{database_check_error_skipped=false}}. Eventually, UI will use this property
> and show warnings to the user and even prevent HDP upgrade or other topology
> modifying operations such as Add Host/Service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16142) Add getDeleteDirectives to org.apache.ambari.server.api.resources.ResourceDefinition and use when handling DELETE requests
[ https://issues.apache.org/jira/browse/AMBARI-16142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ajit Kumar updated AMBARI-16142: Affects Version/s: 2.4.0 Fix Version/s: 2.4.0 Component/s: ambari-server > Add getDeleteDirectives to > org.apache.ambari.server.api.resources.ResourceDefinition and use when > handling DELETE requests > -- > > Key: AMBARI-16142 > URL: https://issues.apache.org/jira/browse/AMBARI-16142 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Ajit Kumar >Assignee: Ajit Kumar > Fix For: 2.4.0 > > Attachments: rb46748.patch > > > Add delete directive to RequestDefinition and handle it in Delete requests. > It will be useful for usecases like dry run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16142) Add getDeleteDirectives to org.apache.ambari.server.api.resources.ResourceDefinition and use when handling DELETE requests
[ https://issues.apache.org/jira/browse/AMBARI-16142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ajit Kumar updated AMBARI-16142: Status: Patch Available (was: Open) > Add getDeleteDirectives to > org.apache.ambari.server.api.resources.ResourceDefinition and use when > handling DELETE requests > -- > > Key: AMBARI-16142 > URL: https://issues.apache.org/jira/browse/AMBARI-16142 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Ajit Kumar >Assignee: Ajit Kumar > Fix For: 2.4.0 > > Attachments: rb46748.patch > > > Add delete directive to RequestDefinition and handle it in Delete requests. > It will be useful for usecases like dry run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16142) Add getDeleteDirectives to org.apache.ambari.server.api.resources.ResourceDefinition and use when handling DELETE requests
[ https://issues.apache.org/jira/browse/AMBARI-16142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ajit Kumar updated AMBARI-16142: Attachment: rb46748.patch > Add getDeleteDirectives to > org.apache.ambari.server.api.resources.ResourceDefinition and use when > handling DELETE requests > -- > > Key: AMBARI-16142 > URL: https://issues.apache.org/jira/browse/AMBARI-16142 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Ajit Kumar >Assignee: Ajit Kumar > Fix For: 2.4.0 > > Attachments: rb46748.patch > > > Add delete directive to RequestDefinition and handle it in Delete requests. > It will be useful for usecases like dry run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16142) Add getDeleteDirectives to org.apache.ambari.server.api.resources.ResourceDefinition and use when handling DELETE requests
[ https://issues.apache.org/jira/browse/AMBARI-16142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ajit Kumar updated AMBARI-16142: Status: Patch Available (was: Open) > Add getDeleteDirectives to > org.apache.ambari.server.api.resources.ResourceDefinition and use when > handling DELETE requests > -- > > Key: AMBARI-16142 > URL: https://issues.apache.org/jira/browse/AMBARI-16142 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Ajit Kumar >Assignee: Ajit Kumar > Attachments: rb46748.patch > > > Add delete directive to RequestDefinition and handle it in Delete requests. > It will be useful for usecases like dry run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16142) Add getDeleteDirectives to org.apache.ambari.server.api.resources.ResourceDefinition and use when handling DELETE requests
[ https://issues.apache.org/jira/browse/AMBARI-16142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ajit Kumar updated AMBARI-16142: Status: Open (was: Patch Available) > Add getDeleteDirectives to > org.apache.ambari.server.api.resources.ResourceDefinition and use when > handling DELETE requests > -- > > Key: AMBARI-16142 > URL: https://issues.apache.org/jira/browse/AMBARI-16142 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Ajit Kumar >Assignee: Ajit Kumar > Fix For: 2.4.0 > > Attachments: rb46748.patch > > > Add delete directive to RequestDefinition and handle it in Delete requests. > It will be useful for usecases like dry run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16144) Stack advisor scripts should handle calls where dependent services do not exist
[ https://issues.apache.org/jira/browse/AMBARI-16144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-16144: --- Attachment: AMBARI-16144.patch > Stack advisor scripts should handle calls where dependent services do not > exist > --- > > Key: AMBARI-16144 > URL: https://issues.apache.org/jira/browse/AMBARI-16144 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.2.0 >Reporter: Sumit Mohanty >Assignee: Sumit Mohanty >Priority: Critical > Fix For: 2.2-next > > Attachments: AMBARI-16144.patch > > > Several stack components such as AMS and HAWQ assume that HDFS to be > installed. However, it is possible to deploy cluster that does not have HDFS > deployed. The logic should be robust enough to handle absence of components > such as DATANODE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16144) Stack advisor scripts should handle calls where dependent services do not exist
Sumit Mohanty created AMBARI-16144: -- Summary: Stack advisor scripts should handle calls where dependent services do not exist Key: AMBARI-16144 URL: https://issues.apache.org/jira/browse/AMBARI-16144 Project: Ambari Issue Type: Bug Components: stacks Affects Versions: 2.2.0 Reporter: Sumit Mohanty Assignee: Sumit Mohanty Priority: Critical Fix For: 2.2-next Several stack components such as AMS and HAWQ assume that HDFS to be installed. However, it is possible to deploy cluster that does not have HDFS deployed. The logic should be robust enough to handle absence of components such as DATANODE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16131) Prevent Views From Causing a Loss of Service For Ambari
[
https://issues.apache.org/jira/browse/AMBARI-16131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260843#comment-15260843
]
Hudson commented on AMBARI-16131:
-
SUCCESS: Integrated in Ambari-branch-2.2 #675 (See
[https://builds.apache.org/job/Ambari-branch-2.2/675/])
AMBARI-16131 - Prevent Views From Causing a Loss of Service For Ambari
(jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=84e1d84d1f72ca9a4799f5c592a59479c6f7ab42])
*
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
*
ambari-server/src/main/java/org/apache/ambari/server/view/ViewThrottleFilter.java
* ambari-server/src/main/java/org/apache/ambari/server/utils/VersionUtils.java
*
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java
*
ambari-server/src/test/java/org/apache/ambari/server/view/ViewThrottleFilterTest.java
* ambari-server/src/main/java/org/apache/ambari/server/view/ViewRegistry.java
> Prevent Views From Causing a Loss of Service For Ambari
> ---
>
> Key: AMBARI-16131
> URL: https://issues.apache.org/jira/browse/AMBARI-16131
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.0.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.4.0, 2.2-next
>
> Attachments: AMBARI-16131.patch
>
>
> The underlying problem is that views are accessed off of the REST endpoint
> ({{/api/v1/views}}). This means that the Ambari REST API connector is going
> to handle the request from its own threadpool. There is no way to configure
> Jetty to use a different threadpool for the same connector. As a result, if a
> request to load a view holds the Jetty thread hostage, eventually we will see
> thread starvation and loss of service.
> An example of this situation is a view which makes an innocent request to a
> remote resource. If the view's request has a timeout of 60 seconds, then the
> Jetty thread is going to be held for that amount of time. With concurrent
> users and multiple instances of that view deployed, the Jetty threadpool can
> becomes exhausted quickly.
> Although there are more graceful ways of handling this situation, they mostly
> involve substantial re-architecture and design:
> - The use of a new connector and threadpool would require binding to another
> port for view requests. This will cause problems with "local" views and their
> assumption that if they run on the Ambari server they can share the same
> session.
> - The use of a
> [Continuation|https://wiki.eclipse.org/Jetty/Feature/Continuations] in Jetty
> which can suspend the incoming request. We would need the ability for views
> to signal that they have completed their work in order to proceed with the
> suspended request.
> A quicker and far less invasive fix would be to create a filter which
> intercepts requests for views. It will determine how many executing view
> requests exist and decide if it will allow the new request through. For
> example, if configured to allow a maximum of 10 concurrent view requests,
> then the 11th request would be denied with an {{HTTP 503 - Service
> Unavailable}}. Although the thread is temporarily used while the filter is
> processing, it's quickly returned to the Jetty pool when it's determined
> there are too many other running view requests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16089) Atlas Integration : set atlas.cluster.name in hive-site
[ https://issues.apache.org/jira/browse/AMBARI-16089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260828#comment-15260828 ] Hudson commented on AMBARI-16089: - SUCCESS: Integrated in Ambari-trunk-Commit #4749 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4749/]) AMBARI-16089 - Atlas Integration : set atlas.cluster.name in hive-site (tbeerbower: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=4104f2f9d61dbc3d01ea8dfcbfe9faa6ece2b03c]) * ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py * ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml * ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py * ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py * ambari-server/src/test/python/stacks/2.3/common/test_stack_advisor.py * ambari-server/src/main/resources/stacks/HDP/2.5/services/ATLAS/configuration/application-properties.xml > Atlas Integration : set atlas.cluster.name in hive-site > --- > > Key: AMBARI-16089 > URL: https://issues.apache.org/jira/browse/AMBARI-16089 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > > After deploying Hive+Atlas via Ambari, the value of 'atlas.cluster.name‘ in > 'Advanced hive-site’ is ‘default’. This results in incorrect value in entity > notifications to Ranger. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16139) Duplicate Dashboard metrics API calls should not be made in parallel
[ https://issues.apache.org/jira/browse/AMBARI-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-16139: Resolution: Fixed Status: Resolved (was: Patch Available) Patch committed to trunk and branch-2.2 > Duplicate Dashboard metrics API calls should not be made in parallel > > > Key: AMBARI-16139 > URL: https://issues.apache.org/jira/browse/AMBARI-16139 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.1.2 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.4.0, 2.2-next > > Attachments: AMBARI-16139.patch, Screen Shot 2016-04-26 at 1.37.01 > PM.png > > > Graphs on Cluster dashboard page keeps making API calls irrespective of the > previous APIs call have completed or not. Thus on a cluster where AMS is > misbehaving there are multiple same API calls in pending state and results > into ambari-server unresponsive. > For Graph widgets, ajax calls should be made from the complete callback > function of the same ajax call. so until an ajax call is not finished, the > same ajax is not triggered again > we do this in correct way for enhanced service dashboard on service summary > page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16139) Duplicate Dashboard metrics API calls should not be made in parallel
[ https://issues.apache.org/jira/browse/AMBARI-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-16139: Fix Version/s: 2.2-next > Duplicate Dashboard metrics API calls should not be made in parallel > > > Key: AMBARI-16139 > URL: https://issues.apache.org/jira/browse/AMBARI-16139 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.1.2 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.4.0, 2.2-next > > Attachments: AMBARI-16139.patch, Screen Shot 2016-04-26 at 1.37.01 > PM.png > > > Graphs on Cluster dashboard page keeps making API calls irrespective of the > previous APIs call have completed or not. Thus on a cluster where AMS is > misbehaving there are multiple same API calls in pending state and results > into ambari-server unresponsive. > For Graph widgets, ajax calls should be made from the complete callback > function of the same ajax call. so until an ajax call is not finished, the > same ajax is not triggered again > we do this in correct way for enhanced service dashboard on service summary > page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16143) Ambari metrics API call should allow for early failure
[ https://issues.apache.org/jira/browse/AMBARI-16143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddharth Wagle updated AMBARI-16143: - Description: In case of a ScoektTimeoutException skip populating the resource with metrics until the next retry. (was: In case of a ScoektTimeoutException skip populating the resource with metrics until the next retry. Implement aggressive back-off and retry policy to enable multiple browser session being un-blocked if the AMS API calls are throwing SocketTimeoutExecption.) > Ambari metrics API call should allow for early failure > -- > > Key: AMBARI-16143 > URL: https://issues.apache.org/jira/browse/AMBARI-16143 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: 2.1.2 >Reporter: Siddharth Wagle >Assignee: Siddharth Wagle >Priority: Critical > Fix For: 2.4.0 > > > In case of a ScoektTimeoutException skip populating the resource with metrics > until the next retry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16128) Ambari 2.2.1.1 reporting ACID off on slider, but actually on
[ https://issues.apache.org/jira/browse/AMBARI-16128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaly Brodetskyi updated AMBARI-16128: --- Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk > Ambari 2.2.1.1 reporting ACID off on slider, but actually on > > > Key: AMBARI-16128 > URL: https://issues.apache.org/jira/browse/AMBARI-16128 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.1 >Reporter: Vitaly Brodetskyi >Assignee: Vitaly Brodetskyi >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16128.patch > > > PROBLEM: After upgrade of ambari from 2.0.1 to 2.2.1.0 the ACID slider has > gone back to off, even though ACID is on in cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16094) Improvements to DB consistency check
[
https://issues.apache.org/jira/browse/AMBARI-16094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaly Brodetskyi updated AMBARI-16094:
---
Attachment: AMBARI-16094.patch
> Improvements to DB consistency check
>
>
> Key: AMBARI-16094
> URL: https://issues.apache.org/jira/browse/AMBARI-16094
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16094.patch, AMBARI-16094.patch
>
>
> * disable (we can remove later) DatabaseCheck
> * Have CheckDatabaseHelper be called as part of ambari-server start
> ** Modify {{ambari-server start}} to so that it calls {{ambari-server
> check-database}}
> *ambari-server check-database improvements*
> * On the output modify {{Ambari Server 'check-database' completed
> successfully.}} to {{Ambari Server 'check-database' completed.}} - _remove
> successfully_
> * Use “--skip-database-check” (not skip-database-validation) to force
> ambari-server to start despite error
> * If there is error when check-database is run then use the following text
> {code}
> DB configs consistency check failed. Run “ambari-server start
> --skip-database-check” to skip. If you use this “--skip-database-check”
> option, do not make any changes to your cluster topology or perform a cluster
> upgrade until you correct the database consistency issues. See
> "/var/log/ambari-server/ambari-check-database.log" for more details on the
> consistency issues.
> {code}
> *ambari-server start improvements*
> * On Ambari Server start, the output failure text to should mention
> ambari-server.log (in addition to .out file it does today)
> * If user has not specified {{--skip-database-check}} fail start command if
> check-database reports error
> * When user starts server with --skip-database-check, if there are DB check
> errors, print message:
> {code}
> Ambari Server is starting with the database consistency check skipped. Do not
> make any changes to your cluster topology or perform a cluster upgrade until
> you correct the database consistency issues. See
> "/var/log/ambari-server/ambari-check-database.log" for more details on the
> consistency issues.
> {code}
> When using log file paths, make sure to use the right path from log4j.
> *Optional*
> Modify ambari.properties to add {{database_check_error_skipped=true}} if user
> started with {{--skip-database-check}} and there were errors due to
> database-check. If there are no errors then store
> {{database_check_error_skipped=false}}. Eventually, UI will use this property
> and show warnings to the user and even prevent HDP upgrade or other topology
> modifying operations such as Add Host/Service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16094) Improvements to DB consistency check
[
https://issues.apache.org/jira/browse/AMBARI-16094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaly Brodetskyi updated AMBARI-16094:
---
Attachment: (was: AMBARI-16094.patch)
> Improvements to DB consistency check
>
>
> Key: AMBARI-16094
> URL: https://issues.apache.org/jira/browse/AMBARI-16094
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16094.patch
>
>
> * disable (we can remove later) DatabaseCheck
> * Have CheckDatabaseHelper be called as part of ambari-server start
> ** Modify {{ambari-server start}} to so that it calls {{ambari-server
> check-database}}
> *ambari-server check-database improvements*
> * On the output modify {{Ambari Server 'check-database' completed
> successfully.}} to {{Ambari Server 'check-database' completed.}} - _remove
> successfully_
> * Use “--skip-database-check” (not skip-database-validation) to force
> ambari-server to start despite error
> * If there is error when check-database is run then use the following text
> {code}
> DB configs consistency check failed. Run “ambari-server start
> --skip-database-check” to skip. If you use this “--skip-database-check”
> option, do not make any changes to your cluster topology or perform a cluster
> upgrade until you correct the database consistency issues. See
> "/var/log/ambari-server/ambari-check-database.log" for more details on the
> consistency issues.
> {code}
> *ambari-server start improvements*
> * On Ambari Server start, the output failure text to should mention
> ambari-server.log (in addition to .out file it does today)
> * If user has not specified {{--skip-database-check}} fail start command if
> check-database reports error
> * When user starts server with --skip-database-check, if there are DB check
> errors, print message:
> {code}
> Ambari Server is starting with the database consistency check skipped. Do not
> make any changes to your cluster topology or perform a cluster upgrade until
> you correct the database consistency issues. See
> "/var/log/ambari-server/ambari-check-database.log" for more details on the
> consistency issues.
> {code}
> When using log file paths, make sure to use the right path from log4j.
> *Optional*
> Modify ambari.properties to add {{database_check_error_skipped=true}} if user
> started with {{--skip-database-check}} and there were errors due to
> database-check. If there are no errors then store
> {{database_check_error_skipped=false}}. Eventually, UI will use this property
> and show warnings to the user and even prevent HDP upgrade or other topology
> modifying operations such as Add Host/Service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16103) Tez View : Equip the tez view shim to work with both version 1 & 2 of Tez UI
[ https://issues.apache.org/jira/browse/AMBARI-16103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hitesh Shah updated AMBARI-16103: - Resolution: Fixed Fix Version/s: 2.4.0 Status: Resolved (was: Patch Available) Committed to trunk. Thanks [~Sreenath] > Tez View : Equip the tez view shim to work with both version 1 & 2 of Tez UI > > > Key: AMBARI-16103 > URL: https://issues.apache.org/jira/browse/AMBARI-16103 > Project: Ambari > Issue Type: Task >Affects Versions: 2.4.0 >Reporter: Sreenath Somarajapuram >Assignee: Sreenath Somarajapuram > Fix For: 2.4.0 > > Attachments: AMBARI-16103.1.patch > > > Tez UI 1 would be soon replaced with Tez UI 2, and we need to ensure that the > Ambari view can work with both versions of the UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16131) Prevent Views From Causing a Loss of Service For Ambari
[
https://issues.apache.org/jira/browse/AMBARI-16131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-16131:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Prevent Views From Causing a Loss of Service For Ambari
> ---
>
> Key: AMBARI-16131
> URL: https://issues.apache.org/jira/browse/AMBARI-16131
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.0.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.4.0, 2.2-next
>
> Attachments: AMBARI-16131.patch
>
>
> The underlying problem is that views are accessed off of the REST endpoint
> ({{/api/v1/views}}). This means that the Ambari REST API connector is going
> to handle the request from its own threadpool. There is no way to configure
> Jetty to use a different threadpool for the same connector. As a result, if a
> request to load a view holds the Jetty thread hostage, eventually we will see
> thread starvation and loss of service.
> An example of this situation is a view which makes an innocent request to a
> remote resource. If the view's request has a timeout of 60 seconds, then the
> Jetty thread is going to be held for that amount of time. With concurrent
> users and multiple instances of that view deployed, the Jetty threadpool can
> becomes exhausted quickly.
> Although there are more graceful ways of handling this situation, they mostly
> involve substantial re-architecture and design:
> - The use of a new connector and threadpool would require binding to another
> port for view requests. This will cause problems with "local" views and their
> assumption that if they run on the Ambari server they can share the same
> session.
> - The use of a
> [Continuation|https://wiki.eclipse.org/Jetty/Feature/Continuations] in Jetty
> which can suspend the incoming request. We would need the ability for views
> to signal that they have completed their work in order to proceed with the
> suspended request.
> A quicker and far less invasive fix would be to create a filter which
> intercepts requests for views. It will determine how many executing view
> requests exist and decide if it will allow the new request through. For
> example, if configured to allow a maximum of 10 concurrent view requests,
> then the 11th request would be denied with an {{HTTP 503 - Service
> Unavailable}}. Although the thread is temporarily used while the filter is
> processing, it's quickly returned to the Jetty pool when it's determined
> there are too many other running view requests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16131) Prevent Views From Causing a Loss of Service For Ambari
[
https://issues.apache.org/jira/browse/AMBARI-16131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-16131:
-
Fix Version/s: 2.2-next
> Prevent Views From Causing a Loss of Service For Ambari
> ---
>
> Key: AMBARI-16131
> URL: https://issues.apache.org/jira/browse/AMBARI-16131
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.0.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.4.0, 2.2-next
>
> Attachments: AMBARI-16131.patch
>
>
> The underlying problem is that views are accessed off of the REST endpoint
> ({{/api/v1/views}}). This means that the Ambari REST API connector is going
> to handle the request from its own threadpool. There is no way to configure
> Jetty to use a different threadpool for the same connector. As a result, if a
> request to load a view holds the Jetty thread hostage, eventually we will see
> thread starvation and loss of service.
> An example of this situation is a view which makes an innocent request to a
> remote resource. If the view's request has a timeout of 60 seconds, then the
> Jetty thread is going to be held for that amount of time. With concurrent
> users and multiple instances of that view deployed, the Jetty threadpool can
> becomes exhausted quickly.
> Although there are more graceful ways of handling this situation, they mostly
> involve substantial re-architecture and design:
> - The use of a new connector and threadpool would require binding to another
> port for view requests. This will cause problems with "local" views and their
> assumption that if they run on the Ambari server they can share the same
> session.
> - The use of a
> [Continuation|https://wiki.eclipse.org/Jetty/Feature/Continuations] in Jetty
> which can suspend the incoming request. We would need the ability for views
> to signal that they have completed their work in order to proceed with the
> suspended request.
> A quicker and far less invasive fix would be to create a filter which
> intercepts requests for views. It will determine how many executing view
> requests exist and decide if it will allow the new request through. For
> example, if configured to allow a maximum of 10 concurrent view requests,
> then the 11th request would be denied with an {{HTTP 503 - Service
> Unavailable}}. Although the thread is temporarily used while the filter is
> processing, it's quickly returned to the Jetty pool when it's determined
> there are too many other running view requests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16131) Prevent Views From Causing a Loss of Service For Ambari
[
https://issues.apache.org/jira/browse/AMBARI-16131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-16131:
-
Attachment: AMBARI-16131.patch
> Prevent Views From Causing a Loss of Service For Ambari
> ---
>
> Key: AMBARI-16131
> URL: https://issues.apache.org/jira/browse/AMBARI-16131
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.0.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16131.patch
>
>
> The underlying problem is that views are accessed off of the REST endpoint
> ({{/api/v1/views}}). This means that the Ambari REST API connector is going
> to handle the request from its own threadpool. There is no way to configure
> Jetty to use a different threadpool for the same connector. As a result, if a
> request to load a view holds the Jetty thread hostage, eventually we will see
> thread starvation and loss of service.
> An example of this situation is a view which makes an innocent request to a
> remote resource. If the view's request has a timeout of 60 seconds, then the
> Jetty thread is going to be held for that amount of time. With concurrent
> users and multiple instances of that view deployed, the Jetty threadpool can
> becomes exhausted quickly.
> Although there are more graceful ways of handling this situation, they mostly
> involve substantial re-architecture and design:
> - The use of a new connector and threadpool would require binding to another
> port for view requests. This will cause problems with "local" views and their
> assumption that if they run on the Ambari server they can share the same
> session.
> - The use of a
> [Continuation|https://wiki.eclipse.org/Jetty/Feature/Continuations] in Jetty
> which can suspend the incoming request. We would need the ability for views
> to signal that they have completed their work in order to proceed with the
> suspended request.
> A quicker and far less invasive fix would be to create a filter which
> intercepts requests for views. It will determine how many executing view
> requests exist and decide if it will allow the new request through. For
> example, if configured to allow a maximum of 10 concurrent view requests,
> then the 11th request would be denied with an {{HTTP 503 - Service
> Unavailable}}. Although the thread is temporarily used while the filter is
> processing, it's quickly returned to the Jetty pool when it's determined
> there are too many other running view requests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16131) Prevent Views From Causing a Loss of Service For Ambari
[
https://issues.apache.org/jira/browse/AMBARI-16131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-16131:
-
Status: Patch Available (was: Open)
> Prevent Views From Causing a Loss of Service For Ambari
> ---
>
> Key: AMBARI-16131
> URL: https://issues.apache.org/jira/browse/AMBARI-16131
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.0.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16131.patch
>
>
> The underlying problem is that views are accessed off of the REST endpoint
> ({{/api/v1/views}}). This means that the Ambari REST API connector is going
> to handle the request from its own threadpool. There is no way to configure
> Jetty to use a different threadpool for the same connector. As a result, if a
> request to load a view holds the Jetty thread hostage, eventually we will see
> thread starvation and loss of service.
> An example of this situation is a view which makes an innocent request to a
> remote resource. If the view's request has a timeout of 60 seconds, then the
> Jetty thread is going to be held for that amount of time. With concurrent
> users and multiple instances of that view deployed, the Jetty threadpool can
> becomes exhausted quickly.
> Although there are more graceful ways of handling this situation, they mostly
> involve substantial re-architecture and design:
> - The use of a new connector and threadpool would require binding to another
> port for view requests. This will cause problems with "local" views and their
> assumption that if they run on the Ambari server they can share the same
> session.
> - The use of a
> [Continuation|https://wiki.eclipse.org/Jetty/Feature/Continuations] in Jetty
> which can suspend the incoming request. We would need the ability for views
> to signal that they have completed their work in order to proceed with the
> suspended request.
> A quicker and far less invasive fix would be to create a filter which
> intercepts requests for views. It will determine how many executing view
> requests exist and decide if it will allow the new request through. For
> example, if configured to allow a maximum of 10 concurrent view requests,
> then the 11th request would be denied with an {{HTTP 503 - Service
> Unavailable}}. Although the thread is temporarily used while the filter is
> processing, it's quickly returned to the Jetty pool when it's determined
> there are too many other running view requests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16022) Config group UI enhancements
[ https://issues.apache.org/jira/browse/AMBARI-16022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260632#comment-15260632 ] Antonenko Alexander commented on AMBARI-16022: -- [~sangeetar] Thank you for your approach, this is something we really missed in Config group UI. Please update patch using [~akovalenko] notes. And once it will be ready, I will commit it. > Config group UI enhancements > > > Key: AMBARI-16022 > URL: https://issues.apache.org/jira/browse/AMBARI-16022 > Project: Ambari > Issue Type: Improvement > Components: ambari-web >Affects Versions: trunk >Reporter: Sangeeta Ravindran >Assignee: Sangeeta Ravindran >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-16022.patch, > configGrpDescValidation_afterfix.jpg, > saveconfigrpdlgmsglongnames_afterfix.jpg, > saveconfigrpdlgmsglongnames_beforefix.jpg, > tooltipaddedeachgrpinlist_afterfix.jpg, tooltipaddedselectedgrp_afterfix.jpg > > > 1. The drop-down listing config-groups seems to truncate the group name when > the length exceeds 18. If the config group name is longer, the full name is > is not visible. The items in the drop-down list also show the partial > truncated name. Having a tooltip would allow for the entire name to be > displayed. > 2. In Manage Config Groups, the Description field allows entry of special > characters. Need to restrict characters since the description is stored in > the Database. > 3. Save Configuration Group dialog, the message spills outside the inner > frame. Need to make the text wrap. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16089) Atlas Integration : set atlas.cluster.name in hive-site
[ https://issues.apache.org/jira/browse/AMBARI-16089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Beerbower updated AMBARI-16089: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Atlas Integration : set atlas.cluster.name in hive-site > --- > > Key: AMBARI-16089 > URL: https://issues.apache.org/jira/browse/AMBARI-16089 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > > After deploying Hive+Atlas via Ambari, the value of 'atlas.cluster.name‘ in > 'Advanced hive-site’ is ‘default’. This results in incorrect value in entity > notifications to Ranger. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16090) Atlas Integration : add defult login method configuration
[
https://issues.apache.org/jira/browse/AMBARI-16090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Beerbower updated AMBARI-16090:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Atlas Integration : add defult login method configuration
> -
>
> Key: AMBARI-16090
> URL: https://issues.apache.org/jira/browse/AMBARI-16090
> Project: Ambari
> Issue Type: Bug
>Reporter: Tom Beerbower
>Assignee: Tom Beerbower
>
> To enable login to Atlas UI, following properties have to be manually added
> to ‘Custom application-properties’ in Atlas.
> {code}
> atlas.login.method=file
> atlas.login.credentials.file=/etc/atlas/conf/users-credentials.properties
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16022) Config group UI enhancements
[ https://issues.apache.org/jira/browse/AMBARI-16022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260580#comment-15260580 ] Aleksandr Kovalenko commented on AMBARI-16022: -- [~sangeetar], I do not agree, that we need to restrict user in description field. In this field users usually write sentences with punctuation to explain something about this group. So we should not restrict users in using , . ! ? and so on. It is not a problem for DB to store these characters. Also now users already have clusters with config groups with description without validation, but after upgrading to new version with this validation they should change all the descriptions, that is not good. And regarding tooltips, it is a good idea to show the full group name in tooltip. > Config group UI enhancements > > > Key: AMBARI-16022 > URL: https://issues.apache.org/jira/browse/AMBARI-16022 > Project: Ambari > Issue Type: Improvement > Components: ambari-web >Affects Versions: trunk >Reporter: Sangeeta Ravindran >Assignee: Sangeeta Ravindran >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-16022.patch, > configGrpDescValidation_afterfix.jpg, > saveconfigrpdlgmsglongnames_afterfix.jpg, > saveconfigrpdlgmsglongnames_beforefix.jpg, > tooltipaddedeachgrpinlist_afterfix.jpg, tooltipaddedselectedgrp_afterfix.jpg > > > 1. The drop-down listing config-groups seems to truncate the group name when > the length exceeds 18. If the config group name is longer, the full name is > is not visible. The items in the drop-down list also show the partial > truncated name. Having a tooltip would allow for the entire name to be > displayed. > 2. In Manage Config Groups, the Description field allows entry of special > characters. Need to restrict characters since the description is stored in > the Database. > 3. Save Configuration Group dialog, the message spills outside the inner > frame. Need to make the text wrap. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16125) 500-error on PUT to the repository_versions endpoint
[ https://issues.apache.org/jira/browse/AMBARI-16125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260577#comment-15260577 ] Hudson commented on AMBARI-16125: - SUCCESS: Integrated in Ambari-trunk-Commit #4748 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4748/]) AMBARI-16125. 500-error on PUT to the repository_versions endpoint (ncole: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=bff239c08cb0409898f71c764c0514c03b0ca087]) * ambari-server/src/main/java/org/apache/ambari/server/controller/internal/RepositoryVersionResourceProvider.java > 500-error on PUT to the repository_versions endpoint > > > Key: AMBARI-16125 > URL: https://issues.apache.org/jira/browse/AMBARI-16125 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Nate Cole >Assignee: Nate Cole > Fix For: 2.4.0 > > Attachments: AMBARI-16125.patch > > > RepositoryVersionResourceProvider would check the version being > created/updated was able to be a target for upgrade. This logic is now > incorrect as we can create versions with no cluster installed at all. There > are other places that check compatibility and is unnecessary in the provider. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16129) LogSearch Integration using incorrect query parameters for LogSearch
[ https://issues.apache.org/jira/browse/AMBARI-16129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260576#comment-15260576 ] Hudson commented on AMBARI-16129: - SUCCESS: Integrated in Ambari-trunk-Commit #4748 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4748/]) AMBARI-16129. LogSearch Integration using incorrect query parameters for (rnettleton: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=025b3446ffe4c3389654932e5b9b619432c25d36]) * ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingSearchPropertyProvider.java * ambari-server/src/test/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperImplTest.java * ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperImpl.java * ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingRequestHelper.java * ambari-server/src/test/java/org/apache/ambari/server/controller/logging/LoggingSearchPropertyProviderTest.java > LogSearch Integration using incorrect query parameters for LogSearch > > > Key: AMBARI-16129 > URL: https://issues.apache.org/jira/browse/AMBARI-16129 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Robert Nettleton >Assignee: Robert Nettleton >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16129.patch.2 > > > The LogSearch integration layer in Ambari is passing incorrect query > parameters to the LogSearch Server. Recent multi-node testing has uncovered > this issue. > The LogSearch integration code should use "host_name" for specifying hosts in > query URLs, and "component_name" for specifying the component for a given > LogSearch query. The "component_name" change is related to a change in the > parameters for LogSearch itself, which used to use "components_name". > The integration code should be updated to use these query parameter names. > I'm working on a fix for this, and will be submitting a patch shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16143) Ambari metrics API call should allow for early failure
Siddharth Wagle created AMBARI-16143: Summary: Ambari metrics API call should allow for early failure Key: AMBARI-16143 URL: https://issues.apache.org/jira/browse/AMBARI-16143 Project: Ambari Issue Type: Improvement Components: ambari-server Affects Versions: 2.1.2 Reporter: Siddharth Wagle Assignee: Siddharth Wagle Priority: Critical Fix For: 2.4.0 In case of a ScoektTimeoutException skip populating the resource with metrics until the next retry. Implement aggressive back-off and retry policy to enable multiple browser session being un-blocked if the AMS API calls are throwing SocketTimeoutExecption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16139) Duplicate Dashboard metrics API calls should not be made in parallel
[ https://issues.apache.org/jira/browse/AMBARI-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-16139: Description: Graphs on Cluster dashboard page keeps making API calls irrespective of the previous APIs call have completed or not. Thus on a cluster where AMS is misbehaving there are multiple same API calls in pending state and results into ambari-server unresponsive. For Graph widgets, ajax calls should be made from the complete callback function of the same ajax call. so until an ajax call is not finished, the same ajax is not triggered again we do this in correct way for enhanced service dashboard on service summary page was: Graphs on Cluster dashboard page keeps making API calls irrespective of the previous APIs call have completed or not. Thus on a cluster where AMS is behaving there are multiple same API calls in pending state and results into ambari-server unresponsive. For Graph widgets, ajax calls should be made from the complete callback function of the same ajax call. so until an ajax call is not finished, the same ajax is not triggered again we do this in correct way for enhanced service dashboard on service summary page > Duplicate Dashboard metrics API calls should not be made in parallel > > > Key: AMBARI-16139 > URL: https://issues.apache.org/jira/browse/AMBARI-16139 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.1.2 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16139.patch, Screen Shot 2016-04-26 at 1.37.01 > PM.png > > > Graphs on Cluster dashboard page keeps making API calls irrespective of the > previous APIs call have completed or not. Thus on a cluster where AMS is > misbehaving there are multiple same API calls in pending state and results > into ambari-server unresponsive. > For Graph widgets, ajax calls should be made from the complete callback > function of the same ajax call. so until an ajax call is not finished, the > same ajax is not triggered again > we do this in correct way for enhanced service dashboard on service summary > page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16140) ambari-agent RPM yum update should backup both stack and common-services
[
https://issues.apache.org/jira/browse/AMBARI-16140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260542#comment-15260542
]
Hadoop QA commented on AMBARI-16140:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12801051/AMBARI-16140.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/6691//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6691//console
This message is automatically generated.
> ambari-agent RPM yum update should backup both stack and common-services
>
>
> Key: AMBARI-16140
> URL: https://issues.apache.org/jira/browse/AMBARI-16140
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
> Fix For: trunk
>
> Attachments: AMBARI-16140.patch
>
>
> When a user runs yum upgrade ambari-agent. The preinstall script backs up the
> stack dir in /var/lib/ambari-agent/cache by renaming it with a stampstamp.
> The same logic should happen for /var/lib/ambari-agent/cache/common-services.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16106) Use additional flags for HAWQ Check
[ https://issues.apache.org/jira/browse/AMBARI-16106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt updated AMBARI-16106: -- Description: Make changes to HAWQ Check implementation based on HAWQ-668 > Use additional flags for HAWQ Check > --- > > Key: AMBARI-16106 > URL: https://issues.apache.org/jira/browse/AMBARI-16106 > Project: Ambari > Issue Type: Improvement > Components: stacks >Affects Versions: trunk, 2.2.0 >Reporter: Matt >Assignee: Matt >Priority: Minor > Fix For: 2.4.0 > > > Make changes to HAWQ Check implementation based on HAWQ-668 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16121) HBase RegionServers go down after Ambari upgrade due to ClassCastException
[
https://issues.apache.org/jira/browse/AMBARI-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahadev konar updated AMBARI-16121:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
> HBase RegionServers go down after Ambari upgrade due to ClassCastException
> --
>
> Key: AMBARI-16121
> URL: https://issues.apache.org/jira/browse/AMBARI-16121
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.2.2
>
> Attachments: AMBARI-16121.patch
>
>
> ambari-server --hash
> 2b112376b631384852a6c8aaa2e102d8dd39a9f1
> ambari-server-2.2.2.0-456.x86_64
> *Steps*
> # Deploy HDP 2.3.4.0 cluster with Ambari 2.2.0.0 (HA, unsecure cluster and
> Ranger enabled)
> # Upgrade Ambari to 2.2.2.0
> Observed that all HBase RS reported as down
> Logs show below error:
> {code}
> 016-04-26 09:47:23,575 ERROR [regionserver/host1/ip:16020]
> coprocessor.CoprocessorHost: The coprocessor
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint threw
> java.lang.ClassCastException:
> org.apache.hadoop.hbase.regionserver.RegionServerCoprocessorHost$RegionServerEnvironment
> cannot be cast to
> org.apache.hadoop.hbase.coprocessor.RegionCoprocessorEnvironment
> java.lang.ClassCastException:
> org.apache.hadoop.hbase.regionserver.RegionServerCoprocessorHost$RegionServerEnvironment
> cannot be cast to
> org.apache.hadoop.hbase.coprocessor.RegionCoprocessorEnvironment
> at
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint.start(SecureBulkLoadEndpoint.java:131)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.startup(CoprocessorHost.java:411)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadInstance(CoprocessorHost.java:253)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadSystemCoprocessors(CoprocessorHost.java:156)
> at
> org.apache.hadoop.hbase.regionserver.RegionServerCoprocessorHost.(RegionServerCoprocessorHost.java:69)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:888)
> at java.lang.Thread.run(Thread.java:745)
> 2016-04-26 09:47:23,584 FATAL [regionserver/host1/ip:16020]
> regionserver.HRegionServer: ABORTING region server host1,16020,1461664036377:
> The coprocessor
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint threw
> java.lang.ClassCastException:
> org.apache.hadoop.hbase.regionserver.RegionServerCoprocessorHost$RegionServerEnvironment
> cannot be cast to
> org.apache.hadoop.hbase.coprocessor.RegionCoprocessorEnvironment
> java.lang.ClassCastException:
> org.apache.hadoop.hbase.regionserver.RegionServerCoprocessorHost$RegionServerEnvironment
> cannot be cast to
> org.apache.hadoop.hbase.coprocessor.RegionCoprocessorEnvironment
> at
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint.start(SecureBulkLoadEndpoint.java:131)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.startup(CoprocessorHost.java:411)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadInstance(CoprocessorHost.java:253)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadSystemCoprocessors(CoprocessorHost.java:156)
> at
> org.apache.hadoop.hbase.regionserver.RegionServerCoprocessorHost.(RegionServerCoprocessorHost.java:69)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:888)
> at java.lang.Thread.run(Thread.java:745)
> 2016-04-26 09:47:23,586 FATAL [regionserver/host1/ip:16020]
> regionserver.HRegionServer: RegionServer abort: loaded coprocessors are:
> [org.apache.hadoop.hbase.security.token.TokenProvider]
> 2016-04-26 09:47:27,474 ERROR [main] regionserver.HRegionServerCommandLine:
> Region server exiting
> java.lang.RuntimeException: HRegionServer Aborted
> at
> org.apache.hadoop.hbase.regionserver.HRegionServerCommandLine.start(HRegionServerCommandLine.java:68)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServerCommandLine.run(HRegionServerCommandLine.java:87)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76)
> at
> org.apache.hadoop.hbase.util.ServerCommandLine.doMain(ServerCommandLine.java:126)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.main(HRegionServer.java:2651)
> 2016-04-26 09:47:27,491 INFO [Thread-129] provider.AuditProviderFactory: ==>
> JVMShutdownHook.run()
> 2016-04-26 09:47:27,492 INFO [Thread-129] queue.AuditAsyncQueue: Stop
> called. name=hbaseRegional.async
> 2016-04-26 09:47:27,492 INFO [Thread-129] queue.AuditAsyncQueue:
> Interrupting consumerThread. name=hbaseRegional.async,
> consumer=hbaseRegional.async.summary
> 2016-04-26 09:47:27,496 INFO [Thread-129]
[jira] [Updated] (AMBARI-16072) Stack Advisor issue when adding service to Kerberized cluster
[
https://issues.apache.org/jira/browse/AMBARI-16072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahadev konar updated AMBARI-16072:
---
Fix Version/s: (was: 2.2.2)
2.4.0
> Stack Advisor issue when adding service to Kerberized cluster
> -
>
> Key: AMBARI-16072
> URL: https://issues.apache.org/jira/browse/AMBARI-16072
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Labels: kerberos
> Fix For: 2.4.0
>
> Attachments: AMBARI-16072_branch-2.2_01.patch,
> AMBARI-16072_branch-2.2_02.patch, AMBARI-16072_trunk_01.patch,
> AMBARI-16072_trunk_02.patch
>
>
> When adding a service to a Kerberized cluster and click install nothing
> happens on the UI and i see the following error in the ambari server logs
> {code}
> 20 Apr 2016 16:03:56,818 INFO [qtp-ambari-client-2764]
> KerberosHelperImpl:735 - Adding identity for JOURNALNODE to auth to local
> mapping
> 20 Apr 2016 16:03:56,818 INFO [qtp-ambari-client-2764]
> KerberosHelperImpl:735 - Adding identity for METRICS_COLLECTOR to auth to
> local mapping
> 20 Apr 2016 16:03:56,857 INFO [qtp-ambari-client-2764] StackAdvisorRunner:47
> - Script=/var/lib/ambari-server/resources/scripts/stack_advisor.py,
> actionDirectory=/var/run/ambari-server/stack-recommendations/323,
> command=recommend-configurations
> 20 Apr 2016 16:03:56,860 INFO [qtp-ambari-client-2764] StackAdvisorRunner:61
> - Stack-advisor
> output=/var/run/ambari-server/stack-recommendations/323/stackadvisor.out,
> error=/var/run/ambari-server/stack-recommendations/323/stackadvisor.err
> 20 Apr 2016 16:03:56,917 INFO [qtp-ambari-client-2764] StackAdvisorRunner:69
> - Stack advisor output files
> 20 Apr 2016 16:03:56,917 INFO [qtp-ambari-client-2764] StackAdvisorRunner:70
> - advisor script stdout: StackAdvisor implementation for stack HDP,
> version 2.0.6 was loaded
> StackAdvisor implementation for stack HDP, version 2.1 was loaded
> StackAdvisor implementation for stack HDP, version 2.2 was loaded
> StackAdvisor implementation for stack HDP, version 2.3 was loaded
> StackAdvisor implementation for stack HDP, version 2.4 was loaded
> Returning HDP24StackAdvisor implementation
> Error occured in stack advisor.
> Error details: 'NoneType' object is not iterable
> 20 Apr 2016 16:03:56,917 INFO [qtp-ambari-client-2764] StackAdvisorRunner:71
> - advisor script stderr: Traceback (most recent call last):
> File "/var/lib/ambari-server/resources/scripts/stack_advisor.py", line 158,
> in
> main(sys.argv)
> File "/var/lib/ambari-server/resources/scripts/stack_advisor.py", line 109,
> in main
> result = stackAdvisor.recommendConfigurations(services, hosts)
> File "/var/lib/ambari-server/resources/scripts/../stacks/stack_advisor.py",
> line 570, in recommendConfigurations
> calculation(configurations, clusterSummary, services, hosts)
> File
> "/var/lib/ambari-server/resources/scripts/./../stacks/HDP/2.0.6/services/stack_advisor.py",
> line 627, in recommendAmsConfigurations
> if set(amsCollectorHosts).intersection(dn_hosts):
> TypeError: 'NoneType' object is not iterable
> 20 Apr 2016 16:03:56,918 INFO [qtp-ambari-client-2764]
> AbstractResourceProvider:802 - Caught an exception while updating host
> components, retrying : org.apache.ambari.server.AmbariException: Stack
> Advisor reported an error: TypeError: 'NoneType' object is not iterable
> StdOut file: /var/run/ambari-server/stack-recommendations/323/stackadvisor.out
> StdErr file: /var/run/ambari-server/stack-recommendations/323/stackadvisor.err
> {code}
> *Solution*
> Pass to the stack advisor information about all installed services where each
> component is installed (component host map)
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16139) Duplicate Dashboard metrics API calls should not be made in parallel
[
https://issues.apache.org/jira/browse/AMBARI-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260509#comment-15260509
]
Hadoop QA commented on AMBARI-16139:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12801052/AMBARI-16139.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/6690//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6690//console
This message is automatically generated.
> Duplicate Dashboard metrics API calls should not be made in parallel
>
>
> Key: AMBARI-16139
> URL: https://issues.apache.org/jira/browse/AMBARI-16139
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16139.patch, Screen Shot 2016-04-26 at 1.37.01
> PM.png
>
>
> Graphs on Cluster dashboard page keeps making API calls irrespective of the
> previous APIs call have completed or not. Thus on a cluster where AMS is
> behaving there are multiple same API calls in pending state and results into
> ambari-server unresponsive.
> For Graph widgets, ajax calls should be made from the complete callback
> function of the same ajax call. so until an ajax call is not finished, the
> same ajax is not triggered again
> we do this in correct way for enhanced service dashboard on service summary
> page
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16118) Additional logs required when posting ambari configuration failed with 400 response
[
https://issues.apache.org/jira/browse/AMBARI-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Magyari updated AMBARI-16118:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Additional logs required when posting ambari configuration failed with 400
> response
> ---
>
> Key: AMBARI-16118
> URL: https://issues.apache.org/jira/browse/AMBARI-16118
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Affects Versions: 2.2.1.1
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
> Fix For: 2.2-next
>
> Attachments: AMBARI-16118.patch
>
>
> Add Bad requests response like below to Ambari server logs:
> In case of JSON error:
> {code}
> {
> "status" : 400,
> "message" : "Invalid Request: Malformed Request Body. An exception
> occurred parsing the request body: Unexpected character (':' (code 58)): was
> expecting comma to separate ARRAY entries\n at [Source:
> java.io.StringReader@17747ba1; line: 4, column: 22]"
> } {code}
> In case of improper content:
> {code}
> {
> "status" : 400,
> "message" : "Blueprint configuration validation failed: Missing required
> properties. Specify a value for these properties in the blueprint
> configuration. {host_group_1={kerberos-env=[encryption_types, realm,
> ldap_url, container_dn, kdc_type, kdc_host]},
> host_group_2={kerberos-env=[encryption_types, realm, ldap_url, container_dn,
> kdc_type, kdc_host]}}"
> } {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16129) LogSearch Integration using incorrect query parameters for LogSearch
[
https://issues.apache.org/jira/browse/AMBARI-16129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260471#comment-15260471
]
Hadoop QA commented on AMBARI-16129:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12801020/AMBARI-16129.patch.2
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
ambari-server:
org.apache.ambari.server.state.cluster.ClusterTest
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6689//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6689//console
This message is automatically generated.
> LogSearch Integration using incorrect query parameters for LogSearch
>
>
> Key: AMBARI-16129
> URL: https://issues.apache.org/jira/browse/AMBARI-16129
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Nettleton
>Assignee: Robert Nettleton
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16129.patch.2
>
>
> The LogSearch integration layer in Ambari is passing incorrect query
> parameters to the LogSearch Server. Recent multi-node testing has uncovered
> this issue.
> The LogSearch integration code should use "host_name" for specifying hosts in
> query URLs, and "component_name" for specifying the component for a given
> LogSearch query. The "component_name" change is related to a change in the
> parameters for LogSearch itself, which used to use "components_name".
> The integration code should be updated to use these query parameter names.
> I'm working on a fix for this, and will be submitting a patch shortly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16139) Duplicate Dashboard metrics API calls should not be made in parallel
[ https://issues.apache.org/jira/browse/AMBARI-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260398#comment-15260398 ] Aleksandr Kovalenko commented on AMBARI-16139: -- +1 for the patch > Duplicate Dashboard metrics API calls should not be made in parallel > > > Key: AMBARI-16139 > URL: https://issues.apache.org/jira/browse/AMBARI-16139 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.1.2 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16139.patch, Screen Shot 2016-04-26 at 1.37.01 > PM.png > > > Graphs on Cluster dashboard page keeps making API calls irrespective of the > previous APIs call have completed or not. Thus on a cluster where AMS is > behaving there are multiple same API calls in pending state and results into > ambari-server unresponsive. > For Graph widgets, ajax calls should be made from the complete callback > function of the same ajax call. so until an ajax call is not finished, the > same ajax is not triggered again > we do this in correct way for enhanced service dashboard on service summary > page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16142) Add getDeleteDirectives to org.apache.ambari.server.api.resources.ResourceDefinition and use when handling DELETE requests
Ajit Kumar created AMBARI-16142: --- Summary: Add getDeleteDirectives to org.apache.ambari.server.api.resources.ResourceDefinition and use when handling DELETE requests Key: AMBARI-16142 URL: https://issues.apache.org/jira/browse/AMBARI-16142 Project: Ambari Issue Type: Task Reporter: Ajit Kumar Assignee: Ajit Kumar Add delete directive to RequestDefinition and handle it in Delete requests. It will be useful for usecases like dry run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16141) Add configuration dependencies for Logsearch components
Olivér Szabó created AMBARI-16141: - Summary: Add configuration dependencies for Logsearch components Key: AMBARI-16141 URL: https://issues.apache.org/jira/browse/AMBARI-16141 Project: Ambari Issue Type: Improvement Components: ambari-server, stacks Affects Versions: 2.4.0 Reporter: Olivér Szabó Assignee: Olivér Szabó Fix For: 2.4.0 Logserach server configuration dependencies: - logsearch-properties - logsearch-env - logsearch-admin-json - logsearch-log4j Logfeeder configuration dependencies: - logfeeder-env - logfeeder-log4j - logfeeder-properties - logfeeder-site Solr configuration dependencies: - logsearch-solr-xml - logsearch-solr-log4j - logsearch-solr-env -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16118) Additional logs required when posting ambari configuration failed with 400 response
[
https://issues.apache.org/jira/browse/AMBARI-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260359#comment-15260359
]
Hudson commented on AMBARI-16118:
-
FAILURE: Integrated in Ambari-branch-2.2 #674 (See
[https://builds.apache.org/job/Ambari-branch-2.2/674/])
AMBARI-16118. Additional logs required when posting ambari configuration
(smagyari:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=e9ef632db8f72b85cdb060b02fd1ef7022671be5])
*
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterResourceProvider.java
*
ambari-server/src/main/java/org/apache/ambari/server/api/services/BaseService.java
*
ambari-server/src/main/java/org/apache/ambari/server/api/handlers/CreateHandler.java
> Additional logs required when posting ambari configuration failed with 400
> response
> ---
>
> Key: AMBARI-16118
> URL: https://issues.apache.org/jira/browse/AMBARI-16118
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Affects Versions: 2.2.1.1
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
> Fix For: 2.2-next
>
> Attachments: AMBARI-16118.patch
>
>
> Add Bad requests response like below to Ambari server logs:
> In case of JSON error:
> {code}
> {
> "status" : 400,
> "message" : "Invalid Request: Malformed Request Body. An exception
> occurred parsing the request body: Unexpected character (':' (code 58)): was
> expecting comma to separate ARRAY entries\n at [Source:
> java.io.StringReader@17747ba1; line: 4, column: 22]"
> } {code}
> In case of improper content:
> {code}
> {
> "status" : 400,
> "message" : "Blueprint configuration validation failed: Missing required
> properties. Specify a value for these properties in the blueprint
> configuration. {host_group_1={kerberos-env=[encryption_types, realm,
> ldap_url, container_dn, kdc_type, kdc_host]},
> host_group_2={kerberos-env=[encryption_types, realm, ldap_url, container_dn,
> kdc_type, kdc_host]}}"
> } {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16139) Duplicate Dashboard metrics API calls should not be made in parallel
[ https://issues.apache.org/jira/browse/AMBARI-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260354#comment-15260354 ] Andrii Tkach commented on AMBARI-16139: --- 27704 tests complete (25 seconds) 154 tests pending > Duplicate Dashboard metrics API calls should not be made in parallel > > > Key: AMBARI-16139 > URL: https://issues.apache.org/jira/browse/AMBARI-16139 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.1.2 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16139.patch, Screen Shot 2016-04-26 at 1.37.01 > PM.png > > > Graphs on Cluster dashboard page keeps making API calls irrespective of the > previous APIs call have completed or not. Thus on a cluster where AMS is > behaving there are multiple same API calls in pending state and results into > ambari-server unresponsive. > For Graph widgets, ajax calls should be made from the complete callback > function of the same ajax call. so until an ajax call is not finished, the > same ajax is not triggered again > we do this in correct way for enhanced service dashboard on service summary > page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16139) Duplicate Dashboard metrics API calls should not be made in parallel
[ https://issues.apache.org/jira/browse/AMBARI-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Tkach updated AMBARI-16139: -- Status: Patch Available (was: Open) > Duplicate Dashboard metrics API calls should not be made in parallel > > > Key: AMBARI-16139 > URL: https://issues.apache.org/jira/browse/AMBARI-16139 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.1.2 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16139.patch, Screen Shot 2016-04-26 at 1.37.01 > PM.png > > > Graphs on Cluster dashboard page keeps making API calls irrespective of the > previous APIs call have completed or not. Thus on a cluster where AMS is > behaving there are multiple same API calls in pending state and results into > ambari-server unresponsive. > For Graph widgets, ajax calls should be made from the complete callback > function of the same ajax call. so until an ajax call is not finished, the > same ajax is not triggered again > we do this in correct way for enhanced service dashboard on service summary > page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16139) Duplicate Dashboard metrics API calls should not be made in parallel
[ https://issues.apache.org/jira/browse/AMBARI-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Tkach updated AMBARI-16139: -- Attachment: AMBARI-16139.patch > Duplicate Dashboard metrics API calls should not be made in parallel > > > Key: AMBARI-16139 > URL: https://issues.apache.org/jira/browse/AMBARI-16139 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.1.2 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16139.patch, Screen Shot 2016-04-26 at 1.37.01 > PM.png > > > Graphs on Cluster dashboard page keeps making API calls irrespective of the > previous APIs call have completed or not. Thus on a cluster where AMS is > behaving there are multiple same API calls in pending state and results into > ambari-server unresponsive. > For Graph widgets, ajax calls should be made from the complete callback > function of the same ajax call. so until an ajax call is not finished, the > same ajax is not triggered again > we do this in correct way for enhanced service dashboard on service summary > page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16120) export_ams_script should save configs into the files
[ https://issues.apache.org/jira/browse/AMBARI-16120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260351#comment-15260351 ] Hudson commented on AMBARI-16120: - SUCCESS: Integrated in Ambari-trunk-Commit #4747 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4747/]) AMBARI-16120. export_ams_script should save configs into the files (aonishuk: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=e8a79db74252a01cd530ce7dc796863eaa733945]) * ambari-server/src/main/resources/scripts/export_ams_metrics.py > export_ams_script should save configs into the files > > > Key: AMBARI-16120 > URL: https://issues.apache.org/jira/browse/AMBARI-16120 > Project: Ambari > Issue Type: Bug >Reporter: Andrew Onischuk >Assignee: Andrew Onischuk > Fix For: 2.4.0 > > Attachments: AMBARI-16120.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16118) Additional logs required when posting ambari configuration failed with 400 response
[
https://issues.apache.org/jira/browse/AMBARI-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260350#comment-15260350
]
Hudson commented on AMBARI-16118:
-
SUCCESS: Integrated in Ambari-trunk-Commit #4747 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/4747/])
AMBARI-16118. Additional logs required when posting ambari configuration
(smagyari:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=d0d86edd57cf5a0f50058bf7fa621f8874136bd3])
*
ambari-server/src/main/java/org/apache/ambari/server/api/handlers/CreateHandler.java
*
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterResourceProvider.java
*
ambari-server/src/main/java/org/apache/ambari/server/api/services/BaseService.java
> Additional logs required when posting ambari configuration failed with 400
> response
> ---
>
> Key: AMBARI-16118
> URL: https://issues.apache.org/jira/browse/AMBARI-16118
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Affects Versions: 2.2.1.1
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
> Fix For: 2.2-next
>
> Attachments: AMBARI-16118.patch
>
>
> Add Bad requests response like below to Ambari server logs:
> In case of JSON error:
> {code}
> {
> "status" : 400,
> "message" : "Invalid Request: Malformed Request Body. An exception
> occurred parsing the request body: Unexpected character (':' (code 58)): was
> expecting comma to separate ARRAY entries\n at [Source:
> java.io.StringReader@17747ba1; line: 4, column: 22]"
> } {code}
> In case of improper content:
> {code}
> {
> "status" : 400,
> "message" : "Blueprint configuration validation failed: Missing required
> properties. Specify a value for these properties in the blueprint
> configuration. {host_group_1={kerberos-env=[encryption_types, realm,
> ldap_url, container_dn, kdc_type, kdc_host]},
> host_group_2={kerberos-env=[encryption_types, realm, ldap_url, container_dn,
> kdc_type, kdc_host]}}"
> } {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16129) LogSearch Integration using incorrect query parameters for LogSearch
[ https://issues.apache.org/jira/browse/AMBARI-16129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Nettleton updated AMBARI-16129: -- Resolution: Fixed Status: Resolved (was: Patch Available) Patch merged to trunk > LogSearch Integration using incorrect query parameters for LogSearch > > > Key: AMBARI-16129 > URL: https://issues.apache.org/jira/browse/AMBARI-16129 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Robert Nettleton >Assignee: Robert Nettleton >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16129.patch.2 > > > The LogSearch integration layer in Ambari is passing incorrect query > parameters to the LogSearch Server. Recent multi-node testing has uncovered > this issue. > The LogSearch integration code should use "host_name" for specifying hosts in > query URLs, and "component_name" for specifying the component for a given > LogSearch query. The "component_name" change is related to a change in the > parameters for LogSearch itself, which used to use "components_name". > The integration code should be updated to use these query parameter names. > I'm working on a fix for this, and will be submitting a patch shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16140) ambari-agent RPM yum update should backup both stack and common-services
[ https://issues.apache.org/jira/browse/AMBARI-16140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Di Li updated AMBARI-16140: --- Attachment: AMBARI-16140.patch > ambari-agent RPM yum update should backup both stack and common-services > > > Key: AMBARI-16140 > URL: https://issues.apache.org/jira/browse/AMBARI-16140 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: trunk >Reporter: Di Li >Assignee: Di Li > Fix For: trunk > > Attachments: AMBARI-16140.patch > > > When a user runs yum upgrade ambari-agent. The preinstall script backs up the > stack dir in /var/lib/ambari-agent/cache by renaming it with a stampstamp. > The same logic should happen for /var/lib/ambari-agent/cache/common-services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16140) ambari-agent RPM yum update should backup both stack and common-services
[ https://issues.apache.org/jira/browse/AMBARI-16140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Di Li updated AMBARI-16140: --- Status: Patch Available (was: Open) > ambari-agent RPM yum update should backup both stack and common-services > > > Key: AMBARI-16140 > URL: https://issues.apache.org/jira/browse/AMBARI-16140 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: trunk >Reporter: Di Li >Assignee: Di Li > Fix For: trunk > > Attachments: AMBARI-16140.patch > > > When a user runs yum upgrade ambari-agent. The preinstall script backs up the > stack dir in /var/lib/ambari-agent/cache by renaming it with a stampstamp. > The same logic should happen for /var/lib/ambari-agent/cache/common-services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16140) ambari-agent RPM yum update should backup both stack and common-services
Di Li created AMBARI-16140: -- Summary: ambari-agent RPM yum update should backup both stack and common-services Key: AMBARI-16140 URL: https://issues.apache.org/jira/browse/AMBARI-16140 Project: Ambari Issue Type: Bug Components: ambari-agent Affects Versions: trunk Reporter: Di Li Assignee: Di Li Fix For: trunk When a user runs yum upgrade ambari-agent. The preinstall script backs up the stack dir in /var/lib/ambari-agent/cache by renaming it with a stampstamp. The same logic should happen for /var/lib/ambari-agent/cache/common-services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16139) Duplicate Dashboard metrics API calls should not be made in parallel
[ https://issues.apache.org/jira/browse/AMBARI-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Tkach updated AMBARI-16139: -- Attachment: Screen Shot 2016-04-26 at 1.37.01 PM.png > Duplicate Dashboard metrics API calls should not be made in parallel > > > Key: AMBARI-16139 > URL: https://issues.apache.org/jira/browse/AMBARI-16139 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.1.2 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.4.0 > > Attachments: Screen Shot 2016-04-26 at 1.37.01 PM.png > > > Graphs on Cluster dashboard page keeps making API calls irrespective of the > previous APIs call have completed or not. Thus on a cluster where AMS is > behaving there are multiple same API calls in pending state and results into > ambari-server unresponsive. > For Graph widgets, ajax calls should be made from the complete callback > function of the same ajax call. so until an ajax call is not finished, the > same ajax is not triggered again > we do this in correct way for enhanced service dashboard on service summary > page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16138) Converting cluster to Kerberos the views should automatically adjust and work prior to the kerberization.
[
https://issues.apache.org/jira/browse/AMBARI-16138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260287#comment-15260287
]
Hadoop QA commented on AMBARI-16138:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12801025/AMBARI-16138.2_trunk.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
contrib/views/hive contrib/views/pig contrib/views/tez contrib/views/utils.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6688//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6688//console
This message is automatically generated.
> Converting cluster to Kerberos the views should automatically adjust and work
> prior to the kerberization.
> -
>
> Key: AMBARI-16138
> URL: https://issues.apache.org/jira/browse/AMBARI-16138
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.2.0
>Reporter: Gaurav Nagar
>Assignee: Gaurav Nagar
> Fix For: 2.4.0
>
> Attachments: AMBARI-16138.2_trunk.patch, AMBARI-16138_trunk.patch
>
>
> PROBLEM:
> Converting cluster to Kerberos the views should automatically adjust and work
> prior to the kerberization.
> STEPS TO REPRODUCE:
> -create a cluster
> -enable ha
> -verify views are working as expected using the local ambari manage setting.
> -kerberize cluster
> -verify the views are working as expected. You should get some errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16138) Converting cluster to Kerberos the views should automatically adjust and work prior to the kerberization.
[
https://issues.apache.org/jira/browse/AMBARI-16138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260246#comment-15260246
]
Hadoop QA commented on AMBARI-16138:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12801016/AMBARI-16138_trunk.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
contrib/views/hive contrib/views/tez contrib/views/utils:
org.apache.ambari.view.hive.resources.jobs.JobLDAPServiceTest
org.apache.ambari.view.hive.resources.jobs.JobServiceTest
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6687//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6687//console
This message is automatically generated.
> Converting cluster to Kerberos the views should automatically adjust and work
> prior to the kerberization.
> -
>
> Key: AMBARI-16138
> URL: https://issues.apache.org/jira/browse/AMBARI-16138
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.2.0
>Reporter: Gaurav Nagar
>Assignee: Gaurav Nagar
> Fix For: 2.4.0
>
> Attachments: AMBARI-16138.2_trunk.patch, AMBARI-16138_trunk.patch
>
>
> PROBLEM:
> Converting cluster to Kerberos the views should automatically adjust and work
> prior to the kerberization.
> STEPS TO REPRODUCE:
> -create a cluster
> -enable ha
> -verify views are working as expected using the local ambari manage setting.
> -kerberize cluster
> -verify the views are working as expected. You should get some errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16125) 500-error on PUT to the repository_versions endpoint
[ https://issues.apache.org/jira/browse/AMBARI-16125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate Cole updated AMBARI-16125: --- Resolution: Fixed Status: Resolved (was: Patch Available) > 500-error on PUT to the repository_versions endpoint > > > Key: AMBARI-16125 > URL: https://issues.apache.org/jira/browse/AMBARI-16125 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Nate Cole >Assignee: Nate Cole > Fix For: 2.4.0 > > Attachments: AMBARI-16125.patch > > > RepositoryVersionResourceProvider would check the version being > created/updated was able to be a target for upgrade. This logic is now > incorrect as we can create versions with no cluster installed at all. There > are other places that check compatibility and is unnecessary in the provider. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16090) Atlas Integration : add defult login method configuration
[
https://issues.apache.org/jira/browse/AMBARI-16090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Beerbower updated AMBARI-16090:
---
Status: Patch Available (was: Open)
> Atlas Integration : add defult login method configuration
> -
>
> Key: AMBARI-16090
> URL: https://issues.apache.org/jira/browse/AMBARI-16090
> Project: Ambari
> Issue Type: Bug
>Reporter: Tom Beerbower
>Assignee: Tom Beerbower
>
> To enable login to Atlas UI, following properties have to be manually added
> to ‘Custom application-properties’ in Atlas.
> {code}
> atlas.login.method=file
> atlas.login.credentials.file=/etc/atlas/conf/users-credentials.properties
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16089) Atlas Integration : set atlas.cluster.name in hive-site
[ https://issues.apache.org/jira/browse/AMBARI-16089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Beerbower updated AMBARI-16089: --- Status: Patch Available (was: Open) > Atlas Integration : set atlas.cluster.name in hive-site > --- > > Key: AMBARI-16089 > URL: https://issues.apache.org/jira/browse/AMBARI-16089 > Project: Ambari > Issue Type: Bug >Reporter: Tom Beerbower >Assignee: Tom Beerbower > > After deploying Hive+Atlas via Ambari, the value of 'atlas.cluster.name‘ in > 'Advanced hive-site’ is ‘default’. This results in incorrect value in entity > notifications to Ranger. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16138) Converting cluster to Kerberos the views should automatically adjust and work prior to the kerberization.
[ https://issues.apache.org/jira/browse/AMBARI-16138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Nagar updated AMBARI-16138: -- Attachment: AMBARI-16138.2_trunk.patch > Converting cluster to Kerberos the views should automatically adjust and work > prior to the kerberization. > - > > Key: AMBARI-16138 > URL: https://issues.apache.org/jira/browse/AMBARI-16138 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.0 >Reporter: Gaurav Nagar >Assignee: Gaurav Nagar > Fix For: 2.4.0 > > Attachments: AMBARI-16138.2_trunk.patch, AMBARI-16138_trunk.patch > > > PROBLEM: > Converting cluster to Kerberos the views should automatically adjust and work > prior to the kerberization. > STEPS TO REPRODUCE: > -create a cluster > -enable ha > -verify views are working as expected using the local ambari manage setting. > -kerberize cluster > -verify the views are working as expected. You should get some errors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16085) Modify Ambari stacks for Ranger (for enabling plugins) to use service keytab for creating repositories and policies
[
https://issues.apache.org/jira/browse/AMBARI-16085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260224#comment-15260224
]
Hadoop QA commented on AMBARI-16085:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12800991/AMBARI-16085.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 test build failed in ambari-server
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6686//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6686//console
This message is automatically generated.
> Modify Ambari stacks for Ranger (for enabling plugins) to use service keytab
> for creating repositories and policies
> ---
>
> Key: AMBARI-16085
> URL: https://issues.apache.org/jira/browse/AMBARI-16085
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0
>
> Attachments: AMBARI-16085.2.patch, AMBARI-16085.patch
>
>
> In order to allow Ranger plugins to support Kerberos Authentication. Make
> changes in Ranger plugin stacks to create ranger services and policies using
> component principal / keytab. Also take care of config changes to support
> plugin communication in Kerberos enabled env.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16132) Date Filter editable in History Tab
[
https://issues.apache.org/jira/browse/AMBARI-16132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260195#comment-15260195
]
Hadoop QA commented on AMBARI-16132:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12800960/AMBARI-16132_trunk.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
contrib/views/hive.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6685//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6685//console
This message is automatically generated.
> Date Filter editable in History Tab
> ---
>
> Key: AMBARI-16132
> URL: https://issues.apache.org/jira/browse/AMBARI-16132
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.2.0
>Reporter: Pallav Kulshreshtha
>Assignee: Pallav Kulshreshtha
> Fix For: 2.4.0
>
> Attachments: AMBARI-16132_trunk.patch, Screen Shot 2016-04-14 at
> 10.29.59 PM.png, Screen Shot 2016-04-14 at 10.37.12 PM.png
>
>
> The date filter is allowing the user to clear date and enter any random
> value. On clicking enter no error message is thrown and the list of entries
> remains unchanged. Also, if you leave the values blank, all the history
> queries still get listed.
> Ideally the date filter should not permit any values other than those entered
> through the date picker.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16129) LogSearch Integration using incorrect query parameters for LogSearch
[ https://issues.apache.org/jira/browse/AMBARI-16129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Nettleton updated AMBARI-16129: -- Attachment: AMBARI-16129.patch.2 Uploaded Version 2 of patch, rebased on latest trunk changes > LogSearch Integration using incorrect query parameters for LogSearch > > > Key: AMBARI-16129 > URL: https://issues.apache.org/jira/browse/AMBARI-16129 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Robert Nettleton >Assignee: Robert Nettleton >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16129.patch.2 > > > The LogSearch integration layer in Ambari is passing incorrect query > parameters to the LogSearch Server. Recent multi-node testing has uncovered > this issue. > The LogSearch integration code should use "host_name" for specifying hosts in > query URLs, and "component_name" for specifying the component for a given > LogSearch query. The "component_name" change is related to a change in the > parameters for LogSearch itself, which used to use "components_name". > The integration code should be updated to use these query parameter names. > I'm working on a fix for this, and will be submitting a patch shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-16122) Logsearch: Property changes not getting reflected at the backend
[ https://issues.apache.org/jira/browse/AMBARI-16122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivér Szabó resolved AMBARI-16122. --- Resolution: Fixed > Logsearch: Property changes not getting reflected at the backend > > > Key: AMBARI-16122 > URL: https://issues.apache.org/jira/browse/AMBARI-16122 > Project: Ambari > Issue Type: Bug > Components: ambari-server, stacks >Affects Versions: 2.4.0 >Reporter: Olivér Szabó >Assignee: Olivér Szabó > Fix For: 2.4.0 > > > Cannot add custom properties. > Also some configurations are misleading -> rename them -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16115) After upgrade ambari-env.sh was changed (WARNING: Can not find ambari-env.sh.rpmsave file from previous version)
[ https://issues.apache.org/jira/browse/AMBARI-16115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260185#comment-15260185 ] Hudson commented on AMBARI-16115: - SUCCESS: Integrated in Ambari-trunk-Commit #4746 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4746/]) AMBARI-16115. After upgrade ambari-env.sh was changed (WARNING: Can not (aonishuk: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=a5807823299cc575e8269167a6c0f45b003bb60c]) * ambari-server/src/main/python/ambari_server/serverConfiguration.py > After upgrade ambari-env.sh was changed (WARNING: Can not find > ambari-env.sh.rpmsave file from previous version) > > > Key: AMBARI-16115 > URL: https://issues.apache.org/jira/browse/AMBARI-16115 > Project: Ambari > Issue Type: Bug >Reporter: Andrew Onischuk >Assignee: Andrew Onischuk > Fix For: 2.4.0 > > Attachments: AMBARI-16115.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16122) Logsearch: Property changes not getting reflected at the backend
[ https://issues.apache.org/jira/browse/AMBARI-16122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260186#comment-15260186 ] Hudson commented on AMBARI-16122: - SUCCESS: Integrated in Ambari-trunk-Commit #4746 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4746/]) AMBARI-16122. Logsearch: Property changes not getting reflected at the (oleewere: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=03ce1907b795ee6bbd15b685eda4271e61feada9]) * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-site.xml * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logfeeder-properties.xml * ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logsearch.py * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-admin-properties.xml * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/logsearch.py * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/quicklinks/quicklinks.json * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logfeeder-site.xml * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-env.xml * ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperImpl.java * ambari-web/app/data/HDP2/site_properties.js * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/templates/logsearch.properties.j2 * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/properties/logsearch-env.sh.j2 * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/alerts.json * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/metainfo.xml * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/templates/logfeeder.properties.j2 * ambari-server/src/test/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperImplTest.java * ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperFactoryImpl.java * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logsearch.py * ambari-logsearch/ambari-logsearch-portal/src/main/scripts/run.sh * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-admin-json.xml * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logfeeder-env.xml * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-properties.xml * ambari-web/app/models/quick_links.js * ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/params.py * ambari-server/src/test/python/stacks/2.4/configs/default.json * ambari-server/src/test/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperFactoryImplTest.java > Logsearch: Property changes not getting reflected at the backend > > > Key: AMBARI-16122 > URL: https://issues.apache.org/jira/browse/AMBARI-16122 > Project: Ambari > Issue Type: Bug > Components: ambari-server, stacks >Affects Versions: 2.4.0 >Reporter: Olivér Szabó >Assignee: Olivér Szabó > Fix For: 2.4.0 > > > Cannot add custom properties. > Also some configurations are misleading -> rename them -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16129) LogSearch Integration using incorrect query parameters for LogSearch
[ https://issues.apache.org/jira/browse/AMBARI-16129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Nettleton updated AMBARI-16129: -- Attachment: (was: AMBARI-16129.patch) > LogSearch Integration using incorrect query parameters for LogSearch > > > Key: AMBARI-16129 > URL: https://issues.apache.org/jira/browse/AMBARI-16129 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Robert Nettleton >Assignee: Robert Nettleton >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16129.patch.2 > > > The LogSearch integration layer in Ambari is passing incorrect query > parameters to the LogSearch Server. Recent multi-node testing has uncovered > this issue. > The LogSearch integration code should use "host_name" for specifying hosts in > query URLs, and "component_name" for specifying the component for a given > LogSearch query. The "component_name" change is related to a change in the > parameters for LogSearch itself, which used to use "components_name". > The integration code should be updated to use these query parameter names. > I'm working on a fix for this, and will be submitting a patch shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16129) LogSearch Integration using incorrect query parameters for LogSearch
[ https://issues.apache.org/jira/browse/AMBARI-16129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Nettleton updated AMBARI-16129: -- Status: Patch Available (was: In Progress) > LogSearch Integration using incorrect query parameters for LogSearch > > > Key: AMBARI-16129 > URL: https://issues.apache.org/jira/browse/AMBARI-16129 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Robert Nettleton >Assignee: Robert Nettleton >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16129.patch.2 > > > The LogSearch integration layer in Ambari is passing incorrect query > parameters to the LogSearch Server. Recent multi-node testing has uncovered > this issue. > The LogSearch integration code should use "host_name" for specifying hosts in > query URLs, and "component_name" for specifying the component for a given > LogSearch query. The "component_name" change is related to a change in the > parameters for LogSearch itself, which used to use "components_name". > The integration code should be updated to use these query parameter names. > I'm working on a fix for this, and will be submitting a patch shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16129) LogSearch Integration using incorrect query parameters for LogSearch
[ https://issues.apache.org/jira/browse/AMBARI-16129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Nettleton updated AMBARI-16129: -- Status: Open (was: Patch Available) > LogSearch Integration using incorrect query parameters for LogSearch > > > Key: AMBARI-16129 > URL: https://issues.apache.org/jira/browse/AMBARI-16129 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Robert Nettleton >Assignee: Robert Nettleton >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16129.patch.2 > > > The LogSearch integration layer in Ambari is passing incorrect query > parameters to the LogSearch Server. Recent multi-node testing has uncovered > this issue. > The LogSearch integration code should use "host_name" for specifying hosts in > query URLs, and "component_name" for specifying the component for a given > LogSearch query. The "component_name" change is related to a change in the > parameters for LogSearch itself, which used to use "components_name". > The integration code should be updated to use these query parameter names. > I'm working on a fix for this, and will be submitting a patch shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16133) Zeppelin to select only tested Interpreter
[
https://issues.apache.org/jira/browse/AMBARI-16133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260160#comment-15260160
]
Hadoop QA commented on AMBARI-16133:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12800965/AMBARI-16133.trunk.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/6684//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6684//console
This message is automatically generated.
> Zeppelin to select only tested Interpreter
> --
>
> Key: AMBARI-16133
> URL: https://issues.apache.org/jira/browse/AMBARI-16133
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Prabhjyot Singh
> Fix For: ambari-2.4.0
>
> Attachments: AMBARI-16133.trunk.patch
>
>
> Allowing only those interpreters that are tested with ambari. i.e.;
> Spark
> Hive
> Shell
> MarkDown
> R
> Livy
> Phoenix
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15790) Clean up stack scripts that refer to dfs.nameservices to use dfs.internal.nameservices as first option
[ https://issues.apache.org/jira/browse/AMBARI-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmytro Sen updated AMBARI-15790: Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk > Clean up stack scripts that refer to dfs.nameservices to use > dfs.internal.nameservices as first option > -- > > Key: AMBARI-15790 > URL: https://issues.apache.org/jira/browse/AMBARI-15790 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.2.2 >Reporter: Sumit Mohanty >Assignee: Dmytro Sen > Fix For: 2.4.0 > > Attachments: AMBARI-15790-trunk_5.patch, AMBARI-15790-trunk_6.patch, > AMBARI-15790_trunk_7.patch > > > Several stack scripts refer to dfs.nameservices and they should be modified > to use dfs.internal.nameservices -- This message was sent by Atlassian JIRA (v6.3.4#6332)
