Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of enis.soz@gmail.com designates
 209.85.213.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOmV22v5PnJP3xPaETn7tpQGw6GrgR8zYdAVQocU6f=H+os3gw@mail.gmail.com>
References: 
 <CAPzbcGTJtGgmGUntVmxgM2+WLJUAHgsu5p65kWsyQxQF8OsrqQ@mail.gmail.com>
 <CFB7B30C.25F63%jzhong@hortonworks.com>
 <CAOmV22v5PnJP3xPaETn7tpQGw6GrgR8zYdAVQocU6f=H+os3gw@mail.gmail.com>
From: =?UTF-8?Q?Enis_S=C3=B6ztutar?= <enis.soz@gmail.com>
Date: Mon, 9 Jun 2014 11:01:25 -0700
Message-ID: 
 <CAMUu0w--QXAkVYHgrj8ZaCx7z+5=Hn3e3P57+-PA=adu7VY72g@mail.gmail.com>
Subject: Re: [VOTE] Merge branch HBASE-10070 to trunk
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=20cf30363ccf235a8504fb6b0167

--20cf30363ccf235a8504fb6b0167
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

BTW, I would really prefer to finish the merge before HBASE-11059. The
replica assignment has been working with the new patches and zk-based
assignment for many months.

Enis


On Fri, Jun 6, 2014 at 7:07 PM, Jimmy Xiang <jxiang@cloudera.com> wrote:

> First of all, I have not looked into the patches recently. I remember the=
re
> are some changes to the public interface. I was wondering if it is backwa=
rd
> compatible. Enis mentioned that it's rolling upgradable. Just want to
> confirm if it is backward compatible. For existing applications, do they
> need to recompile?
>
> Second, there should be some conflict with HBASE-11059 I am working on no=
w,
> which is almost finished. How should we resolve this issue? ZK-less regio=
n
> assignment doesn't know region replica yet.
>
> Thanks,
> Jimmy
>
>
>
>
> On Fri, Jun 6, 2014 at 6:12 PM, Jeffrey Zhong <jzhong@hortonworks.com>
> wrote:
>
> >
> > +1. It brings goodies such as region replica, cross region server
> > scan&get, anti-affinity of regions, and pave the way for sync region
> > replication.
> >
> > Thanks,
> > -Jeffrey
> >
> > On 6/6/14 2:42 PM, "Devaraj Das" <ddas@hortonworks.com> wrote:
> >
> > >+1
> > >
> > >On Fri, Jun 6, 2014 at 2:13 PM, Andrew Purtell <apurtell@apache.org>
> > >wrote:
> > >> +1, thanks Enis
> > >>
> > >>
> > >> On Fri, Jun 6, 2014 at 1:46 PM, Enis S=C3=B6ztutar <enis.soz@gmail.c=
om>
> > >>wrote:
> > >>
> > >>> Sorry, I was mostly out for HadoopSummit.
> > >>>
> > >>> Yes, the git flow would be very similar to what you propose:
> > >>>
> > >>>      $ git checkout HBASE-10070
> > >>>      $ git rebase --ignore-date master
> > >>>      (fixups, git add, git rebase --continue, etc, etc, etc)
> > >>>      $ git checkout master
> > >>>
> > >>>      $ git push origin HBASE-10070 HBASE-10070-rebase-date
> > >>>(optionally)
> > >>>      $ git merge HBASE-10070
> > >>>
> > >>> We can either go --ignore-date or not depending on what we want. If
> > >>>needed
> > >>> I am fine with pushing the rebased master branch for review to main
> > >>>repo
> > >>> before the merge to another branch. If not, I can just rebase the
> > >>>branch
> > >>> locally and merge + push to main repo.
> > >>>
> > >>> Creating final patches and attaching them to jira might be
> cumbersome.
> > >>>If
> > >>> we do the rebased-branch on repo, we might not need it. But if we
> need
> > >>>that
> > >>> for review, I can do it.
> > >>>
> > >>> Thanks,
> > >>> Enis
> > >>>
> > >>>
> > >>>
> > >>> On Wed, Jun 4, 2014 at 10:48 AM, Andrew Purtell <apurtell@apache.or=
g
> >
> > >>> wrote:
> > >>>
> > >>> > I realize this is a vote thread but I need a satisfactory answer =
to
> > >>>the
> > >>> > below inquiries before feeling comfortable casting a vote. Or
> perhaps
> > >>> that
> > >>> > means we need to cancel this vote and move back to discussion.
> > >>> >
> > >>> >
> > >>> > On Tue, Jun 3, 2014 at 11:17 AM, Andrew Purtell <
> apurtell@apache.org
> > >
> > >>> > wrote:
> > >>> >
> > >>> > > Also after the merge process is completed, do you plan to use g=
it
> > >>> > > format-patch to break out the per-JIRA changes into updated
> > >>>patches for
> > >>> > > those JIRAs representing in effect the final commit?
> > >>> > >
> > >>> > >
> > >>> > > On Tue, Jun 3, 2014 at 11:16 AM, Andrew Purtell
> > >>><apurtell@apache.org>
> > >>> > > wrote:
> > >>> > >
> > >>> > >>
> > >>> > >> On Mon, Jun 2, 2014 at 2:24 PM, Enis S=C3=B6ztutar <enis@apach=
e.org>
> > >>> wrote:
> > >>> > >>
> > >>> > >> This VOTE is for merging back the remaining changes in branch =
to
> > >>> trunk.
> > >>> > If
> > >>> > >>> passes, we will rebase the branch on top of current trunk, in
> > >>>which
> > >>> we
> > >>> > >>> will
> > >>> > >>> keep the commit-per-issue log history. After that we will do =
a
> > >>>git
> > >>> > merge
> > >>> > >>> for the branch keeping the history clean and not squashing th=
e
> > >>> > commits. I
> > >>> > >>> expect rebasing to be straightforward, however with some manu=
al
> > >>> > conflict
> > >>> > >>> resolution. After the merge we'll keep running the tests to
> make
> > >>>sure
> > >>> > >>> everything is ok.
> > >>> > >>>
> > >>> > >>
> > >>> > >> Just to clarify that would look something like this:
> > >>> > >>
> > >>> > >>      $ git checkout HBASE-10070
> > >>> > >>      $ git rebase --ignore-date master
> > >>> > >>      (fixups, git add, git rebase --continue, etc, etc, etc)
> > >>> > >>      $ git checkout master
> > >>> > >>      $ git merge HBASE-10070
> > >>> > >>
> > >>> > >> ?
> > >>> > >>
> > >>> > >> That sounds good to me, the final merge should be a fast forwa=
rd
> > >>> merge.
> > >>> > >>
> > >>> > >> Use of ' --ignore-date' could be mildly controversial. It's no=
t
> > >>> strictly
> > >>> > >> necessary because the commits for 10070 will appear grouped in
> > >>> history,
> > >>> > but
> > >>> > >> then dates on commits will be discontiguous in that section of
> > >>> history.
> > >>> > I
> > >>> > >> suggest using that option so the order of commits and dates so=
rt
> > >>>the
> > >>> > same
> > >>> > >> on master.
> > >>> > >>
> > >>> > >>
> > >>> > >> On Mon, Jun 2, 2014 at 2:24 PM, Enis S=C3=B6ztutar <enis@apach=
e.org>
> > >>> wrote:
> > >>> > >>
> > >>> > >>> Hi,
> > >>> > >>>
> > >>> > >>> Last week we started some discussion[4] for merging branch
> > >>> > hbase-10070[1]
> > >>> > >>> into trunk. It seems like the consensus there is to do the
> merge
> > >>> sooner
> > >>> > >>> rather than later.
> > >>> > >>>
> > >>> > >>>
> > >>> > >>> We had branched hbase-10070 in Feb out of trunk[5]. The branc=
h
> > >>> contains
> > >>> > >>> 55
> > >>> > >>> jiras committed[2]. Out of these 55, 15 has already been
> > >>>committed to
> > >>> > >>> trunk
> > >>> > >>> and backported to hbase-10070 branch[3].
> > >>> > >>>
> > >>> > >>> This VOTE is for merging back the remaining changes in branch
> to
> > >>> trunk.
> > >>> > >>> If
> > >>> > >>> passes, we will rebase the branch on top of current trunk, in
> > >>>which
> > >>> we
> > >>> > >>> will
> > >>> > >>> keep the commit-per-issue log history. After that we will do =
a
> > >>>git
> > >>> > merge
> > >>> > >>> for the branch keeping the history clean and not squashing th=
e
> > >>> > commits. I
> > >>> > >>> expect rebasing to be straightforward, however with some manu=
al
> > >>> > conflict
> > >>> > >>> resolution. After the merge we'll keep running the tests to
> make
> > >>>sure
> > >>> > >>> everything is ok.
> > >>> > >>>
> > >>> > >>> An overview of the changes, and the status of the work can be
> > >>>found
> > >>> > under
> > >>> > >>> [4], [6] and [7].In summary, with the code in branch, you can
> > >>>create
> > >>> > >>> tables
> > >>> > >>> with region replicas, do gets / multi gets and scans using
> > >>>TIMELINE
> > >>> > >>> consistency with high availability. Region replicas
> periodically
> > >>>scan
> > >>> > the
> > >>> > >>> files of the primary and pick up flushed / committed files. T=
he
> > >>>RPC
> > >>> > >>> paths /
> > >>> > >>> assignment, balancing etc are pretty stable. However some mor=
e
> > >>> > >>> performance
> > >>> > >>> analysis and tuning is needed. Phase 2 work is being worked o=
n
> > >>>under
> > >>> > >>> HBASE-11183, and we have some working prototype for
> > >>>async-replicating
> > >>> > and
> > >>> > >>> region splits. However, we believe even without those feature=
s,
> > >>>this
> > >>> > work
> > >>> > >>> is useable (especially for read-only/bulk load tables) , and
> can
> > >>>be
> > >>> > >>> released as an experimental feature in 1.0.
> > >>> > >>>
> > >>> > >>> Please indicate your choice:
> > >>> > >>>
> > >>> > >>> [ ] +1 on yes, merge branch hbase-10070 to trunk.
> > >>> > >>> [ ] 0 on don't care
> > >>> > >>> [ ] -1 don't merge, because ...
> > >>> > >>>
> > >>> > >>> I'll keep the vote running for 7 days, and close it Mon 9th o=
f
> > >>>June,
> > >>> > PDT.
> > >>> > >>>
> > >>> > >>> Here is my official +1.
> > >>> > >>>
> > >>> > >>> Thanks,
> > >>> > >>> Enis
> > >>> > >>>
> > >>> > >>> [1]
> > >>> > >>>
> > >>> > >>>
> > >>> >
> > >>>
> > >>>
> > https://git-wip-us.apache.org/repos/asf?p=3Dhbase.git;a=3Dlog;h=3Drefs/=
heads/h
> > >>>base-10070
> > >>> > >>> [2]
> > >>> > >>>
> > >>> > >>>
> > >>> >
> > >>>
> > >>>
> > https://issues.apache.org/jira/browse/HBASE-11214?jql=3DfixVersion%20%3=
D%2
> >
> >>>0hbase-10070%20AND%20project%20%3D%20HBASE%20AND%20status%20%3D%20reso=
lv
> > >>>ed
> > >>> > >>> [3]
> > >>> > >>>
> > >>> > >>>
> > >>> >
> > >>>
> > >>>
> > https://issues.apache.org/jira/browse/HBASE-10792?jql=3DfixVersion%20%3=
D%2
> >
> >>>0hbase-10070%20and%20fixversion%20%3D%200.99.0%20AND%20project%20%3D%2=
0H
> > >>>BASE%20AND%20status%20%3D%20resolved
> > >>> > >>> [4]
> > >>>https://www.mail-archive.com/dev@hbase.apache.org/msg25795.html
> > >>> > >>> [5]
> > >>> > >>>
> > >>> > >>>
> > >>> >
> > >>>
> > >>>
> > https://github.com/apache/hbase/commit/e22c7efeac02efde3451a0c9ff9bdcd2=
7
> > >>>25576d0
> > >>> > >>> [6]
> > >>> > >>>
> > >>> > >>>
> > >>> >
> > >>>
> > >>>
> > http://www.slideshare.net/enissoz/hbase-high-availability-for-reads-wit=
h
> > >>>-time
> > >>> > >>> [7] https://issues.apache.org/jira/browse/HBASE-10070
> > >>> > >>>
> > >>> > >>
> > >>> > >>
> > >>> > >>
> > >>> > >> --
> > >>> > >> 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)
> > >>> > >
> > >>> >
> > >>> >
> > >>> >
> > >>> > --
> > >>> > Best regards,
> > >>> >
> > >>> >    - Andy
> > >>> >
> > >>> > Problems worthy of attack prove their worth by hitting back. - Pi=
et
> > >>>Hein
> > >>> > (via Tom White)
> > >>> >
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Best regards,
> > >>
> > >>    - Andy
> > >>
> > >> Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > >> (via Tom White)
> > >
> > >--
> > >CONFIDENTIALITY NOTICE
> > >NOTICE: This message is intended for the use of the individual or enti=
ty
> > >to
> > >which it is addressed and may contain information that is confidential=
,
> > >privileged and exempt from disclosure under applicable law. If the
> reader
> > >of this message is not the intended recipient, you are hereby notified
> > >that
> > >any printing, copying, dissemination, distribution, disclosure or
> > >forwarding of this communication is strictly prohibited. If you have
> > >received this communication in error, please contact the sender
> > >immediately
> > >and delete it from your system. Thank You.
> >
> >
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entit=
y
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the read=
er
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>

--20cf30363ccf235a8504fb6b0167--