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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > 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" <[email protected]> wrote: > > > > > > > > >+1 > > > > > > > > > >On Fri, Jun 6, 2014 at 2:13 PM, Andrew Purtell <[email protected] > > > > > > >wrote: > > > > >> +1, thanks Enis > > > > >> > > > > >> > > > > >> On Fri, Jun 6, 2014 at 1:46 PM, Enis Söztutar <[email protected] > > > > > > >>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 < > > [email protected] > > > > > > > > >>> 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 < > > > [email protected] > > > > > > > > > >>> > 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 > > > > >>><[email protected]> > > > > >>> > > wrote: > > > > >>> > > > > > > >>> > >> > > > > >>> > >> On Mon, Jun 2, 2014 at 2:24 PM, Enis Söztutar < > > [email protected]> > > > > >>> 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 < > > [email protected]> > > > > >>> 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/[email protected]/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. > > > > > > > > > >
