Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Jonathan Hsieh <jo...@cloudera.com>]

The feature is definitely not abandoned -- we have few sizable customers at
PB scale that I can recall off the top of my head that have been using it
for over 8-12 months in the version backported to CDH (we backported an
early version back in oct/14 (CDH5.2), and updated with the recent more
recent changes in roughly may/15 (CDH5.4).   These are used primarily to
store documents -- think PDF files. They are pretty happy -- the customer
reported that it was slightly slower on the write side (10-15%) than a
competing system but significantly faster on the read side (3x-4x
throughput).

Over the holidays we shook out a semi-rare data loss issue with mob
compaction that had this as the root cause[1] -- (since pointers are only
stored in the "normal hfiles" the volume of datas on this case was fairly
large).

We've been working on trying to get at least one of them to present at
hbasecon, but I'm not reviewing submissions this year and don't know if
they made it or not.

Jon.

[1] https://issues.apache.org/jira/browse/HBASE-15035

On Fri, Feb 26, 2016 at 12:27 PM, Andrew Purtell <ap...@apache.org>
wrote:

> ​I think we need at least one success story or one very interested user
> with a real project on the line to justify a backport. Otherwise it's a
> feature without any users - technically, abandoned. ​
>
> On Fri, Feb 26, 2016 at 10:11 AM, Ted Yu <yu...@gmail.com> wrote:
>
> > I am interested in hearing about user experience with MOB feature as
> well.
> >
> > In my opinion, this feature is a nice addition to branch-1.
> >
> > On Wed, Feb 10, 2016 at 1:45 PM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > +user@
> > >
> > > Is there anyone using the MOB feature in trunk for anything who can
> > comment
> > > on how well it's been working out? Intel folks maybe?
> > >
> > > On Thu, Jan 21, 2016 at 7:46 AM, Sean Busbey <bu...@apache.org>
> wrote:
> > >
> > > > The last time MOB on branch-1 came up, folks were concerned that it
> > > > wasn't stable enough in master yet. Is that still the case?
> > > >
> > > > Can we get a [DISCUSS] flagged thread to see what, if anything, folks
> > > > would like to see gate inclusion in branch-1?
> > > >
> > > > On Tue, Jan 19, 2016 at 7:31 PM, Jonathan Hsieh <jo...@cloudera.com>
> > > wrote:
> > > > > +1 to 1.2 being feature complete corrently.  There has already
> been a
> > > > > release candidate and folks are burning down the blockers currently
> > to
> > > > prep
> > > > > for the next RC.
> > > > >
> > > > > I like the idea of mob and sparkonhbase for 1.3.  I'm more
> > comfortable
> > > > with
> > > > > sparkonhbase -- it is a new module and thus not as invasive.
> > > > >
> > > > > Jon.
> > > > >
> > > > > On Tue, Jan 19, 2016 at 4:55 PM, Andrew Purtell <
> > > > andrew.purtell@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Pretty sure Sean expressed 1.2 is feature complete and I'd support
> > > that.
> > > > >> Can we wait for 1.3 for MOB ? Can look at Spark connector then
> too.
> > > > >>
> > > > >> > On Jan 19, 2016, at 4:52 PM, Ted Yu <yu...@gmail.com>
> wrote:
> > > > >> >
> > > > >> > Looks like 1.2.0 RC is in near future.
> > > > >> >
> > > > >> > I wonder if it is time to revive this thread (due to customer
> > > > interest).
> > > > >> >
> > > > >> > As far as I can tell, the Mob related tests have been passing in
> > the
> > > > >> recent
> > > > >> > past.
> > > > >> >
> > > > >> > Thanks
> > > > >> >
> > > > >> >> On Wed, Oct 28, 2015 at 2:07 PM, Andrew Purtell <
> > > apurtell@apache.org
> > > > >
> > > > >> wrote:
> > > > >> >>
> > > > >> >> I haven't heard an user answer in the affirmative to wanting
> it.
> > > > >> >>
> > > > >> >> I'll volunteer to RM 1.3, whenever we need it. Premature to
> have
> > > that
> > > > >> >> discussion without 1.2 even out the door yet, though.
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> On Wed, Oct 28, 2015 at 1:01 PM, Stephen Jiang <
> > > > syuanjiangdev@gmail.com
> > > > >> >
> > > > >> >> wrote:
> > > > >> >>
> > > > >> >>> Actually, it is actively changing in master branch on MOB
> > feature
> > > > made
> > > > >> me
> > > > >> >>> think about: if we ever want to port MOB feature to branch-1,
> > now
> > > > is a
> > > > >> >> good
> > > > >> >>> time.  We can commit changes in both branches; otherwise, we
> > > > probably
> > > > >> >> would
> > > > >> >>> miss some commits when we port MOB to branch-1 in a late time.
> > > > >> >>>
> > > > >> >>> I am more thinking about 1.3 release (certainly not 1.2),
> which
> > we
> > > > >> still
> > > > >> >>> have some time to stabilize and allow interesting party to
> play
> > > with
> > > > >> the
> > > > >> >>> feature and give feedback.
> > > > >> >>>
> > > > >> >>> Thanks
> > > > >> >>> Stephen
> > > > >> >>>
> > > > >> >>> PS. given the features we discussed in 2.0.0 in the last
> > community
> > > > >> >> meeting,
> > > > >> >>> I think it would not release earlier than 1.3 :-), unless we
> > > > >> >> intentionally
> > > > >> >>> not find a release manager for 1.3.
> > > > >> >>>
> > > > >> >>>
> > > > >> >>>
> > > > >> >>>
> > > > >> >>>> On Wed, Oct 28, 2015 at 9:09 AM, Sean Busbey <
> > > busbey@cloudera.com>
> > > > >> >>> wrote:
> > > > >> >>>
> > > > >> >>>> It's practically November. Matteo, are you up for a thread on
> > > > target
> > > > >> >>>> dates for 2.0.0 to start RCs?
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>>> On Wed, Oct 28, 2015 at 11:02 AM, Elliott Clark <
> > > eclark@apache.org
> > > > >
> > > > >> >>> wrote:
> > > > >> >>>>> I feel the same lets keep branch-1 stable, and work towards
> a
> > > > faster
> > > > >> >>>> 2.0.0.
> > > > >> >>>>>
> > > > >> >>>>>> On Tue, Oct 27, 2015 at 4:52 PM, Stack <st...@duboce.net>
> > > wrote:
> > > > >> >>>>>>
> > > > >> >>>>>> IMO, MOB is still not settled in Master. It has a bunch of
> > > flakey
> > > > >> >>> tests
> > > > >> >>>>>> that are getting fixed by Jingcheng or I've disabled them
> > till
> > > > >> >> someone
> > > > >> >>>> has
> > > > >> >>>>>> time to look at them. There is also a load of duplicated
> code
> > > > that
> > > > >> >> is
> > > > >> >>>> being
> > > > >> >>>>>> cleaned up (Matteo).
> > > > >> >>>>>>
> > > > >> >>>>>> Its not ready to go back to branch-1 IMO.
> > > > >> >>>>>>
> > > > >> >>>>>> Are there users who'd like it backported?
> > > > >> >>>>>> St.Ack
> > > > >> >>>>>>
> > > > >> >>>>>>
> > > > >> >>>>>> On Mon, Oct 26, 2015 at 10:55 AM, Stephen Jiang <
> > > > >> >>>> syuanjiangdev@gmail.com>
> > > > >> >>>>>> wrote:
> > > > >> >>>>>>
> > > > >> >>>>>>> Hello, guys, the MOB is in master branch.  I saw bug fixes
> > > > >> >> happening
> > > > >> >>>> in
> > > > >> >>>>>>> master branch.
> > > > >> >>>>>>>
> > > > >> >>>>>>> I just wonder whether there is a plan to put MOB in
> > > branch-1.  I
> > > > >> >> am
> > > > >> >>>>>> afraid
> > > > >> >>>>>>> if we don't do it now, it would be harder in the future to
> > > back
> > > > >> >> port
> > > > >> >>>> if
> > > > >> >>>>>> we
> > > > >> >>>>>>> decide to do it in a late time.
> > > > >> >>>>>>>
> > > > >> >>>>>>> Thanks
> > > > >> >>>>>>> Stephen
> > > > >> >>>>>>>
> > > > >> >>>>>>> On Thu, Jul 23, 2015 at 1:15 PM, Andrew Purtell <
> > > > >> >>> apurtell@apache.org>
> > > > >> >>>>>>> wrote:
> > > > >> >>>>>>>
> > > > >> >>>>>>>> Thanks Jon.
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> When I'm back in the office I'll check out master and
> have
> > a
> > > > >> >> look
> > > > >> >>>> into
> > > > >> >>>>>>> any
> > > > >> >>>>>>>> locally repeatable test failures. Anyway in my opinion at
> > > this
> > > > >> >>>> point it
> > > > >> >>>>>>>> would make the most sense for us to keep the MOB changes
> in
> > > on
> > > > >> >>>> master
> > > > >> >>>>>> and
> > > > >> >>>>>>>> deal with any fallout in follow on issues. I think all
> who
> > > > voted
> > > > >> >>> +1
> > > > >> >>>> for
> > > > >> >>>>>>>> this change were aware that large changes like this can
> > have
> > > a
> > > > >> >>>>>>> temporarily
> > > > >> >>>>>>>> destabilizing effect. As long as the MOB devs are around
> to
> > > > help
> > > > >> >>>> clean
> > > > >> >>>>>>> up,
> > > > >> >>>>>>>> we should be good!
> > > > >> >>>>>>>>
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> On Wed, Jul 22, 2015 at 8:09 PM, Jonathan Hsieh <
> > > > >> >> jon@cloudera.com
> > > > >> >>>>
> > > > >> >>>>>>> wrote:
> > > > >> >>>>>>>>
> > > > >> >>>>>>>>> I had two clean full builds/unit test on my internal
> setup
> > > and
> > > > >> >>> the
> > > > >> >>>>>>> latest
> > > > >> >>>>>>>>> build went back to ~4325 total tests and failures on
> > > Procedure
> > > > >> >>>> relate
> > > > >> >>>>>>>> tests
> > > > >> >>>>>>>>> cases.
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>> I don't think mob is responsible for these failures.
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>> Jon.
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>> On Wed, Jul 22, 2015 at 4:32 PM, Jonathan Hsieh <
> > > > >> >>> jon@cloudera.com
> > > > >> >>>>>
> > > > >> >>>>>>>> wrote:
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>>> Although the the precommit buiid passed, and the
> > > compilation
> > > > >> >>> and
> > > > >> >>>>>> mob
> > > > >> >>>>>>>>>> testing I ran after before the merge was commited
> passed,
> > > It
> > > > >> >>>> looks
> > > > >> >>>>>>> like
> > > > >> >>>>>>>>>> the first full build after the merge [1] failed.  It
> > looked
> > > > >> >>> like
> > > > >> >>>>>>>>>> something hung along the way, and that most of the
> > previous
> > > > >> >>>> builds
> > > > >> >>>>>>> had
> > > > >> >>>>>>>>>> failed for various reasons. :(
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>> I kicked it off again have it do another try.  If it is
> > mob
> > > > >> >>>> related
> > > > >> >>>>>>>> we'll
> > > > >> >>>>>>>>>> take hunt it down and take care of it.
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>> Jon.
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>> [1] https://builds.apache.org/job/HBase-TRUNK/6672/
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>> On Wed, Jul 22, 2015 at 1:16 PM, Jonathan Hsieh <
> > > > >> >>>> jon@cloudera.com>
> > > > >> >>>>>>>>> wrote:
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>>> I've merged the code in to master.  Thanks for all the
> > > hard
> > > > >> >>>> work
> > > > >> >>>>>>>>>>> Jingcheng and thanks to all who have been involved
> with
> > > > >> >>>> reviews,
> > > > >> >>>>>>>>>>> discussion, and voting!
> > > > >> >>>>>>>>>>>
> > > > >> >>>>>>>>>>> Jon
> > > > >> >>>>>>>>>>>
> > > > >> >>>>>>>>>>> On Wed, Jul 22, 2015 at 12:45 AM, Jingcheng Du <
> > > > >> >>>>>>>> jingcheng.du@intel.com>
> > > > >> >>>>>>>>>>> wrote:
> > > > >> >>>>>>>>>>>
> > > > >> >>>>>>>>>>>> Hi all,
> > > > >> >>>>>>>>>>>>
> > > > >> >>>>>>>>>>>> The vote passes with 8 +1s and no -1. Thanks all for
> > > > >> >>> guiding,
> > > > >> >>>>>>> helping
> > > > >> >>>>>>>>> and
> > > > >> >>>>>>>>>>>> voting!
> > > > >> >>>>>>>>>>>> We will work on the merge activities and will let
> guys
> > > > >> >> know
> > > > >> >>>> about
> > > > >> >>>>>>> the
> > > > >> >>>>>>>>>>>> detailed plan for merge time.
> > > > >> >>>>>>>>>>>> And thanks Jon for helping merge this branch to
> trunk!
> > > > >> >>>>>>>>>>>>
> > > > >> >>>>>>>>>>>> Regards,
> > > > >> >>>>>>>>>>>> Jingcheng
> > > > >> >>>>>>>>>>>>
> > > > >> >>>>>>>>>>>>
> > > > >> >>>>>>>>>>>>
> > > > >> >>>>>>>>>>>> --
> > > > >> >>>>>>>>>>>> View this message in context:
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> http://apache-hbase.679495.n3.nabble.com/RESULT-VOTE-Merge-branch-hbase-11339-HBase-MOB-to-trunk-tp4073446.html
> > > > >> >>>>>>>>>>>> Sent from the HBase Developer mailing list archive at
> > > > >> >>>> Nabble.com.
> > > > >> >>>>>>>>>>>
> > > > >> >>>>>>>>>>>
> > > > >> >>>>>>>>>>>
> > > > >> >>>>>>>>>>> --
> > > > >> >>>>>>>>>>> // Jonathan Hsieh (shay)
> > > > >> >>>>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
> > > > >> >>>>>>>>>>> // jon@cloudera.com // @jmhsieh
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>> --
> > > > >> >>>>>>>>>> // Jonathan Hsieh (shay)
> > > > >> >>>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
> > > > >> >>>>>>>>>> // jon@cloudera.com // @jmhsieh
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>> --
> > > > >> >>>>>>>>> // Jonathan Hsieh (shay)
> > > > >> >>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
> > > > >> >>>>>>>>> // jon@cloudera.com // @jmhsieh
> > > > >> >>>>>>>>
> > > > >> >>>>>>>>
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> --
> > > > >> >>>>>>>> Best regards,
> > > > >> >>>>>>>>
> > > > >> >>>>>>>>   - Andy
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> Problems worthy of attack prove their worth by hitting
> > back.
> > > -
> > > > >> >>> Piet
> > > > >> >>>>>> Hein
> > > > >> >>>>>>>> (via Tom White)
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>>> --
> > > > >> >>>> Sean
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> --
> > > > >> >> 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
> > > > > // jon@cloudera.com // @jmhsieh
> > > >
> > >
> > >
> > >
> > > --
> > > 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
// jon@cloudera.com // @jmhsieh

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Stack <st...@duboce.net>]

On Mon, Feb 29, 2016 at 6:56 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:

> ...
> We've been working on trying to get at least one of them to present at
> hbasecon, but I'm not reviewing submissions this year and don't know if
> they made it or not.
>
> This did not happen. The use case is to surface in another forum soon
though....
St.Ack

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Ted Yu <yu...@gmail.com>]

Jon:
Mind taking a look at this attachment for list of commits (in case I missed
any):

https://issues.apache.org/jira/secure/attachment/12791047/mob-cmmits.txt


Thanks

On Wed, Mar 2, 2016 at 7:26 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:

> Most of the patches should have some mention of "mob" in their titles.
> Another sure sign is to look for commits attributed to jingcheng du -- he
> contributed the majority of the patches.  I did a few mostly adding flags
> for testing and that bulk load related bug fix.
>
> I'll review the list of patches as part of any branch merge proposal to
> make sure all the necessary ones are present.
>
> On more minor thing -- instead of the longish hbase-11339-branch-1 name I
> proposed -- naming the branch the name umbrella jira of the backport
> (hbase-15370) would make it even easier to track provenance of the branch.
>
> Jon.
>
> On Wed, Mar 2, 2016 at 6:44 PM, Devaraj Das <dd...@hortonworks.com> wrote:
>
> > Sounds good to me, Jonathan. Although I suspect that at the end this will
> > be close to what Ted Yu has in the backport patch but this is a more
> > structured / reliable way of doing it. When you say this - "backport the
> > patches that came after the merge to trunk....", is there a reliable way
> to
> > identify all those. In the backport jira, there is a mention of some
> > additional jiras after the original merge - https://goo.gl/6stN7Y - we
> > need to make sure if these are the only ones relevant.
> > ________________________________________
> > From: Jonathan Hsieh <jo...@cloudera.com>
> > Sent: Wednesday, March 02, 2016 2:03 PM
> > To: dev@hbase.apache.org
> > Subject: Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch
> hbase-11339
> > HBase MOB to trunk)
> >
> > I'll offer what I think would be another reasonable and likely less
> > destabilizing approach:  essentially treat it as a branch.  We could
> start
> > from the existing hbase-11339 branch, call it hbase-11339-branch-1 and do
> > the work to merge it into branch-1 (instead of trunk).  To merge into
> > branch-1 it would require the 3 +1's just like any other branch merge.
> >
> > Mob initially started off as a mega patch and was broken down and
> committed
> > in reviewable pieces to branch hbase-11339.  Most of this was actually
> when
> > 1.0.0-SNAPSHOT was trunk so many of the older commits may actually jive
> > better with branch-1. Towards the end we did periodic merge commits with
> > trunk as we shook out issues integration testing found, and as branch
> merge
> > reviews uncovered other short comings.  These merge patches actually
> showed
> > how we modified the mob code to account for the later changes in trunk.
> In
> > this particular case we coud take hbase-11339-branch-1,  backport the
> > patches that came after the merge to trunk with the normal single +1
> review
> > process on the branch, and then propose a branch merge with branch-1.
> When
> > all pieces are ready and we had stable unit tests (admittedly that was a
> > one shortcoming when I sheparded hbase-11339) we do 3 +1s to merge to
> > branch-1 (and possibly branch-1.3).
> >
> > This has the nice benefit compared to andrew's suggesting of not
> > potentially blocking branch-1 or having a half complete mob feature in
> > branch-1 if hbase-11339-branch-1 isn't ready.
> >
> > Jon.
> >
> >
> >
> >
> > On Wed, Mar 2, 2016 at 1:31 PM, Andrew Purtell <andrew.purtell@gmail.com
> >
> > wrote:
> >
> > > On the question of change provenance, if I can make a suggestion: How I
> > > would approach the backport of a feature developed in trunk over
> multiple
> > > commits and JIRAs is I would look through git history, find each
> related
> > > commit, and apply each commit in sequence to branch-1, fixing things up
> > as
> > > needed each time. Then the resulting working branch can be pushed up to
> > aid
> > > review of the aggregate result by the MOB developers and the larger
> > > community. Ted, if you approached the backport in this way, then
> pushing
> > up
> > > your working branch will aid review.
> > >
> > > > On Mar 2, 2016, at 1:17 PM, Andrew Purtell <andrew.purtell@gmail.com
> >
> > > wrote:
> > > >
> > > > I concur with Stack's concerns with a developer not involved in
> > building
> > > the MOB feature attempting a backport in general, and furthermore
> without
> > > detailed provenance of all of the incorporated changes. I'm also
> > concerned
> > > about how well MOB works in real production given people use branch-1
> in
> > > production and not trunk.
> > > >
> > > > As for Ted's issue, I'm not going to let him commit it (I will veto)
> > > without clear proof that it works and doesn't hurt perf of non MOB
> cases
> > by
> > > way of reproducible benchmarks - benchmarks I can personally reproduce
> > > afterward (I'm not volunteering to do Ted's necessary legwork) - done
> > with
> > > branch-1 with the proposed patch applied. We are not there yet though,
> > > barely, into review, but this will be coming up very soon.
> > > >
> > > >>> On Mar 2, 2016, at 1:03 PM, Stack <st...@duboce.net> wrote:
> > > >>>
> > > >>> On Wed, Mar 2, 2016 at 11:26 AM, Devaraj Das <ddas@hortonworks.com
> >
> > > wrote:
> > > >>>
> > > >>> Stack, as things stand, Ted Yu has a patch that is a backport of
> MOB.
> > > He
> > > >>> told me offline he has taken a look at the jiras that went in in
> the
> > > master
> > > >>> that is to do with MOB, and got them in the backport.
> > > >>
> > > >>
> > > >>
> > > >> On the issue, a near 800k blob is dumped which is described as "...a
> > > >> backport of MOB... " but w/o attribution of provenance nor any other
> > > >> description of what it contains. Only when this is pointed-out in
> the
> > > issue
> > > >> do we get a short listing of supposed JIRAs included with no
> > > justification
> > > >> of what is covered, what is included/excluded, and what machinations
> > > were
> > > >> done to make it fit branch-1 (Yet you offline were given this
> info?).
> > > >>
> > > >> Such poor practice only makes me more intent on my objection.
> > > >>
> > > >>
> > > >>
> > > >>> Now, to your point, I agree that someone familiar with MOB code
> > should
> > > do
> > > >>> the backport but the question is, is that dev available to do it
> now?
> > > The
> > > >>> next best thing is to get Ted Yu's patch reviewed by someone
> familiar
> > > with
> > > >>> the feature. I really hope that we can get cycles from the original
> > MOB
> > > >>> devs on this.
> > > >>
> > > >>
> > > >> MOB is unsupported? If so, lets for sure not backport it.
> > > >>
> > > >>
> > > >> Agree that we shouldn't be adding flaky tests. The question is if
> the
> > > >>> failures on master to do with MOB are really MOB related or
> something
> > > else
> > > >>> (for argument's sake, let's say, procv2)..
> > > >> Sounds like we need to spend a bit of time digging in on the flakey
> > > tests
> > > >> then. Branch-1 is pretty stable now after a bunch of expended effort
> > by
> > > a
> > > >> few folks. Would be a pity taking a step back.
> > > >>
> > > >> St.Ack
> > > >>
> > > >>
> > > >>
> > > >>> On the point about the DISCUSS thread, yeah, it's fine to do it if
> > > folks
> > > >>> feel it's the right way to go.
> > > >>> ________________________________________
> > > >>> From: saint.ack@gmail.com <sa...@gmail.com> on behalf of
> Stack <
> > > >>> stack@duboce.net>
> > > >>> Sent: Wednesday, March 02, 2016 10:55 AM
> > > >>> To: HBase Dev List
> > > >>> Subject: Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch
> > > hbase-11339
> > > >>> HBase MOB to trunk)
> > > >>>
> > > >>> (Doing another resend...)
> > > >>>
> > > >>> I have objection to you, Ted Yu, doing it. MOB has spread all about
> > > master
> > > >>> branch. Backport should be done by someone who knows MOB.
> > > >>>
> > > >>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS]
> flagged
> > > thread
> > > >>> to see what, if anything, folks
> > > >>> would like to see gate inclusion in branch-1?"  Shouldn't we do
> this
> > > before
> > > >>> we 'create a backport...'.
> > > >>>
> > > >>> For me, there should be no new flakies in branch-1. Branch-1 builds
> > > are a
> > > >>> hard-won stable(-ish). Looking at master build, MOB seems quiet
> > lately
> > > but
> > > >>> going by HBASE-15012, our flakies umbrella issue, I see notes that
> > > >>> TestMobExportSnapshot has failed a few times (that is probably
> > because
> > > the
> > > >>> test it derives from is flakey) and
> > > TestMobRestoreFlushSnapshotFromClient
> > > >>> gets a mention.
> > > >>>
> > > >>> St.Ack
> > > >>>
> > > >>>
> > > >>>
> > > >>>> On Tue, Mar 1, 2016 at 5:27 PM, Stack <st...@duboce.net> wrote:
> > > >>>>
> > > >>>> (Doing a resend of below... it doesn't seem to have gone through)
> > > >>>>
> > > >>>>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com>
> > wrote:
> > > >>>>>
> > > >>>>> If there is no objection, I will create a backport JIRA tomorrow
> > and
> > > >>>>> attach patch.
> > > >>>> I have objection to you doing it. MOB has spread all about master
> > > branch.
> > > >>>> Backport should be done by someone who knows MOB.
> > > >>>>
> > > >>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS]
> flagged
> > > >>>> thread to see what, if anything, folks
> > > >>>> would like to see gate inclusion in branch-1?"  Shouldn't we do
> this
> > > >>>> before we 'create a backport...'.
> > > >>>>
> > > >>>> For me, there should be no new flakies in branch-1. Branch-1
> builds
> > > are a
> > > >>>> hard-won stable(-ish). Looking at master build, MOB seems quiet
> > lately
> > > >>> but
> > > >>>> going by HBASE-15012, our flakies umbrella issue, I see notes that
> > > >>>> TestMobExportSnapshot has failed a few times (that is probably
> > because
> > > >>> the
> > > >>>> test it derives from is flakey) and
> > > TestMobRestoreFlushSnapshotFromClient
> > > >>>> gets a mention.
> > > >>>>
> > > >>>> St.Ack
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>> On Tue, Mar 1, 2016 at 9:32 AM, Stack <st...@duboce.net> wrote:
> > > >>>>>>
> > > >>>>>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com>
> > > wrote:
> > > >>>>>>
> > > >>>>>> If there is no objection, I will create a backport JIRA tomorrow
> > and
> > > >>>>>> attach patch.
> > > >>>>> I have objection to you doing it. MOB has spread all about master
> > > >>> branch.
> > > >>>>> Backport should be done by someone who knows MOB.
> > > >>>>>
> > > >>>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS]
> > flagged
> > > >>>>> thread to see what, if anything, folks
> > > >>>>> would like to see gate inclusion in branch-1?"  Shouldn't we do
> > this
> > > >>>>> before we 'create a backport...'.
> > > >>>>>
> > > >>>>> For me, there should be no new flakies in branch-1. Branch-1
> builds
> > > are
> > > >>> a
> > > >>>>> hard-won stable(-ish). Looking at master build, MOB seems quiet
> > > lately
> > > >>> but
> > > >>>>> going by HBASE-15012, our flakies umbrella issue, I see notes
> that
> > > >>>>> TestMobExportSnapshot has failed a few times (that is probably
> > > because
> > > >>> the
> > > >>>>> test it derives from is flakey) and
> > > >>> TestMobRestoreFlushSnapshotFromClient
> > > >>>>> gets a mention.
> > > >>>>>
> > > >>>>> St.Ack
> > > >>>
> > >
> >
> >
> >
> > --
> > // Jonathan Hsieh (shay)
> > // HBase Tech Lead, Software Engineer, Cloudera
> > // jon@cloudera.com // @jmhsieh
> >
>
>
>
> --
> // Jonathan Hsieh (shay)
> // HBase Tech Lead, Software Engineer, Cloudera
> // jon@cloudera.com // @jmhsieh
>

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Jonathan Hsieh <jo...@cloudera.com>]

Most of the patches should have some mention of "mob" in their titles.
Another sure sign is to look for commits attributed to jingcheng du -- he
contributed the majority of the patches.  I did a few mostly adding flags
for testing and that bulk load related bug fix.

I'll review the list of patches as part of any branch merge proposal to
make sure all the necessary ones are present.

On more minor thing -- instead of the longish hbase-11339-branch-1 name I
proposed -- naming the branch the name umbrella jira of the backport
(hbase-15370) would make it even easier to track provenance of the branch.

Jon.

On Wed, Mar 2, 2016 at 6:44 PM, Devaraj Das <dd...@hortonworks.com> wrote:

> Sounds good to me, Jonathan. Although I suspect that at the end this will
> be close to what Ted Yu has in the backport patch but this is a more
> structured / reliable way of doing it. When you say this - "backport the
> patches that came after the merge to trunk....", is there a reliable way to
> identify all those. In the backport jira, there is a mention of some
> additional jiras after the original merge - https://goo.gl/6stN7Y - we
> need to make sure if these are the only ones relevant.
> ________________________________________
> From: Jonathan Hsieh <jo...@cloudera.com>
> Sent: Wednesday, March 02, 2016 2:03 PM
> To: dev@hbase.apache.org
> Subject: Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339
> HBase MOB to trunk)
>
> I'll offer what I think would be another reasonable and likely less
> destabilizing approach:  essentially treat it as a branch.  We could start
> from the existing hbase-11339 branch, call it hbase-11339-branch-1 and do
> the work to merge it into branch-1 (instead of trunk).  To merge into
> branch-1 it would require the 3 +1's just like any other branch merge.
>
> Mob initially started off as a mega patch and was broken down and committed
> in reviewable pieces to branch hbase-11339.  Most of this was actually when
> 1.0.0-SNAPSHOT was trunk so many of the older commits may actually jive
> better with branch-1. Towards the end we did periodic merge commits with
> trunk as we shook out issues integration testing found, and as branch merge
> reviews uncovered other short comings.  These merge patches actually showed
> how we modified the mob code to account for the later changes in trunk.  In
> this particular case we coud take hbase-11339-branch-1,  backport the
> patches that came after the merge to trunk with the normal single +1 review
> process on the branch, and then propose a branch merge with branch-1. When
> all pieces are ready and we had stable unit tests (admittedly that was a
> one shortcoming when I sheparded hbase-11339) we do 3 +1s to merge to
> branch-1 (and possibly branch-1.3).
>
> This has the nice benefit compared to andrew's suggesting of not
> potentially blocking branch-1 or having a half complete mob feature in
> branch-1 if hbase-11339-branch-1 isn't ready.
>
> Jon.
>
>
>
>
> On Wed, Mar 2, 2016 at 1:31 PM, Andrew Purtell <an...@gmail.com>
> wrote:
>
> > On the question of change provenance, if I can make a suggestion: How I
> > would approach the backport of a feature developed in trunk over multiple
> > commits and JIRAs is I would look through git history, find each related
> > commit, and apply each commit in sequence to branch-1, fixing things up
> as
> > needed each time. Then the resulting working branch can be pushed up to
> aid
> > review of the aggregate result by the MOB developers and the larger
> > community. Ted, if you approached the backport in this way, then pushing
> up
> > your working branch will aid review.
> >
> > > On Mar 2, 2016, at 1:17 PM, Andrew Purtell <an...@gmail.com>
> > wrote:
> > >
> > > I concur with Stack's concerns with a developer not involved in
> building
> > the MOB feature attempting a backport in general, and furthermore without
> > detailed provenance of all of the incorporated changes. I'm also
> concerned
> > about how well MOB works in real production given people use branch-1 in
> > production and not trunk.
> > >
> > > As for Ted's issue, I'm not going to let him commit it (I will veto)
> > without clear proof that it works and doesn't hurt perf of non MOB cases
> by
> > way of reproducible benchmarks - benchmarks I can personally reproduce
> > afterward (I'm not volunteering to do Ted's necessary legwork) - done
> with
> > branch-1 with the proposed patch applied. We are not there yet though,
> > barely, into review, but this will be coming up very soon.
> > >
> > >>> On Mar 2, 2016, at 1:03 PM, Stack <st...@duboce.net> wrote:
> > >>>
> > >>> On Wed, Mar 2, 2016 at 11:26 AM, Devaraj Das <dd...@hortonworks.com>
> > wrote:
> > >>>
> > >>> Stack, as things stand, Ted Yu has a patch that is a backport of MOB.
> > He
> > >>> told me offline he has taken a look at the jiras that went in in the
> > master
> > >>> that is to do with MOB, and got them in the backport.
> > >>
> > >>
> > >>
> > >> On the issue, a near 800k blob is dumped which is described as "...a
> > >> backport of MOB... " but w/o attribution of provenance nor any other
> > >> description of what it contains. Only when this is pointed-out in the
> > issue
> > >> do we get a short listing of supposed JIRAs included with no
> > justification
> > >> of what is covered, what is included/excluded, and what machinations
> > were
> > >> done to make it fit branch-1 (Yet you offline were given this info?).
> > >>
> > >> Such poor practice only makes me more intent on my objection.
> > >>
> > >>
> > >>
> > >>> Now, to your point, I agree that someone familiar with MOB code
> should
> > do
> > >>> the backport but the question is, is that dev available to do it now?
> > The
> > >>> next best thing is to get Ted Yu's patch reviewed by someone familiar
> > with
> > >>> the feature. I really hope that we can get cycles from the original
> MOB
> > >>> devs on this.
> > >>
> > >>
> > >> MOB is unsupported? If so, lets for sure not backport it.
> > >>
> > >>
> > >> Agree that we shouldn't be adding flaky tests. The question is if the
> > >>> failures on master to do with MOB are really MOB related or something
> > else
> > >>> (for argument's sake, let's say, procv2)..
> > >> Sounds like we need to spend a bit of time digging in on the flakey
> > tests
> > >> then. Branch-1 is pretty stable now after a bunch of expended effort
> by
> > a
> > >> few folks. Would be a pity taking a step back.
> > >>
> > >> St.Ack
> > >>
> > >>
> > >>
> > >>> On the point about the DISCUSS thread, yeah, it's fine to do it if
> > folks
> > >>> feel it's the right way to go.
> > >>> ________________________________________
> > >>> From: saint.ack@gmail.com <sa...@gmail.com> on behalf of Stack <
> > >>> stack@duboce.net>
> > >>> Sent: Wednesday, March 02, 2016 10:55 AM
> > >>> To: HBase Dev List
> > >>> Subject: Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch
> > hbase-11339
> > >>> HBase MOB to trunk)
> > >>>
> > >>> (Doing another resend...)
> > >>>
> > >>> I have objection to you, Ted Yu, doing it. MOB has spread all about
> > master
> > >>> branch. Backport should be done by someone who knows MOB.
> > >>>
> > >>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
> > thread
> > >>> to see what, if anything, folks
> > >>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
> > before
> > >>> we 'create a backport...'.
> > >>>
> > >>> For me, there should be no new flakies in branch-1. Branch-1 builds
> > are a
> > >>> hard-won stable(-ish). Looking at master build, MOB seems quiet
> lately
> > but
> > >>> going by HBASE-15012, our flakies umbrella issue, I see notes that
> > >>> TestMobExportSnapshot has failed a few times (that is probably
> because
> > the
> > >>> test it derives from is flakey) and
> > TestMobRestoreFlushSnapshotFromClient
> > >>> gets a mention.
> > >>>
> > >>> St.Ack
> > >>>
> > >>>
> > >>>
> > >>>> On Tue, Mar 1, 2016 at 5:27 PM, Stack <st...@duboce.net> wrote:
> > >>>>
> > >>>> (Doing a resend of below... it doesn't seem to have gone through)
> > >>>>
> > >>>>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com>
> wrote:
> > >>>>>
> > >>>>> If there is no objection, I will create a backport JIRA tomorrow
> and
> > >>>>> attach patch.
> > >>>> I have objection to you doing it. MOB has spread all about master
> > branch.
> > >>>> Backport should be done by someone who knows MOB.
> > >>>>
> > >>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
> > >>>> thread to see what, if anything, folks
> > >>>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
> > >>>> before we 'create a backport...'.
> > >>>>
> > >>>> For me, there should be no new flakies in branch-1. Branch-1 builds
> > are a
> > >>>> hard-won stable(-ish). Looking at master build, MOB seems quiet
> lately
> > >>> but
> > >>>> going by HBASE-15012, our flakies umbrella issue, I see notes that
> > >>>> TestMobExportSnapshot has failed a few times (that is probably
> because
> > >>> the
> > >>>> test it derives from is flakey) and
> > TestMobRestoreFlushSnapshotFromClient
> > >>>> gets a mention.
> > >>>>
> > >>>> St.Ack
> > >>>>
> > >>>>
> > >>>>
> > >>>>>> On Tue, Mar 1, 2016 at 9:32 AM, Stack <st...@duboce.net> wrote:
> > >>>>>>
> > >>>>>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com>
> > wrote:
> > >>>>>>
> > >>>>>> If there is no objection, I will create a backport JIRA tomorrow
> and
> > >>>>>> attach patch.
> > >>>>> I have objection to you doing it. MOB has spread all about master
> > >>> branch.
> > >>>>> Backport should be done by someone who knows MOB.
> > >>>>>
> > >>>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS]
> flagged
> > >>>>> thread to see what, if anything, folks
> > >>>>> would like to see gate inclusion in branch-1?"  Shouldn't we do
> this
> > >>>>> before we 'create a backport...'.
> > >>>>>
> > >>>>> For me, there should be no new flakies in branch-1. Branch-1 builds
> > are
> > >>> a
> > >>>>> hard-won stable(-ish). Looking at master build, MOB seems quiet
> > lately
> > >>> but
> > >>>>> going by HBASE-15012, our flakies umbrella issue, I see notes that
> > >>>>> TestMobExportSnapshot has failed a few times (that is probably
> > because
> > >>> the
> > >>>>> test it derives from is flakey) and
> > >>> TestMobRestoreFlushSnapshotFromClient
> > >>>>> gets a mention.
> > >>>>>
> > >>>>> St.Ack
> > >>>
> >
>
>
>
> --
> // Jonathan Hsieh (shay)
> // HBase Tech Lead, Software Engineer, Cloudera
> // jon@cloudera.com // @jmhsieh
>



