[jira] [Updated] (AMBARI-14444) Inconsistent graph refresh behavior when time scale is changed in host metrics

[Mark Petronic (JIRA)]

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

Mark Petronic updated AMBARI-1:
---
Attachment: screenshot-1.png

> Inconsistent graph refresh behavior when time scale is changed in host metrics
> --
>
> Key: AMBARI-1
> URL: https://issues.apache.org/jira/browse/AMBARI-1
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 0.1.0
> Environment: Chromium Version 47.0.2526.106 (64-bit) on Arch Linux
>Reporter: Mark Petronic
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> 1. Go host metrics and click on any host
> 2. Click on the Load graph to expand to its own window
> 3. Click on the left time scale expand arrow to expand to "Last 12 hours". 
> You will observe the graph repaints to reflect 12 hours of data
> 4. Wait about 15 seconds
> 5. The graph will refresh back to the data for "Last 1 hour" yet the title on 
> the page still shows "Last 12 hours"
> If you try this on the graphs on the main Dashboard, they appear to work as 
> expected. Whatever scale you select is persistently displayed. It sticks with 
> that time scale until you change it manually and there is no weird refresh 
> regression back to "Last 1 hour" scale. Also, why doesn't the host metric 
> graphs group have a time range pick list for the whole group like you see, 
> for example, on the HDFS metrics group?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14444) Inconsistent graph refresh behavior when time scale is changed in host metrics

[Mark Petronic (JIRA)]

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

Mark Petronic updated AMBARI-1:
---
Attachment: screenshot-1.png

> Inconsistent graph refresh behavior when time scale is changed in host metrics
> --
>
> Key: AMBARI-1
> URL: https://issues.apache.org/jira/browse/AMBARI-1
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 0.1.0
> Environment: Chromium Version 47.0.2526.106 (64-bit) on Arch Linux
>Reporter: Mark Petronic
>Priority: Minor
>
> 1. Go host metrics and click on any host
> 2. Click on the Load graph to expand to its own window
> 3. Click on the left time scale expand arrow to expand to "Last 12 hours". 
> You will observe the graph repaints to reflect 12 hours of data
> 4. Wait about 15 seconds
> 5. The graph will refresh back to the data for "Last 1 hour" yet the title on 
> the page still shows "Last 12 hours"
> If you try this on the graphs on the main Dashboard, they appear to work as 
> expected. Whatever scale you select is persistently displayed. It sticks with 
> that time scale until you change it manually and there is no weird refresh 
> regression back to "Last 1 hour" scale. Also, why doesn't the host metric 
> graphs group have a time range pick list for the whole group like you see, 
> for example, on the HDFS metrics group?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14444) Inconsistent graph refresh behavior when time scale is changed in host metrics

[Mark Petronic (JIRA)]

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

Mark Petronic updated AMBARI-1:
---
Attachment: (was: screenshot-1.png)

> Inconsistent graph refresh behavior when time scale is changed in host metrics
> --
>
> Key: AMBARI-1
> URL: https://issues.apache.org/jira/browse/AMBARI-1
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 0.1.0
> Environment: Chromium Version 47.0.2526.106 (64-bit) on Arch Linux
>Reporter: Mark Petronic
>Priority: Minor
>
> 1. Go host metrics and click on any host
> 2. Click on the Load graph to expand to its own window
> 3. Click on the left time scale expand arrow to expand to "Last 12 hours". 
> You will observe the graph repaints to reflect 12 hours of data
> 4. Wait about 15 seconds
> 5. The graph will refresh back to the data for "Last 1 hour" yet the title on 
> the page still shows "Last 12 hours"
> If you try this on the graphs on the main Dashboard, they appear to work as 
> expected. Whatever scale you select is persistently displayed. It sticks with 
> that time scale until you change it manually and there is no weird refresh 
> regression back to "Last 1 hour" scale. Also, why doesn't the host metric 
> graphs group have a time range pick list for the whole group like you see, 
> for example, on the HDFS metrics group?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14444) Inconsistent graph refresh behavior when time scale is changed in host metrics

[Mark Petronic (JIRA)]

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

Mark Petronic updated AMBARI-1:
---
Description: 
1. Go host metrics and click on any host
2. Click on the Load graph to expand to its own window
3. Click on the left time scale expand arrow to expand to "Last 12 hours". You 
will observe the graph repaints to reflect 12 hours of data
4. Wait about 15 seconds
5. The graph will refresh back to the data for "Last 1 hour" yet the title on 
the page still shows "Last 12 hours"

If you try this on the graphs on the main Dashboard, they appear to work as 
expected. Whatever scale you select is persistently displayed. It sticks with 
that time scale until you change it manually and there is no weird refresh 
regression back to "Last 1 hour" scale. Also, why doesn't the host metric 
graphs group have a time range pick list for the whole group like you see, for 
example, on the HDFS metrics group?

  was:
1. Go host metrics and click on any host
2. Click on the Load graph to expand to its own window
3. Click on the left time scale expand arrow to expand to "Last 12 hours". You 
will observe the graph repaints to reflect 12 hours of data
4. Wait about 15 seconds
5. The graph will refresh back to the data for "Last 1 hour" yet the title on 
the page still shows "Last 12 hours"

If you try this on the graphs on the main Dashboard, they appear to work as 
expected. Whatever scale you go is persistently displayed. It sticks with that 
time scale until you change it manually and there is no weird refresh 
regression back to "Last 1 hour" scale. Also, why doesn't the host metric 
graphs group have a time range pick list for the whole group like you see, for 
example, on the HDFS metrics group?


> Inconsistent graph refresh behavior when time scale is changed in host metrics
> --
>
> Key: AMBARI-1
> URL: https://issues.apache.org/jira/browse/AMBARI-1
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 0.1.0
> Environment: Chromium Version 47.0.2526.106 (64-bit) on Arch Linux
>Reporter: Mark Petronic
>Priority: Minor
>
> 1. Go host metrics and click on any host
> 2. Click on the Load graph to expand to its own window
> 3. Click on the left time scale expand arrow to expand to "Last 12 hours". 
> You will observe the graph repaints to reflect 12 hours of data
> 4. Wait about 15 seconds
> 5. The graph will refresh back to the data for "Last 1 hour" yet the title on 
> the page still shows "Last 12 hours"
> If you try this on the graphs on the main Dashboard, they appear to work as 
> expected. Whatever scale you select is persistently displayed. It sticks with 
> that time scale until you change it manually and there is no weird refresh 
> regression back to "Last 1 hour" scale. Also, why doesn't the host metric 
> graphs group have a time range pick list for the whole group like you see, 
> for example, on the HDFS metrics group?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMBARI-14444) Inconsistent graph refresh behavior when time scale is changed in host metrics

[Mark Petronic (JIRA)]

Mark Petronic created AMBARI-1:
--

 Summary: Inconsistent graph refresh behavior when time scale is 
changed in host metrics
 Key: AMBARI-1
 URL: https://issues.apache.org/jira/browse/AMBARI-1
 Project: Ambari
  Issue Type: Bug
  Components: ambari-metrics
Affects Versions: 0.1.0
 Environment: Chromium Version 47.0.2526.106 (64-bit) on Arch Linux
Reporter: Mark Petronic
Priority: Minor


1. Go host metrics and click on any host
2. Click on the Load graph to expand to its own window
3. Click on the left time scale expand arrow to expand to "Last 12 hours". You 
will observe the graph repaints to reflect 12 hours of data
4. Wait about 15 seconds
5. The graph will refresh back to the data for "Last 1 hour" yet the title on 
the page still shows "Last 12 hours"

If you try this on the graphs on the main Dashboard, they appear to work as 
expected. Whatever scale you go is persistently displayed. It sticks with that 
time scale until you change it manually and there is no weird refresh 
regression back to "Last 1 hour" scale. Also, why doesn't the host metric 
graphs group have a time range pick list for the whole group like you see, for 
example, on the HDFS metrics group?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14442) Typo in error message displayed when connection fails in Hive view

[Sangeeta Ravindran (JIRA)]

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

Sangeeta Ravindran updated AMBARI-14442:

Attachment: AMBARI-14442.patch

> Typo in error message displayed when connection fails in Hive view
> --
>
> Key: AMBARI-14442
> URL: https://issues.apache.org/jira/browse/AMBARI-14442
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.1.0
>Reporter: Sangeeta Ravindran
>Assignee: Sangeeta Ravindran
>Priority: Trivial
> Attachments: AMBARI-14442.patch, hiveconnectionerrortypo.png
>
>
> There is a typo in the exception message when connection to Hive server fails 
> in Hive view.
> H020 Could not establish connecton to



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14442) Typo in error message displayed when connection fails in Hive view

[Sangeeta Ravindran (JIRA)]

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

Sangeeta Ravindran updated AMBARI-14442:

Attachment: (was: AMBARI-14442)

> Typo in error message displayed when connection fails in Hive view
> --
>
> Key: AMBARI-14442
> URL: https://issues.apache.org/jira/browse/AMBARI-14442
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.1.0
>Reporter: Sangeeta Ravindran
>Assignee: Sangeeta Ravindran
>Priority: Trivial
> Attachments: hiveconnectionerrortypo.png
>
>
> There is a typo in the exception message when connection to Hive server fails 
> in Hive view.
> H020 Could not establish connecton to



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14442) Typo in error message displayed when connection fails in Hive view

[Sangeeta Ravindran (JIRA)]

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

Sangeeta Ravindran updated AMBARI-14442:

Attachment: AMBARI-14442

> Typo in error message displayed when connection fails in Hive view
> --
>
> Key: AMBARI-14442
> URL: https://issues.apache.org/jira/browse/AMBARI-14442
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.1.0
>Reporter: Sangeeta Ravindran
>Assignee: Sangeeta Ravindran
>Priority: Trivial
> Attachments: hiveconnectionerrortypo.png
>
>
> There is a typo in the exception message when connection to Hive server fails 
> in Hive view.
> H020 Could not establish connecton to



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14443) In the Move Master Wizard, manual commands text scroll outside the frame when the message is long

[Sangeeta Ravindran (JIRA)]

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

Sangeeta Ravindran updated AMBARI-14443:

Attachment: MoveService_NN.jpg

> In the Move Master Wizard, manual commands text scroll outside the frame when 
> the message is long
> -
>
> Key: AMBARI-14443
> URL: https://issues.apache.org/jira/browse/AMBARI-14443
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.0
>Reporter: Sangeeta Ravindran
>Assignee: Sangeeta Ravindran
>Priority: Minor
> Attachments: MoveService_NN.jpg
>
>
> During the process of moving the NameNode to another host, when the manual 
> commands are displayed, the text scrolls out of the frame when the message is 
> long.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMBARI-14443) In the Move Master Wizard, manual commands text scroll outside the frame when the message is long

[Sangeeta Ravindran (JIRA)]

Sangeeta Ravindran created AMBARI-14443:
---

 Summary: In the Move Master Wizard, manual commands text scroll 
outside the frame when the message is long
 Key: AMBARI-14443
 URL: https://issues.apache.org/jira/browse/AMBARI-14443
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.1.0
Reporter: Sangeeta Ravindran
Assignee: Sangeeta Ravindran
Priority: Minor


During the process of moving the NameNode to another host, when the manual 
commands are displayed, the text scrolls out of the frame when the message is 
long.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14442) Typo in error message displayed when connection fails in Hive view

[Sangeeta Ravindran (JIRA)]

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

Sangeeta Ravindran updated AMBARI-14442:

Attachment: hiveconnectionerrortypo.png

> Typo in error message displayed when connection fails in Hive view
> --
>
> Key: AMBARI-14442
> URL: https://issues.apache.org/jira/browse/AMBARI-14442
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.1.0
>Reporter: Sangeeta Ravindran
>Assignee: Sangeeta Ravindran
>Priority: Trivial
> Attachments: hiveconnectionerrortypo.png
>
>
> There is a typo in the exception message when connection to Hive server fails 
> in Hive view.
> H020 Could not establish connecton to



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMBARI-14442) Typo in error message displayed when connection fails in Hive view

[Sangeeta Ravindran (JIRA)]

Sangeeta Ravindran created AMBARI-14442:
---

 Summary: Typo in error message displayed when connection fails in 
Hive view
 Key: AMBARI-14442
 URL: https://issues.apache.org/jira/browse/AMBARI-14442
 Project: Ambari
  Issue Type: Bug
  Components: ambari-views
Affects Versions: 2.1.0
Reporter: Sangeeta Ravindran
Assignee: Sangeeta Ravindran
Priority: Trivial


There is a typo in the exception message when connection to Hive server fails 
in Hive view.

H020 Could not establish connecton to



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14426) If repos for the current os are not defined install_packages doesn't show error

[Hudson (JIRA)]

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

Hudson commented on AMBARI-14426:
-

ABORTED: Integrated in Ambari-trunk-Commit #4069 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4069/])
AMBARI-14426. If repos for the current os are not defined (xiwang: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=fd6e9cc00ea511c3433c847654d994dd605c6368])
* ambari-web/app/controllers/main/admin/stack_and_upgrade_controller.js
* ambari-web/app/messages.js


> If repos for the current os are not defined install_packages doesn't show 
> error
> ---
>
> Key: AMBARI-14426
> URL: https://issues.apache.org/jira/browse/AMBARI-14426
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Xi Wang
>Assignee: Xi Wang
> Fix For: 2.4.0
>
> Attachments: AMBARI-14426.patch, AMBARI-14426.patch
>
>
> 1. After cluster deployment in 'Versions' tab, On os X define new repo 
> version, but set the repos only for os Y.
> 2. Click install_packages. It gives 500 error from server with reasonable 
> error, however UI doesn't show anything to user, which is pretty confusing.
> {noformat}
> {
>   "status" : 500,
>   "message" : "Repositories for os type ubuntu12 are not defined. Repo 
> version=2.3.5.0, stackId=HDP-2.3"
> }
> {noformat}
> We could show a general error message for all the errors on this stage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14429) Ambari Web Unit Test failures on trunk (test/models/configs/service_config_version_test App.ServiceConfigVersion #createdDate)

[Hudson (JIRA)]

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

Hudson commented on AMBARI-14429:
-

ABORTED: Integrated in Ambari-trunk-Commit #4069 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4069/])
AMBARI-14429. Ambari Web Unit Test failures on trunk (rzang) (rzang: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=32e86548cb69b244f11ba08e927cdda2f96f9331])
* ambari-web/test/models/configs/service_config_version_test.js


