I updated the roadmap up on the wiki:
* Data integrity
* Insure that proper append() support in HDFS actually closes the
WAL last block write hole
* HBase-FSCK (HBASE-7) -- Suggest making this a blocker for 0.21
I have had several recent conversations on my travels with people in
Fortune 100 companies (based on this list:
http://www.wageproject.org/content/fortune/index.php).
You and I know we can set up well engineered HBase 0.20 clusters that
will be operationally solid for a wide range of use cases, but given
those aforementioned discussions there are certain sectors which would
say HBASE-7 is #1 before HBase is "bank ready". Not until we can say:
- Yes, when the client sees data has been committed, it actually has
been written and replicated on spinning or solid state media in all
cases.
- Yes, we go to great lengths to recover data if ${deity} forbid you
crush some underprovisioned cluster with load or some bizarre bug or
system fault happens.
HBASE-1295 is also required for business continuity reasons, but this
is already a priority item for some HBase committers.
The question is I think does the above align with project goals.
Making HBase-FSCK a blocker will probably knock something someone
wants for the 0.21 timeframe off the list.
- Andy