-- 
// Jonathan Hsieh (shay)
// HBase Tech Lead, Software Engineer, Cloudera
// jon@cloudera.com // @jmhsieh

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Devaraj Das <dd...@hortonworks.com>]

Sounds good to me, Jonathan. Although I suspect that at the end this will be close to what Ted Yu has in the backport patch but this is a more structured / reliable way of doing it. When you say this - "backport the patches that came after the merge to trunk....", is there a reliable way to identify all those. In the backport jira, there is a mention of some additional jiras after the original merge - https://goo.gl/6stN7Y - we need to make sure if these are the only ones relevant.
________________________________________
From: Jonathan Hsieh <jo...@cloudera.com>
Sent: Wednesday, March 02, 2016 2:03 PM
To: dev@hbase.apache.org
Subject: Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

I'll offer what I think would be another reasonable and likely less
destabilizing approach:  essentially treat it as a branch.  We could start
from the existing hbase-11339 branch, call it hbase-11339-branch-1 and do
the work to merge it into branch-1 (instead of trunk).  To merge into
branch-1 it would require the 3 +1's just like any other branch merge.

Mob initially started off as a mega patch and was broken down and committed
in reviewable pieces to branch hbase-11339.  Most of this was actually when
1.0.0-SNAPSHOT was trunk so many of the older commits may actually jive
better with branch-1. Towards the end we did periodic merge commits with
trunk as we shook out issues integration testing found, and as branch merge
reviews uncovered other short comings.  These merge patches actually showed
how we modified the mob code to account for the later changes in trunk.  In
this particular case we coud take hbase-11339-branch-1,  backport the
patches that came after the merge to trunk with the normal single +1 review
process on the branch, and then propose a branch merge with branch-1. When
all pieces are ready and we had stable unit tests (admittedly that was a
one shortcoming when I sheparded hbase-11339) we do 3 +1s to merge to
branch-1 (and possibly branch-1.3).

This has the nice benefit compared to andrew's suggesting of not
potentially blocking branch-1 or having a half complete mob feature in
branch-1 if hbase-11339-branch-1 isn't ready.

Jon.




On Wed, Mar 2, 2016 at 1:31 PM, Andrew Purtell <an...@gmail.com>
wrote:

> On the question of change provenance, if I can make a suggestion: How I
> would approach the backport of a feature developed in trunk over multiple
> commits and JIRAs is I would look through git history, find each related
> commit, and apply each commit in sequence to branch-1, fixing things up as
> needed each time. Then the resulting working branch can be pushed up to aid
> review of the aggregate result by the MOB developers and the larger
> community. Ted, if you approached the backport in this way, then pushing up
> your working branch will aid review.
>
> > On Mar 2, 2016, at 1:17 PM, Andrew Purtell <an...@gmail.com>
> wrote:
> >
> > I concur with Stack's concerns with a developer not involved in building
> the MOB feature attempting a backport in general, and furthermore without
> detailed provenance of all of the incorporated changes. I'm also concerned
> about how well MOB works in real production given people use branch-1 in
> production and not trunk.
> >
> > As for Ted's issue, I'm not going to let him commit it (I will veto)
> without clear proof that it works and doesn't hurt perf of non MOB cases by
> way of reproducible benchmarks - benchmarks I can personally reproduce
> afterward (I'm not volunteering to do Ted's necessary legwork) - done with
> branch-1 with the proposed patch applied. We are not there yet though,
> barely, into review, but this will be coming up very soon.
> >
> >>> On Mar 2, 2016, at 1:03 PM, Stack <st...@duboce.net> wrote:
> >>>
> >>> On Wed, Mar 2, 2016 at 11:26 AM, Devaraj Das <dd...@hortonworks.com>
> wrote:
> >>>
> >>> Stack, as things stand, Ted Yu has a patch that is a backport of MOB.
> He
> >>> told me offline he has taken a look at the jiras that went in in the
> master
> >>> that is to do with MOB, and got them in the backport.
> >>
> >>
> >>
> >> On the issue, a near 800k blob is dumped which is described as "...a
> >> backport of MOB... " but w/o attribution of provenance nor any other
> >> description of what it contains. Only when this is pointed-out in the
> issue
> >> do we get a short listing of supposed JIRAs included with no
> justification
> >> of what is covered, what is included/excluded, and what machinations
> were
> >> done to make it fit branch-1 (Yet you offline were given this info?).
> >>
> >> Such poor practice only makes me more intent on my objection.
> >>
> >>
> >>
> >>> Now, to your point, I agree that someone familiar with MOB code should
> do
> >>> the backport but the question is, is that dev available to do it now?
> The
> >>> next best thing is to get Ted Yu's patch reviewed by someone familiar
> with
> >>> the feature. I really hope that we can get cycles from the original MOB
> >>> devs on this.
> >>
> >>
> >> MOB is unsupported? If so, lets for sure not backport it.
> >>
> >>
> >> Agree that we shouldn't be adding flaky tests. The question is if the
> >>> failures on master to do with MOB are really MOB related or something
> else
> >>> (for argument's sake, let's say, procv2)..
> >> Sounds like we need to spend a bit of time digging in on the flakey
> tests
> >> then. Branch-1 is pretty stable now after a bunch of expended effort by
> a
> >> few folks. Would be a pity taking a step back.
> >>
> >> St.Ack
> >>
> >>
> >>
> >>> On the point about the DISCUSS thread, yeah, it's fine to do it if
> folks
> >>> feel it's the right way to go.
> >>> ________________________________________
> >>> From: saint.ack@gmail.com <sa...@gmail.com> on behalf of Stack <
> >>> stack@duboce.net>
> >>> Sent: Wednesday, March 02, 2016 10:55 AM
> >>> To: HBase Dev List
> >>> Subject: Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch
> hbase-11339
> >>> HBase MOB to trunk)
> >>>
> >>> (Doing another resend...)
> >>>
> >>> I have objection to you, Ted Yu, doing it. MOB has spread all about
> master
> >>> branch. Backport should be done by someone who knows MOB.
> >>>
> >>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
> thread
> >>> to see what, if anything, folks
> >>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
> before
> >>> we 'create a backport...'.
> >>>
> >>> For me, there should be no new flakies in branch-1. Branch-1 builds
> are a
> >>> hard-won stable(-ish). Looking at master build, MOB seems quiet lately
> but
> >>> going by HBASE-15012, our flakies umbrella issue, I see notes that
> >>> TestMobExportSnapshot has failed a few times (that is probably because
> the
> >>> test it derives from is flakey) and
> TestMobRestoreFlushSnapshotFromClient
> >>> gets a mention.
> >>>
> >>> St.Ack
> >>>
> >>>
> >>>
> >>>> On Tue, Mar 1, 2016 at 5:27 PM, Stack <st...@duboce.net> wrote:
> >>>>
> >>>> (Doing a resend of below... it doesn't seem to have gone through)
> >>>>
> >>>>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com> wrote:
> >>>>>
> >>>>> If there is no objection, I will create a backport JIRA tomorrow and
> >>>>> attach patch.
> >>>> I have objection to you doing it. MOB has spread all about master
> branch.
> >>>> Backport should be done by someone who knows MOB.
> >>>>
> >>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
> >>>> thread to see what, if anything, folks
> >>>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
> >>>> before we 'create a backport...'.
> >>>>
> >>>> For me, there should be no new flakies in branch-1. Branch-1 builds
> are a
> >>>> hard-won stable(-ish). Looking at master build, MOB seems quiet lately
> >>> but
> >>>> going by HBASE-15012, our flakies umbrella issue, I see notes that
> >>>> TestMobExportSnapshot has failed a few times (that is probably because
> >>> the
> >>>> test it derives from is flakey) and
> TestMobRestoreFlushSnapshotFromClient
> >>>> gets a mention.
> >>>>
> >>>> St.Ack
> >>>>
> >>>>
> >>>>
> >>>>>> On Tue, Mar 1, 2016 at 9:32 AM, Stack <st...@duboce.net> wrote:
> >>>>>>
> >>>>>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com>
> wrote:
> >>>>>>
> >>>>>> If there is no objection, I will create a backport JIRA tomorrow and
> >>>>>> attach patch.
> >>>>> I have objection to you doing it. MOB has spread all about master
> >>> branch.
> >>>>> Backport should be done by someone who knows MOB.
> >>>>>
> >>>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
> >>>>> thread to see what, if anything, folks
> >>>>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
> >>>>> before we 'create a backport...'.
> >>>>>
> >>>>> For me, there should be no new flakies in branch-1. Branch-1 builds
> are
> >>> a
> >>>>> hard-won stable(-ish). Looking at master build, MOB seems quiet
> lately
> >>> but
> >>>>> going by HBASE-15012, our flakies umbrella issue, I see notes that
> >>>>> TestMobExportSnapshot has failed a few times (that is probably
> because
> >>> the
> >>>>> test it derives from is flakey) and
> >>> TestMobRestoreFlushSnapshotFromClient
> >>>>> gets a mention.
> >>>>>
> >>>>> St.Ack
> >>>
>



--
// Jonathan Hsieh (shay)
// HBase Tech Lead, Software Engineer, Cloudera
// jon@cloudera.com // @jmhsieh

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Andrew Purtell <ap...@apache.org>]

Branch development with later merge vote is another way to get at review of
change provenance in digestible bits as I suggested. +1 from me

On Wed, Mar 2, 2016 at 2:03 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:

> I'll offer what I think would be another reasonable and likely less
> destabilizing approach:  essentially treat it as a branch.  We could start
> from the existing hbase-11339 branch, call it hbase-11339-branch-1 and do
> the work to merge it into branch-1 (instead of trunk).  To merge into
> branch-1 it would require the 3 +1's just like any other branch merge.
>
> Mob initially started off as a mega patch and was broken down and committed
> in reviewable pieces to branch hbase-11339.  Most of this was actually when
> 1.0.0-SNAPSHOT was trunk so many of the older commits may actually jive
> better with branch-1. Towards the end we did periodic merge commits with
> trunk as we shook out issues integration testing found, and as branch merge
> reviews uncovered other short comings.  These merge patches actually showed
> how we modified the mob code to account for the later changes in trunk.  In
> this particular case we coud take hbase-11339-branch-1,  backport the
> patches that came after the merge to trunk with the normal single +1 review
> process on the branch, and then propose a branch merge with branch-1. When
> all pieces are ready and we had stable unit tests (admittedly that was a
> one shortcoming when I sheparded hbase-11339) we do 3 +1s to merge to
> branch-1 (and possibly branch-1.3).
>
> This has the nice benefit compared to andrew's suggesting of not
> potentially blocking branch-1 or having a half complete mob feature in
> branch-1 if hbase-11339-branch-1 isn't ready.
>
> Jon.
>
>
>
>
> On Wed, Mar 2, 2016 at 1:31 PM, Andrew Purtell <an...@gmail.com>
> wrote:
>
> > On the question of change provenance, if I can make a suggestion: How I
> > would approach the backport of a feature developed in trunk over multiple
> > commits and JIRAs is I would look through git history, find each related
> > commit, and apply each commit in sequence to branch-1, fixing things up
> as
> > needed each time. Then the resulting working branch can be pushed up to
> aid
> > review of the aggregate result by the MOB developers and the larger
> > community. Ted, if you approached the backport in this way, then pushing
> up
> > your working branch will aid review.
> >
> > > On Mar 2, 2016, at 1:17 PM, Andrew Purtell <an...@gmail.com>
> > wrote:
> > >
> > > I concur with Stack's concerns with a developer not involved in
> building
> > the MOB feature attempting a backport in general, and furthermore without
> > detailed provenance of all of the incorporated changes. I'm also
> concerned
> > about how well MOB works in real production given people use branch-1 in
> > production and not trunk.
> > >
> > > As for Ted's issue, I'm not going to let him commit it (I will veto)
> > without clear proof that it works and doesn't hurt perf of non MOB cases
> by
> > way of reproducible benchmarks - benchmarks I can personally reproduce
> > afterward (I'm not volunteering to do Ted's necessary legwork) - done
> with
> > branch-1 with the proposed patch applied. We are not there yet though,
> > barely, into review, but this will be coming up very soon.
> > >
> > >>> On Mar 2, 2016, at 1:03 PM, Stack <st...@duboce.net> wrote:
> > >>>
> > >>> On Wed, Mar 2, 2016 at 11:26 AM, Devaraj Das <dd...@hortonworks.com>
> > wrote:
> > >>>
> > >>> Stack, as things stand, Ted Yu has a patch that is a backport of MOB.
> > He
> > >>> told me offline he has taken a look at the jiras that went in in the
> > master
> > >>> that is to do with MOB, and got them in the backport.
> > >>
> > >>
> > >>
> > >> On the issue, a near 800k blob is dumped which is described as "...a
> > >> backport of MOB... " but w/o attribution of provenance nor any other
> > >> description of what it contains. Only when this is pointed-out in the
> > issue
> > >> do we get a short listing of supposed JIRAs included with no
> > justification
> > >> of what is covered, what is included/excluded, and what machinations
> > were
> > >> done to make it fit branch-1 (Yet you offline were given this info?).
> > >>
> > >> Such poor practice only makes me more intent on my objection.
> > >>
> > >>
> > >>
> > >>> Now, to your point, I agree that someone familiar with MOB code
> should
> > do
> > >>> the backport but the question is, is that dev available to do it now?
> > The
> > >>> next best thing is to get Ted Yu's patch reviewed by someone familiar
> > with
> > >>> the feature. I really hope that we can get cycles from the original
> MOB
> > >>> devs on this.
> > >>
> > >>
> > >> MOB is unsupported? If so, lets for sure not backport it.
> > >>
> > >>
> > >> Agree that we shouldn't be adding flaky tests. The question is if the
> > >>> failures on master to do with MOB are really MOB related or something
> > else
> > >>> (for argument's sake, let's say, procv2)..
> > >> Sounds like we need to spend a bit of time digging in on the flakey
> > tests
> > >> then. Branch-1 is pretty stable now after a bunch of expended effort
> by
> > a
> > >> few folks. Would be a pity taking a step back.
> > >>
> > >> St.Ack
> > >>
> > >>
> > >>
> > >>> On the point about the DISCUSS thread, yeah, it's fine to do it if
> > folks
> > >>> feel it's the right way to go.
> > >>> ________________________________________
> > >>> From: saint.ack@gmail.com <sa...@gmail.com> on behalf of Stack <
> > >>> stack@duboce.net>
> > >>> Sent: Wednesday, March 02, 2016 10:55 AM
> > >>> To: HBase Dev List
> > >>> Subject: Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch
> > hbase-11339
> > >>> HBase MOB to trunk)
> > >>>
> > >>> (Doing another resend...)
> > >>>
> > >>> I have objection to you, Ted Yu, doing it. MOB has spread all about
> > master
> > >>> branch. Backport should be done by someone who knows MOB.
> > >>>
> > >>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
> > thread
> > >>> to see what, if anything, folks
> > >>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
> > before
> > >>> we 'create a backport...'.
> > >>>
> > >>> For me, there should be no new flakies in branch-1. Branch-1 builds
> > are a
> > >>> hard-won stable(-ish). Looking at master build, MOB seems quiet
> lately
> > but
> > >>> going by HBASE-15012, our flakies umbrella issue, I see notes that
> > >>> TestMobExportSnapshot has failed a few times (that is probably
> because
> > the
> > >>> test it derives from is flakey) and
> > TestMobRestoreFlushSnapshotFromClient
> > >>> gets a mention.
> > >>>
> > >>> St.Ack
> > >>>
> > >>>
> > >>>
> > >>>> On Tue, Mar 1, 2016 at 5:27 PM, Stack <st...@duboce.net> wrote:
> > >>>>
> > >>>> (Doing a resend of below... it doesn't seem to have gone through)
> > >>>>
> > >>>>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com>
> wrote:
> > >>>>>
> > >>>>> If there is no objection, I will create a backport JIRA tomorrow
> and
> > >>>>> attach patch.
> > >>>> I have objection to you doing it. MOB has spread all about master
> > branch.
> > >>>> Backport should be done by someone who knows MOB.
> > >>>>
> > >>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
> > >>>> thread to see what, if anything, folks
> > >>>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
> > >>>> before we 'create a backport...'.
> > >>>>
> > >>>> For me, there should be no new flakies in branch-1. Branch-1 builds
> > are a
> > >>>> hard-won stable(-ish). Looking at master build, MOB seems quiet
> lately
> > >>> but
> > >>>> going by HBASE-15012, our flakies umbrella issue, I see notes that
> > >>>> TestMobExportSnapshot has failed a few times (that is probably
> because
> > >>> the
> > >>>> test it derives from is flakey) and
> > TestMobRestoreFlushSnapshotFromClient
> > >>>> gets a mention.
> > >>>>
> > >>>> St.Ack
> > >>>>
> > >>>>
> > >>>>
> > >>>>>> On Tue, Mar 1, 2016 at 9:32 AM, Stack <st...@duboce.net> wrote:
> > >>>>>>
> > >>>>>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com>
> > wrote:
> > >>>>>>
> > >>>>>> If there is no objection, I will create a backport JIRA tomorrow
> and
> > >>>>>> attach patch.
> > >>>>> I have objection to you doing it. MOB has spread all about master
> > >>> branch.
> > >>>>> Backport should be done by someone who knows MOB.
> > >>>>>
> > >>>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS]
> flagged
> > >>>>> thread to see what, if anything, folks
> > >>>>> would like to see gate inclusion in branch-1?"  Shouldn't we do
> this
> > >>>>> before we 'create a backport...'.
> > >>>>>
> > >>>>> For me, there should be no new flakies in branch-1. Branch-1 builds
> > are
> > >>> a
> > >>>>> hard-won stable(-ish). Looking at master build, MOB seems quiet
> > lately
> > >>> but
> > >>>>> going by HBASE-15012, our flakies umbrella issue, I see notes that
> > >>>>> TestMobExportSnapshot has failed a few times (that is probably
> > because
> > >>> the
> > >>>>> test it derives from is flakey) and
> > >>> TestMobRestoreFlushSnapshotFromClient
> > >>>>> gets a mention.
> > >>>>>
> > >>>>> St.Ack
> > >>>
> >
>
>
>
> --
> // Jonathan Hsieh (shay)
> // HBase Tech Lead, Software Engineer, Cloudera
> // jon@cloudera.com // @jmhsieh
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Jonathan Hsieh <jo...@cloudera.com>]

