Thanks Stack for the update. +1 on branching as soon as possible. For
getting aforementioned stability, we need to start rejecting patches/
features from 2.0.0. Branching early gives us the option of gradually
working towards that, but also does not block new development to happen on
master. I think the most important job for the RM is to say NO to
improvement jiras going into 2.0, if they have nothing to do with the
agreed upon goals of the release.
Enis
On Thu, Mar 30, 2017 at 5:07 PM, Stack <st...@duboce.net> wrote:
> Some notes on progress toward hbase2.
>
> Given that stability and performance are NOT emergent behaviors but rather
> projects unto themselves, my thought is that we commit all that we've
> agreed as core for hbase2 (see [1]), branch, and then work on stabilizing
> and perf rather than do stabilize, commit, and then branch. What this means
> in practice is that for features like Inmemory Compaction, we commit it
> defaulted 'on' ("BASIC" mode) which is what we want in hbase2. Should it
> prove problematic under test, we disable it before release.
>
> Are folks good w/ this mode? I ask because, in a few issues there are
> requests for proof that a master feature is 'stable' before commit. This is
> normally a healthy request only in master's case, it is hard to demonstrate
> stability given its current state.
>
> Other outstanding issues such as decisions about whether master hosts
> system tables only (by default), I'm thinking, we can work out post branch
> in alpha/betas before release.
>
> The awkward item is the long-pole Assignment Manager. This is an
> all-or-nothing affair. Here we are switching in a new Master core. While I
> think it fine that AMv2 is incomplete come branch time, those of us working
> on the new AM still need to demonstrate to you all that it basically
> viable.
>
> The point-of-no-return is commit of the patch in HBASE-14614. HBASE-14614
> (AMv2) is coming close to passing all unit tests. We'll spend some time
> running it on a cluster to make sure it fundamentally sound and will report
> back on our experience. There has been an ask for some dev doc and
> low-levels on how it works (in progress). Let satisfaction of these
> requests be blockers on commit. We'll put the HBASE-14614 commit up for a
> vote on dev list given its import.
>
> Branch will happen after HBASE-14614 goes in (or its rejection) with our
> first alpha soon after. Its looking like a week or two at least given how
> things have been going up to this.
>
> I intend to start in on hbase2 stability/perf projects after we branch.
>
> Interested in any thoughts you all might have on the above (Would also
> appreciate updates on state in [1] if you are a feature owner).
>
> Thanks,
> St.Ack
>
> 1. https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4
> z9iEu_ktczrlKHK8N4SZzs/edit#
>
>
>
> On Sat, Mar 11, 2017 at 5:32 PM, Josh Elser <els...@apache.org> wrote:
>
> >
> > Stack wrote:
> >
> >> On Tue, Mar 7, 2017 at 1:51 PM, Josh Elser<els...@apache.org> wrote:
> >>
> >> Thanks for pulling in the FS Quotas work, Stack. I'm trying to cross the
> >>> last T's and dot the last I's.
> >>>
> >>> The biggest thing I know I need to do still is to write a new chapter
> to
> >>> the book. After that, I'd start entertaining larger reviews/discussions
> >>> to
> >>> merge the feature into master. Anyone with free time (giggles) is more
> >>> than
> >>> welcome to start perusing :)
> >>>
> >>>
> >>> Out of interest, this could come in after 2.0 Josh? Any 2.0 specific
> >> needs
> >> to make this work?
> >>
> >> Meantime, updated the 2.0 doc 1.
> >>
> >> Thanks Josh,
> >> St.Ack
> >>
> >> 1.
> >> https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9i
> >> Eu_ktczrlKHK8N4SZzs/edit#
> >>
> >>
> > Nope, no need to block 2.0 on this one (given the other, related
> chatter).
> > Would be nice to get it in, but I completely understand if it slips :)
> >
> > Thanks for updating the doc for me!
> >
>
