hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Hadoop Wiki] Update of "SystemTestingConfCallSynopsis" by SteveWatt
Date Fri, 04 Dec 2009 22:13:35 GMT
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.


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)

View raw message