> Ambari Web Unit Test failures on trunk 
> (test/models/configs/service_config_version_test App.ServiceConfigVersion 
> #createdDate)
> --
>
> Key: AMBARI-14429
> URL: https://issues.apache.org/jira/browse/AMBARI-14429
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Richard Zang
>Assignee: Richard Zang
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-14429.patch
>
>
> [0m  1) Ambari Web Unit tests test/models/configs/service_config_version_test 
> App.ServiceConfigVersion #createdDate should return created date:
>   
>   [41mactual[0m [42mexpected[0m
>   
>   "Wed, Dec 16, 2015 [42m14[0m[41m12[0m:06"
>   [0m[90m
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/chai/chai.js:925
>   at assertEqual 
> (file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/chai/chai.js:1402)
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/chai/chai.js:3638
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/public/test/javascripts/test.js:52112
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:4039
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:4404
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:4463
>   at next 
> (file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:4330)
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:4339
>   at next 
> (file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:4287)
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:4307
>   at timeslice 
> (file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:5279)
> [0m
> npm ERR! Test failed.  See above for more details.
> npm ERR! not ok code 0
> [INFO]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14436) Spark ThriftServer Does Not Upgrade

[Hudson (JIRA)]

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

Hudson commented on AMBARI-14436:
-

ABORTED: Integrated in Ambari-trunk-Commit #4069 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4069/])
AMBARI-14436 - Spark ThriftServer Does Not Upgrade (jonathanhurley) (jhurley: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=3b693eab67e5f37229cc0070fa52d68f730c7c3e])
* ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml


> Spark ThriftServer Does Not Upgrade
> ---
>
> Key: AMBARI-14436
> URL: https://issues.apache.org/jira/browse/AMBARI-14436
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-14436.patch
>
>
> The blueprint is deploying SPARK_THRIFTSERVER
> {code}
> {
> "name": "SPARK_THRIFTSERVER"
> },
> {code}
> The failure is due to:
> {code}
> The following components were found to have version mismatches.  Finalize 
> will not complete successfully:
> os-s11-3-dzcnju-ambari-eu-1-2.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-4.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-5.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> {code}
> This is because the STS is not part of any upgrade packs. Since it first 
> appeared in HDP 2.3.2, the 2 upgrade packs for HDP 2.3 -> 2.3+ should be 
> updated to include STS.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14434) Passwords for headless principals with cached keytab files are changed unnecessarily

[Hudson (JIRA)]

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

Hudson commented on AMBARI-14434:
-

ABORTED: Integrated in Ambari-trunk-Commit #4069 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4069/])
AMBARI-14434. Passwords for headless principals with cached keytab files 
(rlevas: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=f0b029e57daf5e3ec01b8dbc53ea41886ebe5e55])
* 
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/CreatePrincipalsServerAction.java


> Passwords for headless principals with cached keytab files are changed 
> unnecessarily
> 
>
> Key: AMBARI-14434
> URL: https://issues.apache.org/jira/browse/AMBARI-14434
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 2.4.0, 2.2.1
>
> Attachments: AMBARI-14434_branch-2.2.1-pre_01.patch, 
> AMBARI-14434_trunk_01.patch
>
>
> Passwords for headless principals with cached keytab files are changed 
> unnecessarily.
> Solution check for the existence of a cached keytab file for headless 
> principals before updating their passwords.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14437) Unable To Restart HCat Client When Not Colocated With WebHCat Server

[Hudson (JIRA)]

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

Hudson commented on AMBARI-14437:
-

ABORTED: Integrated in Ambari-trunk-Commit #4069 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4069/])
AMBARI-14437 - Unable To Restart HCat Client When Not Colocated With (jhurley: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=b61f6eafab1e2eb6ef7ae8dacce87baa742933eb])
* 
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hcat_client.py
* ambari-server/src/test/python/stacks/2.0.6/HIVE/test_hcat_client.py


> Unable To Restart HCat Client When Not Colocated With WebHCat Server
> 
>
> Key: AMBARI-14437
> URL: https://issues.apache.org/jira/browse/AMBARI-14437
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.2.1
>
> Attachments: AMBARI-14437.patch
>
>
> Errors are encountered while restart Hive HCat client when it is not located 
> on a host which also has WebHCat daemon.
> {code:title=This is good - the pointers have moved for 2.3.4}
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp/2.3.4.0-3485/hive-hcatalog/etc
> total 4
> lrwxrwxrwx 1 root root   33 Dec 18 14:45 hcatalog -> 
> /etc/hive-hcatalog/2.3.4.0-3485/0
> drwxr-xr-x 2 root root 4096 Dec 18 14:45 init.d
> lrwxrwxrwx 1 root root   32 Dec 18 14:45 webhcat -> 
> /etc/hive-webhcat/2.3.4.0-3485/0
> {code}
> {code:title=This is bad - current for hcatalog is still 2.3.2, which has the 
> symlink issue}
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp/current | grep hive
> lrwxrwxrwx 1 root root 26 Dec 18 15:50 hive-client -> 
> /usr/hdp/2.3.4.0-3485/hive
> lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-metastore -> 
> /usr/hdp/2.3.2.0-2826/hive
> lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-server2 -> 
> /usr/hdp/2.3.2.0-2826/hive
> lrwxrwxrwx 1 root root 35 Dec 18 12:59 hive-webhcat -> 
> /usr/hdp/2.3.2.0-2826/hive-hcatalog
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp2.3.2.0-2826/hive-hcatalog/etc
> lrwxrwxrwx 1 root root 23 Dec 18 20:35 hcatalog -> /etc/hive-hcatalog/conf
> lrwxrwxrwx 1 root root 22 Dec 18 20:35 webhcat -> /etc/hive-webhcat/conf
> {code}
> The problem is that {{hcat_client.py}} must write out configs to 
> {{/usr/hdp/current/hive-webhcat/etc/hcatalog}} but {{hcat_client.py}} doesn't 
> {{hdp-select}} anything.
> So that the "current" pointers are never changed. {{hcat_client.py}} should 
> probably {{hdp-select hive-webhcat}} since there is no {{hcat-client}} in 
> {{hdp-select}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 41577: AMBARI-11670: Width of services menu container is fixed and causes part of longer service names to be rendered outside the frame

[Keta Patel]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41577/
---

Review request for Ambari and Alexandr Antonenko.


Bugs: AMBARI-11670
https://issues.apache.org/jira/browse/AMBARI-11670


Repository: ambari


Description
---

If a service has a really long name (19 characters or more), part of the 
service name is rendered outside the frame. Any action icons for e.g. refresh 
also appear outside the frame.

The frame width should change dynamically to accommodate a longer service name 
or the service name should wrap to the next line.


Diffs
-

  ambari-web/app/assets/test/tests.js d13767f 
  ambari-web/app/templates/main/service/menu_item.hbs 8842858 
  ambari-web/app/views/main/service/menu.js e70dea2 
  ambari-web/test/views/main/service/menu_test.js PRE-CREATION 

Diff: https://reviews.apache.org/r/41577/diff/


Testing
---

The cause of the long service name rendering outside the frame of the 
menu-container was because the CSS style for the service names didn't allow 
word wrapping. While working on this issue, we also realized that the refresh 
icon could be overlapped by the alert box when either the service name was long 
or the alert count was big. 
We fixed these issues by surrounding a  block around the health icon, 
service name, refresh icon and alert box. The width of all these 4 components 
are fixed to a suitable amount so that all the 4 components now appear 
consistently in their respective positions. 
To allow for long service names, its CSS style is updated to allow for 
word-wrapping on white space. For the case of long words in the service name 
that can't fit in one line in its  block, we have added the CSS style to 
allow for word-breaks also.
In the case of alert box, the width of its  block allows alert counts 
having a maximum of 2 digits to fit properly. An alert count of greater than 99 
can overlap the refresh icon. So to avoid this overlap, we display the alert 
count as "99+" for alert counts greater than 99. The exact value of the alert 
count can be seen in the Summary page of the Service. We came up with this fix 
considering that the average case of alert counts usually involves 2 digits or 
less. Any count greater than that is not very likely to occur and even if for 
some reason there are a lot of alerts, then showing the exact count in the 
fixed width menu container comes only secondary to showing that the Service has 
alerts.


To implement the logic of showing "99+" in the alert box, we added a new 
function "isAlertsCountBig" in the ambari-web/app/views/main/service/menu.js. 
This function returns "true" when the "alertsCount" is greater than 99, 
otherwise returns "false".

Test cases:
1. when "alertsCount"=0 (no alerts), "isAlertsCountBig" should return "false"
2. when "alertsCount"=5 (average case), "isAlertsCountBig" should return "false"
3. when "alertsCount"=200 (big alert count), "isAlertsCountBig" should return 
"true"
4. when "alertsCount"=99 (corner case of the condition), "isAlertsCountBig" 
should return "false"


Ambari-web tests for the original trunk (without patch):

  11734 tests complete (14 seconds)
  137 tests pending

Ambari-web tests for the original trunk (after applying patch with 4 new tests):

  11738 tests complete (14 seconds)
  137 tests pending


Thanks,

Keta Patel

[jira] [Updated] (AMBARI-14435) Parameterize distro-specific stack information for ZOOKEEPER

[Juanjo Marron (JIRA)]

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

Juanjo Marron updated AMBARI-14435:
---
Attachment: AMBARI-14435.patch

Zookeeper has been parameterized according to the prototype:
/usr/hdp paths, specific stack versions, hdp variables 
(hdp_root,hdp_stack_version ), version-based conditions, HDP references in 
get_stack_component method...

The patch has been built against AMBARI-13364 branch.

Tested ZK fresh installation successfully

> Parameterize distro-specific stack information for ZOOKEEPER
> 
>
> Key: AMBARI-14435
> URL: https://issues.apache.org/jira/browse/AMBARI-14435
> Project: Ambari
>  Issue Type: Technical task
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.2.1
>Reporter: Juanjo Marron
>Assignee: Juanjo Marron
> Fix For: 2.4.0
>
> Attachments: AMBARI-14435.patch
>
>
> Apply the prototype detailed on AMBARI-13364 to ZOOKEEPER service.
> Tokens such as: current version, upgrade version, stack name, install 
> path..., will be parameterized and distro-agnostic at service definition 
> level.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-13364) Parameterize stack information used by common services

[Juanjo Marron (JIRA)]

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

Juanjo Marron commented on AMBARI-13364:


Creating subtasks to do one service at a time with no impact to other services.
Tokens such as: stack version, current version, upgrade version, stack name, 
stack directory, variables names... will be parameterized and distro-agnostic 
at service definition level.
  
Renaming  generic functions or script names such as: format_hdp_stack_version, 
is_hdp_stack_greater_or_equal and hdp_select  would affect to all the services 
in common-services, so they will be renamed at the end once all services are 
paremeterized.
  

>  Parameterize stack information used by common services
> ---
>
> Key: AMBARI-13364
> URL: https://issues.apache.org/jira/browse/AMBARI-13364
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-server
>Reporter: Tuong Truong
>Assignee: Juanjo Marron
> Attachments: AMBARI-13364 Parameterize stack information used by 
> common services.pdf, AMBARI-13364.patch
>
>
> This feature will add a basic framework to remove hardcoded stack information 
> out of the common services and use parameter to get access to stack 
> information.  Currently, the common services hardcoded much information 
> specific to Hortonworks' HDP stack including name (HDP), specific versions 
> (2.0, 2.1, 2.2), and install location.   This feature will propose a way of 
> configuration these information and parameterize them into the services for 
> reference as require. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14352) EU/RU: add error handler for 'Pause upgrade'

[Richard Zang (JIRA)]

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

Richard Zang commented on AMBARI-14352:
---

+1 for patch.

> EU/RU: add error handler for 'Pause upgrade'
> 
>
> Key: AMBARI-14352
> URL: https://issues.apache.org/jira/browse/AMBARI-14352
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.2.1
>
> Attachments: AMBARI-14352.patch, AMBARI-14352.patch
>
>
> STR
> # deploy cluster
> # start RU
> # try to pause upgrade one manual step
> Result: upgrade not paused, service actions not available
> As not able to reproduce this issue, just add an error handler for this case, 
> so that if "Pause Upgrade" failed, an alert popup will show the error message.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14352) EU/RU: add error handler for 'Pause upgrade'

[Xi Wang (JIRA)]

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

Xi Wang updated AMBARI-14352:
-
Fix Version/s: (was: 2.4.0)
   2.2.1

> EU/RU: add error handler for 'Pause upgrade'
> 
>
> Key: AMBARI-14352
> URL: https://issues.apache.org/jira/browse/AMBARI-14352
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.2.1
>
> Attachments: AMBARI-14352.patch, AMBARI-14352.patch
>
>
> STR
> # deploy cluster
> # start RU
> # try to pause upgrade one manual step
> Result: upgrade not paused, service actions not available
> As not able to reproduce this issue, just add an error handler for this case, 
> so that if "Pause Upgrade" failed, an alert popup will show the error message.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14435) Parameterize distro-specific stack information for ZOOKEEPER

[Juanjo Marron (JIRA)]

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

Juanjo Marron updated AMBARI-14435:
---
Description: 
Apply the prototype detailed on AMBARI-13364 to ZOOKEEPER service.

Tokens such as: current version, upgrade version, stack name, install path..., 
will be parameterized and distro-agnostic at service definition level.




  was:
Apply the prototype detailed on AMBARI-13364 to ZOOKEEPER service.

Tokens such as: current version, upgrade version, stack name, install path, 
..., will be parameterized and distro-agnostic at service definition level



> Parameterize distro-specific stack information for ZOOKEEPER
> 
>
> Key: AMBARI-14435
> URL: https://issues.apache.org/jira/browse/AMBARI-14435
> Project: Ambari
>  Issue Type: Technical task
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.2.1
>Reporter: Juanjo Marron
>Assignee: Juanjo Marron
> Fix For: 2.4.0
>
>
> Apply the prototype detailed on AMBARI-13364 to ZOOKEEPER service.
> Tokens such as: current version, upgrade version, stack name, install 
> path..., will be parameterized and distro-agnostic at service definition 
> level.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14352) EU/RU: add error handler for 'Pause upgrade'

[Xi Wang (JIRA)]

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

Xi Wang updated AMBARI-14352:
-
Attachment: AMBARI-14352.patch

> EU/RU: add error handler for 'Pause upgrade'
> 
>
> Key: AMBARI-14352
> URL: https://issues.apache.org/jira/browse/AMBARI-14352
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-14352.patch, AMBARI-14352.patch
>
>
> STR
> # deploy cluster
> # start RU
> # try to pause upgrade one manual step
> Result: upgrade not paused, service actions not available
> As not able to reproduce this issue, just add an error handler for this case, 
> so that if "Pause Upgrade" failed, an alert popup will show the error message.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14437) Unable To Restart HCat Client When Not Colocated With WebHCat Server

[Hudson (JIRA)]

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

Hudson commented on AMBARI-14437:
-

FAILURE: Integrated in Ambari-branch-2.2 #86 (See 
[https://builds.apache.org/job/Ambari-branch-2.2/86/])
AMBARI-14437 - Unable To Restart HCat Client When Not Colocated With (jhurley: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=1c88d47c0fb7cdba2d5626f7714dca467355d9ed])
* ambari-server/src/test/python/stacks/2.0.6/HIVE/test_hcat_client.py
* 
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hcat_client.py


> Unable To Restart HCat Client When Not Colocated With WebHCat Server
> 
>
> Key: AMBARI-14437
> URL: https://issues.apache.org/jira/browse/AMBARI-14437
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.2.1
>
> Attachments: AMBARI-14437.patch
>
>
> Errors are encountered while restart Hive HCat client when it is not located 
> on a host which also has WebHCat daemon.
> {code:title=This is good - the pointers have moved for 2.3.4}
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp/2.3.4.0-3485/hive-hcatalog/etc
> total 4
> lrwxrwxrwx 1 root root   33 Dec 18 14:45 hcatalog -> 
> /etc/hive-hcatalog/2.3.4.0-3485/0
> drwxr-xr-x 2 root root 4096 Dec 18 14:45 init.d
> lrwxrwxrwx 1 root root   32 Dec 18 14:45 webhcat -> 
> /etc/hive-webhcat/2.3.4.0-3485/0
> {code}
> {code:title=This is bad - current for hcatalog is still 2.3.2, which has the 
> symlink issue}
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp/current | grep hive
> lrwxrwxrwx 1 root root 26 Dec 18 15:50 hive-client -> 
> /usr/hdp/2.3.4.0-3485/hive
> lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-metastore -> 
> /usr/hdp/2.3.2.0-2826/hive
> lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-server2 -> 
> /usr/hdp/2.3.2.0-2826/hive
> lrwxrwxrwx 1 root root 35 Dec 18 12:59 hive-webhcat -> 
> /usr/hdp/2.3.2.0-2826/hive-hcatalog
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp2.3.2.0-2826/hive-hcatalog/etc
> lrwxrwxrwx 1 root root 23 Dec 18 20:35 hcatalog -> /etc/hive-hcatalog/conf
> lrwxrwxrwx 1 root root 22 Dec 18 20:35 webhcat -> /etc/hive-webhcat/conf
> {code}
> The problem is that {{hcat_client.py}} must write out configs to 
> {{/usr/hdp/current/hive-webhcat/etc/hcatalog}} but {{hcat_client.py}} doesn't 
> {{hdp-select}} anything.
> So that the "current" pointers are never changed. {{hcat_client.py}} should 
> probably {{hdp-select hive-webhcat}} since there is no {{hcat-client}} in 
> {{hdp-select}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (AMBARI-14441) EU/RU: add error handler for 'Pause upgrade'

[Xi Wang (JIRA)]

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

Xi Wang resolved AMBARI-14441.
--
Resolution: Duplicate

> EU/RU: add error handler for 'Pause upgrade'
> 
>
> Key: AMBARI-14441
> URL: https://issues.apache.org/jira/browse/AMBARI-14441
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.2.1
>
>
> STR
> # deploy cluster
> # start RU
> # try to pause upgrade one manual step
> Result: upgrade not paused, service actions not available
> As not able to reproduce this issue, just add an error handler for this case, 
> so that if "Pause Upgrade" failed, an alert popup will show the error message.
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14352) Should show error message when "Pause Upgrade" failed

[Xi Wang (JIRA)]

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

Xi Wang commented on AMBARI-14352:
--

As not able to reproduce this issue, just add an error handler for this case, 
so that if "Pause Upgrade" failed, an alert popup will show the error message.

> Should show error message when "Pause Upgrade" failed
> -
>
> Key: AMBARI-14352
> URL: https://issues.apache.org/jira/browse/AMBARI-14352
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-14352.patch
>
>
> STR
> # deploy cluster
> # start RU
> # try to pause upgrade one manual step
> Result: upgrade not paused, service actions not available



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14352) EU/RU: add error handler for 'Pause upgrade'

[Xi Wang (JIRA)]

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

Xi Wang updated AMBARI-14352:
-
Summary: EU/RU: add error handler for 'Pause upgrade'  (was: Should show 
error message when "Pause Upgrade" failed)

> EU/RU: add error handler for 'Pause upgrade'
> 
>
> Key: AMBARI-14352
> URL: https://issues.apache.org/jira/browse/AMBARI-14352
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-14352.patch
>
>
> STR
> # deploy cluster
> # start RU
> # try to pause upgrade one manual step
> Result: upgrade not paused, service actions not available
> As not able to reproduce this issue, just add an error handler for this case, 
> so that if "Pause Upgrade" failed, an alert popup will show the error message.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14352) Should show error message when "Pause Upgrade" failed

[Xi Wang (JIRA)]

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

Xi Wang updated AMBARI-14352:
-
Description: 
STR
# deploy cluster
# start RU
# try to pause upgrade one manual step
Result: upgrade not paused, service actions not available

As not able to reproduce this issue, just add an error handler for this case, 
so that if "Pause Upgrade" failed, an alert popup will show the error message.



  was:
STR
# deploy cluster
# start RU
# try to pause upgrade one manual step
Result: upgrade not paused, service actions not available




> Should show error message when "Pause Upgrade" failed
> -
>
> Key: AMBARI-14352
> URL: https://issues.apache.org/jira/browse/AMBARI-14352
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-14352.patch
>
>
> STR
> # deploy cluster
> # start RU
> # try to pause upgrade one manual step
> Result: upgrade not paused, service actions not available
> As not able to reproduce this issue, just add an error handler for this case, 
> so that if "Pause Upgrade" failed, an alert popup will show the error message.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14441) EU/RU: add error handler for 'Pause upgrade'

[Xi Wang (JIRA)]

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

Xi Wang updated AMBARI-14441:
-
Summary: EU/RU: add error handler for 'Pause upgrade'  (was: EU/RU: add 
error handler for "Pause upgrade")

> EU/RU: add error handler for 'Pause upgrade'
> 
>
> Key: AMBARI-14441
> URL: https://issues.apache.org/jira/browse/AMBARI-14441
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Critical
> Fix For: 2.2.1
>
>
> STR
> # deploy cluster
> # start RU
> # try to pause upgrade one manual step
> Result: upgrade not paused, service actions not available
> As not able to reproduce this issue, just add an error handler for this case, 
> so that if "Pause Upgrade" failed, an alert popup will show the error message.
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMBARI-14441) EU/RU: add error handler for "Pause upgrade"

[Xi Wang (JIRA)]

Xi Wang created AMBARI-14441:


 Summary: EU/RU: add error handler for "Pause upgrade"
 Key: AMBARI-14441
 URL: https://issues.apache.org/jira/browse/AMBARI-14441
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.2.0
Reporter: Xi Wang
Assignee: Xi Wang
Priority: Critical
 Fix For: 2.2.1


STR
# deploy cluster
# start RU
# try to pause upgrade one manual step
Result: upgrade not paused, service actions not available


As not able to reproduce this issue, just add an error handler for this case, 
so that if "Pause Upgrade" failed, an alert popup will show the error message.

 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14436) Spark ThriftServer Does Not Upgrade

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-14436:


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

This message is automatically generated.

> Spark ThriftServer Does Not Upgrade
> ---
>
> Key: AMBARI-14436
> URL: https://issues.apache.org/jira/browse/AMBARI-14436
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-14436.patch
>
>
> The blueprint is deploying SPARK_THRIFTSERVER
> {code}
> {
> "name": "SPARK_THRIFTSERVER"
> },
> {code}
> The failure is due to:
> {code}
> The following components were found to have version mismatches.  Finalize 
> will not complete successfully:
> os-s11-3-dzcnju-ambari-eu-1-2.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-4.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-5.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> {code}
> This is because the STS is not part of any upgrade packs. Since it first 
> appeared in HDP 2.3.2, the 2 upgrade packs for HDP 2.3 -> 2.3+ should be 
> updated to include STS.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 41572: Disable the Atlas Metadata Server Web UI alert

[Swapan Shridhar]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41572/
---

(Updated Dec. 18, 2015, 11:34 p.m.)


Review request for Ambari and Sumit Mohanty.


Changes
---

Updated the Testing Section.


Bugs: AMBARI-14440
https://issues.apache.org/jira/browse/AMBARI-14440


Repository: ambari


Description
---

Disable the Atlas Metadata Server Web UI alert.

Reason for doing this: Currently, with Ambari-2.3.0.0 builds, Atlas version 
2.3.99.0-175 is getting installed, where its WEB UI is not responding (Error: 
503).


Diffs
-

  ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/alerts.json 
5eaaace 

Diff: https://reviews.apache.org/r/41572/diff/


Testing (updated)
---

* Before deploying the Cluster, introduced the new ATLAS/alerts.json.
* Metadata Web UI alert was shown disabled. Screenshots attached.


File Attachments (updated)


Atlas - No alert pertaining to its Web UI.png
  
https://reviews.apache.org/media/uploaded/files/2015/12/18/cefa3cd8-86ab-4656-94be-7835f3c34802__Atlas_-_No_alert_pertaining_to_its_Web_UI.png
Atlas - Metadata Web UI alert shown disabled..png
  
https://reviews.apache.org/media/uploaded/files/2015/12/18/eb101f1a-49c0-4b1c-9eee-13eb083c1526__Atlas_-_Metadata_Web_UI_alert_shown_disabled..png


Thanks,

Swapan Shridhar

Re: Review Request 41572: Disable the Atlas Metadata Server Web UI alert

[Sumit Mohanty]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41572/#review111314
---

Ship it!


Ship It!

- Sumit Mohanty


On Dec. 18, 2015, 11:09 p.m., Swapan Shridhar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41572/
> ---
> 
> (Updated Dec. 18, 2015, 11:09 p.m.)
> 
> 
> Review request for Ambari and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-14440
> https://issues.apache.org/jira/browse/AMBARI-14440
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Disable the Atlas Metadata Server Web UI alert.
> 
> Reason for doing this: Currently, with Ambari-2.3.0.0 builds, Atlas version 
> 2.3.99.0-175 is getting installed, where its WEB UI is not responding (Error: 
> 503).
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/alerts.json 
> 5eaaace 
> 
> Diff: https://reviews.apache.org/r/41572/diff/
> 
> 
> Testing
> ---
> 
> * Deployed the ATLAS/alerts.json file and deleted the existing ALERT from UI. 
> Alert wasn't shown after that.
> 
> 
> Thanks,
> 
> Swapan Shridhar
> 
>

[jira] [Updated] (AMBARI-14440) Disable the Atlas Metadata Server Web UI alert

[Swapan Shridhar (JIRA)]

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

Swapan Shridhar updated AMBARI-14440:
-
Attachment: AMBARI-14440.patch

> Disable the Atlas Metadata Server Web UI alert
> --
>
> Key: AMBARI-14440
> URL: https://issues.apache.org/jira/browse/AMBARI-14440
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.3.0
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.3.0
>
> Attachments: AMBARI-14440.patch
>
>
> Disable the Atlas Metadata Server Web UI alert



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14437) Unable To Restart HCat Client When Not Colocated With WebHCat Server

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-14437:


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

This message is automatically generated.

> Unable To Restart HCat Client When Not Colocated With WebHCat Server
> 
>
> Key: AMBARI-14437
> URL: https://issues.apache.org/jira/browse/AMBARI-14437
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.2.1
>
> Attachments: AMBARI-14437.patch
>
>
> Errors are encountered while restart Hive HCat client when it is not located 
> on a host which also has WebHCat daemon.
> {code:title=This is good - the pointers have moved for 2.3.4}
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp/2.3.4.0-3485/hive-hcatalog/etc
> total 4
> lrwxrwxrwx 1 root root   33 Dec 18 14:45 hcatalog -> 
> /etc/hive-hcatalog/2.3.4.0-3485/0
> drwxr-xr-x 2 root root 4096 Dec 18 14:45 init.d
> lrwxrwxrwx 1 root root   32 Dec 18 14:45 webhcat -> 
> /etc/hive-webhcat/2.3.4.0-3485/0
> {code}
> {code:title=This is bad - current for hcatalog is still 2.3.2, which has the 
> symlink issue}
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp/current | grep hive
> lrwxrwxrwx 1 root root 26 Dec 18 15:50 hive-client -> 
> /usr/hdp/2.3.4.0-3485/hive
> lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-metastore -> 
> /usr/hdp/2.3.2.0-2826/hive
> lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-server2 -> 
> /usr/hdp/2.3.2.0-2826/hive
> lrwxrwxrwx 1 root root 35 Dec 18 12:59 hive-webhcat -> 
> /usr/hdp/2.3.2.0-2826/hive-hcatalog
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp2.3.2.0-2826/hive-hcatalog/etc
> lrwxrwxrwx 1 root root 23 Dec 18 20:35 hcatalog -> /etc/hive-hcatalog/conf
> lrwxrwxrwx 1 root root 22 Dec 18 20:35 webhcat -> /etc/hive-webhcat/conf
> {code}
> The problem is that {{hcat_client.py}} must write out configs to 
> {{/usr/hdp/current/hive-webhcat/etc/hcatalog}} but {{hcat_client.py}} doesn't 
> {{hdp-select}} anything.
> So that the "current" pointers are never changed. {{hcat_client.py}} should 
> probably {{hdp-select hive-webhcat}} since there is no {{hcat-client}} in 
> {{hdp-select}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-11358) During RU, capacity scheduler config needs to be modified for HDP-2.3 to get rid of bad values

[David Tucker (JIRA)]

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

David Tucker commented on AMBARI-11358:
---

This affects HDP 2.2.9 + Ambari 1.7.0 too... YARN-4483

> During RU, capacity scheduler config needs to be modified for HDP-2.3 to get 
> rid of bad values
> --
>
> Key: AMBARI-11358
> URL: https://issues.apache.org/jira/browse/AMBARI-11358
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.1.0
>
>
> The following three config properties should be removed if the values are the 
> HDP-2.2 default.
> * yarn.scheduler.capacity.root.accessible-node-labels.default.capacity
> ** Remove if value is "-1"
> * yarn.scheduler.capacity.root.accessible-node-labels.default.maximum-capacity
> ** Remove if value is "-1"
> * yarn.scheduler.capacity.root.default-node-label-expression
> ** Remove if value is " " (space)
> There is currently no logic in place that says remove a property if the 
> property meets a condition. That would require work. Some options:
> - We have the ability to set a property if a property meets a condition. For 
> example, we can set 
> {{yarn.scheduler.capacity.root.accessible-node-labels.default.capacity}} to 
> {{""}} or {{10}} if it is currently {{-1}}
> - We can just set it regardless of any condition to any value
> - We can just remove it outright
> - We can write a pre-req check and have the user change it.
> The best balance of effort/reward is option #1 - conditionally set the 
> properties.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 41572: Disable the Atlas Metadata Server Web UI alert

[Swapan Shridhar]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41572/
---

Review request for Ambari and Sumit Mohanty.


Bugs: AMBARI-14440
https://issues.apache.org/jira/browse/AMBARI-14440


Repository: ambari


Description
---

Disable the Atlas Metadata Server Web UI alert.

Reason for doing this: Currently, with Ambari-2.3.0.0 builds, Atlas version 
2.3.99.0-175 is getting installed, where its WEB UI is not responding (Error: 
503).


Diffs
-

  ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/alerts.json 
5eaaace 

Diff: https://reviews.apache.org/r/41572/diff/


Testing
---

* Deployed the ATLAS/alerts.json file and deleted the existing ALERT from UI. 
Alert wasn't shown after that.


Thanks,

Swapan Shridhar

[jira] [Created] (AMBARI-14440) Disable the Atlas Metadata Server Web UI alert

[Swapan Shridhar (JIRA)]

Swapan Shridhar created AMBARI-14440:


 Summary: Disable the Atlas Metadata Server Web UI alert
 Key: AMBARI-14440
 URL: https://issues.apache.org/jira/browse/AMBARI-14440
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.3.0
Reporter: Swapan Shridhar
Assignee: Swapan Shridhar
 Fix For: 2.3.0


Disable the Atlas Metadata Server Web UI alert



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-11670) Width of services menu container is fixed and causes part of longer service names to be rendered outside the frame

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-11670:


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

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

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

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

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

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

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

This message is automatically generated.

> Width of services menu container is fixed and causes part of longer service 
> names to be rendered outside the frame
> --
>
> Key: AMBARI-11670
> URL: https://issues.apache.org/jira/browse/AMBARI-11670
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.0
>Reporter: Sangeeta Ravindran
>Assignee: Keta Patel
>Priority: Minor
> Attachments: AMBARI-11670.patch, big_alert_count.png, 
> long_service_name.png, service_name_and_alerts_with_fix.png
>
>
> If a service has a really long name (19 characters or more), part of the 
> service name is rendered outside the frame. Any action icons for e.g. refresh 
> also appear outside the frame.
> The frame width should change dynamically to accommodate a longer service 
> name or the service name should wrap to the next line.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14439) Categorize Ambari unit tests with Slow/Fast to run only desired group

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-14439:
-
Attachment: AMBARI-14439.trunk.patch

> Categorize Ambari unit tests with Slow/Fast to run only desired group
> -
>
> Key: AMBARI-14439
> URL: https://issues.apache.org/jira/browse/AMBARI-14439
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-server
>Affects Versions: 2.3.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.3.0
>
> Attachments: AMBARI-14439.trunk.patch
>
>
> Categorize the unit tests with wither SlowTest, FastTest, and some other 
> group based on the area.
> This will allow us to run a test suite that matches a given group.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14439) Categorize Ambari unit tests with Slow/Fast to run only desired group

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez commented on AMBARI-14439:
--

Idea is to call the following,

mvn clean test -P ${profile_id}
mvn clean -Drat.ignoreErrors=true test -P FastTest > fast-tests.txt
mvn clean -Drat.ignoreErrors=true test -P NonFastTest > nonfast-tests.txt

> Categorize Ambari unit tests with Slow/Fast to run only desired group
> -
>
> Key: AMBARI-14439
> URL: https://issues.apache.org/jira/browse/AMBARI-14439
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-server
>Affects Versions: 2.3.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.3.0
>
>
> Categorize the unit tests with wither SlowTest, FastTest, and some other 
> group based on the area.
> This will allow us to run a test suite that matches a given group.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (AMBARI-14439) Categorize Ambari unit tests with Slow/Fast to run only desired group

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez edited comment on AMBARI-14439 at 12/18/15 10:25 PM:
-

Idea is to call the following,

{code}
mvn clean test -P ${profile_id}
mvn clean -Drat.ignoreErrors=true test -P FastTest > fast-tests.txt
mvn clean -Drat.ignoreErrors=true test -P NonFastTest > nonfast-tests.txt
{code}


was (Author: afernandez):
Idea is to call the following,

mvn clean test -P ${profile_id}
mvn clean -Drat.ignoreErrors=true test -P FastTest > fast-tests.txt
mvn clean -Drat.ignoreErrors=true test -P NonFastTest > nonfast-tests.txt

> Categorize Ambari unit tests with Slow/Fast to run only desired group
> -
>
> Key: AMBARI-14439
> URL: https://issues.apache.org/jira/browse/AMBARI-14439
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-server
>Affects Versions: 2.3.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.3.0
>
>
> Categorize the unit tests with wither SlowTest, FastTest, and some other 
> group based on the area.
> This will allow us to run a test suite that matches a given group.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 41569: AMBARI-14439. Categorize Ambari unit tests with Slow/Fast to run only desired group

[Alejandro Fernandez]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41569/
---

Review request for Ambari, Aravindan Vijayan, Dmytro Grinenko, Di Li, Dmitro 
Lisnichenko, Jonathan Hurley, Jayush Luniya, Nate Cole, Robert Levas, Robert 
Nettleton, Nahappan Somasundaram, Swapan Shridhar, and Sid Wagle.


Bugs: AMBARI-14439
https://issues.apache.org/jira/browse/AMBARI-14439


Repository: ambari


Description
---

Categorize the unit tests with wither SlowTest, FastTest, and some other group 
based on the area.
This will allow us to run a test suite that matches a given group.

mvn clean test -P ${profile_id}
mvn clean -Drat.ignoreErrors=true test -P FastTest > fast-tests.txt
mvn clean -Drat.ignoreErrors=true test -P NonFastTest > nonfast-tests.txt


Diffs
-

  ambari-server/pom.xml 56d9e44 
  ambari-server/src/test/java/org/apache/ambari/server/AlertTest.java 
PRE-CREATION 
  ambari-server/src/test/java/org/apache/ambari/server/AmbariUpgradeTest.java 
PRE-CREATION 
  ambari-server/src/test/java/org/apache/ambari/server/BlueprintTest.java 
PRE-CREATION 
  ambari-server/src/test/java/org/apache/ambari/server/FastTest.java 
PRE-CREATION 
  ambari-server/src/test/java/org/apache/ambari/server/KerberosTest.java 
PRE-CREATION 
  ambari-server/src/test/java/org/apache/ambari/server/SlowTest.java 
PRE-CREATION 
  ambari-server/src/test/java/org/apache/ambari/server/StackUpgradeTest.java 
PRE-CREATION 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/ClientRetryPropertyCheckTest.java
 7b8239c 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/ComponentsInstallationCheckTest.java
 450d74e 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/ConfigurationMergeCheckTest.java
 68a0522 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/HiveDynamicServiceDiscoveryCheckTest.java
 cdf13eb 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/HiveMultipleMetastoreCheckTest.java
 16f383a 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/HostMaintenanceModeCheckTest.java
 0e14376 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/HostsHeartbeatCheckTest.java
 cc2c276 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/HostsMasterMaintenanceCheckTest.java
 9fcb319 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/HostsRepositoryVersionCheckTest.java
 4529554 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/InstallPackagesCheckTest.java
 080ca3a 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/MapReduce2JobHistoryStatePreservingCheckTest.java
 bfe0c3e 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/RangerPasswordCheckTest.java
 afa3789 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/SecondaryNamenodeDeletedCheckTest.java
 e2617bf 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/ServicesMaintenanceModeCheckTest.java
 a941b7a 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/ServicesMapReduceDistributedCacheCheckTest.java
 22f2b1b 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/ServicesNamenodeHighAvailabilityCheckTest.java
 abe7abe 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/ServicesNamenodeTruncateCheckTest.java
 87d4167 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/ServicesUpCheckTest.java
 88826a0 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/ServicesYarnWorkPreservingCheckTest.java
 98cfb18 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/UpgradeCheckOrderTest.java
 7d70311 
  
