The upgrade test looks something like:

* Start up 1.4 (or 1.5)
* Create tables with a variety of configurations (LZO/Snappy/GZ, Bloom
Filter On/Off, Block Cache On/Off)
* Load some data into these tables, enough such that flushes and
compactions start to occur.
* Abruptly kill all of the servers. This ensures that there are WALs
around. Unfortunately, we can't have any compactions in progress at this
point, since that causes a Fate Operation, and that would prevent the
upgrade from completing.
* Upgrade the bits, start 1.6, and wait for the upgrade steps to finish.
* Check for data loss
* Trigger some compactions and wait for those to finish. In a previous
iteration, we discovered an issue where the relative path'd files and WALs
were not being properly deleted from !0.
* Check for data loss.
* Restart the tablet servers to force tablets to reload (test for orphaned
* Check for data loss.

We did not try using custom iterators.

On Wed, Jul 30, 2014 at 4:58 PM, Christopher <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB