[jira] [Created] (AMBARI-16035) Add support for Rolling and Express Upgrade for Ranger Tagsync
Mugdha Varadkar created AMBARI-16035:
Summary: Add support for Rolling and Express Upgrade for Ranger
Tagsync
Key: AMBARI-16035
URL: https://issues.apache.org/jira/browse/AMBARI-16035
Project: Ambari
Issue Type: Task
Components: ambari-server
Reporter: Mugdha Varadkar
Assignee: Mugdha Varadkar
Fix For: 2.4.0
{{RANGER_TAGSYNC}} is a new SLAVE component for RANGER service which needs to
be included in the Rolling and Express Upgrades for stack 2.5 to 2.5 +
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15678) YARN service_check doesn't fail when application status is not reasonable
[ https://issues.apache.org/jira/browse/AMBARI-15678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253460#comment-15253460 ] Masahiro TANAKA commented on AMBARI-15678: -- BTW, why can't I "assign to me" this issue...? > YARN service_check doesn't fail when application status is not reasonable > - > > Key: AMBARI-15678 > URL: https://issues.apache.org/jira/browse/AMBARI-15678 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: trunk > Environment: CentOS 6.5 >Reporter: Masahiro TANAKA > Labels: easyfix, patch-available > Attachments: AMBARI-15678.patch, AMBARI-15678.v2.patch > > > If yarn app state is not state or yarn app finalStatus is not succeeded, YARN > service check should fail. > But in the YARN > [service_check.py|https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/service_check.py#L130], > it doesn't fail because raise statement is in try block and there is only > `pass` in except block. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16004) Hive-view change to show "UNKNOWN" status for saved queries,history queries
[ https://issues.apache.org/jira/browse/AMBARI-16004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pradarttana updated AMBARI-16004: - Status: Patch Available (was: Open) > Hive-view change to show "UNKNOWN" status for saved queries,history queries > > > Key: AMBARI-16004 > URL: https://issues.apache.org/jira/browse/AMBARI-16004 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.1 >Reporter: Pradarttana >Priority: Minor > Labels: patch > Fix For: 2.4.0 > > Attachments: AMBARI-16004_trunk.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > Hive-view should show the "UNKNOWN" status to the queries in saved queries > and history queries. > This is done in order to facilitate the migration of hive queries from hue to > ambari. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16004) Hive-view change to show "UNKNOWN" status for saved queries,history queries
[ https://issues.apache.org/jira/browse/AMBARI-16004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pradarttana updated AMBARI-16004: - Attachment: AMBARI-16004_trunk.patch > Hive-view change to show "UNKNOWN" status for saved queries,history queries > > > Key: AMBARI-16004 > URL: https://issues.apache.org/jira/browse/AMBARI-16004 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.1 >Reporter: Pradarttana >Priority: Minor > Labels: patch > Fix For: 2.4.0 > > Attachments: AMBARI-16004_trunk.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > Hive-view should show the "UNKNOWN" status to the queries in saved queries > and history queries. > This is done in order to facilitate the migration of hive queries from hue to > ambari. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15892) Incorrect (Negative) values are shown for memory metrics
[ https://issues.apache.org/jira/browse/AMBARI-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253432#comment-15253432 ] Hudson commented on AMBARI-15892: - SUCCESS: Integrated in Ambari-branch-2.2 #661 (See [https://builds.apache.org/job/Ambari-branch-2.2/661/]) AMBARI-15892 : Incorrect (Negative) values are shown for memory metrics (avijayan: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=dbde2f9b05c9896bed69e0c1c0306d02f9945c64]) * ambari-server/src/main/resources/stacks/HDP/2.3/services/YARN/YARN_widgets.json * ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog222.java * ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog222Test.java * ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java * ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/widgets.json * ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricConfiguration.java * ambari-server/src/main/resources/stacks/HDP/2.3/services/HBASE/widgets.json * ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/YARN_widgets.json > Incorrect (Negative) values are shown for memory metrics > > > Key: AMBARI-15892 > URL: https://issues.apache.org/jira/browse/AMBARI-15892 > Project: Ambari > Issue Type: Bug >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan >Priority: Blocker > Attachments: AMBARI-15892-2.patch, AMBARI-15892.patch > > > Issue > In the "NameNode HostLoad" graph, the negative values are seen for the > computed metric "Memory Utilization" which goes by the formula : > ( mem_total - (mem_free + mem_cache) ) *100 / mem_total > Bug > AMBARI-15448 changed the way memory metrics are being reported to AMS. This > lead to a double subtraction of mem_cached, thereby leading to a negative > value intermittently. > Fix > Change the widget to : > ( mem_total - mem_free ) *100 / mem_total -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16029) Ambari version history: Create DB table, constraints and sequence id.
[
https://issues.apache.org/jira/browse/AMBARI-16029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253431#comment-15253431
]
Hadoop QA commented on AMBARI-16029:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12800126/rb46545.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6596//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6596//console
This message is automatically generated.
> Ambari version history: Create DB table, constraints and sequence id.
> -
>
> Key: AMBARI-16029
> URL: https://issues.apache.org/jira/browse/AMBARI-16029
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.4.0
>
> Attachments: rb46545.patch
>
>
> Create backing DB table, constraint and sequence id to capture ambari version
> history.
> 1. ambari_version_history table
> 2. primary key constraint
> 3. sequence id
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16018) Namenode RPC widget on Ambari Dashboard shows n/a
[ https://issues.apache.org/jira/browse/AMBARI-16018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253425#comment-15253425 ] Hudson commented on AMBARI-16018: - ABORTED: Integrated in Ambari-trunk-Commit #4710 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4710/]) AMBARI-16018. Namenode RPC widget on Ambari Dashboard shows n/a. (yusaku: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=e508c2244684b590aaafa2547e8a5db61e125ecf]) * ambari-web/app/assets/data/dashboard/services_multi_hosts.json * ambari-web/app/assets/data/dashboard/HDP2/master_components.json * ambari-web/app/assets/data/widget_layouts/HDFS_SUMMARY.json * ambari-web/app/utils/ajax/ajax.js * ambari-web/app/mappers/service_metrics_mapper.js * ambari-web/app/assets/data/services/metrics/hdfs/rpc.json * ambari-web/app/controllers/global/update_controller.js > Namenode RPC widget on Ambari Dashboard shows n/a > - > > Key: AMBARI-16018 > URL: https://issues.apache.org/jira/browse/AMBARI-16018 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.2.2 > > Attachments: AMBARI-16018_2.2.patch, AMBARI-16018_trunk.patch > > > - I did an Ambari 2.4.0 install of HDP 2.4.0 (GA). > - 3 node, hdfs, yarn, zk, ams > - Ambari Web > Dashboard > NameNode RPC widget says 'n/a' > The cluster has been running for close to an hour and these metrics are still > not showing up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15997) After HSI is enabled in install wizard the validation call does not send HSI in the component list of the host_group resulting in validation errors
[ https://issues.apache.org/jira/browse/AMBARI-15997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253426#comment-15253426 ] Hudson commented on AMBARI-15997: - ABORTED: Integrated in Ambari-trunk-Commit #4710 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4710/]) AMBARI-15997. After HSI is enabled in install wizard the validation call (jaimin: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=1c7a284b2f2747670cd8d68292f29930312d3fc1]) * ambari-web/app/views/common/configs/widgets/config_widget_view.js * ambari-web/test/controllers/wizard/step7/assign_master_controller_test.js * ambari-web/app/controllers/wizard/step7/assign_master_controller.js * ambari-web/app/utils/blueprint.js * ambari-web/app/mixins/common/serverValidator.js * ambari-web/app/controllers/main/service/item.js * ambari-web/app/controllers/main/service/info/configs.js * ambari-web/app/controllers/installer.js * ambari-web/app/controllers/wizard/step6_controller.js * ambari-web/app/app.js > After HSI is enabled in install wizard the validation call does not send HSI > in the component list of the host_group resulting in validation errors > --- > > Key: AMBARI-15997 > URL: https://issues.apache.org/jira/browse/AMBARI-15997 > Project: Ambari > Issue Type: Task > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Jaimin D Jetly >Assignee: Jaimin D Jetly > Fix For: 2.4.0 > > Attachments: AMBARI-15997.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16021) Update LogSearch integration to use configuration to obtain credential
[ https://issues.apache.org/jira/browse/AMBARI-16021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253427#comment-15253427 ] Hudson commented on AMBARI-16021: - ABORTED: Integrated in Ambari-trunk-Commit #4710 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4710/]) AMBARI-16021. Update LogSearch integration to use configuration to (rnettleton: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=9c142715019fb028bf9ee5acad5343dc4b0a9d04]) * ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperFactoryImpl.java * ambari-server/src/test/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperImplTest.java * ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperImpl.java > Update LogSearch integration to use configuration to obtain credential > -- > > Key: AMBARI-16021 > URL: https://issues.apache.org/jira/browse/AMBARI-16021 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Robert Nettleton >Assignee: Robert Nettleton >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16021.patch > > > The LogSearch integration components in Ambari needs to obtain the credential > used to connect to the LogSearch service via a configuration mechanism. > In the initial checkins, the integration code used a hard-coded credential. > Now that AMBARI-15884 has implemented the stack and configuration support to > allow a user to configure the credential for the LogSearch Server, the Ambari > Integration layer should use this configuration, defined in: > ambari/ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-admin-properties.xml > This current JIRA tracks the work involved in updating the integration layer > to obtain the credential from the cluster's configuration, and use this > credential to connect to the LogSearch service. > I'm working on a fix for this, and will be submitting a patch shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16026) YARN ATS Should Advertise a Version
[
https://issues.apache.org/jira/browse/AMBARI-16026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253361#comment-15253361
]
Hadoop QA commented on AMBARI-16026:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12800081/AMBARI-16026.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6595//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6595//console
This message is automatically generated.
> YARN ATS Should Advertise a Version
> ---
>
> Key: AMBARI-16026
> URL: https://issues.apache.org/jira/browse/AMBARI-16026
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.0.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16026.patch
>
>
> In YARN's {{metainfo.xml}}, ATS does not have a {{versionAdvertised}}
> element. As a result, the absence of this element causes Ambari to think that
> YARN is not part of the {{hdp-select}} logic and we will never validate that
> it is reporting the correct version on startup.
> However, YARN ATS does have a version and an entry in {{hdp-select}}:
> {code}
> if params.version and check_stack_feature(StackFeature.ROLLING_UPGRADE,
> params.version):
> conf_select.select(params.stack_name, "hadoop", params.version)
> stack_select.select("hadoop-yarn-timelineserver", params.version)
> {code}
> {code}
> [root@c6401 ~]# cat /usr/bin/hdp-select | grep "timeline"
>"hadoop-yarn-timelineserver": "hadoop-yarn",
> "hadoop-yarn-timelineserver"],
> {code}
> This actually causes the ATS component to say it has a {{VERSION_MISMATCH}}
> since upgrading HDP changes it's version when we were not expecting it to:
> {code}
> YARN_CLIENT 2.4.2.0-39 COMPLETE UNKNOWN
> APP_TIMELINE_SERVER 2.4.2.0-39 VERSION_MISMATCH UNSECURED
> ZOOKEEPER_SERVER 2.4.2.0-39 COMPLETEUNSECURED
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-16034) Incremental changes to LogSearch to bring it up to date in the trunk
Don Bosco Durai created AMBARI-16034: Summary: Incremental changes to LogSearch to bring it up to date in the trunk Key: AMBARI-16034 URL: https://issues.apache.org/jira/browse/AMBARI-16034 Project: Ambari Issue Type: Improvement Components: ambari-server Reporter: Don Bosco Durai During the initial LogSearch commit, some changes were not included. This JIRA tracks these addition items. 1. Use standard tokenizer for indexing. 2. Configuring Log level filter for LogFeeder 3. Tab graph clean up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15519) Add Service Wizard with nodes in the maintenance mode
[
https://issues.apache.org/jira/browse/AMBARI-15519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253328#comment-15253328
]
Hadoop QA commented on AMBARI-15519:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12800028/AMBARI-15519.amend.v0.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6594//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6594//console
This message is automatically generated.
> Add Service Wizard with nodes in the maintenance mode
> -
>
> Key: AMBARI-15519
> URL: https://issues.apache.org/jira/browse/AMBARI-15519
> Project: Ambari
> Issue Type: Task
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Zhe (Joe) Wang
>Assignee: Zhe (Joe) Wang
> Fix For: 2.4.0
>
> Attachments: AMBARI-15519.amend.v0.patch, AMBARI-15519.v0.patch
>
>
> On the cluster where some nodes are in the maintenance mode Add Service
> Wizard doesn't track this.
> So, user may select host in the maintenance mode to install some master
> component. And this component won't be installed (only record in the DB will
> be created for it).
> Another situation:
> there is some cluster where all nodes are in the maintenance mode. In this
> case ASW is almost useless. Because all new components won't be installed
> while it works.
> Maybe ASW should track hosts in the maintenance mode and warn user about
> adding components on them (Steps "Assign Masters", "Assign Slaves and
> Clients")? Or just don't allow to do this?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16018) Namenode RPC widget on Ambari Dashboard shows n/a
[ https://issues.apache.org/jira/browse/AMBARI-16018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253293#comment-15253293 ] Hudson commented on AMBARI-16018: - FAILURE: Integrated in Ambari-branch-2.2 #660 (See [https://builds.apache.org/job/Ambari-branch-2.2/660/]) AMBARI-16018. Namenode RPC widget on Ambari Dashboard shows n/a. (yusaku: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=642dd9b6a9c566d05a7b2ebbeee3fae6f60638d3]) * ambari-web/app/mappers/service_metrics_mapper.js * ambari-web/app/assets/data/dashboard/HDP2/master_components.json * ambari-web/app/controllers/global/update_controller.js * ambari-web/app/assets/data/widget_layouts/HDFS_SUMMARY.json * ambari-web/app/assets/data/services/metrics/hdfs/rpc.json * ambari-web/app/utils/ajax/ajax.js * ambari-web/app/assets/data/dashboard/services_multi_hosts.json > Namenode RPC widget on Ambari Dashboard shows n/a > - > > Key: AMBARI-16018 > URL: https://issues.apache.org/jira/browse/AMBARI-16018 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.2.2 > > Attachments: AMBARI-16018_2.2.patch, AMBARI-16018_trunk.patch > > > - I did an Ambari 2.4.0 install of HDP 2.4.0 (GA). > - 3 node, hdfs, yarn, zk, ams > - Ambari Web > Dashboard > NameNode RPC widget says 'n/a' > The cluster has been running for close to an hour and these metrics are still > not showing up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15892) Incorrect (Negative) values are shown for memory metrics
[ https://issues.apache.org/jira/browse/AMBARI-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravindan Vijayan updated AMBARI-15892: --- Resolution: Fixed Status: Resolved (was: Patch Available) Pushed to branch-2.2.2, branch-2.2 and trunk. > Incorrect (Negative) values are shown for memory metrics > > > Key: AMBARI-15892 > URL: https://issues.apache.org/jira/browse/AMBARI-15892 > Project: Ambari > Issue Type: Bug >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan >Priority: Blocker > Attachments: AMBARI-15892-2.patch, AMBARI-15892.patch > > > Issue > In the "NameNode HostLoad" graph, the negative values are seen for the > computed metric "Memory Utilization" which goes by the formula : > ( mem_total - (mem_free + mem_cache) ) *100 / mem_total > Bug > AMBARI-15448 changed the way memory metrics are being reported to AMS. This > lead to a double subtraction of mem_cached, thereby leading to a negative > value intermittently. > Fix > Change the widget to : > ( mem_total - mem_free ) *100 / mem_total -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16033) Update pom.xml versions to 2.2.2 for ambari-2.2.2 release
[ https://issues.apache.org/jira/browse/AMBARI-16033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srimanth Gunturi updated AMBARI-16033: -- Resolution: Fixed Status: Resolved (was: Patch Available) Committed to branch-2.2.2 > Update pom.xml versions to 2.2.2 for ambari-2.2.2 release > - > > Key: AMBARI-16033 > URL: https://issues.apache.org/jira/browse/AMBARI-16033 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Srimanth Gunturi >Assignee: Srimanth Gunturi >Priority: Critical > Fix For: 2.2.2 > > Attachments: AMBARI-16033_branch-2.2.patch > > > For making Ambari-2.2.2 RC's, the pom.xml's have to be updated to show the > correct release version of '2.2.2'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16033) Update pom.xml versions to 2.2.2 for ambari-2.2.2 release
[ https://issues.apache.org/jira/browse/AMBARI-16033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253221#comment-15253221 ] Siddharth Wagle commented on AMBARI-16033: -- +1 > Update pom.xml versions to 2.2.2 for ambari-2.2.2 release > - > > Key: AMBARI-16033 > URL: https://issues.apache.org/jira/browse/AMBARI-16033 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Srimanth Gunturi >Assignee: Srimanth Gunturi >Priority: Critical > Fix For: 2.2.2 > > Attachments: AMBARI-16033_branch-2.2.patch > > > For making Ambari-2.2.2 RC's, the pom.xml's have to be updated to show the > correct release version of '2.2.2'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15892) Incorrect (Negative) values are shown for memory metrics
[ https://issues.apache.org/jira/browse/AMBARI-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253220#comment-15253220 ] Siddharth Wagle commented on AMBARI-15892: -- +1 LGTM > Incorrect (Negative) values are shown for memory metrics > > > Key: AMBARI-15892 > URL: https://issues.apache.org/jira/browse/AMBARI-15892 > Project: Ambari > Issue Type: Bug >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan >Priority: Blocker > Attachments: AMBARI-15892-2.patch, AMBARI-15892.patch > > > Issue > In the "NameNode HostLoad" graph, the negative values are seen for the > computed metric "Memory Utilization" which goes by the formula : > ( mem_total - (mem_free + mem_cache) ) *100 / mem_total > Bug > AMBARI-15448 changed the way memory metrics are being reported to AMS. This > lead to a double subtraction of mem_cached, thereby leading to a negative > value intermittently. > Fix > Change the widget to : > ( mem_total - mem_free ) *100 / mem_total -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15892) Incorrect (Negative) values are shown for memory metrics
[ https://issues.apache.org/jira/browse/AMBARI-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravindan Vijayan updated AMBARI-15892: --- Attachment: (was: AMBARI-15892-2.patch) > Incorrect (Negative) values are shown for memory metrics > > > Key: AMBARI-15892 > URL: https://issues.apache.org/jira/browse/AMBARI-15892 > Project: Ambari > Issue Type: Bug >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan >Priority: Blocker > Attachments: AMBARI-15892-2.patch, AMBARI-15892.patch > > > Issue > In the "NameNode HostLoad" graph, the negative values are seen for the > computed metric "Memory Utilization" which goes by the formula : > ( mem_total - (mem_free + mem_cache) ) *100 / mem_total > Bug > AMBARI-15448 changed the way memory metrics are being reported to AMS. This > lead to a double subtraction of mem_cached, thereby leading to a negative > value intermittently. > Fix > Change the widget to : > ( mem_total - mem_free ) *100 / mem_total -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15892) Incorrect (Negative) values are shown for memory metrics
[ https://issues.apache.org/jira/browse/AMBARI-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravindan Vijayan updated AMBARI-15892: --- Attachment: AMBARI-15892-2.patch > Incorrect (Negative) values are shown for memory metrics > > > Key: AMBARI-15892 > URL: https://issues.apache.org/jira/browse/AMBARI-15892 > Project: Ambari > Issue Type: Bug >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan >Priority: Blocker > Attachments: AMBARI-15892-2.patch, AMBARI-15892.patch > > > Issue > In the "NameNode HostLoad" graph, the negative values are seen for the > computed metric "Memory Utilization" which goes by the formula : > ( mem_total - (mem_free + mem_cache) ) *100 / mem_total > Bug > AMBARI-15448 changed the way memory metrics are being reported to AMS. This > lead to a double subtraction of mem_cached, thereby leading to a negative > value intermittently. > Fix > Change the widget to : > ( mem_total - mem_free ) *100 / mem_total -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16033) Update pom.xml versions to 2.2.2 for ambari-2.2.2 release
[ https://issues.apache.org/jira/browse/AMBARI-16033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srimanth Gunturi updated AMBARI-16033: -- Attachment: AMBARI-16033_branch-2.2.patch > Update pom.xml versions to 2.2.2 for ambari-2.2.2 release > - > > Key: AMBARI-16033 > URL: https://issues.apache.org/jira/browse/AMBARI-16033 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Srimanth Gunturi >Assignee: Srimanth Gunturi >Priority: Critical > Fix For: 2.2.2 > > Attachments: AMBARI-16033_branch-2.2.patch > > > For making Ambari-2.2.2 RC's, the pom.xml's have to be updated to show the > correct release version of '2.2.2'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16033) Update pom.xml versions to 2.2.2 for ambari-2.2.2 release
[ https://issues.apache.org/jira/browse/AMBARI-16033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srimanth Gunturi updated AMBARI-16033: -- Attachment: (was: AMBARI-16033_branch-2.2.patch) > Update pom.xml versions to 2.2.2 for ambari-2.2.2 release > - > > Key: AMBARI-16033 > URL: https://issues.apache.org/jira/browse/AMBARI-16033 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Srimanth Gunturi >Assignee: Srimanth Gunturi >Priority: Critical > Fix For: 2.2.2 > > Attachments: AMBARI-16033_branch-2.2.patch > > > For making Ambari-2.2.2 RC's, the pom.xml's have to be updated to show the > correct release version of '2.2.2'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16033) Update pom.xml versions to 2.2.2 for ambari-2.2.2 release
[
https://issues.apache.org/jira/browse/AMBARI-16033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Srimanth Gunturi updated AMBARI-16033:
--
Attachment: AMBARI-16033_branch-2.2.patch
Attaching patch with pom.xml changes. Was able to successfully compile Ambari:
{noformat}
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Ambari Main ... SUCCESS [2.707s]
[INFO] Apache Ambari Project POM . SUCCESS [0.033s]
[INFO] Ambari Web SUCCESS [22.092s]
[INFO] Ambari Views .. SUCCESS [1.167s]
[INFO] Ambari Admin View . SUCCESS [58.663s]
[INFO] ambari-metrics SUCCESS [0.281s]
[INFO] Ambari Metrics Common . SUCCESS [0.867s]
[INFO] Ambari Metrics Hadoop Sink SUCCESS [1.172s]
[INFO] Ambari Metrics Flume Sink . SUCCESS [0.601s]
[INFO] Ambari Metrics Kafka Sink . SUCCESS [0.634s]
[INFO] Ambari Metrics Storm Sink . SUCCESS [1.744s]
[INFO] Ambari Metrics Collector .. SUCCESS [8.655s]
[INFO] Ambari Metrics Monitor SUCCESS [1.615s]
[INFO] Ambari Metrics Grafana SUCCESS [4.597s]
[INFO] Ambari Metrics Assembly ... SUCCESS [1:15.929s]
[INFO] Ambari Server . SUCCESS [1:46.151s]
[INFO] Ambari Agent .. SUCCESS [2.808s]
[INFO] Ambari Client . SUCCESS [0.034s]
[INFO] Ambari Python Client .. SUCCESS [0.621s]
[INFO] Ambari Groovy Client .. SUCCESS [3.626s]
[INFO] Ambari Shell .. SUCCESS [0.025s]
[INFO] Ambari Python Shell ... SUCCESS [0.660s]
[INFO] Ambari Groovy Shell ... SUCCESS [0.936s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 4:56.312s
[INFO] Finished at: Thu Apr 21 19:24:38 PDT 2016
[INFO] Final Memory: 171M/646M
[INFO]
{noformat}
> Update pom.xml versions to 2.2.2 for ambari-2.2.2 release
> -
>
> Key: AMBARI-16033
> URL: https://issues.apache.org/jira/browse/AMBARI-16033
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Srimanth Gunturi
>Assignee: Srimanth Gunturi
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-16033_branch-2.2.patch
>
>
> For making Ambari-2.2.2 RC's, the pom.xml's have to be updated to show the
> correct release version of '2.2.2'.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16033) Update pom.xml versions to 2.2.2 for ambari-2.2.2 release
[ https://issues.apache.org/jira/browse/AMBARI-16033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srimanth Gunturi updated AMBARI-16033: -- Status: Patch Available (was: Open) > Update pom.xml versions to 2.2.2 for ambari-2.2.2 release > - > > Key: AMBARI-16033 > URL: https://issues.apache.org/jira/browse/AMBARI-16033 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Srimanth Gunturi >Assignee: Srimanth Gunturi >Priority: Critical > Fix For: 2.2.2 > > Attachments: AMBARI-16033_branch-2.2.patch > > > For making Ambari-2.2.2 RC's, the pom.xml's have to be updated to show the > correct release version of '2.2.2'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16033) Update pom.xml versions to 2.2.2 for ambari-2.2.2 release
Srimanth Gunturi created AMBARI-16033: - Summary: Update pom.xml versions to 2.2.2 for ambari-2.2.2 release Key: AMBARI-16033 URL: https://issues.apache.org/jira/browse/AMBARI-16033 Project: Ambari Issue Type: Task Components: ambari-server Affects Versions: 2.2.2 Reporter: Srimanth Gunturi Assignee: Srimanth Gunturi Priority: Critical Fix For: 2.2.2 For making Ambari-2.2.2 RC's, the pom.xml's have to be updated to show the correct release version of '2.2.2'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16032) 1-855-855-3090 Turbotax helpline phone number
Willium desoja created AMBARI-16032: --- Summary: 1-855-855-3090 Turbotax helpline phone number Key: AMBARI-16032 URL: https://issues.apache.org/jira/browse/AMBARI-16032 Project: Ambari Issue Type: Story Components: alerts Affects Versions: branch-windows-dev Environment: windows Reporter: Willium desoja Priority: Minor Fix For: branch-windows-dev Turbotax customer support number, Turbotax support phone number, Turbotax help desk number, Turbotax toll free number, Turbotax customer care number, Turbotax help desk phone number USA,Turbotax Help Phone Number((( $$1-855-855-3090$$)))USA Turbotax Customer Service Number Turbotax Help Phone Number,Turbotax customer service phone number((( $$1-855-855-3090$$))) Turbotax customer support phone number,Turbotax Technical support number,Turbotax Tech support Contact number,Turbotax Tech support Phone number,Turbotax Technical support Phone number,Turbotax customer support number, Turbotax support phone number, Turbotax help desk number, Turbotax toll free number, Turbotax customer care number, Turbotax help desk phone number USA,Turbotax Help Phone Number((( $$1-855-855-3090$$)))USA Turbotax Customer Service Number Turbotax Help Phone Number,Turbotax customer service phone number((( $$1-855-855-3090$$)))Turbotax Tech support Phone number,Turbotax Technical support Phone number,Turbotax customer support number, Turbotax support phone number, Turbotax help desk number, Turbotax toll free number, Turbotax customer care number, Turbotax help desk phone number USA,Turbotax Help Phone Number((( $$1-855-855-3090$$)))USA Turbotax Customer Service Number Turbotax Help Phone Number,Turbotax customer service phone number((( $$1-855-855-3090$$))) Turbotax customer support phone number,Turbotax Technical support number,Turbotax Tech support Contact number,Turbotax Tech support Phone number,Turbotax Technical support Phone number,Turbotax customer support number, Turbotax support phone number, Turbotax help desk number, Turbotax toll free number, Turbotax customer care number, Turbotax help desk phone number USADescribe Turbotax phone number customer service@1-855-855-3090,turbotax support phone number here.Turbotax service Number ((( $$1-855-855-3090$$))) Turbotax support number Turbotax customer service numbr Turbotax tech support number Turbotax Support ((( $$1-855-855-3090$$))) Turbotax technical support phone number Turbotax tech support phone number. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16025) Installer wizard: Starting Services hangs because of LLAP status check.
[ https://issues.apache.org/jira/browse/AMBARI-16025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253138#comment-15253138 ] Hudson commented on AMBARI-16025: - SUCCESS: Integrated in Ambari-trunk-Commit #4709 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4709/]) AMBARI-16025. HiveServerInteractive. Disabling the LLAP app status (sshridhar: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=5534cd5231afaf466775cbffceee252d115dcd5f]) * ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_interactive.py > Installer wizard: Starting Services hangs because of LLAP status check. > --- > > Key: AMBARI-16025 > URL: https://issues.apache.org/jira/browse/AMBARI-16025 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16025.patch > > > - Start deploying 1 host cluster HDFS+YARN+HIVE > - On Customize Services page, enable Interactive Query > - On install, start and Test page, API hangs with ResourceManager and > SNameNode in "QUEUED" status. This is because LLAP status checks take more > than 5 seconds to come back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253136#comment-15253136 ] Hudson commented on AMBARI-15496: - SUCCESS: Integrated in Ambari-trunk-Commit #4709 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4709/]) AMBARI-15496. (afernandez: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=360fcfeb82d45cb0db0ce3e857ab2ac327d7ca99]) * ambari-agent/src/test/python/ambari_agent/TestClusterConfigurationCache.py * ambari-agent/src/main/python/ambari_agent/ClusterConfiguration.py * ambari-agent/src/test/python/ambari_agent/TestAlerts.py > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0, 2.2.1 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > Attachments: AMBARI-15496-2.patch, AMBARI-15496.patch, > AMBARI-15496.patch > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16010) Update HDFS HA alerts definitions during upgrade
[ https://issues.apache.org/jira/browse/AMBARI-16010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253137#comment-15253137 ] Hudson commented on AMBARI-16010: - SUCCESS: Integrated in Ambari-trunk-Commit #4709 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4709/]) AMBARI-16010 Update HDFS HA alerts definitions during upgrade (dsen) (dsen: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=d408e2c808138a23dbf4d038a8ebde9fbd1bb9a4]) * ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog240Test.java * ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java > Update HDFS HA alerts definitions during upgrade > > > Key: AMBARI-16010 > URL: https://issues.apache.org/jira/browse/AMBARI-16010 > Project: Ambari > Issue Type: Bug > Components: alerts, ambari-upgrade >Affects Versions: 2.4.0 >Reporter: Dmytro Sen >Assignee: Dmytro Sen >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16010.patch > > > During upgrade hdfs-site/dfs.nameservices should be replaced with > hdfs-site/dfs.internal.nameservices for all HDFS alerts. > hdfs-site/dfs.nameservices might contain external nameservices -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16029) Ambari version history: Create DB table, constraints and sequence id.
[ https://issues.apache.org/jira/browse/AMBARI-16029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253133#comment-15253133 ] Alejandro Fernandez commented on AMBARI-16029: -- Suggest adding a status and errors columns. > Ambari version history: Create DB table, constraints and sequence id. > - > > Key: AMBARI-16029 > URL: https://issues.apache.org/jira/browse/AMBARI-16029 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Nahappan Somasundaram >Assignee: Nahappan Somasundaram > Fix For: 2.4.0 > > Attachments: rb46545.patch > > > Create backing DB table, constraint and sequence id to capture ambari version > history. > 1. ambari_version_history table > 2. primary key constraint > 3. sequence id -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16030) Ambari version history: Add ambari_version_history table for record keeping history of ambari versions
[
https://issues.apache.org/jira/browse/AMBARI-16030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sumit Mohanty updated AMBARI-16030:
---
Description:
When investigating upgrade issues, information about history about Ambari
versions is missing. Also information about when the Ambari upgrades actually
happened in the past is completely missing.
Instead of relying on this information to be provided, Ambari should record
Ambari upgrade history in Ambari DB.
{noformat}
ambari_version_history
VersionDateNotes
2.2.2.0-102/09/2015 01:00:00Clean Install
2.2.3.0-203/10/2015 01:00:00Upgraded 2.2.2.0-1 ->
2.2.3.0-2
2.4.0.0-306/09/2015 01:00:00Upgraded 2.2.3.0-2 ->
2.4.0.0-3
{noformat}
was:
When investigating customer issues, information about history about Ambari
versions is missing. We rely on this information to be provided in the EAR.
Many times information in the EAR is inaccurate. Also information about when
the Ambari upgrades actually happened in the past is completely missing.
Instead of relying on this information to be provided, Ambari should record
Ambari upgrade history in Ambari DB.
{noformat}
ambari_version_history
VersionDateNotes
2.2.2.0-102/09/2015 01:00:00Clean Install
2.2.3.0-203/10/2015 01:00:00Upgraded 2.2.2.0-1 ->
2.2.3.0-2
2.4.0.0-306/09/2015 01:00:00Upgraded 2.2.3.0-2 ->
2.4.0.0-3
{noformat}
> Ambari version history: Add ambari_version_history table for record keeping
> history of ambari versions
> --
>
> Key: AMBARI-16030
> URL: https://issues.apache.org/jira/browse/AMBARI-16030
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.4.0
>
>
> When investigating upgrade issues, information about history about Ambari
> versions is missing. Also information about when the Ambari upgrades actually
> happened in the past is completely missing.
> Instead of relying on this information to be provided, Ambari should record
> Ambari upgrade history in Ambari DB.
> {noformat}
> ambari_version_history
> VersionDateNotes
> 2.2.2.0-102/09/2015 01:00:00Clean Install
> 2.2.3.0-203/10/2015 01:00:00Upgraded 2.2.2.0-1 ->
> 2.2.3.0-2
> 2.4.0.0-306/09/2015 01:00:00Upgraded 2.2.3.0-2 ->
> 2.4.0.0-3
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16030) Ambari version history: Add ambari_version_history table for record keeping history of ambari versions
[
https://issues.apache.org/jira/browse/AMBARI-16030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253109#comment-15253109
]
Alejandro Fernandez commented on AMBARI-16030:
--
I suggest renaming stop_time to end_time.
What will happen if the user attempts to upgrade from version x to y but it
fails (perhaps it did a partial upgrade of some sort).
Then they discard that particular upgrade, and pick some other version such as
z. In this case, we would want to know that upgrade x->y failed.
If the user does end up deleting ambari-server.log, it would be useful to
collect some error statements in this table, as well as the status.
> Ambari version history: Add ambari_version_history table for record keeping
> history of ambari versions
> --
>
> Key: AMBARI-16030
> URL: https://issues.apache.org/jira/browse/AMBARI-16030
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.4.0
>
>
> When investigating customer issues, information about history about Ambari
> versions is missing. We rely on this information to be provided in the EAR.
> Many times information in the EAR is inaccurate. Also information about when
> the Ambari upgrades actually happened in the past is completely missing.
> Instead of relying on this information to be provided, Ambari should record
> Ambari upgrade history in Ambari DB.
> {noformat}
> ambari_version_history
> VersionDateNotes
> 2.2.2.0-102/09/2015 01:00:00Clean Install
> 2.2.3.0-203/10/2015 01:00:00Upgraded 2.2.2.0-1 ->
> 2.2.3.0-2
> 2.4.0.0-306/09/2015 01:00:00Upgraded 2.2.3.0-2 ->
> 2.4.0.0-3
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16031) Create "/hadoop/llap/local" on each host and disk in Kerberized cluster for LLAP
[
https://issues.apache.org/jira/browse/AMBARI-16031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Fernandez updated AMBARI-16031:
-
Attachment: AMBARI-16031.trunk.patch
> Create "/hadoop/llap/local" on each host and disk in Kerberized cluster for
> LLAP
>
>
> Key: AMBARI-16031
> URL: https://issues.apache.org/jira/browse/AMBARI-16031
> Project: Ambari
> Issue Type: Story
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.4.0
>
> Attachments: AMBARI-16031.trunk.patch
>
>
> - In non-kerberized cluster, hive.llap.daemon.work.dir will point to :
> "$\{yarn.nodemanager.local-dirs\}”
> - In kerberized cluster, we need to create "/hadoop/llap/local" on each node
> and disk and have "hive.llap.daemon.work.dirs" point to it.
> - It's similar to the way yarn.nodemanager.local-dirs is created.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16031) Create "/hadoop/llap/local" on each host and disk in Kerberized cluster for LLAP
[
https://issues.apache.org/jira/browse/AMBARI-16031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Fernandez updated AMBARI-16031:
-
Status: Patch Available (was: Open)
> Create "/hadoop/llap/local" on each host and disk in Kerberized cluster for
> LLAP
>
>
> Key: AMBARI-16031
> URL: https://issues.apache.org/jira/browse/AMBARI-16031
> Project: Ambari
> Issue Type: Story
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.4.0
>
> Attachments: AMBARI-16031.trunk.patch
>
>
> - In non-kerberized cluster, hive.llap.daemon.work.dir will point to :
> "$\{yarn.nodemanager.local-dirs\}”
> - In kerberized cluster, we need to create "/hadoop/llap/local" on each node
> and disk and have "hive.llap.daemon.work.dirs" point to it.
> - It's similar to the way yarn.nodemanager.local-dirs is created.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-16031) Create "/hadoop/llap/local" on each host and disk in Kerberized cluster for LLAP
Alejandro Fernandez created AMBARI-16031:
Summary: Create "/hadoop/llap/local" on each host and disk in
Kerberized cluster for LLAP
Key: AMBARI-16031
URL: https://issues.apache.org/jira/browse/AMBARI-16031
Project: Ambari
Issue Type: Story
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Alejandro Fernandez
Assignee: Alejandro Fernandez
Fix For: 2.4.0
- In non-kerberized cluster, hive.llap.daemon.work.dir will point to :
"$\{yarn.nodemanager.local-dirs\}”
- In kerberized cluster, we need to create "/hadoop/llap/local" on each node
and disk and have "hive.llap.daemon.work.dirs" point to it.
- It's similar to the way yarn.nodemanager.local-dirs is created.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16030) Ambari version history: Add ambari_version_history table for record keeping history of ambari versions
[
https://issues.apache.org/jira/browse/AMBARI-16030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nahappan Somasundaram updated AMBARI-16030:
---
Description:
When investigating customer issues, information about history about Ambari
versions is missing. We rely on this information to be provided in the EAR.
Many times information in the EAR is inaccurate. Also information about when
the Ambari upgrades actually happened in the past is completely missing.
Instead of relying on this information to be provided, Ambari should record
Ambari upgrade history in Ambari DB.
{noformat}
ambari_version_history
VersionDateNotes
2.2.2.0-102/09/2015 01:00:00Clean Install
2.2.3.0-203/10/2015 01:00:00Upgraded 2.2.2.0-1 ->
2.2.3.0-2
2.4.0.0-306/09/2015 01:00:00Upgraded 2.2.3.0-2 ->
2.4.0.0-3
{noformat}
was:
When investigating customer issues, information about history about Ambari
versions is missing. We rely on this information to be provided in the EAR.
Many times information in the EAR is inaccurate. Also information about when
the Ambari upgrades actually happened in the past is completely missing.
Instead of relying on this information to be provided, Ambari should record
Ambari upgrade history in Ambari DB.
{noformat}
ambari_version_history
VersionDateNotes
2.2.2.0-102/09/2015 01:00:00Clean Install
2.2.3.0-203/10/2015 01:00:00Upgraded 2.2.2.0-1 ->
2.2.3.0-2
2.4.0.0-306/09/2015 01:00:00Upgraded 2.2.3.0-2 ->
2.4.0.0-3
{noformat}
cc: [~mahadev] [~smohanty] [~swagle]
Design document:
https://docs.google.com/a/hortonworks.com/document/d/1RcAth8M1oEDOjIZ0qMaCAtatCyz6qdLWuEcZLC4Ejbs/edit?usp=sharing
> Ambari version history: Add ambari_version_history table for record keeping
> history of ambari versions
> --
>
> Key: AMBARI-16030
> URL: https://issues.apache.org/jira/browse/AMBARI-16030
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.4.0
>
>
> When investigating customer issues, information about history about Ambari
> versions is missing. We rely on this information to be provided in the EAR.
> Many times information in the EAR is inaccurate. Also information about when
> the Ambari upgrades actually happened in the past is completely missing.
> Instead of relying on this information to be provided, Ambari should record
> Ambari upgrade history in Ambari DB.
> {noformat}
> ambari_version_history
> VersionDateNotes
> 2.2.2.0-102/09/2015 01:00:00Clean Install
> 2.2.3.0-203/10/2015 01:00:00Upgraded 2.2.2.0-1 ->
> 2.2.3.0-2
> 2.4.0.0-306/09/2015 01:00:00Upgraded 2.2.3.0-2 ->
> 2.4.0.0-3
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-16030) Ambari version history: Add ambari_version_history table for record keeping history of ambari versions
Nahappan Somasundaram created AMBARI-16030:
--
Summary: Ambari version history: Add ambari_version_history table
for record keeping history of ambari versions
Key: AMBARI-16030
URL: https://issues.apache.org/jira/browse/AMBARI-16030
Project: Ambari
Issue Type: Task
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Nahappan Somasundaram
Assignee: Nahappan Somasundaram
Fix For: 2.4.0
When investigating customer issues, information about history about Ambari
versions is missing. We rely on this information to be provided in the EAR.
Many times information in the EAR is inaccurate. Also information about when
the Ambari upgrades actually happened in the past is completely missing.
Instead of relying on this information to be provided, Ambari should record
Ambari upgrade history in Ambari DB.
{noformat}
ambari_version_history
VersionDateNotes
2.2.2.0-102/09/2015 01:00:00Clean Install
2.2.3.0-203/10/2015 01:00:00Upgraded 2.2.2.0-1 ->
2.2.3.0-2
2.4.0.0-306/09/2015 01:00:00Upgraded 2.2.3.0-2 ->
2.4.0.0-3
{noformat}
cc: [~mahadev] [~smohanty] [~swagle]
Design document:
https://docs.google.com/a/hortonworks.com/document/d/1RcAth8M1oEDOjIZ0qMaCAtatCyz6qdLWuEcZLC4Ejbs/edit?usp=sharing
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16029) Ambari version history: Create DB table, constraints and sequence id.
[ https://issues.apache.org/jira/browse/AMBARI-16029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253080#comment-15253080 ] Alejandro Fernandez commented on AMBARI-16029: -- [~smnaha], what is the need for this new table? > Ambari version history: Create DB table, constraints and sequence id. > - > > Key: AMBARI-16029 > URL: https://issues.apache.org/jira/browse/AMBARI-16029 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Nahappan Somasundaram >Assignee: Nahappan Somasundaram > Fix For: 2.4.0 > > Attachments: rb46545.patch > > > Create backing DB table, constraint and sequence id to capture ambari version > history. > 1. ambari_version_history table > 2. primary key constraint > 3. sequence id -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15724) Integrate Version Registration in Select Stack Page
[ https://issues.apache.org/jira/browse/AMBARI-15724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253063#comment-15253063 ] Xi Wang commented on AMBARI-15724: -- Uploaded version6.patch including all Register Version page functions. > Integrate Version Registration in Select Stack Page > --- > > Key: AMBARI-15724 > URL: https://issues.apache.org/jira/browse/AMBARI-15724 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Xi Wang >Assignee: Xi Wang >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-15724.patch, AMBARI-15724.patch, version1.patch, > version2.patch, version3.patch, version4.patch, version5.patch, version6.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15724) Integrate Version Registration in Select Stack Page
[ https://issues.apache.org/jira/browse/AMBARI-15724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xi Wang updated AMBARI-15724: - Attachment: version6.patch > Integrate Version Registration in Select Stack Page > --- > > Key: AMBARI-15724 > URL: https://issues.apache.org/jira/browse/AMBARI-15724 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Xi Wang >Assignee: Xi Wang >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-15724.patch, AMBARI-15724.patch, version1.patch, > version2.patch, version3.patch, version4.patch, version5.patch, version6.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16018) Namenode RPC widget on Ambari Dashboard shows n/a
[ https://issues.apache.org/jira/browse/AMBARI-16018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yusaku Sako updated AMBARI-16018: - Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk, branch-2.2, and branch-2.2.2. > Namenode RPC widget on Ambari Dashboard shows n/a > - > > Key: AMBARI-16018 > URL: https://issues.apache.org/jira/browse/AMBARI-16018 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.2.2 > > Attachments: AMBARI-16018_2.2.patch, AMBARI-16018_trunk.patch > > > - I did an Ambari 2.4.0 install of HDP 2.4.0 (GA). > - 3 node, hdfs, yarn, zk, ams > - Ambari Web > Dashboard > NameNode RPC widget says 'n/a' > The cluster has been running for close to an hour and these metrics are still > not showing up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16018) Namenode RPC widget on Ambari Dashboard shows n/a
[ https://issues.apache.org/jira/browse/AMBARI-16018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253052#comment-15253052 ] Yusaku Sako commented on AMBARI-16018: -- +1 for the patch. > Namenode RPC widget on Ambari Dashboard shows n/a > - > > Key: AMBARI-16018 > URL: https://issues.apache.org/jira/browse/AMBARI-16018 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.2.2 > > Attachments: AMBARI-16018_2.2.patch, AMBARI-16018_trunk.patch > > > - I did an Ambari 2.4.0 install of HDP 2.4.0 (GA). > - 3 node, hdfs, yarn, zk, ams > - Ambari Web > Dashboard > NameNode RPC widget says 'n/a' > The cluster has been running for close to an hour and these metrics are still > not showing up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16021) Update LogSearch integration to use configuration to obtain credential
[ https://issues.apache.org/jira/browse/AMBARI-16021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Nettleton updated AMBARI-16021: -- Resolution: Fixed Status: Resolved (was: Patch Available) Patch merged to trunk > Update LogSearch integration to use configuration to obtain credential > -- > > Key: AMBARI-16021 > URL: https://issues.apache.org/jira/browse/AMBARI-16021 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Robert Nettleton >Assignee: Robert Nettleton >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16021.patch > > > The LogSearch integration components in Ambari needs to obtain the credential > used to connect to the LogSearch service via a configuration mechanism. > In the initial checkins, the integration code used a hard-coded credential. > Now that AMBARI-15884 has implemented the stack and configuration support to > allow a user to configure the credential for the LogSearch Server, the Ambari > Integration layer should use this configuration, defined in: > ambari/ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-admin-properties.xml > This current JIRA tracks the work involved in updating the integration layer > to obtain the credential from the cluster's configuration, and use this > credential to connect to the LogSearch service. > I'm working on a fix for this, and will be submitting a patch shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16029) Ambari version history: Create DB table, constraints and sequence id.
[ https://issues.apache.org/jira/browse/AMBARI-16029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nahappan Somasundaram updated AMBARI-16029: --- Status: Patch Available (was: Open) > Ambari version history: Create DB table, constraints and sequence id. > - > > Key: AMBARI-16029 > URL: https://issues.apache.org/jira/browse/AMBARI-16029 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Nahappan Somasundaram >Assignee: Nahappan Somasundaram > Fix For: 2.4.0 > > Attachments: rb46545.patch > > > Create backing DB table, constraint and sequence id to capture ambari version > history. > 1. ambari_version_history table > 2. primary key constraint > 3. sequence id -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16029) Ambari version history: Create DB table, constraints and sequence id.
[ https://issues.apache.org/jira/browse/AMBARI-16029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nahappan Somasundaram updated AMBARI-16029: --- Attachment: rb46545.patch > Ambari version history: Create DB table, constraints and sequence id. > - > > Key: AMBARI-16029 > URL: https://issues.apache.org/jira/browse/AMBARI-16029 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Nahappan Somasundaram >Assignee: Nahappan Somasundaram > Fix For: 2.4.0 > > Attachments: rb46545.patch > > > Create backing DB table, constraint and sequence id to capture ambari version > history. > 1. ambari_version_history table > 2. primary key constraint > 3. sequence id -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16019) Validation popup: Proceed Anyway button is disabled
[ https://issues.apache.org/jira/browse/AMBARI-16019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252980#comment-15252980 ] Hudson commented on AMBARI-16019: - FAILURE: Integrated in Ambari-branch-2.2 #659 (See [https://builds.apache.org/job/Ambari-branch-2.2/659/]) AMBARI-16019. Validation popup: Proceed Anyway button is disabled (hiveww: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=a520256fb3af19d6a668c13881e227d603953898]) * ambari-web/app/mixins/common/serverValidator.js > Validation popup: Proceed Anyway button is disabled > --- > > Key: AMBARI-16019 > URL: https://issues.apache.org/jira/browse/AMBARI-16019 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-16019.patch, Screen Shot 2016-04-20 at 1.19.39 > PM.png, disdown.png, proceedDisabled.png > > > # Change configurations that will make validation API return validation issue > with atleatst one issue of any type except 'WARN' type. > # This will display popup to user with 'Cancel' and 'Proceed Anyway' button > 'Proceed Anyway' button is disabled. > One of possible ways to reproduce > STR: > # Install ambari 2.0.2 with HDP 2.2.8.0-3150 > # Add Ranger > # Turn on security (ambari-server setup-security) > # Kerberise cluster > # Upgrade ambari to 2.2.2.0 > # Try to add some services (e.g SmartSense) > Result: "Proceed Anyway" button is disabled on popup after "Configure > services" step -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16009) Regenerating keytabs on re-imaged hosts results in error during 'Creating Principals'
[
https://issues.apache.org/jira/browse/AMBARI-16009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252981#comment-15252981
]
Hudson commented on AMBARI-16009:
-
FAILURE: Integrated in Ambari-branch-2.2 #659 (See
[https://builds.apache.org/job/Ambari-branch-2.2/659/])
AMBARI-16009. Regenerating keytabs on re-imaged hosts results in error (rlevas:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=7e7f3b0a8d60895ef52002ff54daff846602d52e])
*
ambari-server/src/test/java/org/apache/ambari/server/serveraction/kerberos/MITKerberosOperationHandlerTest.java
*
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/MITKerberosOperationHandler.java
> Regenerating keytabs on re-imaged hosts results in error during 'Creating
> Principals'
> -
>
> Key: AMBARI-16009
> URL: https://issues.apache.org/jira/browse/AMBARI-16009
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Blocker
> Labels: kerberos
> Fix For: 2.2.2
>
> Attachments: AMBARI-16009_branch-2.2_01.patch,
> AMBARI-16009_trunk_01.patch
>
>
> We had a 1600 unsecured cluster initially, from which 700 nodes were
> destroyed. Though Ambari-server knew of 1600 hosts, only 900 were
> heartbeating. At this point we secured the cluster and everything was good.
> Then we brought back the 700 hosts, which started heartbeating with
> ambari-server.
> At this point we did 'Regenerate Keytabs' which failed at the 'Create
> Principals' step (image attached), as it was trying to re-create principal
> which is already existing with kadmin, and with ambari-server.
> *Create Principals*
> Stderr:
> {noformat}
> 2016-04-21 01:28:52,985 - Failed to create or update principal,
> HTTP/host1.example@example.com - Failed to create service principal for
> HTTP/host1.example@example.com
> STDOUT: Authenticating as principal admin/admin with password.
> STDERR: WARNING: no policy specified for HTTP/host1.example@example.com;
> defaulting to no policy
> add_principal: Principal or policy already exists while creating
> "HTTP/host1.example@example.com".
> {noformat}
> Stdout:
> {noformat}
> 2016-04-21 01:27:32,400 - Processing identities...
> 2016-04-21 01:28:29,874 - Processing principal,
> HTTP/host1.example@example.com
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15892) Incorrect (Negative) values are shown for memory metrics
[
https://issues.apache.org/jira/browse/AMBARI-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252973#comment-15252973
]
Hadoop QA commented on AMBARI-15892:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12800031/AMBARI-15892-2.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6592//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6592//console
This message is automatically generated.
> Incorrect (Negative) values are shown for memory metrics
>
>
> Key: AMBARI-15892
> URL: https://issues.apache.org/jira/browse/AMBARI-15892
> Project: Ambari
> Issue Type: Bug
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Blocker
> Attachments: AMBARI-15892-2.patch, AMBARI-15892.patch
>
>
> Issue
> In the "NameNode HostLoad" graph, the negative values are seen for the
> computed metric "Memory Utilization" which goes by the formula :
> ( mem_total - (mem_free + mem_cache) ) *100 / mem_total
> Bug
> AMBARI-15448 changed the way memory metrics are being reported to AMS. This
> lead to a double subtraction of mem_cached, thereby leading to a negative
> value intermittently.
> Fix
> Change the widget to :
> ( mem_total - mem_free ) *100 / mem_total
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15997) After HSI is enabled in install wizard the validation call does not send HSI in the component list of the host_group resulting in validation errors
[ https://issues.apache.org/jira/browse/AMBARI-15997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-15997: Resolution: Fixed Status: Resolved (was: Patch Available) Received +1 on ReviewBoard. Patch committed to trunk. > After HSI is enabled in install wizard the validation call does not send HSI > in the component list of the host_group resulting in validation errors > --- > > Key: AMBARI-15997 > URL: https://issues.apache.org/jira/browse/AMBARI-15997 > Project: Ambari > Issue Type: Task > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Jaimin D Jetly >Assignee: Jaimin D Jetly > Fix For: 2.4.0 > > Attachments: AMBARI-15997.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15979) Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.
[ https://issues.apache.org/jira/browse/AMBARI-15979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-15979: Status: Open (was: Patch Available) > Provide UI validation for widget_name and description fields in Create/Edit > Widget pop-up. > -- > > Key: AMBARI-15979 > URL: https://issues.apache.org/jira/browse/AMBARI-15979 > Project: Ambari > Issue Type: Improvement > Components: ambari-web >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-15979-April-20.patch, > AMBARI-15979-inlineError.patch, AMBARI-15979-topError.patch, > AMBARI-15979.patch, create_widget_button_location.tiff, > create_widget_step1.tiff, create_widget_step2.tiff, create_widget_step3.tiff, > fixed_ErrorOnTop_character_validation_for_description.tiff, > fixed_ErrorOnTop_character_validation_for_name.tiff, > fixed_ErrorOnTop_length_validation_for_description.tiff, > fixed_ErrorOnTop_length_validation_for_name.tiff, > fixed_InlineError_character_validation_for_description.tiff, > fixed_InlineError_character_validation_for_name.tiff, > fixed_InlineError_length_validation_for_description.tiff, > fixed_InlineError_length_validation_for_name.tiff, > fixed_characters_allowed_for_description.tiff, > fixed_characters_allowed_for_name.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_description.tiff, > original_length_validation_for_name.tiff > > > The UI validation at present checks only the length of the user input for > widget_name and description fields. All characters are allowed to be stored > in the database through them. A more strict UI validation that limits the > type of characters entered for these fields will provide a good first line of > defense. > Steps to reproduce: > 1. Make sure you have Ambari Metrics service installed on your cluster. > 2. On the Dashboard, select any service that makes use of Ambari Metrics, say > HDFS. > 3. In the "Metrics" section, click the "Actions" button in the top-right > corner, and select "Create a new widget" option from the drop-down. > (attachment: create_widget_button_location.tiff) > 4. Create widget pop-up is displayed. > 5. On Step-1, select any type for the widget and click "Next". (attachment: > create_widget_step1.tiff) > 6. On Step-2, select any valid metrics parameter and click "Next". > (attachment: create_widget_step2.tiff) > 7. On Step-3, for widget_name and description fields, you can enter any > character. No validation is present to check the contents. The only > validation present checks the length of the input text. > (attachments: > create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_name.tiff, > original_length_validation_for_description.tiff ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15979) Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.
[ https://issues.apache.org/jira/browse/AMBARI-15979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-15979: Status: Patch Available (was: Open) > Provide UI validation for widget_name and description fields in Create/Edit > Widget pop-up. > -- > > Key: AMBARI-15979 > URL: https://issues.apache.org/jira/browse/AMBARI-15979 > Project: Ambari > Issue Type: Improvement > Components: ambari-web >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-15979-April-20.patch, > AMBARI-15979-inlineError.patch, AMBARI-15979-topError.patch, > AMBARI-15979.patch, create_widget_button_location.tiff, > create_widget_step1.tiff, create_widget_step2.tiff, create_widget_step3.tiff, > fixed_ErrorOnTop_character_validation_for_description.tiff, > fixed_ErrorOnTop_character_validation_for_name.tiff, > fixed_ErrorOnTop_length_validation_for_description.tiff, > fixed_ErrorOnTop_length_validation_for_name.tiff, > fixed_InlineError_character_validation_for_description.tiff, > fixed_InlineError_character_validation_for_name.tiff, > fixed_InlineError_length_validation_for_description.tiff, > fixed_InlineError_length_validation_for_name.tiff, > fixed_characters_allowed_for_description.tiff, > fixed_characters_allowed_for_name.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_description.tiff, > original_length_validation_for_name.tiff > > > The UI validation at present checks only the length of the user input for > widget_name and description fields. All characters are allowed to be stored > in the database through them. A more strict UI validation that limits the > type of characters entered for these fields will provide a good first line of > defense. > Steps to reproduce: > 1. Make sure you have Ambari Metrics service installed on your cluster. > 2. On the Dashboard, select any service that makes use of Ambari Metrics, say > HDFS. > 3. In the "Metrics" section, click the "Actions" button in the top-right > corner, and select "Create a new widget" option from the drop-down. > (attachment: create_widget_button_location.tiff) > 4. Create widget pop-up is displayed. > 5. On Step-1, select any type for the widget and click "Next". (attachment: > create_widget_step1.tiff) > 6. On Step-2, select any valid metrics parameter and click "Next". > (attachment: create_widget_step2.tiff) > 7. On Step-3, for widget_name and description fields, you can enter any > character. No validation is present to check the contents. The only > validation present checks the length of the input text. > (attachments: > create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_name.tiff, > original_length_validation_for_description.tiff ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15979) Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.
[ https://issues.apache.org/jira/browse/AMBARI-15979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-15979: Attachment: AMBARI-15979-inlineError.patch > Provide UI validation for widget_name and description fields in Create/Edit > Widget pop-up. > -- > > Key: AMBARI-15979 > URL: https://issues.apache.org/jira/browse/AMBARI-15979 > Project: Ambari > Issue Type: Improvement > Components: ambari-web >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-15979-April-20.patch, > AMBARI-15979-inlineError.patch, AMBARI-15979-topError.patch, > AMBARI-15979.patch, create_widget_button_location.tiff, > create_widget_step1.tiff, create_widget_step2.tiff, create_widget_step3.tiff, > fixed_ErrorOnTop_character_validation_for_description.tiff, > fixed_ErrorOnTop_character_validation_for_name.tiff, > fixed_ErrorOnTop_length_validation_for_description.tiff, > fixed_ErrorOnTop_length_validation_for_name.tiff, > fixed_InlineError_character_validation_for_description.tiff, > fixed_InlineError_character_validation_for_name.tiff, > fixed_InlineError_length_validation_for_description.tiff, > fixed_InlineError_length_validation_for_name.tiff, > fixed_characters_allowed_for_description.tiff, > fixed_characters_allowed_for_name.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_description.tiff, > original_length_validation_for_name.tiff > > > The UI validation at present checks only the length of the user input for > widget_name and description fields. All characters are allowed to be stored > in the database through them. A more strict UI validation that limits the > type of characters entered for these fields will provide a good first line of > defense. > Steps to reproduce: > 1. Make sure you have Ambari Metrics service installed on your cluster. > 2. On the Dashboard, select any service that makes use of Ambari Metrics, say > HDFS. > 3. In the "Metrics" section, click the "Actions" button in the top-right > corner, and select "Create a new widget" option from the drop-down. > (attachment: create_widget_button_location.tiff) > 4. Create widget pop-up is displayed. > 5. On Step-1, select any type for the widget and click "Next". (attachment: > create_widget_step1.tiff) > 6. On Step-2, select any valid metrics parameter and click "Next". > (attachment: create_widget_step2.tiff) > 7. On Step-3, for widget_name and description fields, you can enter any > character. No validation is present to check the contents. The only > validation present checks the length of the input text. > (attachments: > create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_name.tiff, > original_length_validation_for_description.tiff ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15979) Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.
[ https://issues.apache.org/jira/browse/AMBARI-15979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-15979: Attachment: fixed_characters_allowed_for_description.tiff fixed_characters_allowed_for_name.tiff fixed_ErrorOnTop_character_validation_for_description.tiff fixed_ErrorOnTop_character_validation_for_name.tiff fixed_ErrorOnTop_length_validation_for_description.tiff fixed_ErrorOnTop_length_validation_for_name.tiff fixed_InlineError_character_validation_for_description.tiff fixed_InlineError_character_validation_for_name.tiff fixed_InlineError_length_validation_for_description.tiff fixed_InlineError_length_validation_for_name.tiff > Provide UI validation for widget_name and description fields in Create/Edit > Widget pop-up. > -- > > Key: AMBARI-15979 > URL: https://issues.apache.org/jira/browse/AMBARI-15979 > Project: Ambari > Issue Type: Improvement > Components: ambari-web >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-15979-April-20.patch, > AMBARI-15979-topError.patch, AMBARI-15979.patch, > create_widget_button_location.tiff, create_widget_step1.tiff, > create_widget_step2.tiff, create_widget_step3.tiff, > fixed_ErrorOnTop_character_validation_for_description.tiff, > fixed_ErrorOnTop_character_validation_for_name.tiff, > fixed_ErrorOnTop_length_validation_for_description.tiff, > fixed_ErrorOnTop_length_validation_for_name.tiff, > fixed_InlineError_character_validation_for_description.tiff, > fixed_InlineError_character_validation_for_name.tiff, > fixed_InlineError_length_validation_for_description.tiff, > fixed_InlineError_length_validation_for_name.tiff, > fixed_characters_allowed_for_description.tiff, > fixed_characters_allowed_for_name.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_description.tiff, > original_length_validation_for_name.tiff > > > The UI validation at present checks only the length of the user input for > widget_name and description fields. All characters are allowed to be stored > in the database through them. A more strict UI validation that limits the > type of characters entered for these fields will provide a good first line of > defense. > Steps to reproduce: > 1. Make sure you have Ambari Metrics service installed on your cluster. > 2. On the Dashboard, select any service that makes use of Ambari Metrics, say > HDFS. > 3. In the "Metrics" section, click the "Actions" button in the top-right > corner, and select "Create a new widget" option from the drop-down. > (attachment: create_widget_button_location.tiff) > 4. Create widget pop-up is displayed. > 5. On Step-1, select any type for the widget and click "Next". (attachment: > create_widget_step1.tiff) > 6. On Step-2, select any valid metrics parameter and click "Next". > (attachment: create_widget_step2.tiff) > 7. On Step-3, for widget_name and description fields, you can enter any > character. No validation is present to check the contents. The only > validation present checks the length of the input text. > (attachments: > create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_name.tiff, > original_length_validation_for_description.tiff ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15979) Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.
[ https://issues.apache.org/jira/browse/AMBARI-15979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-15979: Attachment: AMBARI-15979-topError.patch > Provide UI validation for widget_name and description fields in Create/Edit > Widget pop-up. > -- > > Key: AMBARI-15979 > URL: https://issues.apache.org/jira/browse/AMBARI-15979 > Project: Ambari > Issue Type: Improvement > Components: ambari-web >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-15979-April-20.patch, > AMBARI-15979-topError.patch, AMBARI-15979.patch, > create_widget_button_location.tiff, create_widget_step1.tiff, > create_widget_step2.tiff, create_widget_step3.tiff, > fixed_ErrorOnTop_character_validation_for_description.tiff, > fixed_ErrorOnTop_character_validation_for_name.tiff, > fixed_ErrorOnTop_length_validation_for_description.tiff, > fixed_ErrorOnTop_length_validation_for_name.tiff, > fixed_InlineError_character_validation_for_description.tiff, > fixed_InlineError_character_validation_for_name.tiff, > fixed_InlineError_length_validation_for_description.tiff, > fixed_InlineError_length_validation_for_name.tiff, > fixed_characters_allowed_for_description.tiff, > fixed_characters_allowed_for_name.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_description.tiff, > original_length_validation_for_name.tiff > > > The UI validation at present checks only the length of the user input for > widget_name and description fields. All characters are allowed to be stored > in the database through them. A more strict UI validation that limits the > type of characters entered for these fields will provide a good first line of > defense. > Steps to reproduce: > 1. Make sure you have Ambari Metrics service installed on your cluster. > 2. On the Dashboard, select any service that makes use of Ambari Metrics, say > HDFS. > 3. In the "Metrics" section, click the "Actions" button in the top-right > corner, and select "Create a new widget" option from the drop-down. > (attachment: create_widget_button_location.tiff) > 4. Create widget pop-up is displayed. > 5. On Step-1, select any type for the widget and click "Next". (attachment: > create_widget_step1.tiff) > 6. On Step-2, select any valid metrics parameter and click "Next". > (attachment: create_widget_step2.tiff) > 7. On Step-3, for widget_name and description fields, you can enter any > character. No validation is present to check the contents. The only > validation present checks the length of the input text. > (attachments: > create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_name.tiff, > original_length_validation_for_description.tiff ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15979) Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.
[ https://issues.apache.org/jira/browse/AMBARI-15979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-15979: Attachment: (was: fixed_character_validation_for_name.tiff) > Provide UI validation for widget_name and description fields in Create/Edit > Widget pop-up. > -- > > Key: AMBARI-15979 > URL: https://issues.apache.org/jira/browse/AMBARI-15979 > Project: Ambari > Issue Type: Improvement > Components: ambari-web >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-15979-April-20.patch, AMBARI-15979.patch, > create_widget_button_location.tiff, create_widget_step1.tiff, > create_widget_step2.tiff, create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_description.tiff, > original_length_validation_for_name.tiff > > > The UI validation at present checks only the length of the user input for > widget_name and description fields. All characters are allowed to be stored > in the database through them. A more strict UI validation that limits the > type of characters entered for these fields will provide a good first line of > defense. > Steps to reproduce: > 1. Make sure you have Ambari Metrics service installed on your cluster. > 2. On the Dashboard, select any service that makes use of Ambari Metrics, say > HDFS. > 3. In the "Metrics" section, click the "Actions" button in the top-right > corner, and select "Create a new widget" option from the drop-down. > (attachment: create_widget_button_location.tiff) > 4. Create widget pop-up is displayed. > 5. On Step-1, select any type for the widget and click "Next". (attachment: > create_widget_step1.tiff) > 6. On Step-2, select any valid metrics parameter and click "Next". > (attachment: create_widget_step2.tiff) > 7. On Step-3, for widget_name and description fields, you can enter any > character. No validation is present to check the contents. The only > validation present checks the length of the input text. > (attachments: > create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_name.tiff, > original_length_validation_for_description.tiff ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15979) Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.
[ https://issues.apache.org/jira/browse/AMBARI-15979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-15979: Attachment: (was: fixed_length_validation_for_description.tiff) > Provide UI validation for widget_name and description fields in Create/Edit > Widget pop-up. > -- > > Key: AMBARI-15979 > URL: https://issues.apache.org/jira/browse/AMBARI-15979 > Project: Ambari > Issue Type: Improvement > Components: ambari-web >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-15979-April-20.patch, AMBARI-15979.patch, > create_widget_button_location.tiff, create_widget_step1.tiff, > create_widget_step2.tiff, create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_description.tiff, > original_length_validation_for_name.tiff > > > The UI validation at present checks only the length of the user input for > widget_name and description fields. All characters are allowed to be stored > in the database through them. A more strict UI validation that limits the > type of characters entered for these fields will provide a good first line of > defense. > Steps to reproduce: > 1. Make sure you have Ambari Metrics service installed on your cluster. > 2. On the Dashboard, select any service that makes use of Ambari Metrics, say > HDFS. > 3. In the "Metrics" section, click the "Actions" button in the top-right > corner, and select "Create a new widget" option from the drop-down. > (attachment: create_widget_button_location.tiff) > 4. Create widget pop-up is displayed. > 5. On Step-1, select any type for the widget and click "Next". (attachment: > create_widget_step1.tiff) > 6. On Step-2, select any valid metrics parameter and click "Next". > (attachment: create_widget_step2.tiff) > 7. On Step-3, for widget_name and description fields, you can enter any > character. No validation is present to check the contents. The only > validation present checks the length of the input text. > (attachments: > create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_name.tiff, > original_length_validation_for_description.tiff ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15979) Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.
[ https://issues.apache.org/jira/browse/AMBARI-15979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-15979: Attachment: (was: fixed_characters_allowed_for_description.tiff) > Provide UI validation for widget_name and description fields in Create/Edit > Widget pop-up. > -- > > Key: AMBARI-15979 > URL: https://issues.apache.org/jira/browse/AMBARI-15979 > Project: Ambari > Issue Type: Improvement > Components: ambari-web >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-15979-April-20.patch, AMBARI-15979.patch, > create_widget_button_location.tiff, create_widget_step1.tiff, > create_widget_step2.tiff, create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_description.tiff, > original_length_validation_for_name.tiff > > > The UI validation at present checks only the length of the user input for > widget_name and description fields. All characters are allowed to be stored > in the database through them. A more strict UI validation that limits the > type of characters entered for these fields will provide a good first line of > defense. > Steps to reproduce: > 1. Make sure you have Ambari Metrics service installed on your cluster. > 2. On the Dashboard, select any service that makes use of Ambari Metrics, say > HDFS. > 3. In the "Metrics" section, click the "Actions" button in the top-right > corner, and select "Create a new widget" option from the drop-down. > (attachment: create_widget_button_location.tiff) > 4. Create widget pop-up is displayed. > 5. On Step-1, select any type for the widget and click "Next". (attachment: > create_widget_step1.tiff) > 6. On Step-2, select any valid metrics parameter and click "Next". > (attachment: create_widget_step2.tiff) > 7. On Step-3, for widget_name and description fields, you can enter any > character. No validation is present to check the contents. The only > validation present checks the length of the input text. > (attachments: > create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_name.tiff, > original_length_validation_for_description.tiff ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15979) Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.
[ https://issues.apache.org/jira/browse/AMBARI-15979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-15979: Attachment: (was: fixed_character_validation_for_description.tiff) > Provide UI validation for widget_name and description fields in Create/Edit > Widget pop-up. > -- > > Key: AMBARI-15979 > URL: https://issues.apache.org/jira/browse/AMBARI-15979 > Project: Ambari > Issue Type: Improvement > Components: ambari-web >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-15979-April-20.patch, AMBARI-15979.patch, > create_widget_button_location.tiff, create_widget_step1.tiff, > create_widget_step2.tiff, create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_description.tiff, > original_length_validation_for_name.tiff > > > The UI validation at present checks only the length of the user input for > widget_name and description fields. All characters are allowed to be stored > in the database through them. A more strict UI validation that limits the > type of characters entered for these fields will provide a good first line of > defense. > Steps to reproduce: > 1. Make sure you have Ambari Metrics service installed on your cluster. > 2. On the Dashboard, select any service that makes use of Ambari Metrics, say > HDFS. > 3. In the "Metrics" section, click the "Actions" button in the top-right > corner, and select "Create a new widget" option from the drop-down. > (attachment: create_widget_button_location.tiff) > 4. Create widget pop-up is displayed. > 5. On Step-1, select any type for the widget and click "Next". (attachment: > create_widget_step1.tiff) > 6. On Step-2, select any valid metrics parameter and click "Next". > (attachment: create_widget_step2.tiff) > 7. On Step-3, for widget_name and description fields, you can enter any > character. No validation is present to check the contents. The only > validation present checks the length of the input text. > (attachments: > create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_name.tiff, > original_length_validation_for_description.tiff ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15979) Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.
[ https://issues.apache.org/jira/browse/AMBARI-15979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-15979: Attachment: (was: fixed_characters_allowed_for_name.tiff) > Provide UI validation for widget_name and description fields in Create/Edit > Widget pop-up. > -- > > Key: AMBARI-15979 > URL: https://issues.apache.org/jira/browse/AMBARI-15979 > Project: Ambari > Issue Type: Improvement > Components: ambari-web >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-15979-April-20.patch, AMBARI-15979.patch, > create_widget_button_location.tiff, create_widget_step1.tiff, > create_widget_step2.tiff, create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_description.tiff, > original_length_validation_for_name.tiff > > > The UI validation at present checks only the length of the user input for > widget_name and description fields. All characters are allowed to be stored > in the database through them. A more strict UI validation that limits the > type of characters entered for these fields will provide a good first line of > defense. > Steps to reproduce: > 1. Make sure you have Ambari Metrics service installed on your cluster. > 2. On the Dashboard, select any service that makes use of Ambari Metrics, say > HDFS. > 3. In the "Metrics" section, click the "Actions" button in the top-right > corner, and select "Create a new widget" option from the drop-down. > (attachment: create_widget_button_location.tiff) > 4. Create widget pop-up is displayed. > 5. On Step-1, select any type for the widget and click "Next". (attachment: > create_widget_step1.tiff) > 6. On Step-2, select any valid metrics parameter and click "Next". > (attachment: create_widget_step2.tiff) > 7. On Step-3, for widget_name and description fields, you can enter any > character. No validation is present to check the contents. The only > validation present checks the length of the input text. > (attachments: > create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_name.tiff, > original_length_validation_for_description.tiff ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15979) Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.
[ https://issues.apache.org/jira/browse/AMBARI-15979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-15979: Attachment: (was: fixed_length_validation_for_name.tiff) > Provide UI validation for widget_name and description fields in Create/Edit > Widget pop-up. > -- > > Key: AMBARI-15979 > URL: https://issues.apache.org/jira/browse/AMBARI-15979 > Project: Ambari > Issue Type: Improvement > Components: ambari-web >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-15979-April-20.patch, AMBARI-15979.patch, > create_widget_button_location.tiff, create_widget_step1.tiff, > create_widget_step2.tiff, create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_description.tiff, > original_length_validation_for_name.tiff > > > The UI validation at present checks only the length of the user input for > widget_name and description fields. All characters are allowed to be stored > in the database through them. A more strict UI validation that limits the > type of characters entered for these fields will provide a good first line of > defense. > Steps to reproduce: > 1. Make sure you have Ambari Metrics service installed on your cluster. > 2. On the Dashboard, select any service that makes use of Ambari Metrics, say > HDFS. > 3. In the "Metrics" section, click the "Actions" button in the top-right > corner, and select "Create a new widget" option from the drop-down. > (attachment: create_widget_button_location.tiff) > 4. Create widget pop-up is displayed. > 5. On Step-1, select any type for the widget and click "Next". (attachment: > create_widget_step1.tiff) > 6. On Step-2, select any valid metrics parameter and click "Next". > (attachment: create_widget_step2.tiff) > 7. On Step-3, for widget_name and description fields, you can enter any > character. No validation is present to check the contents. The only > validation present checks the length of the input text. > (attachments: > create_widget_step3.tiff, > original_characters_allowed_for_name_and_description.tiff, > original_length_validation_for_name.tiff, > original_length_validation_for_description.tiff ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16029) Ambari version history: Create DB table, constraints and sequence id.
Nahappan Somasundaram created AMBARI-16029: -- Summary: Ambari version history: Create DB table, constraints and sequence id. Key: AMBARI-16029 URL: https://issues.apache.org/jira/browse/AMBARI-16029 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.4.0 Reporter: Nahappan Somasundaram Assignee: Nahappan Somasundaram Fix For: 2.4.0 Create backing DB table, constraint and sequence id to capture ambari version history. 1. ambari_version_history table 2. primary key constraint 3. sequence id -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15997) After HSI is enabled in install wizard the validation call does not send HSI in the component list of the host_group resulting in validation errors
[ https://issues.apache.org/jira/browse/AMBARI-15997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-15997: Status: Patch Available (was: Open) Verified manually that the patch fixes the issue Verified that ambari-web unit tests works with the patch: 27517 tests complete (31 seconds) 154 tests pending > After HSI is enabled in install wizard the validation call does not send HSI > in the component list of the host_group resulting in validation errors > --- > > Key: AMBARI-15997 > URL: https://issues.apache.org/jira/browse/AMBARI-15997 > Project: Ambari > Issue Type: Task > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Jaimin D Jetly >Assignee: Jaimin D Jetly > Fix For: 2.4.0 > > Attachments: AMBARI-15997.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15997) After HSI is enabled in install wizard the validation call does not send HSI in the component list of the host_group resulting in validation errors
[ https://issues.apache.org/jira/browse/AMBARI-15997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-15997: Attachment: AMBARI-15997.patch > After HSI is enabled in install wizard the validation call does not send HSI > in the component list of the host_group resulting in validation errors > --- > > Key: AMBARI-15997 > URL: https://issues.apache.org/jira/browse/AMBARI-15997 > Project: Ambari > Issue Type: Task > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Jaimin D Jetly >Assignee: Jaimin D Jetly > Fix For: 2.4.0 > > Attachments: AMBARI-15997.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16028) Namenode marked as INITIAL standby could potentially never start if other namenode is down
[
https://issues.apache.org/jira/browse/AMBARI-16028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-16028:
---
Description:
*Issue:*
# During Namenode HA blueprint deployment, we configure the name nodes to start
in active/standby mode based on the following properties
{code}
{
"hadoop-env": {
"properties" : {
"dfs_ha_initial_namenode_active" : "host1",
"dfs_ha_initial_namenode_standby" : "host2”
}
}
}
{code}
# The current logic is to always bootstrap the name node marked as standby.
# This will lead to the Namenode marked as Standby to never start under the
following situation
- Cluster is deployed successfully
- Both name nodes are stopped
- Start the name node marked as standby. Namenode will never start.
- This is because the standby name node will try to bootstrap again.
- However to bootstrap a name node an active name node is required. Based on
the HDFS logic the first step done when bootstrapping is to connect to the
Active Namenode.
- Also there is no need to bootstrap here as the name node should already be
bootstrapped and should come back up as “Active"
was:
*Issue:*
# During Namenode HA blueprint deployment, we configure the name nodes to start
in active/standby mode based on the following properties
{code}
{
"hadoop-env": {
"properties" : {
"dfs_ha_initial_namenode_active" :
"jay-msft-1.c.pramod-thangali.internal",
"dfs_ha_initial_namenode_standby" :
"jay-msft-2.c.pramod-thangali.internal”
}
}
}
{code}
# The current logic is to always bootstrap the name node marked as standby.
# This will lead to the Namenode marked as Standby to never start under the
following situation
- Cluster is deployed successfully
- Both name nodes are stopped
- Start the name node marked as standby. Namenode will never start.
- This is because the standby name node will try to bootstrap again.
- However to bootstrap a name node an active name node is required. Based on
the HDFS logic the first step done when bootstrapping is to connect to the
Active Namenode.
- Also there is no need to bootstrap here as the name node should already be
bootstrapped and should come back up as “Active"
> Namenode marked as INITIAL standby could potentially never start if other
> namenode is down
> --
>
> Key: AMBARI-16028
> URL: https://issues.apache.org/jira/browse/AMBARI-16028
> Project: Ambari
> Issue Type: Bug
> Components: stacks
>Affects Versions: 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16028-trunk.patch
>
>
> *Issue:*
> # During Namenode HA blueprint deployment, we configure the name nodes to
> start in active/standby mode based on the following properties
> {code}
> {
> "hadoop-env": {
> "properties" : {
> "dfs_ha_initial_namenode_active" : "host1",
> "dfs_ha_initial_namenode_standby" : "host2”
> }
> }
> }
> {code}
> # The current logic is to always bootstrap the name node marked as standby.
> # This will lead to the Namenode marked as Standby to never start under the
> following situation
> - Cluster is deployed successfully
> - Both name nodes are stopped
> - Start the name node marked as standby. Namenode will never start.
> - This is because the standby name node will try to bootstrap again.
> - However to bootstrap a name node an active name node is required. Based on
> the HDFS logic the first step done when bootstrapping is to connect to the
> Active Namenode.
> - Also there is no need to bootstrap here as the name node should already be
> bootstrapped and should come back up as “Active"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16028) Namenode marked as INITIAL standby could potentially never start if other namenode is down
[
https://issues.apache.org/jira/browse/AMBARI-16028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-16028:
---
Attachment: AMBARI-16028-trunk.patch
> Namenode marked as INITIAL standby could potentially never start if other
> namenode is down
> --
>
> Key: AMBARI-16028
> URL: https://issues.apache.org/jira/browse/AMBARI-16028
> Project: Ambari
> Issue Type: Bug
> Components: stacks
>Affects Versions: 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16028-trunk.patch
>
>
> *Issue:*
> # During Namenode HA blueprint deployment, we configure the name nodes to
> start in active/standby mode based on the following properties
> {code}
> {
> "hadoop-env": {
> "properties" : {
> "dfs_ha_initial_namenode_active" :
> "jay-msft-1.c.pramod-thangali.internal",
> "dfs_ha_initial_namenode_standby" :
> "jay-msft-2.c.pramod-thangali.internal”
> }
> }
> }
> {code}
> # The current logic is to always bootstrap the name node marked as standby.
> # This will lead to the Namenode marked as Standby to never start under the
> following situation
> - Cluster is deployed successfully
> - Both name nodes are stopped
> - Start the name node marked as standby. Namenode will never start.
> - This is because the standby name node will try to bootstrap again.
> - However to bootstrap a name node an active name node is required. Based on
> the HDFS logic the first step done when bootstrapping is to connect to the
> Active Namenode.
> - Also there is no need to bootstrap here as the name node should already be
> bootstrapped and should come back up as “Active"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16028) Namenode marked as INITIAL standby could potentially never start if other namenode is down
[
https://issues.apache.org/jira/browse/AMBARI-16028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-16028:
---
Status: Patch Available (was: In Progress)
> Namenode marked as INITIAL standby could potentially never start if other
> namenode is down
> --
>
> Key: AMBARI-16028
> URL: https://issues.apache.org/jira/browse/AMBARI-16028
> Project: Ambari
> Issue Type: Bug
> Components: stacks
>Affects Versions: 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16028-trunk.patch
>
>
> *Issue:*
> # During Namenode HA blueprint deployment, we configure the name nodes to
> start in active/standby mode based on the following properties
> {code}
> {
> "hadoop-env": {
> "properties" : {
> "dfs_ha_initial_namenode_active" :
> "jay-msft-1.c.pramod-thangali.internal",
> "dfs_ha_initial_namenode_standby" :
> "jay-msft-2.c.pramod-thangali.internal”
> }
> }
> }
> {code}
> # The current logic is to always bootstrap the name node marked as standby.
> # This will lead to the Namenode marked as Standby to never start under the
> following situation
> - Cluster is deployed successfully
> - Both name nodes are stopped
> - Start the name node marked as standby. Namenode will never start.
> - This is because the standby name node will try to bootstrap again.
> - However to bootstrap a name node an active name node is required. Based on
> the HDFS logic the first step done when bootstrapping is to connect to the
> Active Namenode.
> - Also there is no need to bootstrap here as the name node should already be
> bootstrapped and should come back up as “Active"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (AMBARI-16028) Namenode marked as INITIAL standby could potentially never start if other namenode is down
[
https://issues.apache.org/jira/browse/AMBARI-16028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya reassigned AMBARI-16028:
--
Assignee: Jayush Luniya
> Namenode marked as INITIAL standby could potentially never start if other
> namenode is down
> --
>
> Key: AMBARI-16028
> URL: https://issues.apache.org/jira/browse/AMBARI-16028
> Project: Ambari
> Issue Type: Bug
> Components: stacks
>Affects Versions: 2.2.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.4.0
>
>
> *Issue:*
> # During Namenode HA blueprint deployment, we configure the name nodes to
> start in active/standby mode based on the following properties
> {code}
> {
> "hadoop-env": {
> "properties" : {
> "dfs_ha_initial_namenode_active" :
> "jay-msft-1.c.pramod-thangali.internal",
> "dfs_ha_initial_namenode_standby" :
> "jay-msft-2.c.pramod-thangali.internal”
> }
> }
> }
> {code}
> # The current logic is to always bootstrap the name node marked as standby.
> # This will lead to the Namenode marked as Standby to never start under the
> following situation
> - Cluster is deployed successfully
> - Both name nodes are stopped
> - Start the name node marked as standby. Namenode will never start.
> - This is because the standby name node will try to bootstrap again.
> - However to bootstrap a name node an active name node is required. Based on
> the HDFS logic the first step done when bootstrapping is to connect to the
> Active Namenode.
> - Also there is no need to bootstrap here as the name node should already be
> bootstrapped and should come back up as “Active"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16028) Namenode marked as INITIAL standby could potentially never start if other namenode is down
[
https://issues.apache.org/jira/browse/AMBARI-16028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252864#comment-15252864
]
Jayush Luniya commented on AMBARI-16028:
*Fix:*
# The fix is to maintain a bootstrap marker file (similar to the way we keep a
name node formatted marker file)
# In the INITIAL_START phase (during cluster deployment) we will always force
bootstrap so as to enforce the name node marked as Standby to wait for the
Active name node to come up, bootstrap and start in STANDBY node.
# Once we are out of INITIAL_START phase, we will bootstrap only if this name
node has not been bootstrapped in the past.
# We will not enforce bootstrapping only in the INITIAL_START phase because
there is a possibility during cluster deployment that both name nodes don’t
start and hence bootstrapping out of INITIAL_START phase would be required in
this case.
> Namenode marked as INITIAL standby could potentially never start if other
> namenode is down
> --
>
> Key: AMBARI-16028
> URL: https://issues.apache.org/jira/browse/AMBARI-16028
> Project: Ambari
> Issue Type: Bug
> Components: stacks
>Affects Versions: 2.2.0
>Reporter: Jayush Luniya
>Priority: Critical
> Fix For: 2.4.0
>
>
> *Issue:*
> # During Namenode HA blueprint deployment, we configure the name nodes to
> start in active/standby mode based on the following properties
> {code}
> {
> "hadoop-env": {
> "properties" : {
> "dfs_ha_initial_namenode_active" :
> "jay-msft-1.c.pramod-thangali.internal",
> "dfs_ha_initial_namenode_standby" :
> "jay-msft-2.c.pramod-thangali.internal”
> }
> }
> }
> {code}
> # The current logic is to always bootstrap the name node marked as standby.
> # This will lead to the Namenode marked as Standby to never start under the
> following situation
> - Cluster is deployed successfully
> - Both name nodes are stopped
> - Start the name node marked as standby. Namenode will never start.
> - This is because the standby name node will try to bootstrap again.
> - However to bootstrap a name node an active name node is required. Based on
> the HDFS logic the first step done when bootstrapping is to connect to the
> Active Namenode.
> - Also there is no need to bootstrap here as the name node should already be
> bootstrapped and should come back up as “Active"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-16028) Namenode marked as INITIAL standby could potentially never start if other namenode is down
Jayush Luniya created AMBARI-16028:
--
Summary: Namenode marked as INITIAL standby could potentially
never start if other namenode is down
Key: AMBARI-16028
URL: https://issues.apache.org/jira/browse/AMBARI-16028
Project: Ambari
Issue Type: Bug
Components: stacks
Affects Versions: 2.2.0
Reporter: Jayush Luniya
Priority: Critical
Fix For: 2.4.0
*Issue:*
# During Namenode HA blueprint deployment, we configure the name nodes to start
in active/standby mode based on the following properties
{code}
{
"hadoop-env": {
"properties" : {
"dfs_ha_initial_namenode_active" :
"jay-msft-1.c.pramod-thangali.internal",
"dfs_ha_initial_namenode_standby" :
"jay-msft-2.c.pramod-thangali.internal”
}
}
}
{code}
# The current logic is to always bootstrap the name node marked as standby.
# This will lead to the Namenode marked as Standby to never start under the
following situation
- Cluster is deployed successfully
- Both name nodes are stopped
- Start the name node marked as standby. Namenode will never start.
- This is because the standby name node will try to bootstrap again.
- However to bootstrap a name node an active name node is required. Based on
the HDFS logic the first step done when bootstrapping is to connect to the
Active Namenode.
- Also there is no need to bootstrap here as the name node should already be
bootstrapped and should come back up as “Active"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16019) Validation popup: Proceed Anyway button is disabled
[ https://issues.apache.org/jira/browse/AMBARI-16019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252849#comment-15252849 ] Hudson commented on AMBARI-16019: - SUCCESS: Integrated in Ambari-trunk-Commit #4708 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4708/]) AMBARI-16019. Validation popup: Proceed Anyway button is disabled (hiveww: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=c3a72eb3079538b0ff6caabdf3fa78e43046cc27]) * ambari-web/app/mixins/common/serverValidator.js > Validation popup: Proceed Anyway button is disabled > --- > > Key: AMBARI-16019 > URL: https://issues.apache.org/jira/browse/AMBARI-16019 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.2.2 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-16019.patch, Screen Shot 2016-04-20 at 1.19.39 > PM.png, disdown.png, proceedDisabled.png > > > # Change configurations that will make validation API return validation issue > with atleatst one issue of any type except 'WARN' type. > # This will display popup to user with 'Cancel' and 'Proceed Anyway' button > 'Proceed Anyway' button is disabled. > One of possible ways to reproduce > STR: > # Install ambari 2.0.2 with HDP 2.2.8.0-3150 > # Add Ranger > # Turn on security (ambari-server setup-security) > # Kerberise cluster > # Upgrade ambari to 2.2.2.0 > # Try to add some services (e.g SmartSense) > Result: "Proceed Anyway" button is disabled on popup after "Configure > services" step -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16003) JS error on hosts filtering when filter for same field is used twice
[
https://issues.apache.org/jira/browse/AMBARI-16003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252848#comment-15252848
]
Hudson commented on AMBARI-16003:
-
SUCCESS: Integrated in Ambari-trunk-Commit #4708 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/4708/])
AMBARI-16003: JS error on hosts filtering when filter for same field is (rzang:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=04f7d5c3efe8af2c43824f32c1ce04d2ddc6cee2])
* ambari-web/app/views/main/host/combo_search_box.js
> JS error on hosts filtering when filter for same field is used twice
>
>
> Key: AMBARI-16003
> URL: https://issues.apache.org/jira/browse/AMBARI-16003
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.4.0
>
> Attachments: AMBARI-16003.patch
>
>
> * Open hosts page
> * Do filtering "Cores: 3" and "Cores: 1" in the same time
> * JS-error appears: {{Uncaught TypeError: value.charAt is not a function}}
> {code}
> getComparisonType: function (value) {
> var comparisonChar = value.charAt(0);
> var result = 'EQUAL';
> if (isNaN(comparisonChar)) {
> switch (comparisonChar) {
> case '>':
> result = 'MORE';
> break;
> case '<':
> result = 'LESS';
> break;
> }
> }
> return result;
> },
> {code}
> UI expects that {{value}} is a string and not an array of strings.
> Same issue is when filtering is done by RAM-field
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16010) Update HDFS HA alerts definitions during upgrade
[ https://issues.apache.org/jira/browse/AMBARI-16010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmytro Sen updated AMBARI-16010: Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk > Update HDFS HA alerts definitions during upgrade > > > Key: AMBARI-16010 > URL: https://issues.apache.org/jira/browse/AMBARI-16010 > Project: Ambari > Issue Type: Bug > Components: alerts, ambari-upgrade >Affects Versions: 2.4.0 >Reporter: Dmytro Sen >Assignee: Dmytro Sen >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16010.patch > > > During upgrade hdfs-site/dfs.nameservices should be replaced with > hdfs-site/dfs.internal.nameservices for all HDFS alerts. > hdfs-site/dfs.nameservices might contain external nameservices -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15657) HAWQ config should not allow multiple Master/Segment directories
[
https://issues.apache.org/jira/browse/AMBARI-15657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252792#comment-15252792
]
Lav Jain commented on AMBARI-15657:
---
Hi [~aantonenko], Thanks a lot for letting us know.
The rationale was that if some configuration change results in an ERROR, the
user should not be allowed to proceed. Otherwise, the validation should trigger
a WARN (instead of ERROR). Currently, there is no distinction between the two.
> HAWQ config should not allow multiple Master/Segment directories
>
>
> Key: AMBARI-15657
> URL: https://issues.apache.org/jira/browse/AMBARI-15657
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Affects Versions: trunk, 2.2.0
>Reporter: Lav Jain
>Assignee: Lav Jain
>Priority: Minor
> Attachments: AMBARI-15657.branch22.patch, AMBARI-15657.patch,
> screenshot.png
>
>
> User can add multiple space delimited directories, but after installation, it
> shows a comma in between. however, only first directory goes into effect,
> that too with a comma in the end.
> {code}
> [pivotal@ip-10-32-36-213 etc]$ cat hawq-site.xml
>
> hawq_master_directory
> /data/hawq/master,/data/hawq/master2
>
>
> hawq_segment_directory
> /data/hawq/segment,/data/hawq/segment2
>
> [pivotal@ip-10-32-36-213 etc]$ ls -l /data/hawq
> drwxr-xr-x 3 root root 4096 Mar 12 01:00 master,
> drwxr-xr-x 3 root root 4096 Mar 12 01:00 segment,
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-16027) Kafka upgrade from HDP 2.2 to HDP 2.3 is breaking
Sriharsha Chintalapani created AMBARI-16027: --- Summary: Kafka upgrade from HDP 2.2 to HDP 2.3 is breaking Key: AMBARI-16027 URL: https://issues.apache.org/jira/browse/AMBARI-16027 Project: Ambari Issue Type: Bug Reporter: Sriharsha Chintalapani Assignee: Sriharsha Chintalapani Priority: Blocker Fix For: ambari-2.4.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16026) YARN ATS Should Advertise a Version
[
https://issues.apache.org/jira/browse/AMBARI-16026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-16026:
-
Status: Patch Available (was: Open)
> YARN ATS Should Advertise a Version
> ---
>
> Key: AMBARI-16026
> URL: https://issues.apache.org/jira/browse/AMBARI-16026
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.0.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16026.patch
>
>
> In YARN's {{metainfo.xml}}, ATS does not have a {{versionAdvertised}}
> element. As a result, the absence of this element causes Ambari to think that
> YARN is not part of the {{hdp-select}} logic and we will never validate that
> it is reporting the correct version on startup.
> However, YARN ATS does have a version and an entry in {{hdp-select}}:
> {code}
> if params.version and check_stack_feature(StackFeature.ROLLING_UPGRADE,
> params.version):
> conf_select.select(params.stack_name, "hadoop", params.version)
> stack_select.select("hadoop-yarn-timelineserver", params.version)
> {code}
> {code}
> [root@c6401 ~]# cat /usr/bin/hdp-select | grep "timeline"
>"hadoop-yarn-timelineserver": "hadoop-yarn",
> "hadoop-yarn-timelineserver"],
> {code}
> This actually causes the ATS component to say it has a {{VERSION_MISMATCH}}
> since upgrading HDP changes it's version when we were not expecting it to:
> {code}
> YARN_CLIENT 2.4.2.0-39 COMPLETE UNKNOWN
> APP_TIMELINE_SERVER 2.4.2.0-39 VERSION_MISMATCH UNSECURED
> ZOOKEEPER_SERVER 2.4.2.0-39 COMPLETEUNSECURED
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16026) YARN ATS Should Advertise a Version
[
https://issues.apache.org/jira/browse/AMBARI-16026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-16026:
-
Attachment: AMBARI-16026.patch
> YARN ATS Should Advertise a Version
> ---
>
> Key: AMBARI-16026
> URL: https://issues.apache.org/jira/browse/AMBARI-16026
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.0.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16026.patch
>
>
> In YARN's {{metainfo.xml}}, ATS does not have a {{versionAdvertised}}
> element. As a result, the absence of this element causes Ambari to think that
> YARN is not part of the {{hdp-select}} logic and we will never validate that
> it is reporting the correct version on startup.
> However, YARN ATS does have a version and an entry in {{hdp-select}}:
> {code}
> if params.version and check_stack_feature(StackFeature.ROLLING_UPGRADE,
> params.version):
> conf_select.select(params.stack_name, "hadoop", params.version)
> stack_select.select("hadoop-yarn-timelineserver", params.version)
> {code}
> {code}
> [root@c6401 ~]# cat /usr/bin/hdp-select | grep "timeline"
>"hadoop-yarn-timelineserver": "hadoop-yarn",
> "hadoop-yarn-timelineserver"],
> {code}
> This actually causes the ATS component to say it has a {{VERSION_MISMATCH}}
> since upgrading HDP changes it's version when we were not expecting it to:
> {code}
> YARN_CLIENT 2.4.2.0-39 COMPLETE UNKNOWN
> APP_TIMELINE_SERVER 2.4.2.0-39 VERSION_MISMATCH UNSECURED
> ZOOKEEPER_SERVER 2.4.2.0-39 COMPLETEUNSECURED
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15933) Views work for Hue to Views Migration Tool
[
https://issues.apache.org/jira/browse/AMBARI-15933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252724#comment-15252724
]
Hadoop QA commented on AMBARI-15933:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12800033/AMBARI-15933.2_trunk.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
contrib/views/hueambarimigration.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6590//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6590//console
This message is automatically generated.
> Views work for Hue to Views Migration Tool
> --
>
> Key: AMBARI-15933
> URL: https://issues.apache.org/jira/browse/AMBARI-15933
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-views
>Affects Versions: ambari-2.4.0
> Environment: Hue is only supported on Linux (non HDInsight), hence
> whever Hue was previously supported on we must be able to migrate.
>Reporter: Pradarttana
>Priority: Critical
> Labels: ambari-views, dev-test, scoping
> Fix For: ambari-2.4.0
>
> Attachments: AMBARI-15933.1_trunk.patch, AMBARI-15933.2_trunk.patch,
> AMBARI-15933_trunk.patch
>
> Original Estimate: 840h
> Remaining Estimate: 840h
>
> Problem:
Hue is planned to be deprecated, hence need a way for customers to
> migrate over artifacts from Hue to the equivalent Views.
> Link to the PRD Doc
> https://docs.google.com/a/hortonworks.com/document/d/13m-Ioxamq4oF3yYHASkVjJ3mhpRlKuM12BCgCAJaap4/edit?usp=sharing
> This RMP is a clone specifically to cover the work on the Views Framework
> side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-16026) YARN ATS Should Advertise a Version
Jonathan Hurley created AMBARI-16026:
Summary: YARN ATS Should Advertise a Version
Key: AMBARI-16026
URL: https://issues.apache.org/jira/browse/AMBARI-16026
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.0.0
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
Priority: Critical
Fix For: 2.4.0
In YARN's {{metainfo.xml}}, ATS does not have a {{versionAdvertised}} element.
As a result, the absence of this element causes Ambari to think that YARN is
not part of the {{hdp-select}} logic and we will never validate that it is
reporting the correct version on startup.
However, YARN ATS does have a version and an entry in {{hdp-select}}:
{code}
if params.version and check_stack_feature(StackFeature.ROLLING_UPGRADE,
params.version):
conf_select.select(params.stack_name, "hadoop", params.version)
stack_select.select("hadoop-yarn-timelineserver", params.version)
{code}
{code}
[root@c6401 ~]# cat /usr/bin/hdp-select | grep "timeline"
"hadoop-yarn-timelineserver": "hadoop-yarn",
"hadoop-yarn-timelineserver"],
{code}
This actually causes the ATS component to say it has a {{VERSION_MISMATCH}}
since upgrading HDP changes it's version when we were not expecting it to:
{code}
YARN_CLIENT 2.4.2.0-39 COMPLETE UNKNOWN
APP_TIMELINE_SERVER 2.4.2.0-39 VERSION_MISMATCH UNSECURED
ZOOKEEPER_SERVER 2.4.2.0-39 COMPLETEUNSECURED
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16025) Installer wizard: Starting Services hangs because of LLAP status check.
[ https://issues.apache.org/jira/browse/AMBARI-16025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar updated AMBARI-16025: - Priority: Critical (was: Major) > Installer wizard: Starting Services hangs because of LLAP status check. > --- > > Key: AMBARI-16025 > URL: https://issues.apache.org/jira/browse/AMBARI-16025 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-16025.patch > > > - Start deploying 1 host cluster HDFS+YARN+HIVE > - On Customize Services page, enable Interactive Query > - On install, start and Test page, API hangs with ResourceManager and > SNameNode in "QUEUED" status. This is because LLAP status checks take more > than 5 seconds to come back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16025) Installer wizard: Starting Services hangs because of LLAP status check.
[ https://issues.apache.org/jira/browse/AMBARI-16025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252702#comment-15252702 ] Swapan Shridhar commented on AMBARI-16025: -- Disabled LLAP status check in Hive status() call. > Installer wizard: Starting Services hangs because of LLAP status check. > --- > > Key: AMBARI-16025 > URL: https://issues.apache.org/jira/browse/AMBARI-16025 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > Attachments: AMBARI-16025.patch > > > - Start deploying 1 host cluster HDFS+YARN+HIVE > - On Customize Services page, enable Interactive Query > - On install, start and Test page, API hangs with ResourceManager and > SNameNode in "QUEUED" status. This is because LLAP status checks take more > than 5 seconds to come back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16025) Installer wizard: Starting Services hangs because of LLAP status check.
[ https://issues.apache.org/jira/browse/AMBARI-16025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar updated AMBARI-16025: - Status: Patch Available (was: Open) > Installer wizard: Starting Services hangs because of LLAP status check. > --- > > Key: AMBARI-16025 > URL: https://issues.apache.org/jira/browse/AMBARI-16025 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > Attachments: AMBARI-16025.patch > > > - Start deploying 1 host cluster HDFS+YARN+HIVE > - On Customize Services page, enable Interactive Query > - On install, start and Test page, API hangs with ResourceManager and > SNameNode in "QUEUED" status. This is because LLAP status checks take more > than 5 seconds to come back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16025) Installer wizard: Starting Services hangs because of LLAP status check.
[ https://issues.apache.org/jira/browse/AMBARI-16025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar updated AMBARI-16025: - Status: Open (was: Patch Available) > Installer wizard: Starting Services hangs because of LLAP status check. > --- > > Key: AMBARI-16025 > URL: https://issues.apache.org/jira/browse/AMBARI-16025 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > Attachments: AMBARI-16025.patch > > > - Start deploying 1 host cluster HDFS+YARN+HIVE > - On Customize Services page, enable Interactive Query > - On install, start and Test page, API hangs with ResourceManager and > SNameNode in "QUEUED" status. This is because LLAP status checks take more > than 5 seconds to come back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16025) Installer wizard: Starting Services hangs because of LLAP status check.
[ https://issues.apache.org/jira/browse/AMBARI-16025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar updated AMBARI-16025: - Attachment: AMBARI-16025.patch > Installer wizard: Starting Services hangs because of LLAP status check. > --- > > Key: AMBARI-16025 > URL: https://issues.apache.org/jira/browse/AMBARI-16025 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > Attachments: AMBARI-16025.patch > > > - Start deploying 1 host cluster HDFS+YARN+HIVE > - On Customize Services page, enable Interactive Query > - On install, start and Test page, API hangs with ResourceManager and > SNameNode in "QUEUED" status. This is because LLAP status checks take more > than 5 seconds to come back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16025) Installer wizard: Starting Services hangs because of LLAP status check.
[ https://issues.apache.org/jira/browse/AMBARI-16025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar updated AMBARI-16025: - Resolution: Fixed Status: Resolved (was: Patch Available) > Installer wizard: Starting Services hangs because of LLAP status check. > --- > > Key: AMBARI-16025 > URL: https://issues.apache.org/jira/browse/AMBARI-16025 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > Attachments: AMBARI-16025.patch > > > - Start deploying 1 host cluster HDFS+YARN+HIVE > - On Customize Services page, enable Interactive Query > - On install, start and Test page, API hangs with ResourceManager and > SNameNode in "QUEUED" status. This is because LLAP status checks take more > than 5 seconds to come back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16025) Installer wizard: Starting Services hangs because of LLAP status check.
[ https://issues.apache.org/jira/browse/AMBARI-16025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar updated AMBARI-16025: - Attachment: (was: AMBARI-16025.patch) > Installer wizard: Starting Services hangs because of LLAP status check. > --- > > Key: AMBARI-16025 > URL: https://issues.apache.org/jira/browse/AMBARI-16025 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > > - Start deploying 1 host cluster HDFS+YARN+HIVE > - On Customize Services page, enable Interactive Query > - On install, start and Test page, API hangs with ResourceManager and > SNameNode in "QUEUED" status. This is because LLAP status checks take more > than 5 seconds to come back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16024) Remove performing service check during "Remove Standby Wizard"
[ https://issues.apache.org/jira/browse/AMBARI-16024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252680#comment-15252680 ] bhuvnesh chaudhary commented on AMBARI-16024: - In case of Non-HA we might not see the problem listed in the jira but my above comment describes the other problem which we see because of segments not being registered early enough. What you mentioned, in general service check is a good thing, i agree with that. > Remove performing service check during "Remove Standby Wizard" > -- > > Key: AMBARI-16024 > URL: https://issues.apache.org/jira/browse/AMBARI-16024 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.0 >Reporter: bhuvnesh chaudhary >Assignee: bhuvnesh chaudhary > Fix For: 2.3.0 > > Attachments: AMBARI-16024.patch > > > Users will need to remove the HAWQ Standby Master using "Remove Standby > Wizard" after enabling HDFS HA. > So the service check may fail during the wizard as the HAWQ catalog might be > still pointing to the old filespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16024) Remove performing service check during "Remove Standby Wizard"
[ https://issues.apache.org/jira/browse/AMBARI-16024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252647#comment-15252647 ] bhuvnesh chaudhary commented on AMBARI-16024: - Also, we do execute the service check as part of the api calling start, so often it happens that the segments have not registered and due to which service check fails, so we should not do it here in my opinion. We can definitely add the service check but we should find out a way to identify the right time to run the service check. > Remove performing service check during "Remove Standby Wizard" > -- > > Key: AMBARI-16024 > URL: https://issues.apache.org/jira/browse/AMBARI-16024 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.0 >Reporter: bhuvnesh chaudhary >Assignee: bhuvnesh chaudhary > Fix For: 2.3.0 > > Attachments: AMBARI-16024.patch > > > Users will need to remove the HAWQ Standby Master using "Remove Standby > Wizard" after enabling HDFS HA. > So the service check may fail during the wizard as the HAWQ catalog might be > still pointing to the old filespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16024) Remove performing service check during "Remove Standby Wizard"
[ https://issues.apache.org/jira/browse/AMBARI-16024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252616#comment-15252616 ] jun aoki commented on AMBARI-16024: --- [~bhuvnesh2703], I might be missing some background context but have a question. In general, changing topology (in this case removing standby) and followed by performing a service check is a right thing to do. The problem occurs when HDFS HA, but is Remove Standby wizard OK when HDFS non-HA? I'd rather keep Service Check running on Remove Standby wizard, but fix a wizard to enable HDFS HA to update "the old filespace"? Just my 2 cents > Remove performing service check during "Remove Standby Wizard" > -- > > Key: AMBARI-16024 > URL: https://issues.apache.org/jira/browse/AMBARI-16024 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.0 >Reporter: bhuvnesh chaudhary >Assignee: bhuvnesh chaudhary > Fix For: 2.3.0 > > Attachments: AMBARI-16024.patch > > > Users will need to remove the HAWQ Standby Master using "Remove Standby > Wizard" after enabling HDFS HA. > So the service check may fail during the wizard as the HAWQ catalog might be > still pointing to the old filespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16025) Installer wizard: Starting Services hangs because of LLAP status check.
[ https://issues.apache.org/jira/browse/AMBARI-16025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar updated AMBARI-16025: - Status: Patch Available (was: In Progress) > Installer wizard: Starting Services hangs because of LLAP status check. > --- > > Key: AMBARI-16025 > URL: https://issues.apache.org/jira/browse/AMBARI-16025 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > Attachments: AMBARI-16025.patch > > > - Start deploying 1 host cluster HDFS+YARN+HIVE > - On Customize Services page, enable Interactive Query > - On install, start and Test page, API hangs with ResourceManager and > SNameNode in "QUEUED" status. This is because LLAP status checks take more > than 5 seconds to come back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16025) Installer wizard: Starting Services hangs because of LLAP status check.
[ https://issues.apache.org/jira/browse/AMBARI-16025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar updated AMBARI-16025: - Attachment: AMBARI-16025.patch > Installer wizard: Starting Services hangs because of LLAP status check. > --- > > Key: AMBARI-16025 > URL: https://issues.apache.org/jira/browse/AMBARI-16025 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.0 > > Attachments: AMBARI-16025.patch > > > - Start deploying 1 host cluster HDFS+YARN+HIVE > - On Customize Services page, enable Interactive Query > - On install, start and Test page, API hangs with ResourceManager and > SNameNode in "QUEUED" status. This is because LLAP status checks take more > than 5 seconds to come back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-15496: - Resolution: Fixed Status: Resolved (was: Patch Available) Pushed to trunk, commit 360fcfeb82d45cb0db0ce3e857ab2ac327d7ca99 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0, 2.2.1 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > Attachments: AMBARI-15496-2.patch, AMBARI-15496.patch, > AMBARI-15496.patch > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16018) Namenode RPC widget on Ambari Dashboard shows n/a
[
https://issues.apache.org/jira/browse/AMBARI-16018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252609#comment-15252609
]
Hadoop QA commented on AMBARI-16018:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12800026/AMBARI-16018_trunk.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6589//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6589//console
This message is automatically generated.
> Namenode RPC widget on Ambari Dashboard shows n/a
> -
>
> Key: AMBARI-16018
> URL: https://issues.apache.org/jira/browse/AMBARI-16018
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-16018_2.2.patch, AMBARI-16018_trunk.patch
>
>
> - I did an Ambari 2.4.0 install of HDP 2.4.0 (GA).
> - 3 node, hdfs, yarn, zk, ams
> - Ambari Web > Dashboard > NameNode RPC widget says 'n/a'
> The cluster has been running for close to an hour and these metrics are still
> not showing up.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16001) Fix bad entry in hbase-env.sh, added as part of 2.2.0-2.2.1.1 upgrade
[
https://issues.apache.org/jira/browse/AMBARI-16001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252608#comment-15252608
]
Hudson commented on AMBARI-16001:
-
SUCCESS: Integrated in Ambari-branch-2.2 #658 (See
[https://builds.apache.org/job/Ambari-branch-2.2/658/])
AMBARI-16001. Fix bad entry in hbase-env.sh, added as part of (ajit:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=fd3e212b414c59edeb49a982b8a4b6ebf92c6069])
*
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog222Test.java
*
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog222.java
> Fix bad entry in hbase-env.sh, added as part of 2.2.0-2.2.1.1 upgrade
> -
>
> Key: AMBARI-16001
> URL: https://issues.apache.org/jira/browse/AMBARI-16001
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Ajit Kumar
>Assignee: Ajit Kumar
> Fix For: 2.2.2
>
> Attachments: rb45592.patch
>
>
> Ambari upgrades, 2.2.0-2.2.1.1 adds a bad entry to the hbase-env
> {code}export HBASE_OPTS="-Djava.io.tmpdir={{java_io_tmpdir}}"{code}
> With broken hbase-env user cannot run any mapreduce services for hbase.
> Currently it needs to be fixed manually.
> {code}
> export HBASE_OPTS="${HBASE_OPTS} -Djava.io.tmpdir={{java_io_tmpdir}}"
> {code}
> It will be good if just upgrading to 2.2.2 fixes this issue rather than
> mucking around with configs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16013) Host_status stuck in UNKNOWN status after blueprint deploy with host in heartbeat-lost
[
https://issues.apache.org/jira/browse/AMBARI-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252607#comment-15252607
]
Hudson commented on AMBARI-16013:
-
SUCCESS: Integrated in Ambari-branch-2.2 #658 (See
[https://builds.apache.org/job/Ambari-branch-2.2/658/])
AMBARI-16013. Host_status stuck in UNKNOWN status after blueprint deploy
(stoader:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=ff25b1d7f3142d18114b351180c1fff85caa8799])
*
ambari-server/src/main/java/org/apache/ambari/server/topology/TopologyManager.java
* ambari-server/src/main/java/org/apache/ambari/server/state/host/HostImpl.java
> Host_status stuck in UNKNOWN status after blueprint deploy with host in
> heartbeat-lost
> --
>
> Key: AMBARI-16013
> URL: https://issues.apache.org/jira/browse/AMBARI-16013
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Blocker
> Fix For: 2.2.2
>
> Attachments: AMBARI-16013.branch-2.2.v2.patch,
> AMBARI-16013.trunk.v2.patch
>
>
> Deploy a cluster using blueprint when all nodes are in HEARTBEAT_LOST state
> (e.g. nodes already registered with Ambari server once but than all were
> stopped prior posting the blueprint/cluster creation template to the server).
> The blueprint and cluster creation succeeded and UI looked good with all the
> hosts in heartbeat-lost state.
> Then start the agents one by one. Expected behaviour is that as soon as all
> required nodes are up Ambari to start scheduling tasks on the connected
> nodes to install the cluster.
> However the hosts were stuck in {{host_status: UNKNOWN}} state and Ambari did
> not start scheduling any tasks to the connected hosts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15724) Integrate Version Registration in Select Stack Page
[ https://issues.apache.org/jira/browse/AMBARI-15724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252591#comment-15252591 ] Xi Wang commented on AMBARI-15724: -- 27496 tests complete (27 seconds) 154 tests pending > Integrate Version Registration in Select Stack Page > --- > > Key: AMBARI-15724 > URL: https://issues.apache.org/jira/browse/AMBARI-15724 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Xi Wang >Assignee: Xi Wang >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-15724.patch, AMBARI-15724.patch, version1.patch, > version2.patch, version3.patch, version4.patch, version5.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15724) Integrate Version Registration in Select Stack Page
[ https://issues.apache.org/jira/browse/AMBARI-15724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xi Wang updated AMBARI-15724: - Attachment: version5.patch > Integrate Version Registration in Select Stack Page > --- > > Key: AMBARI-15724 > URL: https://issues.apache.org/jira/browse/AMBARI-15724 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Xi Wang >Assignee: Xi Wang >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-15724.patch, AMBARI-15724.patch, version1.patch, > version2.patch, version3.patch, version4.patch, version5.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16013) Host_status stuck in UNKNOWN status after blueprint deploy with host in heartbeat-lost
[
https://issues.apache.org/jira/browse/AMBARI-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252589#comment-15252589
]
Sebastian Toader commented on AMBARI-16013:
---
{code:title=branch-2.2.2}
commit 95bc6b6056f7c87890cb2b1473b2fc72e6be89c4
Author: Toader, Sebastian
Date: Thu Apr 21 19:07:36 2016 +0200
AMBARI-16013. Host_status stuck in UNKNOWN status after blueprint deploy
with host in heartbeat-lost. (stoader)
{code}
{code:title=branch-2.2}
commit ff25b1d7f3142d18114b351180c1fff85caa8799
Author: Toader, Sebastian
Date: Thu Apr 21 19:07:36 2016 +0200
AMBARI-16013. Host_status stuck in UNKNOWN status after blueprint deploy
with host in heartbeat-lost. (stoader)
{code}
{code:title=trunk}
commit 5b5bf1a34b1b060202421fcdb91a73f47376c273
Author: Toader, Sebastian
Date: Thu Apr 21 19:09:56 2016 +0200
AMBARI-16013. Host_status stuck in UNKNOWN status after blueprint deploy
with host in heartbeat-lost. (stoader)
{code}
> Host_status stuck in UNKNOWN status after blueprint deploy with host in
> heartbeat-lost
> --
>
> Key: AMBARI-16013
> URL: https://issues.apache.org/jira/browse/AMBARI-16013
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Blocker
> Fix For: 2.2.2
>
> Attachments: AMBARI-16013.branch-2.2.v2.patch,
> AMBARI-16013.trunk.v2.patch
>
>
> Deploy a cluster using blueprint when all nodes are in HEARTBEAT_LOST state
> (e.g. nodes already registered with Ambari server once but than all were
> stopped prior posting the blueprint/cluster creation template to the server).
> The blueprint and cluster creation succeeded and UI looked good with all the
> hosts in heartbeat-lost state.
> Then start the agents one by one. Expected behaviour is that as soon as all
> required nodes are up Ambari to start scheduling tasks on the connected
> nodes to install the cluster.
> However the hosts were stuck in {{host_status: UNKNOWN}} state and Ambari did
> not start scheduling any tasks to the connected hosts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16016) Properly handle 'properties' in Manage Config Group popup
[
https://issues.apache.org/jira/browse/AMBARI-16016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252528#comment-15252528
]
Hadoop QA commented on AMBARI-16016:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/1276/AMBARI-16516.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6586//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6586//console
This message is automatically generated.
> Properly handle 'properties' in Manage Config Group popup
> -
>
> Key: AMBARI-16016
> URL: https://issues.apache.org/jira/browse/AMBARI-16016
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-16516.patch
>
>
> On installer on ASW
> - create new override
> - update value for this override
> - open manage group popup
> - select group that just was edited
> - see 'properties'
> value in 'properties' and override value doesn't match
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-16025) Installer wizard: Starting Services hangs because of LLAP status check.
Swapan Shridhar created AMBARI-16025: Summary: Installer wizard: Starting Services hangs because of LLAP status check. Key: AMBARI-16025 URL: https://issues.apache.org/jira/browse/AMBARI-16025 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.4.0 Reporter: Swapan Shridhar Assignee: Swapan Shridhar Fix For: 2.4.0 - Start deploying 1 host cluster HDFS+YARN+HIVE - On Customize Services page, enable Interactive Query - On install, start and Test page, API hangs with ResourceManager and SNameNode in "QUEUED" status. This is because LLAP status checks take more than 5 seconds to come back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16024) Remove performing service check during "Remove Standby Wizard"
[ https://issues.apache.org/jira/browse/AMBARI-16024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bhuvnesh chaudhary updated AMBARI-16024: Fix Version/s: 2.3.0 > Remove performing service check during "Remove Standby Wizard" > -- > > Key: AMBARI-16024 > URL: https://issues.apache.org/jira/browse/AMBARI-16024 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.0 >Reporter: bhuvnesh chaudhary >Assignee: bhuvnesh chaudhary > Fix For: 2.3.0 > > Attachments: AMBARI-16024.patch > > > Users will need to remove the HAWQ Standby Master using "Remove Standby > Wizard" after enabling HDFS HA. > So the service check may fail during the wizard as the HAWQ catalog might be > still pointing to the old filespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16024) Remove performing service check during "Remove Standby Wizard"
[ https://issues.apache.org/jira/browse/AMBARI-16024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bhuvnesh chaudhary updated AMBARI-16024: Affects Version/s: 2.2.0 > Remove performing service check during "Remove Standby Wizard" > -- > > Key: AMBARI-16024 > URL: https://issues.apache.org/jira/browse/AMBARI-16024 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.0 >Reporter: bhuvnesh chaudhary >Assignee: bhuvnesh chaudhary > Fix For: 2.3.0 > > Attachments: AMBARI-16024.patch > > > Users will need to remove the HAWQ Standby Master using "Remove Standby > Wizard" after enabling HDFS HA. > So the service check may fail during the wizard as the HAWQ catalog might be > still pointing to the old filespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