I'll offer what I think would be another reasonable and likely less
destabilizing approach:  essentially treat it as a branch.  We could start
from the existing hbase-11339 branch, call it hbase-11339-branch-1 and do
the work to merge it into branch-1 (instead of trunk).  To merge into
branch-1 it would require the 3 +1's just like any other branch merge.

Mob initially started off as a mega patch and was broken down and committed
in reviewable pieces to branch hbase-11339.  Most of this was actually when
1.0.0-SNAPSHOT was trunk so many of the older commits may actually jive
better with branch-1. Towards the end we did periodic merge commits with
trunk as we shook out issues integration testing found, and as branch merge
reviews uncovered other short comings.  These merge patches actually showed
how we modified the mob code to account for the later changes in trunk.  In
this particular case we coud take hbase-11339-branch-1,  backport the
patches that came after the merge to trunk with the normal single +1 review
process on the branch, and then propose a branch merge with branch-1. When
all pieces are ready and we had stable unit tests (admittedly that was a
one shortcoming when I sheparded hbase-11339) we do 3 +1s to merge to
branch-1 (and possibly branch-1.3).

This has the nice benefit compared to andrew's suggesting of not
potentially blocking branch-1 or having a half complete mob feature in
branch-1 if hbase-11339-branch-1 isn't ready.

Jon.




On Wed, Mar 2, 2016 at 1:31 PM, Andrew Purtell <an...@gmail.com>
wrote:

> On the question of change provenance, if I can make a suggestion: How I
> would approach the backport of a feature developed in trunk over multiple
> commits and JIRAs is I would look through git history, find each related
> commit, and apply each commit in sequence to branch-1, fixing things up as
> needed each time. Then the resulting working branch can be pushed up to aid
> review of the aggregate result by the MOB developers and the larger
> community. Ted, if you approached the backport in this way, then pushing up
> your working branch will aid review.
>
> > On Mar 2, 2016, at 1:17 PM, Andrew Purtell <an...@gmail.com>
> wrote:
> >
> > I concur with Stack's concerns with a developer not involved in building
> the MOB feature attempting a backport in general, and furthermore without
> detailed provenance of all of the incorporated changes. I'm also concerned
> about how well MOB works in real production given people use branch-1 in
> production and not trunk.
> >
> > As for Ted's issue, I'm not going to let him commit it (I will veto)
> without clear proof that it works and doesn't hurt perf of non MOB cases by
> way of reproducible benchmarks - benchmarks I can personally reproduce
> afterward (I'm not volunteering to do Ted's necessary legwork) - done with
> branch-1 with the proposed patch applied. We are not there yet though,
> barely, into review, but this will be coming up very soon.
> >
> >>> On Mar 2, 2016, at 1:03 PM, Stack <st...@duboce.net> wrote:
> >>>
> >>> On Wed, Mar 2, 2016 at 11:26 AM, Devaraj Das <dd...@hortonworks.com>
> wrote:
> >>>
> >>> Stack, as things stand, Ted Yu has a patch that is a backport of MOB.
> He
> >>> told me offline he has taken a look at the jiras that went in in the
> master
> >>> that is to do with MOB, and got them in the backport.
> >>
> >>
> >>
> >> On the issue, a near 800k blob is dumped which is described as "...a
> >> backport of MOB... " but w/o attribution of provenance nor any other
> >> description of what it contains. Only when this is pointed-out in the
> issue
> >> do we get a short listing of supposed JIRAs included with no
> justification
> >> of what is covered, what is included/excluded, and what machinations
> were
> >> done to make it fit branch-1 (Yet you offline were given this info?).
> >>
> >> Such poor practice only makes me more intent on my objection.
> >>
> >>
> >>
> >>> Now, to your point, I agree that someone familiar with MOB code should
> do
> >>> the backport but the question is, is that dev available to do it now?
> The
> >>> next best thing is to get Ted Yu's patch reviewed by someone familiar
> with
> >>> the feature. I really hope that we can get cycles from the original MOB
> >>> devs on this.
> >>
> >>
> >> MOB is unsupported? If so, lets for sure not backport it.
> >>
> >>
> >> Agree that we shouldn't be adding flaky tests. The question is if the
> >>> failures on master to do with MOB are really MOB related or something
> else
> >>> (for argument's sake, let's say, procv2)..
> >> Sounds like we need to spend a bit of time digging in on the flakey
> tests
> >> then. Branch-1 is pretty stable now after a bunch of expended effort by
> a
> >> few folks. Would be a pity taking a step back.
> >>
> >> St.Ack
> >>
> >>
> >>
> >>> On the point about the DISCUSS thread, yeah, it's fine to do it if
> folks
> >>> feel it's the right way to go.
> >>> ________________________________________
> >>> From: saint.ack@gmail.com <sa...@gmail.com> on behalf of Stack <
> >>> stack@duboce.net>
> >>> Sent: Wednesday, March 02, 2016 10:55 AM
> >>> To: HBase Dev List
> >>> Subject: Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch
> hbase-11339
> >>> HBase MOB to trunk)
> >>>
> >>> (Doing another resend...)
> >>>
> >>> I have objection to you, Ted Yu, doing it. MOB has spread all about
> master
> >>> branch. Backport should be done by someone who knows MOB.
> >>>
> >>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
> thread
> >>> to see what, if anything, folks
> >>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
> before
> >>> we 'create a backport...'.
> >>>
> >>> For me, there should be no new flakies in branch-1. Branch-1 builds
> are a
> >>> hard-won stable(-ish). Looking at master build, MOB seems quiet lately
> but
> >>> going by HBASE-15012, our flakies umbrella issue, I see notes that
> >>> TestMobExportSnapshot has failed a few times (that is probably because
> the
> >>> test it derives from is flakey) and
> TestMobRestoreFlushSnapshotFromClient
> >>> gets a mention.
> >>>
> >>> St.Ack
> >>>
> >>>
> >>>
> >>>> On Tue, Mar 1, 2016 at 5:27 PM, Stack <st...@duboce.net> wrote:
> >>>>
> >>>> (Doing a resend of below... it doesn't seem to have gone through)
> >>>>
> >>>>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com> wrote:
> >>>>>
> >>>>> If there is no objection, I will create a backport JIRA tomorrow and
> >>>>> attach patch.
> >>>> I have objection to you doing it. MOB has spread all about master
> branch.
> >>>> Backport should be done by someone who knows MOB.
> >>>>
> >>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
> >>>> thread to see what, if anything, folks
> >>>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
> >>>> before we 'create a backport...'.
> >>>>
> >>>> For me, there should be no new flakies in branch-1. Branch-1 builds
> are a
> >>>> hard-won stable(-ish). Looking at master build, MOB seems quiet lately
> >>> but
> >>>> going by HBASE-15012, our flakies umbrella issue, I see notes that
> >>>> TestMobExportSnapshot has failed a few times (that is probably because
> >>> the
> >>>> test it derives from is flakey) and
> TestMobRestoreFlushSnapshotFromClient
> >>>> gets a mention.
> >>>>
> >>>> St.Ack
> >>>>
> >>>>
> >>>>
> >>>>>> On Tue, Mar 1, 2016 at 9:32 AM, Stack <st...@duboce.net> wrote:
> >>>>>>
> >>>>>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com>
> wrote:
> >>>>>>
> >>>>>> If there is no objection, I will create a backport JIRA tomorrow and
> >>>>>> attach patch.
> >>>>> I have objection to you doing it. MOB has spread all about master
> >>> branch.
> >>>>> Backport should be done by someone who knows MOB.
> >>>>>
> >>>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
> >>>>> thread to see what, if anything, folks
> >>>>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
> >>>>> before we 'create a backport...'.
> >>>>>
> >>>>> For me, there should be no new flakies in branch-1. Branch-1 builds
> are
> >>> a
> >>>>> hard-won stable(-ish). Looking at master build, MOB seems quiet
> lately
> >>> but
> >>>>> going by HBASE-15012, our flakies umbrella issue, I see notes that
> >>>>> TestMobExportSnapshot has failed a few times (that is probably
> because
> >>> the
> >>>>> test it derives from is flakey) and
> >>> TestMobRestoreFlushSnapshotFromClient
> >>>>> gets a mention.
> >>>>>
> >>>>> St.Ack
> >>>
>



-- 
// Jonathan Hsieh (shay)
// HBase Tech Lead, Software Engineer, Cloudera
// jon@cloudera.com // @jmhsieh

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Andrew Purtell <an...@gmail.com>]

On the question of change provenance, if I can make a suggestion: How I would approach the backport of a feature developed in trunk over multiple commits and JIRAs is I would look through git history, find each related commit, and apply each commit in sequence to branch-1, fixing things up as needed each time. Then the resulting working branch can be pushed up to aid review of the aggregate result by the MOB developers and the larger community. Ted, if you approached the backport in this way, then pushing up your working branch will aid review. 

> On Mar 2, 2016, at 1:17 PM, Andrew Purtell <an...@gmail.com> wrote:
> 
> I concur with Stack's concerns with a developer not involved in building the MOB feature attempting a backport in general, and furthermore without detailed provenance of all of the incorporated changes. I'm also concerned about how well MOB works in real production given people use branch-1 in production and not trunk. 
> 
> As for Ted's issue, I'm not going to let him commit it (I will veto) without clear proof that it works and doesn't hurt perf of non MOB cases by way of reproducible benchmarks - benchmarks I can personally reproduce afterward (I'm not volunteering to do Ted's necessary legwork) - done with branch-1 with the proposed patch applied. We are not there yet though, barely, into review, but this will be coming up very soon. 
> 
>>> On Mar 2, 2016, at 1:03 PM, Stack <st...@duboce.net> wrote:
>>> 
>>> On Wed, Mar 2, 2016 at 11:26 AM, Devaraj Das <dd...@hortonworks.com> wrote:
>>> 
>>> Stack, as things stand, Ted Yu has a patch that is a backport of MOB. He
>>> told me offline he has taken a look at the jiras that went in in the master
>>> that is to do with MOB, and got them in the backport.
>> 
>> 
>> 
>> On the issue, a near 800k blob is dumped which is described as "...a
>> backport of MOB... " but w/o attribution of provenance nor any other
>> description of what it contains. Only when this is pointed-out in the issue
>> do we get a short listing of supposed JIRAs included with no justification
>> of what is covered, what is included/excluded, and what machinations were
>> done to make it fit branch-1 (Yet you offline were given this info?).
>> 
>> Such poor practice only makes me more intent on my objection.
>> 
>> 
>> 
>>> Now, to your point, I agree that someone familiar with MOB code should do
>>> the backport but the question is, is that dev available to do it now? The
>>> next best thing is to get Ted Yu's patch reviewed by someone familiar with
>>> the feature. I really hope that we can get cycles from the original MOB
>>> devs on this.
>> 
>> 
>> MOB is unsupported? If so, lets for sure not backport it.
>> 
>> 
>> Agree that we shouldn't be adding flaky tests. The question is if the
>>> failures on master to do with MOB are really MOB related or something else
>>> (for argument's sake, let's say, procv2)..
>> Sounds like we need to spend a bit of time digging in on the flakey tests
>> then. Branch-1 is pretty stable now after a bunch of expended effort by a
>> few folks. Would be a pity taking a step back.
>> 
>> St.Ack
>> 
>> 
>> 
>>> On the point about the DISCUSS thread, yeah, it's fine to do it if folks
>>> feel it's the right way to go.
>>> ________________________________________
>>> From: saint.ack@gmail.com <sa...@gmail.com> on behalf of Stack <
>>> stack@duboce.net>
>>> Sent: Wednesday, March 02, 2016 10:55 AM
>>> To: HBase Dev List
>>> Subject: Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339
>>> HBase MOB to trunk)
>>> 
>>> (Doing another resend...)
>>> 
>>> I have objection to you, Ted Yu, doing it. MOB has spread all about master
>>> branch. Backport should be done by someone who knows MOB.
>>> 
>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged thread
>>> to see what, if anything, folks
>>> would like to see gate inclusion in branch-1?"  Shouldn't we do this before
>>> we 'create a backport...'.
>>> 
>>> For me, there should be no new flakies in branch-1. Branch-1 builds are a
>>> hard-won stable(-ish). Looking at master build, MOB seems quiet lately but
>>> going by HBASE-15012, our flakies umbrella issue, I see notes that
>>> TestMobExportSnapshot has failed a few times (that is probably because the
>>> test it derives from is flakey) and TestMobRestoreFlushSnapshotFromClient
>>> gets a mention.
>>> 
>>> St.Ack
>>> 
>>> 
>>> 
>>>> On Tue, Mar 1, 2016 at 5:27 PM, Stack <st...@duboce.net> wrote:
>>>> 
>>>> (Doing a resend of below... it doesn't seem to have gone through)
>>>> 
>>>>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com> wrote:
>>>>> 
>>>>> If there is no objection, I will create a backport JIRA tomorrow and
>>>>> attach patch.
>>>> I have objection to you doing it. MOB has spread all about master branch.
>>>> Backport should be done by someone who knows MOB.
>>>> 
>>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
>>>> thread to see what, if anything, folks
>>>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
>>>> before we 'create a backport...'.
>>>> 
>>>> For me, there should be no new flakies in branch-1. Branch-1 builds are a
>>>> hard-won stable(-ish). Looking at master build, MOB seems quiet lately
>>> but
>>>> going by HBASE-15012, our flakies umbrella issue, I see notes that
>>>> TestMobExportSnapshot has failed a few times (that is probably because
>>> the
>>>> test it derives from is flakey) and TestMobRestoreFlushSnapshotFromClient
>>>> gets a mention.
>>>> 
>>>> St.Ack
>>>> 
>>>> 
>>>> 
>>>>>> On Tue, Mar 1, 2016 at 9:32 AM, Stack <st...@duboce.net> wrote:
>>>>>> 
>>>>>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com> wrote:
>>>>>> 
>>>>>> If there is no objection, I will create a backport JIRA tomorrow and
>>>>>> attach patch.
>>>>> I have objection to you doing it. MOB has spread all about master
>>> branch.
>>>>> Backport should be done by someone who knows MOB.
>>>>> 
>>>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
>>>>> thread to see what, if anything, folks
>>>>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
>>>>> before we 'create a backport...'.
>>>>> 
>>>>> For me, there should be no new flakies in branch-1. Branch-1 builds are
>>> a
>>>>> hard-won stable(-ish). Looking at master build, MOB seems quiet lately
>>> but
>>>>> going by HBASE-15012, our flakies umbrella issue, I see notes that
>>>>> TestMobExportSnapshot has failed a few times (that is probably because
>>> the
>>>>> test it derives from is flakey) and
>>> TestMobRestoreFlushSnapshotFromClient
>>>>> gets a mention.
>>>>> 
>>>>> St.Ack
>>> 

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Andrew Purtell <an...@gmail.com>]

