date:20160425


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

(Updated April 25, 2016, 11:37 p.m.)


Review request for Ambari, Alejandro Fernandez and Sumit Mohanty.


Changes
---

Added Sid's suggestions and fixed few corener cases.


Bugs: AMBARI-16078, AMBARI-16079, AMBARI-16086, and AMBARI-16087
https://issues.apache.org/jira/browse/AMBARI-16078
https://issues.apache.org/jira/browse/AMBARI-16079
https://issues.apache.org/jira/browse/AMBARI-16086
https://issues.apache.org/jira/browse/AMBARI-16087


Repository: ambari


Description
---

Fix for : 
  (1). AMBARI-16078. Config calculations used by LLAP app. 
  
  Trivial fixes for :
  
   (2). AMBARI-16079. waiting for fixed number of times if the launched LLAP 
app is in LAUNCHING state, for it to go to RUNNING_ALL or RUNNING_PARTIAL
  (3). AMBARI-16086. Hide HSI related sliders when 'llap' queue is not being 
used.
  (4). AMBARI-16087. LLAP queue is not selected when enabling Hive Interactive 
Query during Install Wizard

AMBARI-16078:

- Calculated in Stack advisor code whenever : LLAP queue is in selection and 
(1). HSI is enabled or (2). change done to slider HSI slider "% of Cluster 
Capacity" , or (3). change done to slider HSI slider 'Number of Daemon 
Instances'
- 
- caluclations are not done if the overall cluster state is not conduciv for 
meaningful run of LLAP.

AMBARI-16079: 
=

Reason : If the LLAP app state is LAUNCHING and we go ahead with HSI start, the 
overall workability of app may not be ascertained.
As of now, using llap0 name, app does go into RUNNING_ALL state.


Diffs (updated)
-

  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_interactive.py
 f548ea3 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
 a044fda 
  
ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-env.xml
 816e207 
  
ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-site.xml
 21d1109 
  
ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/themes/theme.json 
4e1a54b 
  ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
4da21fa 
  ambari-server/src/test/python/stacks/2.5/HIVE/test_hive_server_int.py 44759a9 
  ambari-server/src/test/python/stacks/2.5/common/test_stack_advisor.py 3934301 
  ambari-server/src/test/python/stacks/2.5/configs/hsi_default.json 1cb2a02 

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


Testing
---

- Python tests added.
- Python UT passes.


--
Ran 261 tests in 7.091s

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


Thanks,

Swapan Shridhar

Re: Review Request 45507: Enhance blueprint support for using references

2016-04-25 Thread Amruta Borkar



> On April 19, 2016, 8:47 p.m., Robert Nettleton wrote:
> > I've taken a quick look at this, and I have a few concerns with this patch:
> > 
> > 1. I'm not sure there is that much utility in replacing the secret tokens 
> > with the "default_password" value specified in the Cluster Creation 
> > Template.  It should be noted that the "default_password" was never meant 
> > as a production-level feature, and is there mainly for the convenience of 
> > developers building new Blueprints.  With that in mind, I'm not sure it 
> > makes sense to introduce this kind of change. In most production scenarios, 
> > it is likely that most of the passwords will differ, and will need to be 
> > handled manually anyway.  In those cases, it is usually best to configure 
> > the passwords in a Cluster Creation Template, keeping the Blueprint as 
> > portable as possible.
> > 2. I've mentioned this in my comments, but I'm a little concerned about 
> > removing the Password property filter, for the reasons I list below.  We've 
> > hit many situations in which a new set of stack configurations cause a 
> > "password" to show up in clear text, and this filter is very useful in 
> > keeping much of that from being a problem.  If a change like the one 
> > proposed goes through, at the very least this filter should be 
> > re-introduced, and modified to account for any changes made.
> > 
> > Thanks.

Hello Bob,

Thank you for your feedback, we are working on a document that would explain 
this and relevant functionality in more details. I also agree with some of the 
issues listed here and I am working on it. 

Thanks


- Amruta


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


On March 30, 2016, 10:19 p.m., Amruta Borkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45507/
> ---
> 
> (Updated March 30, 2016, 10:19 p.m.)
> 
> 
> Review request for Ambari and Robert Nettleton.
> 
> 
> Bugs: AMBARI-15395 and AMBARI-15406
> https://issues.apache.org/jira/browse/AMBARI-15395
> https://issues.apache.org/jira/browse/AMBARI-15406
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Enhance blueprints to export placeholder/token for password properties. This 
> is to avoid user from having tochange the password once the cluster is formed 
> if a user wishes to do so.
> Secret References acting as tokens to password properties would be replaced 
> by user with appropriate passwords,
> If any Secret references are found during cluster deployment with blueprint, 
> those will be replaced by default_password provided in blueprint template. 
> Need more comments to make this feature more portable.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
>  9cc7b13 
>   
> ambari-server/src/main/java/org/apache/ambari/server/topology/BlueprintValidatorImpl.java
>  432c6f8 
>   
> ambari-server/src/main/java/org/apache/ambari/server/topology/RequiredPasswordValidator.java
>  98eaa40 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
>  14a718d 
>   
> ambari-server/src/test/java/org/apache/ambari/server/topology/BlueprintImplTest.java
>  0b06eb8 
>   
> ambari-server/src/test/java/org/apache/ambari/server/topology/RequiredPasswordValidatorTest.java
>  e8a2ff5 
> 
> Diff: https://reviews.apache.org/r/45507/diff/
> 
> 
> Testing
> ---
> 
> Tested the patch by trying out blueprint export and creating a cluster from 
> the exported blueprint. Result was: the password tokens were replaced by 
> default password and cluster was created successfully.
> 
> 
> File Attachments
> 
> 
> AMBARI-15406.patch
>   
> https://reviews.apache.org/media/uploaded/files/2016/03/30/8daa09ee-82e5-4cd8-98d3-b1c00f1269b7__AMBARI-15406.patch
> 
> 
> Thanks,
> 
> Amruta Borkar
> 
>

Re: Review Request 46398: Name in create Alert Notification should be restricted to use only alphanumerics, hyphens, spaces and underscores

2016-04-25 Thread Alexandr Antonenko



> On April 20, 2016, 9:46 a.m., Alexandr Antonenko wrote:
> > Ship It!
> 
> Anita Jebaraj wrote:
> Can you please push the code to trunk, I don't have the priviledge for 
> that.

yes, ofc


- Alexandr


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


On April 19, 2016, 6:20 p.m., Anita Jebaraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46398/
> ---
> 
> (Updated April 19, 2016, 6:20 p.m.)
> 
> 
> Review request for Ambari, Alexandr Antonenko and Di Li.
> 
> 
> Bugs: ambari-15869
> https://issues.apache.org/jira/browse/ambari-15869
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Click Alerts at the top
> The Click Actions -> select Manage Notifications
> Click on the + icon, the create Alert notification pop up will be displayed.
> Currently the notification name allows all characters, it should be 
> restricted to allow only alphanumberics, spaces, hyphens and underscores.
> 
> 
> Diffs
> -
> 
>   
> ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js
>  7dd7dea 
>   ambari-web/app/messages.js 3ede13a 
>   ambari-web/app/utils/validator.js 6426163 
>   
> ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
>  837c2f3 
> 
> Diff: https://reviews.apache.org/r/46398/diff/
> 
> 
> Testing
> ---
> 
> Ran mvn clean test 
>   25660 tests complete (29 seconds)
>   154 tests pending
> 
> 
> Thanks,
> 
> Anita Jebaraj
> 
>

Re: Review Request 46562: View Configuration Simplification

2016-04-25 Thread Jonathan Hurley


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



Did a quick pass through - could we add JavaDoc for methods with don't have it 
- I saw a lot of them.

I'll take another pass through and look at some of the view specific code


ambari-server/src/main/java/org/apache/ambari/server/api/resources/ResourceInstanceFactoryImpl.java
 (lines 225 - 227)


It's not really an instance of a view or a cluster - it's just 
configuration information, right? Should probably reflect that in the naming; 
something like ViewClusterConfiguration



ambari-server/src/main/java/org/apache/ambari/server/api/resources/ResourceInstanceFactoryImpl.java
 (lines 229 - 231)


This really isn't a service; it's more like the meta information which 
describes what a view needs. Could be something like ViewConfigurationTemplate 
or something similar.



ambari-server/src/main/java/org/apache/ambari/server/api/services/ViewClusterInstanceService.java
 (line 35)


Consider revising / renaming.



ambari-server/src/main/java/org/apache/ambari/server/api/services/ViewClusterInstanceService.java
 (lines 47 - 51)


GETs don't need a body.



ambari-server/src/main/java/org/apache/ambari/server/api/services/ViewServiceService.java
 (line 38)


Consider revising / renaming.



ambari-server/src/main/java/org/apache/ambari/server/api/services/ViewServiceService.java
 (lines 50 - 54)


Gets don't need a body.



ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ViewClusterInstanceResourceProvider.java
 (lines 138 - 139)


Proper Javadoc



ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ViewClusterInstanceResourceProvider.java
 (line 141)


Transactional should not be defined at this level.



ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ViewClusterInstanceResourceProvider.java
 (line 165)


Transactional should not be defined at this level.



ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ViewClusterInstanceResourceProvider.java
 (line 182)


JavaDoc



ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ViewClusterInstanceResourceProvider.java
 (line 198)


JavaDoc.



ambari-server/src/main/java/org/apache/ambari/server/orm/dao/ViewClusterConfigurationDao.java
 (lines 36 - 40)


Private?



ambari-server/src/main/java/org/apache/ambari/server/orm/dao/ViewClusterConfigurationDao.java
 (lines 67 - 69)


Use a NamedQuery



ambari-server/src/main/java/org/apache/ambari/server/orm/dao/ViewServiceDAO.java
 (lines 41 - 42)


Private?



ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ViewClusterConfigurationPropertyEntityPK.java
 (line 27)


We don't use compound PKs - instead use a surrogate PK and define these 
parameters as a UNIQUE constraint.



ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ViewClusterServiceEntityPK.java
 (line 27)


We don't use compound PKs - instead use a surrogate PK and define these 
parameters as a UNIQUE constraint.



ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ViewInstanceEntity.java
 (lines 86 - 88)


Enum?



ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ViewInstanceEntity.java
 (lines 124 - 125)


This should be an enumeration.



ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ViewServiceParameterEntityPK.java
 (line 27)


We don't use compound PKs - instead use a surrogate PK and define these 
parameters as a UNIQUE constraint.



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


In general we use surrogate PKs and try not to use the business logic as 
constraints.

Also, we can create the PK and

Re: Review Request 46651: AMBARI-16102: Inconsistency between grid and list view of roles page


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


Ship it!




Ship It!

- Zhe (Joe) Wang


On April 25, 2016, 6:39 p.m., Richard Zang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46651/
> ---
> 
> (Updated April 25, 2016, 6:39 p.m.)
> 
> 
> Review request for Ambari and Zhe (Joe) Wang.
> 
> 
> Bugs: AMBARI-16102
> https://issues.apache.org/jira/browse/AMBARI-16102
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> In the grid view, a user can be assigned more than one role just by typing 
> the user name in 2 different role fields. But in list view you see/can choose 
> only one role.
> Attached : Screenshots.
> The RMP suggested that the UI must allow just one role per user. We should 
> add a check while adding users to roles in the grid view to check that a user 
> is assigned only one role
> 
> 
> Diffs
> -
> 
>   ambari-admin/src/main/resources/ui/admin-web/app/scripts/i18n.config.js 
> e95ebdb 
>   
> ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/PermissionsSaver.js
>  6560f51 
> 
> Diff: https://reviews.apache.org/r/46651/diff/
> 
> 
> Testing
> ---
> 
> Manually tested on live cluster.
> 
> 
> Thanks,
> 
> Richard Zang
> 
>

Re: Review Request 46475: Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.

2016-04-25 Thread Keta Patel



> On April 25, 2016, 6:27 p.m., Di Li wrote:
> > Ship It!

Thank you Di!


- Keta


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


On April 25, 2016, 4:37 p.m., Keta Patel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46475/
> ---
> 
> (Updated April 25, 2016, 4:37 p.m.)
> 
> 
> Review request for Ambari, Andrii Tkach and Di Li.
> 
> 
> Bugs: AMBARI-15979
> https://issues.apache.org/jira/browse/AMBARI-15979
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> ISSUE:
> The UI validation at present checks only the length of the user input for 
> widget_name and description fields. All characters are allowed to be stored 
> in the database through them. A more strict UI validation that limits the 
> type of characters entered for these fields will provide a good first line of 
> defense. 
> 
> Steps to reproduce:
> 1. Make sure you have Ambari Metrics service installed on your cluster.
> 2. On the Dashboard, select any service that makes use of Ambari Metrics, say 
> HDFS.
> 3. In the "Metrics" section, click the "Actions" button in the top-right 
> corner, and select "Create a new widget" option from the drop-down. 
> (attachment: create_widget_button_location.tiff)
> 4. Create widget pop-up is displayed. 
> 5. On Step-1, select any type for the widget and click "Next". (attachment: 
> create_widget_step1.tiff)
> 6. On Step-2, select any valid metrics parameter and click "Next". 
> (attachment: create_widget_step2.tiff)
> 7. On Step-3, for widget_name and description fields, you can enter any 
> character. No validation is present to check the contents. The only 
> validation present checks the length of the input text. 
> (attachments:
> create_widget_step3.tiff, 
> original_characters_allowed_for_name_and_description.tiff,
> original_length_validation_for_name.tiff,
> original_length_validation_for_description.tiff )
> 
> 
> FIX:
> The UI validation is enhanced by checking the content of the input for name 
> and description.
> The patch attached allows only alphanumeric, underscore, hyphen, space and 
> percentage symbol to be valid characters for both fields.
> The % symbol is added as part of the white-list as there are existing widgets 
> that contain % symbols in their names. In order to keep the characters in the 
> name consistent, this was decided.
> The description could probably have a little more flexibility in terms of 
> characters allowed. Any suggestions to update this validation would be 
> helpful.
> The warning message template is also updated to conform to the existing norms 
> used in several Ambari pop-ups (e.g. Manage Config Groups, Manage Alert 
> Groups).
> 
> The images attached (starting with "fixed_") show how the fix appears with 
> the patch.
> 
> 
> Diffs
> -
> 
>   ambari-web/app/controllers/main/service/widgets/create/step3_controller.js 
> dd7a93f 
>   ambari-web/app/messages.js 907d9ae 
>   ambari-web/app/templates/main/service/widgets/create/step3.hbs 9f431af 
>   
> ambari-web/test/controllers/main/service/widgets/create/step3_controller_test.js
>  6f92142 
> 
> Diff: https://reviews.apache.org/r/46475/diff/
> 
> 
> Testing
> ---
> 
> Tests are added that check the validate functions added for widget name and 
> description.
> Both widget name and description are tested for:
> 1. all valid characters
> 2. invalid characters
> 3. length of input
> 4. empty string
> 
> Ambari-Web tests with the patch:
> 25671 tests complete (33 seconds)
> 154 tests pending
> 
> 
> File Attachments
> 
> 
> AMBARI-15979-inlineError.patch
>   
> https://reviews.apache.org/media/uploaded/files/2016/04/21/03bc972a-b076-4520-948b-3a204082eca0__AMBARI-15979-inlineError.patch
> AMBARI-15979-topError.patch
>   
> https://reviews.apache.org/media/uploaded/files/2016/04/21/8b4e9a7b-96cb-4a17-9c9c-56e59b5fd349__AMBARI-15979-topError.patch
> 
> 
> Thanks,
> 
> Keta Patel
> 
>

Re: Review Request 46585: Show number of PXFs Live widget on main dashboard

2016-04-25 Thread Lav Jain


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


Ship it!




Ship It!

- Lav Jain


On April 22, 2016, 11:51 p.m., Matt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46585/
> ---
> 
> (Updated April 22, 2016, 11:51 p.m.)
> 
> 
> Review request for Ambari, Alexander Denissov, bhuvnesh chaudhary, Goutam 
> Tadi, jun aoki, and Lav Jain.
> 
> 
> Bugs: AMBARI-16074
> https://issues.apache.org/jira/browse/AMBARI-16074
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Show number of PXFs Live widget on main dashboard
> 
> 
> Diffs
> -
> 
>   ambari-web/app/assets/test/tests.js 33e7f1c 
>   ambari-web/app/mappers/components_state_mapper.js 755c0f5 
>   ambari-web/app/messages.js 907d9ae 
>   ambari-web/app/views.js 6bb2774 
>   ambari-web/app/views/main/dashboard/widgets.js 067607f 
>   ambari-web/app/views/main/dashboard/widgets/hawqsegment_live.js bec98c6 
>   ambari-web/app/views/main/dashboard/widgets/pxf_live.js PRE-CREATION 
>   ambari-web/test/views/main/dashboard/widgets/pxf_live_test.js PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46585/diff/
> 
> 
> Testing
> ---
> 
> Manually Tested
> 
> Added Unit test.
> 
> Unit test Results:
> 
>   27538 tests complete (22 seconds)
>   154 tests pending
>   
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 01:11 min
> [INFO] Finished at: 2016-04-22T16:50:37-07:00
> [INFO] Final Memory: 12M/310M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Matt
> 
>