ambari-server/src/test/java/org/apache/ambari/server/checks/YarnTimelineServerStatePreservingCheckTest.java
 7469bbc 

Diff: https://reviews.apache.org/r/41569/diff/


Testing
---

Verified it worked on the handful of tests I annotated.


Thanks,

Alejandro Fernandez

[jira] [Updated] (AMBARI-14437) Unable To Restart HCat Client When Not Colocated With WebHCat Server

[Jonathan Hurley (JIRA)]

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

Jonathan Hurley updated AMBARI-14437:
-
Description: 
Errors are encountered while restart Hive HCat client when it is not located on 
a host which also has WebHCat daemon.

{code:title=This is good - the pointers have moved for 2.3.4}
root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# ls 
-l /usr/hdp/2.3.4.0-3485/hive-hcatalog/etc
total 4
lrwxrwxrwx 1 root root   33 Dec 18 14:45 hcatalog -> 
/etc/hive-hcatalog/2.3.4.0-3485/0
drwxr-xr-x 2 root root 4096 Dec 18 14:45 init.d
lrwxrwxrwx 1 root root   32 Dec 18 14:45 webhcat -> 
/etc/hive-webhcat/2.3.4.0-3485/0
{code}

{code:title=This is bad - current for hcatalog is still 2.3.2, which has the 
symlink issue}
root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# ls 
-l /usr/hdp/current | grep hive
lrwxrwxrwx 1 root root 26 Dec 18 15:50 hive-client -> /usr/hdp/2.3.4.0-3485/hive
lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-metastore -> 
/usr/hdp/2.3.2.0-2826/hive
lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-server2 -> 
/usr/hdp/2.3.2.0-2826/hive
lrwxrwxrwx 1 root root 35 Dec 18 12:59 hive-webhcat -> 
/usr/hdp/2.3.2.0-2826/hive-hcatalog

root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# ls 
-l /usr/hdp2.3.2.0-2826/hive-hcatalog/etc
lrwxrwxrwx 1 root root 23 Dec 18 20:35 hcatalog -> /etc/hive-hcatalog/conf
lrwxrwxrwx 1 root root 22 Dec 18 20:35 webhcat -> /etc/hive-webhcat/conf
{code}

The problem is that {{hcat_client.py}} must write out configs to 
{{/usr/hdp/current/hive-webhcat/etc/hcatalog}} but {{hcat_client.py}} doesn't 
{{hdp-select}} anything.

So that the "current" pointers are never changed. {{hcat_client.py}} should 
probably {{hdp-select hive-webhcat}} since there is no {{hcat-client}} in 
{{hdp-select}}.


  was:
Errors are encountered while restart Hive HCat client when it is not located on 
a host which also has WebHCat daemon.

{code:title=This is good - the pointers have moved for 2.3.4}
root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# ls 
-l /usr/hdp/2.3.4.0-3485/hive-hcatalog/etc
total 4
lrwxrwxrwx 1 root root   33 Dec 18 14:45 hcatalog -> 
/etc/hive-hcatalog/2.3.4.0-3485/0
drwxr-xr-x 2 root root 4096 Dec 18 14:45 init.d
lrwxrwxrwx 1 root root   32 Dec 18 14:45 webhcat -> 
/etc/hive-webhcat/2.3.4.0-3485/0
{code}

{code:title=This is bad - current for hcatalog is still 2.3.2, which has the 
symlink issue}
root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# ls 
-l /usr/hdp/current | grep hive
lrwxrwxrwx 1 root root 26 Dec 18 15:50 hive-client -> /usr/hdp/2.3.4.0-3485/hive
lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-metastore -> 
/usr/hdp/2.3.2.0-2826/hive
lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-server2 -> 
/usr/hdp/2.3.2.0-2826/hive
lrwxrwxrwx 1 root root 35 Dec 18 12:59 hive-webhcat -> 
/usr/hdp/2.3.2.0-2826/hive-hcatalog
{code}

The problem is that {{hcat_client.py}} must write out configs to 
{{/usr/hdp/current/hive-webhcat/etc/hcatalog}} but {{hcat_client.py}} doesn't 
{{hdp-select}} anything.

So that the "current" pointers are never changed. {{hcat_client.py}} should 
probably {{hdp-select hive-webhcat}} since there is no {{hcat-client}} in 
{{hdp-select}}.



> Unable To Restart HCat Client When Not Colocated With WebHCat Server
> 
>
> Key: AMBARI-14437
> URL: https://issues.apache.org/jira/browse/AMBARI-14437
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.2.1
>
> Attachments: AMBARI-14437.patch
>
>
> Errors are encountered while restart Hive HCat client when it is not located 
> on a host which also has WebHCat daemon.
> {code:title=This is good - the pointers have moved for 2.3.4}
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp/2.3.4.0-3485/hive-hcatalog/etc
> total 4
> lrwxrwxrwx 1 root root   33 Dec 18 14:45 hcatalog -> 
> /etc/hive-hcatalog/2.3.4.0-3485/0
> drwxr-xr-x 2 root root 4096 Dec 18 14:45 init.d
> lrwxrwxrwx 1 root root   32 Dec 18 14:45 webhcat -> 
> /etc/hive-webhcat/2.3.4.0-3485/0
> {code}
> {code:title=This is bad - current for hcatalog is still 2.3.2, which has the 
> symlink issue}
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp/current | grep hive
> lrwxrwxrwx 1 root root 26 Dec 18 15:50 hive-client -> 
> /usr/hdp/2.3.4.0-3485/hive
> lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-metastore -> 
> /usr/hdp/2.3.2.0-2826/hive
> lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-server2 -> 
> /usr/hdp/2.3.2.0-2826/hive
> lrwxrwxr

[jira] [Commented] (AMBARI-14434) Passwords for headless principals with cached keytab files are changed unnecessarily

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-14434:


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

This message is automatically generated.

> Passwords for headless principals with cached keytab files are changed 
> unnecessarily
> 
>
> Key: AMBARI-14434
> URL: https://issues.apache.org/jira/browse/AMBARI-14434
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 2.4.0, 2.2.1
>
> Attachments: AMBARI-14434_branch-2.2.1-pre_01.patch, 
> AMBARI-14434_trunk_01.patch
>
>
> Passwords for headless principals with cached keytab files are changed 
> unnecessarily.
> Solution check for the existence of a cached keytab file for headless 
> principals before updating their passwords.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14433) RBAC : "Cluster User" and "Cluster Operator" role has "View stack version details" permission, but no place on UI to see it.

[Hudson (JIRA)]

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

Hudson commented on AMBARI-14433:
-

ABORTED: Integrated in Ambari-trunk-Commit #4068 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4068/])
AMBARI-14433. RBAC : "Cluster User" and "Cluster Operator" role has (hiveww: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=d804eb398c5f0fe796f8417054cb97fc46795caa])
* ambari-web/app/routes/main.js
* ambari-web/test/views/main/menu_test.js
* ambari-web/test/views/main/admin_test.js
* ambari-web/app/views/main/menu.js
* ambari-web/app/utils/ajax/ajax.js
* ambari-web/app/views/main/admin.js


> RBAC : "Cluster User" and "Cluster Operator" role has "View stack version 
> details" permission, but no place on UI to see it.
> 
>
> Key: AMBARI-14433
> URL: https://issues.apache.org/jira/browse/AMBARI-14433
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-14433.patch
>
>
> RBAC : "Cluster User" and "Cluster Operator" role have "View stack version 
> details" permission, but no place on UI to see it.
> Typically, it is seen from Admin Tab -> Stacks and Versions. As Admin Tab is 
> not shown in these roles, we miss on showing the "Stack version details".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14431) Agent becomes unresposive after version incompatible Exception

[Hudson (JIRA)]

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

Hudson commented on AMBARI-14431:
-

ABORTED: Integrated in Ambari-trunk-Commit #4068 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4068/])
AMBARI-14431. Agent becomes unresposive after version incompatible (aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=d090dbf78c8860a7e7c7d20330b3f810556f6325])
* ambari-agent/src/main/python/ambari_agent/main.py


> Agent becomes unresposive after version incompatible Exception 
> ---
>
> Key: AMBARI-14431
> URL: https://issues.apache.org/jira/browse/AMBARI-14431
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-14431.patch
>
>
> While testing with perf cluster found this bug:  
> Agent did not register with server due to version incompatible error and then
> did not recover from this state, although the server side was fixed.  
> If agent is not retrying, it should quit
> 
> 
> 
> ERROR 2015-12-10 23:04:35,184 Controller.py:165 - Cannot register host 
> with non compatible agent version, 
> hostname=perf-a-1.c.pramod-thangali.internal, agentVersion=2.2.0.0, 
> serverVersion=2.1.3.0
> INFO 2015-12-10 23:04:35,184 Controller.py:392 - Registration response 
> from perf-a-1.c.pramod-thangali.internal was FAILED
> ERROR 2015-12-10 23:04:35,185 main.py:315 - Fatal exception occurred:
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/site-packages/ambari_agent/main.py", line 312, 
> in 
> main(heartbeat_stop_callback)
>   File "/usr/lib/python2.6/site-packages/ambari_agent/main.py", line 303, 
> in main
> ExitHelper.execute_cleanup()
> TypeError: unbound method execute_cleanup() must be called with 
> ExitHelper instance as first argument (got nothing instead)
> 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14404) Ambari Admin: incorrect cluster filter behaviour on Versions page

[Hudson (JIRA)]

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

Hudson commented on AMBARI-14404:
-

ABORTED: Integrated in Ambari-trunk-Commit #4068 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4068/])
AMBARI-14404. Ambari Admin: incorrect cluster filter behaviour on (hiveww: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=2c7ecd12ece30851395d518e6ad3f1fdf8b94cf9])
* ambari-admin/src/main/resources/ui/admin-web/app/views/stackVersions/list.html
* 
ambari-admin/src/main/resources/ui/admin-web/test/unit/controllers/stackVersions/StackversionsListCtrl_test.js
* 
ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/stackVersions/StackVersionsListCtrl.js


> Ambari Admin: incorrect cluster filter behaviour on Versions page
> -
>
> Key: AMBARI-14404
> URL: https://issues.apache.org/jira/browse/AMBARI-14404
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-14404.patch, versions-cluster-filter.mp4
>
>
> Choosing some options from cluster filter for Versions table in Admin View 
> results in setting filter back to default value ('All'):



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14409) Blueprints: Kerberos deployments fail intermittently due to invalid keytabs

[Hudson (JIRA)]

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

Hudson commented on AMBARI-14409:
-

ABORTED: Integrated in Ambari-trunk-Commit #4068 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4068/])
AMBARI-14409. Blueprints Kerberos deployments fail intermittently due to 
(rnettleton: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=232522483bb3445aabd0c2a5eec99dc789eda47a])
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
* 
ambari-server/src/test/java/org/apache/ambari/server/topology/ClusterConfigurationRequestTest.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/topology/ClusterConfigurationRequest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/CreatePrincipalsServerAction.java


> Blueprints: Kerberos deployments fail intermittently due to invalid keytabs
> ---
>
> Key: AMBARI-14409
> URL: https://issues.apache.org/jira/browse/AMBARI-14409
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
>Priority: Critical
> Fix For: 2.2.1
>
> Attachments: AMBARI-14409.patch
>
>
> The basic problem appears to be a concurrency problem, in which keytabs are 
> sometimes generated incorrectly.  This results in certain keytabs across the 
> cluster having different created/modified times in the keytabs, which can 
> cause Kerberos Preauthentication failures, such as the following:
> {code}
> resource_management.core.exceptions.Fail: Execution of '/usr/bin/kinit -kt 
> /etc/security/keytabs/smokeuser.headless.keytab 
> ambari-qa-cluster...@example.com;' returned 1. kinit: Password incorrect 
> while getting initial credentials
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_server.py",
>  line 179, in 
> ZookeeperServer().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 217, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_server.py",
>  line 55, in start
> zookeeper_service(action='start', upgrade_type=upgrade_type)
>   File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py", 
> line 89, in thunk
> return fn(*args, **kwargs)
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_service.py",
>  line 54, in zookeeper_service
> user=params.smokeuser
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
> line 154, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 158, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 121, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 238, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 70, in inner
> result = function(command, **kwargs)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 92, in checked_call
> tries=tries, try_sleep=try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 291, in _call
> raise Fail(err_msg)
> {code}
> The basic underlying problem appears to be invalid keytabs.  Looking to the 
> keytabs on the failing node:
> {code}
> [root@rwntest-2 keytabs]# klist -kt smokeuser.headless.keytab
> Keytab name: FILE:smokeuser.headless.keytab
> KVNO Timestamp Principal
>  - 
> 
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
> {code}
> whereas other nodes in the cluster report the following value for the same 
> keytab:
> {code}
> [root@rwntest-4 keytabs]# klist -kt smok

[jira] [Commented] (AMBARI-14416) Refactor Host Details controller

[Hudson (JIRA)]

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

Hudson commented on AMBARI-14416:
-

ABORTED: Integrated in Ambari-trunk-Commit #4068 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4068/])
AMBARI-14416. Refactor Host Details controller (hiveww: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=6c38d84b1152807c0b94f175e090d90ad0c74a28])
* ambari-web/app/utils/configs/nn_ha_config_initializer.js
* ambari-web/app/utils/configs/ha_config_initializer_class.js
* ambari-web/app/utils/configs/config_initializer_class.js
* ambari-web/app/utils/configs/config_initializer.js
* ambari-web/app/mixins.js
* ambari-web/app/utils/configs/mount_points_based_initializer_mixin.js
* ambari-web/app/utils/configs/hosts_based_initializer_mixin.js
* ambari-web/app/utils/configs/control_flow_initializer_mixin.js
* ambari-web/app/controllers/main/host/details.js
* ambari-web/app/utils/configs/rm_ha_config_initializer.js
* ambari-web/app/utils/configs/add_component_config_initializer.js
* ambari-web/app/messages.js
* ambari-web/test/controllers/main/host/details_test.js


> Refactor Host Details controller
> 
>
> Key: AMBARI-14416
> URL: https://issues.apache.org/jira/browse/AMBARI-14416
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-web
>Affects Versions: 2.3.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-14416.patch
>
>
> Configs updater should be done as ConfigInitializer



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14437) Unable To Restart HCat Client When Not Colocated With WebHCat Server

[Mahadev konar (JIRA)]

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

Mahadev konar updated AMBARI-14437:
---
Fix Version/s: (was: 2.2.0)
   2.2.1

> Unable To Restart HCat Client When Not Colocated With WebHCat Server
> 
>
> Key: AMBARI-14437
> URL: https://issues.apache.org/jira/browse/AMBARI-14437
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.2.1
>
> Attachments: AMBARI-14437.patch
>
>
> Errors are encountered while restart Hive HCat client when it is not located 
> on a host which also has WebHCat daemon.
> {code:title=This is good - the pointers have moved for 2.3.4}
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp/2.3.4.0-3485/hive-hcatalog/etc
> total 4
> lrwxrwxrwx 1 root root   33 Dec 18 14:45 hcatalog -> 
> /etc/hive-hcatalog/2.3.4.0-3485/0
> drwxr-xr-x 2 root root 4096 Dec 18 14:45 init.d
> lrwxrwxrwx 1 root root   32 Dec 18 14:45 webhcat -> 
> /etc/hive-webhcat/2.3.4.0-3485/0
> {code}
> {code:title=This is bad - current for hcatalog is still 2.3.2, which has the 
> symlink issue}
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp/current | grep hive
> lrwxrwxrwx 1 root root 26 Dec 18 15:50 hive-client -> 
> /usr/hdp/2.3.4.0-3485/hive
> lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-metastore -> 
> /usr/hdp/2.3.2.0-2826/hive
> lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-server2 -> 
> /usr/hdp/2.3.2.0-2826/hive
> lrwxrwxrwx 1 root root 35 Dec 18 12:59 hive-webhcat -> 
> /usr/hdp/2.3.2.0-2826/hive-hcatalog
> {code}
> The problem is that {{hcat_client.py}} must write out configs to 
> {{/usr/hdp/current/hive-webhcat/etc/hcatalog}} but {{hcat_client.py}} doesn't 
> {{hdp-select}} anything.
> So that the "current" pointers are never changed. {{hcat_client.py}} should 
> probably {{hdp-select hive-webhcat}} since there is no {{hcat-client}} in 
> {{hdp-select}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 41561: Spark ThriftServer Does Not Upgrade

[Jonathan Hurley]

> On Dec. 18, 2015, 2:49 p.m., Alejandro Fernandez wrote:
> > ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml,
> >  line 440
> > 
> >
> > I'm guessing someone tested the actual python files.

See my comment above - I performed an upgrade from 2.3.4 to 2.3.4+ with 3 STS 
instances.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41561/#review111246
---


On Dec. 18, 2015, 2:32 p.m., Jonathan Hurley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41561/
> ---
> 
> (Updated Dec. 18, 2015, 2:32 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Nate Cole, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-14436
> https://issues.apache.org/jira/browse/AMBARI-14436
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> The blueprint is deploying SPARK_THRIFTSERVER
> {code}
> {
> "name": "SPARK_THRIFTSERVER"
> },
> {code}
> 
> The failure is due to:
> {code}
> The following components were found to have version mismatches.  Finalize 
> will not complete successfully:
> os-s11-3-dzcnju-ambari-eu-1-2.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-4.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-5.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> {code}
> 
> This is because the STS is not part of any upgrade packs. Since it first 
> appeared in HDP 2.3.2, the 2 upgrade packs for HDP 2.3 -> 2.3+ should be 
> updated to include STS.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
>  5e0d364 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml 
> e31e7fb 
> 
> Diff: https://reviews.apache.org/r/41561/diff/
> 
> 
> Testing
> ---
> 
> Upgraded a cluster with STS installed.
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

[jira] [Created] (AMBARI-14439) Categorize Ambari unit tests with Slow/Fast to run only desired group

[Alejandro Fernandez (JIRA)]

Alejandro Fernandez created AMBARI-14439:


 Summary: Categorize Ambari unit tests with Slow/Fast to run only 
desired group
 Key: AMBARI-14439
 URL: https://issues.apache.org/jira/browse/AMBARI-14439
 Project: Ambari
  Issue Type: Story
  Components: ambari-server
Affects Versions: 2.3.0
Reporter: Alejandro Fernandez
Assignee: Alejandro Fernandez
 Fix For: 2.3.0


Categorize the unit tests with wither SlowTest, FastTest, and some other group 
based on the area.
This will allow us to run a test suite that matches a given group.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMBARI-14438) Improve Ambari unit tests time to less than 30 mins

[Alejandro Fernandez (JIRA)]

Alejandro Fernandez created AMBARI-14438:


 Summary: Improve Ambari unit tests time to less than 30 mins
 Key: AMBARI-14438
 URL: https://issues.apache.org/jira/browse/AMBARI-14438
 Project: Ambari
  Issue Type: Epic
  Components: ambari-server
Affects Versions: 2.3.0
Reporter: Alejandro Fernandez
Assignee: Alejandro Fernandez
 Fix For: 2.3.0


We need to drastically reduce the time it takes unit tests to run.
On Apache, they often take 3-4+ hours.
This discourages developers from running them locally (which can take 30-50 
mins).

* Refactor some test suites to reuse DB to make it faster
* Run tests in parallel (currently some tests fail if not clean or reuse 
objects)
* Make Ambari Web independent of Ambari Server, so that can still get results 
even if one fails
* Annotate tests based on priority and type - useful for devs to run just the 
tests they care about locally
* Sumit: Internal infra for running tests locally. Annotate some tests to not 
run on Apache.


Optional item:
* Script to ensure Apache process, get results if unit tests pass, and always 
attach patch to Apache Jira



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14434) Passwords for headless principals with cached keytab files are changed unnecessarily

