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

jay vyas edited comment on BIGTOP-1222 at 7/29/14 7:41 PM:
-----------------------------------------------------------

- ok regarding pi , your right ! The 1000 is for the *number of samples*, which 
doesnt result in any real extra compute time.  updated. I had confused that w/ 
number of maps.  

- Comment improvements:  I can remove them if you really feel its necessary, 
but Id rather keep them in.  here is my argument for keeping them: they are a 
non functional change which improves the understandability of the tests... and 
that is part of the overall goal of the patch.

- Dependencies inheritance: I actually tried this but it failed.   I think it 
could be gradle version dependent, and that scares me also.  So I think the 
right thing to do is actually implement this JIRA:  BIGTOP-1384.   

if necessary to put in these changes i will do so, otherwise lets push it in so 
others can help improve it :) 


was (Author: jayunit100):
- ok regarding pi , your right ! The 1000 is for the *number of samples*, which 
doesnt result in any real extra compute time.  updated. I had confused that w/ 
number of maps.  

- Comment improvements:  I can remove them if you really feel its necessary, 
but Id rather keep them in.  here is my argument for keeping them: they are a 
non functional change which improves the understandability of the tests... and 
that is part of the overall goal of the patch.

- Dependencies inheritance: I actually tried this but it failed.   I think it 
could be gradle version dependent, and that scares me also.  So I think the 
right thing to do is actually implement this JIRA:  BIGTOP-1384.   

> Simplify and gradleize a subset of the bigtop smokes
> ----------------------------------------------------
>
>                 Key: BIGTOP-1222
>                 URL: https://issues.apache.org/jira/browse/BIGTOP-1222
>             Project: Bigtop
>          Issue Type: Improvement
>          Components: Build, Tests
>    Affects Versions: 0.7.0
>            Reporter: jay vyas
>            Assignee: Konstantin Boudnik
>             Fix For: backlog
>
>         Attachments: BIGTOP-1222-2.patch, BIGTOP-1222.patch, 
> BIGTOP-1222.patch, BIGTOP-1222.patch, BIGTOP-1222.patch, BIGTOP-1222.patch, 
> BIGTOP-1222.patch, BIGTOP-1222.patch, BIGTOP-1222.patch, BIGTOP-1222.patch, 
> BIGTOP-1222.patch, BIGTOP-1222.patch, BIGTOP-1222.patch
>
>
> (Rewritten the description for clarity)
> We need an easier way to run bigtop smoke tests, and gradle provides this:
> 1) Easy to script/modify
> 2) Human readable
> 3) equally oriented towards both groovy and plain old java
> The advantage of this method to running smokes : 
> 1) No need to compile a jar : this is a costly step and not much value added, 
> also creates indirection which can make debugging a broken test very hard.
> 2) Simple: A smoke test doesnt need to make low level API calls or be 
> compiled against the right APIs - rather, it should test the end user 
> interface ("hive -q  ....", "pig -x ....", "hadoop jar ....", and so on).  
> 3) Customizable:  The smoke tests shouldnt require users to have to write XML 
> and debug environmental variables / grep around for System properties etc.  
> Rather, a high level controller should do all that checking for you.  
> The initial idea was to write a python/bash implementation wrapper of 
> scripts, but that was replaced by the idea of using gradle.  The advantage of 
> gradle is that we don't need to manually set the classpath and run groovy 
> commands: Gradle wraps groovy scripts in their native java context quite 
> nicely - but it doesnt add any other unnecessary overhead (xml, jar files, no 
> need for complex xml tag wrappers for simple tasks - just plain groovy code).
> So, here the goal is just to create a nice, clean, extensible non-jar, 
> non-API dependent gradle runner for the smoke tests which exersizes the 
> hadoop cluster the same way a typical end-user would.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to