I concur with Stack's concerns with a developer not involved in building the MOB feature attempting a backport in general, and furthermore without detailed provenance of all of the incorporated changes. I'm also concerned about how well MOB works in real production given people use branch-1 in production and not trunk. 

As for Ted's issue, I'm not going to let him commit it (I will veto) without clear proof that it works and doesn't hurt perf of non MOB cases by way of reproducible benchmarks - benchmarks I can personally reproduce afterward (I'm not volunteering to do Ted's necessary legwork) - done with branch-1 with the proposed patch applied. We are not there yet though, barely, into review, but this will be coming up very soon. 

> On Mar 2, 2016, at 1:03 PM, Stack <st...@duboce.net> wrote:
> 
>> On Wed, Mar 2, 2016 at 11:26 AM, Devaraj Das <dd...@hortonworks.com> wrote:
>> 
>> Stack, as things stand, Ted Yu has a patch that is a backport of MOB. He
>> told me offline he has taken a look at the jiras that went in in the master
>> that is to do with MOB, and got them in the backport.
> 
> 
> 
> On the issue, a near 800k blob is dumped which is described as "...a
> backport of MOB... " but w/o attribution of provenance nor any other
> description of what it contains. Only when this is pointed-out in the issue
> do we get a short listing of supposed JIRAs included with no justification
> of what is covered, what is included/excluded, and what machinations were
> done to make it fit branch-1 (Yet you offline were given this info?).
> 
> Such poor practice only makes me more intent on my objection.
> 
> 
> 
>> Now, to your point, I agree that someone familiar with MOB code should do
>> the backport but the question is, is that dev available to do it now? The
>> next best thing is to get Ted Yu's patch reviewed by someone familiar with
>> the feature. I really hope that we can get cycles from the original MOB
>> devs on this.
> 
> 
> MOB is unsupported? If so, lets for sure not backport it.
> 
> 
> Agree that we shouldn't be adding flaky tests. The question is if the
>> failures on master to do with MOB are really MOB related or something else
>> (for argument's sake, let's say, procv2)..
> Sounds like we need to spend a bit of time digging in on the flakey tests
> then. Branch-1 is pretty stable now after a bunch of expended effort by a
> few folks. Would be a pity taking a step back.
> 
> St.Ack
> 
> 
> 
>> On the point about the DISCUSS thread, yeah, it's fine to do it if folks
>> feel it's the right way to go.
>> ________________________________________
>> From: saint.ack@gmail.com <sa...@gmail.com> on behalf of Stack <
>> stack@duboce.net>
>> Sent: Wednesday, March 02, 2016 10:55 AM
>> To: HBase Dev List
>> Subject: Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339
>> HBase MOB to trunk)
>> 
>> (Doing another resend...)
>> 
>> I have objection to you, Ted Yu, doing it. MOB has spread all about master
>> branch. Backport should be done by someone who knows MOB.
>> 
>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged thread
>> to see what, if anything, folks
>> would like to see gate inclusion in branch-1?"  Shouldn't we do this before
>> we 'create a backport...'.
>> 
>> For me, there should be no new flakies in branch-1. Branch-1 builds are a
>> hard-won stable(-ish). Looking at master build, MOB seems quiet lately but
>> going by HBASE-15012, our flakies umbrella issue, I see notes that
>> TestMobExportSnapshot has failed a few times (that is probably because the
>> test it derives from is flakey) and TestMobRestoreFlushSnapshotFromClient
>> gets a mention.
>> 
>> St.Ack
>> 
>> 
>> 
>>> On Tue, Mar 1, 2016 at 5:27 PM, Stack <st...@duboce.net> wrote:
>>> 
>>> (Doing a resend of below... it doesn't seem to have gone through)
>>> 
>>>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com> wrote:
>>>> 
>>>> If there is no objection, I will create a backport JIRA tomorrow and
>>>> attach patch.
>>> I have objection to you doing it. MOB has spread all about master branch.
>>> Backport should be done by someone who knows MOB.
>>> 
>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
>>> thread to see what, if anything, folks
>>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
>>> before we 'create a backport...'.
>>> 
>>> For me, there should be no new flakies in branch-1. Branch-1 builds are a
>>> hard-won stable(-ish). Looking at master build, MOB seems quiet lately
>> but
>>> going by HBASE-15012, our flakies umbrella issue, I see notes that
>>> TestMobExportSnapshot has failed a few times (that is probably because
>> the
>>> test it derives from is flakey) and TestMobRestoreFlushSnapshotFromClient
>>> gets a mention.
>>> 
>>> St.Ack
>>> 
>>> 
>>> 
>>>> On Tue, Mar 1, 2016 at 9:32 AM, Stack <st...@duboce.net> wrote:
>>>> 
>>>>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com> wrote:
>>>>> 
>>>>> If there is no objection, I will create a backport JIRA tomorrow and
>>>>> attach patch.
>>>> I have objection to you doing it. MOB has spread all about master
>> branch.
>>>> Backport should be done by someone who knows MOB.
>>>> 
>>>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
>>>> thread to see what, if anything, folks
>>>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
>>>> before we 'create a backport...'.
>>>> 
>>>> For me, there should be no new flakies in branch-1. Branch-1 builds are
>> a
>>>> hard-won stable(-ish). Looking at master build, MOB seems quiet lately
>> but
>>>> going by HBASE-15012, our flakies umbrella issue, I see notes that
>>>> TestMobExportSnapshot has failed a few times (that is probably because
>> the
>>>> test it derives from is flakey) and
>> TestMobRestoreFlushSnapshotFromClient
>>>> gets a mention.
>>>> 
>>>> St.Ack
>> 

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Stack <st...@duboce.net>]

On Wed, Mar 2, 2016 at 11:26 AM, Devaraj Das <dd...@hortonworks.com> wrote:

> Stack, as things stand, Ted Yu has a patch that is a backport of MOB. He
> told me offline he has taken a look at the jiras that went in in the master
> that is to do with MOB, and got them in the backport.



On the issue, a near 800k blob is dumped which is described as "...a
backport of MOB... " but w/o attribution of provenance nor any other
description of what it contains. Only when this is pointed-out in the issue
do we get a short listing of supposed JIRAs included with no justification
of what is covered, what is included/excluded, and what machinations were
done to make it fit branch-1 (Yet you offline were given this info?).

Such poor practice only makes me more intent on my objection.



> Now, to your point, I agree that someone familiar with MOB code should do
> the backport but the question is, is that dev available to do it now? The
> next best thing is to get Ted Yu's patch reviewed by someone familiar with
> the feature. I really hope that we can get cycles from the original MOB
> devs on this.
>


MOB is unsupported? If so, lets for sure not backport it.


Agree that we shouldn't be adding flaky tests. The question is if the
> failures on master to do with MOB are really MOB related or something else
> (for argument's sake, let's say, procv2)..
>
>
Sounds like we need to spend a bit of time digging in on the flakey tests
then. Branch-1 is pretty stable now after a bunch of expended effort by a
few folks. Would be a pity taking a step back.

St.Ack



> On the point about the DISCUSS thread, yeah, it's fine to do it if folks
> feel it's the right way to go.
> ________________________________________
> From: saint.ack@gmail.com <sa...@gmail.com> on behalf of Stack <
> stack@duboce.net>
> Sent: Wednesday, March 02, 2016 10:55 AM
> To: HBase Dev List
> Subject: Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339
> HBase MOB to trunk)
>
> (Doing another resend...)
>
> I have objection to you, Ted Yu, doing it. MOB has spread all about master
> branch. Backport should be done by someone who knows MOB.
>
> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged thread
> to see what, if anything, folks
> would like to see gate inclusion in branch-1?"  Shouldn't we do this before
> we 'create a backport...'.
>
> For me, there should be no new flakies in branch-1. Branch-1 builds are a
> hard-won stable(-ish). Looking at master build, MOB seems quiet lately but
> going by HBASE-15012, our flakies umbrella issue, I see notes that
> TestMobExportSnapshot has failed a few times (that is probably because the
> test it derives from is flakey) and TestMobRestoreFlushSnapshotFromClient
> gets a mention.
>
> St.Ack
>
>
>
> On Tue, Mar 1, 2016 at 5:27 PM, Stack <st...@duboce.net> wrote:
>
> > (Doing a resend of below... it doesn't seem to have gone through)
> >
> > On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com> wrote:
> >
> >> If there is no objection, I will create a backport JIRA tomorrow and
> >> attach patch.
> >>
> >>
> > I have objection to you doing it. MOB has spread all about master branch.
> > Backport should be done by someone who knows MOB.
> >
> > Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
> > thread to see what, if anything, folks
> > would like to see gate inclusion in branch-1?"  Shouldn't we do this
> > before we 'create a backport...'.
> >
> > For me, there should be no new flakies in branch-1. Branch-1 builds are a
> > hard-won stable(-ish). Looking at master build, MOB seems quiet lately
> but
> > going by HBASE-15012, our flakies umbrella issue, I see notes that
> > TestMobExportSnapshot has failed a few times (that is probably because
> the
> > test it derives from is flakey) and TestMobRestoreFlushSnapshotFromClient
> > gets a mention.
> >
> > St.Ack
> >
> >
> >
> > On Tue, Mar 1, 2016 at 9:32 AM, Stack <st...@duboce.net> wrote:
> >
> >> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com> wrote:
> >>
> >>> If there is no objection, I will create a backport JIRA tomorrow and
> >>> attach patch.
> >>>
> >>>
> >> I have objection to you doing it. MOB has spread all about master
> branch.
> >> Backport should be done by someone who knows MOB.
> >>
> >> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
> >> thread to see what, if anything, folks
> >> would like to see gate inclusion in branch-1?"  Shouldn't we do this
> >> before we 'create a backport...'.
> >>
> >> For me, there should be no new flakies in branch-1. Branch-1 builds are
> a
> >> hard-won stable(-ish). Looking at master build, MOB seems quiet lately
> but
> >> going by HBASE-15012, our flakies umbrella issue, I see notes that
> >> TestMobExportSnapshot has failed a few times (that is probably because
> the
> >> test it derives from is flakey) and
> TestMobRestoreFlushSnapshotFromClient
> >> gets a mention.
> >>
> >> St.Ack
> >>
> >
>

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Devaraj Das <dd...@hortonworks.com>]

Stack, as things stand, Ted Yu has a patch that is a backport of MOB. He told me offline he has taken a look at the jiras that went in in the master that is to do with MOB, and got them in the backport. Now, to your point, I agree that someone familiar with MOB code should do the backport but the question is, is that dev available to do it now? The next best thing is to get Ted Yu's patch reviewed by someone familiar with the feature. I really hope that we can get cycles from the original MOB devs on this.

Agree that we shouldn't be adding flaky tests. The question is if the failures on master to do with MOB are really MOB related or something else (for argument's sake, let's say, procv2)..

On the point about the DISCUSS thread, yeah, it's fine to do it if folks feel it's the right way to go.
________________________________________
From: saint.ack@gmail.com <sa...@gmail.com> on behalf of Stack <st...@duboce.net>
Sent: Wednesday, March 02, 2016 10:55 AM
To: HBase Dev List
Subject: Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

(Doing another resend...)

I have objection to you, Ted Yu, doing it. MOB has spread all about master
branch. Backport should be done by someone who knows MOB.

Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged thread
to see what, if anything, folks
would like to see gate inclusion in branch-1?"  Shouldn't we do this before
we 'create a backport...'.

For me, there should be no new flakies in branch-1. Branch-1 builds are a
hard-won stable(-ish). Looking at master build, MOB seems quiet lately but
going by HBASE-15012, our flakies umbrella issue, I see notes that
TestMobExportSnapshot has failed a few times (that is probably because the
test it derives from is flakey) and TestMobRestoreFlushSnapshotFromClient
gets a mention.

St.Ack



On Tue, Mar 1, 2016 at 5:27 PM, Stack <st...@duboce.net> wrote:

> (Doing a resend of below... it doesn't seem to have gone through)
>
> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com> wrote:
>
>> If there is no objection, I will create a backport JIRA tomorrow and
>> attach patch.
>>
>>
> I have objection to you doing it. MOB has spread all about master branch.
> Backport should be done by someone who knows MOB.
>
> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
> thread to see what, if anything, folks
> would like to see gate inclusion in branch-1?"  Shouldn't we do this
> before we 'create a backport...'.
>
> For me, there should be no new flakies in branch-1. Branch-1 builds are a
> hard-won stable(-ish). Looking at master build, MOB seems quiet lately but
> going by HBASE-15012, our flakies umbrella issue, I see notes that
> TestMobExportSnapshot has failed a few times (that is probably because the
> test it derives from is flakey) and TestMobRestoreFlushSnapshotFromClient
> gets a mention.
>
> St.Ack
>
>
>
> On Tue, Mar 1, 2016 at 9:32 AM, Stack <st...@duboce.net> wrote:
>
>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com> wrote:
>>
>>> If there is no objection, I will create a backport JIRA tomorrow and
>>> attach patch.
>>>
>>>
>> I have objection to you doing it. MOB has spread all about master branch.
>> Backport should be done by someone who knows MOB.
>>
>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
>> thread to see what, if anything, folks
>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
>> before we 'create a backport...'.
>>
>> For me, there should be no new flakies in branch-1. Branch-1 builds are a
>> hard-won stable(-ish). Looking at master build, MOB seems quiet lately but
>> going by HBASE-15012, our flakies umbrella issue, I see notes that
>> TestMobExportSnapshot has failed a few times (that is probably because the
>> test it derives from is flakey) and TestMobRestoreFlushSnapshotFromClient
>> gets a mention.
>>
>> St.Ack
>>
>

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Stack <st...@duboce.net>]

(Doing another resend...)

I have objection to you, Ted Yu, doing it. MOB has spread all about master
branch. Backport should be done by someone who knows MOB.

Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged thread
to see what, if anything, folks
would like to see gate inclusion in branch-1?"  Shouldn't we do this before
we 'create a backport...'.

For me, there should be no new flakies in branch-1. Branch-1 builds are a
hard-won stable(-ish). Looking at master build, MOB seems quiet lately but
going by HBASE-15012, our flakies umbrella issue, I see notes that
TestMobExportSnapshot has failed a few times (that is probably because the
test it derives from is flakey) and TestMobRestoreFlushSnapshotFromClient
gets a mention.

St.Ack



On Tue, Mar 1, 2016 at 5:27 PM, Stack <st...@duboce.net> wrote:

> (Doing a resend of below... it doesn't seem to have gone through)
>
> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com> wrote:
>
>> If there is no objection, I will create a backport JIRA tomorrow and
>> attach patch.
>>
>>
> I have objection to you doing it. MOB has spread all about master branch.
> Backport should be done by someone who knows MOB.
>
> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
> thread to see what, if anything, folks
> would like to see gate inclusion in branch-1?"  Shouldn't we do this
> before we 'create a backport...'.
>
> For me, there should be no new flakies in branch-1. Branch-1 builds are a
> hard-won stable(-ish). Looking at master build, MOB seems quiet lately but
> going by HBASE-15012, our flakies umbrella issue, I see notes that
> TestMobExportSnapshot has failed a few times (that is probably because the
> test it derives from is flakey) and TestMobRestoreFlushSnapshotFromClient
> gets a mention.
>
> St.Ack
>
>
>
> On Tue, Mar 1, 2016 at 9:32 AM, Stack <st...@duboce.net> wrote:
>
>> On Mon, Feb 29, 2016 at 8:20 PM, Ted Yu <yu...@gmail.com> wrote:
>>
>>> If there is no objection, I will create a backport JIRA tomorrow and
>>> attach patch.
>>>
>>>
>> I have objection to you doing it. MOB has spread all about master branch.
>> Backport should be done by someone who knows MOB.
>>
>> Higher up in this thread, Sean asks: "Can we get a [DISCUSS] flagged
>> thread to see what, if anything, folks
>> would like to see gate inclusion in branch-1?"  Shouldn't we do this
>> before we 'create a backport...'.
>>
>> For me, there should be no new flakies in branch-1. Branch-1 builds are a
>> hard-won stable(-ish). Looking at master build, MOB seems quiet lately but
>> going by HBASE-15012, our flakies umbrella issue, I see notes that
>> TestMobExportSnapshot has failed a few times (that is probably because the
>> test it derives from is flakey) and TestMobRestoreFlushSnapshotFromClient
>> gets a mention.
>>
>> St.Ack
>>
>

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Ted Yu <yu...@gmail.com>]