[Robert Levas (JIRA)]

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

Robert Levas commented on AMBARI-14434:
---

Committed to trunk
{noformat}
commit f0b029e57daf5e3ec01b8dbc53ea41886ebe5e55
Author: Robert Levas 
Date:   Fri Dec 18 16:23:45 2015 -0500
{noformat}


> Passwords for headless principals with cached keytab files are changed 
> unnecessarily
> 
>
> Key: AMBARI-14434
> URL: https://issues.apache.org/jira/browse/AMBARI-14434
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 2.4.0, 2.2.1
>
> Attachments: AMBARI-14434_branch-2.2.1-pre_01.patch, 
> AMBARI-14434_trunk_01.patch
>
>
> Passwords for headless principals with cached keytab files are changed 
> unnecessarily.
> Solution check for the existence of a cached keytab file for headless 
> principals before updating their passwords.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Ambari 2.2.0 - RC1

[Siddharth Wagle]

+1 for release.

- Sid


From: Nate Cole 
Sent: Friday, December 18, 2015 11:57 AM
To: dev@ambari.apache.org
Subject: Re: [VOTE] Ambari 2.2.0 - RC1

+1 for RC1

On 12/17/15, 5:43 PM, "Yusaku Sako"  wrote:

>+1 for the release.
>
>Verified signature, hash, rat check, was able to compile successfully
>using "mvn clean package".
>
>All unit tests passed:
>[INFO]
>
>[INFO] Reactor Summary:
>[INFO]
>[INFO] Ambari Main ... SUCCESS
>[7.946s]
>[INFO] Apache Ambari Project POM . SUCCESS
>[0.035s]
>[INFO] Ambari Web  SUCCESS
>[40.249s]
>[INFO] Ambari Views .. SUCCESS
>[2.362s]
>[INFO] Ambari Admin View . SUCCESS
>[10.831s]
>[INFO] ambari-metrics  SUCCESS
>[0.551s]
>[INFO] Ambari Metrics Common . SUCCESS
>[1.892s]
>[INFO] Ambari Metrics Hadoop Sink  SUCCESS
>[4.641s]
>[INFO] Ambari Metrics Flume Sink . SUCCESS
>[2.193s]
>[INFO] Ambari Metrics Kafka Sink . SUCCESS
>[3.150s]
>[INFO] Ambari Metrics Storm Sink . SUCCESS
>[2.172s]
>[INFO] Ambari Metrics Collector .. SUCCESS
>[54.967s]
>[INFO] Ambari Metrics Monitor  SUCCESS
>[2.122s]
>[INFO] Ambari Metrics Assembly ... SUCCESS
>[1:06.286s]
>[INFO] Ambari Server . SUCCESS
>[53:47.893s]
>[INFO] Ambari Agent .. SUCCESS
>[26.636s]
>[INFO] Ambari Client . SUCCESS
>[0.036s]
>[INFO] Ambari Python Client .. SUCCESS
>[1.384s]
>[INFO] Ambari Groovy Client .. SUCCESS
>[8.855s]
>[INFO] Ambari Shell .. SUCCESS
>[0.031s]
>[INFO] Ambari Python Shell ... SUCCESS
>[0.549s]
>[INFO] Ambari Groovy Shell ... SUCCESS
>[6.453s]
>[INFO]
>
>[INFO] BUILD SUCCESS
>[INFO]
>
>[INFO] Total time: 57:53.442s
>[INFO] Finished at: Thu Dec 17 14:18:53 PST 2015
>[INFO] Final Memory: 159M/1770M
>
>
>
>Yusaku
>
>
>
>On 12/15/15, 7:35 PM, "Jaimin Jetly"  wrote:
>
>>Hi all,
>>
>>
>>I have created an Apache Ambari 2.2.0 Release Candidate (RC1).
>>
>>
>>GIT source tag:
>>https://git-wip-us.apache.org/repos/asf/ambari/repo?p=ambari.git;a=log;h=
>>refs/tags/release-2.2.0-rc1
>>
>>
>>Staging site: http://people.apache.org/~jaimin/apache-ambari-2.2.0-rc1/
>>
>>
>>PGP release key used (signed using D30E6003):
>>http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x85041753D30E6003?
>>
>>One can look into the issues fixed in this release at
>>https://goo.gl/AU3h70
>>
>>
>>Vote will be open for 72 hours.
>>
>>
>>[ ] +1 approve
>>
>>[ ] +0 no opinion
>>
>>[ ] -1 disapprove (and reason why)
>>
>>
>>Here's my vote to start: +1
>>
>>
>>Thanks
>>
>>Jaimin Jetly
>>
>>Apache Ambari 2.2.0 Release Manager

Re: Review Request 41566: Passwords for headless principals with cached keytab files are changed unnecessarily

[Sandor Magyari]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41566/#review111269
---

Ship it!


Ship It!

- Sandor Magyari


On Dec. 18, 2015, 8:49 p.m., Robert Levas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41566/
> ---
> 
> (Updated Dec. 18, 2015, 8:49 p.m.)
> 
> 
> Review request for Ambari, Robert Nettleton and Sandor Magyari.
> 
> 
> Bugs: AMBARI-14434
> https://issues.apache.org/jira/browse/AMBARI-14434
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Passwords for headless principals with cached keytab files are changed 
> unnecessarily.
> 
> Solution check for the existence of a cached keytab file for headless 
> principals before updating their passwords.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/CreatePrincipalsServerAction.java
>  fdcc672 
> 
> Diff: https://reviews.apache.org/r/41566/diff/
> 
> 
> Testing
> ---
> 
> Manually tested
> 
> # Local unit tests:
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 1:03:54.409s
> [INFO] Finished at: Fri Dec 18 15:37:21 EST 2015
> [INFO] Final Memory: 67M/1233M
> [INFO] 
> 
> 
> # Jenkins unit test: PENDING
> 
> 
> Thanks,
> 
> Robert Levas
> 
>

Re: Review Request 41526: Hive Metastore alert timeout

[Vitalyi Brodetskyi]

> On Гру. 18, 2015, 6:05 після полудня, Alejandro Fernandez wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog221.java,
> >  lines 114-141
> > 
> >
> > It's my impression that this type of change for alerts is not uncommon. 
> > Can we have a general function to call?

We have some usefull functions in entity as of now, so i think it will be 
better to add some additional there. Even if we will decide to add some 
functions in AbstractUpgradeCatalog, i think it should be implemented as a 
feature in separate jira, with Unit Tests and etc.


- Vitalyi


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41526/#review111213
---


On Гру. 18, 2015, 4:41 після полудня, Vitalyi Brodetskyi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41526/
> ---
> 
> (Updated Гру. 18, 2015, 4:41 після полудня)
> 
> 
> Review request for Ambari, Andrew Onischuk, Dmytro Sen, Jonathan Hurley, and 
> Sumit Mohanty.
> 
> 
> Bugs: AMBARI-14424
> https://issues.apache.org/jira/browse/AMBARI-14424
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> For Hive metastore and server alerts
> 1) Change default timeout to 60 seconds
> 2) Make this a configurable script param, so people can pass this in
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/hive_check.py
>  55fd6bd 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/SchemaUpgradeHelper.java
>  5e22f71 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog221.java
>  PRE-CREATION 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/alerts.json 
> 55e3f78 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/alerts/alert_hive_metastore.py
>  c7a9102 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/alerts/alert_hive_thrift_port.py
>  a04c2a6 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog221Test.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/41526/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Vitalyi Brodetskyi
> 
>

Review Request 41566: Passwords for headless principals with cached keytab files are changed unnecessarily

[Robert Levas]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41566/
---

Review request for Ambari, Robert Nettleton and Sandor Magyari.


Bugs: AMBARI-14434
https://issues.apache.org/jira/browse/AMBARI-14434


Repository: ambari


Description
---

Passwords for headless principals with cached keytab files are changed 
unnecessarily.

Solution check for the existence of a cached keytab file for headless 
principals before updating their passwords.


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/CreatePrincipalsServerAction.java
 fdcc672 

Diff: https://reviews.apache.org/r/41566/diff/


Testing
---

Manually tested

# Local unit tests:
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 1:03:54.409s
[INFO] Finished at: Fri Dec 18 15:37:21 EST 2015
[INFO] Final Memory: 67M/1233M
[INFO] 

# Jenkins unit test: PENDING


Thanks,

Robert Levas

[jira] [Updated] (AMBARI-14434) Passwords for headless principals with cached keytab files are changed unnecessarily

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-14434:
--
Attachment: AMBARI-14434_trunk_01.patch
AMBARI-14434_branch-2.2.1-pre_01.patch

> Passwords for headless principals with cached keytab files are changed 
> unnecessarily
> 
>
> Key: AMBARI-14434
> URL: https://issues.apache.org/jira/browse/AMBARI-14434
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 2.4.0, 2.2.1
>
> Attachments: AMBARI-14434_branch-2.2.1-pre_01.patch, 
> AMBARI-14434_trunk_01.patch
>
>
> Passwords for headless principals with cached keytab files are changed 
> unnecessarily.
> Solution check for the existence of a cached keytab file for headless 
> principals before updating their passwords.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Ambari 2.2.0 - RC1

[Nate Cole]

+1 for RC1

On 12/17/15, 5:43 PM, "Yusaku Sako"  wrote:

>+1 for the release.
>
>Verified signature, hash, rat check, was able to compile successfully
>using "mvn clean package".
>
>All unit tests passed:
>[INFO] 
>
>[INFO] Reactor Summary:
>[INFO]
>[INFO] Ambari Main ... SUCCESS
>[7.946s]
>[INFO] Apache Ambari Project POM . SUCCESS
>[0.035s]
>[INFO] Ambari Web  SUCCESS
>[40.249s]
>[INFO] Ambari Views .. SUCCESS
>[2.362s]
>[INFO] Ambari Admin View . SUCCESS
>[10.831s]
>[INFO] ambari-metrics  SUCCESS
>[0.551s]
>[INFO] Ambari Metrics Common . SUCCESS
>[1.892s]
>[INFO] Ambari Metrics Hadoop Sink  SUCCESS
>[4.641s]
>[INFO] Ambari Metrics Flume Sink . SUCCESS
>[2.193s]
>[INFO] Ambari Metrics Kafka Sink . SUCCESS
>[3.150s]
>[INFO] Ambari Metrics Storm Sink . SUCCESS
>[2.172s]
>[INFO] Ambari Metrics Collector .. SUCCESS
>[54.967s]
>[INFO] Ambari Metrics Monitor  SUCCESS
>[2.122s]
>[INFO] Ambari Metrics Assembly ... SUCCESS
>[1:06.286s]
>[INFO] Ambari Server . SUCCESS
>[53:47.893s]
>[INFO] Ambari Agent .. SUCCESS
>[26.636s]
>[INFO] Ambari Client . SUCCESS
>[0.036s]
>[INFO] Ambari Python Client .. SUCCESS
>[1.384s]
>[INFO] Ambari Groovy Client .. SUCCESS
>[8.855s]
>[INFO] Ambari Shell .. SUCCESS
>[0.031s]
>[INFO] Ambari Python Shell ... SUCCESS
>[0.549s]
>[INFO] Ambari Groovy Shell ... SUCCESS
>[6.453s]
>[INFO] 
>
>[INFO] BUILD SUCCESS
>[INFO] 
>
>[INFO] Total time: 57:53.442s
>[INFO] Finished at: Thu Dec 17 14:18:53 PST 2015
>[INFO] Final Memory: 159M/1770M
>
>
>
>Yusaku
>
>
>
>On 12/15/15, 7:35 PM, "Jaimin Jetly"  wrote:
>
>>Hi all,
>>
>>
>>I have created an Apache Ambari 2.2.0 Release Candidate (RC1).
>>
>>
>>GIT source tag: 
>>https://git-wip-us.apache.org/repos/asf/ambari/repo?p=ambari.git;a=log;h=
>>refs/tags/release-2.2.0-rc1
>>
>>
>>Staging site: http://people.apache.org/~jaimin/apache-ambari-2.2.0-rc1/
>>
>>
>>PGP release key used (signed using D30E6003):
>>http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x85041753D30E6003?
>>
>>One can look into the issues fixed in this release at
>>https://goo.gl/AU3h70
>>
>>
>>Vote will be open for 72 hours.
>>
>>
>>[ ] +1 approve
>>
>>[ ] +0 no opinion
>>
>>[ ] -1 disapprove (and reason why)
>>
>>
>>Here's my vote to start: +1
>>
>>
>>Thanks
>>
>>Jaimin Jetly
>>
>>Apache Ambari 2.2.0 Release Manager

[jira] [Commented] (AMBARI-14426) If repos for the current os are not defined install_packages doesn't show error

[Richard Zang (JIRA)]

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

Richard Zang commented on AMBARI-14426:
---

+1 for patch

> If repos for the current os are not defined install_packages doesn't show 
> error
> ---
>
> Key: AMBARI-14426
> URL: https://issues.apache.org/jira/browse/AMBARI-14426
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Xi Wang
>Assignee: Xi Wang
> Fix For: 2.4.0
>
> Attachments: AMBARI-14426.patch, AMBARI-14426.patch
>
>
> 1. After cluster deployment in 'Versions' tab, On os X define new repo 
> version, but set the repos only for os Y.
> 2. Click install_packages. It gives 500 error from server with reasonable 
> error, however UI doesn't show anything to user, which is pretty confusing.
> {noformat}
> {
>   "status" : 500,
>   "message" : "Repositories for os type ubuntu12 are not defined. Repo 
> version=2.3.5.0, stackId=HDP-2.3"
> }
> {noformat}
> We could show a general error message for all the errors on this stage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14426) If repos for the current os are not defined install_packages doesn't show error

[Xi Wang (JIRA)]

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

Xi Wang commented on AMBARI-14426:
--

  11734 tests complete (13 seconds)
  137 tests pending

> If repos for the current os are not defined install_packages doesn't show 
> error
> ---
>
> Key: AMBARI-14426
> URL: https://issues.apache.org/jira/browse/AMBARI-14426
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Xi Wang
>Assignee: Xi Wang
> Fix For: 2.4.0
>
> Attachments: AMBARI-14426.patch, AMBARI-14426.patch
>
>
> 1. After cluster deployment in 'Versions' tab, On os X define new repo 
> version, but set the repos only for os Y.
> 2. Click install_packages. It gives 500 error from server with reasonable 
> error, however UI doesn't show anything to user, which is pretty confusing.
> {noformat}
> {
>   "status" : 500,
>   "message" : "Repositories for os type ubuntu12 are not defined. Repo 
> version=2.3.5.0, stackId=HDP-2.3"
> }
> {noformat}
> We could show a general error message for all the errors on this stage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 41561: Spark ThriftServer Does Not Upgrade

[Alejandro Fernandez]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41561/#review111246
---



ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
 (line 440)


I'm guessing someone tested the actual python files.


- Alejandro Fernandez