Review Request 46654: Auth-to-local rule generation duplicates default rules when adding case-insensitive default rules

2016-04-25 Thread Robert Levas


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

Review request for Ambari, Dmitro Lisnichenko, Jonathan Hurley, Laszlo Puskas, 
and Nate Cole.


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


Repository: ambari


Description
---

When re-generating auth-to-local rules where existing rules are already set, 
the default (or fallback) rule for the default and additional realms is 
duplicated but the extra instance(s) have the case-insensitive flag:

Example:
# Was
```
...
RULE:[1:$1@$0](.*@EXAMPLE.COM)s/@.*//
...
```
# Becomes}
```
...
RULE:[1:$1@$0](.*@EXAMPLE.COM)s/@.*//
RULE:[1:$1@$0](.*@EXAMPLE.COM)s/@.*///L
...
```

*Steps to Reproduce*
1. Create cluster with (at least) HDFS
2. Enable Kerberos (do not check the box next to "Enable case insensitive 
username rules"; kerberos-env/case_insensitive_username_rules should be false
3. Edit Kerberos configuration and check "Enable case insensitive username 
rules" to set kerberos-env/case_insensitive_username_rules to true
4. Regenerate Keytabs
5. See duplicate entry in HDFS configs (core-site/hadoop.security.auth_to_local)


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/AuthToLocalBuilder.java
 9d6db0a 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/AuthToLocalBuilderTest.java
 c88acc1 

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


Testing
---

Manually tested

Running org.apache.ambari.server.controller.AuthToLocalBuilderTest
Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec - in 
org.apache.ambari.server.controller.AuthToLocalBuilderTest

Results :

Tests run: 20, Failures: 0, Errors: 0, Skipped: 0

# Local test result: PENDING

# Jenkins test results: PENDING


Thanks,

Robert Levas

Re: Review Request 46653: HBase service check fails on an HA cluster deployed via blueprint

2016-04-25 Thread Andrew Onischuk


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

(Updated April 25, 2016, 6:53 p.m.)


Review request for Ambari and Dmytro Sen.


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


Repository: ambari


Description
---

On an HA cluster deployed via blueprints, HBase service check is failing with
the below error




Traceback (most recent call last):
  File 
"/var/lib/ambari-agent/cache/common-services/HBASE/0.96.0.2.0/package/scripts/service_check.py",
 line 88, in 
HbaseServiceCheck().execute()
  File 
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
 line 219, in execute
method(env)
  File 
"/var/lib/ambari-agent/cache/common-services/HBASE/0.96.0.2.0/package/scripts/service_check.py",
 line 84, in service_check
logoutput = True
  File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
line 154, in __init__
self.env.run()
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
line 160, in run
self.run_action(resource, action)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
line 124, in run_action
provider_action()
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
 line 238, in action_run
tries=self.resource.tries, try_sleep=self.resource.try_sleep)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 70, 
in inner
result = function(command, **kwargs)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 92, 
in checked_call
tries=tries, try_sleep=try_sleep)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 140, 
in _call_wrapper
result = _call(command, **kwargs_copy)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 291, 
in _call
raise Fail(err_msg)
resource_management.core.exceptions.Fail: Execution of ' 
/usr/hdp/current/hbase-client/bin/hbase --config 
/usr/hdp/current/hbase-client/conf shell 
/var/lib/ambari-agent/tmp/hbase-smoke.sh && 
/var/lib/ambari-agent/tmp/hbaseSmokeVerify.sh 
/usr/hdp/current/hbase-client/conf id16ac4252_date492216 
/usr/hdp/current/hbase-client/bin/hbase' returned 1.  Hortonworks 
#
This is MOTD message, added for testing in qe infra
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:/grid/0/hdp/2.4.2.0-244/hadoop/lib/slf4j-log4j12-1.7.10.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:/grid/0/hdp/2.4.2.0-244/zookeeper/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an 
explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]

ERROR: Table ambarismoketest does not exist.

Here is some help for this command:
Start disable of named table:
  hbase> disable 't1'
  hbase> disable 'ns1:t1'



ERROR: Table ambarismoketest does not exist.

Here is some help for this command:
Drop the named table. Table must first be disabled:
  hbase> drop 't1'
  hbase> drop 'ns1:t1'



ERROR: org.apache.hadoop.hbase.security.AccessDeniedException: Insufficient 
permissions for user 'ambari-qa' (action=create)

Here is some help for this command:
Creates a table. Pass a table name, and a set of column family
specifications (at least one), and, optionally, table configuration.
Column specification can be a simple string (name), or a dictionary
(dictionaries are described below in main help output), necessarily 
including NAME attribute. 
Examples:

Create a table with namespace=ns1 and table qualifier=t1
  hbase> create 'ns1:t1', {NAME => 'f1', VERSIONS => 5}

Create a table with namespace=default and table qualifier=t1
  hbase> create 't1', {NAME => 'f1'}, {NAME => 'f2'}, {NAME => 'f3'}
  hbase> # The above in shorthand would be the following:
  hbase> create 't1', 'f1', 'f2', 'f3'
  hbase> create 't1', {NAME => 'f1', VERSIONS => 1, TTL => 2592000, 
BLOCKCACHE => true}
  hbase> create 't1', {NAME => 'f1', CONFIGURATION => 
{'hbase.hstore.blockingStoreFiles' => '10'}}
  