If there is no objection, I will create a backport JIRA tomorrow and attach patch. 

Thanks

> On Feb 29, 2016, at 8:14 PM, Andrew Purtell <an...@gmail.com> wrote:
> 
> Thanks Jon. This is very helpful information for those of us who don't have visibility to these users. Answers my question. 
> 
> 
>> On Feb 29, 2016, at 6:56 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>> 
>> The feature is definitely not abandoned -- we have few sizable customers at
>> PB scale that I can recall off the top of my head that have been using it
>> for over 8-12 months in the version backported to CDH (we backported an
>> early version back in oct/14 (CDH5.2), and updated with the recent more
>> recent changes in roughly may/15 (CDH5.4).   These are used primarily to
>> store documents -- think PDF files. They are pretty happy -- the customer
>> reported that it was slightly slower on the write side (10-15%) than a
>> competing system but significantly faster on the read side (3x-4x
>> throughput).
>> 
>> Over the holidays we shook out a semi-rare data loss issue with mob
>> compaction that had this as the root cause[1] -- (since pointers are only
>> stored in the "normal hfiles" the volume of datas on this case was fairly
>> large).
>> 
>> We've been working on trying to get at least one of them to present at
>> hbasecon, but I'm not reviewing submissions this year and don't know if
>> they made it or not.
>> 
>> Jon.
>> 
>> [1] https://issues.apache.org/jira/browse/HBASE-15035
>> 
>> On Fri, Feb 26, 2016 at 12:27 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>> 
>>> ​I think we need at least one success story or one very interested user
>>> with a real project on the line to justify a backport. Otherwise it's a
>>> feature without any users - technically, abandoned. ​
>>> 
>>>> On Fri, Feb 26, 2016 at 10:11 AM, Ted Yu <yu...@gmail.com> wrote:
>>>> 
>>>> I am interested in hearing about user experience with MOB feature as
>>> well.
>>>> 
>>>> In my opinion, this feature is a nice addition to branch-1.
>>>> 
>>>> On Wed, Feb 10, 2016 at 1:45 PM, Andrew Purtell <ap...@apache.org>
>>>> wrote:
>>>> 
>>>>> +user@
>>>>> 
>>>>> Is there anyone using the MOB feature in trunk for anything who can
>>>> comment
>>>>> on how well it's been working out? Intel folks maybe?
>>>>> 
>>>>> On Thu, Jan 21, 2016 at 7:46 AM, Sean Busbey <bu...@apache.org>
>>> wrote:
>>>>> 
>>>>>> The last time MOB on branch-1 came up, folks were concerned that it
>>>>>> wasn't stable enough in master yet. Is that still the case?
>>>>>> 
>>>>>> Can we get a [DISCUSS] flagged thread to see what, if anything, folks
>>>>>> would like to see gate inclusion in branch-1?
>>>>>> 
>>>>>> On Tue, Jan 19, 2016 at 7:31 PM, Jonathan Hsieh <jo...@cloudera.com>
>>>>> wrote:
>>>>>>> +1 to 1.2 being feature complete corrently.  There has already
>>> been a
>>>>>>> release candidate and folks are burning down the blockers currently
>>>> to
>>>>>> prep
>>>>>>> for the next RC.
>>>>>>> 
>>>>>>> I like the idea of mob and sparkonhbase for 1.3.  I'm more
>>>> comfortable
>>>>>> with
>>>>>>> sparkonhbase -- it is a new module and thus not as invasive.
>>>>>>> 
>>>>>>> Jon.
>>>>>>> 
>>>>>>> On Tue, Jan 19, 2016 at 4:55 PM, Andrew Purtell <
>>>>>> andrew.purtell@gmail.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Pretty sure Sean expressed 1.2 is feature complete and I'd support
>>>>> that.
>>>>>>>> Can we wait for 1.3 for MOB ? Can look at Spark connector then
>>> too.
>>>>>>>> 
>>>>>>>>> On Jan 19, 2016, at 4:52 PM, Ted Yu <yu...@gmail.com>
>>> wrote:
>>>>>>>>> 
>>>>>>>>> Looks like 1.2.0 RC is in near future.
>>>>>>>>> 
>>>>>>>>> I wonder if it is time to revive this thread (due to customer
>>>>>> interest).
>>>>>>>>> 
>>>>>>>>> As far as I can tell, the Mob related tests have been passing in
>>>> the
>>>>>>>> recent
>>>>>>>>> past.
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> 
>>>>>>>>>> On Wed, Oct 28, 2015 at 2:07 PM, Andrew Purtell <
>>>>> apurtell@apache.org
>>>>>>> 
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> I haven't heard an user answer in the affirmative to wanting
>>> it.
>>>>>>>>>> 
>>>>>>>>>> I'll volunteer to RM 1.3, whenever we need it. Premature to
>>> have
>>>>> that
>>>>>>>>>> discussion without 1.2 even out the door yet, though.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Wed, Oct 28, 2015 at 1:01 PM, Stephen Jiang <
>>>>>> syuanjiangdev@gmail.com
>>>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Actually, it is actively changing in master branch on MOB
>>>> feature
>>>>>> made
>>>>>>>> me
>>>>>>>>>>> think about: if we ever want to port MOB feature to branch-1,
>>>> now
>>>>>> is a
>>>>>>>>>> good
>>>>>>>>>>> time.  We can commit changes in both branches; otherwise, we
>>>>>> probably
>>>>>>>>>> would
>>>>>>>>>>> miss some commits when we port MOB to branch-1 in a late time.
>>>>>>>>>>> 
>>>>>>>>>>> I am more thinking about 1.3 release (certainly not 1.2),
>>> which
>>>> we
>>>>>>>> still
>>>>>>>>>>> have some time to stabilize and allow interesting party to
>>> play
>>>>> with
>>>>>>>> the
>>>>>>>>>>> feature and give feedback.
>>>>>>>>>>> 
>>>>>>>>>>> Thanks
>>>>>>>>>>> Stephen
>>>>>>>>>>> 
>>>>>>>>>>> PS. given the features we discussed in 2.0.0 in the last
>>>> community
>>>>>>>>>> meeting,
>>>>>>>>>>> I think it would not release earlier than 1.3 :-), unless we
>>>>>>>>>> intentionally
>>>>>>>>>>> not find a release manager for 1.3.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Oct 28, 2015 at 9:09 AM, Sean Busbey <
>>>>> busbey@cloudera.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> It's practically November. Matteo, are you up for a thread on
>>>>>> target
>>>>>>>>>>>> dates for 2.0.0 to start RCs?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Oct 28, 2015 at 11:02 AM, Elliott Clark <
>>>>> eclark@apache.org
>>>>>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>>> I feel the same lets keep branch-1 stable, and work towards
>>> a
>>>>>> faster
>>>>>>>>>>>> 2.0.0.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Tue, Oct 27, 2015 at 4:52 PM, Stack <st...@duboce.net>
>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> IMO, MOB is still not settled in Master. It has a bunch of
>>>>> flakey
>>>>>>>>>>> tests
>>>>>>>>>>>>>> that are getting fixed by Jingcheng or I've disabled them
>>>> till
>>>>>>>>>> someone
>>>>>>>>>>>> has
>>>>>>>>>>>>>> time to look at them. There is also a load of duplicated
>>> code
>>>>>> that
>>>>>>>>>> is
>>>>>>>>>>>> being
>>>>>>>>>>>>>> cleaned up (Matteo).
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Its not ready to go back to branch-1 IMO.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Are there users who'd like it backported?
>>>>>>>>>>>>>> St.Ack
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 10:55 AM, Stephen Jiang <
>>>>>>>>>>>> syuanjiangdev@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hello, guys, the MOB is in master branch.  I saw bug fixes
>>>>>>>>>> happening
>>>>>>>>>>>> in
>>>>>>>>>>>>>>> master branch.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I just wonder whether there is a plan to put MOB in
>>>>> branch-1.  I
>>>>>>>>>> am
>>>>>>>>>>>>>> afraid
>>>>>>>>>>>>>>> if we don't do it now, it would be harder in the future to
>>>>> back
>>>>>>>>>> port
>>>>>>>>>>>> if
>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>> decide to do it in a late time.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Stephen
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Thu, Jul 23, 2015 at 1:15 PM, Andrew Purtell <
>>>>>>>>>>> apurtell@apache.org>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Thanks Jon.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> When I'm back in the office I'll check out master and
>>> have
>>>> a
>>>>>>>>>> look
>>>>>>>>>>>> into
>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>> locally repeatable test failures. Anyway in my opinion at
>>>>> this
>>>>>>>>>>>> point it
>>>>>>>>>>>>>>>> would make the most sense for us to keep the MOB changes
>>> in
>>>>> on
>>>>>>>>>>>> master
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> deal with any fallout in follow on issues. I think all
>>> who
>>>>>> voted
>>>>>>>>>>> +1
>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> this change were aware that large changes like this can
>>>> have
>>>>> a
>>>>>>>>>>>>>>> temporarily
>>>>>>>>>>>>>>>> destabilizing effect. As long as the MOB devs are around
>>> to
>>>>>> help
>>>>>>>>>>>> clean
>>>>>>>>>>>>>>> up,
>>>>>>>>>>>>>>>> we should be good!
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 8:09 PM, Jonathan Hsieh <
>>>>>>>>>> jon@cloudera.com
>>>>>>>>>>>> 
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I had two clean full builds/unit test on my internal
>>> setup
>>>>> and
>>>>>>>>>>> the
>>>>>>>>>>>>>>> latest
>>>>>>>>>>>>>>>>> build went back to ~4325 total tests and failures on
>>>>> Procedure
>>>>>>>>>>>> relate
>>>>>>>>>>>>>>>> tests
>>>>>>>>>>>>>>>>> cases.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I don't think mob is responsible for these failures.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Jon.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 4:32 PM, Jonathan Hsieh <
>>>>>>>>>>> jon@cloudera.com
>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Although the the precommit buiid passed, and the
>>>>> compilation
>>>>>>>>>>> and
>>>>>>>>>>>>>> mob
>>>>>>>>>>>>>>>>>> testing I ran after before the merge was commited
>>> passed,
>>>>> It
>>>>>>>>>>>> looks
>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>> the first full build after the merge [1] failed.  It
>>>> looked
>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>> something hung along the way, and that most of the
>>>> previous
>>>>>>>>>>>> builds
>>>>>>>>>>>>>>> had
>>>>>>>>>>>>>>>>>> failed for various reasons. :(
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I kicked it off again have it do another try.  If it is
>>>> mob
>>>>>>>>>>>> related
>>>>>>>>>>>>>>>> we'll
>>>>>>>>>>>>>>>>>> take hunt it down and take care of it.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Jon.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> [1] https://builds.apache.org/job/HBase-TRUNK/6672/
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 1:16 PM, Jonathan Hsieh <
>>>>>>>>>>>> jon@cloudera.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I've merged the code in to master.  Thanks for all the
>>>>> hard
>>>>>>>>>>>> work
>>>>>>>>>>>>>>>>>>> Jingcheng and thanks to all who have been involved
>>> with
>>>>>>>>>>>> reviews,
>>>>>>>>>>>>>>>>>>> discussion, and voting!
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Jon
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 12:45 AM, Jingcheng Du <
>>>>>>>>>>>>>>>> jingcheng.du@intel.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> The vote passes with 8 +1s and no -1. Thanks all for
>>>>>>>>>>> guiding,
>>>>>>>>>>>>>>> helping
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> voting!
>>>>>>>>>>>>>>>>>>>> We will work on the merge activities and will let
>>> guys
>>>>>>>>>> know
>>>>>>>>>>>> about
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> detailed plan for merge time.
>>>>>>>>>>>>>>>>>>>> And thanks Jon for helping merge this branch to
>>> trunk!
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>> Jingcheng
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> View this message in context:
>>> http://apache-hbase.679495.n3.nabble.com/RESULT-VOTE-Merge-branch-hbase-11339-HBase-MOB-to-trunk-tp4073446.html
>>>>>>>>>>>>>>>>>>>> Sent from the HBase Developer mailing list archive at
>>>>>>>>>>>> Nabble.com.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> // Jonathan Hsieh (shay)
>>>>>>>>>>>>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
>>>>>>>>>>>>>>>>>>> // jon@cloudera.com // @jmhsieh
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> // Jonathan Hsieh (shay)
>>>>>>>>>>>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
>>>>>>>>>>>>>>>>>> // jon@cloudera.com // @jmhsieh
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> // Jonathan Hsieh (shay)
>>>>>>>>>>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
>>>>>>>>>>>>>>>>> // jon@cloudera.com // @jmhsieh
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Problems worthy of attack prove their worth by hitting
>>>> back.
>>>>> -
>>>>>>>>>>> Piet
>>>>>>>>>>>>>> Hein
>>>>>>>>>>>>>>>> (via Tom White)
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Sean
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>> // jon@cloudera.com // @jmhsieh
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 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
>> // jon@cloudera.com // @jmhsieh

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Ted Yu <yu...@gmail.com>]

If there is no objection, I will create a backport JIRA tomorrow and attach patch. 

Thanks

