+1 on branching (yay!)
I have EC2 resources for running ITBLL etc.
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!
> >
>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
