hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <enis....@gmail.com>
Subject Re: [VOTE] Merge branch HBASE-10070 to trunk
Date Mon, 09 Jun 2014 18:01:25 GMT
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 there
> are some changes to the public interface. I was wondering if it is backward
> 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 now,
> which is almost finished. How should we resolve this issue? ZK-less region
> 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öztutar <enis.soz@gmail.com>
> > >>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.org
> >
> > >>> 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 git
> > >>> > > 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öztutar <enis@apache.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 the
> > >>> > commits. I
> > >>> > >>> expect rebasing to be straightforward, however with
some manual
> > >>> > 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
forward
> > >>> merge.
> > >>> > >>
> > >>> > >> Use of ' --ignore-date' could be mildly controversial.
It's not
> > >>> 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 sort
> > >>>the
> > >>> > same
> > >>> > >> on master.
> > >>> > >>
> > >>> > >>
> > >>> > >> On Mon, Jun 2, 2014 at 2:24 PM, Enis Söztutar <enis@apache.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 branch
> > >>> 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 the
> > >>> > commits. I
> > >>> > >>> expect rebasing to be straightforward, however with
some manual
> > >>> > 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. The
> > >>>RPC
> > >>> > >>> paths /
> > >>> > >>> assignment, balancing etc are pretty stable. However
some more
> > >>> > >>> performance
> > >>> > >>> analysis and tuning is needed. Phase 2 work is being
worked on
> > >>>under
> > >>> > >>> HBASE-11183, and we have some working prototype for
> > >>>async-replicating
> > >>> > and
> > >>> > >>> region splits. However, we believe even without those
features,
> > >>>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 of
> > >>>June,
> > >>> > PDT.
> > >>> > >>>
> > >>> > >>> Here is my official +1.
> > >>> > >>>
> > >>> > >>> Thanks,
> > >>> > >>> Enis
> > >>> > >>>
> > >>> > >>> [1]
> > >>> > >>>
> > >>> > >>>
> > >>> >
> > >>>
> > >>>
> > https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=log;h=refs/heads/h
> > >>>base-10070
> > >>> > >>> [2]
> > >>> > >>>
> > >>> > >>>
> > >>> >
> > >>>
> > >>>
> > https://issues.apache.org/jira/browse/HBASE-11214?jql=fixVersion%20%3D%2
> >
> >>>0hbase-10070%20AND%20project%20%3D%20HBASE%20AND%20status%20%3D%20resolv
> > >>>ed
> > >>> > >>> [3]
> > >>> > >>>
> > >>> > >>>
> > >>> >
> > >>>
> > >>>
> > https://issues.apache.org/jira/browse/HBASE-10792?jql=fixVersion%20%3D%2
> >
> >>>0hbase-10070%20and%20fixversion%20%3D%200.99.0%20AND%20project%20%3D%20H
> > >>>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/e22c7efeac02efde3451a0c9ff9bdcd27
> > >>>25576d0
> > >>> > >>> [6]
> > >>> > >>>
> > >>> > >>>
> > >>> >
> > >>>
> > >>>
> > http://www.slideshare.net/enissoz/hbase-high-availability-for-reads-with
> > >>>-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. -
Piet
> > >>>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 entity
> > >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 entity
> 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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message