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

jay vyas edited comment on BIGTOP-1222 at 5/13/14 3:40 PM:
-----------------------------------------------------------

Adding a simple pig smoke:  Right now, i dont knwo how to run the "real" pig 
smokes from a jar in gradle.   

Obviously this patch is a little rough (3 commits, has a workaround for pig), 
but basically its an easy way to validate: 

-mapreduce
-pig
-hive
-mahout

all in one pass.  

Also, these tests are "certified" as HCFS compliant, API neutral, and not 
dependent on any binaries.   Over time we can continue patching the other 
bigtop tests to make them HCFS compatible, and portable... (for right now Flume 
depends on HDFS, and Sqoop depends on MySQL, so there is more work to do on 
that front).

Any thoughts on the major points?  After that ill refine it (remove hardcoded 
paths, add a few more defensive checks). 


was (Author: jayunit100):
Adding a simple pig smoke:  Right now, i dont knwo how to run the "real" pig 
smokes from a jar in gradle.   

Obviously this patch is a little rough (3 commits, has a workaround for pig), 
but basically its an easy way to validate: 

-mapreduce
-pig
-hive
-mahout

all in one pass.

> 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
>    Affects Versions: 0.7.0
>            Reporter: jay vyas
>             Fix For: backlog
>
>         Attachments: BIGTOP-1222-2.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