[jira] [Commented] (AMBARI-20688) Supvervisord control option for Kafka broker

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AMBARI-20688:
-

GitHub user ambud opened a pull request:

https://github.com/apache/ambari/pull/53

AMBARI-20688 Supvervisord control option for Kafka broker

Just like Storm Supervisor option in Storm Ambari stack to have Supervisord 
manage the process, adding supervisord for Kafka is helpful for automated 
broker recovery in case of machine reboots.

https://issues.apache.org/jira/browse/AMBARI-20688

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ambud/ambari trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ambari/pull/53.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #53


commit 6186aa0708137b4008e6ec27006af5c43e3ef6b6
Author: Ambud 
Date:   2017-04-06T04:44:13Z

Create supervisord.conf

commit 37eadb37897dd819ae92d16bc56a667e43269ab3
Author: Ambud 
Date:   2017-04-06T04:44:41Z

Create supervisord_service.py

commit 481b2cb88006ce8230774d4da1676d0606c99c19
Author: Ambud 
Date:   2017-04-06T04:45:03Z

Create supervisor_prod.py




> Supvervisord control option for Kafka broker
> 
>
> Key: AMBARI-20688
> URL: https://issues.apache.org/jira/browse/AMBARI-20688
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: 2.4.1
>Reporter: Ambud Sharma
>
> Just like Storm Supervisor option in Storm Ambari stack to have Supervisord 
> manage the process, adding supervisord for Kafka is helpful for automated 
> broker recovery in case of machine reboots.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20688) Supvervisord control option for Kafka broker

[Ambud Sharma (JIRA)]

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

Ambud Sharma updated AMBARI-20688:
--
Summary: Supvervisord control option for Kafka broker  (was: Supvervisord 
control option for Kafka)

> Supvervisord control option for Kafka broker
> 
>
> Key: AMBARI-20688
> URL: https://issues.apache.org/jira/browse/AMBARI-20688
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: 2.4.1
>Reporter: Ambud Sharma
>
> Just like Storm Supervisor option in Storm Ambari stack to have Supervisord 
> manage the process, adding supervisord for Kafka is helpful for automated 
> broker recovery in case of machine reboots.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20688) Supvervisord control option for Kafka

[Ambud Sharma (JIRA)]

Ambud Sharma created AMBARI-20688:
-

 Summary: Supvervisord control option for Kafka
 Key: AMBARI-20688
 URL: https://issues.apache.org/jira/browse/AMBARI-20688
 Project: Ambari
  Issue Type: Improvement
  Components: ambari-server
Affects Versions: 2.4.1
Reporter: Ambud Sharma


Just like Storm Supervisor option in Storm Ambari stack to have Supervisord 
manage the process, adding supervisord for Kafka is helpful for automated 
broker recovery in case of machine reboots.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20675) Repetitive operation in hdfs.py

[zhangxiaolu (JIRA)]

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

zhangxiaolu updated AMBARI-20675:
-
Resolution: Not A Bug
Status: Resolved  (was: Patch Available)

> Repetitive operation in hdfs.py
> ---
>
> Key: AMBARI-20675
> URL: https://issues.apache.org/jira/browse/AMBARI-20675
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: trunk
>Reporter: zhangxiaolu
>Assignee: zhangxiaolu
> Fix For: trunk
>
> Attachments: AMBARI-20675.patch, screenshot-1.png
>
>
> the method of install_snappy in hdfs.py is as follows:
> def install_snappy():
>   import params
>   Directory([params.so_target_dir_x86, params.so_target_dir_x64],
> create_parents = True,
>   )
>   Link(params.so_target_x86,
>to=params.so_src_x86,
>   )
>   Link(params.so_target_x64,
>to=params.so_src_x64,
>   )
>  is repetitived.
> so it's better remove one



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20687) Perf: Refactor ambari db-cleanup to include all big tables

[Vitaly Brodetskyi (JIRA)]

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

Vitaly Brodetskyi updated AMBARI-20687:
---
Attachment: (was: AMBARI-20687.patch)

> Perf: Refactor ambari db-cleanup to include all big tables
> --
>
> Key: AMBARI-20687
> URL: https://issues.apache.org/jira/browse/AMBARI-20687
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-20687.patch
>
>
> Add check for large tables into db consistency check.
> Add code to cleanup these tables into db-cleanup code.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20687) Perf: Refactor ambari db-cleanup to include all big tables

[Vitaly Brodetskyi (JIRA)]

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

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

> Perf: Refactor ambari db-cleanup to include all big tables
> --
>
> Key: AMBARI-20687
> URL: https://issues.apache.org/jira/browse/AMBARI-20687
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-20687.patch
>
>
> Add check for large tables into db consistency check.
> Add code to cleanup these tables into db-cleanup code.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20687) Perf: Refactor ambari db-cleanup to include all big tables

[Vitaly Brodetskyi (JIRA)]

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

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

> Perf: Refactor ambari db-cleanup to include all big tables
> --
>
> Key: AMBARI-20687
> URL: https://issues.apache.org/jira/browse/AMBARI-20687
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-20687.patch
>
>
> Add check for large tables into db consistency check.
> Add code to cleanup these tables into db-cleanup code.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20687) Perf: Refactor ambari db-cleanup to include all big tables

[Vitaly Brodetskyi (JIRA)]

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

Vitaly Brodetskyi updated AMBARI-20687:
---
Status: Patch Available  (was: Open)

> Perf: Refactor ambari db-cleanup to include all big tables
> --
>
> Key: AMBARI-20687
> URL: https://issues.apache.org/jira/browse/AMBARI-20687
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-20687.patch
>
>
> Add check for large tables into db consistency check.
> Add code to cleanup these tables into db-cleanup code.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20687) Perf: Refactor ambari db-cleanup to include all big tables

[Vitaly Brodetskyi (JIRA)]

Vitaly Brodetskyi created AMBARI-20687:
--

 Summary: Perf: Refactor ambari db-cleanup to include all big tables
 Key: AMBARI-20687
 URL: https://issues.apache.org/jira/browse/AMBARI-20687
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.5.0
Reporter: Vitaly Brodetskyi
Assignee: Vitaly Brodetskyi
Priority: Critical
 Fix For: 3.0.0


Add check for large tables into db consistency check.
Add code to cleanup these tables into db-cleanup code.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20490) Fixes for Express Upgrade on large-scale clusters: batch execute-stage for hdp-select set all, EU from HDP 2.2 to 2.5

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-20490:
-
Resolution: Won't Do
Status: Resolved  (was: Patch Available)

Decided not to merge these into trunk since a lot of this code will be 
refactored as part of Patch Upgrades.


> Fixes for Express Upgrade on large-scale clusters: batch execute-stage for 
> hdp-select set all, EU from HDP 2.2 to 2.5
> -
>
> Key: AMBARI-20490
> URL: https://issues.apache.org/jira/browse/AMBARI-20490
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: trunk
>
> Attachments: AMBARI-20490.branch-2.4.patch, 
> AMBARI-20490.branch-2.5.patch, AMBARI-20490.trunk.patch
>
>
> On large-scale clusters over 1000 nodes, performance during Express Upgrade 
> can be very slow and it takes more time to fix potential errors.
> We can remedy these with the following fixes:
> * "hdp-select set all" is currently ran in the ClusterGroup with a single 
> stage instead of batching. This can cause Ambari Server to be the bottleneck 
> when processing 1000+ requests. Allow the execute-stage inside a ClusterGroup 
> to use batching.
> * There is currently no upgrade path from HDP 2.2 directly to 2.5. Doing a 
> 2-step upgrade is very time consuming (only for branch 2.4 since HDP 2.2 no 
> longer supported in Ambari 2.5).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20670) Node manager start extremely slow when YARN NM local dirs are very large

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20670:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12862101/AMBARI-20670-2.5.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/11314//console

This message is automatically generated.

> Node manager start extremely slow when YARN NM local dirs are very large
> 
>
> Key: AMBARI-20670
> URL: https://issues.apache.org/jira/browse/AMBARI-20670
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.1
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk, 2.5.1
>
> Attachments: AMBARI-20670-2.5.patch, AMBARI-20670.patch
>
>
> On the cluster with the YARN NM, where local dirs are 100 GB+ with lot of 
> small files - NM starts slow with timeouts
> Reason could be in this specific call in  yarn.py
> {code}
> def create_local_dir(dir_name):
>   import params
>   Directory(dir_name,
> create_parents = True,
> cd_access="a",
> mode=0755,
> owner=params.yarn_user,
> group=params.user_group,
> ignore_failures=True,
> recursive_mode_flags = {'f': 'a+rw', 'd': 'a+rwx'},
>   )
> {code}
> was taking ~15 minutes per mount.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20548) Grafana dashboard changes for some new llap daemon metrics

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20548:
-

SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #7243 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/7243/])
AMBARI-20548. Grafana dashboard changes for some new llap daemon metrics 
(vivekratnavel90: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=e61d111245fd7631a4fd0a2d572d88b3f86a4b5f])
* (edit) 
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/files/grafana-dashboards/HDP/grafana-llapdaemon-daemons.json


> Grafana dashboard changes for some new llap daemon metrics
> --
>
> Key: AMBARI-20548
> URL: https://issues.apache.org/jira/browse/AMBARI-20548
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.1
>Reporter: Vivek Ratnavel Subramanian
>Assignee: Vivek Ratnavel Subramanian
>Priority: Blocker
> Fix For: 2.5.1
>
> Attachments: AMBARI-20548.v0.patch, AMBARI-20548.v1.patch
>
>
> Few new metrics (Offheap memory metrics) got added to llap recently which 
> will be critical for debugging. Also some old metrics in dashboard are not 
> really useful which can be removed (Llap IO Metrics).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20551) Blueprint export fails if config-type is not mapped to any service after upgrade

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20551:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12862134/AMBARI-20551.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 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

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

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

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

This message is automatically generated.

> Blueprint export fails if config-type is not mapped to any service after 
> upgrade
> 
>
> Key: AMBARI-20551
> URL: https://issues.apache.org/jira/browse/AMBARI-20551
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, blueprints
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-20551.patch
>
>
> 20 Mar 2017 11:39:57,948 ERROR [ambari-client-thread-8726] ReadHandler:99 - 
> Bad request:
> java.lang.IllegalArgumentException: Specified configuration type is not 
> associated with any service: storm-site
> at 
> org.apache.ambari.server.controller.internal.Stack.getServiceForConfigType(Stack.java:494)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor$StackPropertyTypeFilter.isPropertyIncluded(BlueprintConfigurationProcessor.java:2946)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.shouldPropertyBeExcludedForBlueprintExport(BlueprintConfigurationProcessor.java:939)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doFilterPriorToExport(BlueprintConfigurationProcessor.java:439)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForBlueprintExport(BlueprintConfigurationProcessor.java:416)
> at 
> org.apache.ambari.server.api.query.render.ClusterBlueprintRenderer.createBlueprintResource(ClusterBlueprintRenderer.java:186)
> at 
> org.apache.ambari.server.api.query.render.ClusterBlueprintRenderer.finalizeResult(ClusterBlueprintRenderer.java:141)
> at 
> org.apache.ambari.server.api.query.QueryImpl.getResult(QueryImpl.java:839)
> at 
> org.apache.ambari.server.api.query.QueryImpl.execute(QueryImpl.java:223)
> at 
> org.apache.ambari.server.api.handlers.ReadHandler.handleRequest(ReadHandler.java:77)
> at 
> org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:145)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:126)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:90)
> at 
> org.apache.ambari.server.api.services.ClusterService.getCluster(ClusterService.java:91)
> at sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20548) Grafana dashboard changes for some new llap daemon metrics

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20548:
-

SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #1363 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1363/])
AMBARI-20548. Grafana dashboard changes for some new llap daemon metrics 
(vivekratnavel90: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=5d9d73248fb6cf1906372fa0a2c74530c29b67d9])
* (edit) 
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/files/grafana-dashboards/HDP/grafana-llapdaemon-daemons.json


> Grafana dashboard changes for some new llap daemon metrics
> --
>
> Key: AMBARI-20548
> URL: https://issues.apache.org/jira/browse/AMBARI-20548
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.1
>Reporter: Vivek Ratnavel Subramanian
>Assignee: Vivek Ratnavel Subramanian
>Priority: Blocker
> Fix For: 2.5.1
>
> Attachments: AMBARI-20548.v0.patch, AMBARI-20548.v1.patch
>
>
> Few new metrics (Offheap memory metrics) got added to llap recently which 
> will be critical for debugging. Also some old metrics in dashboard are not 
> really useful which can be removed (Llap IO Metrics).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20548) Grafana dashboard changes for some new llap daemon metrics

[Vivek Ratnavel Subramanian (JIRA)]

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

Vivek Ratnavel Subramanian commented on AMBARI-20548:
-

Committed to trunk and branch-2.5 - 5d9d73248fb6cf1906372fa0a2c74530c29b67d9

> Grafana dashboard changes for some new llap daemon metrics
> --
>
> Key: AMBARI-20548
> URL: https://issues.apache.org/jira/browse/AMBARI-20548
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.1
>Reporter: Vivek Ratnavel Subramanian
>Assignee: Vivek Ratnavel Subramanian
>Priority: Blocker
> Fix For: 2.5.1
>
> Attachments: AMBARI-20548.v0.patch, AMBARI-20548.v1.patch
>
>
> Few new metrics (Offheap memory metrics) got added to llap recently which 
> will be critical for debugging. Also some old metrics in dashboard are not 
> really useful which can be removed (Llap IO Metrics).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20548) Grafana dashboard changes for some new llap daemon metrics

[Vivek Ratnavel Subramanian (JIRA)]

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

Vivek Ratnavel Subramanian updated AMBARI-20548:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Grafana dashboard changes for some new llap daemon metrics
> --
>
> Key: AMBARI-20548
> URL: https://issues.apache.org/jira/browse/AMBARI-20548
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.1
>Reporter: Vivek Ratnavel Subramanian
>Assignee: Vivek Ratnavel Subramanian
>Priority: Blocker
> Fix For: 2.5.1
>
> Attachments: AMBARI-20548.v0.patch, AMBARI-20548.v1.patch
>
>
> Few new metrics (Offheap memory metrics) got added to llap recently which 
> will be critical for debugging. Also some old metrics in dashboard are not 
> really useful which can be removed (Llap IO Metrics).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20429) Warn users about pending requests while trying to enable Interactive Query immediately after disabling it

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20429:
-

SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #1362 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1362/])
AMBARI-20429. Warn users about pending requests while trying to enable 
(vivekratnavel90: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=09105035abd51ef0d820bcafa7ec38cebb079e2f])
* (edit) ambari-web/app/controllers/wizard/step7/assign_master_controller.js
* (edit) ambari-web/app/views/common/configs/widgets/config_widget_view.js
* (edit) ambari-web/app/utils/ajax/ajax.js
* (edit) ambari-web/app/messages.js


> Warn users about pending requests while trying to enable Interactive Query 
> immediately after disabling it
> -
>
> Key: AMBARI-20429
> URL: https://issues.apache.org/jira/browse/AMBARI-20429
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Vivek Ratnavel Subramanian
>Assignee: Vivek Ratnavel Subramanian
> Fix For: 2.5.1
>
> Attachments: AMBARI-20429.v0.branch-2.5.patch
>
>
>  There is no warning or protection for the user to avoid enabling of 
> Interactive Query immediately after disabling it. Showing a popup to warn the 
> user about a pending batch request would be helpful here.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20686) Allow compilation with maven >=2.2

[Arnaud Launay (JIRA)]

Arnaud Launay created AMBARI-20686:
--

 Summary: Allow compilation with maven >=2.2
 Key: AMBARI-20686
 URL: https://issues.apache.org/jira/browse/AMBARI-20686
 Project: Ambari
  Issue Type: Bug
 Environment: Debian Jessie 8.0 with Java 8, maven 3.3.9
Reporter: Arnaud Launay
Priority: Minor
 Fix For: 2.5.0


Compilation fails with recent maven due to empty id.

Here is a pull request including a patch correcting it:

https://github.com/apache/ambari/pull/52



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20429) Warn users about pending requests while trying to enable Interactive Query immediately after disabling it

[Vivek Ratnavel Subramanian (JIRA)]

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

Vivek Ratnavel Subramanian commented on AMBARI-20429:
-

Committed to branch-2.5 again - 09105035abd51ef0d820bcafa7ec38cebb079e2f

> Warn users about pending requests while trying to enable Interactive Query 
> immediately after disabling it
> -
>
> Key: AMBARI-20429
> URL: https://issues.apache.org/jira/browse/AMBARI-20429
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Vivek Ratnavel Subramanian
>Assignee: Vivek Ratnavel Subramanian
> Fix For: 2.5.1
>
> Attachments: AMBARI-20429.v0.branch-2.5.patch
>
>
>  There is no warning or protection for the user to avoid enabling of 
> Interactive Query immediately after disabling it. Showing a popup to warn the 
> user about a pending batch request would be helpful here.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (AMBARI-20429) Warn users about pending requests while trying to enable Interactive Query immediately after disabling it

[Vivek Ratnavel Subramanian (JIRA)]

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

Vivek Ratnavel Subramanian resolved AMBARI-20429.
-
Resolution: Fixed

> Warn users about pending requests while trying to enable Interactive Query 
> immediately after disabling it
> -
>
> Key: AMBARI-20429
> URL: https://issues.apache.org/jira/browse/AMBARI-20429
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Vivek Ratnavel Subramanian
>Assignee: Vivek Ratnavel Subramanian
> Fix For: 2.5.1
>
> Attachments: AMBARI-20429.v0.branch-2.5.patch
>
>
>  There is no warning or protection for the user to avoid enabling of 
> Interactive Query immediately after disabling it. Showing a popup to warn the 
> user about a pending batch request would be helpful here.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20612) Fetching running application logs results in 'java.io.IOException'

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20612:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1361 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1361/])
AMBARI-20612. Fetching running application logs results in (smohanty: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=413db00ffe8592baef121c132189ff054fa6c630])
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.6.xml
* (add) 
ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/FixYarnWebServiceUrl.java
* (add) 
ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/FixYarnWebServiceUrlTest.java
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.6.xml
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.6.xml
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.6.xml
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.6.xml
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.6.xml


> Fetching running application logs results in 'java.io.IOException'
> --
>
> Key: AMBARI-20612
> URL: https://issues.apache.org/jira/browse/AMBARI-20612
> Project: Ambari
>  Issue Type: Bug
>Reporter: Sumana Sathish
>Assignee: Madhuvanthi Radhakrishnan
> Fix For: 2.5.1
>
>
> A new property called yarn.log.server.web-service.url was added in HDP 2.6
> It takes value from yarn.timeline-service.webapp.address if the 
> yarn.http.policy is HTTP_ONLY and takes value from 
> yarn.timeline-service.webapp.https.address if the yarn.http.policy is 
> HTTPS_ONLY.
> The logic works on fresh installs but is not present during upgrades from 
> HDP2.x to HDP2.6
> Fix is to provide the upgrade packs for it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20568) Update hash aggregation settings for llap in hdp stack

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20568:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1361 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1361/])
AMBARI-20568. Update hash aggregation settings for llap in hdp stack (smohanty: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=6e256d9f09c16f79f912889f50dfb3bcf19aa232])
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-site.xml
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/config-upgrade.xml
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.6.xml
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.6.xml


> Update hash aggregation settings for llap in hdp stack
> --
>
> Key: AMBARI-20568
> URL: https://issues.apache.org/jira/browse/AMBARI-20568
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Reporter: Siddharth Seth
>Assignee: Siddharth Seth
> Fix For: 2.5.1
>
> Attachments: AMBARI-20568.01.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20556) Add SPARK_CONF_DIR in livy-env when upgrading from HDP 2.5 to 2.6

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20556:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1361 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1361/])
AMBARI-20556. Add SPARK_CONF_DIR in livy-env when upgrading from HDP 2.5 
(smohanty: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=7fbec01c4eb1f947ca03fae4c6f83081cec26f10])
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/config-upgrade.xml
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.6.xml
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.6.xml


> Add SPARK_CONF_DIR in livy-env when upgrading from HDP 2.5 to 2.6
> -
>
> Key: AMBARI-20556
> URL: https://issues.apache.org/jira/browse/AMBARI-20556
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Yesha Vora
>Assignee: Jeff Zhang
> Fix For: 2.5.1
>
> Attachments: AMBARI-20556-1.patch, AMBARI-20556-2.patch
>
>
> Thanks for [~yeshavora] for finding this issue. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20555) Add Ambari cluster name for Ranger-Tagsync to sync generated atlas tags.

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20555:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1361 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1361/])
AMBARI-20555. Add Ambari cluster name for Ranger-Tagsync to sync (smohanty: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=1730747cf0da3a35dd85f4864e04d389d25cad30])
* (edit) 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/params.py
* (edit) 
ambari-server/src/main/resources/common-services/RANGER/0.7.0/configuration/ranger-tagsync-site.xml


> Add Ambari cluster name for Ranger-Tagsync to sync generated atlas tags.
> 
>
> Key: AMBARI-20555
> URL: https://issues.apache.org/jira/browse/AMBARI-20555
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vishal Suvagia
>Assignee: Vishal Suvagia
> Fix For: 2.5.1
>
> Attachments: AMBARI-20555.patch
>
>
> Need to add {{ranger.tagsync.atlas.default.cluster.name}} property to 
> {{ranger-tagsync-site.xml}} should be set to ambari cluster-name, to sync 
> tags from Atlas metadata to Ranger.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20570) Remove property atlas.cluster.name from hive-site for fresh deployments

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20570:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1361 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1361/])
AMBARI-20570. Remove property atlas.cluster.name from hive-site for (smohanty: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=a9a23e22afd4b92226baed28af43aa33aeb7ba59])
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-site.xml


> Remove property atlas.cluster.name from hive-site for fresh deployments
> ---
>
> Key: AMBARI-20570
> URL: https://issues.apache.org/jira/browse/AMBARI-20570
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.5.0
>Reporter: Sumit Mohanty
>Assignee: Sumit Mohanty
> Fix For: 2.5.1
>
> Attachments: AMBARI-20570.patch
>
>
> Property atlas.cluster.name is no longer expected in hive-site. It should 
> have been deleted in the stack definition, from HDP-2.5/hive-site onwards but 
> it was missed. 
> Presence of this property does not cause any problem either.
> Now, if you deploy Hive and Atlas together (UI or BP) you will see this 
> property added and subsequently removed when Atlas is removed.
> If you deploy just Hive and then add Atlas, the property will not get added 
> and thus it will not appear in the list of properties being removed.
> This bug is only tracking fresh cluster deployments.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20554) Fix minimum recommended value for slider and Tez AM for HSI.

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20554:
-

SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #1360 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1360/])
AMBARI-20554. Fix minimum recommended value for slider and Tez AM for 
(smohanty: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=44b5155fc0bdebd359143063524d90f14bf8572a])
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py
* (edit) ambari-server/src/test/python/stacks/2.5/common/test_stack_advisor.py


