-Your Project Management Committee met yesterday
Stack 2012-03-29, 03:58
The bulk of the HBase Project Management Committed (PMC)  met
yesterday at the StumbleUpon offices in SF ahead of the HBase
Meetup  that happened later in the evening. We are posting the
dev list the agenda and minutes to let you all know what was discussed
but also to solicit input and comment.
(Its a bit long. Sorry about that).
A suggested agenda had been put on the private mailing list the day
before soliciting that folks add their own items ahead of the meeting.
The hope was that we'd put the agenda out on the dev mailing list
before the meeting started to garner more suggestions but that didn’t
The agenda items below sort of followed on from the contributor
pow-wow we had at salesforce a while back [1,2,3] but it was thought
that we could go into more depth on a few of the topics raised then,
in particular, project existential matters.
+ Where do we want HBase to be in two years? What will success look
like? Discuss. Make a short list.
+ How do we achieve the just made short list? What resources do we
have to hand? What can we deploy in the short term to help achieve our
just stated objectives? What do we need to prioritize in near future?
Make a short list.
+ How do we exchange best practices/design decisions when developing
new features? Sometimes there may be more things that can be shared if
everyone follows the same best practices, and less features need to be
1. HBase pow-wow at SalesForce Agenda,
2. HBase pow-wow at SalesForce Minutes:
3. Jon Hsieh's summary of the pow-wow:
Todd, the secretary, took notes. St.Ack summarized his notes into the
below minutes. The meeting started at about 4:20 (after the requisite
20 minutes dicking w/ A/V/ and dial-in setup).
First Agenda Item: “Where do we want HBase to be in two years? What
will success look like? Discuss. Make a short (actionable) list.”
Secondary indexes and transactions were suggested as was operations on
a parity w/ MySQL and rock solid stable so it could be used as primary
copy of data. It was also suggested that we expend effort making
HBase more usable out of the box (auto-tuning/defaults).
Then followed discussion of who is HBase for? Big companies? Or new
users, or startups? Is our goal stimulating demand and creating
demand? Or is it to be reactive to what problems people are actually
hitting? A dose of reality had it that while it would be nice to make
all possible users happy, and even to talk about doing this, in
actuality, we are mostly going to focus on what our employers need
rather than prospective ‘customers’.
After this detour, the list making became more blunt and basic. It
was suggested that we build a rock solid db which other people might
be able to build on top of for higher-level stuff. The core engine
needs to work reliably -- lets do this first -- and then talk of new
features and add-ons. Meantime, we can point users to coprocessers
for building extensions and features w/o their needing to touch core
hbase (It was noted that we are open to extending CPs if we have to to
extend the ‘control surface’ exposed but that coverage has been pretty
much sufficient up to this). Usability is important but operability
is more important. Don’t need to target n00bs. First nail ops being
able to understand whats going on.
After further banter, we arrived at list: reliability, operability
(insight into the running application, dynamic config. changes,
usability improvements that make it easier on a clueful ops), and
performance. It was offered that we are not too bad on performance --
especially in 0.94 -- and that use cases will drive the performance
improvements so focus should be on the first two items in the list.
Second Agenda Item: “How do we achieve the just made short list?”
To improve reliability, testing has to be better. This has been said
repeatedly in the past. It was noted that progress has been made at
least on our unit test story (Tests have been //ized, more of hbase is
now testable because of refactorings). Progress on integration tests
and or contributions to Apache Bigtop have not progressed. As is,
BigTop is a little "cryptic"; its a different harness with shim layers
to insulate against version changes. We should help make it easier.
We should add being able to do fault injection. Should hbase
integration tests be done out in the open continuously running on
something like an EC2 cluster that all can observe? This is the
BigTop goal but its not yet there. Of note, EC2 can’t be used
validating performance. Too erratic. Bottom line, improving testing
requires bodies. Resources such as hardware, etc., are relatively
easy to come by. Hard is getting an owner and bodies to write the
tests and test infrastructure. Each of us has our own hack testing
setup. Doing a general test infrastructure whether on BigTop or not
is a bit of chicken and egg problem. Lets just make sure that who
ever hits the need to do this general test infrastructure tooling
first, that they do it out in the open and that we all pile on and
help. Meantime we'll keep up w/ our custom test tools.
Regards the current state of reliability, its thought that as is, we
can’t run a cluster continuously w/ a chaos monkey operating. There
are probably still “hundreds of issues” to be fixed before we’re at a
state where we can run for days under “chaos monkey” conditions.
For example, a
-Re: Your Project Management Committee met yesterday
Stack 2012-03-29, 18:02
I put the meeting minutes up on our blog:
-Re: Your Project Management Committee met yesterday
Luke Lu 2012-03-31, 01:09
Thanks for the transparency, lads. Good stuff!
On Thu, Mar 29, 2012 at 11:02 AM, Stack <[EMAIL PROTECTED]> wrote:
> I put the meeting minutes up on our blog:
-Your Project Management Committee voted to distingush Committer and PMC status
Stack 2012-05-31, 14:49
Just a note to say that your Project Member Committee has voted to
disentangle committer and PMC status. Up to this, in the HBase
project, a newly-made committer was automatically added to the PMC.
As of now, this will no longer be the case. Rather, after being made
a committer, a separate vote will be needed to made a committer into a
The vote and discussion happened up on the private Project Management.
The main argument in favor was that this disentangling would lower
the barrier adding new committers to the HBase project.
Let us know if you have any questions on the above,