On Dec. 18, 2015, 7:32 p.m., Jonathan Hurley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41561/
> ---
> 
> (Updated Dec. 18, 2015, 7:32 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Nate Cole, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-14436
> https://issues.apache.org/jira/browse/AMBARI-14436
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> The blueprint is deploying SPARK_THRIFTSERVER
> {code}
> {
> "name": "SPARK_THRIFTSERVER"
> },
> {code}
> 
> The failure is due to:
> {code}
> The following components were found to have version mismatches.  Finalize 
> will not complete successfully:
> os-s11-3-dzcnju-ambari-eu-1-2.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-4.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-5.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> {code}
> 
> This is because the STS is not part of any upgrade packs. Since it first 
> appeared in HDP 2.3.2, the 2 upgrade packs for HDP 2.3 -> 2.3+ should be 
> updated to include STS.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
>  5e0d364 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml 
> e31e7fb 
> 
> Diff: https://reviews.apache.org/r/41561/diff/
> 
> 
> Testing
> ---
> 
> Upgraded a cluster with STS installed.
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

Re: Review Request 41562: Unable To Restart HCat Client When Not Colocated With WebHCat Server

[Nate Cole]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41562/#review111245
---

Ship it!


Ship It!

- Nate Cole


On Dec. 18, 2015, 2:38 p.m., Jonathan Hurley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41562/
> ---
> 
> (Updated Dec. 18, 2015, 2:38 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Nate Cole, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-14437
> https://issues.apache.org/jira/browse/AMBARI-14437
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Errors are encountered while restart Hive HCat client when it is not located 
> on a host which also has WebHCat daemon.
> 
> {code:title=This is good - the pointers have moved for 2.3.4}
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp/2.3.4.0-3485/hive-hcatalog/etc
> total 4
> lrwxrwxrwx 1 root root   33 Dec 18 14:45 hcatalog -> 
> /etc/hive-hcatalog/2.3.4.0-3485/0
> drwxr-xr-x 2 root root 4096 Dec 18 14:45 init.d
> lrwxrwxrwx 1 root root   32 Dec 18 14:45 webhcat -> 
> /etc/hive-webhcat/2.3.4.0-3485/0
> {code}
> 
> {code:title=This is bad - current for hcatalog is still 2.3.2, which has the 
> symlink issue}
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp/current | grep hive
> lrwxrwxrwx 1 root root 26 Dec 18 15:50 hive-client -> 
> /usr/hdp/2.3.4.0-3485/hive
> lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-metastore -> 
> /usr/hdp/2.3.2.0-2826/hive
> lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-server2 -> 
> /usr/hdp/2.3.2.0-2826/hive
> lrwxrwxrwx 1 root root 35 Dec 18 12:59 hive-webhcat -> 
> /usr/hdp/2.3.2.0-2826/hive-hcatalog
> {code}
> 
> The problem is that {{hcat_client.py}} must write out configs to 
> {{/usr/hdp/current/hive-webhcat/etc/hcatalog}} but {{hcat_client.py}} doesn't 
> {{hdp-select}} anything.
> 
> So that the "current" pointers are never changed. {{hcat_client.py}} should 
> probably {{hdp-select hive-webhcat}} since there is no {{hcat-client}} in 
> {{hdp-select}}.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hcat_client.py
>  75a37f1 
>   ambari-server/src/test/python/stacks/2.0.6/HIVE/test_hcat_client.py 396e6a1 
> 
> Diff: https://reviews.apache.org/r/41562/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> --
> Total run:853
> Total errors:0
> Total failures:0
> OK
> 
> Upgraded cluster with multiple hcat clients not located with other hive 
> components.
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

[jira] [Commented] (AMBARI-11252) Refresh icon and alert count image overlaps

[Keta Patel (JIRA)]

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

Keta Patel commented on AMBARI-11252:
-

This issue is being resolved in AMBARI-11670 as well.
The patch has been submitted.

> Refresh icon and alert count image overlaps
> ---
>
> Key: AMBARI-11252
> URL: https://issues.apache.org/jira/browse/AMBARI-11252
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.0
>Reporter: Gour Saha
>Assignee: Keta Patel
> Attachments: Ambari_Img_Overlap.png
>
>
> The yellow refresh icon and the red alert count icon overlaps. Screenshot 
> attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-11670) Width of services menu container is fixed and causes part of longer service names to be rendered outside the frame

[Keta Patel (JIRA)]

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

Keta Patel updated AMBARI-11670:

Attachment: (was: AMBARI-11670.patch)

> Width of services menu container is fixed and causes part of longer service 
> names to be rendered outside the frame
> --
>
> Key: AMBARI-11670
> URL: https://issues.apache.org/jira/browse/AMBARI-11670
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.0
>Reporter: Sangeeta Ravindran
>Assignee: Keta Patel
>Priority: Minor
> Attachments: AMBARI-11670.patch, big_alert_count.png, 
> long_service_name.png, service_name_and_alerts_with_fix.png
>
>
> If a service has a really long name (19 characters or more), part of the 
> service name is rendered outside the frame. Any action icons for e.g. refresh 
> also appear outside the frame.
> The frame width should change dynamically to accommodate a longer service 
> name or the service name should wrap to the next line.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-11670) Width of services menu container is fixed and causes part of longer service names to be rendered outside the frame

[Keta Patel (JIRA)]

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

Keta Patel updated AMBARI-11670:

Attachment: AMBARI-11670.patch

> Width of services menu container is fixed and causes part of longer service 
> names to be rendered outside the frame
> --
>
> Key: AMBARI-11670
> URL: https://issues.apache.org/jira/browse/AMBARI-11670
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.0
>Reporter: Sangeeta Ravindran
>Assignee: Keta Patel
>Priority: Minor
> Attachments: AMBARI-11670.patch, big_alert_count.png, 
> long_service_name.png, service_name_and_alerts_with_fix.png
>
>
> If a service has a really long name (19 characters or more), part of the 
> service name is rendered outside the frame. Any action icons for e.g. refresh 
> also appear outside the frame.
> The frame width should change dynamically to accommodate a longer service 
> name or the service name should wrap to the next line.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (AMBARI-11252) Refresh icon and alert count image overlaps

[Keta Patel (JIRA)]

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

Keta Patel reassigned AMBARI-11252:
---

Assignee: Keta Patel

> Refresh icon and alert count image overlaps
> ---
>
> Key: AMBARI-11252
> URL: https://issues.apache.org/jira/browse/AMBARI-11252
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.0
>Reporter: Gour Saha
>Assignee: Keta Patel
> Attachments: Ambari_Img_Overlap.png
>
>
> The yellow refresh icon and the red alert count icon overlaps. Screenshot 
> attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 41562: Unable To Restart HCat Client When Not Colocated With WebHCat Server

[Jonathan Hurley]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41562/
---

Review request for Ambari, Alejandro Fernandez, Nate Cole, and Sumit Mohanty.


Bugs: AMBARI-14437
https://issues.apache.org/jira/browse/AMBARI-14437


Repository: ambari


Description
---

Errors are encountered while restart Hive HCat client when it is not located on 
a host which also has WebHCat daemon.

{code:title=This is good - the pointers have moved for 2.3.4}
root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# ls 
-l /usr/hdp/2.3.4.0-3485/hive-hcatalog/etc
total 4
lrwxrwxrwx 1 root root   33 Dec 18 14:45 hcatalog -> 
/etc/hive-hcatalog/2.3.4.0-3485/0
drwxr-xr-x 2 root root 4096 Dec 18 14:45 init.d
lrwxrwxrwx 1 root root   32 Dec 18 14:45 webhcat -> 
/etc/hive-webhcat/2.3.4.0-3485/0
{code}

{code:title=This is bad - current for hcatalog is still 2.3.2, which has the 
symlink issue}
root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# ls 
-l /usr/hdp/current | grep hive
lrwxrwxrwx 1 root root 26 Dec 18 15:50 hive-client -> /usr/hdp/2.3.4.0-3485/hive
lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-metastore -> 
/usr/hdp/2.3.2.0-2826/hive
lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-server2 -> 
/usr/hdp/2.3.2.0-2826/hive
lrwxrwxrwx 1 root root 35 Dec 18 12:59 hive-webhcat -> 
/usr/hdp/2.3.2.0-2826/hive-hcatalog
{code}

The problem is that {{hcat_client.py}} must write out configs to 
{{/usr/hdp/current/hive-webhcat/etc/hcatalog}} but {{hcat_client.py}} doesn't 
{{hdp-select}} anything.

So that the "current" pointers are never changed. {{hcat_client.py}} should 
probably {{hdp-select hive-webhcat}} since there is no {{hcat-client}} in 
{{hdp-select}}.


Diffs
-

  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hcat_client.py
 75a37f1 
  ambari-server/src/test/python/stacks/2.0.6/HIVE/test_hcat_client.py 396e6a1 

Diff: https://reviews.apache.org/r/41562/diff/


Testing
---

mvn clean test

--
Total run:853
Total errors:0
Total failures:0
OK

Upgraded cluster with multiple hcat clients not located with other hive 
components.


Thanks,

Jonathan Hurley

Re: Review Request 41561: Spark ThriftServer Does Not Upgrade

[Sumit Mohanty]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41561/#review111241
---

Ship it!


Ship It!

- Sumit Mohanty


