[jira] [Created] (AMBARI-20336) Use lowercase of principal for livy
Jeff Zhang created AMBARI-20336: --- Summary: Use lowercase of principal for livy Key: AMBARI-20336 URL: https://issues.apache.org/jira/browse/AMBARI-20336 Project: Ambari Issue Type: Improvement Affects Versions: 2.4.0 Reporter: Jeff Zhang Assignee: Jeff Zhang Fix For: 2.5.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20308) Atlas service check fails during EU on wire encrypted cluster
[
https://issues.apache.org/jira/browse/AMBARI-20308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-20308:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Atlas service check fails during EU on wire encrypted cluster
> -
>
> Key: AMBARI-20308
> URL: https://issues.apache.org/jira/browse/AMBARI-20308
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vivek Sharma
>Assignee: Jonathan Hurley
>Priority: Critical
> Labels: express_upgrade
> Fix For: 2.5.0
>
> Attachments: AMBARI-20308.patch
>
>
> STR
> 1. Deployed cluster with Ambari version: 2.4.2.0-136 and HDP version:
> 2.5.3.0-37 (wire encrypted cluster)
> 2. Upgrade Ambari to 2.5.0.0-1030 and then start EU to 2.6
> 3. Observed following failure at Atlas service check
> {code}
> 2017-03-02 13:22:41,729 - ATLAS service check failed for host atlas_host with
> error Execution of 'curl -k --negotiate -u : -b ~/cookiejar.txt -c
> ~/cookiejar.txt -s -o /dev/null -w "%{http_code}" https://atlas_host:21443/'
> returned 35. Hortonworks #
> This is MOTD message, added for testing in qe infra
> 000
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/service_check.py",
> line 52, in
> AtlasServiceCheck().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 313, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/service_check.py",
> line 48, in service_check
> raise Fail("All instances of ATLAS METADATA SERVER are down.")
> resource_management.core.exceptions.Fail: All instances of ATLAS METADATA
> SERVER are down.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMBARI-18892) storm DRPC_SERVER kerberos configs duplicate
[ https://issues.apache.org/jira/browse/AMBARI-18892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898647#comment-15898647 ] wangyaoxin commented on AMBARI-18892: - Hi [~rlevas] Thanks , I have attached a new patch . > storm DRPC_SERVER kerberos configs duplicate > - > > Key: AMBARI-18892 > URL: https://issues.apache.org/jira/browse/AMBARI-18892 > Project: Ambari > Issue Type: Improvement >Affects Versions: trunk, 2.4.1 >Reporter: wangyaoxin >Assignee: wangyaoxin > Fix For: trunk, 3.0.0 > > Attachments: AMBARI-18892_01.patch, AMBARI-18892.patch, storm.png > > > when ambari enables kerberos, add storm service ,nimbus_keytab and > nimbus_principal_name will duplicate -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-18892) storm DRPC_SERVER kerberos configs duplicate
[ https://issues.apache.org/jira/browse/AMBARI-18892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] wangyaoxin updated AMBARI-18892: Attachment: AMBARI-18892_01.patch > storm DRPC_SERVER kerberos configs duplicate > - > > Key: AMBARI-18892 > URL: https://issues.apache.org/jira/browse/AMBARI-18892 > Project: Ambari > Issue Type: Improvement >Affects Versions: trunk, 2.4.1 >Reporter: wangyaoxin >Assignee: wangyaoxin > Fix For: trunk, 3.0.0 > > Attachments: AMBARI-18892_01.patch, AMBARI-18892.patch, storm.png > > > when ambari enables kerberos, add storm service ,nimbus_keytab and > nimbus_principal_name will duplicate -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-18892) storm DRPC_SERVER kerberos configs duplicate
[ https://issues.apache.org/jira/browse/AMBARI-18892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] wangyaoxin updated AMBARI-18892: Attachment: (was: AMBARI-18892_01.patch) > storm DRPC_SERVER kerberos configs duplicate > - > > Key: AMBARI-18892 > URL: https://issues.apache.org/jira/browse/AMBARI-18892 > Project: Ambari > Issue Type: Improvement >Affects Versions: trunk, 2.4.1 >Reporter: wangyaoxin >Assignee: wangyaoxin > Fix For: trunk, 3.0.0 > > Attachments: AMBARI-18892.patch, storm.png > > > when ambari enables kerberos, add storm service ,nimbus_keytab and > nimbus_principal_name will duplicate -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-18892) storm DRPC_SERVER kerberos configs duplicate
[ https://issues.apache.org/jira/browse/AMBARI-18892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] wangyaoxin updated AMBARI-18892: Attachment: AMBARI-18892_01.patch > storm DRPC_SERVER kerberos configs duplicate > - > > Key: AMBARI-18892 > URL: https://issues.apache.org/jira/browse/AMBARI-18892 > Project: Ambari > Issue Type: Improvement >Affects Versions: trunk, 2.4.1 >Reporter: wangyaoxin >Assignee: wangyaoxin > Fix For: trunk, 3.0.0 > > Attachments: AMBARI-18892_01.patch, AMBARI-18892.patch, storm.png > > > when ambari enables kerberos, add storm service ,nimbus_keytab and > nimbus_principal_name will duplicate -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (AMBARI-20331) testSafeCreateCommandNotExisting UT fails
[
https://issues.apache.org/jira/browse/AMBARI-20331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya reassigned AMBARI-20331:
--
Assignee: Madhuvanthi Radhakrishnan
> testSafeCreateCommandNotExisting UT fails
> -
>
> Key: AMBARI-20331
> URL: https://issues.apache.org/jira/browse/AMBARI-20331
> Project: Ambari
> Issue Type: Bug
> Components: test
>Reporter: Yesha Vora
>Assignee: Madhuvanthi Radhakrishnan
>
> testSafeCreateCommandNotExisting is failing with below error.
> {code}
> Error Message
> org/apache/commons/io/Charsets
> Stacktrace
> java.lang.NoClassDefFoundError: org/apache/commons/io/Charsets
> at
> org.apache.ambari.server.credentialapi.CredentialUtilTest.executeCommand(CredentialUtilTest.java:215)
> at
> org.apache.ambari.server.credentialapi.CredentialUtilTest.testSafeCreateCommandNotExisting(CredentialUtilTest.java:350)
> Caused by: java.lang.ClassNotFoundException: org.apache.commons.io.Charsets
> at
> org.apache.ambari.server.credentialapi.CredentialUtilTest.executeCommand(CredentialUtilTest.java:215)
> at
> org.apache.ambari.server.credentialapi.CredentialUtilTest.testSafeCreateCommandNotExisting(CredentialUtilTest.java:350){code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20333) Value for "User Limit Factor" should be float instead of integer in YARN Queue Manager.
[ https://issues.apache.org/jira/browse/AMBARI-20333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Gnanamalar Jebaraj updated AMBARI-20333: -- Attachment: (was: AMBARI-20333.patch) > Value for "User Limit Factor" should be float instead of integer in YARN > Queue Manager. > --- > > Key: AMBARI-20333 > URL: https://issues.apache.org/jira/browse/AMBARI-20333 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk >Reporter: Anita Gnanamalar Jebaraj >Assignee: Anita Gnanamalar Jebaraj >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-20333.patch, screenshot-1.png > > > According to yarn documentation, > "yarn.scheduler.capacity..user-limit-factor" should be a float: > https://hadoop.apache.org/docs/r2.4.1/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html > Hence the user should be allowed to enter decimal values for 'User limit > factor' -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20333) Value for "User Limit Factor" should be float instead of integer in YARN Queue Manager.
[ https://issues.apache.org/jira/browse/AMBARI-20333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Gnanamalar Jebaraj updated AMBARI-20333: -- Attachment: AMBARI-20333.patch > Value for "User Limit Factor" should be float instead of integer in YARN > Queue Manager. > --- > > Key: AMBARI-20333 > URL: https://issues.apache.org/jira/browse/AMBARI-20333 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk >Reporter: Anita Gnanamalar Jebaraj >Assignee: Anita Gnanamalar Jebaraj >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-20333.patch, screenshot-1.png > > > According to yarn documentation, > "yarn.scheduler.capacity..user-limit-factor" should be a float: > https://hadoop.apache.org/docs/r2.4.1/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html > Hence the user should be allowed to enter decimal values for 'User limit > factor' -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20333) Value for "User Limit Factor" should be float instead of integer in YARN Queue Manager.
[ https://issues.apache.org/jira/browse/AMBARI-20333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Gnanamalar Jebaraj updated AMBARI-20333: -- Status: Patch Available (was: Open) > Value for "User Limit Factor" should be float instead of integer in YARN > Queue Manager. > --- > > Key: AMBARI-20333 > URL: https://issues.apache.org/jira/browse/AMBARI-20333 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk >Reporter: Anita Gnanamalar Jebaraj >Assignee: Anita Gnanamalar Jebaraj >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-20333.patch, screenshot-1.png > > > According to yarn documentation, > "yarn.scheduler.capacity..user-limit-factor" should be a float: > https://hadoop.apache.org/docs/r2.4.1/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html > Hence the user should be allowed to enter decimal values for 'User limit > factor' -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20333) Value for "User Limit Factor" should be float instead of integer in YARN Queue Manager.
[ https://issues.apache.org/jira/browse/AMBARI-20333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Gnanamalar Jebaraj updated AMBARI-20333: -- Attachment: AMBARI-20333.patch > Value for "User Limit Factor" should be float instead of integer in YARN > Queue Manager. > --- > > Key: AMBARI-20333 > URL: https://issues.apache.org/jira/browse/AMBARI-20333 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk >Reporter: Anita Gnanamalar Jebaraj >Assignee: Anita Gnanamalar Jebaraj >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-20333.patch, screenshot-1.png > > > According to yarn documentation, > "yarn.scheduler.capacity..user-limit-factor" should be a float: > https://hadoop.apache.org/docs/r2.4.1/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html > Hence the user should be allowed to enter decimal values for 'User limit > factor' -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20333) Value for "User Limit Factor" should be float instead of integer in YARN Queue Manager.
[ https://issues.apache.org/jira/browse/AMBARI-20333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Gnanamalar Jebaraj updated AMBARI-20333: -- Status: Open (was: Patch Available) > Value for "User Limit Factor" should be float instead of integer in YARN > Queue Manager. > --- > > Key: AMBARI-20333 > URL: https://issues.apache.org/jira/browse/AMBARI-20333 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk >Reporter: Anita Gnanamalar Jebaraj >Assignee: Anita Gnanamalar Jebaraj >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-20333.patch, screenshot-1.png > > > According to yarn documentation, > "yarn.scheduler.capacity..user-limit-factor" should be a float: > https://hadoop.apache.org/docs/r2.4.1/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html > Hence the user should be allowed to enter decimal values for 'User limit > factor' -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20333) Value for "User Limit Factor" should be float instead of integer in YARN Queue Manager.
[ https://issues.apache.org/jira/browse/AMBARI-20333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Gnanamalar Jebaraj updated AMBARI-20333: -- Attachment: (was: AMBARI-20333.patch) > Value for "User Limit Factor" should be float instead of integer in YARN > Queue Manager. > --- > > Key: AMBARI-20333 > URL: https://issues.apache.org/jira/browse/AMBARI-20333 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk >Reporter: Anita Gnanamalar Jebaraj >Assignee: Anita Gnanamalar Jebaraj >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-20333.patch, screenshot-1.png > > > According to yarn documentation, > "yarn.scheduler.capacity..user-limit-factor" should be a float: > https://hadoop.apache.org/docs/r2.4.1/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html > Hence the user should be allowed to enter decimal values for 'User limit > factor' -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20335) Kerberos identity reference not working for ranger-audit property in hbase
[
https://issues.apache.org/jira/browse/AMBARI-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-20335:
--
Status: Patch Available (was: Open)
> Kerberos identity reference not working for ranger-audit property in hbase
> --
>
> Key: AMBARI-20335
> URL: https://issues.apache.org/jira/browse/AMBARI-20335
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: kerberos, kerberos_descriptor
> Fix For: 2.5.0
>
> Attachments: AMBARI-20335_branch-2.5_01.patch,
> AMBARI-20335_trunk_01.patch
>
>
> From stack 2.5 onwards
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} needs to
> have principal value available under
> {{hbase.master.kerberos.principal/hbase-site}}
> To achieve that added below block of code under hbase
> [kerberos.json|https://github.com/apache/ambari/blob/branch-2.5/ambari-server/src/main/resources/stacks/HDP/2.5/services/HBASE/kerberos.json]
> {noformat}
> {
> "name": "/HBASE/HBASE_MASTER/hbase_master_hbase",
> "principal": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.principal"
> },
> "keytab": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.keyTab"
> }
> }
> {noformat}
> But on test cluster,
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} property
> is not showing the expected value. It is showing the principal/keytab values
> of {{ams_hbase_master_hbase}} identity.
> Because of wrong reference of principal audit to solr is not working in
> kerberos environment, as security.json have below entry instead of
> {{hb...@example.com}}
> {noformat}
> "amshb...@example.com":[
> "ranger_audit_user",
> "dev"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20335) Kerberos identity reference not working for ranger-audit property in hbase
[
https://issues.apache.org/jira/browse/AMBARI-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-20335:
--
Attachment: (was: AMBARI-20335_trunk_01.patch)
> Kerberos identity reference not working for ranger-audit property in hbase
> --
>
> Key: AMBARI-20335
> URL: https://issues.apache.org/jira/browse/AMBARI-20335
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: kerberos, kerberos_descriptor
> Fix For: 2.5.0
>
> Attachments: AMBARI-20335_branch-2.5_01.patch,
> AMBARI-20335_trunk_01.patch
>
>
> From stack 2.5 onwards
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} needs to
> have principal value available under
> {{hbase.master.kerberos.principal/hbase-site}}
> To achieve that added below block of code under hbase
> [kerberos.json|https://github.com/apache/ambari/blob/branch-2.5/ambari-server/src/main/resources/stacks/HDP/2.5/services/HBASE/kerberos.json]
> {noformat}
> {
> "name": "/HBASE/HBASE_MASTER/hbase_master_hbase",
> "principal": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.principal"
> },
> "keytab": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.keyTab"
> }
> }
> {noformat}
> But on test cluster,
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} property
> is not showing the expected value. It is showing the principal/keytab values
> of {{ams_hbase_master_hbase}} identity.
> Because of wrong reference of principal audit to solr is not working in
> kerberos environment, as security.json have below entry instead of
> {{hb...@example.com}}
> {noformat}
> "amshb...@example.com":[
> "ranger_audit_user",
> "dev"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20335) Kerberos identity reference not working for ranger-audit property in hbase
[
https://issues.apache.org/jira/browse/AMBARI-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-20335:
--
Status: Open (was: Patch Available)
> Kerberos identity reference not working for ranger-audit property in hbase
> --
>
> Key: AMBARI-20335
> URL: https://issues.apache.org/jira/browse/AMBARI-20335
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: kerberos, kerberos_descriptor
> Fix For: 2.5.0
>
> Attachments: AMBARI-20335_branch-2.5_01.patch,
> AMBARI-20335_trunk_01.patch
>
>
> From stack 2.5 onwards
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} needs to
> have principal value available under
> {{hbase.master.kerberos.principal/hbase-site}}
> To achieve that added below block of code under hbase
> [kerberos.json|https://github.com/apache/ambari/blob/branch-2.5/ambari-server/src/main/resources/stacks/HDP/2.5/services/HBASE/kerberos.json]
> {noformat}
> {
> "name": "/HBASE/HBASE_MASTER/hbase_master_hbase",
> "principal": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.principal"
> },
> "keytab": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.keyTab"
> }
> }
> {noformat}
> But on test cluster,
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} property
> is not showing the expected value. It is showing the principal/keytab values
> of {{ams_hbase_master_hbase}} identity.
> Because of wrong reference of principal audit to solr is not working in
> kerberos environment, as security.json have below entry instead of
> {{hb...@example.com}}
> {noformat}
> "amshb...@example.com":[
> "ranger_audit_user",
> "dev"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20335) Kerberos identity reference not working for ranger-audit property in hbase
[
https://issues.apache.org/jira/browse/AMBARI-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-20335:
--
Attachment: AMBARI-20335_trunk_01.patch
AMBARI-20335_branch-2.5_01.patch
> Kerberos identity reference not working for ranger-audit property in hbase
> --
>
> Key: AMBARI-20335
> URL: https://issues.apache.org/jira/browse/AMBARI-20335
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: kerberos, kerberos_descriptor
> Fix For: 2.5.0
>
> Attachments: AMBARI-20335_branch-2.5_01.patch,
> AMBARI-20335_trunk_01.patch
>
>
> From stack 2.5 onwards
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} needs to
> have principal value available under
> {{hbase.master.kerberos.principal/hbase-site}}
> To achieve that added below block of code under hbase
> [kerberos.json|https://github.com/apache/ambari/blob/branch-2.5/ambari-server/src/main/resources/stacks/HDP/2.5/services/HBASE/kerberos.json]
> {noformat}
> {
> "name": "/HBASE/HBASE_MASTER/hbase_master_hbase",
> "principal": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.principal"
> },
> "keytab": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.keyTab"
> }
> }
> {noformat}
> But on test cluster,
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} property
> is not showing the expected value. It is showing the principal/keytab values
> of {{ams_hbase_master_hbase}} identity.
> Because of wrong reference of principal audit to solr is not working in
> kerberos environment, as security.json have below entry instead of
> {{hb...@example.com}}
> {noformat}
> "amshb...@example.com":[
> "ranger_audit_user",
> "dev"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20335) Kerberos identity reference not working for ranger-audit property in hbase
[
https://issues.apache.org/jira/browse/AMBARI-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-20335:
--
Attachment: (was: AMBARI-20335_branch-2.5_01.patch)
> Kerberos identity reference not working for ranger-audit property in hbase
> --
>
> Key: AMBARI-20335
> URL: https://issues.apache.org/jira/browse/AMBARI-20335
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: kerberos, kerberos_descriptor
> Fix For: 2.5.0
>
> Attachments: AMBARI-20335_branch-2.5_01.patch,
> AMBARI-20335_trunk_01.patch
>
>
> From stack 2.5 onwards
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} needs to
> have principal value available under
> {{hbase.master.kerberos.principal/hbase-site}}
> To achieve that added below block of code under hbase
> [kerberos.json|https://github.com/apache/ambari/blob/branch-2.5/ambari-server/src/main/resources/stacks/HDP/2.5/services/HBASE/kerberos.json]
> {noformat}
> {
> "name": "/HBASE/HBASE_MASTER/hbase_master_hbase",
> "principal": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.principal"
> },
> "keytab": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.keyTab"
> }
> }
> {noformat}
> But on test cluster,
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} property
> is not showing the expected value. It is showing the principal/keytab values
> of {{ams_hbase_master_hbase}} identity.
> Because of wrong reference of principal audit to solr is not working in
> kerberos environment, as security.json have below entry instead of
> {{hb...@example.com}}
> {noformat}
> "amshb...@example.com":[
> "ranger_audit_user",
> "dev"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20335) Kerberos identity reference not working for ranger-audit property in hbase
[
https://issues.apache.org/jira/browse/AMBARI-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-20335:
--
Attachment: (was: AMBARI-20335_branch2.5_01.patch)
> Kerberos identity reference not working for ranger-audit property in hbase
> --
>
> Key: AMBARI-20335
> URL: https://issues.apache.org/jira/browse/AMBARI-20335
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: kerberos, kerberos_descriptor
> Fix For: 2.5.0
>
> Attachments: AMBARI-20335_branch-2.5_01.patch,
> AMBARI-20335_trunk_01.patch
>
>
> From stack 2.5 onwards
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} needs to
> have principal value available under
> {{hbase.master.kerberos.principal/hbase-site}}
> To achieve that added below block of code under hbase
> [kerberos.json|https://github.com/apache/ambari/blob/branch-2.5/ambari-server/src/main/resources/stacks/HDP/2.5/services/HBASE/kerberos.json]
> {noformat}
> {
> "name": "/HBASE/HBASE_MASTER/hbase_master_hbase",
> "principal": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.principal"
> },
> "keytab": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.keyTab"
> }
> }
> {noformat}
> But on test cluster,
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} property
> is not showing the expected value. It is showing the principal/keytab values
> of {{ams_hbase_master_hbase}} identity.
> Because of wrong reference of principal audit to solr is not working in
> kerberos environment, as security.json have below entry instead of
> {{hb...@example.com}}
> {noformat}
> "amshb...@example.com":[
> "ranger_audit_user",
> "dev"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20335) Kerberos identity reference not working for ranger-audit property in hbase
[
https://issues.apache.org/jira/browse/AMBARI-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-20335:
--
Attachment: AMBARI-20335_branch-2.5_01.patch
> Kerberos identity reference not working for ranger-audit property in hbase
> --
>
> Key: AMBARI-20335
> URL: https://issues.apache.org/jira/browse/AMBARI-20335
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: kerberos, kerberos_descriptor
> Fix For: 2.5.0
>
> Attachments: AMBARI-20335_branch-2.5_01.patch,
> AMBARI-20335_trunk_01.patch
>
>
> From stack 2.5 onwards
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} needs to
> have principal value available under
> {{hbase.master.kerberos.principal/hbase-site}}
> To achieve that added below block of code under hbase
> [kerberos.json|https://github.com/apache/ambari/blob/branch-2.5/ambari-server/src/main/resources/stacks/HDP/2.5/services/HBASE/kerberos.json]
> {noformat}
> {
> "name": "/HBASE/HBASE_MASTER/hbase_master_hbase",
> "principal": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.principal"
> },
> "keytab": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.keyTab"
> }
> }
> {noformat}
> But on test cluster,
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} property
> is not showing the expected value. It is showing the principal/keytab values
> of {{ams_hbase_master_hbase}} identity.
> Because of wrong reference of principal audit to solr is not working in
> kerberos environment, as security.json have below entry instead of
> {{hb...@example.com}}
> {noformat}
> "amshb...@example.com":[
> "ranger_audit_user",
> "dev"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20335) Kerberos identity reference not working for ranger-audit property in hbase
[
https://issues.apache.org/jira/browse/AMBARI-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-20335:
--
Status: Patch Available (was: In Progress)
> Kerberos identity reference not working for ranger-audit property in hbase
> --
>
> Key: AMBARI-20335
> URL: https://issues.apache.org/jira/browse/AMBARI-20335
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: kerberos, kerberos_descriptor
> Fix For: 2.5.0
>
> Attachments: AMBARI-20335_branch-2.5_01.patch,
> AMBARI-20335_trunk_01.patch
>
>
> From stack 2.5 onwards
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} needs to
> have principal value available under
> {{hbase.master.kerberos.principal/hbase-site}}
> To achieve that added below block of code under hbase
> [kerberos.json|https://github.com/apache/ambari/blob/branch-2.5/ambari-server/src/main/resources/stacks/HDP/2.5/services/HBASE/kerberos.json]
> {noformat}
> {
> "name": "/HBASE/HBASE_MASTER/hbase_master_hbase",
> "principal": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.principal"
> },
> "keytab": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.keyTab"
> }
> }
> {noformat}
> But on test cluster,
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} property
> is not showing the expected value. It is showing the principal/keytab values
> of {{ams_hbase_master_hbase}} identity.
> Because of wrong reference of principal audit to solr is not working in
> kerberos environment, as security.json have below entry instead of
> {{hb...@example.com}}
> {noformat}
> "amshb...@example.com":[
> "ranger_audit_user",
> "dev"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20335) Kerberos identity reference not working for ranger-audit property in hbase
[
https://issues.apache.org/jira/browse/AMBARI-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-20335:
--
Attachment: AMBARI-20335_trunk_01.patch
AMBARI-20335_branch2.5_01.patch
> Kerberos identity reference not working for ranger-audit property in hbase
> --
>
> Key: AMBARI-20335
> URL: https://issues.apache.org/jira/browse/AMBARI-20335
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: kerberos, kerberos_descriptor
> Fix For: 2.5.0
>
> Attachments: AMBARI-20335_branch2.5_01.patch,
> AMBARI-20335_trunk_01.patch
>
>
> From stack 2.5 onwards
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} needs to
> have principal value available under
> {{hbase.master.kerberos.principal/hbase-site}}
> To achieve that added below block of code under hbase
> [kerberos.json|https://github.com/apache/ambari/blob/branch-2.5/ambari-server/src/main/resources/stacks/HDP/2.5/services/HBASE/kerberos.json]
> {noformat}
> {
> "name": "/HBASE/HBASE_MASTER/hbase_master_hbase",
> "principal": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.principal"
> },
> "keytab": {
> "configuration":
> "ranger-hbase-audit/xasecure.audit.jaas.Client.option.keyTab"
> }
> }
> {noformat}
> But on test cluster,
> {{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} property
> is not showing the expected value. It is showing the principal/keytab values
> of {{ams_hbase_master_hbase}} identity.
> Because of wrong reference of principal audit to solr is not working in
> kerberos environment, as security.json have below entry instead of
> {{hb...@example.com}}
> {noformat}
> "amshb...@example.com":[
> "ranger_audit_user",
> "dev"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (AMBARI-20335) Kerberos identity reference not working for ranger-audit property in hbase
Robert Levas created AMBARI-20335:
-
Summary: Kerberos identity reference not working for ranger-audit
property in hbase
Key: AMBARI-20335
URL: https://issues.apache.org/jira/browse/AMBARI-20335
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Robert Levas
Assignee: Robert Levas
Fix For: 2.5.0
>From stack 2.5 onwards
>{{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} needs to
>have principal value available under
>{{hbase.master.kerberos.principal/hbase-site}}
To achieve that added below block of code under hbase
[kerberos.json|https://github.com/apache/ambari/blob/branch-2.5/ambari-server/src/main/resources/stacks/HDP/2.5/services/HBASE/kerberos.json]
{noformat}
{
"name": "/HBASE/HBASE_MASTER/hbase_master_hbase",
"principal": {
"configuration":
"ranger-hbase-audit/xasecure.audit.jaas.Client.option.principal"
},
"keytab": {
"configuration":
"ranger-hbase-audit/xasecure.audit.jaas.Client.option.keyTab"
}
}
{noformat}
But on test cluster,
{{xasecure.audit.jaas.Client.option.principal/ranger-hbase-audit}} property is
not showing the expected value. It is showing the principal/keytab values of
{{ams_hbase_master_hbase}} identity.
Because of wrong reference of principal audit to solr is not working in
kerberos environment, as security.json have below entry instead of
{{hb...@example.com}}
{noformat}
"amshb...@example.com":[
"ranger_audit_user",
"dev"]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (AMBARI-20334) Yarn Queue manager capacity field allows entering invalid values
Anita Gnanamalar Jebaraj created AMBARI-20334: - Summary: Yarn Queue manager capacity field allows entering invalid values Key: AMBARI-20334 URL: https://issues.apache.org/jira/browse/AMBARI-20334 Project: Ambari Issue Type: Bug Components: ambari-views Affects Versions: trunk Reporter: Anita Gnanamalar Jebaraj Assignee: Anita Gnanamalar Jebaraj Priority: Minor Fix For: trunk capacity field in yarn queue manager should allow entering decimal numbers upto 2 places, currently the field allows entering values like 1.2.3 12... 1 2.3 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20329) After restarting Ranger, PAM files are overwritten by default template
[ https://issues.apache.org/jira/browse/AMBARI-20329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shi Wang updated AMBARI-20329: -- Description: AMBARI-18425 add PAM support for ranger authentication in Ambari, but every time restart ranger-admin it will generate the files again, which will overwrite the user change. Need to check first if these files already exist, do not generate again. (was: AMBARI-18425 add PAM support for ranger authentication in Ambari, but it relies on the default template and not allow user configure the pam file by ambari. Therefore when restart ranger admin the custom pam file content will be overwritten by the default template. ) > After restarting Ranger, PAM files are overwritten by default template > -- > > Key: AMBARI-20329 > URL: https://issues.apache.org/jira/browse/AMBARI-20329 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.5.0 >Reporter: Shi Wang >Assignee: Shi Wang > > AMBARI-18425 add PAM support for ranger authentication in Ambari, but every > time restart ranger-admin it will generate the files again, which will > overwrite the user change. Need to check first if these files already exist, > do not generate again. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20243) Include option to filter out properties from APi that returns ambari.properties file
[ https://issues.apache.org/jira/browse/AMBARI-20243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Gnanamalar Jebaraj updated AMBARI-20243: -- Attachment: AMBARI-20243-Mar6.patch > Include option to filter out properties from APi that returns > ambari.properties file > > > Key: AMBARI-20243 > URL: https://issues.apache.org/jira/browse/AMBARI-20243 > Project: Ambari > Issue Type: Bug > Components: ambari-sever >Affects Versions: trunk >Reporter: Anita Gnanamalar Jebaraj >Assignee: Anita Gnanamalar Jebaraj > Fix For: trunk > > Attachments: AMBARI-20243-Mar1.patch, AMBARI-20243-Mar3.patch, > AMBARI-20243-Mar6.patch, AMBARI-20243.patch > > > Currently all the details from the ambari.properties file is being returned > by the API call. > Some of those information may not be utilized and hence an option can be > provided to filter the properties. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (AMBARI-16880) Add common log rotation settings to Smart Config
[ https://issues.apache.org/jira/browse/AMBARI-16880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya resolved AMBARI-16880. Resolution: Fixed > Add common log rotation settings to Smart Config > > > Key: AMBARI-16880 > URL: https://issues.apache.org/jira/browse/AMBARI-16880 > Project: Ambari > Issue Type: New Feature >Reporter: Paul Codding >Assignee: Madhuvanthi Radhakrishnan > Fix For: 2.5.0 > > > Common log4j configurations for the rolling file appender used by components > like Hive, HDFS, Kafka, etc. should be easily configurable as Smart Config > fields. > Specifically configurations like: > * MaxBackupIndex > * MaxFileSize > These fields should be exposed in each component in a Logging section that > has input fields such as: > * Maximum Backup File Size: 100 MB > * Maximum Number of Backup Files: 10 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-16880) Add common log rotation settings to Smart Config
[ https://issues.apache.org/jira/browse/AMBARI-16880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-16880: --- Fix Version/s: (was: 3.0.0) 2.5.0 > Add common log rotation settings to Smart Config > > > Key: AMBARI-16880 > URL: https://issues.apache.org/jira/browse/AMBARI-16880 > Project: Ambari > Issue Type: New Feature >Reporter: Paul Codding >Assignee: Madhuvanthi Radhakrishnan > Fix For: 2.5.0 > > > Common log4j configurations for the rolling file appender used by components > like Hive, HDFS, Kafka, etc. should be easily configurable as Smart Config > fields. > Specifically configurations like: > * MaxBackupIndex > * MaxFileSize > These fields should be exposed in each component in a Logging section that > has input fields such as: > * Maximum Backup File Size: 100 MB > * Maximum Number of Backup Files: 10 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (AMBARI-16880) Add common log rotation settings to Smart Config
[ https://issues.apache.org/jira/browse/AMBARI-16880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya reassigned AMBARI-16880: -- Assignee: Madhuvanthi Radhakrishnan > Add common log rotation settings to Smart Config > > > Key: AMBARI-16880 > URL: https://issues.apache.org/jira/browse/AMBARI-16880 > Project: Ambari > Issue Type: New Feature >Reporter: Paul Codding >Assignee: Madhuvanthi Radhakrishnan > Fix For: 3.0.0, 2.5.0 > > > Common log4j configurations for the rolling file appender used by components > like Hive, HDFS, Kafka, etc. should be easily configurable as Smart Config > fields. > Specifically configurations like: > * MaxBackupIndex > * MaxFileSize > These fields should be exposed in each component in a Logging section that > has input fields such as: > * Maximum Backup File Size: 100 MB > * Maximum Number of Backup Files: 10 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20333) Value for "User Limit Factor" should be float instead of integer in YARN Queue Manager.
[ https://issues.apache.org/jira/browse/AMBARI-20333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Gnanamalar Jebaraj updated AMBARI-20333: -- Status: Patch Available (was: Open) > Value for "User Limit Factor" should be float instead of integer in YARN > Queue Manager. > --- > > Key: AMBARI-20333 > URL: https://issues.apache.org/jira/browse/AMBARI-20333 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk >Reporter: Anita Gnanamalar Jebaraj >Assignee: Anita Gnanamalar Jebaraj >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-20333.patch, screenshot-1.png > > > According to yarn documentation, > "yarn.scheduler.capacity..user-limit-factor" should be a float: > https://hadoop.apache.org/docs/r2.4.1/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html > Hence the user should be allowed to enter decimal values for 'User limit > factor' -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20333) Value for "User Limit Factor" should be float instead of integer in YARN Queue Manager.
[ https://issues.apache.org/jira/browse/AMBARI-20333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Gnanamalar Jebaraj updated AMBARI-20333: -- Attachment: screenshot-1.png > Value for "User Limit Factor" should be float instead of integer in YARN > Queue Manager. > --- > > Key: AMBARI-20333 > URL: https://issues.apache.org/jira/browse/AMBARI-20333 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk >Reporter: Anita Gnanamalar Jebaraj >Assignee: Anita Gnanamalar Jebaraj >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-20333.patch, screenshot-1.png > > > According to yarn documentation, > "yarn.scheduler.capacity..user-limit-factor" should be a float: > https://hadoop.apache.org/docs/r2.4.1/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html > Hence the user should be allowed to enter decimal values for 'User limit > factor' -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20333) Value for "User Limit Factor" should be float instead of integer in YARN Queue Manager.
[ https://issues.apache.org/jira/browse/AMBARI-20333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Gnanamalar Jebaraj updated AMBARI-20333: -- Attachment: AMBARI-20333.patch > Value for "User Limit Factor" should be float instead of integer in YARN > Queue Manager. > --- > > Key: AMBARI-20333 > URL: https://issues.apache.org/jira/browse/AMBARI-20333 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk >Reporter: Anita Gnanamalar Jebaraj >Assignee: Anita Gnanamalar Jebaraj >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-20333.patch > > > According to yarn documentation, > "yarn.scheduler.capacity..user-limit-factor" should be a float: > https://hadoop.apache.org/docs/r2.4.1/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html > Hence the user should be allowed to enter decimal values for 'User limit > factor' -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-20333) Value for "User Limit Factor" should be float instead of integer in YARN Queue Manager.
Anita Gnanamalar Jebaraj created AMBARI-20333: - Summary: Value for "User Limit Factor" should be float instead of integer in YARN Queue Manager. Key: AMBARI-20333 URL: https://issues.apache.org/jira/browse/AMBARI-20333 Project: Ambari Issue Type: Bug Affects Versions: trunk Reporter: Anita Gnanamalar Jebaraj Assignee: Anita Gnanamalar Jebaraj Priority: Minor Fix For: trunk According to yarn documentation, "yarn.scheduler.capacity..user-limit-factor" should be a float: https://hadoop.apache.org/docs/r2.4.1/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html Hence the user should be allowed to enter decimal values for 'User limit factor' -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20255) Sometimes the Hosts page shows a different page for page 1
[ https://issues.apache.org/jira/browse/AMBARI-20255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898136#comment-15898136 ] Hudson commented on AMBARI-20255: - FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1196 (See [https://builds.apache.org/job/Ambari-branch-2.5/1196/]) AMBARI-20255 Sometimes the Hosts page shows a different page for page 1. (atkach: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=7f9a5123eedb9043ce7102df9ae3cb3f2ebc8f76]) * (edit) ambari-web/app/views/main/host.js * (edit) ambari-web/app/controllers/global/update_controller.js * (edit) ambari-web/app/controllers/main/host.js * (edit) ambari-web/test/mixins/common/table_server_view_mixin_test.js * (edit) ambari-web/app/mixins/common/table_server_mixin.js * (edit) ambari-web/app/mixins/common/table_server_view_mixin.js * (edit) ambari-web/app/views/common/table_view.js * (edit) ambari-web/test/views/main/host_test.js * (edit) ambari-web/test/views/common/table_view_test.js > Sometimes the Hosts page shows a different page for page 1 > -- > > Key: AMBARI-20255 > URL: https://issues.apache.org/jira/browse/AMBARI-20255 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20255_branch-2.5.patch, > AMBARI-20255_branch-2.5_v2.patch, AMBARI-20255.patch, > AMBARI-20255_trunk_add.patch, page2-showing-page1-b.png > > > I've seen cases where you go back to the Hosts page and the paging filter on > the bottom is showing page 1, but page 2 results are shown. > Repro scenario: > * Go to Hosts page > * Apply a valid filter (Host Status: Slave Down) > * Go to page 2 > * Click on "Services" from the top nav > * Go back to Hosts page. Initially, the hosts from the original filter are > shown (but the filter is cleared). Then the hosts with no filters show up, > but the page is still showing 2 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20255) Sometimes the Hosts page shows a different page for page 1
[ https://issues.apache.org/jira/browse/AMBARI-20255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898106#comment-15898106 ] Hudson commented on AMBARI-20255: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #6959 (See [https://builds.apache.org/job/Ambari-trunk-Commit/6959/]) AMBARI-20255 Sometimes the Hosts page shows a different page for page 1 (atkach: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=34df7650207e957a38a5067f1553b753a00297e3]) * (edit) ambari-web/app/mixins/common/table_server_view_mixin.js * (edit) ambari-web/app/mixins/common/table_server_mixin.js * (edit) ambari-web/test/mixins/common/table_server_view_mixin_test.js > Sometimes the Hosts page shows a different page for page 1 > -- > > Key: AMBARI-20255 > URL: https://issues.apache.org/jira/browse/AMBARI-20255 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20255_branch-2.5.patch, > AMBARI-20255_branch-2.5_v2.patch, AMBARI-20255.patch, > AMBARI-20255_trunk_add.patch, page2-showing-page1-b.png > > > I've seen cases where you go back to the Hosts page and the paging filter on > the bottom is showing page 1, but page 2 results are shown. > Repro scenario: > * Go to Hosts page > * Apply a valid filter (Host Status: Slave Down) > * Go to page 2 > * Click on "Services" from the top nav > * Go back to Hosts page. Initially, the hosts from the original filter are > shown (but the filter is cleared). Then the hosts with no filters show up, > but the page is still showing 2 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20317) Update stack advisor logic for getting enable atlas hook flag value
[ https://issues.apache.org/jira/browse/AMBARI-20317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898105#comment-15898105 ] Hudson commented on AMBARI-20317: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #6959 (See [https://builds.apache.org/job/Ambari-trunk-Commit/6959/]) AMBARI-20317. Update stack advisor logic for getting enable atlas hook (smohanty: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=f60c4ccfa841457bb6e253b478e3b0d51b48e131]) * (edit) ambari-server/src/main/resources/common-services/SQOOP/1.4.4.2.0/configuration/sqoop-site.xml * (edit) ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py > Update stack advisor logic for getting enable atlas hook flag value > --- > > Key: AMBARI-20317 > URL: https://issues.apache.org/jira/browse/AMBARI-20317 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.5.0 >Reporter: Mugdha Varadkar >Assignee: Mugdha Varadkar >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20317.patch > > > Stack advisor recommendation for atlas hooks not working as expected due to > AMBARI-20304 changes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20329) After restarting Ranger, PAM files are overwritten by default template
[ https://issues.apache.org/jira/browse/AMBARI-20329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shi Wang updated AMBARI-20329: -- Description: AMBARI-18425 add PAM support for ranger authentication in Ambari, but it relies on the default template and not allow user configure the pam file by ambari. Therefore when restart ranger admin the custom pam file content will be overwritten by the default template. > After restarting Ranger, PAM files are overwritten by default template > -- > > Key: AMBARI-20329 > URL: https://issues.apache.org/jira/browse/AMBARI-20329 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.5.0 >Reporter: Shi Wang >Assignee: Shi Wang > > AMBARI-18425 add PAM support for ranger authentication in Ambari, but it > relies on the default template and not allow user configure the pam file by > ambari. Therefore when restart ranger admin the custom pam file content will > be overwritten by the default template. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20255) Sometimes the Hosts page shows a different page for page 1
[
https://issues.apache.org/jira/browse/AMBARI-20255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898063#comment-15898063
]
Hadoop QA commented on AMBARI-20255:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12856336/AMBARI-20255_trunk_add.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/10900//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/10900//console
This message is automatically generated.
> Sometimes the Hosts page shows a different page for page 1
> --
>
> Key: AMBARI-20255
> URL: https://issues.apache.org/jira/browse/AMBARI-20255
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20255_branch-2.5.patch,
> AMBARI-20255_branch-2.5_v2.patch, AMBARI-20255.patch,
> AMBARI-20255_trunk_add.patch, page2-showing-page1-b.png
>
>
> I've seen cases where you go back to the Hosts page and the paging filter on
> the bottom is showing page 1, but page 2 results are shown.
> Repro scenario:
> * Go to Hosts page
> * Apply a valid filter (Host Status: Slave Down)
> * Go to page 2
> * Click on "Services" from the top nav
> * Go back to Hosts page. Initially, the hosts from the original filter are
> shown (but the filter is cleared). Then the hosts with no filters show up,
> but the page is still showing 2
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMBARI-20317) Update stack advisor logic for getting enable atlas hook flag value
[ https://issues.apache.org/jira/browse/AMBARI-20317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898058#comment-15898058 ] Hudson commented on AMBARI-20317: - SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #1195 (See [https://builds.apache.org/job/Ambari-branch-2.5/1195/]) AMBARI-20317. Update stack advisor logic for getting enable atlas hook (smohanty: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=1b8b91dc87a0694cb7b3aa3a55829a90b202bb35]) * (edit) ambari-server/src/main/resources/common-services/SQOOP/1.4.4.2.0/configuration/sqoop-site.xml * (edit) ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py > Update stack advisor logic for getting enable atlas hook flag value > --- > > Key: AMBARI-20317 > URL: https://issues.apache.org/jira/browse/AMBARI-20317 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.5.0 >Reporter: Mugdha Varadkar >Assignee: Mugdha Varadkar >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20317.patch > > > Stack advisor recommendation for atlas hooks not working as expected due to > AMBARI-20304 changes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-19433) Increase default timeout and threadpool size for the external script to work on slower machines
[ https://issues.apache.org/jira/browse/AMBARI-19433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898054#comment-15898054 ] Hudson commented on AMBARI-19433: - SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #1195 (See [https://builds.apache.org/job/Ambari-branch-2.5/1195/]) AMBARI-19433. Increase default timeout and threadpool size for the (jaimin: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=23bd4187cb8442bcc06fd20469e9f8b77158a4cf]) * (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClientConfigResourceProvider.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java > Increase default timeout and threadpool size for the external script to work > on slower machines > --- > > Key: AMBARI-19433 > URL: https://issues.apache.org/jira/browse/AMBARI-19433 > Project: Ambari > Issue Type: Task >Affects Versions: 2.5.0 >Reporter: Jaimin Jetly >Assignee: Jaimin Jetly > Fix For: 2.5.0 > > Attachments: AMBARI-19433.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-20332) Few ambari agent unit tests are failing
Yesha Vora created AMBARI-20332:
---
Summary: Few ambari agent unit tests are failing
Key: AMBARI-20332
URL: https://issues.apache.org/jira/browse/AMBARI-20332
Project: Ambari
Issue Type: Bug
Components: test
Reporter: Yesha Vora
Few ambari agent tests are failing as below.
{code:title=test cmd}
export MAVEN_OPTS="-Xmx8192m -XX:MaxPermSize=4096m"; mvn -B -nsu -DforkCount=4
-Dmaven.test.failure.ignore=true -fae clean test {code}
{code}
==
ERROR: test_may_manage_folder (TestDatanodeHelper.TestDatanodeHelper)
--
Traceback (most recent call last):
File "/xxx/ambari/ambari-common/src/test/python/mock/mock.py", line 1199, in
patched
return func(*args, **keywargs)
File
"/xxx/ambari/ambari-agent/src/test/python/resource_management/TestDatanodeHelper.py",
line 179, in test_may_manage_folder
self.assertSetEqual(dirs_unmounted, set())
AttributeError: 'TestDatanodeHelper' object has no attribute 'assertSetEqual'
==
FAIL: test_kill_process_with_children (TestShell.TestShell)
--
Traceback (most recent call last):
File "/xxx/ambari/ambari-agent/src/test/python/ambari_agent/TestShell.py",
line 71, in test_kill_process_with_children
self.assertTrue(sleep_cmd in out)
AssertionError
==
FAIL: test_facterMemInfoOutput (TestHardware.TestHardware)
--
Traceback (most recent call last):
File "/xxx/ambari/ambari-common/src/test/python/mock/mock.py", line 1199, in
patched
return func(*args, **keywargs)
File "/xxx/ambari/ambari-agent/src/test/python/ambari_agent/TestHardware.py",
line 247, in test_facterMemInfoOutput
self.assertEquals(result['memorysize'], 1832392)
AssertionError: u'4194304' != 1832392
--
Ran 448 tests in 15.028s
FAILED (failures=2, errors=1)
[INFO] {code}
{code}
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Ambari Main SUCCESS [ 7.696 s]
[INFO] Apache Ambari Project POM .. SUCCESS [ 0.213 s]
[INFO] Ambari Web . SUCCESS [02:07 min]
[INFO] Ambari Views ... SUCCESS [ 6.316 s]
[INFO] Ambari Admin View .. SUCCESS [01:17 min]
[INFO] utility SUCCESS [ 3.209 s]
[INFO] ambari-metrics . SUCCESS [ 1.427 s]
[INFO] Ambari Metrics Common .. SUCCESS [ 5.610 s]
[INFO] Ambari Metrics Hadoop Sink . SUCCESS [ 7.023 s]
[INFO] Ambari Metrics Flume Sink .. SUCCESS [ 5.797 s]
[INFO] Ambari Metrics Kafka Sink .. SUCCESS [ 4.710 s]
[INFO] Ambari Metrics Storm Sink .. SUCCESS [ 2.895 s]
[INFO] Ambari Metrics Storm Sink (Legacy) . SUCCESS [ 3.642 s]
[INFO] Ambari Metrics Collector ... SUCCESS [07:18 min]
[INFO] Ambari Metrics Monitor . SUCCESS [ 5.923 s]
[INFO] Ambari Metrics Grafana . SUCCESS [ 3.769 s]
[INFO] Ambari Metrics Assembly SUCCESS [ 7.651 s]
[INFO] Ambari Server .. FAILURE [15:35 min]
[INFO] Ambari Functional Tests SKIPPED
[INFO] Ambari Agent ... FAILURE [ 42.590 s]
[INFO] Ambari Client .. SUCCESS [ 0.068 s]
[INFO] Ambari Python Client ... SUCCESS [ 2.080 s]
[INFO] Ambari Groovy Client ... SUCCESS [ 17.194 s]
[INFO] Ambari Shell ... SUCCESS [ 0.044 s]
[INFO] Ambari Python Shell SUCCESS [ 0.232 s]
[INFO] Ambari Groovy Shell SUCCESS [ 10.669 s]
[INFO] ambari-logsearch ... SUCCESS [ 0.171 s]
[INFO] Ambari Logsearch Appender .. SUCCESS [ 0.418 s]
[INFO] Ambari Logsearch Portal SUCCESS [ 15.327 s]
[INFO] Ambari Logsearch Log Feeder SUCCESS [ 9.812 s]
[INFO] Ambari Logsearch Solr Client ... SUCCESS [ 2.240 s]
[INFO] Ambari Infra Solr Plugin ...
[jira] [Created] (AMBARI-20331) testSafeCreateCommandNotExisting UT fails
Yesha Vora created AMBARI-20331:
---
Summary: testSafeCreateCommandNotExisting UT fails
Key: AMBARI-20331
URL: https://issues.apache.org/jira/browse/AMBARI-20331
Project: Ambari
Issue Type: Bug
Components: test
Reporter: Yesha Vora
testSafeCreateCommandNotExisting is failing with below error.
{code}
Error Message
org/apache/commons/io/Charsets
Stacktrace
java.lang.NoClassDefFoundError: org/apache/commons/io/Charsets
at
org.apache.ambari.server.credentialapi.CredentialUtilTest.executeCommand(CredentialUtilTest.java:215)
at
org.apache.ambari.server.credentialapi.CredentialUtilTest.testSafeCreateCommandNotExisting(CredentialUtilTest.java:350)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.io.Charsets
at
org.apache.ambari.server.credentialapi.CredentialUtilTest.executeCommand(CredentialUtilTest.java:215)
at
org.apache.ambari.server.credentialapi.CredentialUtilTest.testSafeCreateCommandNotExisting(CredentialUtilTest.java:350){code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (AMBARI-20330) testThreadPoolEnabledPropertyProviderDefaults & testMetricsRetrieveServiceDefaults UT is failing
Yesha Vora created AMBARI-20330:
---
Summary: testThreadPoolEnabledPropertyProviderDefaults &
testMetricsRetrieveServiceDefaults UT is failing
Key: AMBARI-20330
URL: https://issues.apache.org/jira/browse/AMBARI-20330
Project: Ambari
Issue Type: Bug
Components: test
Reporter: Yesha Vora
testThreadPoolEnabledPropertyProviderDefaults &
testMetricsRetrieveServiceDefaults UT is failing with below error
{code}
Stacktrace
junit.framework.AssertionFailedError
at
org.apache.ambari.server.configuration.ConfigurationTest.testMetricsRetrieveServiceDefaults(ConfigurationTest.java:905)
Standard Output
2017-03-06 19:18:42,262 INFO [main] configuration.Configuration
(Configuration.java:(2906)) - Reading password from existing file{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20329) After restarting Ranger, PAM files are overwritten by default template
[ https://issues.apache.org/jira/browse/AMBARI-20329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shi Wang updated AMBARI-20329: -- Affects Version/s: 2.5.0 > After restarting Ranger, PAM files are overwritten by default template > -- > > Key: AMBARI-20329 > URL: https://issues.apache.org/jira/browse/AMBARI-20329 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.5.0 >Reporter: Shi Wang >Assignee: Shi Wang > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-20329) After restarting Ranger, PAM files are overwritten by default template
Shi Wang created AMBARI-20329: - Summary: After restarting Ranger, PAM files are overwritten by default template Key: AMBARI-20329 URL: https://issues.apache.org/jira/browse/AMBARI-20329 Project: Ambari Issue Type: Bug Reporter: Shi Wang Assignee: Shi Wang -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20255) Sometimes the Hosts page shows a different page for page 1
[ https://issues.apache.org/jira/browse/AMBARI-20255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Tkach updated AMBARI-20255: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Sometimes the Hosts page shows a different page for page 1 > -- > > Key: AMBARI-20255 > URL: https://issues.apache.org/jira/browse/AMBARI-20255 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20255_branch-2.5.patch, > AMBARI-20255_branch-2.5_v2.patch, AMBARI-20255.patch, > AMBARI-20255_trunk_add.patch, page2-showing-page1-b.png > > > I've seen cases where you go back to the Hosts page and the paging filter on > the bottom is showing page 1, but page 2 results are shown. > Repro scenario: > * Go to Hosts page > * Apply a valid filter (Host Status: Slave Down) > * Go to page 2 > * Click on "Services" from the top nav > * Go back to Hosts page. Initially, the hosts from the original filter are > shown (but the filter is cleared). Then the hosts with no filters show up, > but the page is still showing 2 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-19433) Increase default timeout and threadpool size for the external script to work on slower machines
[ https://issues.apache.org/jira/browse/AMBARI-19433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898026#comment-15898026 ] Hudson commented on AMBARI-19433: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #6958 (See [https://builds.apache.org/job/Ambari-trunk-Commit/6958/]) AMBARI-19433. Increase default timeout and threadpool size for the (jaimin: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=cf3321b4e43f3fd31239c27d763415271627687a]) * (edit) ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClientConfigResourceProvider.java > Increase default timeout and threadpool size for the external script to work > on slower machines > --- > > Key: AMBARI-19433 > URL: https://issues.apache.org/jira/browse/AMBARI-19433 > Project: Ambari > Issue Type: Task >Affects Versions: 2.5.0 >Reporter: Jaimin Jetly >Assignee: Jaimin Jetly > Fix For: 2.5.0 > > Attachments: AMBARI-19433.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20255) Sometimes the Hosts page shows a different page for page 1
[ https://issues.apache.org/jira/browse/AMBARI-20255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898021#comment-15898021 ] Andrii Tkach commented on AMBARI-20255: --- committed to trunk and branch-2.5 > Sometimes the Hosts page shows a different page for page 1 > -- > > Key: AMBARI-20255 > URL: https://issues.apache.org/jira/browse/AMBARI-20255 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20255_branch-2.5.patch, > AMBARI-20255_branch-2.5_v2.patch, AMBARI-20255.patch, > AMBARI-20255_trunk_add.patch, page2-showing-page1-b.png > > > I've seen cases where you go back to the Hosts page and the paging filter on > the bottom is showing page 1, but page 2 results are shown. > Repro scenario: > * Go to Hosts page > * Apply a valid filter (Host Status: Slave Down) > * Go to page 2 > * Click on "Services" from the top nav > * Go back to Hosts page. Initially, the hosts from the original filter are > shown (but the filter is cleared). Then the hosts with no filters show up, > but the page is still showing 2 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20255) Sometimes the Hosts page shows a different page for page 1
[ https://issues.apache.org/jira/browse/AMBARI-20255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898015#comment-15898015 ] Denys Buzhor commented on AMBARI-20255: --- +1 for additional patch. > Sometimes the Hosts page shows a different page for page 1 > -- > > Key: AMBARI-20255 > URL: https://issues.apache.org/jira/browse/AMBARI-20255 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20255_branch-2.5.patch, > AMBARI-20255_branch-2.5_v2.patch, AMBARI-20255.patch, > AMBARI-20255_trunk_add.patch, page2-showing-page1-b.png > > > I've seen cases where you go back to the Hosts page and the paging filter on > the bottom is showing page 1, but page 2 results are shown. > Repro scenario: > * Go to Hosts page > * Apply a valid filter (Host Status: Slave Down) > * Go to page 2 > * Click on "Services" from the top nav > * Go back to Hosts page. Initially, the hosts from the original filter are > shown (but the filter is cleared). Then the hosts with no filters show up, > but the page is still showing 2 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20255) Sometimes the Hosts page shows a different page for page 1
[
https://issues.apache.org/jira/browse/AMBARI-20255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897988#comment-15897988
]
Hadoop QA commented on AMBARI-20255:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12856336/AMBARI-20255_trunk_add.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/10899//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/10899//console
This message is automatically generated.
> Sometimes the Hosts page shows a different page for page 1
> --
>
> Key: AMBARI-20255
> URL: https://issues.apache.org/jira/browse/AMBARI-20255
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20255_branch-2.5.patch,
> AMBARI-20255_branch-2.5_v2.patch, AMBARI-20255.patch,
> AMBARI-20255_trunk_add.patch, page2-showing-page1-b.png
>
>
> I've seen cases where you go back to the Hosts page and the paging filter on
> the bottom is showing page 1, but page 2 results are shown.
> Repro scenario:
> * Go to Hosts page
> * Apply a valid filter (Host Status: Slave Down)
> * Go to page 2
> * Click on "Services" from the top nav
> * Go back to Hosts page. Initially, the hosts from the original filter are
> shown (but the filter is cleared). Then the hosts with no filters show up,
> but the page is still showing 2
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMBARI-20308) Atlas service check fails during EU on wire encrypted cluster
[
https://issues.apache.org/jira/browse/AMBARI-20308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897960#comment-15897960
]
Hudson commented on AMBARI-20308:
-
FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1194 (See
[https://builds.apache.org/job/Ambari-branch-2.5/1194/])
Revert "AMBARI-20308 - Atlas service check fails during EU on wire (jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=e19f57e83c387c21109dfe4bda0e0e146db2e60e])
* (delete)
ambari-server/src/main/resources/stacks/HDP/2.5/services/ATLAS/configuration/application-properties.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.5.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/config-upgrade.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.6.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.6.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.6/services/ATLAS/configuration/application-properties.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.5.xml
AMBARI-20308 - Atlas service check fails during EU on wire encrypted (jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=8e68824473cf68b5129ead6f81d4d9e5b9cfdc8f])
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/config-upgrade.xml
* (add)
ambari-server/src/main/resources/stacks/HDP/2.5/services/ATLAS/configuration/application-properties.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.6.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.5.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.6.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.6/services/ATLAS/configuration/application-properties.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.5.xml
> Atlas service check fails during EU on wire encrypted cluster
> -
>
> Key: AMBARI-20308
> URL: https://issues.apache.org/jira/browse/AMBARI-20308
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vivek Sharma
>Assignee: Jonathan Hurley
>Priority: Critical
> Labels: express_upgrade
> Fix For: 2.5.0
>
> Attachments: AMBARI-20308.patch
>
>
> STR
> 1. Deployed cluster with Ambari version: 2.4.2.0-136 and HDP version:
> 2.5.3.0-37 (wire encrypted cluster)
> 2. Upgrade Ambari to 2.5.0.0-1030 and then start EU to 2.6
> 3. Observed following failure at Atlas service check
> {code}
> 2017-03-02 13:22:41,729 - ATLAS service check failed for host atlas_host with
> error Execution of 'curl -k --negotiate -u : -b ~/cookiejar.txt -c
> ~/cookiejar.txt -s -o /dev/null -w "%{http_code}" https://atlas_host:21443/'
> returned 35. Hortonworks #
> This is MOTD message, added for testing in qe infra
> 000
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/service_check.py",
> line 52, in
> AtlasServiceCheck().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 313, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/service_check.py",
> line 48, in service_check
> raise Fail("All instances of ATLAS METADATA SERVER are down.")
> resource_management.core.exceptions.Fail: All instances of ATLAS METADATA
> SERVER are down.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20317) Update stack advisor logic for getting enable atlas hook flag value
[ https://issues.apache.org/jira/browse/AMBARI-20317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-20317: --- Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk and branch-2.5 > Update stack advisor logic for getting enable atlas hook flag value > --- > > Key: AMBARI-20317 > URL: https://issues.apache.org/jira/browse/AMBARI-20317 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.5.0 >Reporter: Mugdha Varadkar >Assignee: Mugdha Varadkar >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20317.patch > > > Stack advisor recommendation for atlas hooks not working as expected due to > AMBARI-20304 changes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20278) Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not selected" but it is selected
[ https://issues.apache.org/jira/browse/AMBARI-20278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897935#comment-15897935 ] Antonenko Alexander commented on AMBARI-20278: -- committed to trunk > Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not > selected" but it is selected > > > Key: AMBARI-20278 > URL: https://issues.apache.org/jira/browse/AMBARI-20278 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20278_additional_trunk_fix.patch, > AMBARI-20278.patch, Screen Shot 2017-02-27 at 1.43.56 PM.png > > > See attached. > Most likely, I didn't select Ambari Infra originally, but then I cancelled > out of the series of warning popups. > Then I selected Ambari Infra. The warning does not go away. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (AMBARI-18952) Register BackupObserver and BackupHFileCleaner
[ https://issues.apache.org/jira/browse/AMBARI-18952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884466#comment-15884466 ] Ted Yu edited comment on AMBARI-18952 at 3/6/17 7:50 PM: - Note: There is cost when BackupObserver is registered - it would poll backup table (at the end of bulk load per region) for whether the underlying table has gone thru full backup. was (Author: yuzhih...@gmail.com): Note: There is cost when BackupObserver is registered - it would poll backup table (at the end of bulk load per region) for whether the underlying table has gone thru full backup. > Register BackupObserver and BackupHFileCleaner > -- > > Key: AMBARI-18952 > URL: https://issues.apache.org/jira/browse/AMBARI-18952 > Project: Ambari > Issue Type: Improvement >Reporter: Ted Yu > > Over in HBASE-14417, two new classes are added. > org.apache.hadoop.hbase.backup.BackupHFileCleaner should be registered > through hbase.master.hfilecleaner.plugins . It is responsible for keeping > bulk loaded hfiles so that incremental backup can pick them up. > org.apache.hadoop.hbase.backup.BackupObserver should be registered through > hbase.coprocessor.region.classes > It is notified when bulk load completes and writes records into hbase:backup > table. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-20328) HDP 3.0 TP - Support changed configs and scripts for HBase
Alejandro Fernandez created AMBARI-20328: Summary: HDP 3.0 TP - Support changed configs and scripts for HBase Key: AMBARI-20328 URL: https://issues.apache.org/jira/browse/AMBARI-20328 Project: Ambari Issue Type: Story Components: stacks Affects Versions: 3.0.0 Reporter: Alejandro Fernandez Assignee: Alejandro Fernandez Fix For: 3.0.0 In HDP 3.0, there are expected changes to configs and the startup scripts for HDFS. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-20327) HDP 3.0 TP - create Service Advisor for HBase
Alejandro Fernandez created AMBARI-20327: Summary: HDP 3.0 TP - create Service Advisor for HBase Key: AMBARI-20327 URL: https://issues.apache.org/jira/browse/AMBARI-20327 Project: Ambari Issue Type: Story Components: stacks Affects Versions: 3.0.0 Reporter: Alejandro Fernandez Assignee: Alejandro Fernandez Fix For: 3.0.0 Create a Service Advisor script for HBase in HDP 3.0 Tech Preview. The Service Advisor must encapsulate all of the logic inherited/overwritten from HDP 2.0.6 through HDP 2.6 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-19433) Increase default timeout and threadpool size for the external script to work on slower machines
[ https://issues.apache.org/jira/browse/AMBARI-19433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin Jetly updated AMBARI-19433: -- Resolution: Fixed Status: Resolved (was: Patch Available) Patch committed to trunk and branch-2.5 > Increase default timeout and threadpool size for the external script to work > on slower machines > --- > > Key: AMBARI-19433 > URL: https://issues.apache.org/jira/browse/AMBARI-19433 > Project: Ambari > Issue Type: Task >Affects Versions: 2.5.0 >Reporter: Jaimin Jetly >Assignee: Jaimin Jetly > Fix For: 2.5.0 > > Attachments: AMBARI-19433.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-20326) HDP 3.0 support for HBase with configs, kerberos, widgets, metrics, quicklinks, and themes
Alejandro Fernandez created AMBARI-20326: Summary: HDP 3.0 support for HBase with configs, kerberos, widgets, metrics, quicklinks, and themes Key: AMBARI-20326 URL: https://issues.apache.org/jira/browse/AMBARI-20326 Project: Ambari Issue Type: Story Components: stacks Affects Versions: 3.0.0 Reporter: Alejandro Fernandez Assignee: Alejandro Fernandez Fix For: 3.0.0 HDP 3.0 support for Hbase with configs, kerberos, widgets, metrics, quicklinks, and themes.' Flatten from HDP 2.0.6 - 2.6 into common-services, and reference in HDP 3.0. In HDP 3.0, we have created a new stack definition that does not inherit from other stacks, in order to reduce the complexity of having to analyze older stacks. This means that we need to create a service definition (metainfo.xml, configs, kerberos, widgets, metrics, quicklinks, and themes) that is equivalent to what is inherit and deleted from all of the previous stacks. A merge needs to account for additions, overrides, and deletions. metainfo.xml and configs perform a merge of older versions kerberos.json always seems to override the previous file Because the bits for this service may not yet be available in the HDP 3.0 repo, the task is to ensure that /api/v1/stacks/HDP/versions/2.6/services/HBASE(which uses inheritance) is equivalent to the flattening of /api/v1/stacks/HDP/versions/3.0/services/HBASE . Please take a look at how this was done for ZK, HDFS, and YARN/MR. This means that you will not be able to actually install the service for now, but can still perform validation during the Install Wizard that the correct components and configs show up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20278) Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not selected" but it is selected
[ https://issues.apache.org/jira/browse/AMBARI-20278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897905#comment-15897905 ] Hudson commented on AMBARI-20278: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #6957 (See [https://builds.apache.org/job/Ambari-trunk-Commit/6957/]) AMBARI-20278. Install Wizard > Select Services: Ambari warns me that (hiveww: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=649ca2b825b235660c36015b51d136dca5d564a5]) * (edit) ambari-web/app/controllers/wizard/step4_controller.js > Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not > selected" but it is selected > > > Key: AMBARI-20278 > URL: https://issues.apache.org/jira/browse/AMBARI-20278 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20278_additional_trunk_fix.patch, > AMBARI-20278.patch, Screen Shot 2017-02-27 at 1.43.56 PM.png > > > See attached. > Most likely, I didn't select Ambari Infra originally, but then I cancelled > out of the series of warning popups. > Then I selected Ambari Infra. The warning does not go away. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-20325) Ambari should be able to detect misconfiguration of Http/Https related configs
Yesha Vora created AMBARI-20325:
---
Summary: Ambari should be able to detect misconfiguration of
Http/Https related configs
Key: AMBARI-20325
URL: https://issues.apache.org/jira/browse/AMBARI-20325
Project: Ambari
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Yesha Vora
Priority: Critical
When user tries to misconfigure any component, ambari should validate and give
necessary error messages.
* When user enable/disable https for a service, ambari should recommend and
validate configs
* subsequently if user tries to misconfigure any port then appropriate
validation should be done
Example:
When Yarn http/https properties are misconfigured, it can break Quick links.
Ambari was not able to detect this misconfiguration. Ambari should add proper
validation for such scenario.
Steps to reproduce: ( HA cluster)
* Set yarn.resourcemanager.webapp.https.address to 8090. Set
yarn.resourcemanager.webapp.https.address.rm1 and
yarn.resourcemanager.webapp.https.address.rm2 to have port = 8088.
This is wrong configuration.
{code}
yarn.resourcemanager.webapp.https.address
xxx1:8090
yarn.resourcemanager.webapp.https.address.rm1
xxx1:8088
yarn.resourcemanager.webapp.https.address.rm2
xxx2:8088
{code}
Expected behavior:
When user tries to modify Https related config incorrectly, ambari should be
able to detect that and throw an warning/error message stating the correct
reason such as "port mentioned in yarn.resourcemanager.webapp.https.address is
not same as yarn.resourcemanager.webapp.https.address.rm1/rm2."
Actual behavior:
Ambari perform no validation for such misconfiguration and allows user to
misconfigure the cluster without any warning.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20255) Sometimes the Hosts page shows a different page for page 1
[ https://issues.apache.org/jira/browse/AMBARI-20255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Tkach updated AMBARI-20255: -- Status: Patch Available (was: Reopened) > Sometimes the Hosts page shows a different page for page 1 > -- > > Key: AMBARI-20255 > URL: https://issues.apache.org/jira/browse/AMBARI-20255 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20255_branch-2.5.patch, > AMBARI-20255_branch-2.5_v2.patch, AMBARI-20255.patch, > AMBARI-20255_trunk_add.patch, page2-showing-page1-b.png > > > I've seen cases where you go back to the Hosts page and the paging filter on > the bottom is showing page 1, but page 2 results are shown. > Repro scenario: > * Go to Hosts page > * Apply a valid filter (Host Status: Slave Down) > * Go to page 2 > * Click on "Services" from the top nav > * Go back to Hosts page. Initially, the hosts from the original filter are > shown (but the filter is cleared). Then the hosts with no filters show up, > but the page is still showing 2 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20255) Sometimes the Hosts page shows a different page for page 1
[ https://issues.apache.org/jira/browse/AMBARI-20255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Tkach updated AMBARI-20255: -- Attachment: AMBARI-20255_trunk_add.patch > Sometimes the Hosts page shows a different page for page 1 > -- > > Key: AMBARI-20255 > URL: https://issues.apache.org/jira/browse/AMBARI-20255 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20255_branch-2.5.patch, > AMBARI-20255_branch-2.5_v2.patch, AMBARI-20255.patch, > AMBARI-20255_trunk_add.patch, page2-showing-page1-b.png > > > I've seen cases where you go back to the Hosts page and the paging filter on > the bottom is showing page 1, but page 2 results are shown. > Repro scenario: > * Go to Hosts page > * Apply a valid filter (Host Status: Slave Down) > * Go to page 2 > * Click on "Services" from the top nav > * Go back to Hosts page. Initially, the hosts from the original filter are > shown (but the filter is cleared). Then the hosts with no filters show up, > but the page is still showing 2 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20308) Atlas service check fails during EU on wire encrypted cluster
[
https://issues.apache.org/jira/browse/AMBARI-20308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897866#comment-15897866
]
Hudson commented on AMBARI-20308:
-
FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1193 (See
[https://builds.apache.org/job/Ambari-branch-2.5/1193/])
AMBARI-20308 - Atlas service check fails during EU on wire encrypted (jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=d8901e26c3f5cf45011d700cb44d73ea67c86d20])
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.5.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.6.xml
* (add)
ambari-server/src/main/resources/stacks/HDP/2.5/services/ATLAS/configuration/application-properties.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.6/services/ATLAS/configuration/application-properties.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.6.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/config-upgrade.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.5.xml
> Atlas service check fails during EU on wire encrypted cluster
> -
>
> Key: AMBARI-20308
> URL: https://issues.apache.org/jira/browse/AMBARI-20308
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vivek Sharma
>Assignee: Jonathan Hurley
>Priority: Critical
> Labels: express_upgrade
> Fix For: 2.5.0
>
> Attachments: AMBARI-20308.patch
>
>
> STR
> 1. Deployed cluster with Ambari version: 2.4.2.0-136 and HDP version:
> 2.5.3.0-37 (wire encrypted cluster)
> 2. Upgrade Ambari to 2.5.0.0-1030 and then start EU to 2.6
> 3. Observed following failure at Atlas service check
> {code}
> 2017-03-02 13:22:41,729 - ATLAS service check failed for host atlas_host with
> error Execution of 'curl -k --negotiate -u : -b ~/cookiejar.txt -c
> ~/cookiejar.txt -s -o /dev/null -w "%{http_code}" https://atlas_host:21443/'
> returned 35. Hortonworks #
> This is MOTD message, added for testing in qe infra
> 000
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/service_check.py",
> line 52, in
> AtlasServiceCheck().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 313, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/service_check.py",
> line 48, in service_check
> raise Fail("All instances of ATLAS METADATA SERVER are down.")
> resource_management.core.exceptions.Fail: All instances of ATLAS METADATA
> SERVER are down.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20255) Sometimes the Hosts page shows a different page for page 1
[ https://issues.apache.org/jira/browse/AMBARI-20255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Tkach updated AMBARI-20255: -- Attachment: AMBARI-20255_branch-2.5_v2.patch > Sometimes the Hosts page shows a different page for page 1 > -- > > Key: AMBARI-20255 > URL: https://issues.apache.org/jira/browse/AMBARI-20255 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20255_branch-2.5.patch, > AMBARI-20255_branch-2.5_v2.patch, AMBARI-20255.patch, > page2-showing-page1-b.png > > > I've seen cases where you go back to the Hosts page and the paging filter on > the bottom is showing page 1, but page 2 results are shown. > Repro scenario: > * Go to Hosts page > * Apply a valid filter (Host Status: Slave Down) > * Go to page 2 > * Click on "Services" from the top nav > * Go back to Hosts page. Initially, the hosts from the original filter are > shown (but the filter is cleared). Then the hosts with no filters show up, > but the page is still showing 2 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20308) Atlas service check fails during EU on wire encrypted cluster
[
https://issues.apache.org/jira/browse/AMBARI-20308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897816#comment-15897816
]
Hadoop QA commented on AMBARI-20308:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12856316/AMBARI-20308.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/10897//console
This message is automatically generated.
> Atlas service check fails during EU on wire encrypted cluster
> -
>
> Key: AMBARI-20308
> URL: https://issues.apache.org/jira/browse/AMBARI-20308
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vivek Sharma
>Assignee: Jonathan Hurley
>Priority: Critical
> Labels: express_upgrade
> Fix For: 2.5.0
>
> Attachments: AMBARI-20308.patch
>
>
> STR
> 1. Deployed cluster with Ambari version: 2.4.2.0-136 and HDP version:
> 2.5.3.0-37 (wire encrypted cluster)
> 2. Upgrade Ambari to 2.5.0.0-1030 and then start EU to 2.6
> 3. Observed following failure at Atlas service check
> {code}
> 2017-03-02 13:22:41,729 - ATLAS service check failed for host atlas_host with
> error Execution of 'curl -k --negotiate -u : -b ~/cookiejar.txt -c
> ~/cookiejar.txt -s -o /dev/null -w "%{http_code}" https://atlas_host:21443/'
> returned 35. Hortonworks #
> This is MOTD message, added for testing in qe infra
> 000
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/service_check.py",
> line 52, in
> AtlasServiceCheck().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 313, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/service_check.py",
> line 48, in service_check
> raise Fail("All instances of ATLAS METADATA SERVER are down.")
> resource_management.core.exceptions.Fail: All instances of ATLAS METADATA
> SERVER are down.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMBARI-20278) Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not selected" but it is selected
[
https://issues.apache.org/jira/browse/AMBARI-20278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897811#comment-15897811
]
Hadoop QA commented on AMBARI-20278:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12856303/AMBARI-20278_additional_trunk_fix.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/10896//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/10896//console
This message is automatically generated.
> Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not
> selected" but it is selected
>
>
> Key: AMBARI-20278
> URL: https://issues.apache.org/jira/browse/AMBARI-20278
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20278_additional_trunk_fix.patch,
> AMBARI-20278.patch, Screen Shot 2017-02-27 at 1.43.56 PM.png
>
>
> See attached.
> Most likely, I didn't select Ambari Infra originally, but then I cancelled
> out of the series of warning popups.
> Then I selected Ambari Infra. The warning does not go away.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMBARI-20309) HBase Master CPU Utilization Alert is in unknown state due to kinit error
[
https://issues.apache.org/jira/browse/AMBARI-20309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897773#comment-15897773
]
Hudson commented on AMBARI-20309:
-
SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #6956 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/6956/])
AMBARI-20309. HBase Master CPU Utilization Alert is in unknown state due
(rlevas:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=6cfcc90acfaced9cbcefe8abaa1a5d98a2db20ad])
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog250Test.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog250.java
* (edit)
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/alerts.json
> HBase Master CPU Utilization Alert is in unknown state due to kinit error
> -
>
> Key: AMBARI-20309
> URL: https://issues.apache.org/jira/browse/AMBARI-20309
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: alerts, kerberos
> Fix For: 2.5.0
>
> Attachments: AMBARI-20309_branch-2.5_01.patch,
> AMBARI-20309_branch-2.5_02.patch, AMBARI-20309_trunk_01.patch,
> AMBARI-20309_trunk_02.patch
>
>
> HBase Master CPU Utilization Alert is in unknown state due to kinit error:
> {noformat}
> Execution of '/usr/bin/kinit -c
> /var/lib/ambari-agent/tmp/curl_krb_cache/metric_alert_ambari-qa_cc_56787c2122a8214ca9775f3433361f8b
> -kt HTTP/_h...@example.com /etc/security/keytabs/spnego.service.keytab >
> /dev/null' returned 1. kinit: Client not found in Kerberos database while
> getting initial credentials
> {noformat}
> This issue is also seen in /var/log/krb5kdc.log:
> {noformat}
> Mar 03 16:43:06 c6401.ambari.apache.org krb5kdc[4749](info): AS_REQ (4 etypes
> {18 17 16 23}) 192.168.64.101: CLIENT_NOT_FOUND:
> /etc/security/keytabs/spnego.service.key...@example.com for
> krbtgt/example@example.com, Client not found in Kerberos database
> {noformat}
> *Cause*
> It appears that the HBASE alerts.json file
> ({{common-services/HBASE/0.96.0.2.0/alerts.json}}) has swapped values for the
> {{kerberos_keytab}} and {{kerberos_principal}} properties.
> {code}
> {
> "name": "hbase_master_cpu",
> "label": "HBase Master CPU Utilization",
> "description": "This host-level alert is triggered if CPU utilization
> of the HBase Master exceeds certain warning and critical thresholds. It
> checks the HBase Master JMX Servlet for the SystemCPULoad property. The
> threshold values are in percent.",
> "interval": 5,
> "scope": "ANY",
> "enabled": true,
> "source": {
> "type": "METRIC",
> "uri": {
> "http": "{{hbase-site/hbase.master.info.port}}",
> "default_port": 60010,
> "connection_timeout": 5.0,
> "kerberos_keytab":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.principal}}",
> "kerberos_principal":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.keytab}}"
> },
> "reporting": {
> "ok": {
> "text": "{1} CPU, load {0:.1%}"
> },
> "warning": {
> "text": "{1} CPU, load {0:.1%}",
> "value": 200
> },
> "critical": {
> "text": "{1} CPU, load {0:.1%}",
> "value": 250
> },
> "units" : "%",
> "type": "PERCENT"
> },
> "jmx": {
> "property_list": [
> "java.lang:type=OperatingSystem/SystemCpuLoad",
> "java.lang:type=OperatingSystem/AvailableProcessors"
> ],
> "value": "{0} * 100"
> }
> }
> }
> {code}
> Notice:
> {code}
> "kerberos_keytab":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.principal}}",
> "kerberos_principal":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.keytab}}"
> {code}
> *Solution*
> Fix values for the {{kerberos_keytab}} and {{kerberos_principal}} properties
> in {{common-services/HBASE/0.96.0.2.0/alerts.json}}:
> {code}
> "kerberos_principal":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.principal}}",
> "kerberos_keytab":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.keytab}}"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMBARI-20308) Atlas service check fails during EU on wire encrypted cluster
[
https://issues.apache.org/jira/browse/AMBARI-20308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897774#comment-15897774
]
Hudson commented on AMBARI-20308:
-
SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #6956 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/6956/])
AMBARI-20308 - Atlas service check fails during EU on wire encrypted (jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=9d38b66d1bc015896b82ea6e6e89e1f9bfee79ac])
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.6.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.5.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.5.xml
* (add)
ambari-server/src/main/resources/stacks/HDP/2.5/services/ATLAS/configuration/application-properties.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.6/services/ATLAS/configuration/application-properties.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.6.xml
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/config-upgrade.xml
> Atlas service check fails during EU on wire encrypted cluster
> -
>
> Key: AMBARI-20308
> URL: https://issues.apache.org/jira/browse/AMBARI-20308
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vivek Sharma
>Assignee: Jonathan Hurley
>Priority: Critical
> Labels: express_upgrade
> Fix For: 2.5.0
>
> Attachments: AMBARI-20308.patch
>
>
> STR
> 1. Deployed cluster with Ambari version: 2.4.2.0-136 and HDP version:
> 2.5.3.0-37 (wire encrypted cluster)
> 2. Upgrade Ambari to 2.5.0.0-1030 and then start EU to 2.6
> 3. Observed following failure at Atlas service check
> {code}
> 2017-03-02 13:22:41,729 - ATLAS service check failed for host atlas_host with
> error Execution of 'curl -k --negotiate -u : -b ~/cookiejar.txt -c
> ~/cookiejar.txt -s -o /dev/null -w "%{http_code}" https://atlas_host:21443/'
> returned 35. Hortonworks #
> This is MOTD message, added for testing in qe infra
> 000
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/service_check.py",
> line 52, in
> AtlasServiceCheck().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 313, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/service_check.py",
> line 48, in service_check
> raise Fail("All instances of ATLAS METADATA SERVER are down.")
> resource_management.core.exceptions.Fail: All instances of ATLAS METADATA
> SERVER are down.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMBARI-20309) HBase Master CPU Utilization Alert is in unknown state due to kinit error
[
https://issues.apache.org/jira/browse/AMBARI-20309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897767#comment-15897767
]
Hudson commented on AMBARI-20309:
-
FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #1192 (See
[https://builds.apache.org/job/Ambari-branch-2.5/1192/])
AMBARI-20309. HBase Master CPU Utilization Alert is in unknown state due
(rlevas:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=e8956590389cf1c8e6a3942747710223ff3a5d34])
* (edit)
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/alerts.json
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog250Test.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog250.java
> HBase Master CPU Utilization Alert is in unknown state due to kinit error
> -
>
> Key: AMBARI-20309
> URL: https://issues.apache.org/jira/browse/AMBARI-20309
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: alerts, kerberos
> Fix For: 2.5.0
>
> Attachments: AMBARI-20309_branch-2.5_01.patch,
> AMBARI-20309_branch-2.5_02.patch, AMBARI-20309_trunk_01.patch,
> AMBARI-20309_trunk_02.patch
>
>
> HBase Master CPU Utilization Alert is in unknown state due to kinit error:
> {noformat}
> Execution of '/usr/bin/kinit -c
> /var/lib/ambari-agent/tmp/curl_krb_cache/metric_alert_ambari-qa_cc_56787c2122a8214ca9775f3433361f8b
> -kt HTTP/_h...@example.com /etc/security/keytabs/spnego.service.keytab >
> /dev/null' returned 1. kinit: Client not found in Kerberos database while
> getting initial credentials
> {noformat}
> This issue is also seen in /var/log/krb5kdc.log:
> {noformat}
> Mar 03 16:43:06 c6401.ambari.apache.org krb5kdc[4749](info): AS_REQ (4 etypes
> {18 17 16 23}) 192.168.64.101: CLIENT_NOT_FOUND:
> /etc/security/keytabs/spnego.service.key...@example.com for
> krbtgt/example@example.com, Client not found in Kerberos database
> {noformat}
> *Cause*
> It appears that the HBASE alerts.json file
> ({{common-services/HBASE/0.96.0.2.0/alerts.json}}) has swapped values for the
> {{kerberos_keytab}} and {{kerberos_principal}} properties.
> {code}
> {
> "name": "hbase_master_cpu",
> "label": "HBase Master CPU Utilization",
> "description": "This host-level alert is triggered if CPU utilization
> of the HBase Master exceeds certain warning and critical thresholds. It
> checks the HBase Master JMX Servlet for the SystemCPULoad property. The
> threshold values are in percent.",
> "interval": 5,
> "scope": "ANY",
> "enabled": true,
> "source": {
> "type": "METRIC",
> "uri": {
> "http": "{{hbase-site/hbase.master.info.port}}",
> "default_port": 60010,
> "connection_timeout": 5.0,
> "kerberos_keytab":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.principal}}",
> "kerberos_principal":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.keytab}}"
> },
> "reporting": {
> "ok": {
> "text": "{1} CPU, load {0:.1%}"
> },
> "warning": {
> "text": "{1} CPU, load {0:.1%}",
> "value": 200
> },
> "critical": {
> "text": "{1} CPU, load {0:.1%}",
> "value": 250
> },
> "units" : "%",
> "type": "PERCENT"
> },
> "jmx": {
> "property_list": [
> "java.lang:type=OperatingSystem/SystemCpuLoad",
> "java.lang:type=OperatingSystem/AvailableProcessors"
> ],
> "value": "{0} * 100"
> }
> }
> }
> {code}
> Notice:
> {code}
> "kerberos_keytab":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.principal}}",
> "kerberos_principal":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.keytab}}"
> {code}
> *Solution*
> Fix values for the {{kerberos_keytab}} and {{kerberos_principal}} properties
> in {{common-services/HBASE/0.96.0.2.0/alerts.json}}:
> {code}
> "kerberos_principal":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.principal}}",
> "kerberos_keytab":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.keytab}}"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMBARI-19429) Create an ODPi stack definition
[ https://issues.apache.org/jira/browse/AMBARI-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897768#comment-15897768 ] Roman Shaposhnik commented on AMBARI-19429: --- [~jluniya] I really like your idea of turning this into a management pack so we can have independent release cycles from Ambari. Can you, please, take a first pass at turning the stack into the pack (since I'm sure it'll take less time for you than it would for me). I can most definitely help with testing it, etc. > Create an ODPi stack definition > --- > > Key: AMBARI-19429 > URL: https://issues.apache.org/jira/browse/AMBARI-19429 > Project: Ambari > Issue Type: Improvement > Components: stacks >Affects Versions: 2.4.2 >Reporter: Roman Shaposhnik >Assignee: Roman Shaposhnik > Fix For: trunk > > Attachments: AMBARI-19429.patch2.gz, AMBARI-19429.patch.gz > > > ODPi is a nonprofit organization committed to simplification & > standardization of the big data ecosystem with common reference > specifications and test suites. As part of its mission, ODPi has been > developing a series of specifications for how to integrate upstream Apache > projects into the coherent platform. Part of this standardization effort is > maintenance of the ODPi core stack definition which today includes: >* Apache Zookeeper >* Apache Hadoop >* Apache Hive > and has been maintained as a custom stack on ODPi side: > > https://github.com/odpi/bigtop/tree/odpi-master/bigtop-packages/src/common/ambari/ODPi/1.0 > In conjunction with merge effort for Apache Bigtop BIGTOP-2666 I'd like to > propose that instead of migrating the stack definition to Bigtop, we should > actually migrate it to Ambari. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-19835) HDP 3.0 support for Slider with configs, kerberos, widgets, metrics, quicklinks, and themes
[
https://issues.apache.org/jira/browse/AMBARI-19835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897750#comment-15897750
]
Hadoop QA commented on AMBARI-19835:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12856257/AMBARI-19835_2.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/10895//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/10895//console
This message is automatically generated.
> HDP 3.0 support for Slider with configs, kerberos, widgets, metrics,
> quicklinks, and themes
> ---
>
> Key: AMBARI-19835
> URL: https://issues.apache.org/jira/browse/AMBARI-19835
> Project: Ambari
> Issue Type: Story
> Components: stacks
>Affects Versions: 3.0.0
>Reporter: Alejandro Fernandez
>Assignee: Dmytro Sen
> Fix For: 3.0.0
>
> Attachments: AMBARI-19835_2.patch
>
>
> HDP 3.0 support for Slider with configs, kerberos, widgets, metrics,
> quicklinks, and themes
> Flatten from HDP 2.0.6 - 2.6 into common-services, and reference in HDP 3.0
> In HDP 3.0, we have created a new stack definition that does not inherit from
> other stacks, in order to reduce the complexity of having to analyze older
> stacks.
> This means that we need to create a service definition (metainfo.xml,
> configs, kerberos, widgets, metrics, quicklinks, and themes) that is
> equivalent to what is inherit and deleted from all of the previous stacks.
> A merge needs to account for additions, overrides, and deletions.
> metainfo.xml and configs perform a merge of older versions
> kerberos.json always seems to override the previous file
> Because the bits for this service may not yet be available in the HDP 3.0
> repo,
> the task is to ensure that /api/v1/stacks/HDP/versions/2.6/services/SLIDER
> (which uses inheritance) is equivalent to the flattening of
> /api/v1/stacks/HDP/versions/3.0/services/SLIDER .
> Please take a look at how this was done for ZK, HDFS, and YARN/MR.
> This means that you will not be able to actually install the service for now,
> but can still perform validation during the Install Wizard that the correct
> components and configs show up.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20324) Wrong permissions on /var/run/ambari-server when not running as root
[ https://issues.apache.org/jira/browse/AMBARI-20324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Björn Busse updated AMBARI-20324: - Summary: Wrong permissions on /var/run/ambari-server when not running as root (was: hdp: Wrong permissions on /var/run/ambari-server when not running as root) > Wrong permissions on /var/run/ambari-server when not running as root > > > Key: AMBARI-20324 > URL: https://issues.apache.org/jira/browse/AMBARI-20324 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.1 >Reporter: Björn Busse > > /var/run/ambari-server has wrong permissions when not running as root. > The user under which ambari-server is running (ambari-server.user) should own > /var/run/ambari-server > $ cat /etc/ambari-server/conf/ambari.properties | grep server.user > ambari-server.user=ambari -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20324) hdp: Wrong permissions on /var/run/ambari-server when not running as root
[ https://issues.apache.org/jira/browse/AMBARI-20324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897738#comment-15897738 ] Björn Busse commented on AMBARI-20324: -- This leads to errors e.g. when installing new services: "Error occured during stack advisor command invocation: Cannot create /var/run/ambari-server/stack-recommendations" because /var/run/ambari-server is owned by root:root > hdp: Wrong permissions on /var/run/ambari-server when not running as root > - > > Key: AMBARI-20324 > URL: https://issues.apache.org/jira/browse/AMBARI-20324 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.1 >Reporter: Björn Busse > > /var/run/ambari-server has wrong permissions when not running as root. > The user under which ambari-server is running (ambari-server.user) should own > /var/run/ambari-server > $ cat /etc/ambari-server/conf/ambari.properties | grep server.user > ambari-server.user=ambari -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-20324) hdp: Wrong permissions on /var/run/ambari-server when not running as root
Björn Busse created AMBARI-20324: Summary: hdp: Wrong permissions on /var/run/ambari-server when not running as root Key: AMBARI-20324 URL: https://issues.apache.org/jira/browse/AMBARI-20324 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.4.1 Reporter: Björn Busse /var/run/ambari-server has wrong permissions when not running as root. The user under which ambari-server is running (ambari-server.user) should own /var/run/ambari-server $ cat /etc/ambari-server/conf/ambari.properties | grep server.user ambari-server.user=ambari -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20304) Services shows as Restart required after upgrading from Ambari-2.4.x to 2.5.0.
[ https://issues.apache.org/jira/browse/AMBARI-20304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897724#comment-15897724 ] Hudson commented on AMBARI-20304: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #6955 (See [https://builds.apache.org/job/Ambari-trunk-Commit/6955/]) AMBARI-20304. Services shows as Restart required after upgrading from (dlysnichenko: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=801cd6147ffd5cf1aff067a3970f341df2f6eead]) * (edit) ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-env.xml * (edit) ambari-server/src/main/resources/common-services/STORM/0.10.0/configuration/storm-env.xml * (edit) ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/configuration/falcon-env.xml * (edit) ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/configuration/yarn-site.xml * (edit) ambari-server/src/main/resources/stacks/HDP/2.0.6.GlusterFS/services/YARN/configuration/yarn-site.xml * (edit) ambari-server/src/main/resources/stacks/HDP/2.1.GlusterFS/services/YARN/configuration/yarn-site.xml * (edit) ambari-server/src/main/resources/stacks/BIGTOP/0.8/services/YARN/configuration/yarn-site.xml * (edit) ambari-server/src/main/resources/common-services/SQOOP/1.4.4.2.0/configuration/sqoop-env.xml > Services shows as Restart required after upgrading from Ambari-2.4.x to 2.5.0. > -- > > Key: AMBARI-20304 > URL: https://issues.apache.org/jira/browse/AMBARI-20304 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.5.0 >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20304.patch > > > Properties are added during upgrade to 2.5 > * falcon.atlas.hook > * hive.atlas.hook > * sqoop.atlas.hook > * storm.atlas.hook > * yarn.nodemanager.log.retain-seconds -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20323) Commands timed-out on ambari host without any error logs
[ https://issues.apache.org/jira/browse/AMBARI-20323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eugene Chekanskiy updated AMBARI-20323: --- Status: Patch Available (was: Open) > Commands timed-out on ambari host without any error logs > > > Key: AMBARI-20323 > URL: https://issues.apache.org/jira/browse/AMBARI-20323 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.5.0 >Reporter: Eugene Chekanskiy >Assignee: Eugene Chekanskiy >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20323.patch > > > Ambari-agent stop execution commands. It is happend because of threads > blocking due to broken multiprocessing.Queue after killing > StatusCommandsExecutor. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20291) Script-Based Alert Dispatchers support passing more parameters to script
[ https://issues.apache.org/jira/browse/AMBARI-20291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897723#comment-15897723 ] Hudson commented on AMBARI-20291: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #6955 (See [https://builds.apache.org/job/Ambari-trunk-Commit/6955/]) AMBARI-20291 - Script-Based Alert Dispatchers support passing more (jhurley: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=41906e593cca9ea5a9fa6d413d2ca1f5a5dcbd32]) * (edit) ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/state/services/AlertNoticeDispatchService.java > Script-Based Alert Dispatchers support passing more parameters to script > > > Key: AMBARI-20291 > URL: https://issues.apache.org/jira/browse/AMBARI-20291 > Project: Ambari > Issue Type: Improvement >Affects Versions: trunk >Reporter: Yao Lei >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-20291_2.patch > > > Script-Based Alert Dispatcher now pass five parameters to script,including > alert definition name, definition label,service name, alert state, and alert > text. > But if script can receive other two parameters from dispather,it will be > better. > 1.hostname. > Because hostname the alert for is not always included in alert text,although > it may be null like aggregate alerts. > With it we can more quick to find the related host that occured alert. > 2.alert timestamp. > We may need to know the alert occurrence time ( state change time) more > exactly. After the alert happened,it will spend some time to schedule the > script to run. > Without it,we can only regard the script start time as the alert occurrence > time. > We now use this feature to send alert information to mobile phone and suggest > also passing hostname and alert timestamp. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20180) HDFS SecurityLogger messages are logged twice
[ https://issues.apache.org/jira/browse/AMBARI-20180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897719#comment-15897719 ] Arpit Agarwal commented on AMBARI-20180: This change probably requires no new unit tests. Hi [~afernandez], could you please help commit it? > HDFS SecurityLogger messages are logged twice > - > > Key: AMBARI-20180 > URL: https://issues.apache.org/jira/browse/AMBARI-20180 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.5.0 >Reporter: Arpit Agarwal >Assignee: Arpit Agarwal > Fix For: 2.5.0 > > Attachments: AMBARI-20180.01.patch > > > HDFS SecurityLogger messages are logged twice, once each in the > SecurityAuth.audit log and the NameNode service log. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20304) Services shows as Restart required after upgrading from Ambari-2.4.x to 2.5.0.
[ https://issues.apache.org/jira/browse/AMBARI-20304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897717#comment-15897717 ] Hudson commented on AMBARI-20304: - SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #1191 (See [https://builds.apache.org/job/Ambari-branch-2.5/1191/]) AMBARI-20304. Services shows as Restart required after upgrading from (dlysnichenko: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=84e767ba0064029ed323d193625b165e0cf621dd]) * (edit) ambari-server/src/main/resources/stacks/HDP/2.0.6.GlusterFS/services/YARN/configuration/yarn-site.xml * (edit) ambari-server/src/main/resources/common-services/SQOOP/1.4.4.2.0/configuration/sqoop-env.xml * (edit) ambari-server/src/main/resources/common-services/STORM/0.10.0/configuration/storm-env.xml * (edit) ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/configuration/falcon-env.xml * (edit) ambari-server/src/main/resources/stacks/BIGTOP/0.8/services/YARN/configuration/yarn-site.xml * (edit) ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-env.xml * (edit) ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/configuration/yarn-site.xml * (edit) ambari-server/src/main/resources/stacks/HDP/2.1.GlusterFS/services/YARN/configuration/yarn-site.xml > Services shows as Restart required after upgrading from Ambari-2.4.x to 2.5.0. > -- > > Key: AMBARI-20304 > URL: https://issues.apache.org/jira/browse/AMBARI-20304 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.5.0 >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20304.patch > > > Properties are added during upgrade to 2.5 > * falcon.atlas.hook > * hive.atlas.hook > * sqoop.atlas.hook > * storm.atlas.hook > * yarn.nodemanager.log.retain-seconds -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20323) Commands timed-out on ambari host without any error logs
[ https://issues.apache.org/jira/browse/AMBARI-20323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eugene Chekanskiy updated AMBARI-20323: --- Attachment: AMBARI-20323.patch > Commands timed-out on ambari host without any error logs > > > Key: AMBARI-20323 > URL: https://issues.apache.org/jira/browse/AMBARI-20323 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.5.0 >Reporter: Eugene Chekanskiy >Assignee: Eugene Chekanskiy >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20323.patch > > > Ambari-agent stop execution commands. It is happend because of threads > blocking due to broken multiprocessing.Queue after killing > StatusCommandsExecutor. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-20323) Commands timed-out on ambari host without any error logs
Eugene Chekanskiy created AMBARI-20323: -- Summary: Commands timed-out on ambari host without any error logs Key: AMBARI-20323 URL: https://issues.apache.org/jira/browse/AMBARI-20323 Project: Ambari Issue Type: Bug Components: ambari-agent Affects Versions: 2.5.0 Reporter: Eugene Chekanskiy Assignee: Eugene Chekanskiy Priority: Critical Fix For: 2.5.0 Ambari-agent stop execution commands. It is happend because of threads blocking due to broken multiprocessing.Queue after killing StatusCommandsExecutor. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20309) HBase Master CPU Utilization Alert is in unknown state due to kinit error
[
https://issues.apache.org/jira/browse/AMBARI-20309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-20309:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed to trunk
{noformat}
commit 6cfcc90acfaced9cbcefe8abaa1a5d98a2db20ad
Author: Robert Levas
Date: Mon Mar 6 12:27:23 2017 -0500
{noformat}
Committed to branch-2.5
{noformat}
commit e8956590389cf1c8e6a3942747710223ff3a5d34
Author: Robert Levas
Date: Mon Mar 6 12:30:26 2017 -0500
{noformat}
> HBase Master CPU Utilization Alert is in unknown state due to kinit error
> -
>
> Key: AMBARI-20309
> URL: https://issues.apache.org/jira/browse/AMBARI-20309
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: alerts, kerberos
> Fix For: 2.5.0
>
> Attachments: AMBARI-20309_branch-2.5_01.patch,
> AMBARI-20309_branch-2.5_02.patch, AMBARI-20309_trunk_01.patch,
> AMBARI-20309_trunk_02.patch
>
>
> HBase Master CPU Utilization Alert is in unknown state due to kinit error:
> {noformat}
> Execution of '/usr/bin/kinit -c
> /var/lib/ambari-agent/tmp/curl_krb_cache/metric_alert_ambari-qa_cc_56787c2122a8214ca9775f3433361f8b
> -kt HTTP/_h...@example.com /etc/security/keytabs/spnego.service.keytab >
> /dev/null' returned 1. kinit: Client not found in Kerberos database while
> getting initial credentials
> {noformat}
> This issue is also seen in /var/log/krb5kdc.log:
> {noformat}
> Mar 03 16:43:06 c6401.ambari.apache.org krb5kdc[4749](info): AS_REQ (4 etypes
> {18 17 16 23}) 192.168.64.101: CLIENT_NOT_FOUND:
> /etc/security/keytabs/spnego.service.key...@example.com for
> krbtgt/example@example.com, Client not found in Kerberos database
> {noformat}
> *Cause*
> It appears that the HBASE alerts.json file
> ({{common-services/HBASE/0.96.0.2.0/alerts.json}}) has swapped values for the
> {{kerberos_keytab}} and {{kerberos_principal}} properties.
> {code}
> {
> "name": "hbase_master_cpu",
> "label": "HBase Master CPU Utilization",
> "description": "This host-level alert is triggered if CPU utilization
> of the HBase Master exceeds certain warning and critical thresholds. It
> checks the HBase Master JMX Servlet for the SystemCPULoad property. The
> threshold values are in percent.",
> "interval": 5,
> "scope": "ANY",
> "enabled": true,
> "source": {
> "type": "METRIC",
> "uri": {
> "http": "{{hbase-site/hbase.master.info.port}}",
> "default_port": 60010,
> "connection_timeout": 5.0,
> "kerberos_keytab":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.principal}}",
> "kerberos_principal":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.keytab}}"
> },
> "reporting": {
> "ok": {
> "text": "{1} CPU, load {0:.1%}"
> },
> "warning": {
> "text": "{1} CPU, load {0:.1%}",
> "value": 200
> },
> "critical": {
> "text": "{1} CPU, load {0:.1%}",
> "value": 250
> },
> "units" : "%",
> "type": "PERCENT"
> },
> "jmx": {
> "property_list": [
> "java.lang:type=OperatingSystem/SystemCpuLoad",
> "java.lang:type=OperatingSystem/AvailableProcessors"
> ],
> "value": "{0} * 100"
> }
> }
> }
> {code}
> Notice:
> {code}
> "kerberos_keytab":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.principal}}",
> "kerberos_principal":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.keytab}}"
> {code}
> *Solution*
> Fix values for the {{kerberos_keytab}} and {{kerberos_principal}} properties
> in {{common-services/HBASE/0.96.0.2.0/alerts.json}}:
> {code}
> "kerberos_principal":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.principal}}",
> "kerberos_keytab":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.keytab}}"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMBARI-20319) Server startup script keeps waiting even if DB consistency has failed
[
https://issues.apache.org/jira/browse/AMBARI-20319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897698#comment-15897698
]
Hadoop QA commented on AMBARI-20319:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12856291/AMBARI-20319-Startup_errors-trunk-v1.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/10893//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/10893//console
This message is automatically generated.
> Server startup script keeps waiting even if DB consistency has failed
> -
>
> Key: AMBARI-20319
> URL: https://issues.apache.org/jira/browse/AMBARI-20319
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 3.0.0, 2.5.0
>Reporter: Balázs Bence Sári
>Assignee: Balázs Bence Sári
>Priority: Minor
> Fix For: 3.0.0, 2.5.0
>
> Attachments: AMBARI-20319-Startup_errors-trunk-v1.patch
>
>
> The current logic of the Ambari server startup script:
> 1. Wait for java server process PID
> 2. Java process starts Database check
> 3. Script waits until UI becomes available or timeout occurs
> If DB check fails, the script waits some 50 seconds for the UI, before
> timeout occurs, although it should fail instantly in this case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20308) Atlas service check fails during EU on wire encrypted cluster
[
https://issues.apache.org/jira/browse/AMBARI-20308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-20308:
-
Attachment: AMBARI-20308.patch
> Atlas service check fails during EU on wire encrypted cluster
> -
>
> Key: AMBARI-20308
> URL: https://issues.apache.org/jira/browse/AMBARI-20308
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vivek Sharma
>Assignee: Jonathan Hurley
>Priority: Critical
> Labels: express_upgrade
> Fix For: 2.5.0
>
> Attachments: AMBARI-20308.patch
>
>
> STR
> 1. Deployed cluster with Ambari version: 2.4.2.0-136 and HDP version:
> 2.5.3.0-37 (wire encrypted cluster)
> 2. Upgrade Ambari to 2.5.0.0-1030 and then start EU to 2.6
> 3. Observed following failure at Atlas service check
> {code}
> 2017-03-02 13:22:41,729 - ATLAS service check failed for host atlas_host with
> error Execution of 'curl -k --negotiate -u : -b ~/cookiejar.txt -c
> ~/cookiejar.txt -s -o /dev/null -w "%{http_code}" https://atlas_host:21443/'
> returned 35. Hortonworks #
> This is MOTD message, added for testing in qe infra
> 000
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/service_check.py",
> line 52, in
> AtlasServiceCheck().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 313, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/service_check.py",
> line 48, in service_check
> raise Fail("All instances of ATLAS METADATA SERVER are down.")
> resource_management.core.exceptions.Fail: All instances of ATLAS METADATA
> SERVER are down.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20308) Atlas service check fails during EU on wire encrypted cluster
[
https://issues.apache.org/jira/browse/AMBARI-20308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-20308:
-
Attachment: (was: AMBARI-20308.patch)
> Atlas service check fails during EU on wire encrypted cluster
> -
>
> Key: AMBARI-20308
> URL: https://issues.apache.org/jira/browse/AMBARI-20308
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vivek Sharma
>Assignee: Jonathan Hurley
>Priority: Critical
> Labels: express_upgrade
> Fix For: 2.5.0
>
> Attachments: AMBARI-20308.patch
>
>
> STR
> 1. Deployed cluster with Ambari version: 2.4.2.0-136 and HDP version:
> 2.5.3.0-37 (wire encrypted cluster)
> 2. Upgrade Ambari to 2.5.0.0-1030 and then start EU to 2.6
> 3. Observed following failure at Atlas service check
> {code}
> 2017-03-02 13:22:41,729 - ATLAS service check failed for host atlas_host with
> error Execution of 'curl -k --negotiate -u : -b ~/cookiejar.txt -c
> ~/cookiejar.txt -s -o /dev/null -w "%{http_code}" https://atlas_host:21443/'
> returned 35. Hortonworks #
> This is MOTD message, added for testing in qe infra
> 000
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/service_check.py",
> line 52, in
> AtlasServiceCheck().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 313, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/common-services/ATLAS/0.1.0.2.3/package/scripts/service_check.py",
> line 48, in service_check
> raise Fail("All instances of ATLAS METADATA SERVER are down.")
> resource_management.core.exceptions.Fail: All instances of ATLAS METADATA
> SERVER are down.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20322) HDP 3.0 TP - create Service Advisor for Slider
[ https://issues.apache.org/jira/browse/AMBARI-20322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-20322: - Summary: HDP 3.0 TP - create Service Advisor for Slider (was: HDP 3.0 TP - support for Slider with configs, kerberos, widgets, metrics, quicklinks, and themes) > HDP 3.0 TP - create Service Advisor for Slider > -- > > Key: AMBARI-20322 > URL: https://issues.apache.org/jira/browse/AMBARI-20322 > Project: Ambari > Issue Type: Story > Components: stacks >Affects Versions: 3.0.0 >Reporter: Alejandro Fernandez > Fix For: 3.0.0 > > > HDP 3.0 support for Slider with configs, kerberos, widgets, metrics, > quicklinks, and themes > Flatten from HDP 2.0.6 - 2.6 into common-services, and reference in HDP 3.0 > In HDP 3.0, we have created a new stack definition that does not inherit from > other stacks, in order to reduce the complexity of having to analyze older > stacks. > This means that we need to create a service definition (metainfo.xml, > configs, kerberos, widgets, metrics, quicklinks, and themes) that is > equivalent to what is inherit and deleted from all of the previous stacks. > A merge needs to account for additions, overrides, and deletions. > metainfo.xml and configs perform a merge of older versions > kerberos.json always seems to override the previous file > Because the bits for this service may not yet be available in the HDP 3.0 > repo, > the task is to ensure that /api/v1/stacks/HDP/versions/2.6/services/SLIDER > (which uses inheritance) is equivalent to the flattening of > /api/v1/stacks/HDP/versions/3.0/services/SLIDER . > Please take a look at how this was done for ZK, HDFS, and YARN/MR. > This means that you will not be able to actually install the service for now, > but can still perform validation during the Install Wizard that the correct > components and configs show up. > Slider is being added to the HDP 3.0 stack temporarily in order to unblock > Hive LLAP. Later in the HDP 3.0 release, Slider RPM will be part of YARN. We > may still keep Slider as a Service, but it may move as a component of YARN > instead. > Slider version in common services is 0.91.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20322) HDP 3.0 TP - create Service Advisor for Slider
[ https://issues.apache.org/jira/browse/AMBARI-20322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-20322: - Description: Create a Service Advisor script for Slider in HDP 3.0 Tech Preview. The Service Advisor must encapsulate all of the logic inherited/overwritten from HDP 2.0.6 through HDP 2.6 Slider is being added to the HDP 3.0 stack temporarily in order to unblock Hive LLAP. Later in the HDP 3.0 release, Slider RPM will be part of YARN. We may still keep Slider as a Service, but it may move as a component of YARN instead. was: HDP 3.0 support for Slider with configs, kerberos, widgets, metrics, quicklinks, and themes Flatten from HDP 2.0.6 - 2.6 into common-services, and reference in HDP 3.0 In HDP 3.0, we have created a new stack definition that does not inherit from other stacks, in order to reduce the complexity of having to analyze older stacks. This means that we need to create a service definition (metainfo.xml, configs, kerberos, widgets, metrics, quicklinks, and themes) that is equivalent to what is inherit and deleted from all of the previous stacks. A merge needs to account for additions, overrides, and deletions. metainfo.xml and configs perform a merge of older versions kerberos.json always seems to override the previous file Because the bits for this service may not yet be available in the HDP 3.0 repo, the task is to ensure that /api/v1/stacks/HDP/versions/2.6/services/SLIDER (which uses inheritance) is equivalent to the flattening of /api/v1/stacks/HDP/versions/3.0/services/SLIDER . Please take a look at how this was done for ZK, HDFS, and YARN/MR. This means that you will not be able to actually install the service for now, but can still perform validation during the Install Wizard that the correct components and configs show up. Slider is being added to the HDP 3.0 stack temporarily in order to unblock Hive LLAP. Later in the HDP 3.0 release, Slider RPM will be part of YARN. We may still keep Slider as a Service, but it may move as a component of YARN instead. Slider version in common services is 0.91.0 > HDP 3.0 TP - create Service Advisor for Slider > -- > > Key: AMBARI-20322 > URL: https://issues.apache.org/jira/browse/AMBARI-20322 > Project: Ambari > Issue Type: Story > Components: stacks >Affects Versions: 3.0.0 >Reporter: Alejandro Fernandez > Fix For: 3.0.0 > > > Create a Service Advisor script for Slider in HDP 3.0 Tech Preview. > The Service Advisor must encapsulate all of the logic inherited/overwritten > from HDP 2.0.6 through HDP 2.6 > Slider is being added to the HDP 3.0 stack temporarily in order to unblock > Hive LLAP. Later in the HDP 3.0 release, Slider RPM will be part of YARN. We > may still keep Slider as a Service, but it may move as a component of YARN > instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20322) HDP 3.0 TP - support for Slider with configs, kerberos, widgets, metrics, quicklinks, and themes
[ https://issues.apache.org/jira/browse/AMBARI-20322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-20322: - Description: HDP 3.0 support for Slider with configs, kerberos, widgets, metrics, quicklinks, and themes Flatten from HDP 2.0.6 - 2.6 into common-services, and reference in HDP 3.0 In HDP 3.0, we have created a new stack definition that does not inherit from other stacks, in order to reduce the complexity of having to analyze older stacks. This means that we need to create a service definition (metainfo.xml, configs, kerberos, widgets, metrics, quicklinks, and themes) that is equivalent to what is inherit and deleted from all of the previous stacks. A merge needs to account for additions, overrides, and deletions. metainfo.xml and configs perform a merge of older versions kerberos.json always seems to override the previous file Because the bits for this service may not yet be available in the HDP 3.0 repo, the task is to ensure that /api/v1/stacks/HDP/versions/2.6/services/SLIDER (which uses inheritance) is equivalent to the flattening of /api/v1/stacks/HDP/versions/3.0/services/SLIDER . Please take a look at how this was done for ZK, HDFS, and YARN/MR. This means that you will not be able to actually install the service for now, but can still perform validation during the Install Wizard that the correct components and configs show up. Slider is being added to the HDP 3.0 stack temporarily in order to unblock Hive LLAP. Later in the HDP 3.0 release, Slider RPM will be part of YARN. We may still keep Slider as a Service, but it may move as a component of YARN instead. Slider version in common services is 0.91.0 was: Create a Service Advisor script for Slider in HDP 3.0 Tech Preview. The Service Advisor must encapsulate all of the logic inherited/overwritten from HDP 2.0.6 through HDP 2.6 Slider is being added to the HDP 3.0 stack temporarily in order to unblock Hive LLAP. Later in the HDP 3.0 release, Slider RPM will be part of YARN. We may still keep Slider as a Service, but it may move as a component of YARN instead. > HDP 3.0 TP - support for Slider with configs, kerberos, widgets, metrics, > quicklinks, and themes > > > Key: AMBARI-20322 > URL: https://issues.apache.org/jira/browse/AMBARI-20322 > Project: Ambari > Issue Type: Story > Components: stacks >Affects Versions: 3.0.0 >Reporter: Alejandro Fernandez > Fix For: 3.0.0 > > > HDP 3.0 support for Slider with configs, kerberos, widgets, metrics, > quicklinks, and themes > Flatten from HDP 2.0.6 - 2.6 into common-services, and reference in HDP 3.0 > In HDP 3.0, we have created a new stack definition that does not inherit from > other stacks, in order to reduce the complexity of having to analyze older > stacks. > This means that we need to create a service definition (metainfo.xml, > configs, kerberos, widgets, metrics, quicklinks, and themes) that is > equivalent to what is inherit and deleted from all of the previous stacks. > A merge needs to account for additions, overrides, and deletions. > metainfo.xml and configs perform a merge of older versions > kerberos.json always seems to override the previous file > Because the bits for this service may not yet be available in the HDP 3.0 > repo, > the task is to ensure that /api/v1/stacks/HDP/versions/2.6/services/SLIDER > (which uses inheritance) is equivalent to the flattening of > /api/v1/stacks/HDP/versions/3.0/services/SLIDER . > Please take a look at how this was done for ZK, HDFS, and YARN/MR. > This means that you will not be able to actually install the service for now, > but can still perform validation during the Install Wizard that the correct > components and configs show up. > Slider is being added to the HDP 3.0 stack temporarily in order to unblock > Hive LLAP. Later in the HDP 3.0 release, Slider RPM will be part of YARN. We > may still keep Slider as a Service, but it may move as a component of YARN > instead. > Slider version in common services is 0.91.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-20322) HDP 3.0 TP - support for Slider with configs, kerberos, widgets, metrics, quicklinks, and themes
Alejandro Fernandez created AMBARI-20322: Summary: HDP 3.0 TP - support for Slider with configs, kerberos, widgets, metrics, quicklinks, and themes Key: AMBARI-20322 URL: https://issues.apache.org/jira/browse/AMBARI-20322 Project: Ambari Issue Type: Story Components: stacks Affects Versions: 3.0.0 Reporter: Alejandro Fernandez Fix For: 3.0.0 Create a Service Advisor script for Slider in HDP 3.0 Tech Preview. The Service Advisor must encapsulate all of the logic inherited/overwritten from HDP 2.0.6 through HDP 2.6 Slider is being added to the HDP 3.0 stack temporarily in order to unblock Hive LLAP. Later in the HDP 3.0 release, Slider RPM will be part of YARN. We may still keep Slider as a Service, but it may move as a component of YARN instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20291) Script-Based Alert Dispatchers support passing more parameters to script
[
https://issues.apache.org/jira/browse/AMBARI-20291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-20291:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
{code}
commit 41906e593cca9ea5a9fa6d413d2ca1f5a5dcbd32 (origin/trunk, origin/HEAD)
Author: Jonathan Hurley
Date: Mon Mar 6 11:13:34 2017 -0500
AMBARI-20291 - Script-Based Alert Dispatchers support passing more
parameters to script (Yao Lei via jonathanhurley)
{code}
> Script-Based Alert Dispatchers support passing more parameters to script
>
>
> Key: AMBARI-20291
> URL: https://issues.apache.org/jira/browse/AMBARI-20291
> Project: Ambari
> Issue Type: Improvement
>Affects Versions: trunk
>Reporter: Yao Lei
>Priority: Minor
> Fix For: trunk
>
> Attachments: AMBARI-20291_2.patch
>
>
> Script-Based Alert Dispatcher now pass five parameters to script,including
> alert definition name, definition label,service name, alert state, and alert
> text.
> But if script can receive other two parameters from dispather,it will be
> better.
> 1.hostname.
> Because hostname the alert for is not always included in alert text,although
> it may be null like aggregate alerts.
> With it we can more quick to find the related host that occured alert.
> 2.alert timestamp.
> We may need to know the alert occurrence time ( state change time) more
> exactly. After the alert happened,it will spend some time to schedule the
> script to run.
> Without it,we can only regard the script start time as the alert occurrence
> time.
> We now use this feature to send alert information to mobile phone and suggest
> also passing hostname and alert timestamp.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20304) Services shows as Restart required after upgrading from Ambari-2.4.x to 2.5.0.
[ https://issues.apache.org/jira/browse/AMBARI-20304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Lysnichenko updated AMBARI-20304: Resolution: Fixed Status: Resolved (was: Patch Available) Committed To https://git-wip-us.apache.org/repos/asf/ambari.git b9d199620a..84e767ba00 branch-2.5 -> branch-2.5 41906e593c..801cd6147f trunk -> trunk > Services shows as Restart required after upgrading from Ambari-2.4.x to 2.5.0. > -- > > Key: AMBARI-20304 > URL: https://issues.apache.org/jira/browse/AMBARI-20304 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.5.0 >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20304.patch > > > Properties are added during upgrade to 2.5 > * falcon.atlas.hook > * hive.atlas.hook > * sqoop.atlas.hook > * storm.atlas.hook > * yarn.nodemanager.log.retain-seconds -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20316) Move breadcrumbs to the separated view
[
https://issues.apache.org/jira/browse/AMBARI-20316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897627#comment-15897627
]
Hadoop QA commented on AMBARI-20316:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12856266/AMBARI-20316.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/10892//console
This message is automatically generated.
> Move breadcrumbs to the separated view
> --
>
> Key: AMBARI-20316
> URL: https://issues.apache.org/jira/browse/AMBARI-20316
> Project: Ambari
> Issue Type: Task
> Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 3.0.0
>
> Attachments: AMBARI-20316.patch
>
>
> Breadcrumbs items should be defined in the routes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMBARI-20278) Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not selected" but it is selected
[
https://issues.apache.org/jira/browse/AMBARI-20278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897624#comment-15897624
]
Hadoop QA commented on AMBARI-20278:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12856298/AMBARI-20278_additional_trunk_fix.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The test build failed in ambari-web
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/10891//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/10891//console
This message is automatically generated.
> Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not
> selected" but it is selected
>
>
> Key: AMBARI-20278
> URL: https://issues.apache.org/jira/browse/AMBARI-20278
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-20278_additional_trunk_fix.patch,
> AMBARI-20278.patch, Screen Shot 2017-02-27 at 1.43.56 PM.png
>
>
> See attached.
> Most likely, I didn't select Ambari Infra originally, but then I cancelled
> out of the series of warning popups.
> Then I selected Ambari Infra. The warning does not go away.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMBARI-20278) Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not selected" but it is selected
[ https://issues.apache.org/jira/browse/AMBARI-20278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897582#comment-15897582 ] Aleksandr Kovalenko commented on AMBARI-20278: -- +1 for updated patch > Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not > selected" but it is selected > > > Key: AMBARI-20278 > URL: https://issues.apache.org/jira/browse/AMBARI-20278 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20278_additional_trunk_fix.patch, > AMBARI-20278.patch, Screen Shot 2017-02-27 at 1.43.56 PM.png > > > See attached. > Most likely, I didn't select Ambari Infra originally, but then I cancelled > out of the series of warning popups. > Then I selected Ambari Infra. The warning does not go away. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20309) HBase Master CPU Utilization Alert is in unknown state due to kinit error
[
https://issues.apache.org/jira/browse/AMBARI-20309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-20309:
--
Attachment: AMBARI-20309_trunk_02.patch
AMBARI-20309_branch-2.5_02.patch
> HBase Master CPU Utilization Alert is in unknown state due to kinit error
> -
>
> Key: AMBARI-20309
> URL: https://issues.apache.org/jira/browse/AMBARI-20309
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: alerts, kerberos
> Fix For: 2.5.0
>
> Attachments: AMBARI-20309_branch-2.5_01.patch,
> AMBARI-20309_branch-2.5_02.patch, AMBARI-20309_trunk_01.patch,
> AMBARI-20309_trunk_02.patch
>
>
> HBase Master CPU Utilization Alert is in unknown state due to kinit error:
> {noformat}
> Execution of '/usr/bin/kinit -c
> /var/lib/ambari-agent/tmp/curl_krb_cache/metric_alert_ambari-qa_cc_56787c2122a8214ca9775f3433361f8b
> -kt HTTP/_h...@example.com /etc/security/keytabs/spnego.service.keytab >
> /dev/null' returned 1. kinit: Client not found in Kerberos database while
> getting initial credentials
> {noformat}
> This issue is also seen in /var/log/krb5kdc.log:
> {noformat}
> Mar 03 16:43:06 c6401.ambari.apache.org krb5kdc[4749](info): AS_REQ (4 etypes
> {18 17 16 23}) 192.168.64.101: CLIENT_NOT_FOUND:
> /etc/security/keytabs/spnego.service.key...@example.com for
> krbtgt/example@example.com, Client not found in Kerberos database
> {noformat}
> *Cause*
> It appears that the HBASE alerts.json file
> ({{common-services/HBASE/0.96.0.2.0/alerts.json}}) has swapped values for the
> {{kerberos_keytab}} and {{kerberos_principal}} properties.
> {code}
> {
> "name": "hbase_master_cpu",
> "label": "HBase Master CPU Utilization",
> "description": "This host-level alert is triggered if CPU utilization
> of the HBase Master exceeds certain warning and critical thresholds. It
> checks the HBase Master JMX Servlet for the SystemCPULoad property. The
> threshold values are in percent.",
> "interval": 5,
> "scope": "ANY",
> "enabled": true,
> "source": {
> "type": "METRIC",
> "uri": {
> "http": "{{hbase-site/hbase.master.info.port}}",
> "default_port": 60010,
> "connection_timeout": 5.0,
> "kerberos_keytab":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.principal}}",
> "kerberos_principal":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.keytab}}"
> },
> "reporting": {
> "ok": {
> "text": "{1} CPU, load {0:.1%}"
> },
> "warning": {
> "text": "{1} CPU, load {0:.1%}",
> "value": 200
> },
> "critical": {
> "text": "{1} CPU, load {0:.1%}",
> "value": 250
> },
> "units" : "%",
> "type": "PERCENT"
> },
> "jmx": {
> "property_list": [
> "java.lang:type=OperatingSystem/SystemCpuLoad",
> "java.lang:type=OperatingSystem/AvailableProcessors"
> ],
> "value": "{0} * 100"
> }
> }
> }
> {code}
> Notice:
> {code}
> "kerberos_keytab":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.principal}}",
> "kerberos_principal":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.keytab}}"
> {code}
> *Solution*
> Fix values for the {{kerberos_keytab}} and {{kerberos_principal}} properties
> in {{common-services/HBASE/0.96.0.2.0/alerts.json}}:
> {code}
> "kerberos_principal":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.principal}}",
> "kerberos_keytab":
> "{{hbase-site/hbase.security.authentication.spnego.kerberos.keytab}}"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20278) Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not selected" but it is selected
[ https://issues.apache.org/jira/browse/AMBARI-20278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-20278: - Status: Patch Available (was: Open) > Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not > selected" but it is selected > > > Key: AMBARI-20278 > URL: https://issues.apache.org/jira/browse/AMBARI-20278 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20278_additional_trunk_fix.patch, > AMBARI-20278.patch, Screen Shot 2017-02-27 at 1.43.56 PM.png > > > See attached. > Most likely, I didn't select Ambari Infra originally, but then I cancelled > out of the series of warning popups. > Then I selected Ambari Infra. The warning does not go away. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20278) Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not selected" but it is selected
[ https://issues.apache.org/jira/browse/AMBARI-20278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-20278: - Attachment: (was: AMBARI-20278_additional_trunk_fix.patch) > Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not > selected" but it is selected > > > Key: AMBARI-20278 > URL: https://issues.apache.org/jira/browse/AMBARI-20278 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20278_additional_trunk_fix.patch, > AMBARI-20278.patch, Screen Shot 2017-02-27 at 1.43.56 PM.png > > > See attached. > Most likely, I didn't select Ambari Infra originally, but then I cancelled > out of the series of warning popups. > Then I selected Ambari Infra. The warning does not go away. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20278) Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not selected" but it is selected
[ https://issues.apache.org/jira/browse/AMBARI-20278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-20278: - Attachment: AMBARI-20278_additional_trunk_fix.patch > Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not > selected" but it is selected > > > Key: AMBARI-20278 > URL: https://issues.apache.org/jira/browse/AMBARI-20278 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20278_additional_trunk_fix.patch, > AMBARI-20278.patch, Screen Shot 2017-02-27 at 1.43.56 PM.png > > > See attached. > Most likely, I didn't select Ambari Infra originally, but then I cancelled > out of the series of warning popups. > Then I selected Ambari Infra. The warning does not go away. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20278) Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not selected" but it is selected
[ https://issues.apache.org/jira/browse/AMBARI-20278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-20278: - Status: Open (was: Patch Available) > Install Wizard > Select Services: Ambari warns me that "Ambari Infra is not > selected" but it is selected > > > Key: AMBARI-20278 > URL: https://issues.apache.org/jira/browse/AMBARI-20278 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-20278_additional_trunk_fix.patch, > AMBARI-20278.patch, Screen Shot 2017-02-27 at 1.43.56 PM.png > > > See attached. > Most likely, I didn't select Ambari Infra originally, but then I cancelled > out of the series of warning popups. > Then I selected Ambari Infra. The warning does not go away. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20291) Script-Based Alert Dispatchers support passing more parameters to script
[ https://issues.apache.org/jira/browse/AMBARI-20291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hurley updated AMBARI-20291: - Summary: Script-Based Alert Dispatchers support passing more parameters to script (was: Script-Based Alert Dispathers support passing more parameters to script) > Script-Based Alert Dispatchers support passing more parameters to script > > > Key: AMBARI-20291 > URL: https://issues.apache.org/jira/browse/AMBARI-20291 > Project: Ambari > Issue Type: Improvement >Affects Versions: trunk >Reporter: Yao Lei >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-20291_2.patch > > > Script-Based Alert Dispatcher now pass five parameters to script,including > alert definition name, definition label,service name, alert state, and alert > text. > But if script can receive other two parameters from dispather,it will be > better. > 1.hostname. > Because hostname the alert for is not always included in alert text,although > it may be null like aggregate alerts. > With it we can more quick to find the related host that occured alert. > 2.alert timestamp. > We may need to know the alert occurrence time ( state change time) more > exactly. After the alert happened,it will spend some time to schedule the > script to run. > Without it,we can only regard the script start time as the alert occurrence > time. > We now use this feature to send alert information to mobile phone and suggest > also passing hostname and alert timestamp. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
