Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change 
notification.

The "SystemTestingConfCallSynopsis" page has been changed by SteveWatt.
http://wiki.apache.org/hadoop/SystemTestingConfCallSynopsis

--------------------------------------------------

New page:
This page provides a synopsis of the conference call held to discuss HADOOP-6332

=== Attendees ===

Konstantin Boudnik (Yahoo), Alex Loddengaard (Cloudera), Steve Loughran (HP), 
Steve Watt (IBM), Stuart Hood (Rackspace)

=== Definition ===

Cluster QA - Provide Quality Assurance by verifying with runtime testing that a 
Hadoop Cluster is setup and working correctly. At present there is no way to do 
this. There are existing tests like TeraSort but they only test certain aspects 
of the system.

=== Requirements ===

Each attendee described their requirements and what they would like to see from 
the end product.

General Consensus : There is a user need for regression testing (''' on what 
specifically? ''')

Steve Loughran : 
 * Dynamic cluster testing
 * Cluster QA 

Steve Watt : 
 * Verify that Hadoop works on IBM Java and IBM distributions such as RHEL and 
SLES.
 * Cluster QA
 * Reduce QA time (The existing functional tests take too long and distributed 
execution might reduce the overall time)

Alex Loddengaard: 

 * Cluster QA

Kostantin Boudnik:

 * Cluster QA

=== Initial Proposal ===

 * Deployment is a separate concern from Testing. Deployment is outside of the 
scope of this JIRA. Users will be responsible for setting up their cluster. 
 * Deployment information is provided as a set of parameters (possibly 
environment variables) to the testing framework.
 * Create a 'Cluster QA' set of JUNIT based tests. Start by selecting several 
of the existing functional tests and port them to run over the cluster.
 * Contain the tests inside a hadoop-version-test.jar (or alternatively 
separate jobs for each project split, i.e. mapred-test, hdfs-test etc.)
 * Design the framework such that is able to take the parameters specified and 
run the tests in the test jar specified against the cluster identified.
 * Once the cluster is running the tests could be run against the default 
cluster with something like : "bin/hadooop -verify" 
 * Start collecting data on how long system tests (such as TeraSort) take to 
run on certain cluster configurations so we can provide users a benchmark they 
can use to validate the health of their cluster.


=== Next Steps ===

 * Iterate in public (publish this Wiki Link and the Meeting Wiki Page to the 
mailing lists to solicit feedback)
 * Get community engagement and consensus on approach
 * Provide first drop of code 

=== Available Resources ===

 * Stephen Watt (70 % of his time)
 * Konstantin Boudnik (100 % of his time)

Reply via email to