> On Feb 29, 2016, at 8:14 PM, Andrew Purtell <an...@gmail.com> wrote:
> 
> Thanks Jon. This is very helpful information for those of us who don't have visibility to these users. Answers my question. 
> 
> 
>> On Feb 29, 2016, at 6:56 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>> 
>> The feature is definitely not abandoned -- we have few sizable customers at
>> PB scale that I can recall off the top of my head that have been using it
>> for over 8-12 months in the version backported to CDH (we backported an
>> early version back in oct/14 (CDH5.2), and updated with the recent more
>> recent changes in roughly may/15 (CDH5.4).   These are used primarily to
>> store documents -- think PDF files. They are pretty happy -- the customer
>> reported that it was slightly slower on the write side (10-15%) than a
>> competing system but significantly faster on the read side (3x-4x
>> throughput).
>> 
>> Over the holidays we shook out a semi-rare data loss issue with mob
>> compaction that had this as the root cause[1] -- (since pointers are only
>> stored in the "normal hfiles" the volume of datas on this case was fairly
>> large).
>> 
>> We've been working on trying to get at least one of them to present at
>> hbasecon, but I'm not reviewing submissions this year and don't know if
>> they made it or not.
>> 
>> Jon.
>> 
>> [1] https://issues.apache.org/jira/browse/HBASE-15035
>> 
>> On Fri, Feb 26, 2016 at 12:27 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>> 
>>> ​I think we need at least one success story or one very interested user
>>> with a real project on the line to justify a backport. Otherwise it's a
>>> feature without any users - technically, abandoned. ​
>>> 
>>>> On Fri, Feb 26, 2016 at 10:11 AM, Ted Yu <yu...@gmail.com> wrote:
>>>> 
>>>> I am interested in hearing about user experience with MOB feature as
>>> well.
>>>> 
>>>> In my opinion, this feature is a nice addition to branch-1.
>>>> 
>>>> On Wed, Feb 10, 2016 at 1:45 PM, Andrew Purtell <ap...@apache.org>
>>>> wrote:
>>>> 
>>>>> +user@
>>>>> 
>>>>> Is there anyone using the MOB feature in trunk for anything who can
>>>> comment
>>>>> on how well it's been working out? Intel folks maybe?
>>>>> 
>>>>> On Thu, Jan 21, 2016 at 7:46 AM, Sean Busbey <bu...@apache.org>
>>> wrote:
>>>>> 
>>>>>> The last time MOB on branch-1 came up, folks were concerned that it
>>>>>> wasn't stable enough in master yet. Is that still the case?
>>>>>> 
>>>>>> Can we get a [DISCUSS] flagged thread to see what, if anything, folks
>>>>>> would like to see gate inclusion in branch-1?
>>>>>> 
>>>>>> On Tue, Jan 19, 2016 at 7:31 PM, Jonathan Hsieh <jo...@cloudera.com>
>>>>> wrote:
>>>>>>> +1 to 1.2 being feature complete corrently.  There has already
>>> been a
>>>>>>> release candidate and folks are burning down the blockers currently
>>>> to
>>>>>> prep
>>>>>>> for the next RC.
>>>>>>> 
>>>>>>> I like the idea of mob and sparkonhbase for 1.3.  I'm more
>>>> comfortable
>>>>>> with
>>>>>>> sparkonhbase -- it is a new module and thus not as invasive.
>>>>>>> 
>>>>>>> Jon.
>>>>>>> 
>>>>>>> On Tue, Jan 19, 2016 at 4:55 PM, Andrew Purtell <
>>>>>> andrew.purtell@gmail.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Pretty sure Sean expressed 1.2 is feature complete and I'd support
>>>>> that.
>>>>>>>> Can we wait for 1.3 for MOB ? Can look at Spark connector then
>>> too.
>>>>>>>> 
>>>>>>>>> On Jan 19, 2016, at 4:52 PM, Ted Yu <yu...@gmail.com>
>>> wrote:
>>>>>>>>> 
>>>>>>>>> Looks like 1.2.0 RC is in near future.
>>>>>>>>> 
>>>>>>>>> I wonder if it is time to revive this thread (due to customer
>>>>>> interest).
>>>>>>>>> 
>>>>>>>>> As far as I can tell, the Mob related tests have been passing in
>>>> the
>>>>>>>> recent
>>>>>>>>> past.
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> 
>>>>>>>>>> On Wed, Oct 28, 2015 at 2:07 PM, Andrew Purtell <
>>>>> apurtell@apache.org
>>>>>>> 
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> I haven't heard an user answer in the affirmative to wanting
>>> it.
>>>>>>>>>> 
>>>>>>>>>> I'll volunteer to RM 1.3, whenever we need it. Premature to
>>> have
>>>>> that
>>>>>>>>>> discussion without 1.2 even out the door yet, though.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Wed, Oct 28, 2015 at 1:01 PM, Stephen Jiang <
>>>>>> syuanjiangdev@gmail.com
>>>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Actually, it is actively changing in master branch on MOB
>>>> feature
>>>>>> made
>>>>>>>> me
>>>>>>>>>>> think about: if we ever want to port MOB feature to branch-1,
>>>> now
>>>>>> is a
>>>>>>>>>> good
>>>>>>>>>>> time.  We can commit changes in both branches; otherwise, we
>>>>>> probably
>>>>>>>>>> would
>>>>>>>>>>> miss some commits when we port MOB to branch-1 in a late time.
>>>>>>>>>>> 
>>>>>>>>>>> I am more thinking about 1.3 release (certainly not 1.2),
>>> which
>>>> we
>>>>>>>> still
>>>>>>>>>>> have some time to stabilize and allow interesting party to
>>> play
>>>>> with
>>>>>>>> the
>>>>>>>>>>> feature and give feedback.
>>>>>>>>>>> 
>>>>>>>>>>> Thanks
>>>>>>>>>>> Stephen
>>>>>>>>>>> 
>>>>>>>>>>> PS. given the features we discussed in 2.0.0 in the last
>>>> community
>>>>>>>>>> meeting,
>>>>>>>>>>> I think it would not release earlier than 1.3 :-), unless we
>>>>>>>>>> intentionally
>>>>>>>>>>> not find a release manager for 1.3.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Oct 28, 2015 at 9:09 AM, Sean Busbey <
>>>>> busbey@cloudera.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> It's practically November. Matteo, are you up for a thread on
>>>>>> target
>>>>>>>>>>>> dates for 2.0.0 to start RCs?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Oct 28, 2015 at 11:02 AM, Elliott Clark <
>>>>> eclark@apache.org
>>>>>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>>> I feel the same lets keep branch-1 stable, and work towards
>>> a
>>>>>> faster
>>>>>>>>>>>> 2.0.0.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Tue, Oct 27, 2015 at 4:52 PM, Stack <st...@duboce.net>
>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> IMO, MOB is still not settled in Master. It has a bunch of
>>>>> flakey
>>>>>>>>>>> tests
>>>>>>>>>>>>>> that are getting fixed by Jingcheng or I've disabled them
>>>> till
>>>>>>>>>> someone
>>>>>>>>>>>> has
>>>>>>>>>>>>>> time to look at them. There is also a load of duplicated
>>> code
>>>>>> that
>>>>>>>>>> is
>>>>>>>>>>>> being
>>>>>>>>>>>>>> cleaned up (Matteo).
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Its not ready to go back to branch-1 IMO.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Are there users who'd like it backported?
>>>>>>>>>>>>>> St.Ack
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 10:55 AM, Stephen Jiang <
>>>>>>>>>>>> syuanjiangdev@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hello, guys, the MOB is in master branch.  I saw bug fixes
>>>>>>>>>> happening
>>>>>>>>>>>> in
>>>>>>>>>>>>>>> master branch.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I just wonder whether there is a plan to put MOB in
>>>>> branch-1.  I
>>>>>>>>>> am
>>>>>>>>>>>>>> afraid
>>>>>>>>>>>>>>> if we don't do it now, it would be harder in the future to
>>>>> back
>>>>>>>>>> port
>>>>>>>>>>>> if
>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>> decide to do it in a late time.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Stephen
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Thu, Jul 23, 2015 at 1:15 PM, Andrew Purtell <
>>>>>>>>>>> apurtell@apache.org>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Thanks Jon.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> When I'm back in the office I'll check out master and
>>> have
>>>> a
>>>>>>>>>> look
>>>>>>>>>>>> into
>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>> locally repeatable test failures. Anyway in my opinion at
>>>>> this
>>>>>>>>>>>> point it
>>>>>>>>>>>>>>>> would make the most sense for us to keep the MOB changes
>>> in
>>>>> on
>>>>>>>>>>>> master
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> deal with any fallout in follow on issues. I think all
>>> who
>>>>>> voted
>>>>>>>>>>> +1
>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> this change were aware that large changes like this can
>>>> have
>>>>> a
>>>>>>>>>>>>>>> temporarily
>>>>>>>>>>>>>>>> destabilizing effect. As long as the MOB devs are around
>>> to
>>>>>> help
>>>>>>>>>>>> clean
>>>>>>>>>>>>>>> up,
>>>>>>>>>>>>>>>> we should be good!
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 8:09 PM, Jonathan Hsieh <
>>>>>>>>>> jon@cloudera.com
>>>>>>>>>>>> 
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I had two clean full builds/unit test on my internal
>>> setup
>>>>> and
>>>>>>>>>>> the
>>>>>>>>>>>>>>> latest
>>>>>>>>>>>>>>>>> build went back to ~4325 total tests and failures on
>>>>> Procedure
>>>>>>>>>>>> relate
>>>>>>>>>>>>>>>> tests
>>>>>>>>>>>>>>>>> cases.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I don't think mob is responsible for these failures.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Jon.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 4:32 PM, Jonathan Hsieh <
>>>>>>>>>>> jon@cloudera.com
>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Although the the precommit buiid passed, and the
>>>>> compilation
>>>>>>>>>>> and
>>>>>>>>>>>>>> mob
>>>>>>>>>>>>>>>>>> testing I ran after before the merge was commited
>>> passed,
>>>>> It
>>>>>>>>>>>> looks
>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>> the first full build after the merge [1] failed.  It
>>>> looked
>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>> something hung along the way, and that most of the
>>>> previous
>>>>>>>>>>>> builds
>>>>>>>>>>>>>>> had
>>>>>>>>>>>>>>>>>> failed for various reasons. :(
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I kicked it off again have it do another try.  If it is
>>>> mob
>>>>>>>>>>>> related
>>>>>>>>>>>>>>>> we'll
>>>>>>>>>>>>>>>>>> take hunt it down and take care of it.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Jon.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> [1] https://builds.apache.org/job/HBase-TRUNK/6672/
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 1:16 PM, Jonathan Hsieh <
>>>>>>>>>>>> jon@cloudera.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I've merged the code in to master.  Thanks for all the
>>>>> hard
>>>>>>>>>>>> work
>>>>>>>>>>>>>>>>>>> Jingcheng and thanks to all who have been involved
>>> with
>>>>>>>>>>>> reviews,
>>>>>>>>>>>>>>>>>>> discussion, and voting!
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Jon
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 12:45 AM, Jingcheng Du <
>>>>>>>>>>>>>>>> jingcheng.du@intel.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> The vote passes with 8 +1s and no -1. Thanks all for
>>>>>>>>>>> guiding,
>>>>>>>>>>>>>>> helping
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> voting!
>>>>>>>>>>>>>>>>>>>> We will work on the merge activities and will let
>>> guys
>>>>>>>>>> know
>>>>>>>>>>>> about
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> detailed plan for merge time.
>>>>>>>>>>>>>>>>>>>> And thanks Jon for helping merge this branch to
>>> trunk!
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>> Jingcheng
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> View this message in context:
>>> http://apache-hbase.679495.n3.nabble.com/RESULT-VOTE-Merge-branch-hbase-11339-HBase-MOB-to-trunk-tp4073446.html
>>>>>>>>>>>>>>>>>>>> Sent from the HBase Developer mailing list archive at
>>>>>>>>>>>> Nabble.com.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> // Jonathan Hsieh (shay)
>>>>>>>>>>>>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
>>>>>>>>>>>>>>>>>>> // jon@cloudera.com // @jmhsieh
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> // Jonathan Hsieh (shay)
>>>>>>>>>>>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
>>>>>>>>>>>>>>>>>> // jon@cloudera.com // @jmhsieh
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> // Jonathan Hsieh (shay)
>>>>>>>>>>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
>>>>>>>>>>>>>>>>> // jon@cloudera.com // @jmhsieh
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Problems worthy of attack prove their worth by hitting
>>>> back.
>>>>> -
>>>>>>>>>>> Piet
>>>>>>>>>>>>>> Hein
>>>>>>>>>>>>>>>> (via Tom White)
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Sean
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>> // jon@cloudera.com // @jmhsieh
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 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
>> // jon@cloudera.com // @jmhsieh

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Andrew Purtell <an...@gmail.com>]

Thanks Jon. This is very helpful information for those of us who don't have visibility to these users. Answers my question. 


> On Feb 29, 2016, at 6:56 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
> 
> The feature is definitely not abandoned -- we have few sizable customers at
> PB scale that I can recall off the top of my head that have been using it
> for over 8-12 months in the version backported to CDH (we backported an
> early version back in oct/14 (CDH5.2), and updated with the recent more
> recent changes in roughly may/15 (CDH5.4).   These are used primarily to
> store documents -- think PDF files. They are pretty happy -- the customer
> reported that it was slightly slower on the write side (10-15%) than a
> competing system but significantly faster on the read side (3x-4x
> throughput).
> 
> Over the holidays we shook out a semi-rare data loss issue with mob
> compaction that had this as the root cause[1] -- (since pointers are only
> stored in the "normal hfiles" the volume of datas on this case was fairly
> large).
> 
> We've been working on trying to get at least one of them to present at
> hbasecon, but I'm not reviewing submissions this year and don't know if
> they made it or not.
> 
> Jon.
> 
> [1] https://issues.apache.org/jira/browse/HBASE-15035
> 
> On Fri, Feb 26, 2016 at 12:27 PM, Andrew Purtell <ap...@apache.org>
> wrote:
> 
>> ​I think we need at least one success story or one very interested user
>> with a real project on the line to justify a backport. Otherwise it's a
>> feature without any users - technically, abandoned. ​
>> 
>>> On Fri, Feb 26, 2016 at 10:11 AM, Ted Yu <yu...@gmail.com> wrote:
>>> 
>>> I am interested in hearing about user experience with MOB feature as
>> well.
>>> 
>>> In my opinion, this feature is a nice addition to branch-1.
>>> 
>>> On Wed, Feb 10, 2016 at 1:45 PM, Andrew Purtell <ap...@apache.org>
>>> wrote:
>>> 
>>>> +user@
>>>> 
>>>> Is there anyone using the MOB feature in trunk for anything who can
>>> comment
>>>> on how well it's been working out? Intel folks maybe?
>>>> 
>>>> On Thu, Jan 21, 2016 at 7:46 AM, Sean Busbey <bu...@apache.org>
>> wrote:
>>>> 
>>>>> The last time MOB on branch-1 came up, folks were concerned that it
>>>>> wasn't stable enough in master yet. Is that still the case?
>>>>> 
>>>>> Can we get a [DISCUSS] flagged thread to see what, if anything, folks
>>>>> would like to see gate inclusion in branch-1?
>>>>> 
>>>>> On Tue, Jan 19, 2016 at 7:31 PM, Jonathan Hsieh <jo...@cloudera.com>
>>>> wrote:
>>>>>> +1 to 1.2 being feature complete corrently.  There has already
>> been a
>>>>>> release candidate and folks are burning down the blockers currently
>>> to
>>>>> prep
>>>>>> for the next RC.
>>>>>> 
>>>>>> I like the idea of mob and sparkonhbase for 1.3.  I'm more
>>> comfortable
>>>>> with
>>>>>> sparkonhbase -- it is a new module and thus not as invasive.
>>>>>> 
>>>>>> Jon.
>>>>>> 
>>>>>> On Tue, Jan 19, 2016 at 4:55 PM, Andrew Purtell <
>>>>> andrew.purtell@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Pretty sure Sean expressed 1.2 is feature complete and I'd support
>>>> that.
>>>>>>> Can we wait for 1.3 for MOB ? Can look at Spark connector then
>> too.
>>>>>>> 
>>>>>>>> On Jan 19, 2016, at 4:52 PM, Ted Yu <yu...@gmail.com>
>> wrote:
>>>>>>>> 
>>>>>>>> Looks like 1.2.0 RC is in near future.
>>>>>>>> 
>>>>>>>> I wonder if it is time to revive this thread (due to customer
>>>>> interest).
>>>>>>>> 
>>>>>>>> As far as I can tell, the Mob related tests have been passing in
>>> the
>>>>>>> recent
>>>>>>>> past.
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> 
>>>>>>>>> On Wed, Oct 28, 2015 at 2:07 PM, Andrew Purtell <
>>>> apurtell@apache.org
>>>>>> 
>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> I haven't heard an user answer in the affirmative to wanting
>> it.
>>>>>>>>> 
>>>>>>>>> I'll volunteer to RM 1.3, whenever we need it. Premature to
>> have
>>>> that
>>>>>>>>> discussion without 1.2 even out the door yet, though.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, Oct 28, 2015 at 1:01 PM, Stephen Jiang <
>>>>> syuanjiangdev@gmail.com
>>>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Actually, it is actively changing in master branch on MOB
>>> feature
>>>>> made
>>>>>>> me
>>>>>>>>>> think about: if we ever want to port MOB feature to branch-1,
>>> now
>>>>> is a
>>>>>>>>> good
>>>>>>>>>> time.  We can commit changes in both branches; otherwise, we
>>>>> probably
>>>>>>>>> would
>>>>>>>>>> miss some commits when we port MOB to branch-1 in a late time.
>>>>>>>>>> 
>>>>>>>>>> I am more thinking about 1.3 release (certainly not 1.2),
>> which
>>> we
>>>>>>> still
>>>>>>>>>> have some time to stabilize and allow interesting party to
>> play
>>>> with
>>>>>>> the
>>>>>>>>>> feature and give feedback.
>>>>>>>>>> 
>>>>>>>>>> Thanks
>>>>>>>>>> Stephen
>>>>>>>>>> 
>>>>>>>>>> PS. given the features we discussed in 2.0.0 in the last
>>> community
>>>>>>>>> meeting,
>>>>>>>>>> I think it would not release earlier than 1.3 :-), unless we
>>>>>>>>> intentionally
>>>>>>>>>> not find a release manager for 1.3.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On Wed, Oct 28, 2015 at 9:09 AM, Sean Busbey <
>>>> busbey@cloudera.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> It's practically November. Matteo, are you up for a thread on
>>>>> target
>>>>>>>>>>> dates for 2.0.0 to start RCs?
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Wed, Oct 28, 2015 at 11:02 AM, Elliott Clark <
>>>> eclark@apache.org
>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>>> I feel the same lets keep branch-1 stable, and work towards
>> a
>>>>> faster
>>>>>>>>>>> 2.0.0.
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Tue, Oct 27, 2015 at 4:52 PM, Stack <st...@duboce.net>
>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> IMO, MOB is still not settled in Master. It has a bunch of
>>>> flakey
>>>>>>>>>> tests
>>>>>>>>>>>>> that are getting fixed by Jingcheng or I've disabled them
>>> till
>>>>>>>>> someone
>>>>>>>>>>> has
>>>>>>>>>>>>> time to look at them. There is also a load of duplicated
>> code
>>>>> that
>>>>>>>>> is
>>>>>>>>>>> being
>>>>>>>>>>>>> cleaned up (Matteo).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Its not ready to go back to branch-1 IMO.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Are there users who'd like it backported?
>>>>>>>>>>>>> St.Ack
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 10:55 AM, Stephen Jiang <
>>>>>>>>>>> syuanjiangdev@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hello, guys, the MOB is in master branch.  I saw bug fixes
>>>>>>>>> happening
>>>>>>>>>>> in
>>>>>>>>>>>>>> master branch.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I just wonder whether there is a plan to put MOB in
>>>> branch-1.  I
>>>>>>>>> am
>>>>>>>>>>>>> afraid
>>>>>>>>>>>>>> if we don't do it now, it would be harder in the future to
>>>> back
>>>>>>>>> port
>>>>>>>>>>> if
>>>>>>>>>>>>> we
>>>>>>>>>>>>>> decide to do it in a late time.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Stephen
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Thu, Jul 23, 2015 at 1:15 PM, Andrew Purtell <
>>>>>>>>>> apurtell@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks Jon.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> When I'm back in the office I'll check out master and
>> have
>>> a
>>>>>>>>> look
>>>>>>>>>>> into
>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>> locally repeatable test failures. Anyway in my opinion at
>>>> this
>>>>>>>>>>> point it
>>>>>>>>>>>>>>> would make the most sense for us to keep the MOB changes
>> in
>>>> on
>>>>>>>>>>> master
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> deal with any fallout in follow on issues. I think all
>> who
>>>>> voted
>>>>>>>>>> +1
>>>>>>>>>>> for
>>>>>>>>>>>>>>> this change were aware that large changes like this can
>>> have
>>>> a
>>>>>>>>>>>>>> temporarily
>>>>>>>>>>>>>>> destabilizing effect. As long as the MOB devs are around
>> to
>>>>> help
>>>>>>>>>>> clean
>>>>>>>>>>>>>> up,
>>>>>>>>>>>>>>> we should be good!
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 8:09 PM, Jonathan Hsieh <
>>>>>>>>> jon@cloudera.com
>>>>>>>>>>> 
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I had two clean full builds/unit test on my internal
>> setup
>>>> and
>>>>>>>>>> the
>>>>>>>>>>>>>> latest
>>>>>>>>>>>>>>>> build went back to ~4325 total tests and failures on
>>>> Procedure
>>>>>>>>>>> relate
>>>>>>>>>>>>>>> tests
>>>>>>>>>>>>>>>> cases.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I don't think mob is responsible for these failures.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Jon.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 4:32 PM, Jonathan Hsieh <
>>>>>>>>>> jon@cloudera.com
>>>>>>>>>>>> 
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Although the the precommit buiid passed, and the
>>>> compilation
>>>>>>>>>> and
>>>>>>>>>>>>> mob
>>>>>>>>>>>>>>>>> testing I ran after before the merge was commited
>> passed,
>>>> It
>>>>>>>>>>> looks
>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>> the first full build after the merge [1] failed.  It
>>> looked
>>>>>>>>>> like
>>>>>>>>>>>>>>>>> something hung along the way, and that most of the
>>> previous
>>>>>>>>>>> builds
>>>>>>>>>>>>>> had
>>>>>>>>>>>>>>>>> failed for various reasons. :(
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I kicked it off again have it do another try.  If it is
>>> mob
>>>>>>>>>>> related
>>>>>>>>>>>>>>> we'll
>>>>>>>>>>>>>>>>> take hunt it down and take care of it.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Jon.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> [1] https://builds.apache.org/job/HBase-TRUNK/6672/
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 1:16 PM, Jonathan Hsieh <
>>>>>>>>>>> jon@cloudera.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I've merged the code in to master.  Thanks for all the
>>>> hard
>>>>>>>>>>> work
>>>>>>>>>>>>>>>>>> Jingcheng and thanks to all who have been involved
>> with
>>>>>>>>>>> reviews,
>>>>>>>>>>>>>>>>>> discussion, and voting!
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Jon
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 12:45 AM, Jingcheng Du <
>>>>>>>>>>>>>>> jingcheng.du@intel.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> The vote passes with 8 +1s and no -1. Thanks all for
>>>>>>>>>> guiding,
>>>>>>>>>>>>>> helping
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> voting!
>>>>>>>>>>>>>>>>>>> We will work on the merge activities and will let
>> guys
>>>>>>>>> know
>>>>>>>>>>> about
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> detailed plan for merge time.
>>>>>>>>>>>>>>>>>>> And thanks Jon for helping merge this branch to
>> trunk!
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>> Jingcheng
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> View this message in context:
>> http://apache-hbase.679495.n3.nabble.com/RESULT-VOTE-Merge-branch-hbase-11339-HBase-MOB-to-trunk-tp4073446.html
>>>>>>>>>>>>>>>>>>> Sent from the HBase Developer mailing list archive at
>>>>>>>>>>> Nabble.com.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> // Jonathan Hsieh (shay)
>>>>>>>>>>>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
>>>>>>>>>>>>>>>>>> // jon@cloudera.com // @jmhsieh
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> // Jonathan Hsieh (shay)
>>>>>>>>>>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
>>>>>>>>>>>>>>>>> // jon@cloudera.com // @jmhsieh
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> // Jonathan Hsieh (shay)
>>>>>>>>>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
>>>>>>>>>>>>>>>> // jon@cloudera.com // @jmhsieh
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>  - Andy
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Problems worthy of attack prove their worth by hitting
>>> back.
>>>> -
>>>>>>>>>> Piet
>>>>>>>>>>>>> Hein
>>>>>>>>>>>>>>> (via Tom White)
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Sean
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> 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
>>>>>> // jon@cloudera.com // @jmhsieh
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 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
> // jon@cloudera.com // @jmhsieh

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Andrew Purtell <an...@gmail.com>]