> Fix minimum recommended value for slider and Tez AM for HSI.
> 
>
> Key: AMBARI-20554
> URL: https://issues.apache.org/jira/browse/AMBARI-20554
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
>Priority: Blocker
> Fix For: 2.5.1
>
> Attachments: AMBARI-20554.branch2.5.patch, AMBARI-20554.trunk.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20537) Some config changes for LLAP to avoid daemon getting killed

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20537:
-

SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #1360 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1360/])
AMBARI-20537. Some config changes for LLAP to avoid daemon getting (smohanty: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=84ba22a711bf89b3286c155ec99f638414079d6b])
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-env.xml
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.6/services/HIVE/configuration/hive-interactive-env.xml
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/tez-interactive-site.xml


> Some config changes for LLAP to avoid daemon getting killed
> ---
>
> Key: AMBARI-20537
> URL: https://issues.apache.org/jira/browse/AMBARI-20537
> Project: Ambari
>  Issue Type: Bug
>  Components:  HiveServer2, Metastore, and Client Heap Sizes to Smart 
> Configs
>Affects Versions: 2.5.0
>Reporter: Prasanth Jayachandran
>Assignee: Prasanth Jayachandran
> Fix For: 2.5.1
>
> Attachments: AMBARI-20537.2.patch, AMBARI-20537.patch
>
>
> Following changes are required to improve the stability of LLAP daemons
> {code}
> tez.runtime.shuffle.parallel.copies=8
> Add "-Xss512k" to LLAP app java opts
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20685) Upgrade Progress Dialog Executes Query Which Causes StackOverflow in JPA

[Jonathan Hurley (JIRA)]

Jonathan Hurley created AMBARI-20685:


 Summary: Upgrade Progress Dialog Executes Query Which Causes 
StackOverflow in JPA
 Key: AMBARI-20685
 URL: https://issues.apache.org/jira/browse/AMBARI-20685
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.4.2
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
Priority: Critical
 Fix For: 2.5.1


Large rolling upgrades (1000 hosts with 10,000 host components) creates a 
massive request object object with 10's of 1000's of stages and tasks. The web 
client executes a {{GET}} command against the API to retrieve upgrade 
groups/items. On a large upgrade, this causes the EclipseLink SQL generation 
code to run out of stack frame space while recursively building a query. To 
work around this, the stack frame size per thread can be increased using 
{{-Xss}} along with a value like 32M.

