date:20160510


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




ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
 (lines 2214 - 2215)


RESTART commands worked fine - but a STOP/START had a very, very naughty 
problem. On a START, we'd send down the "current" cluster repo version ID, 
which during an upgrade, is wrong.

Say you were upgrading from 2.2 to 2.3 and suspended it and tried to start 
ZK. We'd send down the repo ID for HDP 2.2 so that when ZK started up on 2.3 
(and reported 2.3.0.0-1234), we'd update the HDP 2.2 repo version with that 
version!!!

I switched this to use the "effective" version which takes into accounts 
upgrades and suspended upgrades.



ambari-server/src/main/java/org/apache/ambari/server/events/listeners/upgrade/StackVersionListener.java
 (lines 97 - 100)


Yet another safeguard to the repo version ID update problem - there's 
absolutely ZERO reason to update it if in an upgrade - it better be correct 
already.



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


I don't know what this was for, but it was wrong. Very wrong. We have JPA 
to handle this association for us now.



ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
 (lines 1209 - 1211)


This is the big change here - in Ambari 2.2.2 we used getUpgradeInProgress 
which searched the database and actually returned suspended upgrades (yay!)

But in 2.4.0, we only looked for the UpgradeEntity which was wrong as it 
would be null if suspended.


- Jonathan Hurley


On May 10, 2016, 7:36 p.m., Jonathan Hurley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47202/
> ---
> 
> (Updated May 10, 2016, 7:36 p.m.)
> 
> 
> Review request for Ambari, Dmitro Lisnichenko and Nate Cole.
> 
> 
> Bugs: AMBARI-16439
> https://issues.apache.org/jira/browse/AMBARI-16439
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> There is a regression on the 2.4.0 line when restarting components during a 
> paused upgrade. 
> 
> STR:
> - Upgrade from HDP 2.3 to HDP 2.4, but don't finalize
> - Suspend the upgrade on the finalization step
> - Restart a ZooKeeper Server
> 
> The commands being sent down have 2.3.x instead of 2.4.0:
> ```
> "commandParams": {
> "service_package_folder": "common-services/ZOOKEEPER/3.4.5/package",
> "script": "scripts/zookeeper_server.py",
> "hooks_folder": "HDP/2.0.6/hooks",
> "version": "2.3.4.0-3485",
> "command_timeout": "1200",
> "script_type": "PYTHON"
> },
> 
> "hostLevelParams": {
> "current_version": "2.3.4.0-3485",
> "custom_command": "RESTART",
> "stack_version": "2.4",
> ```
> 
> The problem is located in {{ClusterImpl}} in how it calculates the upgrade. 
> In Ambari 2.2.2, it searched for upgrades, which also returned suspended 
> upgrades. In 2.4.0, it only looks at a currently running upgrade:
> 
> - 2.4.0
> `UpgradeEntity upgradeInProgress = getUpgradeEntity();`
> 
> 
> - 2.2.2
> `UpgradeEntity upgradeInProgress = this.getUpgradeInProgress();`
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/agent/ExecutionCommand.java
>  34a0918 
>   
> ambari-server/src/main/java/org/apache/ambari/server/agent/HeartbeatProcessor.java
>  c587e9f 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
>  6dbceba 
>   
> ambari-server/src/main/java/org/apache/ambari/server/events/listeners/upgrade/StackVersionListener.java
>  b14e9e5 
>   ambari-server/src/main/java/org/apache/ambari/server/state/Cluster.java 
> cf2c9aa 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
>  f38c25a 
> 
> Diff: https://reviews.apache.org/r/47202/diff/
> 
> 
> Testing
> ---
> 
> Manual upgrade/downgrad/suspend test on a running cluster
> 
> Tests pending ...
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

Re: Review Request 46808: Role selection in List view of Manage Ambari page does not work correctly

2016-05-10 Thread Richard Zang


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




ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/clusters/UserAccessListCtrl.js
 (line 165)


if user change permission to None, currentIndex will be -1. I would 
recommend creating a function like getRoleRank which will give out a rank for 
all roles including None and View User.


- Richard Zang


On May 10, 2016, 7:49 p.m., Keta Patel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46808/
> ---
> 
> (Updated May 10, 2016, 7:49 p.m.)
> 
> 
> Review request for Ambari, Di Li and Richard Zang.
> 
> 
> Bugs: AMBARI-15552
> https://issues.apache.org/jira/browse/AMBARI-15552
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Reproduction Steps:
> 1. Go to Admin->Manage Ambari
> 2. Create a group with a few users belonging to it. 
> (I have created "mygroup" with "user1", "user2", "user3") 
> (attachments "user1.tiff", "mygroup.tiff" shows samples)
> 3. Go to Clusters->Roles on the left navigation menu.
> 4. The default view is the "Block" view for the roles. Assign "mygroup" a 
> role, say "Cluster User". 
> (attachment "block_view_original.tiff")
> 5. Click on "List" view, it will show Users by default. It correctly shows 
> the role "Cluster User" for each user in "mygroup". 
> (attachment "list_view_users.tiff")
> 6. Now, try adding a new Role, say "Service Operator", to one of the users, 
> say "user3". 
> (attachments "list_view_add_role_to_user_step1.tiff", 
> "list_view_add_role_to_user_step2.tiff")
> 7. After making this change, the role gets added for that user (in our case 
> "user3"), but the roles from other users in its group gets removed. Also, the 
> previous role for the user ("user3") is replaced by the new Role.
> (attachment "list_view_add_role_to_user_step3.tiff")
> 8. You can confirm this from the the "Block" view. 
> (attachment "block_view_after_step3.tiff")
> 
> So, the problem here lies with the List view where it is not able to process 
> the changes in the Roles correctly. A change in the Role of a user causes the 
> following:
> 
> CASE-1: The displayed role (effective privilege) comes from an explicitly 
> assigned role to the user.
> 1.1) The new selected role correctly replaces the existing privilege that was 
> explicitly assigned to the user.
> 1.2) But if the user was assigned multiple roles explicilty (before the fix 
> for AMBARI-16102 got pushed in), then all the other roles, which are of lower 
> privilege than the role that got replaced, are still displayed in the Block 
> view (because those roles are still in the database). So, if the new selected 
> role happened to be of a lower privilege than and existing role of the user, 
> then even though the user sees a success Alert message, the effective 
> privileg he sees is different. For the Ambari user, this behavior is not 
> easily understandable.
> 
> CASE-2: The displayed role (effective privilege) comes from a group the user 
> belongs to.
> 2.1) If the new selected privilege is higher than the effective privilege 
> coming from the user's group(s), then the newly selected role replaces this 
> "group" privilege in the database, insetad of creating a new entry.
> 2.2) As a result of losing the group privilege, all the group members also 
> lose their privileges and they show "None" as their effective privilege.
> 2.3) If the newly selected privilege is lower than effective group privilege, 
> the Alert message shows a success of role change but the effective privilge 
> is still not the one that the Ambari user selected.
> 
> 
> Expected results:
> 1. Updating a Role of a user must replace any/all of the explicit roles it 
> has been assigned through the Block View. (this addresses 1.2)
> Note: Even though AMBARI-16102 has attempted to fix the Block view by 
> allowing only a user to have just one role assigned to it, there could be 
> cases where the earlier version of Block view has already allowed users to 
> have multiple roles. So, taking this into consideration, the fix must address 
> removing any or all of the roles the user was assigned explicitly.
> 2. Adding a Role to a user must not affect the Roles of other users in its 
> group. (addressing 2.1 and 2.2)
> 3. Selecting a "NONE" for a user role shows the Alert "User's role chnaged to 
> None". This  may not reflect the correct privilege status as the user might 
> have some effective privilege coming from its group(s). In the fix, the Alert 
> must show the relevant message.
> 4. Alert messages must show more informative messages of what

Re: Review Request 47156: More information for Standby sync alert


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


Ship it!




Ship It!

- Lav Jain


On May 10, 2016, 10:22 p.m., jun aoki wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47156/
> ---
> 
> (Updated May 10, 2016, 10:22 p.m.)
> 
> 
> Review request for Ambari.
> 
> 
> Bugs: AMBARI-16417
> https://issues.apache.org/jira/browse/AMBARI-16417
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When Standby master is down (actually I removed it through API, and it got 
> deleted but somehow the configuration has the old IP) the hawq alert pops 
> up(, which is good) but only saying "HAWQSTANDBY is not in sync with 
> HAWQMASTER".
> 
> If you take a close look at gp_master_mirroring table, it has more detailed 
> information. (in this case, connection issue)
> {code}
> [gpadmin@ip-10-32-38-104 ~]$ psql -d template1 -c "select * from 
> gp_master_mirroring;"
>   summary_state   |   detail_state   |log_time|   
>error_message
> --+--++--
>  Not Synchronized | Connection error | 2016-04-12 21:14:23+00 | error 
> received sending data to standby master: server closed the connection 
> unexpectedly
>   : This 
> probably means the server terminated abnormally
>   : 
> before or while processing the request.
>   :
> (1 row)
> {code}
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/package/alerts/alert_sync_status.py
>  c94be9e 
>   ambari-server/src/test/python/stacks/2.3/HAWQ/test_alert_sync_status.py 
> 7d030dc 
> 
> Diff: https://reviews.apache.org/r/47156/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> jun aoki
> 
>

Re: Review Request 46808: Role selection in List view of Manage Ambari page does not work correctly

2016-05-10 Thread Richard Zang


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




ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/clusters/UserAccessListCtrl.js
 (line 162)


effectivePrivilegeFromGroups has been calculated on line 152 already.



ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/clusters/UserAccessListCtrl.js
 (line 181)


loadUser() needs to be called strictly after delete/add operation to have 
the up-to-date roles loaded. It's better to put it in the then block. This can 
be tested in the case I mentioned earlier: mygroup has "cluster user" role and 
aaa bbb ccc are in mygroup. Change aaa to "cluster administrator", confirm, 
then change aaa back to None, aaa stays at "cluster administrator" because 
loadUser() happens before delete finishes.


- Richard Zang


On May 10, 2016, 7:49 p.m., Keta Patel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46808/
> ---
> 
> (Updated May 10, 2016, 7:49 p.m.)
> 
> 
> Review request for Ambari, Di Li and Richard Zang.
> 
> 
> Bugs: AMBARI-15552
> https://issues.apache.org/jira/browse/AMBARI-15552
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Reproduction Steps:
> 1. Go to Admin->Manage Ambari
> 2. Create a group with a few users belonging to it. 
> (I have created "mygroup" with "user1", "user2", "user3") 
> (attachments "user1.tiff", "mygroup.tiff" shows samples)
> 3. Go to Clusters->Roles on the left navigation menu.
> 4. The default view is the "Block" view for the roles. Assign "mygroup" a 
> role, say "Cluster User". 
> (attachment "block_view_original.tiff")
> 5. Click on "List" view, it will show Users by default. It correctly shows 
> the role "Cluster User" for each user in "mygroup". 
> (attachment "list_view_users.tiff")
> 6. Now, try adding a new Role, say "Service Operator", to one of the users, 
> say "user3". 
> (attachments "list_view_add_role_to_user_step1.tiff", 
> "list_view_add_role_to_user_step2.tiff")
> 7. After making this change, the role gets added for that user (in our case 
> "user3"), but the roles from other users in its group gets removed. Also, the 
> previous role for the user ("user3") is replaced by the new Role.
> (attachment "list_view_add_role_to_user_step3.tiff")
> 8. You can confirm this from the the "Block" view. 
> (attachment "block_view_after_step3.tiff")
> 
> So, the problem here lies with the List view where it is not able to process 
> the changes in the Roles correctly. A change in the Role of a user causes the 
> following:
> 
> CASE-1: The displayed role (effective privilege) comes from an explicitly 
> assigned role to the user.
> 1.1) The new selected role correctly replaces the existing privilege that was 
> explicitly assigned to the user.
> 1.2) But if the user was assigned multiple roles explicilty (before the fix 
> for AMBARI-16102 got pushed in), then all the other roles, which are of lower 
> privilege than the role that got replaced, are still displayed in the Block 
> view (because those roles are still in the database). So, if the new selected 
> role happened to be of a lower privilege than and existing role of the user, 
> then even though the user sees a success Alert message, the effective 
> privileg he sees is different. For the Ambari user, this behavior is not 
> easily understandable.
> 
> CASE-2: The displayed role (effective privilege) comes from a group the user 
> belongs to.
> 2.1) If the new selected privilege is higher than the effective privilege 
> coming from the user's group(s), then the newly selected role replaces this 
> "group" privilege in the database, insetad of creating a new entry.
> 2.2) As a result of losing the group privilege, all the group members also 
> lose their privileges and they show "None" as their effective privilege.
> 2.3) If the newly selected privilege is lower than effective group privilege, 
> the Alert message shows a success of role change but the effective privilge 
> is still not the one that the Ambari user selected.
> 
> 
> Expected results:
> 1. Updating a Role of a user must replace any/all of the explicit roles it 
> has been assigned through the Block View. (this addresses 1.2)
> Note: Even though AMBARI-16102 has attempted to fix the Block view by 
> allowing only a user to have just one role assigned to it, there could be 
> cases where the earlier version of Block view has already allowed users to 
> have multiple roles. So, taking this into consideration, the fix must address 
> removing any or all of the roles

Re: Review Request 47156: More information for Standby sync alert


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

(Updated May 10, 2016, 10:22 p.m.)


Review request for Ambari.


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


Repository: ambari


Description
---

When Standby master is down (actually I removed it through API, and it got 
deleted but somehow the configuration has the old IP) the hawq alert pops up(, 
which is good) but only saying "HAWQSTANDBY is not in sync with HAWQMASTER".

If you take a close look at gp_master_mirroring table, it has more detailed 
information. (in this case, connection issue)
{code}
[gpadmin@ip-10-32-38-104 ~]$ psql -d template1 -c "select * from 
gp_master_mirroring;"
  summary_state   |   detail_state   |log_time| 
 error_message
--+--++--
 Not Synchronized | Connection error | 2016-04-12 21:14:23+00 | error received 
sending data to standby master: server closed the connection unexpectedly
  : This 
probably means the server terminated abnormally
  : before 
or while processing the request.
  :
(1 row)
{code}


Diffs (updated)
-

  
ambari-server/src/main/resources/common-services/HAWQ/2.0.0/package/alerts/alert_sync_status.py
 c94be9e 
  ambari-server/src/test/python/stacks/2.3/HAWQ/test_alert_sync_status.py 