On Dec. 18, 2015, 7:32 p.m., Jonathan Hurley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41561/
> ---
> 
> (Updated Dec. 18, 2015, 7:32 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Nate Cole, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-14436
> https://issues.apache.org/jira/browse/AMBARI-14436
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> The blueprint is deploying SPARK_THRIFTSERVER
> {code}
> {
> "name": "SPARK_THRIFTSERVER"
> },
> {code}
> 
> The failure is due to:
> {code}
> The following components were found to have version mismatches.  Finalize 
> will not complete successfully:
> os-s11-3-dzcnju-ambari-eu-1-2.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-4.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-5.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> {code}
> 
> This is because the STS is not part of any upgrade packs. Since it first 
> appeared in HDP 2.3.2, the 2 upgrade packs for HDP 2.3 -> 2.3+ should be 
> updated to include STS.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
>  5e0d364 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml 
> e31e7fb 
> 
> Diff: https://reviews.apache.org/r/41561/diff/
> 
> 
> Testing
> ---
> 
> Upgraded a cluster with STS installed.
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

Re: Review Request 41561: Spark ThriftServer Does Not Upgrade

[Alejandro Fernandez]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41561/#review111239
---

Ship it!


Ship It!

- Alejandro Fernandez


On Dec. 18, 2015, 7:32 p.m., Jonathan Hurley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41561/
> ---
> 
> (Updated Dec. 18, 2015, 7:32 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Nate Cole, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-14436
> https://issues.apache.org/jira/browse/AMBARI-14436
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> The blueprint is deploying SPARK_THRIFTSERVER
> {code}
> {
> "name": "SPARK_THRIFTSERVER"
> },
> {code}
> 
> The failure is due to:
> {code}
> The following components were found to have version mismatches.  Finalize 
> will not complete successfully:
> os-s11-3-dzcnju-ambari-eu-1-2.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-4.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-5.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> {code}
> 
> This is because the STS is not part of any upgrade packs. Since it first 
> appeared in HDP 2.3.2, the 2 upgrade packs for HDP 2.3 -> 2.3+ should be 
> updated to include STS.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
>  5e0d364 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml 
> e31e7fb 
> 
> Diff: https://reviews.apache.org/r/41561/diff/
> 
> 
> Testing
> ---
> 
> Upgraded a cluster with STS installed.
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

Re: Review Request 41561: Spark ThriftServer Does Not Upgrade

[Nate Cole]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41561/#review111238
---

Ship it!


Ship It!

- Nate Cole


On Dec. 18, 2015, 2:32 p.m., Jonathan Hurley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41561/
> ---
> 
> (Updated Dec. 18, 2015, 2:32 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Nate Cole, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-14436
> https://issues.apache.org/jira/browse/AMBARI-14436
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> The blueprint is deploying SPARK_THRIFTSERVER
> {code}
> {
> "name": "SPARK_THRIFTSERVER"
> },
> {code}
> 
> The failure is due to:
> {code}
> The following components were found to have version mismatches.  Finalize 
> will not complete successfully:
> os-s11-3-dzcnju-ambari-eu-1-2.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-4.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-5.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> {code}
> 
> This is because the STS is not part of any upgrade packs. Since it first 
> appeared in HDP 2.3.2, the 2 upgrade packs for HDP 2.3 -> 2.3+ should be 
> updated to include STS.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
>  5e0d364 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml 
> e31e7fb 
> 
> Diff: https://reviews.apache.org/r/41561/diff/
> 
> 
> Testing
> ---
> 
> Upgraded a cluster with STS installed.
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

[jira] [Updated] (AMBARI-14437) Unable To Restart HCat Client When Not Colocated With WebHCat Server

[Jonathan Hurley (JIRA)]

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

Jonathan Hurley updated AMBARI-14437:
-
Attachment: AMBARI-14437.patch

> Unable To Restart HCat Client When Not Colocated With WebHCat Server
> 
>
> Key: AMBARI-14437
> URL: https://issues.apache.org/jira/browse/AMBARI-14437
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.2.0
>
> Attachments: AMBARI-14437.patch
>
>
> Errors are encountered while restart Hive HCat client when it is not located 
> on a host which also has WebHCat daemon.
> {code:title=This is good - the pointers have moved for 2.3.4}
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp/2.3.4.0-3485/hive-hcatalog/etc
> total 4
> lrwxrwxrwx 1 root root   33 Dec 18 14:45 hcatalog -> 
> /etc/hive-hcatalog/2.3.4.0-3485/0
> drwxr-xr-x 2 root root 4096 Dec 18 14:45 init.d
> lrwxrwxrwx 1 root root   32 Dec 18 14:45 webhcat -> 
> /etc/hive-webhcat/2.3.4.0-3485/0
> {code}
> {code:title=This is bad - current for hcatalog is still 2.3.2, which has the 
> symlink issue}
> root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# 
> ls -l /usr/hdp/current | grep hive
> lrwxrwxrwx 1 root root 26 Dec 18 15:50 hive-client -> 
> /usr/hdp/2.3.4.0-3485/hive
> lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-metastore -> 
> /usr/hdp/2.3.2.0-2826/hive
> lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-server2 -> 
> /usr/hdp/2.3.2.0-2826/hive
> lrwxrwxrwx 1 root root 35 Dec 18 12:59 hive-webhcat -> 
> /usr/hdp/2.3.2.0-2826/hive-hcatalog
> {code}
> The problem is that {{hcat_client.py}} must write out configs to 
> {{/usr/hdp/current/hive-webhcat/etc/hcatalog}} but {{hcat_client.py}} doesn't 
> {{hdp-select}} anything.
> So that the "current" pointers are never changed. {{hcat_client.py}} should 
> probably {{hdp-select hive-webhcat}} since there is no {{hcat-client}} in 
> {{hdp-select}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMBARI-14437) Unable To Restart HCat Client When Not Colocated With WebHCat Server

[Jonathan Hurley (JIRA)]

Jonathan Hurley created AMBARI-14437:


 Summary: Unable To Restart HCat Client When Not Colocated With 
WebHCat Server
 Key: AMBARI-14437
 URL: https://issues.apache.org/jira/browse/AMBARI-14437
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.2.0
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
Priority: Blocker
 Fix For: 2.2.0


Errors are encountered while restart Hive HCat client when it is not located on 
a host which also has WebHCat daemon.

{code:title=This is good - the pointers have moved for 2.3.4}
root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# ls 
-l /usr/hdp/2.3.4.0-3485/hive-hcatalog/etc
total 4
lrwxrwxrwx 1 root root   33 Dec 18 14:45 hcatalog -> 
/etc/hive-hcatalog/2.3.4.0-3485/0
drwxr-xr-x 2 root root 4096 Dec 18 14:45 init.d
lrwxrwxrwx 1 root root   32 Dec 18 14:45 webhcat -> 
/etc/hive-webhcat/2.3.4.0-3485/0
{code}

{code:title=This is bad - current for hcatalog is still 2.3.2, which has the 
symlink issue}
root@os-d7-dkezlu-ambari-hv-r-upg-7-re1-5:/usr/hdp/current/hive-webhcat/etc# ls 
-l /usr/hdp/current | grep hive
lrwxrwxrwx 1 root root 26 Dec 18 15:50 hive-client -> /usr/hdp/2.3.4.0-3485/hive
lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-metastore -> 
/usr/hdp/2.3.2.0-2826/hive
lrwxrwxrwx 1 root root 26 Dec 18 12:59 hive-server2 -> 
/usr/hdp/2.3.2.0-2826/hive
lrwxrwxrwx 1 root root 35 Dec 18 12:59 hive-webhcat -> 
/usr/hdp/2.3.2.0-2826/hive-hcatalog
{code}

The problem is that {{hcat_client.py}} must write out configs to 
{{/usr/hdp/current/hive-webhcat/etc/hcatalog}} but {{hcat_client.py}} doesn't 
{{hdp-select}} anything.

So that the "current" pointers are never changed. {{hcat_client.py}} should 
probably {{hdp-select hive-webhcat}} since there is no {{hcat-client}} in 
{{hdp-select}}.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14436) Spark ThriftServer Does Not Upgrade

[Jonathan Hurley (JIRA)]

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

Jonathan Hurley updated AMBARI-14436:
-
Attachment: AMBARI-14436.patch

> Spark ThriftServer Does Not Upgrade
> ---
>
> Key: AMBARI-14436
> URL: https://issues.apache.org/jira/browse/AMBARI-14436
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-14436.patch
>
>
> The blueprint is deploying SPARK_THRIFTSERVER
> {code}
> {
> "name": "SPARK_THRIFTSERVER"
> },
> {code}
> The failure is due to:
> {code}
> The following components were found to have version mismatches.  Finalize 
> will not complete successfully:
> os-s11-3-dzcnju-ambari-eu-1-2.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-4.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> os-s11-3-dzcnju-ambari-eu-1-5.novalocal: SPARK/SPARK_THRIFTSERVER reports 
> 2.3.2.0-2950
> {code}
> This is because the STS is not part of any upgrade packs. Since it first 
> appeared in HDP 2.3.2, the 2 upgrade packs for HDP 2.3 -> 2.3+ should be 
> updated to include STS.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 41561: Spark ThriftServer Does Not Upgrade

[Jonathan Hurley]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41561/
---

Review request for Ambari, Alejandro Fernandez, Nate Cole, and Sumit Mohanty.


Bugs: AMBARI-14436
https://issues.apache.org/jira/browse/AMBARI-14436


Repository: ambari


Description
---

The blueprint is deploying SPARK_THRIFTSERVER
{code}
{
"name": "SPARK_THRIFTSERVER"
},
{code}

The failure is due to:
{code}
The following components were found to have version mismatches.  Finalize will 
not complete successfully:
os-s11-3-dzcnju-ambari-eu-1-2.novalocal: SPARK/SPARK_THRIFTSERVER reports 
2.3.2.0-2950
os-s11-3-dzcnju-ambari-eu-1-4.novalocal: SPARK/SPARK_THRIFTSERVER reports 
2.3.2.0-2950
os-s11-3-dzcnju-ambari-eu-1-5.novalocal: SPARK/SPARK_THRIFTSERVER reports 
2.3.2.0-2950
{code}

This is because the STS is not part of any upgrade packs. Since it first 
appeared in HDP 2.3.2, the 2 upgrade packs for HDP 2.3 -> 2.3+ should be 
updated to include STS.


Diffs
-

  
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
 5e0d364 
  ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml 
e31e7fb 

Diff: https://reviews.apache.org/r/41561/diff/


Testing
---

Upgraded a cluster with STS installed.


Thanks,

Jonathan Hurley

[jira] [Created] (AMBARI-14436) Spark ThriftServer Does Not Upgrade

[Jonathan Hurley (JIRA)]

Jonathan Hurley created AMBARI-14436:


 Summary: Spark ThriftServer Does Not Upgrade
 Key: AMBARI-14436
 URL: https://issues.apache.org/jira/browse/AMBARI-14436
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.4.0
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
Priority: Blocker
 Fix For: 2.4.0


The blueprint is deploying SPARK_THRIFTSERVER
{code}
{
"name": "SPARK_THRIFTSERVER"
},
{code}

The failure is due to:
{code}
The following components were found to have version mismatches.  Finalize will 
not complete successfully:
os-s11-3-dzcnju-ambari-eu-1-2.novalocal: SPARK/SPARK_THRIFTSERVER reports 
2.3.2.0-2950
os-s11-3-dzcnju-ambari-eu-1-4.novalocal: SPARK/SPARK_THRIFTSERVER reports 
2.3.2.0-2950
os-s11-3-dzcnju-ambari-eu-1-5.novalocal: SPARK/SPARK_THRIFTSERVER reports 
2.3.2.0-2950
{code}

This is because the STS is not part of any upgrade packs. Since it first 
appeared in HDP 2.3.2, the 2 upgrade packs for HDP 2.3 -> 2.3+ should be 
updated to include STS.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 41551: Add Service wizard: Ambari web should select slaves as per the recommendation given by stack advisor

[jun aoki]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41551/#review111236
---



ambari-web/app/controllers/main/service/add_controller.js 


Lack of my knowledge but wanted ask, is this function overriding slave 
recommendation from stack_advisor?


- jun aoki


On Dec. 18, 2015, 1:02 p.m., Andrii Tkach wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41551/
> ---
> 
> (Updated Dec. 18, 2015, 1:02 p.m.)
> 
> 
> Review request for Ambari, Alexandr Antonenko and Jaimin Jetly.
> 
> 
> Bugs: AMBARI-14427
> https://issues.apache.org/jira/browse/AMBARI-14427
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Add Service wizard: Ambari web should select slaves as per the recommendation 
> given by stack advisor
> 
> 
> Diffs
> -
> 
>   ambari-web/app/controllers/main/service/add_controller.js 1f8133d 
>   ambari-web/app/controllers/wizard/step6_controller.js 04930f4 
> 
> Diff: https://reviews.apache.org/r/41551/diff/
> 
> 
> Testing
> ---
> 
> 11763 tests complete (15 seconds)
>   132 tests pending
> 
> 
> Thanks,
> 
> Andrii Tkach
> 
>

[jira] [Commented] (AMBARI-14409) Blueprints: Kerberos deployments fail intermittently due to invalid keytabs

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-14409:


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

This message is automatically generated.

> Blueprints: Kerberos deployments fail intermittently due to invalid keytabs
> ---
>
> Key: AMBARI-14409
> URL: https://issues.apache.org/jira/browse/AMBARI-14409
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
>Priority: Critical
> Fix For: 2.2.1
>
> Attachments: AMBARI-14409.patch
>
>
> The basic problem appears to be a concurrency problem, in which keytabs are 
> sometimes generated incorrectly.  This results in certain keytabs across the 
> cluster having different created/modified times in the keytabs, which can 
> cause Kerberos Preauthentication failures, such as the following:
> {code}
> resource_management.core.exceptions.Fail: Execution of '/usr/bin/kinit -kt 
> /etc/security/keytabs/smokeuser.headless.keytab 
> ambari-qa-cluster...@example.com;' returned 1. kinit: Password incorrect 
> while getting initial credentials
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_server.py",
>  line 179, in 
> ZookeeperServer().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 217, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_server.py",
>  line 55, in start
> zookeeper_service(action='start', upgrade_type=upgrade_type)
>   File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py", 
> line 89, in thunk
> return fn(*args, **kwargs)
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_service.py",
>  line 54, in zookeeper_service
> user=params.smokeuser
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
> line 154, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 158, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 121, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 238, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 70, in inner
> result = function(command, **kwargs)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 92, in checked_call
> tries=tries, try_sleep=try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 291, in _call
> raise Fail(err_msg)
> {code}
> The basic underlying problem appears to be invalid keytabs.  Looking to the 
> keytabs on the failing node:
> {code}
> [root@rwntest-2 keytabs]# klist -kt smokeuser.headless.keytab
> Keytab name: FILE:smokeuser.headless.keytab
> KVNO Timestamp Principal
>  - 
> 
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
> {code}
> whereas other nodes in the cluster report the following value for the same 
> keytab:
> {code}
> [root@rwntest-4 keytabs]# klist -kt smokeuser.headless.keytab
> Keytab name: FILE:smokeuser.headless.keytab
> KVNO Timestamp Principal
>  - 
> 
>4 12/04/15 20:25:32 ambari-qa-cluster...@example.com
>4 12/04/15 20:25:32 ambari-qa-cluster...@example.com
>4 12/04/15 20:25:32 ambari-qa-cluster...@example.com
>4 12/04/15 20:25:32 ambari-qa-cl

Review Request: Move HAWQ hdfs-client.xml parameter injection to Ambari web for Namenode HA

[Mithun Mathew]

Kindly review the following JIRA:
https://issues.apache.org/jira/browse/AMBARI-14392

Brief Description:
HAWQ requires additional parameters in hdfs-client.xml file to operate on
an HDFS HA cluster.
The additional parameters are introduced into configurations, through
Ambari web wizard code change.



-- 
*Mithun Mathew* (Matt)

   - www.linkedin.com/in/mithunmatt/

[jira] [Resolved] (AMBARI-14306) Fix Indices for HAWQ General Config Parameters

[Matt (JIRA)]

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

Matt resolved AMBARI-14306.
---
Resolution: Fixed

This issue was resolved as a result of the patch submitted for AMBARI-14315

> Fix Indices for HAWQ General Config Parameters
> --
>
> Key: AMBARI-14306
> URL: https://issues.apache.org/jira/browse/AMBARI-14306
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: trunk
>Reporter: Matt
>Assignee: Matt
>Priority: Trivial
> Fix For: 2.3.0, trunk
>
> Attachments: AMBARI-14306.patch
>
>
> The order in which HAWQ General Config parameters is displayed is not right. 
> The order has to be fixed so that HAWQ Master is displayed first.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14429) Ambari Web Unit Test failures on trunk (test/models/configs/service_config_version_test App.ServiceConfigVersion #createdDate)

[Yusaku Sako (JIRA)]

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

Yusaku Sako commented on AMBARI-14429:
--

+1 for the patch.

> Ambari Web Unit Test failures on trunk 
> (test/models/configs/service_config_version_test App.ServiceConfigVersion 
> #createdDate)
> --
>
> Key: AMBARI-14429
> URL: https://issues.apache.org/jira/browse/AMBARI-14429
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Richard Zang
>Assignee: Richard Zang
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-14429.patch
>
>
> [0m  1) Ambari Web Unit tests test/models/configs/service_config_version_test 
> App.ServiceConfigVersion #createdDate should return created date:
>   
>   [41mactual[0m [42mexpected[0m
>   
>   "Wed, Dec 16, 2015 [42m14[0m[41m12[0m:06"
>   [0m[90m
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/chai/chai.js:925
>   at assertEqual 
> (file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/chai/chai.js:1402)
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/chai/chai.js:3638
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/public/test/javascripts/test.js:52112
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:4039
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:4404
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:4463
>   at next 
> (file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:4330)
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:4339
>   at next 
> (file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:4287)
>   at 
> file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:4307
>   at timeslice 
> (file:///home/jenkins/jenkins-slave/workspace/Ambari-trunk-Commit/ambari-web/node_modules/mocha/mocha.js:5279)
> [0m
> npm ERR! Test failed.  See above for more details.
> npm ERR! not ok code 0
> [INFO]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (AMBARI-14425) UI hangs in "Cluster Administrator" role when "Settings" dropdown is clicked from User Account.

[Richard Zang (JIRA)]

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

Richard Zang resolved AMBARI-14425.
---
Resolution: Fixed

Fixed in AMBARI-14433

> UI hangs in "Cluster Administrator" role when "Settings" dropdown is clicked 
> from User Account.
> ---
>
> Key: AMBARI-14425
> URL: https://issues.apache.org/jira/browse/AMBARI-14425
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Richard Zang
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: Screen Shot 2015-12-16 at 11.13.22 PM.png
>
>
> UI hangs in "Cluster Administrator" role when "Settings" dropdown is clicked 
> from User Account.
> Screenshot Attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14424) Hive Metastore alert timeout

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-14424:


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

This message is automatically generated.

> Hive Metastore alert timeout
> 
>
> Key: AMBARI-14424
> URL: https://issues.apache.org/jira/browse/AMBARI-14424
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.2.1
>
> Attachments: AMBARI-14424.patch
>
>
> For Hive metastore and server alerts
> 1) Change default timeout to 60 seconds
> 2) Make this a configurable script param, so people can pass this in



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14371) No eventual config changes should not recommend extra config changes

[Hudson (JIRA)]

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

Hudson commented on AMBARI-14371:
-

FAILURE: Integrated in Ambari-trunk-Commit #4067 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4067/])
AMBARI-14371 No eventual config changes should not recommend extra 
(babiychukandrey: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=4c3d38c6f989b72a12b0c1461ba0ffca6d66ee76])
* ambari-web/app/models/configs/objects/service_config_property.js
* ambari-web/app/utils/configs/config_initializer.js
* ambari-web/app/mixins/common/serverValidator.js
* ambari-web/app/mixins/common/configs/enhanced_configs.js
* ambari-web/app/views/common/controls_view.js
* ambari-web/test/views/common/configs/widgets/list_config_widget_view_test.js
* ambari-web/app/models/configs/objects/service_config.js
* ambari-web/app/utils/configs/config_initializer_class.js


> No eventual config changes should not recommend extra config changes
> 
>
> Key: AMBARI-14371
> URL: https://issues.apache.org/jira/browse/AMBARI-14371
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.0
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
> Fix For: 2.4.0
>
> Attachments: AMBARI-14371.patch
>
>
> This ticket proposes that if user has not made any eventual config change 
> (for example "Enabled Ranger plugin for HBase" and then disabled it again) 
> then ambari should not show any extra config changes.
> For this we need to keep track of explicit config changes that are being made 
> by the user. If a config change at any time negates all the user config 
> changes done before then UI should send configs in the data posted in 
> recommendation API as received from stack (on installer/ASW wizard) or the 
> last service config version (post-install).
> Please find below examples:
> First example:
> On Installer/ASW, When user lands on "Customize Services" page, ui posts data 
> to recommendation API with all config values as received from stack endpoint
> After that, If user changes "Ranger plugin for HBase" to ON, ui send 
> recommendation API with all config values as received from stack endpoint + 
> overriden value of some config received from response of API executed in 
> step-1
> User Changes "Ranger plugin for HBase" to OFF, ui should post data to 
> recommendation API with all config values as received from stack endpoint (as 
> done in step1). The reason being the all users previously explicitly made 
> changes have been negated at this point
> Second Example:
> On Installer/ASW, When user lands on "Customize Services" page, ui posts data 
> to recommendation API with all config values as received from stack endpoint
> After that, If user changes "Ranger plugin for HBase" to ON and changes some 
> other property "xyz" to "v1", ui send recommendation API with all config 
> values as currently set in UI (received from stack endpoint + overriden value 
> of some config received from response of API executed in step-1)
> Changes "Ranger plugin for HBase" to OFF, ui should post data to 
> recommendation API with all config values as set currently on UI (same 
> behavior as ui displays today).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 41477: Fix stale cluster entity reference which results in merge issues

[Myroslav Papirkovskyy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41477/#review111223
---

Ship it!


Ship It!

- Myroslav Papirkovskyy


On Гру. 18, 2015, 8:25 після полудня, Sid Wagle wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41477/
> ---
> 
> (Updated Гру. 18, 2015, 8:25 після полудня)
> 
> 
> Review request for Ambari, Jonathan Hurley, Myroslav Papirkovskyy, and Nate 
> Cole.
> 
> 
> Bugs: AMBARI-14411
> https://issues.apache.org/jira/browse/AMBARI-14411
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> *Preliminary patch*
> 
> Symptom:
> 
> {code}
> Local Exception Stack: 
> Exception [EclipseLink-6004] (Eclipse Persistence Services - 
> 2.5.2.v20140319-9ad6abd): org.eclipse.persistence.exceptions.QueryException
> Exception Description: The object 
> [org.apache.ambari.server.orm.entities.ClusterConfigEntity@3646b3a8], of 
> class [class org.apache.ambari.server.orm.entities.ClusterConfigEntity], with 
> identity hashcode (System.identityHashCode()) [364,075,546], 
> is not from this UnitOfWork object space, but the parent session's.  The 
> object was never registered in this UnitOfWork, 
> but read from the parent session and related to an object registered in the 
> UnitOfWork.  Ensure that you are correctly
> registering your objects.  If you are still having problems, you can use the 
> UnitOfWork.validateObjectSpace() method to 
> help debug where the error occurred.  For more information, see the manual or 
> FAQ.
>   at 
> org.eclipse.persistence.exceptions.QueryException.backupCloneIsOriginalFromParent(QueryException.java:298)
>   at 
> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.getBackupClone(UnitOfWorkImpl.java:1995)
>   at 
> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3976)
>   at 
> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3894)
>   at 
> org.eclipse.persistence.mappings.CollectionMapping.buildElementUnitOfWorkClone(CollectionMapping.java:308)
>   at 
> org.eclipse.persistence.mappings.CollectionMapping.buildElementClone(CollectionMapping.java:321)
>   at 
> org.eclipse.persistence.internal.queries.ContainerPolicy.addNextValueFromIteratorInto(ContainerPolicy.java:217)
> {code}
> 
> Likely Cause:
> Stale clusterEntity reference points to a detached entity which gets tried to 
> be merged, the Cascaded relationship throws the error on persist.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
>  a0c6cfc 
> 
> Diff: https://reviews.apache.org/r/41477/diff/
> 
> 
> Testing
> ---
> 
> Unit testing in progress.
> 
> 
> Thanks,
> 
> Sid Wagle
> 
>

Re: Review Request 41477: Fix stale cluster entity reference which results in merge issues

[Sid Wagle]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41477/
---

(Updated Dec. 18, 2015, 6:25 p.m.)


Review request for Ambari, Jonathan Hurley, Myroslav Papirkovskyy, and Nate 
Cole.


Changes
---

- Made sure that the entity reference does not escape ClusterImpl and added 
documentation for the same
- Made sure all mutations that use this reference make sure that it is 
refreshed and thereby is attached to current session
- Added missing @Transactional on 
org.apache.ambari.server.state.cluster.ClusterImpl#setCurrentStackVersion
- Presently, the clusterEntity reference is used when the cluster is not yet 
persisted and this is a valid use case but removing it would be a much larger 
refactoring effort and should be done with a two digit version release eg: 
2.3.0, in my opinion. Thereby still going with the approach of refactoring all 
mutations on the in-memory object to refresh the reference with latest 
information and leaving the getter alone.


Bugs: AMBARI-14411
https://issues.apache.org/jira/browse/AMBARI-14411


Repository: ambari


Description
---

*Preliminary patch*

Symptom:

{code}
Local Exception Stack: 
Exception [EclipseLink-6004] (Eclipse Persistence Services - 
2.5.2.v20140319-9ad6abd): org.eclipse.persistence.exceptions.QueryException
Exception Description: The object 
[org.apache.ambari.server.orm.entities.ClusterConfigEntity@3646b3a8], of class 
[class org.apache.ambari.server.orm.entities.ClusterConfigEntity], with 
identity hashcode (System.identityHashCode()) [364,075,546], 
is not from this UnitOfWork object space, but the parent session's.  The object 
was never registered in this UnitOfWork, 
but read from the parent session and related to an object registered in the 
UnitOfWork.  Ensure that you are correctly
registering your objects.  If you are still having problems, you can use the 
UnitOfWork.validateObjectSpace() method to 
help debug where the error occurred.  For more information, see the manual or 
FAQ.
at 
org.eclipse.persistence.exceptions.QueryException.backupCloneIsOriginalFromParent(QueryException.java:298)
at 
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.getBackupClone(UnitOfWorkImpl.java:1995)
at 
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3976)
at 
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3894)
at 
org.eclipse.persistence.mappings.CollectionMapping.buildElementUnitOfWorkClone(CollectionMapping.java:308)
at 
org.eclipse.persistence.mappings.CollectionMapping.buildElementClone(CollectionMapping.java:321)
at 
org.eclipse.persistence.internal.queries.ContainerPolicy.addNextValueFromIteratorInto(ContainerPolicy.java:217)
{code}

Likely Cause:
Stale clusterEntity reference points to a detached entity which gets tried to 
be merged, the Cascaded relationship throws the error on persist.


Diffs (updated)
-

  
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
 a0c6cfc 

Diff: https://reviews.apache.org/r/41477/diff/


Testing
---

Unit testing in progress.


Thanks,

Sid Wagle

[jira] [Commented] (AMBARI-14409) Blueprints: Kerberos deployments fail intermittently due to invalid keytabs

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-14409:


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

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

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

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

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

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

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

This message is automatically generated.

> Blueprints: Kerberos deployments fail intermittently due to invalid keytabs
> ---
>
> Key: AMBARI-14409
> URL: https://issues.apache.org/jira/browse/AMBARI-14409
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
>Priority: Critical
> Fix For: 2.2.1
>
> Attachments: AMBARI-14409.patch
>
>
> The basic problem appears to be a concurrency problem, in which keytabs are 
> sometimes generated incorrectly.  This results in certain keytabs across the 
> cluster having different created/modified times in the keytabs, which can 
> cause Kerberos Preauthentication failures, such as the following:
> {code}
> resource_management.core.exceptions.Fail: Execution of '/usr/bin/kinit -kt 
> /etc/security/keytabs/smokeuser.headless.keytab 
> ambari-qa-cluster...@example.com;' returned 1. kinit: Password incorrect 
> while getting initial credentials
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_server.py",
>  line 179, in 
> ZookeeperServer().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 217, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_server.py",
>  line 55, in start
> zookeeper_service(action='start', upgrade_type=upgrade_type)
>   File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py", 
> line 89, in thunk
> return fn(*args, **kwargs)
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_service.py",
>  line 54, in zookeeper_service
> user=params.smokeuser
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
> line 154, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 158, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 121, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 238, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 70, in inner
> result = function(command, **kwargs)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 92, in checked_call
> tries=tries, try_sleep=try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 291, in _call
> raise Fail(err_msg)
> {code}
> The basic underlying problem appears to be invalid keytabs.  Looking to the 
> keytabs on the failing node:
> {code}
> [root@rwntest-2 keytabs]# klist -kt smokeuser.headless.keytab
> Keytab name: FILE:smokeuser.headless.keytab
> KVNO Timestamp Principal
>  - 
> 
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
> {code}
> wherea

Re: Review Request 41526: Hive Metastore alert timeout

[Alejandro Fernandez]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41526/#review111213
---

Ship it!



ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog221.java
 (lines 114 - 141)


It's my impression that this type of change for alerts is not uncommon. Can 
we have a general function to call?


- Alejandro Fernandez


On Dec. 18, 2015, 4:41 p.m., Vitalyi Brodetskyi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41526/
> ---
> 
> (Updated Dec. 18, 2015, 4:41 p.m.)
> 
> 
> Review request for Ambari, Andrew Onischuk, Dmytro Sen, Jonathan Hurley, and 
> Sumit Mohanty.
> 
> 
> Bugs: AMBARI-14424
> https://issues.apache.org/jira/browse/AMBARI-14424
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> For Hive metastore and server alerts
> 1) Change default timeout to 60 seconds
> 2) Make this a configurable script param, so people can pass this in
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/hive_check.py
>  55fd6bd 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/SchemaUpgradeHelper.java
>  5e22f71 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog221.java
>  PRE-CREATION 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/alerts.json 
> 55e3f78 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/alerts/alert_hive_metastore.py
>  c7a9102 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/alerts/alert_hive_thrift_port.py
>  a04c2a6 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog221Test.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/41526/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Vitalyi Brodetskyi
> 
>

Re: Review Request 41526: Hive Metastore alert timeout

[Vitalyi Brodetskyi]

> On Гру. 18, 2015, 5:27 після полудня, Jonathan Hurley wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog221.java,
> >  lines 114-141
> > 
> >
> > Looks like you're adding the same source to each entity - can you just 
> > put this in a loop and loop over the 2 entities?

Jonathan, i'm not sure i understand your note. I'm updaring sources for two 
different alerts, hive metastore and hive server process laerts. In the method 
you mentioned, i'm getting source from every alert definition, then adding(if 
needed) "timeout" parameter and then set it to entity.


