hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.org>
Subject [RESULT] [VOTE] Merge branch HBASE-10070 to trunk
Date Tue, 10 Jun 2014 20:09:51 GMT
Hi,

This VOTE is now closed, passing with 5 +1's from: Enis, Andrew, Devaraj,
Jeffrey and Nicolas.

We can continue the discussion on how to execute the merge and whether we
will need more reviews on the final version of the patches. I'll update
this thread when I have the rebase or merge patches close to being ready.

Please feel free to bring up any concerns if any.

Enis


On Mon, Jun 9, 2014 at 11:07 AM, Jimmy Xiang <jxiang@cloudera.com> wrote:

> I will set zk-less assignment off by default so that your change is not
> affected. But zk-less assignment won't support replica, at least for now.
>
>
> On Mon, Jun 9, 2014 at 11:01 AM, Enis Söztutar <enis.soz@gmail.com> wrote:
>
> > 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