7d030dc 

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


Testing
---


Thanks,

jun aoki

Re: Review Request 47156: More information for Standby sync alert



> On May 10, 2016, 9:53 p.m., Lav Jain wrote:
> > ambari-server/src/main/resources/common-services/HAWQ/2.0.0/package/alerts/alert_sync_status.py,
> >  line 93
> > 
> >
> > Please try to use one SQL statement. Delimiter can be defined using -F 
> > option. E.g.:
> > ```
> > source /usr/local/hawq/greenplum_path.sh && psql -F $'##' --no-align -t 
> > -d template1 -c "SELECT summary_state, error_message FROM 
> > gp_master_mirroring"
> > Not Synchronized##error received sending data to standby master: server 
> > closed the connection unexpectedly
> > This probably means the server terminated abnormally
> > before or while processing the request.
> > ```

Lav, this is a good stuff. I actually have to use --no-align option to not to 
be aligned.


- jun


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


On May 10, 2016, 9:54 p.m., jun aoki wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47156/
> ---
> 
> (Updated May 10, 2016, 9:54 p.m.)
> 
> 
> Review request for Ambari.
> 
> 
> Bugs: AMBARI-16417
> https://issues.apache.org/jira/browse/AMBARI-16417
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When Standby master is down (actually I removed it through API, and it got 
> deleted but somehow the configuration has the old IP) the hawq alert pops 
> up(, which is good) but only saying "HAWQSTANDBY is not in sync with 
> HAWQMASTER".
> 
> If you take a close look at gp_master_mirroring table, it has more detailed 
> information. (in this case, connection issue)
> {code}
> [gpadmin@ip-10-32-38-104 ~]$ psql -d template1 -c "select * from 
> gp_master_mirroring;"
>   summary_state   |   detail_state   |log_time|   
>error_message
> --+--++--
>  Not Synchronized | Connection error | 2016-04-12 21:14:23+00 | error 
> received sending data to standby master: server closed the connection 
> unexpectedly
>   : This 
> probably means the server terminated abnormally
>   : 
> before or while processing the request.
>   :
> (1 row)
> {code}
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/package/alerts/alert_sync_status.py
>  c94be9e 
>   ambari-server/src/test/python/stacks/2.3/HAWQ/test_alert_sync_status.py 
> 7d030dc 
> 
> Diff: https://reviews.apache.org/r/47156/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> jun aoki
> 
>

Re: Review Request 47156: More information for Standby sync alert



> On May 10, 2016, 7:10 a.m., Matt wrote:
> >
> 
> Matt wrote:
> Please double check if any unit tests have to be updated.

will do


- jun


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


On May 10, 2016, 9:54 p.m., jun aoki wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47156/
> ---
> 
> (Updated May 10, 2016, 9:54 p.m.)
> 
> 
> Review request for Ambari.
> 
> 
> Bugs: AMBARI-16417
> https://issues.apache.org/jira/browse/AMBARI-16417
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When Standby master is down (actually I removed it through API, and it got 
> deleted but somehow the configuration has the old IP) the hawq alert pops 
> up(, which is good) but only saying "HAWQSTANDBY is not in sync with 
> HAWQMASTER".
> 
> If you take a close look at gp_master_mirroring table, it has more detailed 
> information. (in this case, connection issue)
> {code}
> [gpadmin@ip-10-32-38-104 ~]$ psql -d template1 -c "select * from 
> gp_master_mirroring;"
>   summary_state   |   detail_state   |log_time|   
>error_message
> --+--++--
>  Not Synchronized | Connection error | 2016-04-12 21:14:23+00 | error 
> received sending data to standby master: server closed the connection 
> unexpectedly
>   : This 
> probably means the server terminated abnormally
>   : 
> before or while processing the request.
>   :
> (1 row)
> {code}
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/package/alerts/alert_sync_status.py
>  c94be9e 
>   ambari-server/src/test/python/stacks/2.3/HAWQ/test_alert_sync_status.py 
> 7d030dc 
> 
> Diff: https://reviews.apache.org/r/47156/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> jun aoki
> 
>

Re: Review Request 47156: More information for Standby sync alert


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

(Updated May 10, 2016, 9:54 p.m.)


Review request for Ambari.


Changes
---

Feedback applied


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


Repository: ambari


Description
---

When Standby master is down (actually I removed it through API, and it got 
deleted but somehow the configuration has the old IP) the hawq alert pops up(, 
which is good) but only saying "HAWQSTANDBY is not in sync with HAWQMASTER".

If you take a close look at gp_master_mirroring table, it has more detailed 
information. (in this case, connection issue)
{code}
[gpadmin@ip-10-32-38-104 ~]$ psql -d template1 -c "select * from 
gp_master_mirroring;"
  summary_state   |   detail_state   |log_time| 
 error_message
--+--++--
 Not Synchronized | Connection error | 2016-04-12 21:14:23+00 | error received 
sending data to standby master: server closed the connection unexpectedly
  : This 
probably means the server terminated abnormally
  : before 
or while processing the request.
  :
(1 row)
{code}


Diffs (updated)
-

  
ambari-server/src/main/resources/common-services/HAWQ/2.0.0/package/alerts/alert_sync_status.py
 c94be9e 
  ambari-server/src/test/python/stacks/2.3/HAWQ/test_alert_sync_status.py 
7d030dc 

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


Testing
---


Thanks,

jun aoki

Re: Review Request 47156: More information for Standby sync alert


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




ambari-server/src/main/resources/common-services/HAWQ/2.0.0/package/alerts/alert_sync_status.py
 (line 93)


Please try to use one SQL statement. Delimiter can be defined using -F 
option. E.g.:
```
source /usr/local/hawq/greenplum_path.sh && psql -F $'##' --no-align -t -d 
template1 -c "SELECT summary_state, error_message FROM gp_master_mirroring"
Not Synchronized##error received sending data to standby master: server 
closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
```


- Lav Jain


On May 10, 2016, 4:27 a.m., jun aoki wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47156/
> ---
> 
> (Updated May 10, 2016, 4:27 a.m.)
> 
> 
> Review request for Ambari.
> 
> 
> Bugs: AMBARI-16417
> https://issues.apache.org/jira/browse/AMBARI-16417
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When Standby master is down (actually I removed it through API, and it got 
> deleted but somehow the configuration has the old IP) the hawq alert pops 
> up(, which is good) but only saying "HAWQSTANDBY is not in sync with 
> HAWQMASTER".
> 
> If you take a close look at gp_master_mirroring table, it has more detailed 
> information. (in this case, connection issue)
> {code}
> [gpadmin@ip-10-32-38-104 ~]$ psql -d template1 -c "select * from 
> gp_master_mirroring;"
>   summary_state   |   detail_state   |log_time|   
>error_message
> --+--++--
>  Not Synchronized | Connection error | 2016-04-12 21:14:23+00 | error 
> received sending data to standby master: server closed the connection 
> unexpectedly
>   : This 
> probably means the server terminated abnormally
>   : 
> before or while processing the request.
>   :
> (1 row)
> {code}
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/package/alerts/alert_sync_status.py
>  c94be9e 
> 
> Diff: https://reviews.apache.org/r/47156/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> jun aoki
> 
>

Re: Review Request 47156: More information for Standby sync alert



> On May 10, 2016, 7:10 a.m., Matt wrote:
> > ambari-server/src/main/resources/common-services/HAWQ/2.0.0/package/alerts/alert_sync_status.py,
> >  line 68
> > 
> >
> > Would be better to have **'HAWQSTANDBY is not in sync with HAWQMASTER. 
> > ERROR: ' + error_message**

will fix


- jun


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


On May 10, 2016, 4:27 a.m., jun aoki wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47156/
> ---
> 
> (Updated May 10, 2016, 4:27 a.m.)
> 
> 
> Review request for Ambari.
> 
> 
> Bugs: AMBARI-16417
> https://issues.apache.org/jira/browse/AMBARI-16417
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When Standby master is down (actually I removed it through API, and it got 
> deleted but somehow the configuration has the old IP) the hawq alert pops 
> up(, which is good) but only saying "HAWQSTANDBY is not in sync with 
> HAWQMASTER".
> 
> If you take a close look at gp_master_mirroring table, it has more detailed 
> information. (in this case, connection issue)
> {code}
> [gpadmin@ip-10-32-38-104 ~]$ psql -d template1 -c "select * from 
> gp_master_mirroring;"
>   summary_state   |   detail_state   |log_time|   
>error_message
> --+--++--
>  Not Synchronized | Connection error | 2016-04-12 21:14:23+00 | error 
> received sending data to standby master: server closed the connection 
> unexpectedly
>   : This 
> probably means the server terminated abnormally
>   : 
> before or while processing the request.
>   :
> (1 row)
> {code}
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/package/alerts/alert_sync_status.py
>  c94be9e 
> 
> Diff: https://reviews.apache.org/r/47156/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> jun aoki
> 
>

Re: Review Request 47184: AMBARI-16435 : Change Namenode Total File operations widget to request rate metric instead of actual metric.

2016-05-10 Thread Jaimin Jetly


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


Ship it!




Ship It!

- Jaimin Jetly


On May 10, 2016, 7:45 p.m., Aravindan Vijayan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47184/
> ---
> 
> (Updated May 10, 2016, 7:45 p.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Jaimin Jetly, Sumit Mohanty, and Sid 
> Wagle.
> 
> 
> Bugs: AMBARI-16435
> https://issues.apache.org/jira/browse/AMBARI-16435
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Change since Total File operations is a counter metric and is useful as a 
> rate.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java
>  8c49ab4 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/HDFS/widgets.json 
> 98c1f86 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog240Test.java
>  11f3865 
> 
> Diff: https://reviews.apache.org/r/47184/diff/
> 
> 
> Testing
> ---
> 
> Manually tested upgrade. 
> Unit tests pass.
> 
> 
> Thanks,
> 
> Aravindan Vijayan
> 
>

Re: Review Request 47190: AMBARI-16438. Modifications to llap config names and descriptions

2016-05-10 Thread Sumit Mohanty


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


Ship it!




Ship It!

- Sumit Mohanty


On May 10, 2016, 9:19 p.m., Swapan Shridhar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47190/
> ---
> 
> (Updated May 10, 2016, 9:19 p.m.)
> 
> 
> Review request for Ambari, Jaimin Jetly and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16438
> https://issues.apache.org/jira/browse/AMBARI-16438
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> - Update LLAP with following Descriptions :
> 
> 
> % of Cluster Capacity
> Percentage of the cluster dedicated to interactive query.
> 
> Number of LLAP Daemons
> The number of Hive LLAP daemons to run.
> 
> YARN Memory per Daemon
> The total YARN memory per node to be used by Hive LLAP daemons. This includes 
> memory for cache as well as for memory for query processing.
> 
> In-Memory Cache per Daemon
> The amount of memory reserved for Hive's optimized in-memory cache.
> 
> Maximum CPUs per Daemon
> The maximum number of CPUs a single LLAP daemon will use. Usually this should 
> be equal to the number of available CPUs.
> 
> Maximum Total Concurrent Queries
> The maximum number of queries the Hive Interactive cluster will be able to 
> handle concurrently.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-env.xml
>  e199525 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-site.xml
>  f07da88 
> 
> Diff: https://reviews.apache.org/r/47190/diff/
> 
> 
> Testing
> ---
> 
> Yes. Screenshot attached.
> 
> 
> File Attachments
> 
> 
> Screen Shot 2016-05-10 at 2.18.29 PM.png
>   
> https://reviews.apache.org/media/uploaded/files/2016/05/10/3b6c19ce-0a55-42ce-86cb-a5e3cfa29686__Screen_Shot_2016-05-10_at_2.18.29_PM.png
> 
> 
> Thanks,
> 
> Swapan Shridhar
> 
>

Review Request 47190: AMBARI-16438. Modifications to llap config names and descriptions

2016-05-10 Thread Swapan Shridhar

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

Review request for Ambari, Jaimin Jetly and Sumit Mohanty.

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

Repository: ambari

Description
---

- Update LLAP with following Descriptions :

% of Cluster Capacity
Percentage of the cluster dedicated to interactive query.

Number of LLAP Daemons
The number of Hive LLAP daemons to run.

YARN Memory per Daemon
The total YARN memory per node to be used by Hive LLAP daemons. This includes
memory for cache as well as for memory for query processing.

In-Memory Cache per Daemon
The amount of memory reserved for Hive's optimized in-memory cache.

Maximum CPUs per Daemon
The maximum number of CPUs a single LLAP daemon will use. Usually this should
be equal to the number of available CPUs.

Maximum Total Concurrent Queries
The maximum number of queries the Hive Interactive cluster will be able to
handle concurrently.

Diffs
-

ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-env.xml
e199525

ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-site.xml
f07da88

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

Testing
---

Yes. Screenshot attached.

File Attachments

Screen Shot 2016-05-10 at 2.18.29 PM.png

https://reviews.apache.org/media/uploaded/files/2016/05/10/3b6c19ce-0a55-42ce-86cb-a5e3cfa29686__Screen_Shot_2016-05-10_at_2.18.29_PM.png

Thanks,

Swapan Shridhar

Re: Review Request 47142: AMBARI-16412 : Support TopN queries in AMS


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

(Updated May 10, 2016, 7:58 p.m.)


Review request for Ambari, Dmytro Sen, Sumit Mohanty, and Sid Wagle.


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


Repository: ambari


Description (updated)
---

Adding TopN support to AMS API

Following are supported.

1. Top "N" hosts when 1 metric is requested for "H" hosts.
2. Top "N" metrics when "M" metrics (or a pattern) are requested for 0 or 1 
hosts.
3. Default TopN Hosts when More than a specific value of hosts are requested. 
Default = 20. Configurable through ams-site config.


Diffs
-

  
ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/TopNConfig.java
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java
 89c67d1 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java
 a0ecbcc 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricConfiguration.java
 cf30e24 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
 ded64e3 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcher.java
 632df3f 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/ConditionBuilder.java
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/DefaultCondition.java
 99a6125 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/PhoenixTransactSQL.java
 6ee0006 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TimelineWebServices.java
 4cfc415 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestPhoenixTransactSQL.java
 9c6617c 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestTimelineMetricStore.java
 16bbf0e 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcherTest.java
 277a98c 

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


Testing
---

Manually tested.
Unit tests pass.


Thanks,

Aravindan Vijayan

Re: Review Request 47142: AMBARI-16412 : Support TopN queries in AMS

2016-05-10 Thread Ajit Kumar


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


Ship it!




Ship It!

- Ajit Kumar


On May 10, 2016, 7:56 p.m., Aravindan Vijayan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47142/
> ---
> 
> (Updated May 10, 2016, 7:56 p.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Sumit Mohanty, and Sid Wagle.
> 
> 
> Bugs: AMBARI-16412
> https://issues.apache.org/jira/browse/AMBARI-16412
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Adding TopN support to AMS API
> 
> Following are supported.
> 
> 1. Top "N" hosts when 1 metric is requested for "H" hosts.
> 2. Top "N" metrics when "M" metrics (or a pattern) are requested for 0 or 1 
> hosts.
> 3. When more than 20 hosts are requested, AMS defaults to Top N hosts 
> condition with N=20.
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/TopNConfig.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java
>  89c67d1 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java
>  a0ecbcc 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricConfiguration.java
>  cf30e24 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
>  ded64e3 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcher.java
>  632df3f 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/ConditionBuilder.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/DefaultCondition.java
>  99a6125 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/PhoenixTransactSQL.java
>  6ee0006 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TimelineWebServices.java
>  4cfc415 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestPhoenixTransactSQL.java
>  9c6617c 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestTimelineMetricStore.java
>  16bbf0e 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcherTest.java
>  277a98c 
> 
> Diff: https://reviews.apache.org/r/47142/diff/
> 
> 
> Testing
> ---
> 
> Manually tested.
> Unit tests pass.
> 
> 
> Thanks,
> 
> Aravindan Vijayan
> 
>

Re: Review Request 46808: Role selection in List view of Manage Ambari page does not work correctly

2016-05-10 Thread Keta Patel

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

(Updated May 10, 2016, 7:49 p.m.)

Review request for Ambari, Di Li and Richard Zang.

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

Repository: ambari

Description
---

Reproduction Steps:
1. Go to Admin->Manage Ambari
2. Create a group with a few users belonging to it.
(I have created "mygroup" with "user1", "user2", "user3")
(attachments "user1.tiff", "mygroup.tiff" shows samples)
3. Go to Clusters->Roles on the left navigation menu.
4. The default view is the "Block" view for the roles. Assign "mygroup" a role,
say "Cluster User".
(attachment "block_view_original.tiff")
5. Click on "List" view, it will show Users by default. It correctly shows the
role "Cluster User" for each user in "mygroup".
(attachment "list_view_users.tiff")
6. Now, try adding a new Role, say "Service Operator", to one of the users, say
"user3".
(attachments "list_view_add_role_to_user_step1.tiff",
"list_view_add_role_to_user_step2.tiff")
7. After making this change, the role gets added for that user (in our case
"user3"), but the roles from other users in its group gets removed. Also, the
previous role for the user ("user3") is replaced by the new Role.
(attachment "list_view_add_role_to_user_step3.tiff")
8. You can confirm this from the the "Block" view.
(attachment "block_view_after_step3.tiff")

So, the problem here lies with the List view where it is not able to process
the changes in the Roles correctly. A change in the Role of a user causes the
following:

CASE-1: The displayed role (effective privilege) comes from an explicitly
assigned role to the user.
1.1) The new selected role correctly replaces the existing privilege that was
explicitly assigned to the user.
1.2) But if the user was assigned multiple roles explicilty (before the fix for
AMBARI-16102 got pushed in), then all the other roles, which are of lower
privilege than the role that got replaced, are still displayed in the Block
view (because those roles are still in the database). So, if the new selected
role happened to be of a lower privilege than and existing role of the user,
then even though the user sees a success Alert message, the effective privileg
he sees is different. For the Ambari user, this behavior is not easily
understandable.