{code}
http://localhost:8080/api/v1/clusters/c1/upgrades/12?
upgrade_groups/UpgradeGroup/status!=PENDING&
fields=
  Upgrade/progress_percent,
  Upgrade/request_context,
  Upgrade/request_status,
  Upgrade/direction,
  Upgrade/downgrade_allowed,
  upgrade_groups/UpgradeGroup,
  Upgrade/*,
  upgrade_groups/upgrade_items/UpgradeItem/status,
  upgrade_groups/upgrade_items/UpgradeItem/display_status,
  upgrade_groups/upgrade_items/UpgradeItem/context,
  upgrade_groups/upgrade_items/UpgradeItem/group_id,
  upgrade_groups/upgrade_items/UpgradeItem/progress_percent,
  upgrade_groups/upgrade_items/UpgradeItem/request_id,
  upgrade_groups/upgrade_items/UpgradeItem/skippable,
  upgrade_groups/upgrade_items/UpgradeItem/stage_id,
  upgrade_groups/upgrade_items/UpgradeItem/text&
  minimal_response=true&_=1489680258782
{code}

This call gets turn into a LOT of queries, but some seem to be based on the 
number of stages. For example, this one on a very small upgrade produces very 
poor SQL...

{code}
SELECT
  stage_id,
  cluster_host_info,
  cluster_id,
  command_execution_type,
  command_params,
  display_status,
  host_params,
  log_info,
  request_context,
  request_id,
  skippable,
  status,
  supports_auto_skip_failure
FROM stage
WHERE ((request_id = ?)
AND stage_id = ?)
OR (stage_id = ?))
OR (stage_id = ?))
OR (stage_id = ?))
OR (stage_id = ?))
OR (stage_id = ?))
OR (stage_id = ?))
OR (stage_id = ?)))
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20684) Implement a websocket adapter for stomp.py

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk commented on AMBARI-20684:
--

The patch is not for trunk. That's why Hadoop QA results are irrelevant 

> Implement a websocket adapter for stomp.py
> --
>
> Key: AMBARI-20684
> URL: https://issues.apache.org/jira/browse/AMBARI-20684
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-20684.patch
>
>
> This is needed for stomp to work via websocket instead of tcp



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20667) Storm metrics sink can't connect Ambari metrics collector

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20667:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1359 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1359/])
AMBARI-20667 : Storm metrics sink can't connect Ambari metrics (avijayan: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=4bb66330cd494813d2fd32e5df3afca1ff5da2a0])
* (edit) 
ambari-metrics/ambari-metrics-storm-sink/src/main/java/org/apache/hadoop/metrics2/sink/storm/StormTimelineMetricsSink.java


> Storm metrics sink can't connect Ambari metrics collector
> -
>
> Key: AMBARI-20667
> URL: https://issues.apache.org/jira/browse/AMBARI-20667
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.5.0, 2.5.1
>Reporter: Jungtaek Lim
>Assignee: Jungtaek Lim
>Priority: Critical
> Fix For: 2.5.1
>
> Attachments: AMBARI-20667-branch-2.5.patch
>
>
> From Storm's worker log:
> {code}
> 2017-04-03 07:00:07.643 
> o.a.h.m.s.t.a.MetricSinkWriteShardHostnameHashingStrategy [INFO] Calculated 
> collector shard vett-hdf-sam2.field.hortonworks.com based on hostname: 
> vett-hdf-sam8.field.hortonworks.com
> 2017-04-03 07:00:07.774 o.a.h.m.s.s.StormTimelineMetricsSink [INFO] Unable to 
> connect to collector, null
> This exceptions will be ignored for next 100 times
> 2017-04-03 07:00:07.775 o.a.h.m.s.s.StormTimelineMetricsSink [WARN] Unable to 
> send metrics to collector by address:null
> {code}
> I guess AMBARI-16828 is applied well for trunk, but there seems a mistake for 
> backporting the patch to branch-2.5. Please compare two links below:
> For trunk:
> https://github.com/apache/ambari/blob/trunk/ambari-metrics/ambari-metrics-storm-sink/src/main/java/org/apache/hadoop/metrics2/sink/storm/StormTimelineMetricsSink.java#L74
> For branch-2.5:
> https://github.com/apache/ambari/blob/branch-2.5/ambari-metrics/ambari-metrics-storm-sink/src/main/java/org/apache/hadoop/metrics2/sink/storm/StormTimelineMetricsSink.java#L74
>  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20551) Blueprint export fails if config-type is not mapped to any service after upgrade

[Amruta Borkar (JIRA)]

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

Amruta Borkar updated AMBARI-20551:
---
Status: Patch Available  (was: In Progress)

> Blueprint export fails if config-type is not mapped to any service after 
> upgrade
> 
>
> Key: AMBARI-20551
> URL: https://issues.apache.org/jira/browse/AMBARI-20551
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, blueprints
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-20551.patch
>
>
> 20 Mar 2017 11:39:57,948 ERROR [ambari-client-thread-8726] ReadHandler:99 - 
> Bad request:
> java.lang.IllegalArgumentException: Specified configuration type is not 
> associated with any service: storm-site
> at 
> org.apache.ambari.server.controller.internal.Stack.getServiceForConfigType(Stack.java:494)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor$StackPropertyTypeFilter.isPropertyIncluded(BlueprintConfigurationProcessor.java:2946)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.shouldPropertyBeExcludedForBlueprintExport(BlueprintConfigurationProcessor.java:939)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doFilterPriorToExport(BlueprintConfigurationProcessor.java:439)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForBlueprintExport(BlueprintConfigurationProcessor.java:416)
> at 
> org.apache.ambari.server.api.query.render.ClusterBlueprintRenderer.createBlueprintResource(ClusterBlueprintRenderer.java:186)
> at 
> org.apache.ambari.server.api.query.render.ClusterBlueprintRenderer.finalizeResult(ClusterBlueprintRenderer.java:141)
> at 
> org.apache.ambari.server.api.query.QueryImpl.getResult(QueryImpl.java:839)
> at 
> org.apache.ambari.server.api.query.QueryImpl.execute(QueryImpl.java:223)
> at 
> org.apache.ambari.server.api.handlers.ReadHandler.handleRequest(ReadHandler.java:77)
> at 
> org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:145)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:126)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:90)
> at 
> org.apache.ambari.server.api.services.ClusterService.getCluster(ClusterService.java:91)
> at sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20551) Blueprint export fails if config-type is not mapped to any service after upgrade

[Amruta Borkar (JIRA)]

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

Amruta Borkar updated AMBARI-20551:
---
Status: Open  (was: Patch Available)

> Blueprint export fails if config-type is not mapped to any service after 
> upgrade
> 
>
> Key: AMBARI-20551
> URL: https://issues.apache.org/jira/browse/AMBARI-20551
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, blueprints
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-20551.patch
>
>
> 20 Mar 2017 11:39:57,948 ERROR [ambari-client-thread-8726] ReadHandler:99 - 
> Bad request:
> java.lang.IllegalArgumentException: Specified configuration type is not 
> associated with any service: storm-site
> at 
> org.apache.ambari.server.controller.internal.Stack.getServiceForConfigType(Stack.java:494)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor$StackPropertyTypeFilter.isPropertyIncluded(BlueprintConfigurationProcessor.java:2946)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.shouldPropertyBeExcludedForBlueprintExport(BlueprintConfigurationProcessor.java:939)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doFilterPriorToExport(BlueprintConfigurationProcessor.java:439)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForBlueprintExport(BlueprintConfigurationProcessor.java:416)
> at 
> org.apache.ambari.server.api.query.render.ClusterBlueprintRenderer.createBlueprintResource(ClusterBlueprintRenderer.java:186)
> at 
> org.apache.ambari.server.api.query.render.ClusterBlueprintRenderer.finalizeResult(ClusterBlueprintRenderer.java:141)
> at 
> org.apache.ambari.server.api.query.QueryImpl.getResult(QueryImpl.java:839)
> at 
> org.apache.ambari.server.api.query.QueryImpl.execute(QueryImpl.java:223)
> at 
> org.apache.ambari.server.api.handlers.ReadHandler.handleRequest(ReadHandler.java:77)
> at 
> org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:145)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:126)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:90)
> at 
> org.apache.ambari.server.api.services.ClusterService.getCluster(ClusterService.java:91)
> at sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20551) Blueprint export fails if config-type is not mapped to any service after upgrade

[Amruta Borkar (JIRA)]

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

Amruta Borkar updated AMBARI-20551:
---
Attachment: AMBARI-20551.patch

> Blueprint export fails if config-type is not mapped to any service after 
> upgrade
> 
>
> Key: AMBARI-20551
> URL: https://issues.apache.org/jira/browse/AMBARI-20551
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, blueprints
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-20551.patch
>
>
> 20 Mar 2017 11:39:57,948 ERROR [ambari-client-thread-8726] ReadHandler:99 - 
> Bad request:
> java.lang.IllegalArgumentException: Specified configuration type is not 
> associated with any service: storm-site
> at 
> org.apache.ambari.server.controller.internal.Stack.getServiceForConfigType(Stack.java:494)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor$StackPropertyTypeFilter.isPropertyIncluded(BlueprintConfigurationProcessor.java:2946)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.shouldPropertyBeExcludedForBlueprintExport(BlueprintConfigurationProcessor.java:939)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doFilterPriorToExport(BlueprintConfigurationProcessor.java:439)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForBlueprintExport(BlueprintConfigurationProcessor.java:416)
> at 
> org.apache.ambari.server.api.query.render.ClusterBlueprintRenderer.createBlueprintResource(ClusterBlueprintRenderer.java:186)
> at 
> org.apache.ambari.server.api.query.render.ClusterBlueprintRenderer.finalizeResult(ClusterBlueprintRenderer.java:141)
> at 
> org.apache.ambari.server.api.query.QueryImpl.getResult(QueryImpl.java:839)
> at 
> org.apache.ambari.server.api.query.QueryImpl.execute(QueryImpl.java:223)
> at 
> org.apache.ambari.server.api.handlers.ReadHandler.handleRequest(ReadHandler.java:77)
> at 
> org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:145)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:126)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:90)
> at 
> org.apache.ambari.server.api.services.ClusterService.getCluster(ClusterService.java:91)
> at sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20551) Blueprint export fails if config-type is not mapped to any service after upgrade

[Amruta Borkar (JIRA)]

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

Amruta Borkar updated AMBARI-20551:
---
Attachment: (was: AMBARI-20551.patch)

> Blueprint export fails if config-type is not mapped to any service after 
> upgrade
> 
>
> Key: AMBARI-20551
> URL: https://issues.apache.org/jira/browse/AMBARI-20551
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, blueprints
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-20551.patch
>
>
> 20 Mar 2017 11:39:57,948 ERROR [ambari-client-thread-8726] ReadHandler:99 - 
> Bad request:
> java.lang.IllegalArgumentException: Specified configuration type is not 
> associated with any service: storm-site
> at 
> org.apache.ambari.server.controller.internal.Stack.getServiceForConfigType(Stack.java:494)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor$StackPropertyTypeFilter.isPropertyIncluded(BlueprintConfigurationProcessor.java:2946)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.shouldPropertyBeExcludedForBlueprintExport(BlueprintConfigurationProcessor.java:939)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doFilterPriorToExport(BlueprintConfigurationProcessor.java:439)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForBlueprintExport(BlueprintConfigurationProcessor.java:416)
> at 
> org.apache.ambari.server.api.query.render.ClusterBlueprintRenderer.createBlueprintResource(ClusterBlueprintRenderer.java:186)
> at 
> org.apache.ambari.server.api.query.render.ClusterBlueprintRenderer.finalizeResult(ClusterBlueprintRenderer.java:141)
> at 
> org.apache.ambari.server.api.query.QueryImpl.getResult(QueryImpl.java:839)
> at 
> org.apache.ambari.server.api.query.QueryImpl.execute(QueryImpl.java:223)
> at 
> org.apache.ambari.server.api.handlers.ReadHandler.handleRequest(ReadHandler.java:77)
> at 
> org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:145)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:126)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:90)
> at 
> org.apache.ambari.server.api.services.ClusterService.getCluster(ClusterService.java:91)
> at sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20674) Able to hide the Delete menu item from UI for a given service

[Di Li (JIRA)]

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

Di Li updated AMBARI-20674:
---
Summary: Able to hide the Delete menu item from UI for a given service   
(was: About to hide the Delete menu item from UI for a given service )

> Able to hide the Delete menu item from UI for a given service 
> --
>
> Key: AMBARI-20674
> URL: https://issues.apache.org/jira/browse/AMBARI-20674
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server, ambari-web
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
> Fix For: trunk
>
> Attachments: AMBARI-20674.patch
>
>
> Stack driven approach to have UI show/hide Delete service menu item for a 
> given service.
> A service's metainfo.xml can have 
> false set at the service level to 
> indicate UI should hide the menu item. Directly going thru REST API calls are 
> always supported and non-restricted. 
> If the section is missing, it will be treated as "support" UI delete service 
> operation. In other words, UI only hides the menu item if metainfo.xml has 
> explicitly set the flag to false.
> Example.
> "" +
> "  2.0" +
> "  " +
> "" +
> "  HDFS" +
> "  HDFS" +
> "  false" +
> "" +
> "  " +
> "";



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20667) Storm metrics sink can't connect Ambari metrics collector

[Aravindan Vijayan (JIRA)]

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

Aravindan Vijayan updated AMBARI-20667:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Pushed to branch-2.5.

> Storm metrics sink can't connect Ambari metrics collector
> -
>
> Key: AMBARI-20667
> URL: https://issues.apache.org/jira/browse/AMBARI-20667
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.5.0, 2.5.1
>Reporter: Jungtaek Lim
>Assignee: Jungtaek Lim
>Priority: Critical
> Fix For: 2.5.1
>
> Attachments: AMBARI-20667-branch-2.5.patch
>
>
> From Storm's worker log:
> {code}
> 2017-04-03 07:00:07.643 
> o.a.h.m.s.t.a.MetricSinkWriteShardHostnameHashingStrategy [INFO] Calculated 
> collector shard vett-hdf-sam2.field.hortonworks.com based on hostname: 
> vett-hdf-sam8.field.hortonworks.com
> 2017-04-03 07:00:07.774 o.a.h.m.s.s.StormTimelineMetricsSink [INFO] Unable to 
> connect to collector, null
> This exceptions will be ignored for next 100 times
> 2017-04-03 07:00:07.775 o.a.h.m.s.s.StormTimelineMetricsSink [WARN] Unable to 
> send metrics to collector by address:null
> {code}
> I guess AMBARI-16828 is applied well for trunk, but there seems a mistake for 
> backporting the patch to branch-2.5. Please compare two links below:
> For trunk:
> https://github.com/apache/ambari/blob/trunk/ambari-metrics/ambari-metrics-storm-sink/src/main/java/org/apache/hadoop/metrics2/sink/storm/StormTimelineMetricsSink.java#L74
> For branch-2.5:
> https://github.com/apache/ambari/blob/branch-2.5/ambari-metrics/ambari-metrics-storm-sink/src/main/java/org/apache/hadoop/metrics2/sink/storm/StormTimelineMetricsSink.java#L74
>  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20667) Storm metrics sink can't connect Ambari metrics collector

[Aravindan Vijayan (JIRA)]

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

Aravindan Vijayan updated AMBARI-20667:
---
Fix Version/s: 2.5.1

> Storm metrics sink can't connect Ambari metrics collector
> -
>
> Key: AMBARI-20667
> URL: https://issues.apache.org/jira/browse/AMBARI-20667
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.5.0, 2.5.1
>Reporter: Jungtaek Lim
>Assignee: Jungtaek Lim
>Priority: Critical
> Fix For: 2.5.1
>
> Attachments: AMBARI-20667-branch-2.5.patch
>
>
> From Storm's worker log:
> {code}
> 2017-04-03 07:00:07.643 
> o.a.h.m.s.t.a.MetricSinkWriteShardHostnameHashingStrategy [INFO] Calculated 
> collector shard vett-hdf-sam2.field.hortonworks.com based on hostname: 
> vett-hdf-sam8.field.hortonworks.com
> 2017-04-03 07:00:07.774 o.a.h.m.s.s.StormTimelineMetricsSink [INFO] Unable to 
> connect to collector, null
> This exceptions will be ignored for next 100 times
> 2017-04-03 07:00:07.775 o.a.h.m.s.s.StormTimelineMetricsSink [WARN] Unable to 
> send metrics to collector by address:null
> {code}
> I guess AMBARI-16828 is applied well for trunk, but there seems a mistake for 
> backporting the patch to branch-2.5. Please compare two links below:
> For trunk:
> https://github.com/apache/ambari/blob/trunk/ambari-metrics/ambari-metrics-storm-sink/src/main/java/org/apache/hadoop/metrics2/sink/storm/StormTimelineMetricsSink.java#L74
> For branch-2.5:
> https://github.com/apache/ambari/blob/branch-2.5/ambari-metrics/ambari-metrics-storm-sink/src/main/java/org/apache/hadoop/metrics2/sink/storm/StormTimelineMetricsSink.java#L74
>  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20667) Storm metrics sink can't connect Ambari metrics collector

[Aravindan Vijayan (JIRA)]

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

Aravindan Vijayan commented on AMBARI-20667:


LGTM +1

> Storm metrics sink can't connect Ambari metrics collector
> -
>
> Key: AMBARI-20667
> URL: https://issues.apache.org/jira/browse/AMBARI-20667
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.5.0, 2.5.1
>Reporter: Jungtaek Lim
>Assignee: Jungtaek Lim
>Priority: Critical
> Fix For: 2.5.1
>
> Attachments: AMBARI-20667-branch-2.5.patch
>
>
> From Storm's worker log:
> {code}
> 2017-04-03 07:00:07.643 
> o.a.h.m.s.t.a.MetricSinkWriteShardHostnameHashingStrategy [INFO] Calculated 
> collector shard vett-hdf-sam2.field.hortonworks.com based on hostname: 
> vett-hdf-sam8.field.hortonworks.com
> 2017-04-03 07:00:07.774 o.a.h.m.s.s.StormTimelineMetricsSink [INFO] Unable to 
> connect to collector, null
> This exceptions will be ignored for next 100 times
> 2017-04-03 07:00:07.775 o.a.h.m.s.s.StormTimelineMetricsSink [WARN] Unable to 
> send metrics to collector by address:null
> {code}
> I guess AMBARI-16828 is applied well for trunk, but there seems a mistake for 
> backporting the patch to branch-2.5. Please compare two links below:
> For trunk:
> https://github.com/apache/ambari/blob/trunk/ambari-metrics/ambari-metrics-storm-sink/src/main/java/org/apache/hadoop/metrics2/sink/storm/StormTimelineMetricsSink.java#L74
> For branch-2.5:
> https://github.com/apache/ambari/blob/branch-2.5/ambari-metrics/ambari-metrics-storm-sink/src/main/java/org/apache/hadoop/metrics2/sink/storm/StormTimelineMetricsSink.java#L74
>  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20676) User should be able to visualize inherited properties while submitting the workflow

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20676:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12862045/AMBARI-20676_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 1 new 
or modified test files.

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

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

{color:red}-1 core tests{color}.  The test build failed in 
contrib/views/wfmanager/src/main/resources/ui 

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

This message is automatically generated.

> User should be able to visualize inherited properties while submitting the 
> workflow
> ---
>
> Key: AMBARI-20676
> URL: https://issues.apache.org/jira/browse/AMBARI-20676
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.1
>Reporter: M Madhan Mohan Reddy
>Assignee: M Madhan Mohan Reddy
>  Labels: WFD, WFM
> Fix For: 2.5.1
>
> Attachments: AMBARI-20676_trunk.patch
>
>
> User should be able to visualize inherited properties while submitting the 
> workflow.
> As asked by one of the user (Artem) its better to show inherited properties 
> like “queueName”, “resourceManager”, “namenode” etc which are added by 
> workflow designer by default.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20677) Centering workflows for zoom breaks when multiple tabs exists

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20677:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12862047/AMBARI-20677_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 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

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

{color:red}-1 core tests{color}.  The test build failed in 
contrib/views/wfmanager/src/main/resources/ui 

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

This message is automatically generated.

> Centering workflows for zoom breaks when multiple tabs exists
> -
>
> Key: AMBARI-20677
> URL: https://issues.apache.org/jira/browse/AMBARI-20677
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.1
>Reporter: M Madhan Mohan Reddy
>Assignee: M Madhan Mohan Reddy
>  Labels: WFD, WFM
> Fix For: 2.5.1
>
> Attachments: AMBARI-20677_trunk.patch
>
>
> If multiple tabs exists, only the tab that got highlighted at the end has the 
> workflow at center. In remaining tabs, workflow is not at the center. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20678) Complete node name is not shown when node name is larger than 17 characters

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20678:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12862051/AMBARI-20678-branch-2_5-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 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

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

{color:red}-1 core tests{color}.  The test build failed in 
contrib/views/hive20 

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

This message is automatically generated.

> Complete node name is not shown when node name is larger than 17 characters
> ---
>
> Key: AMBARI-20678
> URL: https://issues.apache.org/jira/browse/AMBARI-20678
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: Pallav Kulshreshtha
>Assignee: Pallav Kulshreshtha
> Fix For: 2.5.1
>
> Attachments: AMBARI-20678-branch-2_5-2.patch
>
>
> Complete node name is not shown when node name is larger than 17 characters.
> Attaching the screenshot.
> From the usability aspect, its better to show the complete node name may be 
> on the tooltip.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20682) Wait For DataNodes To Shutdown During a Rolling Upgrade

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20682:


{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12862069/AMBARI-20682.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 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

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

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

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

This message is automatically generated.

> Wait For DataNodes To Shutdown During a Rolling Upgrade
> ---
>
> Key: AMBARI-20682
> URL: https://issues.apache.org/jira/browse/AMBARI-20682
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.2
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Fix For: 2.5.1
>
> Attachments: AMBARI-20682.patch
>
>
> During a rolling upgrade (especially on a large, heavily used cluster), the 
> DataNodes do not shutdown immediately. However, they do de-register from the 
> NameNode which tricks Ambari into thinking that they are down.
> Since the rolling upgrade uses a {{RESTART}} command, we attempt to start the 
> DataNode back up before the daemon has shutdown:
> {code}
> 2017-03-14 05:00:25,602 - 
> call['/usr/hdp/current/hadoop-hdfs-datanode/bin/hdfs dfsadmin -fs hdfs://c1ha 
> -shutdownDatanode 0.0.0.0:8010 upgrade'] {'user': 'hdfs'}
> 2017-03-14 05:00:28,438 - call returned (0, 'Submitted a shutdown request to 
> datanode 0.0.0.0:8010')
> 2017-03-14 05:00:28,438 - 
> Execute['/usr/hdp/current/hadoop-hdfs-datanode/bin/hdfs dfsadmin -fs 
> hdfs://c1ha -D ipc.client.connect.max.retries=5 -D 
> ipc.client.connect.retry.interval=1000 -getDatanodeInfo 0.0.0.0:8010'] 
> {'tries': 1, 'user': 'hdfs'}
> 2017-03-14 05:00:35,976 - DataNode has successfully shutdown for upgrade.
> {code}
> Even though ~ 6 seconds have passed, the daemon is still running as it 
> drains. Therefore, we attempt to start it which causes a NOOP.
> Instead, we should also monitor for the PID.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20670) Node manager start extremely slow when YARN NM local dirs are very large

[Dmytro Grinenko (JIRA)]

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

Dmytro Grinenko updated AMBARI-20670:
-
Attachment: AMBARI-20670-2.5.patch

> Node manager start extremely slow when YARN NM local dirs are very large
> 
>
> Key: AMBARI-20670
> URL: https://issues.apache.org/jira/browse/AMBARI-20670
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.1
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk, 2.5.1
>
> Attachments: AMBARI-20670-2.5.patch, AMBARI-20670.patch
>
>
> On the cluster with the YARN NM, where local dirs are 100 GB+ with lot of 
> small files - NM starts slow with timeouts
> Reason could be in this specific call in  yarn.py
> {code}
> def create_local_dir(dir_name):
>   import params
>   Directory(dir_name,
> create_parents = True,
> cd_access="a",
> mode=0755,
> owner=params.yarn_user,
> group=params.user_group,
> ignore_failures=True,
> recursive_mode_flags = {'f': 'a+rw', 'd': 'a+rwx'},
>   )
> {code}
> was taking ~15 minutes per mount.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20670) Node manager start extremely slow when YARN NM local dirs are very large

[Dmytro Grinenko (JIRA)]

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

Dmytro Grinenko updated AMBARI-20670:
-
Status: Patch Available  (was: In Progress)

> Node manager start extremely slow when YARN NM local dirs are very large
> 
>
> Key: AMBARI-20670
> URL: https://issues.apache.org/jira/browse/AMBARI-20670
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.1
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk, 2.5.1
>
> Attachments: AMBARI-20670.patch
>
>
> On the cluster with the YARN NM, where local dirs are 100 GB+ with lot of 
> small files - NM starts slow with timeouts
> Reason could be in this specific call in  yarn.py
> {code}
> def create_local_dir(dir_name):
>   import params
>   Directory(dir_name,
> create_parents = True,
> cd_access="a",
> mode=0755,
> owner=params.yarn_user,
> group=params.user_group,
> ignore_failures=True,
> recursive_mode_flags = {'f': 'a+rw', 'd': 'a+rwx'},
>   )
> {code}
> was taking ~15 minutes per mount.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20670) Node manager start extremely slow when YARN NM local dirs are very large

[Dmytro Grinenko (JIRA)]

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

Dmytro Grinenko updated AMBARI-20670:
-
Attachment: AMBARI-20670.patch

> Node manager start extremely slow when YARN NM local dirs are very large
> 
>
> Key: AMBARI-20670
> URL: https://issues.apache.org/jira/browse/AMBARI-20670
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.1
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk, 2.5.1
>
> Attachments: AMBARI-20670.patch
>
>
> On the cluster with the YARN NM, where local dirs are 100 GB+ with lot of 
> small files - NM starts slow with timeouts
> Reason could be in this specific call in  yarn.py
> {code}
> def create_local_dir(dir_name):
>   import params
>   Directory(dir_name,
> create_parents = True,
> cd_access="a",
> mode=0755,
> owner=params.yarn_user,
> group=params.user_group,
> ignore_failures=True,
> recursive_mode_flags = {'f': 'a+rw', 'd': 'a+rwx'},
>   )
> {code}
> was taking ~15 minutes per mount.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20684) Implement a websocket adapter for stomp.py

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20684:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12862079/AMBARI-20684.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/11308//console

This message is automatically generated.

> Implement a websocket adapter for stomp.py
> --
>
> Key: AMBARI-20684
> URL: https://issues.apache.org/jira/browse/AMBARI-20684
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-20684.patch
>
>
> This is needed for stomp to work via websocket instead of tcp



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20683) Reduce size of persisted configurations in wizards

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20683:
-

SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #7242 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/7242/])
AMBARI-20683 Reduce size of persisted configurations in wizards. (atkach: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=7d0baec7d7ddad29a6955f3af2ff6f020136abcd])
* (edit) ambari-web/app/controllers/main/service/add_controller.js
* (edit) ambari-web/test/init_test.js
* (edit) ambari-web/app/routes/installer.js
* (edit) ambari-web/app/routes/add_service_routes.js
* (edit) ambari-web/test/controllers/wizard_test.js
* (edit) ambari-web/app/controllers/wizard.js
* (edit) ambari-web/app/controllers/main/admin/kerberos/wizard_controller.js
* (edit) ambari-web/app/controllers/installer.js
* (edit) ambari-web/app/routes/add_kerberos_routes.js
* (edit) ambari-web/test/controllers/installer_test.js


> Reduce size of persisted configurations in wizards
> --
>
> Key: AMBARI-20683
> URL: https://issues.apache.org/jira/browse/AMBARI-20683
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
> Fix For: 3.0.0
>
> Attachments: AMBARI-20683.patch
>
>
> Currently on routing Customize Services -> Review, we save all configs with 
> an entire set of its attributes, most of that data static.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20683) Reduce size of persisted configurations in wizards

[Andrii Tkach (JIRA)]

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

Andrii Tkach commented on AMBARI-20683:
---

committed to trunk

> Reduce size of persisted configurations in wizards
> --
>
> Key: AMBARI-20683
> URL: https://issues.apache.org/jira/browse/AMBARI-20683
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
> Fix For: 3.0.0
>
> Attachments: AMBARI-20683.patch
>
>
> Currently on routing Customize Services -> Review, we save all configs with 
> an entire set of its attributes, most of that data static.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20683) Reduce size of persisted configurations in wizards

[Andrii Tkach (JIRA)]

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

Andrii Tkach updated AMBARI-20683:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Reduce size of persisted configurations in wizards
> --
>
> Key: AMBARI-20683
> URL: https://issues.apache.org/jira/browse/AMBARI-20683
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
> Fix For: 3.0.0
>
> Attachments: AMBARI-20683.patch
>
>
> Currently on routing Customize Services -> Review, we save all configs with 
> an entire set of its attributes, most of that data static.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20683) Reduce size of persisted configurations in wizards

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20683:


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

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

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

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

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler 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/11307//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/11307//console

This message is automatically generated.

> Reduce size of persisted configurations in wizards
> --
>
> Key: AMBARI-20683
> URL: https://issues.apache.org/jira/browse/AMBARI-20683
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
> Fix For: 3.0.0
>
> Attachments: AMBARI-20683.patch
>
>
> Currently on routing Customize Services -> Review, we save all configs with 
> an entire set of its attributes, most of that data static.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20683) Reduce size of persisted configurations in wizards

[Aleksandr Kovalenko (JIRA)]

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

Aleksandr Kovalenko commented on AMBARI-20683:
--

+1 for the patch

> Reduce size of persisted configurations in wizards
> --
>
> Key: AMBARI-20683
> URL: https://issues.apache.org/jira/browse/AMBARI-20683
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
> Fix For: 3.0.0
>
> Attachments: AMBARI-20683.patch
>
>
> Currently on routing Customize Services -> Review, we save all configs with 
> an entire set of its attributes, most of that data static.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20684) Implement a websocket adapter for stomp.py

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20684:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12862079/AMBARI-20684.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/11306//console

This message is automatically generated.

> Implement a websocket adapter for stomp.py
> --
>
> Key: AMBARI-20684
> URL: https://issues.apache.org/jira/browse/AMBARI-20684
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-20684.patch
>
>
> This is needed for stomp to work via websocket instead of tcp



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20684) Implement a websocket adapter for stomp.py

[Andrew Onischuk (JIRA)]

Andrew Onischuk created AMBARI-20684:


 Summary: Implement a websocket adapter for stomp.py
 Key: AMBARI-20684
 URL: https://issues.apache.org/jira/browse/AMBARI-20684
 Project: Ambari
  Issue Type: Bug
Reporter: Andrew Onischuk
Assignee: Andrew Onischuk
 Fix For: 3.0.0
 Attachments: AMBARI-20684.patch

This is needed for stomp to work via websocket instead of tcp





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20684) Implement a websocket adapter for stomp.py

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk updated AMBARI-20684:
-
Attachment: AMBARI-20684.patch

> Implement a websocket adapter for stomp.py
> --
>
> Key: AMBARI-20684
> URL: https://issues.apache.org/jira/browse/AMBARI-20684
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-20684.patch
>
>
> This is needed for stomp to work via websocket instead of tcp



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20684) Implement a websocket adapter for stomp.py

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk updated AMBARI-20684:
-
Status: Patch Available  (was: Open)

> Implement a websocket adapter for stomp.py
> --
>
> Key: AMBARI-20684
> URL: https://issues.apache.org/jira/browse/AMBARI-20684
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-20684.patch
>
>
> This is needed for stomp to work via websocket instead of tcp



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20683) Reduce size of persisted configurations in wizards

[Andrii Tkach (JIRA)]

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

Andrii Tkach commented on AMBARI-20683:
---

  20675 passing (34s)
  128 pending

> Reduce size of persisted configurations in wizards
> --
>
> Key: AMBARI-20683
> URL: https://issues.apache.org/jira/browse/AMBARI-20683
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
> Fix For: 3.0.0
>
> Attachments: AMBARI-20683.patch
>
>
> Currently on routing Customize Services -> Review, we save all configs with 
> an entire set of its attributes, most of that data static.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20683) Reduce size of persisted configurations in wizards

[Andrii Tkach (JIRA)]

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

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

> Reduce size of persisted configurations in wizards
> --
>
> Key: AMBARI-20683
> URL: https://issues.apache.org/jira/browse/AMBARI-20683
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
> Fix For: 3.0.0
>
> Attachments: AMBARI-20683.patch
>
>
> Currently on routing Customize Services -> Review, we save all configs with 
> an entire set of its attributes, most of that data static.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20683) Reduce size of persisted configurations in wizards

[Andrii Tkach (JIRA)]

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

Andrii Tkach updated AMBARI-20683:
--
Status: Patch Available  (was: Open)

> Reduce size of persisted configurations in wizards
> --
>
> Key: AMBARI-20683
> URL: https://issues.apache.org/jira/browse/AMBARI-20683
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
> Fix For: 3.0.0
>
> Attachments: AMBARI-20683.patch
>
>
> Currently on routing Customize Services -> Review, we save all configs with 
> an entire set of its attributes, most of that data static.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20681) Select Version step of installer: repo URL validation message issues

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20681:
-

SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #7241 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/7241/])
AMBARI-20681 Select Version step of installer: repo URL validation (ababiichuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=6c0b38e00b49eb1f7ac879053ee161496c971a3f])
* (edit) ambari-web/app/views/wizard/step1_view.js


> Select Version step of installer: repo URL validation message issues
> 
>
> Key: AMBARI-20681
> URL: https://issues.apache.org/jira/browse/AMBARI-20681
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-20681.patch, repo-url-overflow.jpg
>
>
> # Error message that contains long repository URL overflows the popover block.
> # Popover has no title.
> See [attached|^repo-url-overflow.jpg]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20683) Reduce size of persisted configurations in wizards

[Andrii Tkach (JIRA)]

Andrii Tkach created AMBARI-20683:
-

 Summary: Reduce size of persisted configurations in wizards
 Key: AMBARI-20683
 URL: https://issues.apache.org/jira/browse/AMBARI-20683
 Project: Ambari
  Issue Type: Task
  Components: ambari-web
Affects Versions: 3.0.0
Reporter: Andrii Tkach
Assignee: Andrii Tkach
 Fix For: 3.0.0


Currently on routing Customize Services -> Review, we save all configs with an 
entire set of its attributes, most of that data static.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20681) Select Version step of installer: repo URL validation message issues

[Andrii Babiichuk (JIRA)]

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

Andrii Babiichuk updated AMBARI-20681:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to trunk

> Select Version step of installer: repo URL validation message issues
> 
>
> Key: AMBARI-20681
> URL: https://issues.apache.org/jira/browse/AMBARI-20681
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-20681.patch, repo-url-overflow.jpg
>
>
> # Error message that contains long repository URL overflows the popover block.
> # Popover has no title.
> See [attached|^repo-url-overflow.jpg]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20681) Select Version step of installer: repo URL validation message issues

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20681:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12862065/AMBARI-20681.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 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler 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/11305//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/11305//console

This message is automatically generated.

> Select Version step of installer: repo URL validation message issues
> 
>
> Key: AMBARI-20681
> URL: https://issues.apache.org/jira/browse/AMBARI-20681
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-20681.patch, repo-url-overflow.jpg
>
>
> # Error message that contains long repository URL overflows the popover block.
> # Popover has no title.
> See [attached|^repo-url-overflow.jpg]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20682) Wait For DataNodes To Shutdown During a Rolling Upgrade

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-20682:

Affects Version/s: 2.4.2

> Wait For DataNodes To Shutdown During a Rolling Upgrade
> ---
>
> Key: AMBARI-20682
> URL: https://issues.apache.org/jira/browse/AMBARI-20682
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.2
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Fix For: 2.5.1
>
> Attachments: AMBARI-20682.patch
>
>
> During a rolling upgrade (especially on a large, heavily used cluster), the 
> DataNodes do not shutdown immediately. However, they do de-register from the 
> NameNode which tricks Ambari into thinking that they are down.
> Since the rolling upgrade uses a {{RESTART}} command, we attempt to start the 
> DataNode back up before the daemon has shutdown:
> {code}
> 2017-03-14 05:00:25,602 - 
> call['/usr/hdp/current/hadoop-hdfs-datanode/bin/hdfs dfsadmin -fs hdfs://c1ha 
> -shutdownDatanode 0.0.0.0:8010 upgrade'] {'user': 'hdfs'}
> 2017-03-14 05:00:28,438 - call returned (0, 'Submitted a shutdown request to 
> datanode 0.0.0.0:8010')
> 2017-03-14 05:00:28,438 - 
> Execute['/usr/hdp/current/hadoop-hdfs-datanode/bin/hdfs dfsadmin -fs 
> hdfs://c1ha -D ipc.client.connect.max.retries=5 -D 
> ipc.client.connect.retry.interval=1000 -getDatanodeInfo 0.0.0.0:8010'] 
> {'tries': 1, 'user': 'hdfs'}
> 2017-03-14 05:00:35,976 - DataNode has successfully shutdown for upgrade.
> {code}
> Even though ~ 6 seconds have passed, the daemon is still running as it 
> drains. Therefore, we attempt to start it which causes a NOOP.
> Instead, we should also monitor for the PID.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20682) Wait For DataNodes To Shutdown During a Rolling Upgrade

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-20682:

Fix Version/s: 2.5.1

> Wait For DataNodes To Shutdown During a Rolling Upgrade
> ---
>
> Key: AMBARI-20682
> URL: https://issues.apache.org/jira/browse/AMBARI-20682
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.2
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Fix For: 2.5.1
>
> Attachments: AMBARI-20682.patch
>
>
> During a rolling upgrade (especially on a large, heavily used cluster), the 
> DataNodes do not shutdown immediately. However, they do de-register from the 
> NameNode which tricks Ambari into thinking that they are down.
> Since the rolling upgrade uses a {{RESTART}} command, we attempt to start the 
> DataNode back up before the daemon has shutdown:
> {code}
> 2017-03-14 05:00:25,602 - 
> call['/usr/hdp/current/hadoop-hdfs-datanode/bin/hdfs dfsadmin -fs hdfs://c1ha 
> -shutdownDatanode 0.0.0.0:8010 upgrade'] {'user': 'hdfs'}
> 2017-03-14 05:00:28,438 - call returned (0, 'Submitted a shutdown request to 
> datanode 0.0.0.0:8010')
> 2017-03-14 05:00:28,438 - 
> Execute['/usr/hdp/current/hadoop-hdfs-datanode/bin/hdfs dfsadmin -fs 
> hdfs://c1ha -D ipc.client.connect.max.retries=5 -D 
> ipc.client.connect.retry.interval=1000 -getDatanodeInfo 0.0.0.0:8010'] 
> {'tries': 1, 'user': 'hdfs'}
> 2017-03-14 05:00:35,976 - DataNode has successfully shutdown for upgrade.
> {code}
> Even though ~ 6 seconds have passed, the daemon is still running as it 
> drains. Therefore, we attempt to start it which causes a NOOP.
> Instead, we should also monitor for the PID.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20682) Wait For DataNodes To Shutdown During a Rolling Upgrade

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-20682:

Attachment: AMBARI-20682.patch

> Wait For DataNodes To Shutdown During a Rolling Upgrade
> ---
>
> Key: AMBARI-20682
> URL: https://issues.apache.org/jira/browse/AMBARI-20682
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Attachments: AMBARI-20682.patch
>
>
> During a rolling upgrade (especially on a large, heavily used cluster), the 
> DataNodes do not shutdown immediately. However, they do de-register from the 
> NameNode which tricks Ambari into thinking that they are down.
> Since the rolling upgrade uses a {{RESTART}} command, we attempt to start the 
> DataNode back up before the daemon has shutdown:
> {code}
> 2017-03-14 05:00:25,602 - 
> call['/usr/hdp/current/hadoop-hdfs-datanode/bin/hdfs dfsadmin -fs hdfs://c1ha 
> -shutdownDatanode 0.0.0.0:8010 upgrade'] {'user': 'hdfs'}
> 2017-03-14 05:00:28,438 - call returned (0, 'Submitted a shutdown request to 
> datanode 0.0.0.0:8010')
> 2017-03-14 05:00:28,438 - 
> Execute['/usr/hdp/current/hadoop-hdfs-datanode/bin/hdfs dfsadmin -fs 
> hdfs://c1ha -D ipc.client.connect.max.retries=5 -D 
> ipc.client.connect.retry.interval=1000 -getDatanodeInfo 0.0.0.0:8010'] 
> {'tries': 1, 'user': 'hdfs'}
> 2017-03-14 05:00:35,976 - DataNode has successfully shutdown for upgrade.
> {code}
> Even though ~ 6 seconds have passed, the daemon is still running as it 
> drains. Therefore, we attempt to start it which causes a NOOP.
> Instead, we should also monitor for the PID.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20682) Wait For DataNodes To Shutdown During a Rolling Upgrade

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-20682:

Status: Patch Available  (was: Open)

> Wait For DataNodes To Shutdown During a Rolling Upgrade
> ---
>
> Key: AMBARI-20682
> URL: https://issues.apache.org/jira/browse/AMBARI-20682
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Attachments: AMBARI-20682.patch
>
>
> During a rolling upgrade (especially on a large, heavily used cluster), the 
> DataNodes do not shutdown immediately. However, they do de-register from the 
> NameNode which tricks Ambari into thinking that they are down.
> Since the rolling upgrade uses a {{RESTART}} command, we attempt to start the 
> DataNode back up before the daemon has shutdown:
> {code}
> 2017-03-14 05:00:25,602 - 
> call['/usr/hdp/current/hadoop-hdfs-datanode/bin/hdfs dfsadmin -fs hdfs://c1ha 
> -shutdownDatanode 0.0.0.0:8010 upgrade'] {'user': 'hdfs'}
> 2017-03-14 05:00:28,438 - call returned (0, 'Submitted a shutdown request to 
> datanode 0.0.0.0:8010')
> 2017-03-14 05:00:28,438 - 
> Execute['/usr/hdp/current/hadoop-hdfs-datanode/bin/hdfs dfsadmin -fs 
> hdfs://c1ha -D ipc.client.connect.max.retries=5 -D 
> ipc.client.connect.retry.interval=1000 -getDatanodeInfo 0.0.0.0:8010'] 
> {'tries': 1, 'user': 'hdfs'}
> 2017-03-14 05:00:35,976 - DataNode has successfully shutdown for upgrade.
> {code}
> Even though ~ 6 seconds have passed, the daemon is still running as it 
> drains. Therefore, we attempt to start it which causes a NOOP.
> Instead, we should also monitor for the PID.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20682) Wait For DataNodes To Shutdown During a Rolling Upgrade

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-20682:

Component/s: ambari-server

> Wait For DataNodes To Shutdown During a Rolling Upgrade
> ---
>
> Key: AMBARI-20682
> URL: https://issues.apache.org/jira/browse/AMBARI-20682
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
>Priority: Critical
> Attachments: AMBARI-20682.patch
>
>
> During a rolling upgrade (especially on a large, heavily used cluster), the 
> DataNodes do not shutdown immediately. However, they do de-register from the 
> NameNode which tricks Ambari into thinking that they are down.
> Since the rolling upgrade uses a {{RESTART}} command, we attempt to start the 
> DataNode back up before the daemon has shutdown:
> {code}
> 2017-03-14 05:00:25,602 - 
> call['/usr/hdp/current/hadoop-hdfs-datanode/bin/hdfs dfsadmin -fs hdfs://c1ha 
> -shutdownDatanode 0.0.0.0:8010 upgrade'] {'user': 'hdfs'}
> 2017-03-14 05:00:28,438 - call returned (0, 'Submitted a shutdown request to 
> datanode 0.0.0.0:8010')
> 2017-03-14 05:00:28,438 - 
> Execute['/usr/hdp/current/hadoop-hdfs-datanode/bin/hdfs dfsadmin -fs 
> hdfs://c1ha -D ipc.client.connect.max.retries=5 -D 
> ipc.client.connect.retry.interval=1000 -getDatanodeInfo 0.0.0.0:8010'] 
> {'tries': 1, 'user': 'hdfs'}
> 2017-03-14 05:00:35,976 - DataNode has successfully shutdown for upgrade.
> {code}
> Even though ~ 6 seconds have passed, the daemon is still running as it 
> drains. Therefore, we attempt to start it which causes a NOOP.
> Instead, we should also monitor for the PID.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20682) Wait For DataNodes To Shutdown During a Rolling Upgrade

[Dmitry Lysnichenko (JIRA)]

Dmitry Lysnichenko created AMBARI-20682:
---

 Summary: Wait For DataNodes To Shutdown During a Rolling Upgrade
 Key: AMBARI-20682
 URL: https://issues.apache.org/jira/browse/AMBARI-20682
 Project: Ambari
  Issue Type: Bug
Reporter: Dmitry Lysnichenko
Assignee: Dmitry Lysnichenko
Priority: Critical
 Attachments: AMBARI-20682.patch


During a rolling upgrade (especially on a large, heavily used cluster), the 
DataNodes do not shutdown immediately. However, they do de-register from the 
NameNode which tricks Ambari into thinking that they are down.

Since the rolling upgrade uses a {{RESTART}} command, we attempt to start the 
DataNode back up before the daemon has shutdown:

{code}
2017-03-14 05:00:25,602 - call['/usr/hdp/current/hadoop-hdfs-datanode/bin/hdfs 
dfsadmin -fs hdfs://c1ha -shutdownDatanode 0.0.0.0:8010 upgrade'] {'user': 
'hdfs'}
2017-03-14 05:00:28,438 - call returned (0, 'Submitted a shutdown request to 
datanode 0.0.0.0:8010')
2017-03-14 05:00:28,438 - 
Execute['/usr/hdp/current/hadoop-hdfs-datanode/bin/hdfs dfsadmin -fs 
hdfs://c1ha -D ipc.client.connect.max.retries=5 -D 
ipc.client.connect.retry.interval=1000 -getDatanodeInfo 0.0.0.0:8010'] 
{'tries': 1, 'user': 'hdfs'}
2017-03-14 05:00:35,976 - DataNode has successfully shutdown for upgrade.
{code}

Even though ~ 6 seconds have passed, the daemon is still running as it drains. 
Therefore, we attempt to start it which causes a NOOP.

Instead, we should also monitor for the PID.





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20681) Select Version step of installer: repo URL validation message issues

[Andrii Babiichuk (JIRA)]

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

Andrii Babiichuk updated AMBARI-20681:
--
Status: Patch Available  (was: Open)

> Select Version step of installer: repo URL validation message issues
> 
>
> Key: AMBARI-20681
> URL: https://issues.apache.org/jira/browse/AMBARI-20681
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-20681.patch, repo-url-overflow.jpg
>
>
> # Error message that contains long repository URL overflows the popover block.
> # Popover has no title.
> See [attached|^repo-url-overflow.jpg]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20681) Select Version step of installer: repo URL validation message issues

[Andrii Babiichuk (JIRA)]

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

Andrii Babiichuk updated AMBARI-20681:
--
Attachment: AMBARI-20681.patch

> Select Version step of installer: repo URL validation message issues
> 
>
> Key: AMBARI-20681
> URL: https://issues.apache.org/jira/browse/AMBARI-20681
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-20681.patch, repo-url-overflow.jpg
>
>
> # Error message that contains long repository URL overflows the popover block.
> # Popover has no title.
> See [attached|^repo-url-overflow.jpg]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20680) Response popup: Add copy icon for "Request URL" and "Response Body" sections

[Oleg Nechiporenko (JIRA)]

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

Oleg Nechiporenko updated AMBARI-20680:
---
Attachment: AMBARI-20680.patch

> Response popup: Add copy icon for "Request URL" and "Response Body" sections
> 
>
> Key: AMBARI-20680
> URL: https://issues.apache.org/jira/browse/AMBARI-20680
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 3.0.0
>
> Attachments: AMBARI-20680.patch
>
>
> Ability to copy request url and response body will be helpful. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20681) Select Version step of installer: repo URL validation message issues

[Andrii Babiichuk (JIRA)]

Andrii Babiichuk created AMBARI-20681:
-

 Summary: Select Version step of installer: repo URL validation 
message issues
 Key: AMBARI-20681
 URL: https://issues.apache.org/jira/browse/AMBARI-20681
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 3.0.0
Reporter: Andrii Babiichuk
Assignee: Andrii Babiichuk
 Fix For: 3.0.0
 Attachments: repo-url-overflow.jpg

# Error message that contains long repository URL overflows the popover block.
# Popover has no title.

See [attached|^repo-url-overflow.jpg]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20679) Size of API Response popup should be responsive as per the browser screen size

[Oleg Nechiporenko (JIRA)]

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

Oleg Nechiporenko updated AMBARI-20679:
---
Issue Type: Task  (was: Bug)

> Size of API Response popup should be responsive as per the browser screen size
> --
>
> Key: AMBARI-20679
> URL: https://issues.apache.org/jira/browse/AMBARI-20679
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 3.0.0
>
> Attachments: AMBARI-20679.patch
>
>
> *STR:*
> # Click on Try button for any GET API
> # This will show a pop up with the response of the API
> Width of this popup should be wider and should be in ratio with the size of 
> the browser screen.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20680) Response popup: Add copy icon for "Request URL" and "Response Body" sections

[Oleg Nechiporenko (JIRA)]

Oleg Nechiporenko created AMBARI-20680:
--

 Summary: Response popup: Add copy icon for "Request URL" and 
"Response Body" sections
 Key: AMBARI-20680
 URL: https://issues.apache.org/jira/browse/AMBARI-20680
 Project: Ambari
  Issue Type: Task
  Components: ambari-web
Affects Versions: 3.0.0
Reporter: Oleg Nechiporenko
Assignee: Oleg Nechiporenko
 Fix For: 3.0.0


Ability to copy request url and response body will be helpful. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20679) Size of API Response popup should be responsive as per the browser screen size

[Oleg Nechiporenko (JIRA)]

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

Oleg Nechiporenko updated AMBARI-20679:
---
Attachment: AMBARI-20679.patch

> Size of API Response popup should be responsive as per the browser screen size
> --
>
> Key: AMBARI-20679
> URL: https://issues.apache.org/jira/browse/AMBARI-20679
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 3.0.0
>
> Attachments: AMBARI-20679.patch
>
>
> *STR:*
> # Click on Try button for any GET API
> # This will show a pop up with the response of the API
> Width of this popup should be wider and should be in ratio with the size of 
> the browser screen.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20679) Size of API Response popup should be responsive as per the browser screen size

[Oleg Nechiporenko (JIRA)]

Oleg Nechiporenko created AMBARI-20679:
--

 Summary: Size of API Response popup should be responsive as per 
the browser screen size
 Key: AMBARI-20679
 URL: https://issues.apache.org/jira/browse/AMBARI-20679
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 3.0.0
Reporter: Oleg Nechiporenko
Assignee: Oleg Nechiporenko
 Fix For: 3.0.0


*STR:*
# Click on Try button for any GET API
# This will show a pop up with the response of the API

Width of this popup should be wider and should be in ratio with the size of the 
browser screen.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20678) Complete node name is not shown when node name is larger than 17 characters

[Pallav Kulshreshtha (JIRA)]

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

Pallav Kulshreshtha updated AMBARI-20678:
-
Status: Patch Available  (was: Open)

> Complete node name is not shown when node name is larger than 17 characters
> ---
>
> Key: AMBARI-20678
> URL: https://issues.apache.org/jira/browse/AMBARI-20678
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: Pallav Kulshreshtha
>Assignee: Pallav Kulshreshtha
> Fix For: 2.5.1
>
> Attachments: AMBARI-20678-branch-2_5-2.patch
>
>
> Complete node name is not shown when node name is larger than 17 characters.
> Attaching the screenshot.
> From the usability aspect, its better to show the complete node name may be 
> on the tooltip.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20678) Complete node name is not shown when node name is larger than 17 characters

[Pallav Kulshreshtha (JIRA)]

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

Pallav Kulshreshtha updated AMBARI-20678:
-
Attachment: AMBARI-20678-branch-2_5-2.patch

> Complete node name is not shown when node name is larger than 17 characters
> ---
>
> Key: AMBARI-20678
> URL: https://issues.apache.org/jira/browse/AMBARI-20678
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: Pallav Kulshreshtha
>Assignee: Pallav Kulshreshtha
> Fix For: 2.5.1
>
> Attachments: AMBARI-20678-branch-2_5-2.patch
>
>
> Complete node name is not shown when node name is larger than 17 characters.
> Attaching the screenshot.
> From the usability aspect, its better to show the complete node name may be 
> on the tooltip.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20677) Centering workflows for zoom breaks when multiple tabs exists

[M Madhan Mohan Reddy (JIRA)]

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

M Madhan Mohan Reddy updated AMBARI-20677:
--
Status: Patch Available  (was: In Progress)

> Centering workflows for zoom breaks when multiple tabs exists
> -
>
> Key: AMBARI-20677
> URL: https://issues.apache.org/jira/browse/AMBARI-20677
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.1
>Reporter: M Madhan Mohan Reddy
>Assignee: M Madhan Mohan Reddy
>  Labels: WFD, WFM
> Fix For: 2.5.1
>
> Attachments: AMBARI-20677_trunk.patch
>
>
> If multiple tabs exists, only the tab that got highlighted at the end has the 
> workflow at center. In remaining tabs, workflow is not at the center. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20677) Centering workflows for zoom breaks when multiple tabs exists

[M Madhan Mohan Reddy (JIRA)]

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

M Madhan Mohan Reddy updated AMBARI-20677:
--
Attachment: AMBARI-20677_trunk.patch

> Centering workflows for zoom breaks when multiple tabs exists
> -
>
> Key: AMBARI-20677
> URL: https://issues.apache.org/jira/browse/AMBARI-20677
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.1
>Reporter: M Madhan Mohan Reddy
>Assignee: M Madhan Mohan Reddy
>  Labels: WFD, WFM
> Fix For: 2.5.1
>
> Attachments: AMBARI-20677_trunk.patch
>
>
> If multiple tabs exists, only the tab that got highlighted at the end has the 
> workflow at center. In remaining tabs, workflow is not at the center. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20678) Complete node name is not shown when node name is larger than 17 characters

[Pallav Kulshreshtha (JIRA)]

Pallav Kulshreshtha created AMBARI-20678:


 Summary: Complete node name is not shown when node name is larger 
than 17 characters
 Key: AMBARI-20678
 URL: https://issues.apache.org/jira/browse/AMBARI-20678
 Project: Ambari
  Issue Type: Bug
  Components: ambari-views
Affects Versions: 2.5.0
Reporter: Pallav Kulshreshtha
Assignee: Pallav Kulshreshtha
 Fix For: 2.5.1


Complete node name is not shown when node name is larger than 17 characters.
Attaching the screenshot.
>From the usability aspect, its better to show the complete node name may be on 
>the tooltip.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20677) Centering workflows for zoom breaks when multiple tabs exists

[M Madhan Mohan Reddy (JIRA)]

M Madhan Mohan Reddy created AMBARI-20677:
-

 Summary: Centering workflows for zoom breaks when multiple tabs 
exists
 Key: AMBARI-20677
 URL: https://issues.apache.org/jira/browse/AMBARI-20677
 Project: Ambari
  Issue Type: Bug
  Components: ambari-views
Affects Versions: 2.5.1
Reporter: M Madhan Mohan Reddy
Assignee: M Madhan Mohan Reddy
 Fix For: 2.5.1


If multiple tabs exists, only the tab that got highlighted at the end has the 
workflow at center. In remaining tabs, workflow is not at the center. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20676) User should be able to visualize inherited properties while submitting the workflow

[M Madhan Mohan Reddy (JIRA)]

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

M Madhan Mohan Reddy updated AMBARI-20676:
--
Status: Patch Available  (was: In Progress)

> User should be able to visualize inherited properties while submitting the 
> workflow
> ---
>
> Key: AMBARI-20676
> URL: https://issues.apache.org/jira/browse/AMBARI-20676
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.1
>Reporter: M Madhan Mohan Reddy
>Assignee: M Madhan Mohan Reddy
>  Labels: WFD, WFM
> Fix For: 2.5.1
>
> Attachments: AMBARI-20676_trunk.patch
>
>
> User should be able to visualize inherited properties while submitting the 
> workflow.
> As asked by one of the user (Artem) its better to show inherited properties 
> like “queueName”, “resourceManager”, “namenode” etc which are added by 
> workflow designer by default.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20676) User should be able to visualize inherited properties while submitting the workflow

[M Madhan Mohan Reddy (JIRA)]

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

M Madhan Mohan Reddy updated AMBARI-20676:
--
Attachment: AMBARI-20676_trunk.patch

> User should be able to visualize inherited properties while submitting the 
> workflow
> ---
>
> Key: AMBARI-20676
> URL: https://issues.apache.org/jira/browse/AMBARI-20676
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.1
>Reporter: M Madhan Mohan Reddy
>Assignee: M Madhan Mohan Reddy
>  Labels: WFD, WFM
> Fix For: 2.5.1
>
> Attachments: AMBARI-20676_trunk.patch
>
>
> User should be able to visualize inherited properties while submitting the 
> workflow.
> As asked by one of the user (Artem) its better to show inherited properties 
> like “queueName”, “resourceManager”, “namenode” etc which are added by 
> workflow designer by default.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMBARI-20676) User should be able to visualize inherited properties while submitting the workflow

[M Madhan Mohan Reddy (JIRA)]

M Madhan Mohan Reddy created AMBARI-20676:
-

 Summary: User should be able to visualize inherited properties 
while submitting the workflow
 Key: AMBARI-20676
 URL: https://issues.apache.org/jira/browse/AMBARI-20676
 Project: Ambari
  Issue Type: Bug
  Components: ambari-views
Affects Versions: 2.5.1
Reporter: M Madhan Mohan Reddy
Assignee: M Madhan Mohan Reddy
 Fix For: 2.5.1


User should be able to visualize inherited properties while submitting the 
workflow.
As asked by one of the user (Artem) its better to show inherited properties 
like “queueName”, “resourceManager”, “namenode” etc which are added by workflow 
designer by default.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20366) Tokenize kerberos principal name appearing in kerberos rules in exported blueprint

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20366:


{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12861988/AMBARI-20366.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 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

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

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

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

This message is automatically generated.

> Tokenize kerberos principal name appearing in kerberos rules in exported 
> blueprint
> --
>
> Key: AMBARI-20366
> URL: https://issues.apache.org/jira/browse/AMBARI-20366
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, blueprints
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-20366.patch
>
>
> If blueprint is exported from a kerberos enabled cluster Kerberos rules 
> export principal names which contain cluster name and Realm, this exports 
> existing cluster name and realm name as tokens and replaces those tokens with 
> new values of cluster name and realm during successive cluster deployments.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20660) HiveView2.0 scrolling in query tab does not work properly for a longer query

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20660:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1358 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1358/])
AMBARI-20660. HiveView2.0 scrolling in query tab does not work properly 
(pallavkul: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=c924df6066a16c1161bbf9155963b130825e2e04])
* (edit) contrib/views/hive20/src/main/resources/ui/app/styles/app.scss


> HiveView2.0 scrolling in query tab does not work properly for a longer query
> 
>
> Key: AMBARI-20660
> URL: https://issues.apache.org/jira/browse/AMBARI-20660
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: Pallav Kulshreshtha
>Assignee: Pallav Kulshreshtha
> Fix For: 2.5.1
>
> Attachments: AMBARI-20660-trunk.patch
>
>
> It does not scroll properly for a long query. Also when I press ENTER on the 
> last line and start typing in the new line, it does not show properly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20660) HiveView2.0 scrolling in query tab does not work properly for a longer query

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20660:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #7240 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/7240/])
AMBARI-20660. HiveView2.0 scrolling in query tab does not work properly 
(pallavkul: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=3b25533430a181b6b83f4f1cf665c8f9aceafd4e])
* (edit) contrib/views/hive20/src/main/resources/ui/app/styles/app.scss


> HiveView2.0 scrolling in query tab does not work properly for a longer query
> 
>
> Key: AMBARI-20660
> URL: https://issues.apache.org/jira/browse/AMBARI-20660
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: Pallav Kulshreshtha
>Assignee: Pallav Kulshreshtha
> Fix For: 2.5.1
>
> Attachments: AMBARI-20660-trunk.patch
>
>
> It does not scroll properly for a long query. Also when I press ENTER on the 
> last line and start typing in the new line, it does not show properly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20551) Blueprint export fails if config-type is not mapped to any service after upgrade

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20551:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12861991/AMBARI-20551.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 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

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

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

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

This message is automatically generated.

> Blueprint export fails if config-type is not mapped to any service after 
> upgrade
> 
>
> Key: AMBARI-20551
> URL: https://issues.apache.org/jira/browse/AMBARI-20551
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, blueprints
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-20551.patch
>
>
> 20 Mar 2017 11:39:57,948 ERROR [ambari-client-thread-8726] ReadHandler:99 - 
> Bad request:
> java.lang.IllegalArgumentException: Specified configuration type is not 
> associated with any service: storm-site
> at 
> org.apache.ambari.server.controller.internal.Stack.getServiceForConfigType(Stack.java:494)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor$StackPropertyTypeFilter.isPropertyIncluded(BlueprintConfigurationProcessor.java:2946)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.shouldPropertyBeExcludedForBlueprintExport(BlueprintConfigurationProcessor.java:939)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doFilterPriorToExport(BlueprintConfigurationProcessor.java:439)
> at 
> org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForBlueprintExport(BlueprintConfigurationProcessor.java:416)
> at 
> org.apache.ambari.server.api.query.render.ClusterBlueprintRenderer.createBlueprintResource(ClusterBlueprintRenderer.java:186)
> at 
> org.apache.ambari.server.api.query.render.ClusterBlueprintRenderer.finalizeResult(ClusterBlueprintRenderer.java:141)
> at 
> org.apache.ambari.server.api.query.QueryImpl.getResult(QueryImpl.java:839)
> at 
> org.apache.ambari.server.api.query.QueryImpl.execute(QueryImpl.java:223)
> at 
> org.apache.ambari.server.api.handlers.ReadHandler.handleRequest(ReadHandler.java:77)
> at 
> org.apache.ambari.server.api.services.BaseRequest.process(BaseRequest.java:145)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:126)
> at 
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:90)
> at 
> org.apache.ambari.server.api.services.ClusterService.getCluster(ClusterService.java:91)
> at sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20657) Usability: screen jumps when you scroll down

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20657:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1357 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/1357/])
AMBARI-20657. Usability: screen jumps when you scroll down (pallavkul) 
(pallavkul: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=cfb1bcc7e7d708465da68569abc2c0c765f11fa7])
* (edit) 
contrib/views/hive20/src/main/resources/ui/app/styles/bootstrap-overrides.scss
* (edit) 
contrib/views/hive20/src/main/resources/ui/app/templates/application.hbs
* (edit) contrib/views/hive20/src/main/resources/ui/app/styles/app.scss


> Usability: screen jumps when you scroll down
> 
>
> Key: AMBARI-20657
> URL: https://issues.apache.org/jira/browse/AMBARI-20657
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: Pallav Kulshreshtha
>Assignee: Pallav Kulshreshtha
> Fix For: 2.5.1
>
> Attachments: AMBARI-20657-trunk.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (AMBARI-20660) HiveView2.0 scrolling in query tab does not work properly for a longer query

[Pallav Kulshreshtha (JIRA)]

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

Pallav Kulshreshtha updated AMBARI-20660:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

committed to trunk and branch-2.5

> HiveView2.0 scrolling in query tab does not work properly for a longer query
> 
>
> Key: AMBARI-20660
> URL: https://issues.apache.org/jira/browse/AMBARI-20660
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: Pallav Kulshreshtha
>Assignee: Pallav Kulshreshtha
> Fix For: 2.5.1
>
> Attachments: AMBARI-20660-trunk.patch
>
>
> It does not scroll properly for a long query. Also when I press ENTER on the 
> last line and start typing in the new line, it does not show properly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20657) Usability: screen jumps when you scroll down

[Hudson (JIRA)]

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

Hudson commented on AMBARI-20657:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #7239 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/7239/])
AMBARI-20657. Usability: screen jumps when you scroll down (pallavkul) 
(pallavkul: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=b4fc47f5ea849a5e8fafea0842397fbb1d73272c])
* (edit) 
contrib/views/hive20/src/main/resources/ui/app/templates/application.hbs
* (edit) contrib/views/hive20/src/main/resources/ui/app/styles/app.scss
* (edit) 
contrib/views/hive20/src/main/resources/ui/app/styles/bootstrap-overrides.scss


> Usability: screen jumps when you scroll down
> 
>
> Key: AMBARI-20657
> URL: https://issues.apache.org/jira/browse/AMBARI-20657
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.5.0
>Reporter: Pallav Kulshreshtha
>Assignee: Pallav Kulshreshtha
> Fix For: 2.5.1
>
> Attachments: AMBARI-20657-trunk.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMBARI-20675) Repetitive operation in hdfs.py

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-20675:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12862013/screenshot-1.png
  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/11302//console

This message is automatically generated.

> Repetitive operation in hdfs.py
> ---
>
> Key: AMBARI-20675
> URL: https://issues.apache.org/jira/browse/AMBARI-20675
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: trunk
>Reporter: zhangxiaolu
>Assignee: zhangxiaolu
> Fix For: trunk
>
> Attachments: AMBARI-20675.patch, screenshot-1.png
>
>
> the method of install_snappy in hdfs.py is as follows:
> def install_snappy():
>   import params
>   Directory([params.so_target_dir_x86, params.so_target_dir_x64],
> create_parents = True,
>   )
>   Link(params.so_target_x86,
>to=params.so_src_x86,
>   )
>   Link(params.so_target_x64,
>to=params.so_src_x64,
>   )
>  is repetitived.
> so it's better remove one



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)