[jira] [Created] (AMBARI-21920) next button does not enable if we go back to Assign master page
Deepak Sharma created AMBARI-21920: -- Summary: next button does not enable if we go back to Assign master page Key: AMBARI-21920 URL: https://issues.apache.org/jira/browse/AMBARI-21920 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.5.3 Reporter: Deepak Sharma Scenario: 1) add a new Service 2) assign a master for that service 3) go to next page and till configuration page 4) click on back , to change the master host 5) assign some other master ER: Next button should enable. AR: Next button does not enable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-14163) zookeeper session timeout for hbase should take zookeeper tickTime into account
[ https://issues.apache.org/jira/browse/AMBARI-14163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated AMBARI-14163: Description: With tickTime=2000 in zoo.cfg, I tried to set zookeeper.session.timeout value of 1 min 40 seconds. The change was accepted. However, such timeout is not reachable (it is > 20 times tickTime). Ambari should detect such scenario and warn user. was: With tickTime=2000 in zoo.cfg, I tried to set zookeeper.session.timeout value of 1 min 40 seconds. The change was accepted. However, such timeout is not reachable (it is > 20 times tickTime). Ambari should detect such scenario and warn user. > zookeeper session timeout for hbase should take zookeeper tickTime into > account > --- > > Key: AMBARI-14163 > URL: https://issues.apache.org/jira/browse/AMBARI-14163 > Project: Ambari > Issue Type: Bug >Reporter: Ted Yu > > With tickTime=2000 in zoo.cfg, I tried to set zookeeper.session.timeout value > of 1 min 40 seconds. > The change was accepted. > However, such timeout is not reachable (it is > 20 times tickTime). > Ambari should detect such scenario and warn user. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-17346) Dependent components should be shutdown before stopping hdfs
[ https://issues.apache.org/jira/browse/AMBARI-17346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated AMBARI-17346: Description: Sometimes admin shuts down hdfs first, then hbase. By the time hbase is shutdown, no data can be persisted (including metadata). This results in large number of inconsistencies when hbase cluster is brought back up. Before hdfs is shutdown, the components dependent on hdfs should be shutdown first. was: Sometimes admin shuts down hdfs first, then hbase. By the time hbase is shutdown, no data can be persisted (including metadata). This results in large number of inconsistencies when hbase cluster is brought back up. Before hdfs is shutdown, the components dependent on hdfs should be shutdown first. > Dependent components should be shutdown before stopping hdfs > > > Key: AMBARI-17346 > URL: https://issues.apache.org/jira/browse/AMBARI-17346 > Project: Ambari > Issue Type: Bug >Reporter: Ted Yu > > Sometimes admin shuts down hdfs first, then hbase. > By the time hbase is shutdown, no data can be persisted (including metadata). > This results in large number of inconsistencies when hbase cluster is brought > back up. > Before hdfs is shutdown, the components dependent on hdfs should be shutdown > first. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-21901) Add 0.7.x stack definition for Zeppelin
[ https://issues.apache.org/jira/browse/AMBARI-21901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prabhjyot Singh updated AMBARI-21901: - Attachment: AMBARI-21901_trunk_v2.patch > Add 0.7.x stack definition for Zeppelin > --- > > Key: AMBARI-21901 > URL: https://issues.apache.org/jira/browse/AMBARI-21901 > Project: Ambari > Issue Type: Bug >Reporter: Prabhjyot Singh >Assignee: Prabhjyot Singh > Attachments: AMBARI-21901_trunk_v1.patch, AMBARI-21901_trunk_v2.patch > > > Currently, in Zeppelin, there are two stack definitions 0.6.0.2.5 and > 0.6.0.3.0. The ideas of this Jira are following: > - rename 0.6.0.2.5 to 0.6.0 > - delete redundant 0.6.0.3.0 > - create another defination for 0.7.x as 0.7.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-21912) Make Ambari changes for external-conf
[ https://issues.apache.org/jira/browse/AMBARI-21912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prabhjyot Singh updated AMBARI-21912: - Attachment: AMBARI-21912_trunk_v1.patch > Make Ambari changes for external-conf > - > > Key: AMBARI-21912 > URL: https://issues.apache.org/jira/browse/AMBARI-21912 > Project: Ambari > Issue Type: Bug >Reporter: Prabhjyot Singh >Assignee: Prabhjyot Singh > Attachments: AMBARI-21912_trunk_v1.patch > > > When the user upgrades from HDP-2.5.x to HDP-2.6.x, they have to do these > manual steps listed here > https://community.hortonworks.com/articles/115251/running-jdbc-intepreter-with-phoenix-causes-broken.html, > to make JDBC(phoenix) works. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-21912) Make Ambari changes for external-conf
[ https://issues.apache.org/jira/browse/AMBARI-21912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prabhjyot Singh updated AMBARI-21912: - Status: Patch Available (was: Open) > Make Ambari changes for external-conf > - > > Key: AMBARI-21912 > URL: https://issues.apache.org/jira/browse/AMBARI-21912 > Project: Ambari > Issue Type: Bug >Reporter: Prabhjyot Singh >Assignee: Prabhjyot Singh > > When the user upgrades from HDP-2.5.x to HDP-2.6.x, they have to do these > manual steps listed here > https://community.hortonworks.com/articles/115251/running-jdbc-intepreter-with-phoenix-causes-broken.html, > to make JDBC(phoenix) works. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (AMBARI-21919) Kerberos identity references should use the "reference" attribute
Robert Levas created AMBARI-21919:
-
Summary: Kerberos identity references should use the "reference"
attribute
Key: AMBARI-21919
URL: https://issues.apache.org/jira/browse/AMBARI-21919
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Robert Levas
Assignee: Robert Levas
Fix For: 2.6.0
Kerberos identity references should use the "reference" attribute rather than
rely on the "name" attribute to indicate the identity descriptor references
some other identity descriptor.
Either method should work on the backend, however the UI appears to not fully
handle the "named" reference properly.
The solution is to change
{code}
{
"name": "/HDFS/NAMENODE/namenode_nn",
"principal": {
"configuration":
"ranger-hdfs-audit/xasecure.audit.jaas.Client.option.principal"
},
"keytab": {
"configuration":
"ranger-hdfs-audit/xasecure.audit.jaas.Client.option.keyTab"
}
}
{code}
by changing the "name" attribute to "reference" and adding a new "name"
reference with a unique name relative to the scope of the identity descriptor.
For example:
{code}
{
"name":"ranger_hdfs_audit"
"reference": "/HDFS/NAMENODE/namenode_nn",
"principal": {
"configuration":
"ranger-hdfs-audit/xasecure.audit.jaas.Client.option.principal"
},
"keytab": {
"configuration":
"ranger-hdfs-audit/xasecure.audit.jaas.Client.option.keyTab"
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