CASE-2: The displayed role (effective privilege) comes from a group the user
belongs to.
2.1) If the new selected privilege is higher than the effective privilege
coming from the user's group(s), then the newly selected role replaces this
"group" privilege in the database, insetad of creating a new entry.
2.2) As a result of losing the group privilege, all the group members also lose
their privileges and they show "None" as their effective privilege.
2.3) If the newly selected privilege is lower than effective group privilege,
the Alert message shows a success of role change but the effective privilge is
still not the one that the Ambari user selected.

Expected results:
1. Updating a Role of a user must replace any/all of the explicit roles it has
been assigned through the Block View. (this addresses 1.2)
Note: Even though AMBARI-16102 has attempted to fix the Block view by allowing
only a user to have just one role assigned to it, there could be cases where
the earlier version of Block view has already allowed users to have multiple
roles. So, taking this into consideration, the fix must address removing any or
all of the roles the user was assigned explicitly.
2. Adding a Role to a user must not affect the Roles of other users in its
group. (addressing 2.1 and 2.2)
3. Selecting a "NONE" for a user role shows the Alert "User's role chnaged to
None". This may not reflect the correct privilege status as the user might
have some effective privilege coming from its group(s). In the fix, the Alert
must show the relevant message.
4. Alert messages must show more informative messages of what is happening with
the user's privileges and why. (addressing 1.2 and 2.3)

Diffs (updated)
-

ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/clusters/UserAccessListCtrl.js
32f46c1
ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/Cluster.js
ff388cd

ambari-admin/src/main/resources/ui/admin-web/test/unit/controllers/clusters/UserAccessListCtrl_test.js
edf16be

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

Testing
---

The testing done mainly checks the logic used to update the privileges of the
user/group which is done after a REST call to retrieve the privileges.

The test cases have mocks setup for server calls. The response from the server
calls are also mocked to work with a particular set of users and groups.

The logic in the .then() clause following

Re: Review Request 46808: Role selection in List view of Manage Ambari page does not work correctly

2016-05-10 Thread Keta Patel



> On May 9, 2016, 9:42 p.m., Richard Zang wrote:
> > File Attachment: AMBARI-15552-May-05.patch - AMBARI-15552-May-05.patch
> > 
> >
> > Coding style needs to be fixed(many places). Also, could you please 
> > attach the latest patch to JIRA after the fix?

Hello Richard,
Thank you for the suggestion. I have updated the patch and attached it as 
"AMBARI-15552-May-10.patch" both on the JIRA and here on the Review Board. The 
changes involve corrections in the white spaces for "if", "for" loops and 
indentation in a few places. Please let me know of further corrections 
necessary.

Thank you,
Keta


- Keta


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


On May 10, 2016, 7:48 p.m., Keta Patel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46808/
> ---
> 
> (Updated May 10, 2016, 7:48 p.m.)
> 
> 
> Review request for Ambari, Di Li and Richard Zang.
> 
> 
> Bugs: AMBARI-15552
> https://issues.apache.org/jira/browse/AMBARI-15552
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Reproduction Steps:
> 1. Go to Admin->Manage Ambari
> 2. Create a group with a few users belonging to it. 
> (I have created "mygroup" with "user1", "user2", "user3") 
> (attachments "user1.tiff", "mygroup.tiff" shows samples)
> 3. Go to Clusters->Roles on the left navigation menu.
> 4. The default view is the "Block" view for the roles. Assign "mygroup" a 
> role, say "Cluster User". 
> (attachment "block_view_original.tiff")
> 5. Click on "List" view, it will show Users by default. It correctly shows 
> the role "Cluster User" for each user in "mygroup". 
> (attachment "list_view_users.tiff")
> 6. Now, try adding a new Role, say "Service Operator", to one of the users, 
> say "user3". 
> (attachments "list_view_add_role_to_user_step1.tiff", 
> "list_view_add_role_to_user_step2.tiff")
> 7. After making this change, the role gets added for that user (in our case 
> "user3"), but the roles from other users in its group gets removed. Also, the 
> previous role for the user ("user3") is replaced by the new Role.
> (attachment "list_view_add_role_to_user_step3.tiff")
> 8. You can confirm this from the the "Block" view. 
> (attachment "block_view_after_step3.tiff")
> 
> So, the problem here lies with the List view where it is not able to process 
> the changes in the Roles correctly. A change in the Role of a user causes the 
> following:
> 
> CASE-1: The displayed role (effective privilege) comes from an explicitly 
> assigned role to the user.
> 1.1) The new selected role correctly replaces the existing privilege that was 
> explicitly assigned to the user.
> 1.2) But if the user was assigned multiple roles explicilty (before the fix 
> for AMBARI-16102 got pushed in), then all the other roles, which are of lower 
> privilege than the role that got replaced, are still displayed in the Block 
> view (because those roles are still in the database). So, if the new selected 
> role happened to be of a lower privilege than and existing role of the user, 
> then even though the user sees a success Alert message, the effective 
> privileg he sees is different. For the Ambari user, this behavior is not 
> easily understandable.
> 
> CASE-2: The displayed role (effective privilege) comes from a group the user 
> belongs to.
> 2.1) If the new selected privilege is higher than the effective privilege 
> coming from the user's group(s), then the newly selected role replaces this 
> "group" privilege in the database, insetad of creating a new entry.
> 2.2) As a result of losing the group privilege, all the group members also 
> lose their privileges and they show "None" as their effective privilege.
> 2.3) If the newly selected privilege is lower than effective group privilege, 
> the Alert message shows a success of role change but the effective privilge 
> is still not the one that the Ambari user selected.
> 
> 
> Expected results:
> 1. Updating a Role of a user must replace any/all of the explicit roles it 
> has been assigned through the Block View. (this addresses 1.2)
> Note: Even though AMBARI-16102 has attempted to fix the Block view by 
> allowing only a user to have just one role assigned to it, there could be 
> cases where the earlier version of Block view has already allowed users to 
> have multiple roles. So, taking this into consideration, the fix must address 
> removing any or all of the roles the user was assigned explicitly.
> 2. Adding a Role to a user must not affect the Roles of other users in its 
> group. (addressing 2.1 and 2.2)
> 3. Selecting a "NONE" for a user role shows the

Re: Review Request 46808: Role selection in List view of Manage Ambari page does not work correctly

2016-05-10 Thread Keta Patel

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

(Updated May 10, 2016, 7:48 p.m.)

Review request for Ambari, Di Li and Richard Zang.

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

Repository: ambari

Description
---

So, the problem here lies with the List view where it is not able to process
the changes in the Roles correctly. A change in the Role of a user causes the
following:

Diffs
-

ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/clusters/UserAccessListCtrl.js
32f46c1
ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/Cluster.js
ff388cd

ambari-admin/src/main/resources/ui/admin-web/test/unit/controllers/clusters/UserAccessListCtrl_test.js
edf16be

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

Testing
---

The testing done mainly checks the logic used to update the privileges of the
user/group which is done after a REST call to retrieve the privileges.

The test cases have mocks setup for server calls. The response from the server
calls are also mocked to work with a particular set of users and groups.

The logic in the .then() clause following the server

Review Request 47184: AMBARI-16435 : Change Namenode Total File operations widget to request rate metric instead of actual metric.


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

Review request for Ambari, Dmytro Sen, Jaimin Jetly, Sumit Mohanty, and Sid 
Wagle.


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


Repository: ambari


Description
---

Change since Total File operations is a counter metric and is useful as a rate.


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java
 8c49ab4 
  ambari-server/src/main/resources/stacks/HDP/2.3/services/HDFS/widgets.json 
98c1f86 
  
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog240Test.java
 11f3865 

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


Testing
---

Manually tested upgrade. 
Unit tests pass.


Thanks,

Aravindan Vijayan

Re: Review Request 47142: AMBARI-16412 : Support TopN queries in AMS


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

(Updated May 10, 2016, 7:39 p.m.)


Review request for Ambari, Dmytro Sen, Sumit Mohanty, and Sid Wagle.


Changes
---

Review comments.


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


Repository: ambari


Description
---

Adding TopN support to AMS API

Following are supported.

1. Top "N" hosts when 1 metric is requested for "H" hosts.
2. Top "N" metrics when "M" metrics (or a pattern) are requested for 0 or 1 
hosts.
3. When more than 20 hosts are requested, AMS defaults to Top N hosts condition 
with N=20.


Diffs (updated)
-

  
ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/TopNConfig.java
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java
 89c67d1 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java
 a0ecbcc 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricConfiguration.java
 cf30e24 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
 ded64e3 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcher.java
 632df3f 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/ConditionBuilder.java
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/DefaultCondition.java
 99a6125 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/PhoenixTransactSQL.java
 6ee0006 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TimelineWebServices.java
 4cfc415 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestPhoenixTransactSQL.java
 9c6617c 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestTimelineMetricStore.java
 16bbf0e 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcherTest.java
 277a98c 

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


Testing
---

Manually tested.
Unit tests pass.


Thanks,

Aravindan Vijayan

Re: Review Request 47142: AMBARI-16412 : Support TopN queries in AMS



> On May 10, 2016, 7:01 p.m., Ajit Kumar wrote:
> > ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestPhoenixTransactSQL.java,
> >  line 561
> > 
> >
> > new ArrayList<>();
> > or you can do Arrays.asList("h1", "h2", "h3", "h4");

Will make this change.


- Aravindan


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


