hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Zhong <jzh...@hortonworks.com>
Subject Re: [VOTE] Merge branch HBASE-10070 to trunk
Date Sat, 07 Jun 2014 01:12:00 GMT

+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
View raw message