Lack of support for HBase native at rest encryption is something that could be documented. For me it's an important gap so I'd still have to think about it. Putting it in to a release headed for production would in effect commit me to fixing it if nobody else is working on it.
A lack of tooling to detect and repair corruption is more fundamental. Can't have that missing in a release meant for production. Confirming no perf or stability regressions is also critical for prod. None of these concerns are operative if we are happy to let MOB bake on trunk for a while, but since there's a rush to put it in a 1.x release, now the work has to happen. > On May 22, 2015, at 1:33 PM, Jonathan Hsieh <j...@cloudera.com> wrote: > > On Fri, May 22, 2015 at 12:40 PM, Andrew Purtell <apurt...@apache.org> > wrote: > >> Another point of clarification, sorry, I hit the send button too early it >> seems: I don't believe MOB is fully integrated yet, for example the feature >> is an extension to store that lacks support for encryption (this would >> technically be a feature regression); and HBCK. I have not been following >> MOB too closely so could be mistaken. These issues do not preclude a merge >> of MOB into trunk, but do preclude a merge back of MOB from trunk to >> branch-1. I would veto the latter until such shortcomings in the >> implementation that could be described as regressions are addressed. I >> would also like to see a performance analysis of a range of workloads >> before and after in as much detail as can be mustered, and would be happy >> to volunteer to help out with that. > I agree that mob is close to ready for trunk merge and that there should be > a higher bar for features merging into production 1.x branches. The items > brought up should be addressed -- I'll address the specific mob concerns on > the mob merge discuss thread. > > Like other new features that have been merged and committed into the the > 1.x line, the mob feature is optional-to-use and should have negligible > impact if not used. I'd use the same criteria as the other young features > that have been called out in the 1.0.x and 1.1.x releases -- allow merge > once concerns are addressed by code fixes or documentation (e.g. explicitly > stating limitations). > > Nick Dimiduk initially wanted the feature in 1.1, but the feature missed > the train when we found some acid violations in the feature. This blocking > problem has since been fixed. Sean's list of suggestions is a reasonable > wishlist, and given that July is 1.5 months away, I think there is > reasonably sufficient time to make the 1.2 train. > > >> >> On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <apurt...@apache.org> >> wrote: >> >>> I was also thinking about RMing for 1.2 as we try and bring something >> post >>> 1.0 into production at my employer. >>> >>> Related, of the list of features proposed I would strongly prefer MOB not >>> be included. >>> >>> >>> >>>> On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bus...@cloudera.com> >>> wrote: >>> >>>> Hi folks! >>>> >>>> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July. >>>> >>>> Here's an initial list of things I want to get out: >>>> >>>> * MOB >>>> >>>> * native crc >>>> >>>> * incremental improvements for procedure v2 >>>> >>>> * adding Java 8 as supported >>>> >>>> >>>> Anything else folks want to see called out? >>>> >>>> -- >>>> Sean >>> >>> >>> >>> -- >>> Best regards, >>> >>> - Andy >>> >>> Problems worthy of attack prove their worth by hitting back. - Piet Hein >>> (via Tom White) >> >> >> >> -- >> Best regards, >> >> - Andy >> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein >> (via Tom White) > > > > -- > // Jonathan Hsieh (shay) > // HBase Tech Lead, Software Engineer, Cloudera > // j...@cloudera.com // @jmhsieh