Thanks Jon. This is very helpful information for those of us who don't have visibility to these users. Answers my question. 


> On Feb 29, 2016, at 6:56 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
> 
> The feature is definitely not abandoned -- we have few sizable customers at
> PB scale that I can recall off the top of my head that have been using it
> for over 8-12 months in the version backported to CDH (we backported an
> early version back in oct/14 (CDH5.2), and updated with the recent more
> recent changes in roughly may/15 (CDH5.4).   These are used primarily to
> store documents -- think PDF files. They are pretty happy -- the customer
> reported that it was slightly slower on the write side (10-15%) than a
> competing system but significantly faster on the read side (3x-4x
> throughput).
> 
> Over the holidays we shook out a semi-rare data loss issue with mob
> compaction that had this as the root cause[1] -- (since pointers are only
> stored in the "normal hfiles" the volume of datas on this case was fairly
> large).
> 
> We've been working on trying to get at least one of them to present at
> hbasecon, but I'm not reviewing submissions this year and don't know if
> they made it or not.
> 
> Jon.
> 
> [1] https://issues.apache.org/jira/browse/HBASE-15035
> 
> On Fri, Feb 26, 2016 at 12:27 PM, Andrew Purtell <ap...@apache.org>
> wrote:
> 
>> ​I think we need at least one success story or one very interested user
>> with a real project on the line to justify a backport. Otherwise it's a
>> feature without any users - technically, abandoned. ​
>> 
>>> On Fri, Feb 26, 2016 at 10:11 AM, Ted Yu <yu...@gmail.com> wrote:
>>> 
>>> I am interested in hearing about user experience with MOB feature as
>> well.
>>> 
>>> In my opinion, this feature is a nice addition to branch-1.
>>> 
>>> On Wed, Feb 10, 2016 at 1:45 PM, Andrew Purtell <ap...@apache.org>
>>> wrote:
>>> 
>>>> +user@
>>>> 
>>>> Is there anyone using the MOB feature in trunk for anything who can
>>> comment
>>>> on how well it's been working out? Intel folks maybe?
>>>> 
>>>> On Thu, Jan 21, 2016 at 7:46 AM, Sean Busbey <bu...@apache.org>
>> wrote:
>>>> 
>>>>> The last time MOB on branch-1 came up, folks were concerned that it
>>>>> wasn't stable enough in master yet. Is that still the case?
>>>>> 
>>>>> Can we get a [DISCUSS] flagged thread to see what, if anything, folks
>>>>> would like to see gate inclusion in branch-1?
>>>>> 
>>>>> On Tue, Jan 19, 2016 at 7:31 PM, Jonathan Hsieh <jo...@cloudera.com>
>>>> wrote:
>>>>>> +1 to 1.2 being feature complete corrently.  There has already
>> been a
>>>>>> release candidate and folks are burning down the blockers currently
>>> to
>>>>> prep
>>>>>> for the next RC.
>>>>>> 
>>>>>> I like the idea of mob and sparkonhbase for 1.3.  I'm more
>>> comfortable
>>>>> with
>>>>>> sparkonhbase -- it is a new module and thus not as invasive.
>>>>>> 
>>>>>> Jon.
>>>>>> 
>>>>>> On Tue, Jan 19, 2016 at 4:55 PM, Andrew Purtell <
>>>>> andrew.purtell@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Pretty sure Sean expressed 1.2 is feature complete and I'd support
>>>> that.
>>>>>>> Can we wait for 1.3 for MOB ? Can look at Spark connector then
>> too.
>>>>>>> 
>>>>>>>> On Jan 19, 2016, at 4:52 PM, Ted Yu <yu...@gmail.com>
>> wrote:
>>>>>>>> 
>>>>>>>> Looks like 1.2.0 RC is in near future.
>>>>>>>> 
>>>>>>>> I wonder if it is time to revive this thread (due to customer
>>>>> interest).
>>>>>>>> 
>>>>>>>> As far as I can tell, the Mob related tests have been passing in
>>> the
>>>>>>> recent
>>>>>>>> past.
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> 
>>>>>>>>> On Wed, Oct 28, 2015 at 2:07 PM, Andrew Purtell <
>>>> apurtell@apache.org
>>>>>> 
>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> I haven't heard an user answer in the affirmative to wanting
>> it.
>>>>>>>>> 
>>>>>>>>> I'll volunteer to RM 1.3, whenever we need it. Premature to
>> have
>>>> that
>>>>>>>>> discussion without 1.2 even out the door yet, though.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, Oct 28, 2015 at 1:01 PM, Stephen Jiang <
>>>>> syuanjiangdev@gmail.com
>>>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Actually, it is actively changing in master branch on MOB
>>> feature
>>>>> made
>>>>>>> me
>>>>>>>>>> think about: if we ever want to port MOB feature to branch-1,
>>> now
>>>>> is a
>>>>>>>>> good
>>>>>>>>>> time.  We can commit changes in both branches; otherwise, we
>>>>> probably
>>>>>>>>> would
>>>>>>>>>> miss some commits when we port MOB to branch-1 in a late time.
>>>>>>>>>> 
>>>>>>>>>> I am more thinking about 1.3 release (certainly not 1.2),
>> which
>>> we
>>>>>>> still
>>>>>>>>>> have some time to stabilize and allow interesting party to
>> play
>>>> with
>>>>>>> the
>>>>>>>>>> feature and give feedback.
>>>>>>>>>> 
>>>>>>>>>> Thanks
>>>>>>>>>> Stephen
>>>>>>>>>> 
>>>>>>>>>> PS. given the features we discussed in 2.0.0 in the last
>>> community
>>>>>>>>> meeting,
>>>>>>>>>> I think it would not release earlier than 1.3 :-), unless we
>>>>>>>>> intentionally
>>>>>>>>>> not find a release manager for 1.3.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On Wed, Oct 28, 2015 at 9:09 AM, Sean Busbey <
>>>> busbey@cloudera.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> It's practically November. Matteo, are you up for a thread on
>>>>> target
>>>>>>>>>>> dates for 2.0.0 to start RCs?
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Wed, Oct 28, 2015 at 11:02 AM, Elliott Clark <
>>>> eclark@apache.org
>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>>> I feel the same lets keep branch-1 stable, and work towards
>> a
>>>>> faster
>>>>>>>>>>> 2.0.0.
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Tue, Oct 27, 2015 at 4:52 PM, Stack <st...@duboce.net>
>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> IMO, MOB is still not settled in Master. It has a bunch of
>>>> flakey
>>>>>>>>>> tests
>>>>>>>>>>>>> that are getting fixed by Jingcheng or I've disabled them
>>> till
>>>>>>>>> someone
>>>>>>>>>>> has
>>>>>>>>>>>>> time to look at them. There is also a load of duplicated
>> code
>>>>> that
>>>>>>>>> is
>>>>>>>>>>> being
>>>>>>>>>>>>> cleaned up (Matteo).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Its not ready to go back to branch-1 IMO.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Are there users who'd like it backported?
>>>>>>>>>>>>> St.Ack
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 10:55 AM, Stephen Jiang <
>>>>>>>>>>> syuanjiangdev@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hello, guys, the MOB is in master branch.  I saw bug fixes
>>>>>>>>> happening
>>>>>>>>>>> in
>>>>>>>>>>>>>> master branch.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I just wonder whether there is a plan to put MOB in
>>>> branch-1.  I
>>>>>>>>> am
>>>>>>>>>>>>> afraid
>>>>>>>>>>>>>> if we don't do it now, it would be harder in the future to
>>>> back
>>>>>>>>> port
>>>>>>>>>>> if
>>>>>>>>>>>>> we
>>>>>>>>>>>>>> decide to do it in a late time.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Stephen
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Thu, Jul 23, 2015 at 1:15 PM, Andrew Purtell <
>>>>>>>>>> apurtell@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks Jon.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> When I'm back in the office I'll check out master and
>> have
>>> a
>>>>>>>>> look
>>>>>>>>>>> into
>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>> locally repeatable test failures. Anyway in my opinion at
>>>> this
>>>>>>>>>>> point it
>>>>>>>>>>>>>>> would make the most sense for us to keep the MOB changes
>> in
>>>> on
>>>>>>>>>>> master
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> deal with any fallout in follow on issues. I think all
>> who
>>>>> voted
>>>>>>>>>> +1
>>>>>>>>>>> for
>>>>>>>>>>>>>>> this change were aware that large changes like this can
>>> have
>>>> a
>>>>>>>>>>>>>> temporarily
>>>>>>>>>>>>>>> destabilizing effect. As long as the MOB devs are around
>> to
>>>>> help
>>>>>>>>>>> clean
>>>>>>>>>>>>>> up,
>>>>>>>>>>>>>>> we should be good!
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 8:09 PM, Jonathan Hsieh <
>>>>>>>>> jon@cloudera.com
>>>>>>>>>>> 
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I had two clean full builds/unit test on my internal
>> setup
>>>> and
>>>>>>>>>> the
>>>>>>>>>>>>>> latest
>>>>>>>>>>>>>>>> build went back to ~4325 total tests and failures on
>>>> Procedure
>>>>>>>>>>> relate
>>>>>>>>>>>>>>> tests
>>>>>>>>>>>>>>>> cases.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I don't think mob is responsible for these failures.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Jon.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 4:32 PM, Jonathan Hsieh <
>>>>>>>>>> jon@cloudera.com
>>>>>>>>>>>> 
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Although the the precommit buiid passed, and the
>>>> compilation
>>>>>>>>>> and
>>>>>>>>>>>>> mob
>>>>>>>>>>>>>>>>> testing I ran after before the merge was commited
>> passed,
>>>> It
>>>>>>>>>>> looks
>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>> the first full build after the merge [1] failed.  It
>>> looked
>>>>>>>>>> like
>>>>>>>>>>>>>>>>> something hung along the way, and that most of the
>>> previous
>>>>>>>>>>> builds
>>>>>>>>>>>>>> had
>>>>>>>>>>>>>>>>> failed for various reasons. :(
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I kicked it off again have it do another try.  If it is
>>> mob
>>>>>>>>>>> related
>>>>>>>>>>>>>>> we'll
>>>>>>>>>>>>>>>>> take hunt it down and take care of it.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Jon.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> [1] https://builds.apache.org/job/HBase-TRUNK/6672/
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 1:16 PM, Jonathan Hsieh <
>>>>>>>>>>> jon@cloudera.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I've merged the code in to master.  Thanks for all the
>>>> hard
>>>>>>>>>>> work
>>>>>>>>>>>>>>>>>> Jingcheng and thanks to all who have been involved
>> with
>>>>>>>>>>> reviews,
>>>>>>>>>>>>>>>>>> discussion, and voting!
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Jon
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Wed, Jul 22, 2015 at 12:45 AM, Jingcheng Du <
>>>>>>>>>>>>>>> jingcheng.du@intel.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> The vote passes with 8 +1s and no -1. Thanks all for
>>>>>>>>>> guiding,
>>>>>>>>>>>>>> helping
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> voting!
>>>>>>>>>>>>>>>>>>> We will work on the merge activities and will let
>> guys
>>>>>>>>> know
>>>>>>>>>>> about
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> detailed plan for merge time.
>>>>>>>>>>>>>>>>>>> And thanks Jon for helping merge this branch to
>> trunk!
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>> Jingcheng
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> View this message in context:
>> http://apache-hbase.679495.n3.nabble.com/RESULT-VOTE-Merge-branch-hbase-11339-HBase-MOB-to-trunk-tp4073446.html
>>>>>>>>>>>>>>>>>>> Sent from the HBase Developer mailing list archive at
>>>>>>>>>>> Nabble.com.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> // Jonathan Hsieh (shay)
>>>>>>>>>>>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
>>>>>>>>>>>>>>>>>> // jon@cloudera.com // @jmhsieh
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> // Jonathan Hsieh (shay)
>>>>>>>>>>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
>>>>>>>>>>>>>>>>> // jon@cloudera.com // @jmhsieh
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> // Jonathan Hsieh (shay)
>>>>>>>>>>>>>>>> // HBase Tech Lead, Software Engineer, Cloudera
>>>>>>>>>>>>>>>> // jon@cloudera.com // @jmhsieh
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>  - Andy
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Problems worthy of attack prove their worth by hitting
>>> back.
>>>> -
>>>>>>>>>> Piet
>>>>>>>>>>>>> Hein
>>>>>>>>>>>>>>> (via Tom White)
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Sean
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> 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
>>>>>> // jon@cloudera.com // @jmhsieh
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 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
> // jon@cloudera.com // @jmhsieh

Re: MOB in branch-1? (Re: [RESULT][VOTE] Merge branch hbase-11339 HBase MOB to trunk)

[Stack <st...@duboce.net>]

On Mon, Feb 29, 2016 at 6:56 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:

> ...
> We've been working on trying to get at least one of them to present at
> hbasecon, but I'm not reviewing submissions this year and don't know if
> they made it or not.
>
> This did not happen. The use case is to surface in another forum soon
though....
St.Ack