On May 10, 2016, 6:41 p.m., Aravindan Vijayan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47142/
> ---
> 
> (Updated May 10, 2016, 6:41 p.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Sumit Mohanty, and Sid Wagle.
> 
> 
> Bugs: AMBARI-16412
> https://issues.apache.org/jira/browse/AMBARI-16412
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Adding TopN support to AMS API
> 
> Following are supported.
> 
> 1. Top "N" hosts when 1 metric is requested for "H" hosts.
> 2. Top "N" metrics when "M" metrics (or a pattern) are requested for 0 or 1 
> hosts.
> 3. When more than 20 hosts are requested, AMS defaults to Top N hosts 
> condition with N=20.
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/TopNConfig.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java
>  89c67d1 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java
>  a0ecbcc 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricConfiguration.java
>  cf30e24 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
>  ded64e3 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcher.java
>  632df3f 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/ConditionBuilder.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/DefaultCondition.java
>  99a6125 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/PhoenixTransactSQL.java
>  6ee0006 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TimelineWebServices.java
>  4cfc415 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestPhoenixTransactSQL.java
>  9c6617c 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestTimelineMetricStore.java
>  16bbf0e 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcherTest.java
>  277a98c 
> 
> Diff: https://reviews.apache.org/r/47142/diff/
> 
> 
> Testing
> ---
> 
> Manually tested.
> Unit tests pass.
> 
> 
> Thanks,
> 
> Aravindan Vijayan
> 
>

Re: Review Request 47142: AMBARI-16412 : Support TopN queries in AMS



> On May 10, 2016, 7:01 p.m., Ajit Kumar wrote:
> > ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/ConditionBuilder.java,
> >  line 29
> > 
> >
> > private?
> > Any particular reason to choose List instead of collection?

Just to make sure it is comopatible with older versions of the code.


> On May 10, 2016, 7:01 p.m., Ajit Kumar wrote:
> > ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java,
> >  line 27
> > 
> >
> > private?
> > 
> > Integer or int?

Went with Integer to maintain similarity with other query params.


> On May 10, 2016, 7:01 p.m., Ajit Kumar wrote:
> > ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java,
> >  line 149
> > 
> >
> > CollectionsUtils.isNotEmpty

I will make this change.


> On May 10, 2016, 7:01 p.m., Ajit Kumar wrote:
> > ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java,
> >  line 161
> > 
> >
> > CollectionsUtils.isEmpty

1 value in hostname list is valid. Hence cannot use this util method.


- Aravindan


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


On May 10, 2016, 6:41 p.m., Aravindan Vijayan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47142/
> ---
> 
> (Updated May 10, 2016, 6:41 p.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Sumit Mohanty, and Sid Wagle.
> 
> 
> Bugs: AMBARI-16412
> https://issues.apache.org/jira/browse/AMBARI-16412
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Adding TopN support to AMS API
> 
> Following are supported.
> 
> 1. Top "N" hosts when 1 metric is requested for "H" hosts.
> 2. Top "N" metrics when "M" metrics (or a pattern) are requested for 0 or 1 
> hosts.
> 3. When more than 20 hosts are requested, AMS defaults to Top N hosts 
> condition with N=20.
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/TopNConfig.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java
>  89c67d1 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java
>  a0ecbcc 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricConfiguration.java
>  cf30e24 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
>  ded64e3 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcher.java
>  632df3f 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/ConditionBuilder.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/DefaultCondition.java
>  99a6125 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/PhoenixTransactSQL.java
>  6ee0006 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TimelineWebServices.java
>  4cfc415 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestPhoenixTransactSQL.java
>  9c6617c 
>   
>

Re: Review Request 47160: PXF should be collocated with NAMENODE even if NAMENODE is moved to another host


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



Do we have to Clean PXF from the previous NN node, if the node does no longer 
have any of PXF related ones? (DN, HAWQ etc.?)

- jun aoki


On May 10, 2016, 7:26 a.m., Matt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47160/
> ---
> 
> (Updated May 10, 2016, 7:26 a.m.)
> 
> 
> Review request for Ambari, Alexander Denissov, bhuvnesh chaudhary, Goutam 
> Tadi, jun aoki, and Lav Jain.
> 
> 
> Bugs: AMBARI-16419
> https://issues.apache.org/jira/browse/AMBARI-16419
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> After move NAMENODE wizard is executed,
> - PXF should be installed on the target host.
> - If the source host does not have a DATANODE, PXF should be removed from the 
> source host.
> 
> 
> Diffs
> -
> 
>   ambari-web/app/controllers/main/service/reassign/step6_controller.js 
> f718d46 
>   ambari-web/app/messages.js e388526 
>   ambari-web/test/controllers/main/service/reassign/step6_controller_test.js 
> 89e2325 
> 
> Diff: https://reviews.apache.org/r/47160/diff/
> 
> 
> Testing
> ---
> 
> Added unit tests.
> 
>   27727 tests complete (25 seconds)
>   154 tests pending
>   
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 01:14 min
> [INFO] Finished at: 2016-05-10T00:20:54-07:00
> [INFO] Final Memory: 12M/310M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Matt
> 
>

Re: Review Request 47142: AMBARI-16412 : Support TopN queries in AMS

2016-05-10 Thread Ajit Kumar


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




ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/ConditionBuilder.java
 (line 29)


private?
Any particular reason to choose List instead of collection?



ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java
 (line 27)


private?

Integer or int?



ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java
 (line 149)


CollectionsUtils.isNotEmpty



ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java
 (line 161)


CollectionsUtils.isEmpty



ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestPhoenixTransactSQL.java
 (line 561)


new ArrayList<>();
or you can do Arrays.asList("h1", "h2", "h3", "h4");


- Ajit Kumar


On May 10, 2016, 6:41 p.m., Aravindan Vijayan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47142/
> ---
> 
> (Updated May 10, 2016, 6:41 p.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Sumit Mohanty, and Sid Wagle.
> 
> 
> Bugs: AMBARI-16412
> https://issues.apache.org/jira/browse/AMBARI-16412
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Adding TopN support to AMS API
> 
> Following are supported.
> 
> 1. Top "N" hosts when 1 metric is requested for "H" hosts.
> 2. Top "N" metrics when "M" metrics (or a pattern) are requested for 0 or 1 
> hosts.
> 3. When more than 20 hosts are requested, AMS defaults to Top N hosts 
> condition with N=20.
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/TopNConfig.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java
>  89c67d1 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java
>  a0ecbcc 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricConfiguration.java
>  cf30e24 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
>  ded64e3 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcher.java
>  632df3f 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/ConditionBuilder.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/DefaultCondition.java
>  99a6125 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/PhoenixTransactSQL.java
>  6ee0006 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TimelineWebServices.java
>  4cfc415 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestPhoenixTransactSQL.java
>  9c6617c 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestTimelineMetricStore.java
>  16bbf0e 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcherTest.java
>  277a98c 
>

Re: Review Request 47142: AMBARI-16412 : Support TopN queries in AMS

2016-05-10 Thread Sid Wagle


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


Ship it!




Ship It!

- Sid Wagle


On May 10, 2016, 6:41 p.m., Aravindan Vijayan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47142/
> ---
> 
> (Updated May 10, 2016, 6:41 p.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Sumit Mohanty, and Sid Wagle.
> 
> 
> Bugs: AMBARI-16412
> https://issues.apache.org/jira/browse/AMBARI-16412
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Adding TopN support to AMS API
> 
> Following are supported.
> 
> 1. Top "N" hosts when 1 metric is requested for "H" hosts.
> 2. Top "N" metrics when "M" metrics (or a pattern) are requested for 0 or 1 
> hosts.
> 3. When more than 20 hosts are requested, AMS defaults to Top N hosts 
> condition with N=20.
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/TopNConfig.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java
>  89c67d1 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java
>  a0ecbcc 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricConfiguration.java
>  cf30e24 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
>  ded64e3 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcher.java
>  632df3f 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/ConditionBuilder.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/DefaultCondition.java
>  99a6125 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/PhoenixTransactSQL.java
>  6ee0006 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TimelineWebServices.java
>  4cfc415 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestPhoenixTransactSQL.java
>  9c6617c 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestTimelineMetricStore.java
>  16bbf0e 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcherTest.java
>  277a98c 
> 
> Diff: https://reviews.apache.org/r/47142/diff/
> 
> 
> Testing
> ---
> 
> Manually tested.
> Unit tests pass.
> 
> 
> Thanks,
> 
> Aravindan Vijayan
> 
>

Re: Review Request 47142: AMBARI-16412 : Support TopN queries in AMS


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

(Updated May 10, 2016, 6:41 p.m.)


Review request for Ambari, Dmytro Sen, Sumit Mohanty, and Sid Wagle.


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


Repository: ambari


Description
---

Adding TopN support to AMS API

Following are supported.

1. Top "N" hosts when 1 metric is requested for "H" hosts.
2. Top "N" metrics when "M" metrics (or a pattern) are requested for 0 or 1 
hosts.
3. When more than 20 hosts are requested, AMS defaults to Top N hosts condition 
with N=20.


Diffs (updated)
-

  
ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/TopNConfig.java
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java
 89c67d1 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java
 a0ecbcc 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricConfiguration.java
 cf30e24 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
 ded64e3 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcher.java
 632df3f 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/ConditionBuilder.java
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/DefaultCondition.java
 99a6125 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/PhoenixTransactSQL.java
 6ee0006 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TimelineWebServices.java
 4cfc415 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestPhoenixTransactSQL.java
 9c6617c 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestTimelineMetricStore.java
 16bbf0e 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcherTest.java
 277a98c 

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


Testing
---

Manually tested.
Unit tests pass.


Thanks,

Aravindan Vijayan

Re: Review Request 47160: PXF should be collocated with NAMENODE even if NAMENODE is moved to another host


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


Ship it!




Ship It!

- Lav Jain


On May 10, 2016, 7:26 a.m., Matt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47160/
> ---
> 
> (Updated May 10, 2016, 7:26 a.m.)
> 
> 
> Review request for Ambari, Alexander Denissov, bhuvnesh chaudhary, Goutam 
> Tadi, jun aoki, and Lav Jain.
> 
> 
> Bugs: AMBARI-16419
> https://issues.apache.org/jira/browse/AMBARI-16419
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> After move NAMENODE wizard is executed,
> - PXF should be installed on the target host.
> - If the source host does not have a DATANODE, PXF should be removed from the 
> source host.
> 
> 
> Diffs
> -
> 
>   ambari-web/app/controllers/main/service/reassign/step6_controller.js 
> f718d46 
>   ambari-web/app/messages.js e388526 
>   ambari-web/test/controllers/main/service/reassign/step6_controller_test.js 
> 89e2325 
> 
> Diff: https://reviews.apache.org/r/47160/diff/
> 
> 
> Testing
> ---
> 
> Added unit tests.
> 
>   27727 tests complete (25 seconds)
>   154 tests pending
>   
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 01:14 min
> [INFO] Finished at: 2016-05-10T00:20:54-07:00
> [INFO] Final Memory: 12M/310M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Matt
> 
>

Re: Review Request 47160: PXF should be collocated with NAMENODE even if NAMENODE is moved to another host


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




ambari-web/test/controllers/main/service/reassign/step6_controller_test.js 
(line 235)


+1 for comprehensive test code


- Lav Jain


On May 10, 2016, 7:26 a.m., Matt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47160/
> ---
> 
> (Updated May 10, 2016, 7:26 a.m.)
> 
> 
> Review request for Ambari, Alexander Denissov, bhuvnesh chaudhary, Goutam 
> Tadi, jun aoki, and Lav Jain.
> 
> 
> Bugs: AMBARI-16419
> https://issues.apache.org/jira/browse/AMBARI-16419
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> After move NAMENODE wizard is executed,
> - PXF should be installed on the target host.
> - If the source host does not have a DATANODE, PXF should be removed from the 
> source host.
> 
> 
> Diffs
> -
> 
>   ambari-web/app/controllers/main/service/reassign/step6_controller.js 
> f718d46 
>   ambari-web/app/messages.js e388526 
>   ambari-web/test/controllers/main/service/reassign/step6_controller_test.js 
> 89e2325 
> 
> Diff: https://reviews.apache.org/r/47160/diff/
> 
> 
> Testing
> ---
> 
> Added unit tests.
> 
>   27727 tests complete (25 seconds)
>   154 tests pending
>   
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 01:14 min
> [INFO] Finished at: 2016-05-10T00:20:54-07:00
> [INFO] Final Memory: 12M/310M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Matt
> 
>

Re: Review Request 47136: The 'krb5-conf' configuration is not available

2016-05-10 Thread Robert Levas


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

(Updated May 10, 2016, 2:09 p.m.)


Review request for Ambari, Aravindan Vijayan, Jonathan Hurley, Nate Cole, 
Sandor Magyari, and Sumit Mohanty.


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


Repository: ambari


Description
---

Configuration is loaded:
```
06 May 2016 10:52:11,998  INFO [qtp-ambari-client-26] ClusterImpl:346 - Service 
config types loaded: {KAFKA=[ranger-kafka-policymgr-ssl, kafka-log4j, 
kafka-env, kafka-broker, ranger-kafka-security, ranger-kafka-plugin-properties, 
ranger-kafka-audit], PIG=[pig-properties, pig-env, pig-log4j], 
ZEPPELIN=[zeppelin-env, zeppelin-config], 
LOGSEARCH=[logsearch-service_logs-solrconfig, logsearch-admin-json, 
logfeeder-log4j, logsearch-env, logsearch-solr-log4j, logfeeder-env, 
logsearch-audit_logs-solrconfig, logsearch-solr-env, logfeeder-properties, 
logsearch-properties, logsearch-log4j, logsearch-solr-client-log4j, 
logsearch-solr-xml], RANGER_KMS=[kms-properties, ranger-kms-security, 
ranger-kms-site, kms-site, kms-env, dbks-site, ranger-kms-audit, 
ranger-kms-policymgr-ssl, kms-log4j], MAPREDUCE2=[mapred-site, mapred-env], 
SLIDER=[slider-log4j, slider-env, slider-client], HIVE=[llap-cli-log4j2, 
hive-interactive-site, hive-exec-log4j, hive-env, ranger-hive-policymgr-ssl, 
tez-interactive-site, 
 hive-site, hivemetastore-site, hive-interactive-env, webhcat-env, 
ranger-hive-plugin-properties, webhcat-site, hive-log4j, ranger-hive-audit, 
webhcat-log4j, hiveserver2-site, hcat-env, llap-daemon-log4j, 
ranger-hive-security], TEZ=[tez-env, tez-site], HBASE=[ranger-hbase-security, 
hbase-env, hbase-policy, hbase-log4j, hbase-site, ranger-hbase-policymgr-ssl, 
ranger-hbase-audit, ranger-hbase-plugin-properties], RANGER=[admin-properties, 
tagsync-log4j, ranger-site, ranger-ugsync-site, ranger-admin-site, 
ranger-tagsync-site, usersync-log4j, tagsync-application-properties, 
usersync-properties, admin-log4j, ranger-env], OOZIE=[oozie-log4j, oozie-env, 
oozie-site], FLUME=[flume-env, flume-conf], MAHOUT=[mahout-log4j, mahout-env], 
HDFS=[ssl-server, hdfs-log4j, ranger-hdfs-audit, ranger-hdfs-plugin-properties, 
ssl-client, hdfs-site, ranger-hdfs-policymgr-ssl, ranger-hdfs-security, 
hadoop-policy, hadoop-env, core-site], AMBARI_METRICS=[ams-ssl-client, 
ams-ssl-server, ams-hbase-log4j, ams-grafa
 na-env, ams-hbase-policy, ams-hbase-security-site, ams-hbase-env, ams-env, 
ams-grafana-ini, ams-log4j, ams-site, ams-hbase-site], 
SPARK=[spark-thrift-fairscheduler, spark-thrift-sparkconf, 
spark-log4j-properties, spark-defaults, spark-metrics-properties, 
spark-hive-site-override, spark-env], SMARTSENSE=[hst-log4j, hst-server-conf, 
hst-common-conf, capture-levels, hst-agent-conf, anonymization-rules], 
YARN=[ranger-yarn-policymgr-ssl, yarn-site, ranger-yarn-audit, 
ranger-yarn-security, ranger-yarn-plugin-properties, yarn-env, 
capacity-scheduler, yarn-log4j], FALCON=[falcon-startup.properties, 
falcon-runtime.properties, falcon-env], SQOOP=[sqoop-site, sqoop-env], 
ZOOKEEPER=[zoo.cfg, zookeeper-env, zookeeper-log4j], 
STORM=[ranger-storm-plugin-properties, storm-site, ranger-storm-audit, 
storm-cluster-log4j, storm-worker-log4j, ranger-storm-policymgr-ssl, 
ranger-storm-security, storm-env], ATLAS=[atlas-hbase-site, atlas-log4j, 
atlas-env, application-properties], GANGLIA=[ganglia-env], KNO
 X=[knoxsso-topology, ranger-knox-security, users-ldif, knox-env, 
ranger-knox-plugin-properties, gateway-site, gateway-log4j, 
ranger-knox-policymgr-ssl, ranger-knox-audit, topology, admin-topology, 
ldap-log4j], KERBEROS=[kerberos-env, krb5-conf], ACCUMULO=[accumulo-log4j, 
accumulo-env, client, accumulo-site]}
```

But: 
```
06 May 2016 12:43:46,050 ERROR [qtp-ambari-client-171] 
AbstractResourceProvider:314 - Caught AmbariException when getting a resource
org.apache.ambari.server.AmbariException: The 'krb5-conf' configuration is not 
available
at 
org.apache.ambari.server.controller.KerberosHelperImpl.getKerberosDetails(KerberosHelperImpl.java:1903)
at 
org.apache.ambari.server.controller.KerberosHelperImpl.addAmbariServerIdentity(KerberosHelperImpl.java:1364)
at 
org.apache.ambari.server.controller.KerberosHelperImpl.getActiveIdentities(KerberosHelperImpl.java:1283)
at 
org.apache.ambari.server.controller.internal.HostKerberosIdentityResourceProvider$GetResourcesCommand.invoke(HostKerberosIdentityResourceProvider.java:163)
at 
org.apache.ambari.server.controller.internal.HostKerberosIdentityResourceProvider$GetResourcesCommand.invoke(HostKerberosIdentityResourceProvider.java:145)
at 
org.apache.ambari.server.controller.internal.AbstractResourceProvider.getResources(AbstractResourceProvider.java:307)
at

Re: Review Request 47147: AMBARI-16413: Ambari server does not start because of permission issues on symbolic links

2016-05-10 Thread Sid Wagle


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


Ship it!




Ship It!

- Sid Wagle


On May 10, 2016, 12:41 a.m., Nahappan Somasundaram wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47147/
> ---
> 
> (Updated May 10, 2016, 12:41 a.m.)
> 
> 
> Review request for Ambari, Andrew Onischuk, Mahadev Konar, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16413
> https://issues.apache.org/jira/browse/AMBARI-16413
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> AMBARI-16413: Ambari server does not start because of permission issues on 
> symbolic links
> 
> ** Issue **
> 
> When setting up ambari-server with a non-root user, ownership change on 
> various log files and other files do not work when those files are in a 
> symbolic linked folder.
> 
> ** Fix **
> When doing a chown -R , specify the -L option to traverse every 
> symbolic link.
> 
> 
> Diffs
> -
> 
>   ambari-common/src/main/python/ambari_commons/os_linux.py a64f99a 
> 
> Diff: https://reviews.apache.org/r/47147/diff/
> 
> 
> Testing
> ---
> 
> ** 1. mvn test -DskipSurefireTests **
> 
> --
> Ran 261 tests in 6.567s
> 
> OK
> --
> Total run:1014
> Total errors:0
> Total failures:0
> OK
> INFO: AMBARI_SERVER_LIB is not set, using default /usr/lib/ambari-server
> INFO: Return code from stack upgrade command, retcode = 0
> StackAdvisor implementation for stack HDP1, version 2.0.6 was not found
> Returning DefaultStackAdvisor implementation
> StackAdvisor implementation for stack XYZ, version 1.0.0 was loaded
> StackAdvisor implementation for stack XYZ, version 1.0.1 was loaded
> Returning XYZ101StackAdvisor implementation
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 1:06.431s
> [INFO] Finished at: Mon May 09 17:35:47 PDT 2016
> [INFO] Final Memory: 61M/984M
> [INFO] 
> 
> 
> ** 2. Manual testing **
> Set up a VM and copy the changed os_linux.py script fromt the build to the 
> VM. Run the following commands:
> rm -rf /var/log/ambari-server
> mkdir /tmp/log/ambari-server
> cd /var/log
> ln -s ambari-server /tmp/log/ambari-server
> 
> Run ambari-server setup and use a non-root user. Verify that the permissions 
> on /var/log/ambari-server and it's contents now have the non-root user as the 
> owner.
> 
> Run ambari-server start and verify that it was successful.
> 
> 
> Thanks,
> 
> Nahappan Somasundaram
> 
>

Re: Review Request 47142: AMBARI-16412 : Support TopN queries in AMS


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

(Updated May 10, 2016, 5:34 p.m.)


Review request for Ambari, Dmytro Sen, Sumit Mohanty, and Sid Wagle.


Changes
---

Review Comments


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


Repository: ambari


Description
---

Adding TopN support to AMS API

Following are supported.

1. Top "N" hosts when 1 metric is requested for "H" hosts.
2. Top "N" metrics when "M" metrics (or a pattern) are requested for 0 or 1 
hosts.
3. When more than 20 hosts are requested, AMS defaults to Top N hosts condition 
with N=20.


Diffs (updated)
-

  
ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/TopNConfig.java
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java
 89c67d1 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java
 a0ecbcc 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricConfiguration.java
 cf30e24 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
 ded64e3 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcher.java
 632df3f 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/ConditionBuilder.java
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/DefaultCondition.java
 99a6125 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/PhoenixTransactSQL.java
 6ee0006 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TimelineWebServices.java
 4cfc415 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestPhoenixTransactSQL.java
 9c6617c 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestTimelineMetricStore.java
 16bbf0e 
  
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcherTest.java
 277a98c 

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


Testing
---

Manually tested.
Unit tests pass.


Thanks,

Aravindan Vijayan

Re: Review Request 47140: Ambari Should Suspend Alerts Notifications During Upgrade

2016-05-10 Thread Nate Cole


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


Ship it!




Ship It!

- Nate Cole


On May 10, 2016, 12:38 p.m., Jonathan Hurley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47140/
> ---
> 
> (Updated May 10, 2016, 12:38 p.m.)
> 
> 
> Review request for Ambari, Nate Cole and Robert Levas.
> 
> 
> Bugs: AMBARI-16410
> https://issues.apache.org/jira/browse/AMBARI-16410
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Ambari reports alerts and triggers notifications during a stack upgrade. In 
> most cases, alert notifications should be suppressed during the upgrade to 
> prevent false positives. 
> 
> However, some alerts, such as those which don't related to the cluster, 
> should remain fully operational:
> 
> - Host disk space
> - Upgrade not finalized
> - Ambari Server Performance
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/events/listeners/alerts/AlertStateChangedListener.java
>  21584fb 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/alerts/AlertStateChangedEventTest.java
>  f76867a 
> 
> Diff: https://reviews.apache.org/r/47140/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

Re: Review Request 47142: AMBARI-16412 : Support TopN queries in AMS

2016-05-10 Thread Sid Wagle



> On May 10, 2016, 12:27 a.m., Sid Wagle wrote:
> > ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java,
> >  line 308
> > 
> >
> > We should cleanup the interface and remove this sigular function call 
> > unless it is documented as supported API.
> 
> Aravindan Vijayan wrote:
> Used by some unit tests.

The unit tests can be ignored as long this API is not being used in order to 
avoid maintenance headache.


- Sid


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


On May 9, 2016, 11:50 p.m., Aravindan Vijayan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47142/
> ---
> 
> (Updated May 9, 2016, 11:50 p.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Sumit Mohanty, and Sid Wagle.
> 
> 
> Bugs: AMBARI-16412
> https://issues.apache.org/jira/browse/AMBARI-16412
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Adding TopN support to AMS API
> 
> Following are supported.
> 
> 1. Top "N" hosts when 1 metric is requested for "H" hosts.
> 2. Top "N" metrics when "M" metrics (or a pattern) are requested for 0 or 1 
> hosts.
> 3. When more than 20 hosts are requested, AMS defaults to Top N hosts 
> condition with N=20.
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/TopNConfig.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java
>  89c67d1 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java
>  a0ecbcc 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
>  ded64e3 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcher.java
>  632df3f 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/ConditionBuilder.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/DefaultCondition.java
>  99a6125 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/PhoenixTransactSQL.java
>  6ee0006 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TimelineWebServices.java
>  4cfc415 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestPhoenixTransactSQL.java
>  9c6617c 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestTimelineMetricStore.java
>  16bbf0e 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcherTest.java
>  277a98c 
> 
> Diff: https://reviews.apache.org/r/47142/diff/
> 
> 
> Testing
> ---
> 
> Manually tested.
> Unit tests pass.
> 
> 
> Thanks,
> 
> Aravindan Vijayan
> 
>

Re: Review Request 47160: PXF should be collocated with NAMENODE even if NAMENODE is moved to another host

2016-05-10 Thread Goutam Tadi


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


Ship it!




Ship It!

- Goutam Tadi


On May 10, 2016, 7:26 a.m., Matt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47160/
> ---
> 
> (Updated May 10, 2016, 7:26 a.m.)
> 
> 
> Review request for Ambari, Alexander Denissov, bhuvnesh chaudhary, Goutam 
> Tadi, jun aoki, and Lav Jain.
> 
> 
> Bugs: AMBARI-16419
> https://issues.apache.org/jira/browse/AMBARI-16419
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> After move NAMENODE wizard is executed,
> - PXF should be installed on the target host.
> - If the source host does not have a DATANODE, PXF should be removed from the 
> source host.
> 
> 
> Diffs
> -
> 
>   ambari-web/app/controllers/main/service/reassign/step6_controller.js 
> f718d46 
>   ambari-web/app/messages.js e388526 
>   ambari-web/test/controllers/main/service/reassign/step6_controller_test.js 
> 89e2325 
> 
> Diff: https://reviews.apache.org/r/47160/diff/
> 
> 
> Testing
> ---
> 
> Added unit tests.
> 
>   27727 tests complete (25 seconds)
>   154 tests pending
>   
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 01:14 min
> [INFO] Finished at: 2016-05-10T00:20:54-07:00
> [INFO] Final Memory: 12M/310M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Matt
> 
>

Re: Review Request 47142: AMBARI-16412 : Support TopN queries in AMS



> On May 10, 2016, 12:27 a.m., Sid Wagle wrote:
> > ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java,
> >  line 308
> > 
> >
> > We should cleanup the interface and remove this sigular function call 
> > unless it is documented as supported API.

Used by some unit tests.


- Aravindan


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


On May 9, 2016, 11:50 p.m., Aravindan Vijayan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47142/
> ---
> 
> (Updated May 9, 2016, 11:50 p.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Sumit Mohanty, and Sid Wagle.
> 
> 
> Bugs: AMBARI-16412
> https://issues.apache.org/jira/browse/AMBARI-16412
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Adding TopN support to AMS API
> 
> Following are supported.
> 
> 1. Top "N" hosts when 1 metric is requested for "H" hosts.
> 2. Top "N" metrics when "M" metrics (or a pattern) are requested for 0 or 1 
> hosts.
> 3. When more than 20 hosts are requested, AMS defaults to Top N hosts 
> condition with N=20.
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/TopNConfig.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java
>  89c67d1 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java
>  a0ecbcc 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
>  ded64e3 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcher.java
>  632df3f 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/ConditionBuilder.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/DefaultCondition.java
>  99a6125 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/PhoenixTransactSQL.java
>  6ee0006 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/query/TopNCondition.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/webapp/TimelineWebServices.java
>  4cfc415 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestPhoenixTransactSQL.java
>  9c6617c 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TestTimelineMetricStore.java
>  16bbf0e 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcherTest.java
>  277a98c 
> 
> Diff: https://reviews.apache.org/r/47142/diff/
> 
> 
> Testing
> ---
> 
> Manually tested.
> Unit tests pass.
> 
> 
> Thanks,
> 
> Aravindan Vijayan
> 
>

Re: Review Request 47023: Views: Simplify View Configuration for Remote Ambari Managed Cluster. Ambari Server Side changes


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


Ship it!





ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariCluster.java
 (line 51)


Make it final maybe?



ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariCluster.java
 (lines 69 - 70)


Yeah, it's too bad you can't just use the cluster name from the response - 
but I suppose that the URI would be different then too :)


- Jonathan Hurley


On May 10, 2016, 11:29 a.m., Gaurav Nagar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47023/
> ---
> 
> (Updated May 10, 2016, 11:29 a.m.)
> 
> 
> Review request for Ambari, DIPAYAN BHOWMICK, Jonathan Hurley, Nitiraj 
> Rathore, Pallav Kulshreshtha, Rohit Choudhary, and Ashwin Rajeev.
> 
> 
> Bugs: AMBARI-16274
> https://issues.apache.org/jira/browse/AMBARI-16274
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Added RemotAmbariClusterEntity, RemoteAmbariClusterDao to store remote 
> cluster credential.
> Added RemoteClusterResourceProvider for accessing Remote Cluster through api.
> Added RemoteAmbariCluster impementation for view.Cluster that can be accessed 
> through ViewContextImpl.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/resources/RemoteClusterResourceDefinition.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/resources/ResourceInstanceFactoryImpl.java
>  0b77511 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/services/RemoteClustersService.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/DefaultProviderModule.java
>  4e7a032 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/RemoteClusterResourceProvider.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ViewInstanceResourceProvider.java
>  605f68d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/spi/Resource.java
>  386e657 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/RemoteAmbariClusterDAO.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/entities/RemoteAmbariClusterEntity.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/entities/RemoteAmbariClusterServiceEntity.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ViewEntity.java
>  29dc2a7 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ViewInstanceEntity.java
>  2d6e5ba 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariCluster.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariClusterRegistry.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariConfigurationReadException.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariStreamProvider.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/ViewAmbariStreamProvider.java
>  1dacd92 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/ViewContextImpl.java
>  ba7f446 
>   ambari-server/src/main/java/org/apache/ambari/server/view/ViewRegistry.java 
> d2d48a9 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/configuration/ViewConfig.java
>  bb6a93c 
>   ambari-server/src/main/resources/META-INF/persistence.xml ce563cb 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/RemoteClusterResourceProviderTest.java
>  PRE-CREATION 
>   
> ambari-server/src/test/java/org/apache/ambari/server/view/RemoteAmbariClusterTest.java
>  PRE-CREATION 
>   
> ambari-server/src/test/java/org/apache/ambari/server/view/ViewAmbariStreamProviderTest.java
>  8549d4a 
>   
> ambari-server/src/test/java/org/apache/ambari/server/view/configuration/ViewConfigTest.java
>  a41e137 
> 
> Diff: https://reviews.apache.org/r/47023/diff/
> 
> 
> Testing
> ---
> 
> Manual Testing
> 
> 
> Thanks,
> 
> Gaurav Nagar
> 
>

Re: Review Request 46944: AMBARI-16230: Sporadic errors when deploying the cluster

2016-05-10 Thread Myroslav Papirkovskyy


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


Ship it!




Ship It!

- Myroslav Papirkovskyy


On Травень 10, 2016, 7:19 після полудня, Oliver Szabo wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46944/
> ---
> 
> (Updated Травень 10, 2016, 7:19 після полудня)
> 
> 
> Review request for Ambari, Jonathan Hurley, Laszlo Puskas, Myroslav 
> Papirkovskyy, Sumit Mohanty, and Sebastian Toader.
> 
> 
> Bugs: AMBARI-16230
> https://issues.apache.org/jira/browse/AMBARI-16230
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> 2 different type of errors can occur during adding any new service to Ambari:
> 
> org.apache.ambari.server.AmbariException: Unable to create a default alert 
> group for unknown service  in cluster
> 
> org.apache.ambari.server.ServiceNotFoundException: Service not found, 
> clusterName=c1, serviceName=
> 
> The reason is that: ServiceInstalledEvent can be handled quicker than 
> ServiceImpl.persist() can finish
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ServiceResourceProvider.java
>  47342f3 
>   ambari-server/src/main/java/org/apache/ambari/server/state/ServiceImpl.java 
> 487489b 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
>  f38c25a 
>   ambari-server/src/test/java/org/apache/ambari/server/events/EventsTest.java 
> a3d05a9 
>   ambari-server/src/test/java/org/apache/ambari/server/orm/OrmTestHelper.java 
> 19146fd 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/alerts/AlertEventPublisherTest.java
>  d1b27a9 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/alerts/InitialAlertEventTest.java
>  1875ba6 
> 
> Diff: https://reviews.apache.org/r/46944/diff/
> 
> 
> Testing
> ---
> 
> Unit Testing is in progress..
> FT: added new services about 10 times, has no any errors thrown.
> 
> 
> Thanks,
> 
> Oliver Szabo
> 
>

Re: Review Request 46944: AMBARI-16230: Sporadic errors when deploying the cluster

2016-05-10 Thread Oliver Szabo


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

(Updated May 10, 2016, 4:19 p.m.)


Review request for Ambari, Jonathan Hurley, Laszlo Puskas, Myroslav 
Papirkovskyy, Sumit Mohanty, and Sebastian Toader.


Changes
---

removed volatile keyword


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


Repository: ambari


Description
---

2 different type of errors can occur during adding any new service to Ambari:

org.apache.ambari.server.AmbariException: Unable to create a default alert 
group for unknown service  in cluster

org.apache.ambari.server.ServiceNotFoundException: Service not found, 
clusterName=c1, serviceName=

The reason is that: ServiceInstalledEvent can be handled quicker than 
ServiceImpl.persist() can finish


Diffs (updated)
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ServiceResourceProvider.java
 47342f3 
  ambari-server/src/main/java/org/apache/ambari/server/state/ServiceImpl.java 
487489b 
  
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
 f38c25a 
  ambari-server/src/test/java/org/apache/ambari/server/events/EventsTest.java 
a3d05a9 
  ambari-server/src/test/java/org/apache/ambari/server/orm/OrmTestHelper.java 
19146fd 
  
ambari-server/src/test/java/org/apache/ambari/server/state/alerts/AlertEventPublisherTest.java
 d1b27a9 
  
ambari-server/src/test/java/org/apache/ambari/server/state/alerts/InitialAlertEventTest.java
 1875ba6 

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


Testing
---

Unit Testing is in progress..
FT: added new services about 10 times, has no any errors thrown.


Thanks,

Oliver Szabo

Re: Review Request 47026: Views: Simplify View Configuration for Remote Ambari Managed Cluster. Ambari Database changes


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


Fix it, then Ship it!





ambari-server/src/main/resources/Ambari-DDL-Derby-CREATE.sql (line 795)


Oracle maximum is 30 characters - let's reduce this across the board.


- Jonathan Hurley


On May 10, 2016, 12:02 p.m., Gaurav Nagar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47026/
> ---
> 
> (Updated May 10, 2016, 12:02 p.m.)
> 
> 
> Review request for Ambari, DIPAYAN BHOWMICK, Jonathan Hurley, Nitiraj 
> Rathore, Pallav Kulshreshtha, Rohit Choudhary, and Ashwin Rajeev.
> 
> 
> Bugs: AMBARI-16274
> https://issues.apache.org/jira/browse/AMBARI-16274
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Added tables for Remote Cluster to create scripts.
> Added table changes to UpgradeCatalog240
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java
>  f85a4c7 
>   ambari-server/src/main/resources/Ambari-DDL-Derby-CREATE.sql f5336bc 
>   ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql fca3be3 
>   ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql ce0bd84 
>   ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql 7fb8c31 
>   ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql 
> 0f3a2c2 
>   ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql b89389c 
>   ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 1107c4d 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog240Test.java
>  7c85ba7 
> 
> Diff: https://reviews.apache.org/r/47026/diff/
> 
> 
> Testing
> ---
> 
> Manual Testing.
> 
> 
> Thanks,
> 
> Gaurav Nagar
> 
>

Re: Review Request 47023: Views: Simplify View Configuration for Remote Ambari Managed Cluster. Ambari Server Side changes



> On May 9, 2016, 3:39 p.m., Jonathan Hurley wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariCluster.java,
> >  lines 65-66
> > 
> >
> > What was wrong with getName() ? this seems a lot more likely to have 
> > problems
> 
> Gaurav Nagar wrote:
> The getName in the remoteAmbariClusterEntity is the nage give by user 
> while creating RemoteClusterEntity. This is different from actual name of the 
> cluster on Remote Ambari Server. 
> The url will be in format like 
> http://host:port:/api/v1/clusters/${clusterName} . As the url will always be 
> in format, this should not cause any problem.

For now it will be I suppose ... So you need to guarantee that the URL has the 
cluster name it in and that it stops at the cluster name. This will break at 
some point in the future with the introduction of api/v2 ... it's too bad you 
can't use the JSON response to determine the cluster name.


- Jonathan


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


On May 10, 2016, 11:29 a.m., Gaurav Nagar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47023/
> ---
> 
> (Updated May 10, 2016, 11:29 a.m.)
> 
> 
> Review request for Ambari, DIPAYAN BHOWMICK, Jonathan Hurley, Nitiraj 
> Rathore, Pallav Kulshreshtha, Rohit Choudhary, and Ashwin Rajeev.
> 
> 
> Bugs: AMBARI-16274
> https://issues.apache.org/jira/browse/AMBARI-16274
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Added RemotAmbariClusterEntity, RemoteAmbariClusterDao to store remote 
> cluster credential.
> Added RemoteClusterResourceProvider for accessing Remote Cluster through api.
> Added RemoteAmbariCluster impementation for view.Cluster that can be accessed 
> through ViewContextImpl.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/resources/RemoteClusterResourceDefinition.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/resources/ResourceInstanceFactoryImpl.java
>  0b77511 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/services/RemoteClustersService.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/DefaultProviderModule.java
>  4e7a032 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/RemoteClusterResourceProvider.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ViewInstanceResourceProvider.java
>  605f68d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/spi/Resource.java
>  386e657 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/RemoteAmbariClusterDAO.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/entities/RemoteAmbariClusterEntity.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/entities/RemoteAmbariClusterServiceEntity.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ViewEntity.java
>  29dc2a7 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ViewInstanceEntity.java
>  2d6e5ba 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariCluster.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariClusterRegistry.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariConfigurationReadException.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariStreamProvider.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/ViewAmbariStreamProvider.java
>  1dacd92 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/ViewContextImpl.java
>  ba7f446 
>   ambari-server/src/main/java/org/apache/ambari/server/view/ViewRegistry.java 
> d2d48a9 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/configuration/ViewConfig.java
>  bb6a93c 
>   ambari-server/src/main/resources/META-INF/persistence.xml ce563cb 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/RemoteClusterResourceProviderTest.java
>  PRE-CREATION 
>   
> ambari-server/src/test/java/org/apache/ambari/server/view/RemoteAmbariClusterTest.java
>  PRE-CREATION 
>   
> ambari-server/src/test/java/org/apache/ambari/server/view/ViewAmbariStreamProviderTest.java
>  8549d4a 
>   
> ambari-server/src/test/java/org/apache/ambari/server/view/configuration/ViewConfigTest.java
>

Re: Review Request 47026: Views: Simplify View Configuration for Remote Ambari Managed Cluster. Ambari Database changes


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

(Updated May 10, 2016, 4:02 p.m.)


Review request for Ambari, DIPAYAN BHOWMICK, Jonathan Hurley, Nitiraj Rathore, 
Pallav Kulshreshtha, Rohit Choudhary, and Ashwin Rajeev.


Changes
---

Changed clusterType column to non nullable.


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


Repository: ambari


Description
---

Added tables for Remote Cluster to create scripts.
Added table changes to UpgradeCatalog240


Diffs (updated)
-

  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java
 f85a4c7 
  ambari-server/src/main/resources/Ambari-DDL-Derby-CREATE.sql f5336bc 
  ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql fca3be3 
  ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql ce0bd84 
  ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql 7fb8c31 
  ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql 
0f3a2c2 
  ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql b89389c 
  ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 1107c4d 
  
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog240Test.java
 7c85ba7 

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


Testing
---

Manual Testing.


Thanks,

Gaurav Nagar

Re: Review Request 47026: Views: Simplify View Configuration for Remote Ambari Managed Cluster. Ambari Database changes



> On May 10, 2016, 3:44 p.m., Jonathan Hurley wrote:
> > ambari-server/src/main/resources/Ambari-DDL-Derby-CREATE.sql, lines 791-797
> > 
> >
> > I thought in the entities you had this as a Many-To-Many relationship 
> > ... but here it's 1:M (which is what I'd expect).
> > 
> > Are the entities adjusted accordingly?

Yes. Changed the Mapping to one to Many. Entities are adjusted accordingly.


- Gaurav


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


On May 10, 2016, 11:19 a.m., Gaurav Nagar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47026/
> ---
> 
> (Updated May 10, 2016, 11:19 a.m.)
> 
> 
> Review request for Ambari, DIPAYAN BHOWMICK, Jonathan Hurley, Nitiraj 
> Rathore, Pallav Kulshreshtha, Rohit Choudhary, and Ashwin Rajeev.
> 
> 
> Bugs: AMBARI-16274
> https://issues.apache.org/jira/browse/AMBARI-16274
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Added tables for Remote Cluster to create scripts.
> Added table changes to UpgradeCatalog240
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java
>  f85a4c7 
>   ambari-server/src/main/resources/Ambari-DDL-Derby-CREATE.sql f5336bc 
>   ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql fca3be3 
>   ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql ce0bd84 
>   ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql 7fb8c31 
>   ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql 
> 0f3a2c2 
>   ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql b89389c 
>   ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 1107c4d 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog240Test.java
>  7c85ba7 
> 
> Diff: https://reviews.apache.org/r/47026/diff/
> 
> 
> Testing
> ---
> 
> Manual Testing.
> 
> 
> Thanks,
> 
> Gaurav Nagar
> 
>

Re: Review Request 47026: Views: Simplify View Configuration for Remote Ambari Managed Cluster. Ambari Database changes


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




ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java
 (line 270)


nullable?



ambari-server/src/main/resources/Ambari-DDL-Derby-CREATE.sql (line 570)


nullable?



ambari-server/src/main/resources/Ambari-DDL-Derby-CREATE.sql (lines 791 - 797)


I thought in the entities you had this as a Many-To-Many relationship ... 
but here it's 1:M (which is what I'd expect).

Are the entities adjusted accordingly?


- Jonathan Hurley


On May 10, 2016, 7:19 a.m., Gaurav Nagar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47026/
> ---
> 
> (Updated May 10, 2016, 7:19 a.m.)
> 
> 
> Review request for Ambari, DIPAYAN BHOWMICK, Jonathan Hurley, Nitiraj 
> Rathore, Pallav Kulshreshtha, Rohit Choudhary, and Ashwin Rajeev.
> 
> 
> Bugs: AMBARI-16274
> https://issues.apache.org/jira/browse/AMBARI-16274
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Added tables for Remote Cluster to create scripts.
> Added table changes to UpgradeCatalog240
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java
>  f85a4c7 
>   ambari-server/src/main/resources/Ambari-DDL-Derby-CREATE.sql f5336bc 
>   ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql fca3be3 
>   ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql ce0bd84 
>   ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql 7fb8c31 
>   ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql 
> 0f3a2c2 
>   ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql b89389c 
>   ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 1107c4d 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog240Test.java
>  7c85ba7 
> 
> Diff: https://reviews.apache.org/r/47026/diff/
> 
> 
> Testing
> ---
> 
> Manual Testing.
> 
> 
> Thanks,
> 
> Gaurav Nagar
> 
>

Re: Review Request 47023: Views: Simplify View Configuration for Remote Ambari Managed Cluster. Ambari Server Side changes


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

(Updated May 10, 2016, 3:29 p.m.)


Review request for Ambari, DIPAYAN BHOWMICK, Jonathan Hurley, Nitiraj Rathore, 
Pallav Kulshreshtha, Rohit Choudhary, and Ashwin Rajeev.


Changes
---

Updated view url formation for remote cluster


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


Repository: ambari


Description
---

Added RemotAmbariClusterEntity, RemoteAmbariClusterDao to store remote cluster 
credential.
Added RemoteClusterResourceProvider for accessing Remote Cluster through api.
Added RemoteAmbariCluster impementation for view.Cluster that can be accessed 
through ViewContextImpl.


Diffs (updated)
-

  
ambari-server/src/main/java/org/apache/ambari/server/api/resources/RemoteClusterResourceDefinition.java
 PRE-CREATION 
  
ambari-server/src/main/java/org/apache/ambari/server/api/resources/ResourceInstanceFactoryImpl.java
 0b77511 
  
ambari-server/src/main/java/org/apache/ambari/server/api/services/RemoteClustersService.java
 PRE-CREATION 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/DefaultProviderModule.java
 4e7a032 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/RemoteClusterResourceProvider.java
 PRE-CREATION 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ViewInstanceResourceProvider.java
 605f68d 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/spi/Resource.java
 386e657 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/RemoteAmbariClusterDAO.java
 PRE-CREATION 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/RemoteAmbariClusterEntity.java
 PRE-CREATION 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/RemoteAmbariClusterServiceEntity.java
 PRE-CREATION 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ViewEntity.java
 29dc2a7 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ViewInstanceEntity.java
 2d6e5ba 
  
ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariCluster.java
 PRE-CREATION 
  
ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariClusterRegistry.java
 PRE-CREATION 
  
ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariConfigurationReadException.java
 PRE-CREATION 
  
ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariStreamProvider.java
 PRE-CREATION 
  
ambari-server/src/main/java/org/apache/ambari/server/view/ViewAmbariStreamProvider.java
 1dacd92 
  
ambari-server/src/main/java/org/apache/ambari/server/view/ViewContextImpl.java 
ba7f446 
  ambari-server/src/main/java/org/apache/ambari/server/view/ViewRegistry.java 
d2d48a9 
  
ambari-server/src/main/java/org/apache/ambari/server/view/configuration/ViewConfig.java
 bb6a93c 
  ambari-server/src/main/resources/META-INF/persistence.xml ce563cb 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/RemoteClusterResourceProviderTest.java
 PRE-CREATION 
  
ambari-server/src/test/java/org/apache/ambari/server/view/RemoteAmbariClusterTest.java
 PRE-CREATION 
  
ambari-server/src/test/java/org/apache/ambari/server/view/ViewAmbariStreamProviderTest.java
 8549d4a 
  
ambari-server/src/test/java/org/apache/ambari/server/view/configuration/ViewConfigTest.java
 a41e137 

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


Testing
---

Manual Testing


Thanks,

Gaurav Nagar

Re: Review Request 47027: Views: Simplify View Configuration for Remote Ambari Managed Cluster. Ambari Views changes


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

(Updated May 10, 2016, 3:25 p.m.)


Review request for Ambari, DIPAYAN BHOWMICK, Jonathan Hurley, Nitiraj Rathore, 
Pallav Kulshreshtha, Rohit Choudhary, and Ashwin Rajeev.


Changes
---

Fixed url formation


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


Repository: ambari


Description
---

Added AmbariClusterStreamProvider interface for connecting to Ambari Cluster 
(Can be Remote or Local) that is attached to view instance.
Added Cluster Type Enum (LOCAL_AMBARI, REMOTE_AMBARI, NONE) for differentiating 
cluster type attached to view instance.


Diffs (updated)
-

  
ambari-views/src/main/java/org/apache/ambari/view/AmbariClusterStreamProvider.java
 PRE-CREATION 
  ambari-views/src/main/java/org/apache/ambari/view/AmbariHttpException.java 
PRE-CREATION 
  ambari-views/src/main/java/org/apache/ambari/view/AmbariStreamProvider.java 
ce91676 
  ambari-views/src/main/java/org/apache/ambari/view/ClusterType.java 
PRE-CREATION 
  ambari-views/src/main/java/org/apache/ambari/view/ViewContext.java 7b7b025 
  ambari-views/src/main/java/org/apache/ambari/view/ViewInstanceDefinition.java 
0c3d3ce 
  ambari-views/src/main/resources/view.xsd 04902e9 
  
contrib/views/capacity-scheduler/src/main/java/org/apache/ambari/view/capacityscheduler/ConfigurationService.java
 7f1d489 
  contrib/views/capacity-scheduler/src/main/resources/view.xml 6dc3ffa 
  
contrib/views/capacity-scheduler/src/test/java/org/apache/ambari/view/capacityscheduler/ConfigurationServiceTest.java
 62fa21e 
  
contrib/views/hive/src/main/java/org/apache/ambari/view/hive/resources/uploads/UploadService.java
 83eae9b 
  
contrib/views/slider/src/main/java/org/apache/ambari/view/slider/rest/client/BaseHttpClient.java
 b4fccf9 
  
contrib/views/utils/src/main/java/org/apache/ambari/view/utils/ambari/AmbariApi.java
 6b88b6f 
  
contrib/views/utils/src/main/java/org/apache/ambari/view/utils/ambari/RemoteCluster.java
 41dc88d 
  
contrib/views/utils/src/main/java/org/apache/ambari/view/utils/ambari/Services.java
 a8ef43f 
  
contrib/views/utils/src/main/java/org/apache/ambari/view/utils/ambari/URLStreamProviderBasicAuth.java
 c9f735a 
  
contrib/views/utils/src/main/java/org/apache/ambari/view/utils/hdfs/AuthConfigurationBuilder.java
 c8ca6cd 
  
contrib/views/utils/src/main/java/org/apache/ambari/view/utils/hdfs/ConfigurationBuilder.java
 4518ac6 
  
contrib/views/utils/src/test/java/org/apache/ambari/view/utils/ambari/RemoteClusterTest.java
 ec4df7d 
  
contrib/views/utils/src/test/java/org/apache/ambari/view/utils/ambari/ServicesTest.java
 455ca20 
  
contrib/views/utils/src/test/java/org/apache/ambari/view/utils/ambari/URLStreamProviderBasicAuthTest.java
 27e98f2 

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


Testing
---

Manual Testing


Thanks,

Gaurav Nagar

Re: Review Request 47136: The 'krb5-conf' configuration is not available

2016-05-10 Thread Nate Cole


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


Ship it!




Ship It!

- Nate Cole


On May 9, 2016, 11:22 p.m., Robert Levas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47136/
> ---
> 
> (Updated May 9, 2016, 11:22 p.m.)
> 
> 
> Review request for Ambari, Aravindan Vijayan, Jonathan Hurley, Nate Cole, 
> Sandor Magyari, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16397
> https://issues.apache.org/jira/browse/AMBARI-16397
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Configuration is loaded:
> ```
> 06 May 2016 10:52:11,998  INFO [qtp-ambari-client-26] ClusterImpl:346 - 
> Service config types loaded: {KAFKA=[ranger-kafka-policymgr-ssl, kafka-log4j, 
> kafka-env, kafka-broker, ranger-kafka-security, 
> ranger-kafka-plugin-properties, ranger-kafka-audit], PIG=[pig-properties, 
> pig-env, pig-log4j], ZEPPELIN=[zeppelin-env, zeppelin-config], 
> LOGSEARCH=[logsearch-service_logs-solrconfig, logsearch-admin-json, 
> logfeeder-log4j, logsearch-env, logsearch-solr-log4j, logfeeder-env, 
> logsearch-audit_logs-solrconfig, logsearch-solr-env, logfeeder-properties, 
> logsearch-properties, logsearch-log4j, logsearch-solr-client-log4j, 
> logsearch-solr-xml], RANGER_KMS=[kms-properties, ranger-kms-security, 
> ranger-kms-site, kms-site, kms-env, dbks-site, ranger-kms-audit, 
> ranger-kms-policymgr-ssl, kms-log4j], MAPREDUCE2=[mapred-site, mapred-env], 
> SLIDER=[slider-log4j, slider-env, slider-client], HIVE=[llap-cli-log4j2, 
> hive-interactive-site, hive-exec-log4j, hive-env, ranger-hive-policymgr-ssl, 
> tez-interactive-site
 , hive-site, hivemetastore-site, hive-interactive-env, webhcat-env, 
ranger-hive-plugin-properties, webhcat-site, hive-log4j, ranger-hive-audit, 
webhcat-log4j, hiveserver2-site, hcat-env, llap-daemon-log4j, 
ranger-hive-security], TEZ=[tez-env, tez-site], HBASE=[ranger-hbase-security, 
hbase-env, hbase-policy, hbase-log4j, hbase-site, ranger-hbase-policymgr-ssl, 
ranger-hbase-audit, ranger-hbase-plugin-properties], RANGER=[admin-properties, 
tagsync-log4j, ranger-site, ranger-ugsync-site, ranger-admin-site, 
ranger-tagsync-site, usersync-log4j, tagsync-application-properties, 
usersync-properties, admin-log4j, ranger-env], OOZIE=[oozie-log4j, oozie-env, 
oozie-site], FLUME=[flume-env, flume-conf], MAHOUT=[mahout-log4j, mahout-env], 
HDFS=[ssl-server, hdfs-log4j, ranger-hdfs-audit, ranger-hdfs-plugin-properties, 
ssl-client, hdfs-site, ranger-hdfs-policymgr-ssl, ranger-hdfs-security, 
hadoop-policy, hadoop-env, core-site], AMBARI_METRICS=[ams-ssl-client, 
ams-ssl-server, ams-hbase-log4j, ams-gra
 fana-env, ams-hbase-policy, ams-hbase-security-site, ams-hbase-env, ams-env, 
ams-grafana-ini, ams-log4j, ams-site, ams-hbase-site], 
SPARK=[spark-thrift-fairscheduler, spark-thrift-sparkconf, 
spark-log4j-properties, spark-defaults, spark-metrics-properties, 
spark-hive-site-override, spark-env], SMARTSENSE=[hst-log4j, hst-server-conf, 
hst-common-conf, capture-levels, hst-agent-conf, anonymization-rules], 
YARN=[ranger-yarn-policymgr-ssl, yarn-site, ranger-yarn-audit, 
ranger-yarn-security, ranger-yarn-plugin-properties, yarn-env, 
capacity-scheduler, yarn-log4j], FALCON=[falcon-startup.properties, 
falcon-runtime.properties, falcon-env], SQOOP=[sqoop-site, sqoop-env], 
ZOOKEEPER=[zoo.cfg, zookeeper-env, zookeeper-log4j], 
STORM=[ranger-storm-plugin-properties, storm-site, ranger-storm-audit, 
storm-cluster-log4j, storm-worker-log4j, ranger-storm-policymgr-ssl, 
ranger-storm-security, storm-env], ATLAS=[atlas-hbase-site, atlas-log4j, 
atlas-env, application-properties], GANGLIA=[ganglia-env], K
 NOX=[knoxsso-topology, ranger-knox-security, users-ldif, knox-env, 
ranger-knox-plugin-properties, gateway-site, gateway-log4j, 
ranger-knox-policymgr-ssl, ranger-knox-audit, topology, admin-topology, 
ldap-log4j], KERBEROS=[kerberos-env, krb5-conf], ACCUMULO=[accumulo-log4j, 
accumulo-env, client, accumulo-site]}
> ```
> 
> But: 
> ```
> 06 May 2016 12:43:46,050 ERROR [qtp-ambari-client-171] 
> AbstractResourceProvider:314 - Caught AmbariException when getting a resource
> org.apache.ambari.server.AmbariException: The 'krb5-conf' configuration is 
> not available
>   at 
> org.apache.ambari.server.controller.KerberosHelperImpl.getKerberosDetails(KerberosHelperImpl.java:1903)
>   at 
> org.apache.ambari.server.controller.KerberosHelperImpl.addAmbariServerIdentity(KerberosHelperImpl.java:1364)
>   at 
> org.apache.ambari.server.controller.KerberosHelperImpl.getActiveIdentities(KerberosHelperImpl.java:1283)
>   at 
>

Re: Review Request 47009: Falcon server start fails

2016-05-10 Thread Tom Beerbower



> On May 9, 2016, 9:49 p.m., Venkat Ranganathan wrote:
> > ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/configuration/falcon-env.xml,
> >  line 162
> > 
> >
> > Don't we want the server classpath to be changed in falcon-config?

Thanks for the review.  I'm not familiar with falcon-config.  Could you give 
more details?


- Tom


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


On May 5, 2016, 12:07 p.m., Tom Beerbower wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47009/
> ---
> 
> (Updated May 5, 2016, 12:07 p.m.)
> 
> 
> Review request for Ambari, Sumit Mohanty and Venkat Ranganathan.
> 
> 
> Bugs: AMBARI-16263
> https://issues.apache.org/jira/browse/AMBARI-16263
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Deployed HDP-2.5 and Falcon server failed to start.
> 
> 
> cat /var/log/falcon/falcon.out.20160504002*
> Error: Could not find or load main class org.apache.falcon.FalconServer
> Error: Could not find or load main class org.apache.falcon.FalconServer
> Error: Could not find or load main class org.apache.falcon.FalconServer
> 
> 
> The command to start, in Ambari is:
> 
> 
> Execute['/usr/hdp/current/falcon-server/bin/falcon-start -port 15000'] 
> {'environment': {'HADOOP_HOME': '/usr/hdp/current/hadoop-client'}, 'path': 
> ['/usr/hdp/current/hadoop-client/bin'], 'user': 'falcon'}
> 
> 
> Link falcon hook jars in falcon classpath - 'ln -s /hook/falcon/* 
> /server/webapp/falcon/WEB-INF/lib/'
> is what is causing it. If falcon webapp is already exploded it will fail for 
> falcon webapp itself. That step should not be done and we should change it to 
> add falcon hook into webapp.jar itself post deployment like what we do for 
> Oozie with prepare-war or added to server classpath explicitly
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/configuration/falcon-env.xml
>  3fdf2e6 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/params_linux.py
>  bf7f437 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/setup_atlas_falcon.py
>  4b7c0c3 
> 
> Diff: https://reviews.apache.org/r/47009/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Tom Beerbower
> 
>

Re: Review Request 46999: AMBARI-16261: LogFeeder logs are not showing up in LogSearch

2016-05-10 Thread Robert Nettleton


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


Ship it!




Ship It!

- Robert Nettleton


On May 10, 2016, 7:34 a.m., Don Bosco Durai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46999/
> ---
> 
> (Updated May 10, 2016, 7:34 a.m.)
> 
> 
> Review request for Ambari, Oliver Szabo and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16261
> https://issues.apache.org/jira/browse/AMBARI-16261
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Found out 3 issues:
> 1. Path to LogFeeder was incorrect
> 2. Input config was incorrect. We were using grok, but LogSearch logs are in 
> JSON format
> 3. log4j.xml for logsearch portal was not using JSON appender
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/templates/input.config-logsearch.json.j2
>  06aaba6 
> 
> Diff: https://reviews.apache.org/r/46999/diff/
> 
> 
> Testing
> ---
> 
> Tested by updating the log4j in Ambari and also updating config files.
> 
> 
> Thanks,
> 
> Don Bosco Durai
> 
>

Re: Review Request 47136: The 'krb5-conf' configuration is not available


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


Ship it!




Ship It!

- Jonathan Hurley


On May 9, 2016, 11:22 p.m., Robert Levas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47136/
> ---
> 
> (Updated May 9, 2016, 11:22 p.m.)
> 
> 
> Review request for Ambari, Aravindan Vijayan, Jonathan Hurley, Nate Cole, 
> Sandor Magyari, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16397
> https://issues.apache.org/jira/browse/AMBARI-16397
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Configuration is loaded:
> ```
> 06 May 2016 10:52:11,998  INFO [qtp-ambari-client-26] ClusterImpl:346 - 
> Service config types loaded: {KAFKA=[ranger-kafka-policymgr-ssl, kafka-log4j, 
> kafka-env, kafka-broker, ranger-kafka-security, 
> ranger-kafka-plugin-properties, ranger-kafka-audit], PIG=[pig-properties, 
> pig-env, pig-log4j], ZEPPELIN=[zeppelin-env, zeppelin-config], 
> LOGSEARCH=[logsearch-service_logs-solrconfig, logsearch-admin-json, 
> logfeeder-log4j, logsearch-env, logsearch-solr-log4j, logfeeder-env, 
> logsearch-audit_logs-solrconfig, logsearch-solr-env, logfeeder-properties, 
> logsearch-properties, logsearch-log4j, logsearch-solr-client-log4j, 
> logsearch-solr-xml], RANGER_KMS=[kms-properties, ranger-kms-security, 
> ranger-kms-site, kms-site, kms-env, dbks-site, ranger-kms-audit, 
> ranger-kms-policymgr-ssl, kms-log4j], MAPREDUCE2=[mapred-site, mapred-env], 
> SLIDER=[slider-log4j, slider-env, slider-client], HIVE=[llap-cli-log4j2, 
> hive-interactive-site, hive-exec-log4j, hive-env, ranger-hive-policymgr-ssl, 
> tez-interactive-site
 , hive-site, hivemetastore-site, hive-interactive-env, webhcat-env, 
ranger-hive-plugin-properties, webhcat-site, hive-log4j, ranger-hive-audit, 
webhcat-log4j, hiveserver2-site, hcat-env, llap-daemon-log4j, 
ranger-hive-security], TEZ=[tez-env, tez-site], HBASE=[ranger-hbase-security, 
hbase-env, hbase-policy, hbase-log4j, hbase-site, ranger-hbase-policymgr-ssl, 
ranger-hbase-audit, ranger-hbase-plugin-properties], RANGER=[admin-properties, 
tagsync-log4j, ranger-site, ranger-ugsync-site, ranger-admin-site, 
ranger-tagsync-site, usersync-log4j, tagsync-application-properties, 
usersync-properties, admin-log4j, ranger-env], OOZIE=[oozie-log4j, oozie-env, 
oozie-site], FLUME=[flume-env, flume-conf], MAHOUT=[mahout-log4j, mahout-env], 
HDFS=[ssl-server, hdfs-log4j, ranger-hdfs-audit, ranger-hdfs-plugin-properties, 
ssl-client, hdfs-site, ranger-hdfs-policymgr-ssl, ranger-hdfs-security, 
hadoop-policy, hadoop-env, core-site], AMBARI_METRICS=[ams-ssl-client, 
ams-ssl-server, ams-hbase-log4j, ams-gra
 fana-env, ams-hbase-policy, ams-hbase-security-site, ams-hbase-env, ams-env, 
ams-grafana-ini, ams-log4j, ams-site, ams-hbase-site], 
SPARK=[spark-thrift-fairscheduler, spark-thrift-sparkconf, 
spark-log4j-properties, spark-defaults, spark-metrics-properties, 
spark-hive-site-override, spark-env], SMARTSENSE=[hst-log4j, hst-server-conf, 
hst-common-conf, capture-levels, hst-agent-conf, anonymization-rules], 
YARN=[ranger-yarn-policymgr-ssl, yarn-site, ranger-yarn-audit, 
ranger-yarn-security, ranger-yarn-plugin-properties, yarn-env, 
capacity-scheduler, yarn-log4j], FALCON=[falcon-startup.properties, 
falcon-runtime.properties, falcon-env], SQOOP=[sqoop-site, sqoop-env], 
ZOOKEEPER=[zoo.cfg, zookeeper-env, zookeeper-log4j], 
STORM=[ranger-storm-plugin-properties, storm-site, ranger-storm-audit, 
storm-cluster-log4j, storm-worker-log4j, ranger-storm-policymgr-ssl, 
ranger-storm-security, storm-env], ATLAS=[atlas-hbase-site, atlas-log4j, 
atlas-env, application-properties], GANGLIA=[ganglia-env], K
 NOX=[knoxsso-topology, ranger-knox-security, users-ldif, knox-env, 
ranger-knox-plugin-properties, gateway-site, gateway-log4j, 
ranger-knox-policymgr-ssl, ranger-knox-audit, topology, admin-topology, 
ldap-log4j], KERBEROS=[kerberos-env, krb5-conf], ACCUMULO=[accumulo-log4j, 
accumulo-env, client, accumulo-site]}
> ```
> 
> But: 
> ```
> 06 May 2016 12:43:46,050 ERROR [qtp-ambari-client-171] 
> AbstractResourceProvider:314 - Caught AmbariException when getting a resource
> org.apache.ambari.server.AmbariException: The 'krb5-conf' configuration is 
> not available
>   at 
> org.apache.ambari.server.controller.KerberosHelperImpl.getKerberosDetails(KerberosHelperImpl.java:1903)
>   at 
> org.apache.ambari.server.controller.KerberosHelperImpl.addAmbariServerIdentity(KerberosHelperImpl.java:1364)
>   at 
> org.apache.ambari.server.controller.KerberosHelperImpl.getActiveIdentities(KerberosHelperImpl.java:1283)
>   at 
>

Re: Review Request 47163: AMBARI-16420: LogFeeder not using fully qualified domain name

2016-05-10 Thread Robert Nettleton


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


Ship it!




Ship It!

- Robert Nettleton


On May 10, 2016, 7:58 a.m., Don Bosco Durai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47163/
> ---
> 
> (Updated May 10, 2016, 7:58 a.m.)
> 
> 
> Review request for Ambari, Hayat Behlim, Dharmesh Makwana, Oliver Szabo, and 
> Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16420
> https://issues.apache.org/jira/browse/AMBARI-16420
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> LogFeeder was using InetAddress.getHostName() method, which was not return 
> the FQDN. Using InetAddress.getCanonicalHostName() resolved the issue
> 
> 
> Diffs
> -
> 
>   
> ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/OutputMgr.java
>  5b70bca 
> 
> Diff: https://reviews.apache.org/r/47163/diff/
> 
> 
> Testing
> ---
> 
> Testing in local Ambari environment
> 
> 
> Thanks,
> 
> Don Bosco Durai
> 
>

Re: Review Request 47140: Ambari Should Suspend Alerts Notifications During Upgrade



> On May 10, 2016, 5:01 a.m., Robert Levas wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/events/listeners/alerts/AlertStateChangedListener.java,
> >  line 192
> > 
> >
> > "the an"?  Don't fix unless there are other changes.

Thx for the review.

Comments are as important as the code itself - I'm fixing it!!! :)


- Jonathan


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


On May 9, 2016, 7:36 p.m., Jonathan Hurley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47140/
> ---
> 
> (Updated May 9, 2016, 7:36 p.m.)
> 
> 
> Review request for Ambari and Robert Levas.
> 
> 
> Bugs: AMBARI-16410
> https://issues.apache.org/jira/browse/AMBARI-16410
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Ambari reports alerts and triggers notifications during a stack upgrade. In 
> most cases, alert notifications should be suppressed during the upgrade to 
> prevent false positives. 
> 
> However, some alerts, such as those which don't related to the cluster, 
> should remain fully operational:
> 
> - Host disk space
> - Upgrade not finalized
> - Ambari Server Performance
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/events/listeners/alerts/AlertStateChangedListener.java
>  21584fb 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/alerts/AlertStateChangedEventTest.java
>  f76867a 
> 
> Diff: https://reviews.apache.org/r/47140/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

Re: Review Request 47130: Upgrade is blocked at 'Upgrade Options' wizard because of Service Checks requirement

2016-05-10 Thread Dmitro Lisnichenko


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




ambari-server/src/main/java/org/apache/ambari/server/checks/ServiceCheckValidityCheck.java
 (line 113)


good idea


- Dmitro Lisnichenko


On May 10, 2016, 1:35 p.m., Nate Cole wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47130/
> ---
> 
> (Updated May 10, 2016, 1:35 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Dmitro Lisnichenko, Jonathan 
> Hurley, and Jayush Luniya.
> 
> 
> Bugs: AMBARI-16380
> https://issues.apache.org/jira/browse/AMBARI-16380
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> The ServiceCheck prerequisite check was checking all service checks, not 
> solely the most recent ones.  So even if Service Checks were run again, the 
> prereq check was still failing on the old runs:
> 
> * Changed the query to only pull back SERVICE_CHECK records using a Predicate.
> * Considered a stale config check, but that was adding complexity where none 
> is needed (debatable).
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/checks/ServiceCheckValidityCheck.java
>  8b39863 
>   
> ambari-server/src/test/java/org/apache/ambari/server/checks/ServiceCheckValidityCheckTest.java
>  4a3ae5c 
> 
> Diff: https://reviews.apache.org/r/47130/diff/
> 
> 
> Testing
> ---
> 
> Manual.  Automated:
> 
> Tests run: 4304, Failures: 0, Errors: 0, Skipped: 34
> 
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 38:25.682s
> [INFO] Finished at: Mon May 09 15:46:16 EDT 2016
> [INFO] Final Memory: 35M/700M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Nate Cole
> 
>

Re: Review Request 47130: Upgrade is blocked at 'Upgrade Options' wizard because of Service Checks requirement

2016-05-10 Thread Dmitro Lisnichenko


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


Ship it!




Ship It!

- Dmitro Lisnichenko


On May 10, 2016, 1:35 p.m., Nate Cole wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47130/
> ---
> 
> (Updated May 10, 2016, 1:35 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Dmitro Lisnichenko, Jonathan 
> Hurley, and Jayush Luniya.
> 
> 
> Bugs: AMBARI-16380
> https://issues.apache.org/jira/browse/AMBARI-16380
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> The ServiceCheck prerequisite check was checking all service checks, not 
> solely the most recent ones.  So even if Service Checks were run again, the 
> prereq check was still failing on the old runs:
> 
> * Changed the query to only pull back SERVICE_CHECK records using a Predicate.
> * Considered a stale config check, but that was adding complexity where none 
> is needed (debatable).
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/checks/ServiceCheckValidityCheck.java
>  8b39863 
>   
> ambari-server/src/test/java/org/apache/ambari/server/checks/ServiceCheckValidityCheckTest.java
>  4a3ae5c 
> 
> Diff: https://reviews.apache.org/r/47130/diff/
> 
> 
> Testing
> ---
> 
> Manual.  Automated:
> 
> Tests run: 4304, Failures: 0, Errors: 0, Skipped: 34
> 
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 38:25.682s
> [INFO] Finished at: Mon May 09 15:46:16 EDT 2016
> [INFO] Final Memory: 35M/700M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Nate Cole
> 
>

Re: Review Request 47138: stackadvisor uses getHostsForSlaveComponent with wrong parameter name

2016-05-10 Thread Tim Thorpe


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


Ship it!




Ship It!

- Tim Thorpe


On May 9, 2016, 11:43 p.m., Lav Jain wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47138/
> ---
> 
> (Updated May 9, 2016, 11:43 p.m.)
> 
> 
> Review request for Ambari, Alexander Denissov, bhuvnesh chaudhary, Goutam 
> Tadi, jun aoki, Matt, and Tim Thorpe.
> 
> 
> Bugs: AMBARI-16378
> https://issues.apache.org/jira/browse/AMBARI-16378
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> ```
> def getHostsForSlaveComponent(self, services, hosts, component, hostsList, 
> hostsComponentsMap, freeHosts):
> componentName = component["StackServiceComponents"]["component_name"]
> 
> if component["StackServiceComponents"]["cardinality"] == "ALL":
>   return hostsList
> 
> componentIsPopulated = self.isComponentHostsPopulated(component)
> if componentIsPopulated:
>   return component["StackServiceComponents"]["hostnames"]
> 
> hostsForComponent = []
> 
> if self.isSlaveComponent(component):
>   cardinality = str(component["StackServiceComponents"]["cardinality"])
>   if self.isComponentUsingCardinalityForLayout(component) and cardinality:
> # cardinality types: 1+, 1-2, 1
> ```
> 
> The correct parameter name is comonentName (instead of component)
> 
> 
> Diffs
> -
> 
>   ambari-server/src/main/resources/stacks/stack_advisor.py 00b9d79 
> 
> Diff: https://reviews.apache.org/r/47138/diff/
> 
> 
> Testing
> ---
> 
> Tested manually
> 
> 
> Thanks,
> 
> Lav Jain
> 
>

Re: Review Request 47026: Views: Simplify View Configuration for Remote Ambari Managed Cluster. Ambari Database changes