- Vitalyi


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41526/#review111206
---


On Гру. 18, 2015, 4:41 після полудня, Vitalyi Brodetskyi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41526/
> ---
> 
> (Updated Гру. 18, 2015, 4:41 після полудня)
> 
> 
> Review request for Ambari, Andrew Onischuk, Dmytro Sen, Jonathan Hurley, and 
> Sumit Mohanty.
> 
> 
> Bugs: AMBARI-14424
> https://issues.apache.org/jira/browse/AMBARI-14424
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> For Hive metastore and server alerts
> 1) Change default timeout to 60 seconds
> 2) Make this a configurable script param, so people can pass this in
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/hive_check.py
>  55fd6bd 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/SchemaUpgradeHelper.java
>  5e22f71 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog221.java
>  PRE-CREATION 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/alerts.json 
> 55e3f78 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/alerts/alert_hive_metastore.py
>  c7a9102 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/alerts/alert_hive_thrift_port.py
>  a04c2a6 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog221Test.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/41526/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Vitalyi Brodetskyi
> 
>

Re: Review Request 41526: Hive Metastore alert timeout

[Jonathan Hurley]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41526/#review111206
---

Ship it!



ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog221.java
 (lines 114 - 141)


Looks like you're adding the same source to each entity - can you just put 
this in a loop and loop over the 2 entities?


- Jonathan Hurley


On Dec. 18, 2015, 11:41 a.m., Vitalyi Brodetskyi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41526/
> ---
> 
> (Updated Dec. 18, 2015, 11:41 a.m.)
> 
> 
> Review request for Ambari, Andrew Onischuk, Dmytro Sen, Jonathan Hurley, and 
> Sumit Mohanty.
> 
> 
> Bugs: AMBARI-14424
> https://issues.apache.org/jira/browse/AMBARI-14424
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> For Hive metastore and server alerts
> 1) Change default timeout to 60 seconds
> 2) Make this a configurable script param, so people can pass this in
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/hive_check.py
>  55fd6bd 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/SchemaUpgradeHelper.java
>  5e22f71 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog221.java
>  PRE-CREATION 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/alerts.json 
> 55e3f78 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/alerts/alert_hive_metastore.py
>  c7a9102 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/alerts/alert_hive_thrift_port.py
>  a04c2a6 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog221Test.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/41526/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Vitalyi Brodetskyi
> 
>

[jira] [Updated] (AMBARI-14434) Passwords for headless principals with cached keytab files are changed unnecessarily

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-14434:
--
Fix Version/s: 2.2.1

> Passwords for headless principals with cached keytab files are changed 
> unnecessarily
> 
>
> Key: AMBARI-14434
> URL: https://issues.apache.org/jira/browse/AMBARI-14434
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 2.4.0, 2.2.1
>
>
> Passwords for headless principals with cached keytab files are changed 
> unnecessarily.
> Solution check for the existence of a cached keytab file for headless 
> principals before updating their passwords.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMBARI-14435) Parameterize distro-specific stack information for ZOOKEEPER

[Juanjo Marron (JIRA)]

Juanjo Marron created AMBARI-14435:
--

 Summary: Parameterize distro-specific stack information for 
ZOOKEEPER
 Key: AMBARI-14435
 URL: https://issues.apache.org/jira/browse/AMBARI-14435
 Project: Ambari
  Issue Type: Technical task
  Components: ambari-server
Affects Versions: 2.2.0, 2.2.1
Reporter: Juanjo Marron
Assignee: Juanjo Marron
 Fix For: 2.4.0


Apply the prototype detailed on AMBARI-13364 to ZOOKEEPER service.

Tokens such as: current version, upgrade version, stack name, install path, 
..., will be parameterized and distro-agnostic at service definition level




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-13364) Parameterize stack information used by common services

[Juanjo Marron (JIRA)]

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

Juanjo Marron updated AMBARI-13364:
---
Issue Type: Story  (was: New Feature)

>  Parameterize stack information used by common services
> ---
>
> Key: AMBARI-13364
> URL: https://issues.apache.org/jira/browse/AMBARI-13364
> Project: Ambari
>  Issue Type: Story
>  Components: ambari-server
>Reporter: Tuong Truong
>Assignee: Juanjo Marron
> Attachments: AMBARI-13364 Parameterize stack information used by 
> common services.pdf, AMBARI-13364.patch
>
>
> This feature will add a basic framework to remove hardcoded stack information 
> out of the common services and use parameter to get access to stack 
> information.  Currently, the common services hardcoded much information 
> specific to Hortonworks' HDP stack including name (HDP), specific versions 
> (2.0, 2.1, 2.2), and install location.   This feature will propose a way of 
> configuration these information and parameterize them into the services for 
> reference as require. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14409) Blueprints: Kerberos deployments fail intermittently due to invalid keytabs

[Sandor Magyari (JIRA)]

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

Sandor Magyari updated AMBARI-14409:

Attachment: (was: AMBARI-14409.patch)

> Blueprints: Kerberos deployments fail intermittently due to invalid keytabs
> ---
>
> Key: AMBARI-14409
> URL: https://issues.apache.org/jira/browse/AMBARI-14409
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
>Priority: Critical
> Fix For: 2.2.1
>
> Attachments: AMBARI-14409.patch
>
>
> The basic problem appears to be a concurrency problem, in which keytabs are 
> sometimes generated incorrectly.  This results in certain keytabs across the 
> cluster having different created/modified times in the keytabs, which can 
> cause Kerberos Preauthentication failures, such as the following:
> {code}
> resource_management.core.exceptions.Fail: Execution of '/usr/bin/kinit -kt 
> /etc/security/keytabs/smokeuser.headless.keytab 
> ambari-qa-cluster...@example.com;' returned 1. kinit: Password incorrect 
> while getting initial credentials
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_server.py",
>  line 179, in 
> ZookeeperServer().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 217, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_server.py",
>  line 55, in start
> zookeeper_service(action='start', upgrade_type=upgrade_type)
>   File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py", 
> line 89, in thunk
> return fn(*args, **kwargs)
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_service.py",
>  line 54, in zookeeper_service
> user=params.smokeuser
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
> line 154, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 158, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 121, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 238, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 70, in inner
> result = function(command, **kwargs)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 92, in checked_call
> tries=tries, try_sleep=try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 291, in _call
> raise Fail(err_msg)
> {code}
> The basic underlying problem appears to be invalid keytabs.  Looking to the 
> keytabs on the failing node:
> {code}
> [root@rwntest-2 keytabs]# klist -kt smokeuser.headless.keytab
> Keytab name: FILE:smokeuser.headless.keytab
> KVNO Timestamp Principal
>  - 
> 
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
> {code}
> whereas other nodes in the cluster report the following value for the same 
> keytab:
> {code}
> [root@rwntest-4 keytabs]# klist -kt smokeuser.headless.keytab
> Keytab name: FILE:smokeuser.headless.keytab
> KVNO Timestamp Principal
>  - 
> 
>4 12/04/15 20:25:32 ambari-qa-cluster...@example.com
>4 12/04/15 20:25:32 ambari-qa-cluster...@example.com
>4 12/04/15 20:25:32 ambari-qa-cluster...@example.com
>4 12/04/15 20:25:32 ambari-qa-cluster...@example.com
>4 12/04/15 20:25:32 ambari-qa-cluster...@example.com
> {code}
> It looks like these keytabs should have the same timestamps, and this is 
> causing the Kerberos failures at cluster start up. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14409) Blueprints: Kerberos deployments fail intermittently due to invalid keytabs

[Sandor Magyari (JIRA)]

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

Sandor Magyari updated AMBARI-14409:

Attachment: AMBARI-14409.patch

> Blueprints: Kerberos deployments fail intermittently due to invalid keytabs
> ---
>
> Key: AMBARI-14409
> URL: https://issues.apache.org/jira/browse/AMBARI-14409
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
>Priority: Critical
> Fix For: 2.2.1
>
> Attachments: AMBARI-14409.patch
>
>
> The basic problem appears to be a concurrency problem, in which keytabs are 
> sometimes generated incorrectly.  This results in certain keytabs across the 
> cluster having different created/modified times in the keytabs, which can 
> cause Kerberos Preauthentication failures, such as the following:
> {code}
> resource_management.core.exceptions.Fail: Execution of '/usr/bin/kinit -kt 
> /etc/security/keytabs/smokeuser.headless.keytab 
> ambari-qa-cluster...@example.com;' returned 1. kinit: Password incorrect 
> while getting initial credentials
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_server.py",
>  line 179, in 
> ZookeeperServer().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 217, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_server.py",
>  line 55, in start
> zookeeper_service(action='start', upgrade_type=upgrade_type)
>   File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py", 
> line 89, in thunk
> return fn(*args, **kwargs)
>   File 
> "/var/lib/ambari-agent/cache/common-services/ZOOKEEPER/3.4.5.2.0/package/scripts/zookeeper_service.py",
>  line 54, in zookeeper_service
> user=params.smokeuser
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
> line 154, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 158, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 121, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 238, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 70, in inner
> result = function(command, **kwargs)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 92, in checked_call
> tries=tries, try_sleep=try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 291, in _call
> raise Fail(err_msg)
> {code}
> The basic underlying problem appears to be invalid keytabs.  Looking to the 
> keytabs on the failing node:
> {code}
> [root@rwntest-2 keytabs]# klist -kt smokeuser.headless.keytab
> Keytab name: FILE:smokeuser.headless.keytab
> KVNO Timestamp Principal
>  - 
> 
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
>1 12/04/15 20:25:04 ambari-qa-cluster...@example.com
> {code}
> whereas other nodes in the cluster report the following value for the same 
> keytab:
> {code}
> [root@rwntest-4 keytabs]# klist -kt smokeuser.headless.keytab
> Keytab name: FILE:smokeuser.headless.keytab
> KVNO Timestamp Principal
>  - 
> 
>4 12/04/15 20:25:32 ambari-qa-cluster...@example.com
>4 12/04/15 20:25:32 ambari-qa-cluster...@example.com
>4 12/04/15 20:25:32 ambari-qa-cluster...@example.com
>4 12/04/15 20:25:32 ambari-qa-cluster...@example.com
>4 12/04/15 20:25:32 ambari-qa-cluster...@example.com
> {code}
> It looks like these keytabs should have the same timestamps, and this is 
> causing the Kerberos failures at cluster start up. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14434) Passwords for headless principals with cached keytab files are changed unnecessarily

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-14434:
--
Fix Version/s: (was: 2.2.1)
   2.4.0

> Passwords for headless principals with cached keytab files are changed 
> unnecessarily
> 
>
> Key: AMBARI-14434
> URL: https://issues.apache.org/jira/browse/AMBARI-14434
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 2.4.0
>
>
> Passwords for headless principals with cached keytab files are changed 
> unnecessarily.
> Solution check for the existence of a cached keytab file for headless 
> principals before updating their passwords.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14425) UI hangs in "Cluster Administrator" role when "Settings" dropdown is clicked from User Account.

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-14425:
--
Assignee: Richard Zang  (was: Robert Levas)

> UI hangs in "Cluster Administrator" role when "Settings" dropdown is clicked 
> from User Account.
> ---
>
> Key: AMBARI-14425
> URL: https://issues.apache.org/jira/browse/AMBARI-14425
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Richard Zang
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: Screen Shot 2015-12-16 at 11.13.22 PM.png
>
>
> UI hangs in "Cluster Administrator" role when "Settings" dropdown is clicked 
> from User Account.
> Screenshot Attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)