Table configuration options can be put at the end.
Examples:

  hbase> create 'ns1:t1', 'f1', SPLITS => ['10', '20', '30', '40']
  hbase> create 't1', 'f1', SPLITS => ['10', '20', '30', '40']
  hbase> create 't1', 'f1', SPLITS_FILE => 'splits.txt', OWNER => 'johndoe'
  hbase> create 't1', {NAME => 'f1',

Re: Review Request 46653: HBase service check fails on an HA cluster deployed via blueprint

2016-04-25 Thread Mahadev Konar


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


Ship it!




Ship It!

- Mahadev Konar


On April 25, 2016, 6:56 p.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46653/
> ---
> 
> (Updated April 25, 2016, 6:56 p.m.)
> 
> 
> Review request for Ambari, Dmytro Sen and Vitalyi Brodetskyi.
> 
> 
> Bugs: AMBARI-16104
> https://issues.apache.org/jira/browse/AMBARI-16104
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> On an HA cluster deployed via blueprints, HBase service check is failing with
> the below error
> 
> 
> 
> 
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/HBASE/0.96.0.2.0/package/scripts/service_check.py",
>  line 88, in 
> HbaseServiceCheck().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 219, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HBASE/0.96.0.2.0/package/scripts/service_check.py",
>  line 84, in service_check
> logoutput = True
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/base.py", line 
> 154, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 160, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 124, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 238, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 70, in inner
> result = function(command, **kwargs)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 92, in checked_call
> tries=tries, try_sleep=try_sleep)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 291, in _call
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of ' 
> /usr/hdp/current/hbase-client/bin/hbase --config 
> /usr/hdp/current/hbase-client/conf shell 
> /var/lib/ambari-agent/tmp/hbase-smoke.sh && 
> /var/lib/ambari-agent/tmp/hbaseSmokeVerify.sh 
> /usr/hdp/current/hbase-client/conf id16ac4252_date492216 
> /usr/hdp/current/hbase-client/bin/hbase' returned 1.  Hortonworks 
> #
> This is MOTD message, added for testing in qe infra
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in 
> [jar:file:/grid/0/hdp/2.4.2.0-244/hadoop/lib/slf4j-log4j12-1.7.10.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in 
> [jar:file:/grid/0/hdp/2.4.2.0-244/zookeeper/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an 
> explanation.
> SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
> 
> ERROR: Table ambarismoketest does not exist.
> 
> Here is some help for this command:
> Start disable of named table:
>   hbase> disable 't1'
>   hbase> disable 'ns1:t1'
> 
> 
> 
> ERROR: Table ambarismoketest does not exist.
> 
> Here is some help for this command:
> Drop the named table. Table must first be disabled:
>   hbase> drop 't1'
>   hbase> drop 'ns1:t1'
> 
> 
> 
> ERROR: org.apache.hadoop.hbase.security.AccessDeniedException: 
> Insufficient permissions for user 'ambari-qa' (action=create)
> 
> Here is some help for this command:
> Creates a table. Pass a table name, and a set of column family
> specifications (at least one), and, optionally, table configuration.
> Column specification can be a simple string (name), or a dictionary
> (dictionaries are described below in main help output), necessarily 
> including NAME attribute. 
> Examples:
> 
> Create a table with namespace=ns1 and table qualifier=t1
>   hbase> create 'ns1:t1', {NAME => 'f1', VERSIONS => 5}
> 
> Create a table with namespace=default and table qualifier=t1
>   hbase> create 't1', {NAME => 'f1'}, {NAME => 'f2'}, {NAME => 'f3'}
>   hbase> # The above in shorthand would be

Re: Review Request 46653: HBase service check fails on an HA cluster deployed via blueprint

2016-04-25 Thread Mahadev Konar


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


Ship it!




Ship It!

- Mahadev Konar


On April 25, 2016, 6:56 p.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46653/
> ---
> 
> (Updated April 25, 2016, 6:56 p.m.)
> 
> 
> Review request for Ambari, Dmytro Sen and Vitalyi Brodetskyi.
> 
> 
> Bugs: AMBARI-16104
> https://issues.apache.org/jira/browse/AMBARI-16104
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> On an HA cluster deployed via blueprints, HBase service check is failing with
> the below error
> 
> 
> 
> 
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/HBASE/0.96.0.2.0/package/scripts/service_check.py",
>  line 88, in 
> HbaseServiceCheck().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 219, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HBASE/0.96.0.2.0/package/scripts/service_check.py",
>  line 84, in service_check
> logoutput = True
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/base.py", line 
> 154, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 160, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 124, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 238, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 70, in inner
> result = function(command, **kwargs)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 92, in checked_call
> tries=tries, try_sleep=try_sleep)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 291, in _call
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of ' 
> /usr/hdp/current/hbase-client/bin/hbase --config 
> /usr/hdp/current/hbase-client/conf shell 
> /var/lib/ambari-agent/tmp/hbase-smoke.sh && 
> /var/lib/ambari-agent/tmp/hbaseSmokeVerify.sh 
> /usr/hdp/current/hbase-client/conf id16ac4252_date492216 
> /usr/hdp/current/hbase-client/bin/hbase' returned 1.  Hortonworks 
> #
> This is MOTD message, added for testing in qe infra
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in 
> [jar:file:/grid/0/hdp/2.4.2.0-244/hadoop/lib/slf4j-log4j12-1.7.10.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in 
> [jar:file:/grid/0/hdp/2.4.2.0-244/zookeeper/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an 
> explanation.
> SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
> 
> ERROR: Table ambarismoketest does not exist.
> 
> Here is some help for this command:
> Start disable of named table:
>   hbase> disable 't1'
>   hbase> disable 'ns1:t1'
> 
> 
> 
> ERROR: Table ambarismoketest does not exist.
> 
> Here is some help for this command:
> Drop the named table. Table must first be disabled:
>   hbase> drop 't1'
>   hbase> drop 'ns1:t1'
> 
> 
> 
> ERROR: org.apache.hadoop.hbase.security.AccessDeniedException: 
> Insufficient permissions for user 'ambari-qa' (action=create)
> 
> Here is some help for this command:
> Creates a table. Pass a table name, and a set of column family
> specifications (at least one), and, optionally, table configuration.
> Column specification can be a simple string (name), or a dictionary
> (dictionaries are described below in main help output), necessarily 
> including NAME attribute. 
> Examples:
> 
> Create a table with namespace=ns1 and table qualifier=t1
>   hbase> create 'ns1:t1', {NAME => 'f1', VERSIONS => 5}
> 
> Create a table with namespace=default and table qualifier=t1
>   hbase> create 't1', {NAME => 'f1'}, {NAME => 'f2'}, {NAME => 'f3'}
>   hbase> # The above in shorthand would be

Re: Review Request 46653: HBase service check fails on an HA cluster deployed via blueprint

2016-04-25 Thread Vitalyi Brodetskyi


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


Ship it!




Ship It!

- Vitalyi Brodetskyi


On Квітень 25, 2016, 6:53 після полудня, Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46653/
> ---
> 
> (Updated Квітень 25, 2016, 6:53 після полудня)
> 
> 
> Review request for Ambari and Dmytro Sen.
> 
> 
> Bugs: AMBARI-16104
> https://issues.apache.org/jira/browse/AMBARI-16104
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> On an HA cluster deployed via blueprints, HBase service check is failing with
> the below error
> 
> 
> 
> 
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/HBASE/0.96.0.2.0/package/scripts/service_check.py",
>  line 88, in 
> HbaseServiceCheck().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 219, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HBASE/0.96.0.2.0/package/scripts/service_check.py",
>  line 84, in service_check
> logoutput = True
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/base.py", line 
> 154, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 160, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 124, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 238, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 70, in inner
> result = function(command, **kwargs)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 92, in checked_call
> tries=tries, try_sleep=try_sleep)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 291, in _call
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of ' 
> /usr/hdp/current/hbase-client/bin/hbase --config 
> /usr/hdp/current/hbase-client/conf shell 
> /var/lib/ambari-agent/tmp/hbase-smoke.sh && 
> /var/lib/ambari-agent/tmp/hbaseSmokeVerify.sh 
> /usr/hdp/current/hbase-client/conf id16ac4252_date492216 
> /usr/hdp/current/hbase-client/bin/hbase' returned 1.  Hortonworks 
> #
> This is MOTD message, added for testing in qe infra
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in 
> [jar:file:/grid/0/hdp/2.4.2.0-244/hadoop/lib/slf4j-log4j12-1.7.10.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in 
> [jar:file:/grid/0/hdp/2.4.2.0-244/zookeeper/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an 
> explanation.
> SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
> 
> ERROR: Table ambarismoketest does not exist.
> 
> Here is some help for this command:
> Start disable of named table:
>   hbase> disable 't1'
>   hbase> disable 'ns1:t1'
> 
> 
> 
> ERROR: Table ambarismoketest does not exist.
> 
> Here is some help for this command:
> Drop the named table. Table must first be disabled:
>   hbase> drop 't1'
>   hbase> drop 'ns1:t1'
> 
> 
> 
> ERROR: org.apache.hadoop.hbase.security.AccessDeniedException: 
> Insufficient permissions for user 'ambari-qa' (action=create)
> 
> Here is some help for this command:
> Creates a table. Pass a table name, and a set of column family
> specifications (at least one), and, optionally, table configuration.
> Column specification can be a simple string (name), or a dictionary
> (dictionaries are described below in main help output), necessarily 
> including NAME attribute. 
> Examples:
> 
> Create a table with namespace=ns1 and table qualifier=t1
>   hbase> create 'ns1:t1', {NAME => 'f1', VERSIONS => 5}
> 
> Create a table with namespace=default and table qualifier=t1
>   hbase> create 't1', {NAME => 'f1'}, {NAME => 'f2'}, {NAME => 'f3'}
>   hbase> # The above in shorthand

Review Request 46653: HBase service check fails on an HA cluster deployed via blueprint

2016-04-25 Thread Andrew Onischuk


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

Review request for Ambari and Dmytro Sen.


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


Repository: ambari


Description
---

On an HA cluster deployed via blueprints, HBase service check is failing with
the below error




Traceback (most recent call last):
  File 
"/var/lib/ambari-agent/cache/common-services/HBASE/0.96.0.2.0/package/scripts/service_check.py",
 line 88, in 
HbaseServiceCheck().execute()
  File 
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
 line 219, in execute
method(env)
  File 
"/var/lib/ambari-agent/cache/common-services/HBASE/0.96.0.2.0/package/scripts/service_check.py",
 line 84, in service_check
logoutput = True
  File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
line 154, in __init__
self.env.run()
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
line 160, in run
self.run_action(resource, action)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
line 124, in run_action
provider_action()
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
 line 238, in action_run
tries=self.resource.tries, try_sleep=self.resource.try_sleep)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 70, 
in inner
result = function(command, **kwargs)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 92, 
in checked_call
tries=tries, try_sleep=try_sleep)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 140, 
in _call_wrapper
result = _call(command, **kwargs_copy)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 291, 
in _call
raise Fail(err_msg)
resource_management.core.exceptions.Fail: Execution of ' 
/usr/hdp/current/hbase-client/bin/hbase --config 
/usr/hdp/current/hbase-client/conf shell 
/var/lib/ambari-agent/tmp/hbase-smoke.sh && 
/var/lib/ambari-agent/tmp/hbaseSmokeVerify.sh 
/usr/hdp/current/hbase-client/conf id16ac4252_date492216 
/usr/hdp/current/hbase-client/bin/hbase' returned 1.  Hortonworks 
#
This is MOTD message, added for testing in qe infra
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:/grid/0/hdp/2.4.2.0-244/hadoop/lib/slf4j-log4j12-1.7.10.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:/grid/0/hdp/2.4.2.0-244/zookeeper/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an 
explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]

ERROR: Table ambarismoketest does not exist.

Here is some help for this command:
Start disable of named table:
  hbase> disable 't1'
  hbase> disable 'ns1:t1'



ERROR: Table ambarismoketest does not exist.

Here is some help for this command:
Drop the named table. Table must first be disabled:
  hbase> drop 't1'
  hbase> drop 'ns1:t1'



ERROR: org.apache.hadoop.hbase.security.AccessDeniedException: Insufficient 
permissions for user 'ambari-qa' (action=create)

Here is some help for this command:
Creates a table. Pass a table name, and a set of column family
specifications (at least one), and, optionally, table configuration.
Column specification can be a simple string (name), or a dictionary
(dictionaries are described below in main help output), necessarily 
including NAME attribute. 
Examples:

Create a table with namespace=ns1 and table qualifier=t1
  hbase> create 'ns1:t1', {NAME => 'f1', VERSIONS => 5}

Create a table with namespace=default and table qualifier=t1
  hbase> create 't1', {NAME => 'f1'}, {NAME => 'f2'}, {NAME => 'f3'}
  hbase> # The above in shorthand would be the following:
  hbase> create 't1', 'f1', 'f2', 'f3'
  hbase> create 't1', {NAME => 'f1', VERSIONS => 1, TTL => 2592000, 
BLOCKCACHE => true}
  hbase> create 't1', {NAME => 'f1', CONFIGURATION => 
{'hbase.hstore.blockingStoreFiles' => '10'}}
  
Table configuration options can be put at the end.
Examples:

  hbase> create 'ns1:t1', 'f1', SPLITS => ['10', '20', '30', '40']
  hbase> create 't1', 'f1', SPLITS => ['10', '20', '30', '40']
  hbase> create 't1', 'f1', SPLITS_FILE => 'splits.txt', OWNER => 'johndoe'
  hbase> create 't1', {NAME => 'f1', VERSIONS => 5}, METADATA => { 'mykey' 
=>

Review Request 46652: Tez View : Equip the tez view shim to work with both version 1 & 2 of Tez UI

2016-04-25 Thread Sreenath Somarajapuram


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

Review request for Ambari, DIPAYAN BHOWMICK and Pallav Kulshreshtha.


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


Repository: ambari


Description
---

Tez UI 1 would be soon replaced with Tez UI 2, and we need to ensure that the 
Ambari view can work with both versions of the UI.


Diffs
-

  contrib/views/tez/pom.xml 9e626b8 
  contrib/views/tez/src/main/resources/ui/ambari-scripts/init-view.js 
PRE-CREATION 
  contrib/views/tez/src/main/resources/ui/index.html ed0230a 
  contrib/views/tez/src/main/resources/ui/scripts/init-ambari-view.js 25d4da0 

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


Testing
---

Tested manually against Tez UI 1 & 2.


Thanks,

Sreenath Somarajapuram

Re: Review Request 46128: AMBARI-15724 Integrate Version Registration in Select Stack Page

2016-04-25 Thread Richard Zang


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


Ship it!




Ship It!

- Richard Zang


On April 25, 2016, 6:36 p.m., Zhe (Joe) Wang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46128/
> ---
> 
> (Updated April 25, 2016, 6:36 p.m.)
> 
> 
> Review request for Ambari, Jaimin Jetly, Richard Zang, Xi Wang, and Yusaku 
> Sako.
> 
> 
> Bugs: AMBARI-15724
> https://issues.apache.org/jira/browse/AMBARI-15724
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Implement New "Select Stack Page".
> Should have two main options : use local repo & use public repo.
> 
> 
> Diffs
> -
> 
>   
> ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/stackVersions/StackVersionsCreateCtrl.js
>  5596a7f 
>   
> ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/stackVersions/StackVersionsEditCtrl.js
>  3da088b 
>   ambari-admin/src/main/resources/ui/admin-web/app/scripts/i18n.config.js 
> e95ebdb 
>   ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/Stack.js 
> fd3a8ba 
>   ambari-admin/src/main/resources/ui/admin-web/app/styles/main.css edf8524 
>   
> ambari-admin/src/main/resources/ui/admin-web/app/views/stackVersions/stackVersionPage.html
>  8e9d3e2 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProvider.java
>  a78af6e 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProviderTest.java
>  c9fa9a3 
>   ambari-web/app/assets/data/wizard/stack/HDP_version_definitions.json 
> PRE-CREATION 
>   ambari-web/app/controllers/installer.js 73f9801 
>   ambari-web/app/controllers/main/admin/stack_and_upgrade_controller.js 
> a056d3b 
>   ambari-web/app/controllers/main/service/add_controller.js 73abd59 
>   ambari-web/app/controllers/wizard.js f242523 
>   ambari-web/app/controllers/wizard/step1_controller.js c357bf4 
>   ambari-web/app/controllers/wizard/step8_controller.js a5eb949 
>   ambari-web/app/mappers/repository_version_mapper.js 67cfe64 
>   ambari-web/app/mappers/stack_mapper.js 75245e0 
>   ambari-web/app/messages.js 907d9ae 
>   ambari-web/app/models/stack.js 0b1c9d2 
>   ambari-web/app/models/stack_version/repository_version.js e02999f 
>   ambari-web/app/routes/add_service_routes.js ad256f5 
>   ambari-web/app/styles/application.less 890a43c 
>   ambari-web/app/templates/main/admin/stack_upgrade/edit_repositories.hbs 
> 35677ab 
>   ambari-web/app/templates/main/admin/stack_upgrade/services.hbs a87c50c 
>   ambari-web/app/templates/main/admin/stack_upgrade/versions.hbs a9fc440 
>   ambari-web/app/templates/wizard/step1.hbs ab9a0dd 
>   ambari-web/app/templates/wizard/step4.hbs cc4c68f 
>   ambari-web/app/utils/ajax/ajax.js 1cb70c5 
>   ambari-web/app/utils/db.js 865839c 
>   ambari-web/app/views/main/admin/stack_upgrade/services_view.js 8805c47 
>   ambari-web/app/views/main/admin/stack_upgrade/upgrade_version_box_view.js 
> 88bfec2 
>   ambari-web/app/views/wizard/step1_view.js 452e676 
>   ambari-web/test/controllers/installer_test.js 353129b 
>   ambari-web/test/controllers/main/admin/stack_and_upgrade_controller_test.js 
> 00d7ce8 
>   ambari-web/test/controllers/wizard/step8_test.js e93e001 
>   ambari-web/test/mappers/stack_mapper_test.js 0bc0f3c 
>   ambari-web/test/views/main/admin/stack_upgrade/services_view_test.js 
> 9a42c42 
>   ambari-web/test/views/wizard/step1_view_test.js 0dacad8 
> 
> Diff: https://reviews.apache.org/r/46128/diff/
> 
> 
> Testing
> ---
> 
> Add and modified test cases.
> ambari-web:
> 27544 tests complete (24 seconds)
> 154 tests pending
> ambari-admin:
> Executed 64 of 64 SUCCESS (0.086 secs / 0.308 secs)
> Manual testing done.
> 
> 
> Thanks,
> 
> Zhe (Joe) Wang
> 
>

Review Request 46651: AMBARI-16102: Inconsistency between grid and list view of roles page

2016-04-25 Thread Richard Zang


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

Review request for Ambari and Zhe (Joe) Wang.


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


Repository: ambari


Description
---

In the grid view, a user can be assigned more than one role just by typing the 
user name in 2 different role fields. But in list view you see/can choose only 
one role.
Attached : Screenshots.
The RMP suggested that the UI must allow just one role per user. We should add 
a check while adding users to roles in the grid view to check that a user is 
assigned only one role


Diffs
-

  ambari-admin/src/main/resources/ui/admin-web/app/scripts/i18n.config.js 
e95ebdb 
  
ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/PermissionsSaver.js
 6560f51 

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


Testing
---

Manually tested on live cluster.


Thanks,

Richard Zang

Re: Review Request 46128: AMBARI-15724 Integrate Version Registration in Select Stack Page


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

(Updated April 25, 2016, 6:36 p.m.)


Review request for Ambari, Jaimin Jetly, Richard Zang, Xi Wang, and Yusaku Sako.


Summary (updated)
-

AMBARI-15724 Integrate Version Registration in Select Stack Page


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


Repository: ambari


Description (updated)
---

Implement New "Select Stack Page".
Should have two main options : use local repo & use public repo.


Diffs (updated)
-

  
ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/stackVersions/StackVersionsCreateCtrl.js
 5596a7f 
  
ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/stackVersions/StackVersionsEditCtrl.js
 3da088b 
  ambari-admin/src/main/resources/ui/admin-web/app/scripts/i18n.config.js 
e95ebdb 
  ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/Stack.js 
fd3a8ba 
  ambari-admin/src/main/resources/ui/admin-web/app/styles/main.css edf8524 
  
ambari-admin/src/main/resources/ui/admin-web/app/views/stackVersions/stackVersionPage.html
 8e9d3e2 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProvider.java
 a78af6e 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProviderTest.java
 c9fa9a3 
  ambari-web/app/assets/data/wizard/stack/HDP_version_definitions.json 
PRE-CREATION 
  ambari-web/app/controllers/installer.js 73f9801 
  ambari-web/app/controllers/main/admin/stack_and_upgrade_controller.js a056d3b 
  ambari-web/app/controllers/main/service/add_controller.js 73abd59 
  ambari-web/app/controllers/wizard.js f242523 
  ambari-web/app/controllers/wizard/step1_controller.js c357bf4 
  ambari-web/app/controllers/wizard/step8_controller.js a5eb949 
  ambari-web/app/mappers/repository_version_mapper.js 67cfe64 
  ambari-web/app/mappers/stack_mapper.js 75245e0 
  ambari-web/app/messages.js 907d9ae 
  ambari-web/app/models/stack.js 0b1c9d2 
  ambari-web/app/models/stack_version/repository_version.js e02999f 
  ambari-web/app/routes/add_service_routes.js ad256f5 
  ambari-web/app/styles/application.less 890a43c 
  ambari-web/app/templates/main/admin/stack_upgrade/edit_repositories.hbs 
35677ab 
  ambari-web/app/templates/main/admin/stack_upgrade/services.hbs a87c50c 
  ambari-web/app/templates/main/admin/stack_upgrade/versions.hbs a9fc440 
  ambari-web/app/templates/wizard/step1.hbs ab9a0dd 
  ambari-web/app/templates/wizard/step4.hbs cc4c68f 
  ambari-web/app/utils/ajax/ajax.js 1cb70c5 
  ambari-web/app/utils/db.js 865839c 
  ambari-web/app/views/main/admin/stack_upgrade/services_view.js 8805c47 
  ambari-web/app/views/main/admin/stack_upgrade/upgrade_version_box_view.js 
88bfec2 
  ambari-web/app/views/wizard/step1_view.js 452e676 
  ambari-web/test/controllers/installer_test.js 353129b 
  ambari-web/test/controllers/main/admin/stack_and_upgrade_controller_test.js 
00d7ce8 
  ambari-web/test/controllers/wizard/step8_test.js e93e001 
  ambari-web/test/mappers/stack_mapper_test.js 0bc0f3c 
  ambari-web/test/views/main/admin/stack_upgrade/services_view_test.js 9a42c42 
  ambari-web/test/views/wizard/step1_view_test.js 0dacad8 

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


Testing (updated)
---

Add and modified test cases.
ambari-web:
27544 tests complete (24 seconds)
154 tests pending
ambari-admin:
Executed 64 of 64 SUCCESS (0.086 secs / 0.308 secs)
Manual testing done.


Thanks,

Zhe (Joe) Wang

Re: Review Request 46475: Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.

2016-04-25 Thread Di Li


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


Ship it!




Ship It!

- Di Li


On April 25, 2016, 4:37 p.m., Keta Patel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46475/
> ---
> 
> (Updated April 25, 2016, 4:37 p.m.)
> 
> 
> Review request for Ambari, Andrii Tkach and Di Li.
> 
> 
> Bugs: AMBARI-15979
> https://issues.apache.org/jira/browse/AMBARI-15979
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> ISSUE:
> The UI validation at present checks only the length of the user input for 
> widget_name and description fields. All characters are allowed to be stored 
> in the database through them. A more strict UI validation that limits the 
> type of characters entered for these fields will provide a good first line of 
> defense. 
> 
> Steps to reproduce:
> 1. Make sure you have Ambari Metrics service installed on your cluster.
> 2. On the Dashboard, select any service that makes use of Ambari Metrics, say 
> HDFS.
> 3. In the "Metrics" section, click the "Actions" button in the top-right 
> corner, and select "Create a new widget" option from the drop-down. 
> (attachment: create_widget_button_location.tiff)
> 4. Create widget pop-up is displayed. 
> 5. On Step-1, select any type for the widget and click "Next". (attachment: 
> create_widget_step1.tiff)
> 6. On Step-2, select any valid metrics parameter and click "Next". 
> (attachment: create_widget_step2.tiff)
> 7. On Step-3, for widget_name and description fields, you can enter any 
> character. No validation is present to check the contents. The only 
> validation present checks the length of the input text. 
> (attachments:
> create_widget_step3.tiff, 
> original_characters_allowed_for_name_and_description.tiff,
> original_length_validation_for_name.tiff,
> original_length_validation_for_description.tiff )
> 
> 
> FIX:
> The UI validation is enhanced by checking the content of the input for name 
> and description.
> The patch attached allows only alphanumeric, underscore, hyphen, space and 
> percentage symbol to be valid characters for both fields.
> The % symbol is added as part of the white-list as there are existing widgets 
> that contain % symbols in their names. In order to keep the characters in the 
> name consistent, this was decided.
> The description could probably have a little more flexibility in terms of 
> characters allowed. Any suggestions to update this validation would be 
> helpful.
> The warning message template is also updated to conform to the existing norms 
> used in several Ambari pop-ups (e.g. Manage Config Groups, Manage Alert 
> Groups).
> 
> The images attached (starting with "fixed_") show how the fix appears with 
> the patch.
> 
> 
> Diffs
> -
> 
>   ambari-web/app/controllers/main/service/widgets/create/step3_controller.js 
> dd7a93f 
>   ambari-web/app/messages.js 907d9ae 
>   ambari-web/app/templates/main/service/widgets/create/step3.hbs 9f431af 
>   
> ambari-web/test/controllers/main/service/widgets/create/step3_controller_test.js
>  6f92142 
> 
> Diff: https://reviews.apache.org/r/46475/diff/
> 
> 
> Testing
> ---
> 
> Tests are added that check the validate functions added for widget name and 
> description.
> Both widget name and description are tested for:
> 1. all valid characters
> 2. invalid characters
> 3. length of input
> 4. empty string
> 
> Ambari-Web tests with the patch:
> 25671 tests complete (33 seconds)
> 154 tests pending
> 
> 
> File Attachments
> 
> 
> AMBARI-15979-inlineError.patch
>   
> https://reviews.apache.org/media/uploaded/files/2016/04/21/03bc972a-b076-4520-948b-3a204082eca0__AMBARI-15979-inlineError.patch
> AMBARI-15979-topError.patch
>   
> https://reviews.apache.org/media/uploaded/files/2016/04/21/8b4e9a7b-96cb-4a17-9c9c-56e59b5fd349__AMBARI-15979-topError.patch
> 
> 
> Thanks,
> 
> Keta Patel
> 
>

Review Request 46649: Upgrade catalog 220 in not idempotent again

2016-04-25 Thread Dmytro Sen


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

Review request for Ambari, Andrew Onischuk, Dmitro Lisnichenko, and Vitalyi 
Brodetskyi.


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


Repository: ambari


Description
---

UpgradeCatalog220#updateKerberosDescriptorArtifact
KerberosIdentityDescriptor hdfsIdentity = 
hdfsService.getIdentity("hdfs");
KerberosComponentDescriptor namenodeComponent = 
hdfsService.getComponent("NAMENODE");
hdfsIdentity.setName("hdfs");
hdfsService.removeIdentity("hdfs");
in case of second run on same database we will have here NPE, coz that 
descriptor was already removed. Before using him, we need check that descriptor 
is present and is not null


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog220.java
 0eef4f1 
  
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog220Test.java
 99cabfa 

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


Testing
---

Unit tests passed


Thanks,

Dmytro Sen

Re: Review Request 46648: Add show_available property to dry_run directive



> On April 25, 2016, 5:51 p.m., Zhe (Joe) Wang wrote:
> > Ship It!

Works as FE expects.


- Zhe (Joe)


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


On April 25, 2016, 5:50 p.m., Nate Cole wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46648/
> ---
> 
> (Updated April 25, 2016, 5:50 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Jonathan Hurley.
> 
> 
> Bugs: AMBARI-16096
> https://issues.apache.org/jira/browse/AMBARI-16096
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When POSTing with dry_run=true, and the POST is for a publicly available VDF, 
> then return the show_available property in the response.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProvider.java
>  a78af6e 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProviderTest.java
>  c9fa9a3 
> 
> Diff: https://reviews.apache.org/r/46648/diff/
> 
> 
> Testing
> ---
> 
> Manual.  Automated:
> 
> Tests run: 4257, Failures: 0, Errors: 0, Skipped: 32
> 
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 40:18.070s
> [INFO] Finished at: Mon Apr 25 13:48:39 EDT 2016
> [INFO] Final Memory: 35M/590M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Nate Cole
> 
>

Re: Review Request 46648: Add show_available property to dry_run directive


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


Ship it!




Ship It!

- Zhe (Joe) Wang


On April 25, 2016, 5:50 p.m., Nate Cole wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46648/
> ---
> 
> (Updated April 25, 2016, 5:50 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Jonathan Hurley.
> 
> 
> Bugs: AMBARI-16096
> https://issues.apache.org/jira/browse/AMBARI-16096
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When POSTing with dry_run=true, and the POST is for a publicly available VDF, 
> then return the show_available property in the response.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProvider.java
>  a78af6e 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProviderTest.java
>  c9fa9a3 
> 
> Diff: https://reviews.apache.org/r/46648/diff/
> 
> 
> Testing
> ---
> 
> Manual.  Automated:
> 
> Tests run: 4257, Failures: 0, Errors: 0, Skipped: 32
> 
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 40:18.070s
> [INFO] Finished at: Mon Apr 25 13:48:39 EDT 2016
> [INFO] Final Memory: 35M/590M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Nate Cole
> 
>

Review Request 46648: Add show_available property to dry_run directive


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

Review request for Ambari, Alejandro Fernandez and Jonathan Hurley.


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


Repository: ambari


Description
---

When POSTing with dry_run=true, and the POST is for a publicly available VDF, 
then return the show_available property in the response.


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProvider.java
 a78af6e 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProviderTest.java
 c9fa9a3 

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


Testing
---

Manual.  Automated:

Tests run: 4257, Failures: 0, Errors: 0, Skipped: 32

[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 40:18.070s
[INFO] Finished at: Mon Apr 25 13:48:39 EDT 2016
[INFO] Final Memory: 35M/590M
[INFO] 


Thanks,

Nate Cole

Re: Review Request 44210: AMBARI-15226 - The stack advisor should be pushed down to the services

2016-04-25 Thread Tim Thorpe



> On April 22, 2016, 11:19 p.m., Matt wrote:
> > ambari-server/src/main/resources/common-services/HAWQ/2.0.0/service_advisor.py,
> >  line 44
> > 
> >
> > *return componentName in ('HAWQMASTER', 'HAWQSTANDBY')*

That works better, think I just copied and pasted it from a different method.


- Tim


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


On April 22, 2016, 6:27 p.m., Tim Thorpe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44210/
> ---
> 
> (Updated April 22, 2016, 6:27 p.m.)
> 
> 
> Review request for Ambari, Alexander Denissov, bhuvnesh chaudhary, Jayush 
> Luniya, Oleksandr Diachenko, Sumit Mohanty, Srimanth Gunturi, and Yusaku Sako.
> 
> 
> Bugs: AMBARI-15226
> https://issues.apache.org/jira/browse/AMBARI-15226
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Currently the stack advisor is defined under each stack version such as 
> HDP/2.3. The problem with this is that it restricts the services that can be 
> added to the stack. If a custom service is to be added, they would need to 
> modify the stack advisor. If the configuration recommendation and validation 
> can be done at the service level then the custom service could just include 
> their own recommendations and validations separately.
> 
> 
> Diffs
> -
> 
>   ambari-server/src/main/assemblies/server.xml e1a4919 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/services/AmbariMetaInfo.java
>  df65010 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/services/stackadvisor/commands/StackAdvisorCommand.java
>  00c8696 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/StackServiceResponse.java
>  ca1968e 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StackServiceResourceProvider.java
>  6c6fa91 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/CommonServiceDirectory.java
>  636de37 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/ServiceDirectory.java
>  d574d60 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/ServiceModule.java 
> b7e09a9 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/StackServiceDirectory.java
>  d27e52a 
>   ambari-server/src/main/java/org/apache/ambari/server/state/ServiceInfo.java 
> db95fec 
>   
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/service_advisor.py
>  PRE-CREATION 
>   
> ambari-server/src/main/resources/common-services/PXF/3.0.0/service_advisor.py 
> PRE-CREATION 
>   ambari-server/src/main/resources/properties.json eac0dbd 
>   ambari-server/src/main/resources/stacks/HDP/2.0.6/services/stack_advisor.py 
> 0130483 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py 
> 3a65541 
>   ambari-server/src/main/resources/stacks/service_advisor.py PRE-CREATION 
>   ambari-server/src/main/resources/stacks/stack_advisor.py 539bd25 
>   ambari-server/src/test/python/stacks/2.3/common/test_stack_advisor.py 
> 6c9fd46 
> 
> Diff: https://reviews.apache.org/r/44210/diff/
> 
> 
> Testing
> ---
> 
> Ran all the non java unit tests.  
> 
> Total run:945
> Total errors:0
> Total failures:0
> 
> Manually configured HAWQ and PXF as part of the HDP 2.3 stack and made sure 
> their service advisors were called.
> 
> 
> Thanks,
> 
> Tim Thorpe
> 
>

Re: Review Request 46484: Enhance Health Check for the Cluster before upgrading.


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


Ship it!




Ship It!

- Nate Cole


On April 25, 2016, 10:43 a.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46484/
> ---
> 
> (Updated April 25, 2016, 10:43 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Dmytro Grinenko, Jonathan 
> Hurley, and Nate Cole.
> 
> 
> Bugs: AMBARI-16005
> https://issues.apache.org/jira/browse/AMBARI-16005
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Enhance Health Check for the Cluster before upgrading.
> 
> * check for alerts (perhaps don't start RU/EU if any blocker alerts).
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/checks/CheckDescription.java
>  4967834 
>   
> ambari-server/src/main/java/org/apache/ambari/server/checks/HealthCheck.java 
> PRE-CREATION 
>   
> ambari-server/src/test/java/org/apache/ambari/server/checks/HealthCheckTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46484/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Re: Review Request 46600: AMBARI-16078. HiveServerInteractive. Config calculations used by LLAP app. and fixes for AMBARI-16079, AMBARI-16086, AMBARI-16087

2016-04-25 Thread Alejandro Fernandez


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


Ship it!




Ship It!

- Alejandro Fernandez


On April 25, 2016, 10:07 a.m., Swapan Shridhar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46600/
> ---
> 
> (Updated April 25, 2016, 10:07 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16078, AMBARI-16079, AMBARI-16086, and AMBARI-16087
> https://issues.apache.org/jira/browse/AMBARI-16078
> https://issues.apache.org/jira/browse/AMBARI-16079
> https://issues.apache.org/jira/browse/AMBARI-16086
> https://issues.apache.org/jira/browse/AMBARI-16087
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Fix for : 
>   (1). AMBARI-16078. Config calculations used by LLAP app. 
>   
>   Trivial fixes for :
>   
>(2). AMBARI-16079. waiting for fixed number of times if the launched LLAP 
> app is in LAUNCHING state, for it to go to RUNNING_ALL or RUNNING_PARTIAL
>   (3). AMBARI-16086. Hide HSI related sliders when 'llap' queue is not being 
> used.
>   (4). AMBARI-16087. LLAP queue is not selected when enabling Hive 
> Interactive Query during Install Wizard
> 
> AMBARI-16078:
> 
> - Calculated in Stack advisor code whenever : LLAP queue is in selection and 
> (1). HSI is enabled or (2). change done to slider HSI slider "% of Cluster 
> Capacity" , or (3). change done to slider HSI slider 'Number of Daemon 
> Instances'
> - 
> - caluclations are not done if the overall cluster state is not conduciv for 
> meaningful run of LLAP.
> 
> AMBARI-16079: 
> =
> 
> Reason : If the LLAP app state is LAUNCHING and we go ahead with HSI start, 
> the overall workability of app may not be ascertained.
> As of now, using llap0 name, app does go into RUNNING_ALL state.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_interactive.py
>  f548ea3 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
>  a044fda 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-env.xml
>  816e207 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-site.xml
>  21d1109 
>   ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
> 4da21fa 
>   ambari-server/src/test/python/stacks/2.5/HIVE/test_hive_server_int.py 
> 44759a9 
>   ambari-server/src/test/python/stacks/2.5/common/test_stack_advisor.py 
> 3934301 
>   ambari-server/src/test/python/stacks/2.5/configs/hsi_default.json 1cb2a02 
> 
> Diff: https://reviews.apache.org/r/46600/diff/
> 
> 
> Testing
> ---
> 
> - Python tests added.
> - Python UT passes.
> 
> 
> --
> Ran 261 tests in 7.091s
> 
> OK
> --
> Total run:995
> Total errors:0
> Total failures:0
> OK
> 
> 
> Thanks,
> 
> Swapan Shridhar
> 
>

Re: Review Request 46484: Enhance Health Check for the Cluster before upgrading.

2016-04-25 Thread Alejandro Fernandez


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


Ship it!




Ship It!

- Alejandro Fernandez


On April 25, 2016, 2:43 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46484/
> ---
> 
> (Updated April 25, 2016, 2:43 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Dmytro Grinenko, Jonathan 
> Hurley, and Nate Cole.
> 
> 
> Bugs: AMBARI-16005
> https://issues.apache.org/jira/browse/AMBARI-16005
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Enhance Health Check for the Cluster before upgrading.
> 
> * check for alerts (perhaps don't start RU/EU if any blocker alerts).
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/checks/CheckDescription.java
>  4967834 
>   
> ambari-server/src/main/java/org/apache/ambari/server/checks/HealthCheck.java 
> PRE-CREATION 
>   
> ambari-server/src/test/java/org/apache/ambari/server/checks/HealthCheckTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46484/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Re: Review Request 46398: Name in create Alert Notification should be restricted to use only alphanumerics, hyphens, spaces and underscores

2016-04-25 Thread Anita Jebaraj



> On April 20, 2016, 9:46 a.m., Alexandr Antonenko wrote:
> > Ship It!

Can you please push the code to trunk, I don't have the priviledge for that.


- Anita


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


On April 19, 2016, 6:20 p.m., Anita Jebaraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46398/
> ---
> 
> (Updated April 19, 2016, 6:20 p.m.)
> 
> 
> Review request for Ambari, Alexandr Antonenko and Di Li.
> 
> 
> Bugs: ambari-15869
> https://issues.apache.org/jira/browse/ambari-15869
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Click Alerts at the top
> The Click Actions -> select Manage Notifications
> Click on the + icon, the create Alert notification pop up will be displayed.
> Currently the notification name allows all characters, it should be 
> restricted to allow only alphanumberics, spaces, hyphens and underscores.
> 
> 
> Diffs
> -
> 
>   
> ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js
>  7dd7dea 
>   ambari-web/app/messages.js 3ede13a 
>   ambari-web/app/utils/validator.js 6426163 
>   
> ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
>  837c2f3 
> 
> Diff: https://reviews.apache.org/r/46398/diff/
> 
> 
> Testing
> ---
> 
> Ran mvn clean test 
>   25660 tests complete (29 seconds)
>   154 tests pending
> 
> 
> Thanks,
> 
> Anita Jebaraj
> 
>

Re: Review Request 46619: AMBARI-16085 : Modify Ambari stacks for Ranger (for enabling plugins) to use service keytab for creating repositories and policies


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




ambari-common/src/main/python/resource_management/libraries/functions/ranger_functions_v2.py
 (lines 153 - 155)


This is a really long time... the method will block for up to 2.5 minutes?



ambari-common/src/main/python/resource_management/libraries/functions/ranger_functions_v2.py
 (lines 311 - 312)


Does this mean retry 75 times with 8 seconds in between?  That would be 
excessively high.


- Nate Cole


On April 25, 2016, 10:12 a.m., Gautam Borad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46619/
> ---
> 
> (Updated April 25, 2016, 10:12 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jaimin Jetly, Mahadev Konar, 
> Nate Cole, Robert Levas, Sumit Mohanty, and Velmurugan Periasamy.
> 
> 
> Bugs: AMBARI-16085
> https://issues.apache.org/jira/browse/AMBARI-16085
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> **Problem Statement**
> In order to allow Ranger plugins to support Kerberos Authentication, make 
> changes in Ranger plugin stacks to create ranger services and policies using 
> component principal / keytab. Also take care of config changes to support 
> plugin communication in Kerberos enabled env.
> 
> **Proposed Solution**
> Update Ranger repository creation calls to use component principal/keytab as 
> well as update config parameters to support Ranger plugin communication.
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/curl_krb_request.py
>  cf0d5a6 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/ranger_functions_v2.py
>  3bb0103 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/setup_ranger_plugin_xml.py
>  a7faf3b 
>   
> ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/params_linux.py
>  2c466ea 
>   
> ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/setup_ranger_hbase.py
>  ffd0715 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/params_linux.py
>  e6fd32c 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/setup_ranger_hdfs.py
>  858044c 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
>  a044fda 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/setup_ranger_hive.py
>  f51dbab 
>   
> ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/package/scripts/params.py
>  d4ee6f9 
>   
> ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/package/scripts/setup_ranger_kafka.py
>  a99dc76 
>   
> ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/params_linux.py
>  d572aff 
>   
> ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/setup_ranger_knox.py
>  13987c8 
>   
> ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/params.py
>  bcbab42 
>   
> ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/params_linux.py
>  3f9b936 
>   
> ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/setup_ranger_storm.py
>  bef1f02 
>   
> ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/params_linux.py
>  8fbefb2 
>   
> ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/setup_ranger_yarn.py
>  21fe8e1 
> 
> Diff: https://reviews.apache.org/r/46619/diff/
> 
> 
> Testing
> ---
> 
> **Verified**
> Added Ranger in a Kerberos enabled environment and verified enable of plugin 
> for supported components.
> 
> 
> Thanks,
> 
> Gautam Borad
> 
>

Re: Review Request 46585: Show number of PXFs Live widget on main dashboard

2016-04-25 Thread Goutam Tadi


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


Ship it!




Ship It!

- Goutam Tadi


On April 22, 2016, 11:51 p.m., Matt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46585/
> ---
> 
> (Updated April 22, 2016, 11:51 p.m.)
> 
> 
> Review request for Ambari, Alexander Denissov, bhuvnesh chaudhary, Goutam 
> Tadi, jun aoki, and Lav Jain.
> 
> 
> Bugs: AMBARI-16074
> https://issues.apache.org/jira/browse/AMBARI-16074
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Show number of PXFs Live widget on main dashboard
> 
> 
> Diffs
> -
> 
>   ambari-web/app/assets/test/tests.js 33e7f1c 
>   ambari-web/app/mappers/components_state_mapper.js 755c0f5 
>   ambari-web/app/messages.js 907d9ae 
>   ambari-web/app/views.js 6bb2774 
>   ambari-web/app/views/main/dashboard/widgets.js 067607f 
>   ambari-web/app/views/main/dashboard/widgets/hawqsegment_live.js bec98c6 
>   ambari-web/app/views/main/dashboard/widgets/pxf_live.js PRE-CREATION 
>   ambari-web/test/views/main/dashboard/widgets/pxf_live_test.js PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46585/diff/
> 
> 
> Testing
> ---
> 
> Manually Tested
> 
> Added Unit test.
> 
> Unit test Results:
> 
>   27538 tests complete (22 seconds)
>   154 tests pending
>   
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 01:11 min
> [INFO] Finished at: 2016-04-22T16:50:37-07:00
> [INFO] Final Memory: 12M/310M
> [INFO] 
> 
> 
> 
> Thanks,
> 
> Matt
> 
>

Re: Review Request 46614: [RU] Hbase is losing table access permissions during upgrade.

2016-04-25 Thread Mahadev Konar


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


Ship it!




Ship It!

- Mahadev Konar


On April 25, 2016, 2:32 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46614/
> ---
> 
> (Updated April 25, 2016, 2:32 p.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Nate Cole, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: AMBARI-16084
> https://issues.apache.org/jira/browse/AMBARI-16084
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> So here's where we are:
> 
> - https://reviews.apache.org/r/45890/diff/2#index_header removed hard-coded 
> python code which was trying to figure out which coprocessor to use. With 
> these values gone, it's now up to Ambari to set the _right_ value in the 
> configurations.
> 
> - However, after removing the above code, we never change the ranger 
> configurations to reflect the proper value
> 
> - To fix this, we need to fix the values on Ambari upgrade. When upgrading 
> Ambari from 2.0, we'll need to do the following:
> -- If Ranger is disabled; do nothing
> -- If Ranger is enabled and the cluster's current stack is HDP 2.2, then set 
> the master/region coprocessors to
> {code}
> hbase_coprocessor_master_classes = 
> "com.xasecure.authorization.hbase.XaSecureAuthorizationCoprocessor"
> hbase_coprocessor_regionserver_classes = 
> "com.xasecure.authorization.hbase.XaSecureAuthorizationCoprocessor"
> hbase_coprocessor_region_classes = 
> "org.apache.hadoop.hbase.security.token.TokenProvider,org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint,com.xasecure.authorization.hbase.XaSecureAuthorizationCoprocessor"
> {code}
> -- If Ranger is enabled and the cluster's current stack is HDP 2.3, then set 
> the master/region coprocessors to
> {code}
> hbase_coprocessor_master_classes = 
> "org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor "
> hbase_coprocessor_regionserver_classes = 
> "org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor"
> hbase_coprocessor_region_classes = 
> "org.apache.hadoop.hbase.security.token.TokenProvider,org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint,org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor"
> {code}
> 
> Now HDP stack upgrades will work since we look for 
> {{XaSecureAuthorizationCoprocessor}} and change it to 
> {{RangerAuthorizationCoprocessor}} as needed.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/AbstractUpgradeCatalog.java
>  b7665ce 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog220.java
>  0738d70 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog222.java
>  31a3ce5 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog222Test.java
>  4302349 
> 
> Diff: https://reviews.apache.org/r/46614/diff/
> 
> 
> Testing
> ---
> 
> ran unit tests
> 
> Checked ambari upgrade on live cluster. Could not perform EU because Hbase 
> Regionserver started to fail after enabling Ranger HBASE Plugin
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Re: Review Request 46475: Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.

2016-04-25 Thread Keta Patel



> On April 22, 2016, 7:07 p.m., Di Li wrote:
> > ambari-web/app/messages.js, line 2842
> > 
> >
> > Message as "Invalid widget name. Only alphanumerics, underscores, 
> > hyphens, percentage and spaces are allowed."

Hello Di,
I have upadted the patch "AMBARI-15979-April-25.patch" accordingly.


> On April 22, 2016, 7:07 p.m., Di Li wrote:
> > ambari-web/app/messages.js, line 2844
> > 
> >
> > Message as "Invalid input. Only alphanumerics, underscores, hyphens, 
> > percentage and spaces are allowed."

Hello Di,
I have upadted the patch "AMBARI-15979-April-25.patch" accordingly.


- Keta


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


On April 25, 2016, 4:37 p.m., Keta Patel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46475/
> ---
> 
> (Updated April 25, 2016, 4:37 p.m.)
> 
> 
> Review request for Ambari, Andrii Tkach and Di Li.
> 
> 
> Bugs: AMBARI-15979
> https://issues.apache.org/jira/browse/AMBARI-15979
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> ISSUE:
> The UI validation at present checks only the length of the user input for 
> widget_name and description fields. All characters are allowed to be stored 
> in the database through them. A more strict UI validation that limits the 
> type of characters entered for these fields will provide a good first line of 
> defense. 
> 
> Steps to reproduce:
> 1. Make sure you have Ambari Metrics service installed on your cluster.
> 2. On the Dashboard, select any service that makes use of Ambari Metrics, say 
> HDFS.
> 3. In the "Metrics" section, click the "Actions" button in the top-right 
> corner, and select "Create a new widget" option from the drop-down. 
> (attachment: create_widget_button_location.tiff)
> 4. Create widget pop-up is displayed. 
> 5. On Step-1, select any type for the widget and click "Next". (attachment: 
> create_widget_step1.tiff)
> 6. On Step-2, select any valid metrics parameter and click "Next". 
> (attachment: create_widget_step2.tiff)
> 7. On Step-3, for widget_name and description fields, you can enter any 
> character. No validation is present to check the contents. The only 
> validation present checks the length of the input text. 
> (attachments:
> create_widget_step3.tiff, 
> original_characters_allowed_for_name_and_description.tiff,
> original_length_validation_for_name.tiff,
> original_length_validation_for_description.tiff )
> 
> 
> FIX:
> The UI validation is enhanced by checking the content of the input for name 
> and description.
> The patch attached allows only alphanumeric, underscore, hyphen, space and 
> percentage symbol to be valid characters for both fields.
> The % symbol is added as part of the white-list as there are existing widgets 
> that contain % symbols in their names. In order to keep the characters in the 
> name consistent, this was decided.
> The description could probably have a little more flexibility in terms of 
> characters allowed. Any suggestions to update this validation would be 
> helpful.
> The warning message template is also updated to conform to the existing norms 
> used in several Ambari pop-ups (e.g. Manage Config Groups, Manage Alert 
> Groups).
> 
> The images attached (starting with "fixed_") show how the fix appears with 
> the patch.
> 
> 
> Diffs
> -
> 
>   ambari-web/app/controllers/main/service/widgets/create/step3_controller.js 
> dd7a93f 
>   ambari-web/app/messages.js 907d9ae 
>   ambari-web/app/templates/main/service/widgets/create/step3.hbs 9f431af 
>   
> ambari-web/test/controllers/main/service/widgets/create/step3_controller_test.js
>  6f92142 
> 
> Diff: https://reviews.apache.org/r/46475/diff/
> 
> 
> Testing
> ---
> 
> Tests are added that check the validate functions added for widget name and 
> description.
> Both widget name and description are tested for:
> 1. all valid characters
> 2. invalid characters
> 3. length of input
> 4. empty string
> 
> Ambari-Web tests with the patch:
> 25671 tests complete (33 seconds)
> 154 tests pending
> 
> 
> File Attachments
> 
> 
> AMBARI-15979-inlineError.patch
>   
> https://reviews.apache.org/media/uploaded/files/2016/04/21/03bc972a-b076-4520-948b-3a204082eca0__AMBARI-15979-inlineError.patch
> AMBARI-15979-topError.patch
>   
> https://reviews.apache.org/media/uploaded/files/2016/04/21/8b4e9a7b-96cb-4a17-9c9c-56e59b5fd349__AMBARI-15979-topError.patch
> 
> 
> Thanks,
> 
> Keta Patel
> 
>

Re: Review Request 46475: Provide UI validation for widget_name and description fields in Create/Edit Widget pop-up.

2016-04-25 Thread Keta Patel

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

(Updated April 25, 2016, 4:37 p.m.)

Review request for Ambari, Andrii Tkach and Di Li.

Changes
---

Updated patch after making changes from Di's suggestions.
Ambari-web tests after applying patch:
27509 tests complete (34 seconds)
154 tests pending

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

Repository: ambari

Description
---

ISSUE:
The UI validation at present checks only the length of the user input for
widget_name and description fields. All characters are allowed to be stored in
the database through them. A more strict UI validation that limits the type of
characters entered for these fields will provide a good first line of defense.

Steps to reproduce:
1. Make sure you have Ambari Metrics service installed on your cluster.
2. On the Dashboard, select any service that makes use of Ambari Metrics, say
HDFS.
3. In the "Metrics" section, click the "Actions" button in the top-right
corner, and select "Create a new widget" option from the drop-down.
(attachment: create_widget_button_location.tiff)
4. Create widget pop-up is displayed.
5. On Step-1, select any type for the widget and click "Next". (attachment:
create_widget_step1.tiff)
6. On Step-2, select any valid metrics parameter and click "Next". (attachment:
create_widget_step2.tiff)
7. On Step-3, for widget_name and description fields, you can enter any
character. No validation is present to check the contents. The only validation
present checks the length of the input text.
(attachments:
create_widget_step3.tiff,
original_characters_allowed_for_name_and_description.tiff,
original_length_validation_for_name.tiff,
original_length_validation_for_description.tiff )

FIX:
The UI validation is enhanced by checking the content of the input for name and
description.
The patch attached allows only alphanumeric, underscore, hyphen, space and
percentage symbol to be valid characters for both fields.
The % symbol is added as part of the white-list as there are existing widgets
that contain % symbols in their names. In order to keep the characters in the
name consistent, this was decided.
The description could probably have a little more flexibility in terms of
characters allowed. Any suggestions to update this validation would be helpful.
The warning message template is also updated to conform to the existing norms
used in several Ambari pop-ups (e.g. Manage Config Groups, Manage Alert Groups).

The images attached (starting with "fixed_") show how the fix appears with the
patch.

Diffs (updated)
-

ambari-web/app/controllers/main/service/widgets/create/step3_controller.js
dd7a93f
ambari-web/app/messages.js 907d9ae
ambari-web/app/templates/main/service/widgets/create/step3.hbs 9f431af

ambari-web/test/controllers/main/service/widgets/create/step3_controller_test.js
6f92142

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

Testing
---

Tests are added that check the validate functions added for widget name and
description.
Both widget name and description are tested for:
1. all valid characters
2. invalid characters
3. length of input
4. empty string

Ambari-Web tests with the patch:
25671 tests complete (33 seconds)
154 tests pending

File Attachments

AMBARI-15979-inlineError.patch

https://reviews.apache.org/media/uploaded/files/2016/04/21/03bc972a-b076-4520-948b-3a204082eca0__AMBARI-15979-inlineError.patch
AMBARI-15979-topError.patch

https://reviews.apache.org/media/uploaded/files/2016/04/21/8b4e9a7b-96cb-4a17-9c9c-56e59b5fd349__AMBARI-15979-topError.patch

Thanks,

Keta Patel

Re: Review Request 46152: Add 'ambari-logsearch-solr-client' module for ambari-logsearch


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

(Updated April 25, 2016, 4:29 p.m.)


Review request for Ambari, Alejandro Fernandez, Andrew Onischuk, Robert 
Nettleton, Sandor Magyari, Sumit Mohanty, and Sebastian Toader.


Changes
---

-fixed typo


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


Repository: ambari


Description
---

Create a small ambari solr client (and rpm/deb), for logsearch solr.
The goal is the create a client which can be used for another services to 
access zookeeper/solr and create their own collections in logsearch solr. (e.g. 
for ATLAS or RANGER)


Diffs (updated)
-

  
ambari-common/src/main/python/resource_management/libraries/functions/package_conditions.py
 1544ffe 
  
ambari-common/src/main/python/resource_management/libraries/functions/solr_cloud_util.py
 PRE-CREATION 
  ambari-logsearch/ambari-logsearch-assembly/pom.xml 2db0608 
  
ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/control
 b853f13 
  
ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/postinst
 21a01fa 
  
ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/postrm 
21a01fa 
  
ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/posttrm
 21a01fa 
  
ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/preinst
 21a01fa 
  
ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/prerm 
21a01fa 
  
ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/control
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/postinst
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/postrm
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/preinst
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/prerm
 PRE-CREATION 
  ambari-logsearch/ambari-logsearch-solr-client/build.xml PRE-CREATION 
  ambari-logsearch/ambari-logsearch-solr-client/pom.xml PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/AmbariSolrCloudCLI.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/AmbariSolrCloudClient.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/AmbariSolrCloudClientBuilder.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/AmbariSolrCloudClientException.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/AbstractRetryCommand.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/AbstractSolrRetryCommand.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/AbstractZookeeperRetryCommand.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/CheckConfigZkCommand.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/CreateCollectionCommand.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/CreateShardCommand.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/DownloadConfigZkCommand.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/GetShardsCommand.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/ListCollectionCommand.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/UploadConfigZkCommand.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/util/ShardUtils.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/resources/log4j.properties
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/main/resources/solrCloudCli.sh
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-solr-client/src/test/java/org/apache/ambari/logsearch/solr/AmbariSolrCloudClientTest.java
 PRE-CREATION 
  ambari-logsearch/pom.xml 9fa7c96 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logfeeder-env.xml
 93311fb

Re: Review Request 46639: Add counter limits to LogSearch integration error logs that occur during failed connection attempts



> On April 25, 2016, 4 p.m., Oliver Szabo wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/controller/logging/Utils.java,
> >  line 29
> > 
> >
> > Utils is too generic for me, can this be more specified ? (like 
> > SomethingUtils.java, i know its in a specified package, but maybe it would 
> > be easier to find with a less generic name)
> 
> Robert Nettleton wrote:
> I'm not sure I agree that the name is too generic, since as you mentioned 
> it is scoped in the intended package.
> 
> As Sumit mentioned above, this might eventually be a useful utility for 
> more than just this case, but I believe that the code might need some 
> refactoring in order to make this generic enough to be useful across Ambari 
> logging.
> 
> Since we'll probably do that in a future patch at some point, I'm less 
> inclined to think that we should rename this now, since this functionality 
> might be moved to a different, more common, package anyway in a future change.
> 
> Please let me know if you agree. 
> 
> Thanks.
> 
> Oliver Szabo wrote:
> im okay with that now, so i will drop the issue, but if it will go into a 
> more generic package (like org.apache.ambari.server.utils.* -> we have some 
> Utils class there), then it would be better with a more specified name

I agree.  Thanks for the comments.


- Robert


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


On April 25, 2016, 3:28 p.m., Robert Nettleton wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46639/
> ---
> 
> (Updated April 25, 2016, 3:28 p.m.)
> 
> 
> Review request for Ambari, Oliver Szabo and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16093
> https://issues.apache.org/jira/browse/AMBARI-16093
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This patch resolves AMBARI-16093.
> 
> Hundreds of repeated error logs were occuring in instances when the LogSearch 
> server was unexpectedly shutdown, and Ambari Server was not yet aware of the 
> change in service state. 
> 
> The LoggingSearchPropertyProvider already waits until the LOGSEARCH_SERVER 
> component is in the started state, but if that component shuts down 
> unexpectedly, there will be a small time window during which the provider 
> will attempt to connect to the LogSearch server, which will then fail and 
> generate error logs.
> 
> In order to resolve this logging issue, this patch implements the following:
> 
> 1. Implements a new utility class to handle checks on a specified counter, 
> which can be used to limit the number of times a given error log is included 
> in ambari-server.log. 
> 2. Modifies the LoggingSearchPropertyProvider and LoggingRequestHelperImpl 
> classes to use this new utility class in cases where this problem of repeated 
> logging may occur.  
> 3. Implements a new unit test case for the new utility class, to verify that 
> a given log is only passed to the logger in certain circumstances, based on 
> the value of the specified counter.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperImpl.java
>  a5cd369 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingSearchPropertyProvider.java
>  e2da4c8 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/Utils.java
>  PRE-CREATION 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/logging/UtilsTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46639/diff/
> 
> 
> Testing
> ---
> 
> 1. Deployed a 1-VM cluster without LogSearch enabled, verified that the 
> cluster deployed successfully, and that no extraneous error logging occurring 
> in ambari-server.log or ambari-server.out.
> 2. Deployed a 1-VM cluster with LogSearch enabled, verified that the cluster 
> deployed successfully, verified that the LogSearch Integration APIs are 
> functioning as expected.  As part of this test, I also killed the LogSearch 
> Server with "kill -9", accessed the various portions of the UI that rely on 
> the HostComponent REST API, and verified that no extraneous logging was 
> present in ambari-server.log or ambari-server.out.
> 3. Ran the ambari-server "mvn clean test" suite with my patch applied.  Test 
> Results:
> 
> "
> Results :
> 
> Tests run: 4273, Failures: 0, Errors: 0, Skipped: 32
> "
> 
> "
> 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,

Re: Review Request 46639: Add counter limits to LogSearch integration error logs that occur during failed connection attempts


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


Ship it!




Ship It!

- Oliver Szabo


On April 25, 2016, 3:28 p.m., Robert Nettleton wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46639/
> ---
> 
> (Updated April 25, 2016, 3:28 p.m.)
> 
> 
> Review request for Ambari, Oliver Szabo and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16093
> https://issues.apache.org/jira/browse/AMBARI-16093
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This patch resolves AMBARI-16093.
> 
> Hundreds of repeated error logs were occuring in instances when the LogSearch 
> server was unexpectedly shutdown, and Ambari Server was not yet aware of the 
> change in service state. 
> 
> The LoggingSearchPropertyProvider already waits until the LOGSEARCH_SERVER 
> component is in the started state, but if that component shuts down 
> unexpectedly, there will be a small time window during which the provider 
> will attempt to connect to the LogSearch server, which will then fail and 
> generate error logs.
> 
> In order to resolve this logging issue, this patch implements the following:
> 
> 1. Implements a new utility class to handle checks on a specified counter, 
> which can be used to limit the number of times a given error log is included 
> in ambari-server.log. 
> 2. Modifies the LoggingSearchPropertyProvider and LoggingRequestHelperImpl 
> classes to use this new utility class in cases where this problem of repeated 
> logging may occur.  
> 3. Implements a new unit test case for the new utility class, to verify that 
> a given log is only passed to the logger in certain circumstances, based on 
> the value of the specified counter.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperImpl.java
>  a5cd369 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingSearchPropertyProvider.java
>  e2da4c8 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/Utils.java
>  PRE-CREATION 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/logging/UtilsTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46639/diff/
> 
> 
> Testing
> ---
> 
> 1. Deployed a 1-VM cluster without LogSearch enabled, verified that the 
> cluster deployed successfully, and that no extraneous error logging occurring 
> in ambari-server.log or ambari-server.out.
> 2. Deployed a 1-VM cluster with LogSearch enabled, verified that the cluster 
> deployed successfully, verified that the LogSearch Integration APIs are 
> functioning as expected.  As part of this test, I also killed the LogSearch 
> Server with "kill -9", accessed the various portions of the UI that rely on 
> the HostComponent REST API, and verified that no extraneous logging was 
> present in ambari-server.log or ambari-server.out.
> 3. Ran the ambari-server "mvn clean test" suite with my patch applied.  Test 
> Results:
> 
> "
> Results :
> 
> Tests run: 4273, Failures: 0, Errors: 0, Skipped: 32
> "
> 
> "
> 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:19:32.519s
> [INFO] Finished at: Mon Apr 25 11:02:50 EDT 2016
> [INFO] Final Memory: 38M/720M
> [INFO] 
> "
> 
> 
> Thanks,
> 
> Robert Nettleton
> 
>

Re: Review Request 46639: Add counter limits to LogSearch integration error logs that occur during failed connection attempts



> On April 25, 2016, 4 p.m., Oliver Szabo wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/controller/logging/Utils.java,
> >  line 29
> > 
> >
> > Utils is too generic for me, can this be more specified ? (like 
> > SomethingUtils.java, i know its in a specified package, but maybe it would 
> > be easier to find with a less generic name)
> 
> Robert Nettleton wrote:
> I'm not sure I agree that the name is too generic, since as you mentioned 
> it is scoped in the intended package.
> 
> As Sumit mentioned above, this might eventually be a useful utility for 
> more than just this case, but I believe that the code might need some 
> refactoring in order to make this generic enough to be useful across Ambari 
> logging.
> 
> Since we'll probably do that in a future patch at some point, I'm less 
> inclined to think that we should rename this now, since this functionality 
> might be moved to a different, more common, package anyway in a future change.
> 
> Please let me know if you agree. 
> 
> Thanks.

im okay with that now, so i will drop the issue, but if it will go into a more 
generic package (like org.apache.ambari.server.utils.* -> we have some Utils 
class there), then it would be better with a more specified name


- Oliver


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


On April 25, 2016, 3:28 p.m., Robert Nettleton wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46639/
> ---
> 
> (Updated April 25, 2016, 3:28 p.m.)
> 
> 
> Review request for Ambari, Oliver Szabo and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16093
> https://issues.apache.org/jira/browse/AMBARI-16093
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This patch resolves AMBARI-16093.
> 
> Hundreds of repeated error logs were occuring in instances when the LogSearch 
> server was unexpectedly shutdown, and Ambari Server was not yet aware of the 
> change in service state. 
> 
> The LoggingSearchPropertyProvider already waits until the LOGSEARCH_SERVER 
> component is in the started state, but if that component shuts down 
> unexpectedly, there will be a small time window during which the provider 
> will attempt to connect to the LogSearch server, which will then fail and 
> generate error logs.
> 
> In order to resolve this logging issue, this patch implements the following:
> 
> 1. Implements a new utility class to handle checks on a specified counter, 
> which can be used to limit the number of times a given error log is included 
> in ambari-server.log. 
> 2. Modifies the LoggingSearchPropertyProvider and LoggingRequestHelperImpl 
> classes to use this new utility class in cases where this problem of repeated 
> logging may occur.  
> 3. Implements a new unit test case for the new utility class, to verify that 
> a given log is only passed to the logger in certain circumstances, based on 
> the value of the specified counter.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperImpl.java
>  a5cd369 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingSearchPropertyProvider.java
>  e2da4c8 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/Utils.java
>  PRE-CREATION 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/logging/UtilsTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46639/diff/
> 
> 
> Testing
> ---
> 
> 1. Deployed a 1-VM cluster without LogSearch enabled, verified that the 
> cluster deployed successfully, and that no extraneous error logging occurring 
> in ambari-server.log or ambari-server.out.
> 2. Deployed a 1-VM cluster with LogSearch enabled, verified that the cluster 
> deployed successfully, verified that the LogSearch Integration APIs are 
> functioning as expected.  As part of this test, I also killed the LogSearch 
> Server with "kill -9", accessed the various portions of the UI that rely on 
> the HostComponent REST API, and verified that no extraneous logging was 
> present in ambari-server.log or ambari-server.out.
> 3. Ran the ambari-server "mvn clean test" suite with my patch applied.  Test 
> Results:
> 
> "
> Results :
> 
> Tests run: 4273, Failures: 0, Errors: 0, Skipped: 32
> "
> 
> "
> 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

Re: Review Request 46639: Add counter limits to LogSearch integration error logs that occur during failed connection attempts



> On April 25, 2016, 4 p.m., Oliver Szabo wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/controller/logging/Utils.java,
> >  line 29
> > 
> >
> > Utils is too generic for me, can this be more specified ? (like 
> > SomethingUtils.java, i know its in a specified package, but maybe it would 
> > be easier to find with a less generic name)

I'm not sure I agree that the name is too generic, since as you mentioned it is 
scoped in the intended package.

As Sumit mentioned above, this might eventually be a useful utility for more 
than just this case, but I believe that the code might need some refactoring in 
order to make this generic enough to be useful across Ambari logging.

Since we'll probably do that in a future patch at some point, I'm less inclined 
to think that we should rename this now, since this functionality might be 
moved to a different, more common, package anyway in a future change.

Please let me know if you agree. 

Thanks.


- Robert


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


On April 25, 2016, 3:28 p.m., Robert Nettleton wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46639/
> ---
> 
> (Updated April 25, 2016, 3:28 p.m.)
> 
> 
> Review request for Ambari, Oliver Szabo and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16093
> https://issues.apache.org/jira/browse/AMBARI-16093
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This patch resolves AMBARI-16093.
> 
> Hundreds of repeated error logs were occuring in instances when the LogSearch 
> server was unexpectedly shutdown, and Ambari Server was not yet aware of the 
> change in service state. 
> 
> The LoggingSearchPropertyProvider already waits until the LOGSEARCH_SERVER 
> component is in the started state, but if that component shuts down 
> unexpectedly, there will be a small time window during which the provider 
> will attempt to connect to the LogSearch server, which will then fail and 
> generate error logs.
> 
> In order to resolve this logging issue, this patch implements the following:
> 
> 1. Implements a new utility class to handle checks on a specified counter, 
> which can be used to limit the number of times a given error log is included 
> in ambari-server.log. 
> 2. Modifies the LoggingSearchPropertyProvider and LoggingRequestHelperImpl 
> classes to use this new utility class in cases where this problem of repeated 
> logging may occur.  
> 3. Implements a new unit test case for the new utility class, to verify that 
> a given log is only passed to the logger in certain circumstances, based on 
> the value of the specified counter.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperImpl.java
>  a5cd369 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingSearchPropertyProvider.java
>  e2da4c8 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/Utils.java
>  PRE-CREATION 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/logging/UtilsTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46639/diff/
> 
> 
> Testing
> ---
> 
> 1. Deployed a 1-VM cluster without LogSearch enabled, verified that the 
> cluster deployed successfully, and that no extraneous error logging occurring 
> in ambari-server.log or ambari-server.out.
> 2. Deployed a 1-VM cluster with LogSearch enabled, verified that the cluster 
> deployed successfully, verified that the LogSearch Integration APIs are 
> functioning as expected.  As part of this test, I also killed the LogSearch 
> Server with "kill -9", accessed the various portions of the UI that rely on 
> the HostComponent REST API, and verified that no extraneous logging was 
> present in ambari-server.log or ambari-server.out.
> 3. Ran the ambari-server "mvn clean test" suite with my patch applied.  Test 
> Results:
> 
> "
> Results :
> 
> Tests run: 4273, Failures: 0, Errors: 0, Skipped: 32
> "
> 
> "
> 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] 
>

Re: Review Request 46639: Add counter limits to LogSearch integration error logs that occur during failed connection attempts


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




ambari-server/src/main/java/org/apache/ambari/server/controller/logging/Utils.java
 (line 29)


Utils is too generic for me, can this be more specified ? (like 
SomethingUtils.java, i know its in a specified package, but maybe it would be 
easier to find with a less generic name)


- Oliver Szabo


On April 25, 2016, 3:28 p.m., Robert Nettleton wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46639/
> ---
> 
> (Updated April 25, 2016, 3:28 p.m.)
> 
> 
> Review request for Ambari, Oliver Szabo and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16093
> https://issues.apache.org/jira/browse/AMBARI-16093
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This patch resolves AMBARI-16093.
> 
> Hundreds of repeated error logs were occuring in instances when the LogSearch 
> server was unexpectedly shutdown, and Ambari Server was not yet aware of the 
> change in service state. 
> 
> The LoggingSearchPropertyProvider already waits until the LOGSEARCH_SERVER 
> component is in the started state, but if that component shuts down 
> unexpectedly, there will be a small time window during which the provider 
> will attempt to connect to the LogSearch server, which will then fail and 
> generate error logs.
> 
> In order to resolve this logging issue, this patch implements the following:
> 
> 1. Implements a new utility class to handle checks on a specified counter, 
> which can be used to limit the number of times a given error log is included 
> in ambari-server.log. 
> 2. Modifies the LoggingSearchPropertyProvider and LoggingRequestHelperImpl 
> classes to use this new utility class in cases where this problem of repeated 
> logging may occur.  
> 3. Implements a new unit test case for the new utility class, to verify that 
> a given log is only passed to the logger in certain circumstances, based on 
> the value of the specified counter.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperImpl.java
>  a5cd369 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingSearchPropertyProvider.java
>  e2da4c8 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/Utils.java
>  PRE-CREATION 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/logging/UtilsTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46639/diff/
> 
> 
> Testing
> ---
> 
> 1. Deployed a 1-VM cluster without LogSearch enabled, verified that the 
> cluster deployed successfully, and that no extraneous error logging occurring 
> in ambari-server.log or ambari-server.out.
> 2. Deployed a 1-VM cluster with LogSearch enabled, verified that the cluster 
> deployed successfully, verified that the LogSearch Integration APIs are 
> functioning as expected.  As part of this test, I also killed the LogSearch 
> Server with "kill -9", accessed the various portions of the UI that rely on 
> the HostComponent REST API, and verified that no extraneous logging was 
> present in ambari-server.log or ambari-server.out.
> 3. Ran the ambari-server "mvn clean test" suite with my patch applied.  Test 
> Results:
> 
> "
> Results :
> 
> Tests run: 4273, Failures: 0, Errors: 0, Skipped: 32
> "
> 
> "
> 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:19:32.519s
> [INFO] Finished at: Mon Apr 25 11:02:50 EDT 2016
> [INFO] Final Memory: 38M/720M
> [INFO] 
> "
> 
> 
> Thanks,
> 
> Robert Nettleton
> 
>

Re: Review Request 46639: Add counter limits to LogSearch integration error logs that occur during failed connection attempts

2016-04-25 Thread Sumit Mohanty


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


Ship it!




Ship It!

- Sumit Mohanty


On April 25, 2016, 3:28 p.m., Robert Nettleton wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46639/
> ---
> 
> (Updated April 25, 2016, 3:28 p.m.)
> 
> 
> Review request for Ambari, Oliver Szabo and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16093
> https://issues.apache.org/jira/browse/AMBARI-16093
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This patch resolves AMBARI-16093.
> 
> Hundreds of repeated error logs were occuring in instances when the LogSearch 
> server was unexpectedly shutdown, and Ambari Server was not yet aware of the 
> change in service state. 
> 
> The LoggingSearchPropertyProvider already waits until the LOGSEARCH_SERVER 
> component is in the started state, but if that component shuts down 
> unexpectedly, there will be a small time window during which the provider 
> will attempt to connect to the LogSearch server, which will then fail and 
> generate error logs.
> 
> In order to resolve this logging issue, this patch implements the following:
> 
> 1. Implements a new utility class to handle checks on a specified counter, 
> which can be used to limit the number of times a given error log is included 
> in ambari-server.log. 
> 2. Modifies the LoggingSearchPropertyProvider and LoggingRequestHelperImpl 
> classes to use this new utility class in cases where this problem of repeated 
> logging may occur.  
> 3. Implements a new unit test case for the new utility class, to verify that 
> a given log is only passed to the logger in certain circumstances, based on 
> the value of the specified counter.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperImpl.java
>  a5cd369 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingSearchPropertyProvider.java
>  e2da4c8 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/logging/Utils.java
>  PRE-CREATION 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/logging/UtilsTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46639/diff/
> 
> 
> Testing
> ---
> 
> 1. Deployed a 1-VM cluster without LogSearch enabled, verified that the 
> cluster deployed successfully, and that no extraneous error logging occurring 
> in ambari-server.log or ambari-server.out.
> 2. Deployed a 1-VM cluster with LogSearch enabled, verified that the cluster 
> deployed successfully, verified that the LogSearch Integration APIs are 
> functioning as expected.  As part of this test, I also killed the LogSearch 
> Server with "kill -9", accessed the various portions of the UI that rely on 
> the HostComponent REST API, and verified that no extraneous logging was 
> present in ambari-server.log or ambari-server.out.
> 3. Ran the ambari-server "mvn clean test" suite with my patch applied.  Test 
> Results:
> 
> "
> Results :
> 
> Tests run: 4273, Failures: 0, Errors: 0, Skipped: 32
> "
> 
> "
> 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:19:32.519s
> [INFO] Finished at: Mon Apr 25 11:02:50 EDT 2016
> [INFO] Final Memory: 38M/720M
> [INFO] 
> "
> 
> 
> Thanks,
> 
> Robert Nettleton
> 
>

Re: Review Request 46619: AMBARI-16085 : Modify Ambari stacks for Ranger (for enabling plugins) to use service keytab for creating repositories and policies

2016-04-25 Thread Robert Levas


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


Fix it, then Ship it!





ambari-common/src/main/python/resource_management/libraries/functions/curl_krb_request.py
 (lines 184 - 200)


Seems like this couuld be simplified a bit. 

Maybe create the base argument arry, then add arguments as needed, 
depending on the method, body, and header parameters. 

Finally call something like the following when done building the array... 
```
 _, curl_stdout, curl_stderr = get_user_call_output(arg_array, user=user, 
env=kerberos_env)
```



ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/params_linux.py
 (lines 260 - 261)


Why duplicate this?  Rename _rm_* to rm_*


- Robert Levas


On April 25, 2016, 10:12 a.m., Gautam Borad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46619/
> ---
> 
> (Updated April 25, 2016, 10:12 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jaimin Jetly, Mahadev Konar, 
> Nate Cole, Robert Levas, Sumit Mohanty, and Velmurugan Periasamy.
> 
> 
> Bugs: AMBARI-16085
> https://issues.apache.org/jira/browse/AMBARI-16085
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> **Problem Statement**
> In order to allow Ranger plugins to support Kerberos Authentication, make 
> changes in Ranger plugin stacks to create ranger services and policies using 
> component principal / keytab. Also take care of config changes to support 
> plugin communication in Kerberos enabled env.
> 
> **Proposed Solution**
> Update Ranger repository creation calls to use component principal/keytab as 
> well as update config parameters to support Ranger plugin communication.
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/curl_krb_request.py
>  cf0d5a6 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/ranger_functions_v2.py
>  3bb0103 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/setup_ranger_plugin_xml.py
>  a7faf3b 
>   
> ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/params_linux.py
>  2c466ea 
>   
> ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/setup_ranger_hbase.py
>  ffd0715 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/params_linux.py
>  e6fd32c 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/setup_ranger_hdfs.py
>  858044c 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
>  a044fda 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/setup_ranger_hive.py
>  f51dbab 
>   
> ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/package/scripts/params.py
>  d4ee6f9 
>   
> ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/package/scripts/setup_ranger_kafka.py
>  a99dc76 
>   
> ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/params_linux.py
>  d572aff 
>   
> ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/setup_ranger_knox.py
>  13987c8 
>   
> ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/params.py
>  bcbab42 
>   
> ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/params_linux.py
>  3f9b936 
>   
> ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/setup_ranger_storm.py
>  bef1f02 
>   
> ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/params_linux.py
>  8fbefb2 
>   
> ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/setup_ranger_yarn.py
>  21fe8e1 
> 
> Diff: https://reviews.apache.org/r/46619/diff/
> 
> 
> Testing
> ---
> 
> **Verified**
> Added Ranger in a Kerberos enabled environment and verified enable of plugin 
> for supported components.
> 
> 
> Thanks,
> 
> Gautam Borad
> 
>

Review Request 46639: Add counter limits to LogSearch integration error logs that occur during failed connection attempts

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

Review request for Ambari, Oliver Szabo and Sumit Mohanty.

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

Repository: ambari

Description
---

This patch resolves AMBARI-16093.

Hundreds of repeated error logs were occuring in instances when the LogSearch
server was unexpectedly shutdown, and Ambari Server was not yet aware of the
change in service state.

The LoggingSearchPropertyProvider already waits until the LOGSEARCH_SERVER
component is in the started state, but if that component shuts down
unexpectedly, there will be a small time window during which the provider will
attempt to connect to the LogSearch server, which will then fail and generate
error logs.

In order to resolve this logging issue, this patch implements the following:

1. Implements a new utility class to handle checks on a specified counter,
which can be used to limit the number of times a given error log is included in
ambari-server.log.
2. Modifies the LoggingSearchPropertyProvider and LoggingRequestHelperImpl
classes to use this new utility class in cases where this problem of repeated
logging may occur.
3. Implements a new unit test case for the new utility class, to verify that a
given log is only passed to the logger in certain circumstances, based on the
value of the specified counter.

Diffs
-

ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingRequestHelperImpl.java
a5cd369

ambari-server/src/main/java/org/apache/ambari/server/controller/logging/LoggingSearchPropertyProvider.java
e2da4c8

ambari-server/src/main/java/org/apache/ambari/server/controller/logging/Utils.java
PRE-CREATION

ambari-server/src/test/java/org/apache/ambari/server/controller/logging/UtilsTest.java
PRE-CREATION

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

Testing
---

1. Deployed a 1-VM cluster without LogSearch enabled, verified that the cluster
deployed successfully, and that no extraneous error logging occurring in
ambari-server.log or ambari-server.out.
2. Deployed a 1-VM cluster with LogSearch enabled, verified that the cluster
deployed successfully, verified that the LogSearch Integration APIs are
functioning as expected. As part of this test, I also killed the LogSearch
Server with "kill -9", accessed the various portions of the UI that rely on the
HostComponent REST API, and verified that no extraneous logging was present in
ambari-server.log or ambari-server.out.
3. Ran the ambari-server "mvn clean test" suite with my patch applied. Test
Results:

"
Results :

Tests run: 4273, Failures: 0, Errors: 0, Skipped: 32
"

"
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:19:32.519s
[INFO] Finished at: Mon Apr 25 11:02:50 EDT 2016
[INFO] Final Memory: 38M/720M
[INFO]
"

Thanks,

Robert Nettleton

Review Request 46638: Issue with stack advisor

2016-04-25 Thread Vitalyi Brodetskyi


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

Review request for Ambari and Dmitro Lisnichenko.


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


Repository: ambari


Description
---

During deploying secure cluster via blueprints there was found issue in stack 
adviser:
{code}
2016-04-21 11:38:34,974 - Problem retrieving YARN queues. Skipping updating 
HIVE Server Interactve 'hive.server2.tez.default.queues' property.
Error occured in stack advisor.
Error details: argument of type 'NoneType' is not iterable
21 Apr 2016 11:38:35,015  INFO [pool-12-thread-1] StackAdvisorRunner:71 - 
advisor script stderr: 2016-04-21 11:38:34,974 - Problem retrieving YARN 
queues. Skipping updating HIVE Server Interactve 
'hive.server2.tez.default.queues' property.
Traceback (most recent call last):
  File "/var/lib/ambari-server/resources/scripts/stack_advisor.py", line 158, 
in 
main(sys.argv)
  File "/var/lib/ambari-server/resources/scripts/stack_advisor.py", line 109, 
in main
result = stackAdvisor.recommendConfigurations(services, hosts)
  File "/var/lib/ambari-server/resources/scripts/../stacks/stack_advisor.py", 
line 589, in recommendConfigurations
calculation(configurations, clusterSummary, services, hosts)
  File 
"/var/lib/ambari-server/resources/scripts/./../stacks/HDP/2.3/services/stack_advisor.py",
 line 761, in recommendStormConfigurations
if not include_atlas and atlas_hook_class in notifier_plugin_value:
TypeError: argument of type 'NoneType' is not iterable
21 Apr 2016 11:38:35,020 ERROR [pool-12-thread-1] 
ClusterConfigurationRequest:156 - An exception occurred while doing 
configuration topology update: 
org.apache.ambari.server.controller.internal.ConfigurationTopologyException: 
Configuration recommendation failed.
org.apache.ambari.server.controller.internal.ConfigurationTopologyException: 
Configuration recommendation failed.
at 
org.apache.ambari.server.api.services.stackadvisor.StackAdvisorBlueprintProcessor.adviseConfiguration(StackAdvisorBlueprintProcessor.java:80)
at 
org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:150)
at 
org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:760)
at 
org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:734)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: 
org.apache.ambari.server.api.services.stackadvisor.StackAdvisorException: Stack 
Advisor reported an error: TypeError: argument of type 'NoneType' is not 
iterable
StdOut file: /var/run/ambari-server/stack-recommendations/1/stackadvisor.out

StdErr file: /var/run/ambari-server/stack-recommendations/1/stackadvisor.err
at 
org.apache.ambari.server.api.services.stackadvisor.StackAdvisorRunner.runScript(StackAdvisorRunner.java:96)
at 
org.apache.ambari.server.api.services.stackadvisor.commands.StackAdvisorCommand.invoke(StackAdvisorCommand.java:258)
at 
org.apache.ambari.server.api.services.stackadvisor.StackAdvisorHelper.recommend(StackAdvisorHelper.java:109)
at 
org.apache.ambari.server.api.services.stackadvisor.StackAdvisorBlueprintProcessor.adviseConfiguration(StackAdvisorBlueprintProcessor.java:77)
... 9 more
{code}


Diffs
-

  ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py 
e880377 

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


Testing
---

mvn clean test


Thanks,

Vitalyi Brodetskyi

Re: Review Request 46600: AMBARI-16078. HiveServerInteractive. Config calculations used by LLAP app. and fixes for AMBARI-16079, AMBARI-16086, AMBARI-16087

2016-04-25 Thread Sumit Mohanty


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


Ship it!




Ship It!

- Sumit Mohanty


On April 25, 2016, 10:07 a.m., Swapan Shridhar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46600/
> ---
> 
> (Updated April 25, 2016, 10:07 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16078, AMBARI-16079, AMBARI-16086, and AMBARI-16087
> https://issues.apache.org/jira/browse/AMBARI-16078
> https://issues.apache.org/jira/browse/AMBARI-16079
> https://issues.apache.org/jira/browse/AMBARI-16086
> https://issues.apache.org/jira/browse/AMBARI-16087
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Fix for : 
>   (1). AMBARI-16078. Config calculations used by LLAP app. 
>   
>   Trivial fixes for :
>   
>(2). AMBARI-16079. waiting for fixed number of times if the launched LLAP 
> app is in LAUNCHING state, for it to go to RUNNING_ALL or RUNNING_PARTIAL
>   (3). AMBARI-16086. Hide HSI related sliders when 'llap' queue is not being 
> used.
>   (4). AMBARI-16087. LLAP queue is not selected when enabling Hive 
> Interactive Query during Install Wizard
> 
> AMBARI-16078:
> 
> - Calculated in Stack advisor code whenever : LLAP queue is in selection and 
> (1). HSI is enabled or (2). change done to slider HSI slider "% of Cluster 
> Capacity" , or (3). change done to slider HSI slider 'Number of Daemon 
> Instances'
> - 
> - caluclations are not done if the overall cluster state is not conduciv for 
> meaningful run of LLAP.
> 
> AMBARI-16079: 
> =
> 
> Reason : If the LLAP app state is LAUNCHING and we go ahead with HSI start, 
> the overall workability of app may not be ascertained.
> As of now, using llap0 name, app does go into RUNNING_ALL state.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_interactive.py
>  f548ea3 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
>  a044fda 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-env.xml
>  816e207 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-site.xml
>  21d1109 
>   ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
> 4da21fa 
>   ambari-server/src/test/python/stacks/2.5/HIVE/test_hive_server_int.py 
> 44759a9 
>   ambari-server/src/test/python/stacks/2.5/common/test_stack_advisor.py 
> 3934301 
>   ambari-server/src/test/python/stacks/2.5/configs/hsi_default.json 1cb2a02 
> 
> Diff: https://reviews.apache.org/r/46600/diff/
> 
> 
> Testing
> ---
> 
> - Python tests added.
> - Python UT passes.
> 
> 
> --
> Ran 261 tests in 7.091s
> 
> OK
> --
> Total run:995
> Total errors:0
> Total failures:0
> OK
> 
> 
> Thanks,
> 
> Swapan Shridhar
> 
>

Review Request 46619: AMBARI-16085 : Modify Ambari stacks for Ranger (for enabling plugins) to use service keytab for creating repositories and policies

2016-04-25 Thread Gautam Borad


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

Review request for Ambari, Alejandro Fernandez, Jaimin Jetly, Mahadev Konar, 
Nate Cole, Robert Levas, Sumit Mohanty, and Velmurugan Periasamy.


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


Repository: ambari


Description
---

**Problem Statement**
In order to allow Ranger plugins to support Kerberos Authentication, make 
changes in Ranger plugin stacks to create ranger services and policies using 
component principal / keytab. Also take care of config changes to support 
plugin communication in Kerberos enabled env.

**Proposed Solution**
Update Ranger repository creation calls to use component principal/keytab as 
well as update config parameters to support Ranger plugin communication.


Diffs
-

  
ambari-common/src/main/python/resource_management/libraries/functions/curl_krb_request.py
 cf0d5a6 
  
ambari-common/src/main/python/resource_management/libraries/functions/ranger_functions_v2.py
 3bb0103 
  
ambari-common/src/main/python/resource_management/libraries/functions/setup_ranger_plugin_xml.py
 a7faf3b 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/params_linux.py
 2c466ea 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/setup_ranger_hbase.py
 ffd0715 
  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/params_linux.py
 e6fd32c 
  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/setup_ranger_hdfs.py
 858044c 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
 a044fda 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/setup_ranger_hive.py
 f51dbab 
  
ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/package/scripts/params.py
 d4ee6f9 
  
ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/package/scripts/setup_ranger_kafka.py
 a99dc76 
  
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/params_linux.py
 d572aff 
  
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/setup_ranger_knox.py
 13987c8 
  
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/params.py
 bcbab42 
  
ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/params_linux.py
 3f9b936 
  
ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/package/scripts/setup_ranger_storm.py
 bef1f02 
  
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/params_linux.py
 8fbefb2 
  
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/setup_ranger_yarn.py
 21fe8e1 

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


Testing
---

**Verified**
Added Ranger in a Kerberos enabled environment and verified enable of plugin 
for supported components.


Thanks,

Gautam Borad

Re: Review Request 46152: Add 'ambari-logsearch-solr-client' module for ambari-logsearch


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


Ship it!




Ship It!

- Robert Nettleton


On April 22, 2016, 6:02 p.m., Oliver Szabo wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46152/
> ---
> 
> (Updated April 22, 2016, 6:02 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Andrew Onischuk, Robert 
> Nettleton, Sandor Magyari, Sumit Mohanty, and Sebastian Toader.
> 
> 
> Bugs: AMBARI-15865
> https://issues.apache.org/jira/browse/AMBARI-15865
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Create a small ambari solr client (and rpm/deb), for logsearch solr.
> The goal is the create a client which can be used for another services to 
> access zookeeper/solr and create their own collections in logsearch solr. 
> (e.g. for ATLAS or RANGER)
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/package_conditions.py
>  1544ffe 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/solr_cloud_util.py
>  PRE-CREATION 
>   ambari-logsearch/ambari-logsearch-assembly/pom.xml 2db0608 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/control
>  b853f13 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/postinst
>  21a01fa 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/postrm
>  21a01fa 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/posttrm
>  21a01fa 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/preinst
>  21a01fa 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/prerm
>  21a01fa 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/control
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/postinst
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/postrm
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/preinst
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/prerm
>  PRE-CREATION 
>   ambari-logsearch/ambari-logsearch-solr-client/build.xml PRE-CREATION 
>   ambari-logsearch/ambari-logsearch-solr-client/pom.xml PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/AmbariSolrCloudCLI.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/AmbariSolrCloudClient.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/AmbariSolrCloudClientBuilder.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/AmbariSolrCloudClientException.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/AbstractRetryCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/AbstractSolrRetryCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/AbstractZookeeperRetryCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/CheckConfigZkCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/CreateCollectionCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/CreateShardCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/DownloadConfigZkCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/GetShardsCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/ListCollectionCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/UploadConfigZkCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/util/ShardUtils.java
>  PRE-CREATION 
>

Re: Review Request 46152: Add 'ambari-logsearch-solr-client' module for ambari-logsearch

2016-04-25 Thread Sumit Mohanty


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


Ship it!




Ship It!

- Sumit Mohanty


On April 22, 2016, 6:02 p.m., Oliver Szabo wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46152/
> ---
> 
> (Updated April 22, 2016, 6:02 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Andrew Onischuk, Robert 
> Nettleton, Sandor Magyari, Sumit Mohanty, and Sebastian Toader.
> 
> 
> Bugs: AMBARI-15865
> https://issues.apache.org/jira/browse/AMBARI-15865
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Create a small ambari solr client (and rpm/deb), for logsearch solr.
> The goal is the create a client which can be used for another services to 
> access zookeeper/solr and create their own collections in logsearch solr. 
> (e.g. for ATLAS or RANGER)
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/package_conditions.py
>  1544ffe 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/solr_cloud_util.py
>  PRE-CREATION 
>   ambari-logsearch/ambari-logsearch-assembly/pom.xml 2db0608 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/control
>  b853f13 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/postinst
>  21a01fa 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/postrm
>  21a01fa 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/posttrm
>  21a01fa 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/preinst
>  21a01fa 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/appender/prerm
>  21a01fa 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/control
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/postinst
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/postrm
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/preinst
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/solr-client/prerm
>  PRE-CREATION 
>   ambari-logsearch/ambari-logsearch-solr-client/build.xml PRE-CREATION 
>   ambari-logsearch/ambari-logsearch-solr-client/pom.xml PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/AmbariSolrCloudCLI.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/AmbariSolrCloudClient.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/AmbariSolrCloudClientBuilder.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/AmbariSolrCloudClientException.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/AbstractRetryCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/AbstractSolrRetryCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/AbstractZookeeperRetryCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/CheckConfigZkCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/CreateCollectionCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/CreateShardCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/DownloadConfigZkCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/GetShardsCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/ListCollectionCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/commands/UploadConfigZkCommand.java
>  PRE-CREATION 
>   
> ambari-logsearch/ambari-logsearch-solr-client/src/main/java/org/apache/ambari/logsearch/solr/util/ShardUtils.java
>  PRE-CREATION 
>

Re: Review Request 46614: [RU] Hbase is losing table access permissions during upgrade.


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


Fix it, then Ship it!





ambari-server/src/main/java/org/apache/ambari/server/upgrade/AbstractUpgradeCatalog.java
 (lines 205 - 206)


This is pretty generic and can be named isConfigEnabled(cluster, 
configType, property)

I agree that it's a bit odd that we have service specific calls in the base 
class, but it's not terrible either.  Maybe see how isRangerKnoxPluginEnabled() 
is used and switch to the more generic function if it's easy enough.


- Nate Cole


On April 24, 2016, 2:55 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46614/
> ---
> 
> (Updated April 24, 2016, 2:55 p.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Nate Cole, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: AMBARI-16084
> https://issues.apache.org/jira/browse/AMBARI-16084
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> So here's where we are:
> 
> - https://reviews.apache.org/r/45890/diff/2#index_header removed hard-coded 
> python code which was trying to figure out which coprocessor to use. With 
> these values gone, it's now up to Ambari to set the _right_ value in the 
> configurations.
> 
> - However, after removing the above code, we never change the ranger 
> configurations to reflect the proper value
> 
> - To fix this, we need to fix the values on Ambari upgrade. When upgrading 
> Ambari from 2.0, we'll need to do the following:
> -- If Ranger is disabled; do nothing
> -- If Ranger is enabled and the cluster's current stack is HDP 2.2, then set 
> the master/region coprocessors to
> {code}
> hbase_coprocessor_master_classes = 
> "com.xasecure.authorization.hbase.XaSecureAuthorizationCoprocessor"
> hbase_coprocessor_regionserver_classes = 
> "com.xasecure.authorization.hbase.XaSecureAuthorizationCoprocessor"
> hbase_coprocessor_region_classes = 
> "org.apache.hadoop.hbase.security.token.TokenProvider,org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint,com.xasecure.authorization.hbase.XaSecureAuthorizationCoprocessor"
> {code}
> -- If Ranger is enabled and the cluster's current stack is HDP 2.3, then set 
> the master/region coprocessors to
> {code}
> hbase_coprocessor_master_classes = 
> "org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor "
> hbase_coprocessor_regionserver_classes = 
> "org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor"
> hbase_coprocessor_region_classes = 
> "org.apache.hadoop.hbase.security.token.TokenProvider,org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint,org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor"
> {code}
> 
> Now HDP stack upgrades will work since we look for 
> {{XaSecureAuthorizationCoprocessor}} and change it to 
> {{RangerAuthorizationCoprocessor}} as needed.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/AbstractUpgradeCatalog.java
>  b7665ce 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog222.java
>  31a3ce5 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog222Test.java
>  4302349 
> 
> Diff: https://reviews.apache.org/r/46614/diff/
> 
> 
> Testing
> ---
> 
> unit tests in progress
> 
> live cluster check in progress
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Review Request 46634: AMBARI-16043: version_builder.py fails to run against Python 2.6

2016-04-25 Thread Di Li


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

Review request for Ambari and Nate Cole.


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


Repository: ambari


Description
---

ersion_builder.py uses the new xpath syntax only supported by ElementTree in 
Python 2.7 and newer. So running the example.py to invoke version_builder.py to 
create version XML fails with the following error when Python is version 2.6.x

[root@myserver version-builder]$ python example.py
Traceback (most recent call last):
File "example.py", line 38, in 
main(sys.argv)
File "example.py", line 29, in main
vb.add_manifest("HDFS-271", "HDFS", "2.7.1.2.4.0")
File 
"/home/otto/dev/oss/ambari/trunk/ambari_trunk/contrib/version-builder/version_builder.py",
 line 122, in add_manifest
service_element = manifest_element.find("./service[@id='
{0}

']".format(id))
File "/usr/lib64/python2.6/xml/etree/ElementTree.py", line 330, in find
return ElementPath.find(self, path)
File "/usr/lib64/python2.6/xml/etree/ElementPath.py", line 186, in find
return _compile(path).find(element)
File "/usr/lib64/python2.6/xml/etree/ElementPath.py", line 176, in _compile
p = Path(path)
File "/usr/lib64/python2.6/xml/etree/ElementPath.py", line 93, in _init_
"expected path separator (%s)" % (op or tag)
SyntaxError: expected path separator ([)


Diffs
-

  contrib/version-builder/version_builder.py 965d80a 

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


Testing
---

generate version XML file on a linux box with only Pyton 2.6 installed, 
verifies it has the same content as one generated on a linux box with Python 
2.7.


Thanks,

Di Li

Re: Review Request 46592: Add a quick link to Grafana dashboards from Hive Service page

2016-04-25 Thread Di Li


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


Ship it!




Ship It!

- Di Li


On April 22, 2016, 11:17 p.m., Jaimin Jetly wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46592/
> ---
> 
> (Updated April 22, 2016, 11:17 p.m.)
> 
> 
> Review request for Ambari, Di Li, Srimanth Gunturi, and Yusaku Sako.
> 
> 
> Bugs: AMBARI-16076
> https://issues.apache.org/jira/browse/AMBARI-16076
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Add Hive Dashboard (Grafana) link in Hive service page->Quick links Action
> 
> At present, All quick links of a service are mapped to only one master 
> component of the service. Also this mapping is done in FE. As part of this 
> task the mapping of a link to a master component is now done in quick link 
> stack definition. So we can now have quick links on a service page linking to 
> different component hosts driven from stack. If host component is not yet 
> installed on the cluster then quick link won't appear.
> 
> Also seperate protocol defination can be made for every single quick link.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/quicklinks/Link.java
>  8800b3a 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/quicklinks/quicklinks.json
>  1c276c0 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/quicklinks/quicklinks.json
>  48a3efe 
>   
> ambari-server/src/main/resources/common-services/STORM/0.9.1.2.1/quicklinks/quicklinks.json
>  b6281f7 
>   
> ambari-server/src/main/resources/stacks/HDP/2.0.6/services/HBASE/quicklinks/quicklinks.json
>  5568122 
>   
> ambari-server/src/main/resources/stacks/HDP/2.0.6/services/HDFS/quicklinks/quicklinks.json
>  a4216e3 
>   
> ambari-server/src/main/resources/stacks/HDP/2.0.6/services/OOZIE/quicklinks/quicklinks.json
>  621fe8a 
>   
> ambari-server/src/main/resources/stacks/HDP/2.0.6/services/YARN/quicklinks-mapred/quicklinks.json
>  36f71b5 
>   
> ambari-server/src/main/resources/stacks/HDP/2.0.6/services/YARN/quicklinks/quicklinks.json
>  56c54b8 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/services/RANGER/quicklinks/quicklinks.json
>  42611d6 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/services/ACCUMULO/quicklinks/quicklinks.json
>  36e67c2 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/services/ATLAS/quicklinks/quicklinks.json
>  37e95cf 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/quicklinks/quicklinks.json
>  9863dc4 
>   ambari-web/app/controllers/wizard/step6_controller.js 3adc636 
>   ambari-web/app/controllers/wizard/step7_controller.js 2f78adf 
>   ambari-web/app/models/quicklinks/quick_links_config.js c9b2709 
>   ambari-web/app/views/common/quick_view_link_view.js dcaacb8 
>   ambari-web/test/views/common/quick_link_view_test.js 32b050b 
> 
> Diff: https://reviews.apache.org/r/46592/diff/
> 
> 
> Testing
> ---
> 
> Manually tested on the cluster.
> Verified all ambari-web unit tests passes:
> 
>   27527 tests complete (31 seconds)
>   154 tests pending
> 
> 
> Thanks,
> 
> Jaimin Jetly
> 
>

Re: Review Request 46600: AMBARI-16078. HiveServerInteractive. Config calculations used by LLAP app. and fixes for AMBARI-16079, AMBARI-16086, AMBARI-16087


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

(Updated April 25, 2016, 9:07 a.m.)


Review request for Ambari, Alejandro Fernandez and Sumit Mohanty.


Changes
---

Update Bugs.


Bugs: AMBARI-16078, AMBARI-16079, AMBARI-16086, and AMBARI-16087
https://issues.apache.org/jira/browse/AMBARI-16078
https://issues.apache.org/jira/browse/AMBARI-16079
https://issues.apache.org/jira/browse/AMBARI-16086
https://issues.apache.org/jira/browse/AMBARI-16087


Repository: ambari


Description
---

Fix for : 
  (1). AMBARI-16078. Config calculations used by LLAP app. 
  
  Trivial fixes for :
  
   (2). AMBARI-16079. waiting for fixed number of times if the launched LLAP 
app is in LAUNCHING state, for it to go to RUNNING_ALL or RUNNING_PARTIAL
  (3). AMBARI-16086. Hide HSI related sliders when 'llap' queue is not being 
used.
  (4). AMBARI-16087. LLAP queue is not selected when enabling Hive Interactive 
Query during Install Wizard

AMBARI-16078:

- Calculated in Stack advisor code whenever : LLAP queue is in selection and 
(1). HSI is enabled or (2). change done to slider HSI slider "% of Cluster 
Capacity" , or (3). change done to slider HSI slider 'Number of Daemon 
Instances'
- 
- caluclations are not done if the overall cluster state is not conduciv for 
meaningful run of LLAP.

AMBARI-16079: 
=

Reason : If the LLAP app state is LAUNCHING and we go ahead with HSI start, the 
overall workability of app may not be ascertained.
As of now, using llap0 name, app does go into RUNNING_ALL state.


Diffs
-

  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_interactive.py
 f548ea3 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
 a044fda 
  
ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-env.xml
 816e207 
  
ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-site.xml
 21d1109 
  ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
4da21fa 
  ambari-server/src/test/python/stacks/2.5/HIVE/test_hive_server_int.py 44759a9 
  ambari-server/src/test/python/stacks/2.5/common/test_stack_advisor.py 3934301 
  ambari-server/src/test/python/stacks/2.5/configs/hsi_default.json 1cb2a02 

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


Testing
---

- Python tests added.
- Python UT passes.


--
Ran 261 tests in 7.091s

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


Thanks,

Swapan Shridhar

Re: Review Request 46600: AMBARI-16078. HiveServerInteractive. Config calculations used by LLAP app. and fixes for AMBARI-16079, AMBARI-16086, AMBARI-16087


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

(Updated April 25, 2016, 9:06 a.m.)


Review request for Ambari, Alejandro Fernandez and Sumit Mohanty.


Summary (updated)
-

AMBARI-16078. HiveServerInteractive. Config calculations used by LLAP app. and 
fixes for AMBARI-16079, AMBARI-16086, AMBARI-16087


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


Repository: ambari


Description
---

Fix for : 
  (1). AMBARI-16078. Config calculations used by LLAP app. 
  
  Trivial fixes for :
  
   (2). AMBARI-16079. waiting for fixed number of times if the launched LLAP 
app is in LAUNCHING state, for it to go to RUNNING_ALL or RUNNING_PARTIAL
  (3). AMBARI-16086. Hide HSI related sliders when 'llap' queue is not being 
used.
  (4). AMBARI-16087. LLAP queue is not selected when enabling Hive Interactive 
Query during Install Wizard

AMBARI-16078:

- Calculated in Stack advisor code whenever : LLAP queue is in selection and 
(1). HSI is enabled or (2). change done to slider HSI slider "% of Cluster 
Capacity" , or (3). change done to slider HSI slider 'Number of Daemon 
Instances'
- 
- caluclations are not done if the overall cluster state is not conduciv for 
meaningful run of LLAP.

AMBARI-16079: 
=

Reason : If the LLAP app state is LAUNCHING and we go ahead with HSI start, the 
overall workability of app may not be ascertained.
As of now, using llap0 name, app does go into RUNNING_ALL state.


Diffs
-

  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_interactive.py
 f548ea3 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
 a044fda 
  
ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-env.xml
 816e207 
  
ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-site.xml
 21d1109 
  ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
4da21fa 
  ambari-server/src/test/python/stacks/2.5/HIVE/test_hive_server_int.py 44759a9 
  ambari-server/src/test/python/stacks/2.5/common/test_stack_advisor.py 3934301 
  ambari-server/src/test/python/stacks/2.5/configs/hsi_default.json 1cb2a02 

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


Testing
---

- Python tests added.
- Python UT passes.


--
Ran 261 tests in 7.091s

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


Thanks,

Swapan Shridhar

Re: Review Request 46600: AMBARI-16078. HiveServerInteractive. (1). Config calculations used by LLAP app. and fixes for AMBARI-16079, AMBARI-16086, AMBARI-16087



> On April 23, 2016, 6:35 p.m., Sumit Mohanty wrote:
> > ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_interactive.py,
> >  line 210
> > 
> >
> > Should slider_am_container_mb be params.slider_am_container_mb?

Fixed.


- Swapan


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


On April 25, 2016, 9:04 a.m., Swapan Shridhar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46600/
> ---
> 
> (Updated April 25, 2016, 9:04 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-16078.patch
> https://issues.apache.org/jira/browse/AMBARI-16078.patch
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Fix for : 
>   (1). AMBARI-16078. Config calculations used by LLAP app. 
>   
>   Trivial fixes for :
>   
>(2). AMBARI-16079. waiting for fixed number of times if the launched LLAP 
> app is in LAUNCHING state, for it to go to RUNNING_ALL or RUNNING_PARTIAL
>   (3). AMBARI-16086. Hide HSI related sliders when 'llap' queue is not being 
> used.
>   (4). AMBARI-16087. LLAP queue is not selected when enabling Hive 
> Interactive Query during Install Wizard
> 
> AMBARI-16078:
> 
> - Calculated in Stack advisor code whenever : LLAP queue is in selection and 
> (1). HSI is enabled or (2). change done to slider HSI slider "% of Cluster 
> Capacity" , or (3). change done to slider HSI slider 'Number of Daemon 
> Instances'
> - 
> - caluclations are not done if the overall cluster state is not conduciv for 
> meaningful run of LLAP.
> 
> AMBARI-16079: 
> =
> 
> Reason : If the LLAP app state is LAUNCHING and we go ahead with HSI start, 
> the overall workability of app may not be ascertained.
> As of now, using llap0 name, app does go into RUNNING_ALL state.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_interactive.py
>  f548ea3 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
>  a044fda 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-env.xml
>  816e207 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-site.xml
>  21d1109 
>   ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
> 4da21fa 
>   ambari-server/src/test/python/stacks/2.5/HIVE/test_hive_server_int.py 
> 44759a9 
>   ambari-server/src/test/python/stacks/2.5/common/test_stack_advisor.py 
> 3934301 
>   ambari-server/src/test/python/stacks/2.5/configs/hsi_default.json 1cb2a02 
> 
> Diff: https://reviews.apache.org/r/46600/diff/
> 
> 
> Testing
> ---
> 
> - Python tests added.
> - Python UT passes.
> 
> 
> --
> Ran 261 tests in 7.091s
> 
> OK
> --
> Total run:995
> Total errors:0
> Total failures:0
> OK
> 
> 
> Thanks,
> 
> Swapan Shridhar
> 
>

Re: Review Request 46600: AMBARI-16078. HiveServerInteractive. (1). Config calculations used by LLAP app. and fixes for AMBARI-16079, AMBARI-16086, AMBARI-16087


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

(Updated April 25, 2016, 9:04 a.m.)


Review request for Ambari, Alejandro Fernandez and Sumit Mohanty.


Summary (updated)
-

AMBARI-16078. HiveServerInteractive. (1). Config calculations used by LLAP app. 
 and fixes for AMBARI-16079, AMBARI-16086, AMBARI-16087


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


Repository: ambari


Description
---

Fix for : 
  (1). AMBARI-16078. Config calculations used by LLAP app. 
  
  Trivial fixes for :
  
   (2). AMBARI-16079. waiting for fixed number of times if the launched LLAP 
app is in LAUNCHING state, for it to go to RUNNING_ALL or RUNNING_PARTIAL
  (3). AMBARI-16086. Hide HSI related sliders when 'llap' queue is not being 
used.
  (4). AMBARI-16087. LLAP queue is not selected when enabling Hive Interactive 
Query during Install Wizard

AMBARI-16078:

- Calculated in Stack advisor code whenever : LLAP queue is in selection and 
(1). HSI is enabled or (2). change done to slider HSI slider "% of Cluster 
Capacity" , or (3). change done to slider HSI slider 'Number of Daemon 
Instances'
- 
- caluclations are not done if the overall cluster state is not conduciv for 
meaningful run of LLAP.

AMBARI-16079: 
=

Reason : If the LLAP app state is LAUNCHING and we go ahead with HSI start, the 
overall workability of app may not be ascertained.
As of now, using llap0 name, app does go into RUNNING_ALL state.


Diffs
-

  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_interactive.py
 f548ea3 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
 a044fda 
  
ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-env.xml
 816e207 
  
ambari-server/src/main/resources/stacks/HDP/2.5/services/HIVE/configuration/hive-interactive-site.xml
 21d1109 
  ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
4da21fa 
  ambari-server/src/test/python/stacks/2.5/HIVE/test_hive_server_int.py 44759a9 
  ambari-server/src/test/python/stacks/2.5/common/test_stack_advisor.py 3934301 
  ambari-server/src/test/python/stacks/2.5/configs/hsi_default.json 1cb2a02 

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


Testing
---

- Python tests added.
- Python UT passes.


--
Ran 261 tests in 7.091s

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


Thanks,

Swapan Shridhar

Re: Review Request 46600: AMBARI-16078. HiveServerInteractive. (1). Config calculations used by LLAP app. (2). AMBARI-16079. waiting for fixed number of times if the launched LLAP app is in LAUNCHING