Thank you all for the vote! Let me follow up on HBASE-25284. Best Regards, Huaxiang
On Thu, Nov 19, 2020 at 9:05 AM Andrew Purtell <apurt...@apache.org> wrote: > Thank you for providing actionable feedback Duo. > > I also thank you personally for adjusting your vote, as it unblocks > everyone here. > > > > On Thu, Nov 19, 2020 at 12:53 AM 张铎(Duo Zhang) <palomino...@gmail.com> > wrote: > > > Oh, just noticed that the design doc has been committed to master and > > branch-2 directly. I'm not sure if this is the correct way but since it > is > > already like this, let's just fix it on master and branch-2. > > > > Then there is no blocker on the merge of the feature branch any more. > > Change my vote to +1. > > > > I've already reopened HBASE-25284 to mention what to change in the design > > doc. I do not have the permission to modify the design doc, as it has > been > > messed up by others so the modification permission for most people have > > been removed to avoid spamming. > > > > Thanks. > > > > 张铎(Duo Zhang) <palomino...@gmail.com> 于2020年11月19日周四 下午2:24写道： > > > > > It is not only about satisfying me, as a community we need to make sure > > > that we are all on the same page before actually moving forward, or at > > > least we should know what is the actual pivot point. > > > > > > I did not pose a quiz for you, there are just 4 technical questions. > You > > > strongly disagree that the test proposed by me is for HBASE-18070 and > > keep > > > saying that the problem can be solved by 'HedgeRead', then I think it > is > > > valid for me to ask what do you think about what problems can be solved > > by > > > the 'HedgeRead' and what can be solved by HBASE-18070? If this is not > > well > > > understood by all, later someone may remove this benefit of HBASE-18070 > > and > > > you will approve it and make HBASE-18070 useless. > > > > > > That's why I proposed we add this explicitly to the design doc, to at > > > least let all the developers know this. > > > > > > Thanks. > > > > > > Stack <st...@duboce.net> 于2020年11月19日周四 下午1:43写道： > > > > > >> On Wed, Nov 18, 2020 at 7:03 PM 张铎(Duo Zhang) <palomino...@gmail.com> > > >> wrote: > > >> > > >> > OK, let me explain the technical part. > > >> > > > >> > What I proposed in the test is to verify that we could distribute > the > > >> load > > >> > across all the meta so we could benefit if the main replica is > f**ked > > >> up. > > >> > But then stack said this has already been solved by the old read > > >> replicas > > >> > feature. Maybe in the first place I did not speak clearly enough but > > >> later > > >> > I spoke clearly that I was talking about the distribution of the > load > > >> for > > >> > the meta table, but stack still does not agree and insist that I was > > >> > talking about hedge read. > > >> > > > >> > For me, I do not think hedge read can fully solve the 'primary > region > > >> > f**ked up' problem. Of course we will go to secondary replicas if > the > > >> > primary can not respond, but it usually means the primary replica is > > >> not in > > >> > a good state. The region server in a cluster will not go to the > > >> secondary > > >> > replicas to read right? If the primary replica is unavailable, a > > >> failure of > > >> > meta read could crash a region server. And it could also affect > write > > >> > requests to meta, which could cause serious problems on master too. > > I've > > >> > implemented a lot of procedures on 2.x, usually we will just abort > > >> master > > >> > if there is a failure when accessing meta. This means, in the old > > hedge > > >> > read mode, if the primary replica has been f**ked up, the cluster > will > > >> not > > >> > be in a good state, finally the test will fail. > > >> > > > >> > And I think HBASE-18070 can solve the problem. But the main > developer > > >> seems > > >> > to have a different opinion on this. So I asked him what are his > > >> opinion on > > >> > the 4 questions on jira, but so far I do not get a response from him > > >> yet. > > >> > > > >> > Why I do not want to write the above explanation before is that, > if I > > >> > throw this out, the main developer could easily say that 'yes I > agree > > >> with > > >> > you, this is my point', to simply let the vote process to pass. But > > the > > >> > actual issue will be covered as he never speaks out his own opinion, > > and > > >> > may cause trouble in the future. > > >> > > > >> > > > >> The veto seems to pivot on whether I, a co-author, knows what the > > feature > > >> I > > >> co-designed and co-wrote does. He has posed a quiz for me to fill out > > that > > >> I am to answer to his satisfaction even though my co-author has > already > > >> answered his questionnaire. > > >> > > >> I suggest that the vote be on the feature rather than my responses to > a > > >> questionnaire of Duo's making. > > >> > > >> S > > >> > > >> > > >> > > >> > Thanks. > > >> > > > >> > Andrew Purtell <apurt...@apache.org> 于2020年11月19日周四 上午10:23写道： > > >> > > > >> > > That's not how a technical veto works. The burden to explain how > the > > >> > > contributors can fix the reason for the veto is on you. You need > to > > >> give > > >> > a > > >> > > list of action items. "Fundamental of the issue" is just your > > opinion. > > >> > > Nobody here is a Boss. Contributors don't have to satisfy your > > >> (nebulous) > > >> > > requirements, you have to successfully argue your point. > > >> > > > > >> > > On Wed, Nov 18, 2020 at 6:10 PM 张铎(Duo Zhang) < > > palomino...@gmail.com> > > >> > > wrote: > > >> > > > > >> > > > Thank you Andrew. I think my last comment clearly describe the > two > > >> > > > questions given by you. > > >> > > > > > >> > > > A clear and compelling reason why the proposed change is harmful > > or > > >> > > > > undesirable > > >> > > > > > >> > > > > > >> > > > It is about the fundamental of this issue. Due to the back and > > >> forth on > > >> > > how > > >> > > > a test could used to verify the feature, I'm concerned whether > the > > >> main > > >> > > > developer has the same opinion on the problems we want to solve > > for > > >> > this > > >> > > > issue. This is a very critical problem, as if we can not even > > reach > > >> an > > >> > > > agreement on what to solve, I do not think we should allow the > > >> merge of > > >> > > the > > >> > > > branch. > > >> > > > > > >> > > > One or more clear and specific action items which would allow > the > > >> > > > > contributors to cure the reason for the veto > > >> > > > > > >> > > > > > >> > > > This is also very very clear even before we started this vote > > >> thread? I > > >> > > > asked 4 technical questions and waited for an answer, but seems > > the > > >> > main > > >> > > > developer refused to answer the questions and let me to read the > > >> design > > >> > > doc > > >> > > > of all the related issues. The design doc is not all written by > > him > > >> so > > >> > I > > >> > > do > > >> > > > not think this is a constructive suggestion to solve the > concerns > > >> here. > > >> > > > > > >> > > > Thanks. > > >> > > > > > >> > > > Sean Busbey <bus...@apache.org> 于2020年11月19日周四 上午4:27写道： > > >> > > > > > >> > > > > Pause a moment Huaxiang and give some time for the PMC to talk > > in > > >> > > > > private a bit. > > >> > > > > > > >> > > > > On Wed, Nov 18, 2020 at 12:44 PM Huaxiang Sun < > > >> huaxiang...@gmail.com > > >> > > > > >> > > > > wrote: > > >> > > > > > > > >> > > > > > This vote passed 24 hours deadline. We got 5 +1s and 1 -1. > > What > > >> is > > >> > > the > > >> > > > > path > > >> > > > > > to move forward? Anything we (as feature developers) can do > to > > >> > revert > > >> > > > the > > >> > > > > > -1? > > >> > > > > > As it blocks 2.4 release, I think we need a decision asap. > > >> > > > > > > > >> > > > > > Thanks, > > >> > > > > > Huaxiang > > >> > > > > > > > >> > > > > > On Wed, Nov 18, 2020 at 8:46 AM Andrew Purtell < > > >> > > > andrew.purt...@gmail.com > > >> > > > > > > > >> > > > > > wrote: > > >> > > > > > > > >> > > > > > > Let me refer you to the Foundation guidance on voting: > > >> > > > > > > https://www.apache.org/foundation/voting.html , and > > >> specifically > > >> > > the > > >> > > > > > > section on vetos: > > >> > > > > > > > > >> > > > > > > A code-modification proposal may be stopped dead in its > > tracks > > >> > by a > > >> > > > -1 > > >> > > > > vote > > >> > > > > > > by a qualified voter. This constitutes a veto, and it > cannot > > >> be > > >> > > > > overruled > > >> > > > > > > nor overridden by anyone. Vetos stand until and unless > > >> withdrawn > > >> > by > > >> > > > > their > > >> > > > > > > casters. To prevent vetos from being used capriciously, > they > > >> must > > >> > > be > > >> > > > > > > accompanied by a technical justification showing why the > > >> change > > >> > is > > >> > > > bad > > >> > > > > > > (opens a security exposure, negatively affects > performance, > > >> > *etc.* > > >> > > > ). A > > >> > > > > > > veto without a justification is invalid and has no weight. > > >> > > > > > > The Merriam-Webster dictionary defines 'capricious' as a > > >> sudden, > > >> > > > > > > unpredictable, and impulsive act > > >> > > > > > > <https://www.merriam-webster.com/dictionary/caprice>. To > > >> guard > > >> > > > against > > >> > > > > > > this > > >> > > > > > > kind of chaos in voting on technical matters, a technical > > veto > > >> > must > > >> > > > > have a > > >> > > > > > > clear and compelling reason. Neither on the earlier thread > > nor > > >> > the > > >> > > > > JIRA is > > >> > > > > > > a clear and compelling concern about the to-be-merged > > feature, > > >> > > > clearly > > >> > > > > > > communicated. A technical veto must also be accompanied > with > > >> > clear > > >> > > > and > > >> > > > > > > actionable feedback for the contributors, which in my view > > is > > >> > also > > >> > > > > absent. > > >> > > > > > > A veto because one participant in the discussion does not > > >> > > understand > > >> > > > > the > > >> > > > > > > change or its motivation, or simply expresses an opinion > > that > > >> it > > >> > is > > >> > > > not > > >> > > > > > > ideal and/or needed, is not a valid reason for a technical > > >> veto > > >> > and > > >> > > > > > > certainly does not provide actionable guidance for curing > > the > > >> > veto. > > >> > > > The > > >> > > > > > > burden of the technical veto is not on the contributors to > > >> > convince > > >> > > > the > > >> > > > > > > vetoing voter; the burden of proof is on the vetoing > voter. > > >> > > > > > > > > >> > > > > > > In my view, as things stand the veto here is not yet valid > > but > > >> > can > > >> > > be > > >> > > > > made > > >> > > > > > > valid by offering the following: > > >> > > > > > > > > >> > > > > > > - A clear and compelling reason why the proposed change > > is > > >> > > harmful > > >> > > > > or > > >> > > > > > > undesirable > > >> > > > > > > - One or more clear and specific action items which > would > > >> > allow > > >> > > > the > > >> > > > > > > contributors to cure the reason for the veto > > >> > > > > > > > > >> > > > > > > Otherwise, the veto should be given no weight. > > >> > > > > > > > > >> > > > > > > To explain further my reason for concern, I have reviewed > > the > > >> > > > > discussion > > >> > > > > > > thread and JIRA in question here and the reason given for > > veto > > >> > > seems > > >> > > > > to me > > >> > > > > > > a relatively minor technical matter that can easily be > > cured, > > >> to > > >> > > the > > >> > > > > extent > > >> > > > > > > it has been described (the reason is somewhat unclear), > > with a > > >> > > simple > > >> > > > > and > > >> > > > > > > straightforward follow up. There is no blocking > functional, > > >> > > > > performance, > > >> > > > > > > regression, or security related reason. However we have a > > >> repeat > > >> > > of a > > >> > > > > > > pattern of disagreement related to a personal problem > > between > > >> two > > >> > > > > > > participants in the discussion, including the vetoing > voter. > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > On Tue, Nov 17, 2020 at 8:03 PM Andrew Purtell < > > >> > > > > andrew.purt...@gmail.com> > > >> > > > > > > wrote: > > >> > > > > > > > > >> > > > > > > > I am concerned this is not a valid technical veto and > it’s > > >> time > > >> > > for > > >> > > > > the > > >> > > > > > > > PMC to take a more active role. This is poison to > > >> collaboration > > >> > > and > > >> > > > > it is > > >> > > > > > > > affecting multiple people. > > >> > > > > > > > > > >> > > > > > > > > On Nov 17, 2020, at 5:43 PM, 张铎 < > palomino...@gmail.com> > > >> > wrote: > > >> > > > > > > > > > > >> > > > > > > > > Hi, bring my -1 from the HEAD-UP thread, this is a > > veto. > > >> > > > > > > > > > > >> > > > > > > > > My concerns have not been fully resolved. Let's work > it > > >> out > > >> > on > > >> > > > > jira. > > >> > > > > > > > > > > >> > > > > > > > > Thanks. > > >> > > > > > > > > > > >> > > > > > > > > clara xiong <clarax98...@gmail.com> 于2020年11月18日周三 > > >> 上午1:51写道： > > >> > > > > > > > > > > >> > > > > > > > >> +1 > > >> > > > > > > > >> > > >> > > > > > > > >>> On Tue, Nov 17, 2020 at 9:49 AM Huaxiang Sun < > > >> > > > > huaxiang...@gmail.com> > > >> > > > > > > > >>> wrote: > > >> > > > > > > > >>> > > >> > > > > > > > >>> +1 > > >> > > > > > > > >>> > > >> > > > > > > > >>> On Tue, Nov 17, 2020 at 9:21 AM Bharath > Vissapragada < > > >> > > > > > > > >> bhara...@apache.org> > > >> > > > > > > > >>> wrote: > > >> > > > > > > > >>> > > >> > > > > > > > >>>> +1. Reviewed the design doc and the consolidated > > patch, > > >> > > great > > >> > > > > > > > >>> improvement, > > >> > > > > > > > >>>> thanks for putting this together. > > >> > > > > > > > >>>> > > >> > > > > > > > >>>> On Tue, Nov 17, 2020 at 9:09 AM Stack < > > >> st...@duboce.net> > > >> > > > wrote: > > >> > > > > > > > >>>> > > >> > > > > > > > >>>>> +1 > > >> > > > > > > > >>>>> S > > >> > > > > > > > >>>>> > > >> > > > > > > > >>>>> On Tue, Nov 17, 2020 at 8:43 AM Stack < > > >> st...@duboce.net> > > >> > > > > wrote: > > >> > > > > > > > >>>>> > > >> > > > > > > > >>>>>> Please VOTE on whether to merge HBASE-18070 > feature > > >> > branch > > >> > > > to > > >> > > > > > > > >> master > > >> > > > > > > > >>>> (and > > >> > > > > > > > >>>>>> HBASE-18070.branch-2 to branch-2). The VOTE runs > > for > > >> 24 > > >> > > > > hours. The > > >> > > > > > > > >>>>> majority > > >> > > > > > > > >>>>>> prevails (+ or -). > > >> > > > > > > > >>>>>> > > >> > > > > > > > >>>>>> Quoting the design lead-in: > > >> > > > > > > > >>>>>> > > >> > > > > > > > >>>>>> Read Replicas on the hbase:meta Table currently > > only > > >> > does > > >> > > > > > > primitive > > >> > > > > > > > >>>> read > > >> > > > > > > > >>>>>> of the primary’s hfiles refreshing every > > >> (configurable) > > >> > N > > >> > > > > seconds. > > >> > > > > > > > >>> This > > >> > > > > > > > >>>>>> issue is about making it so we can do the Async > WAL > > >> > > > > Replication > > >> > > > > > > > >>>>>> < > > >> > http://hbase.apache.org/book.html#_asnyc_wal_replication > > >> > > > > > >> > > > > > > > >> ability, > > >> > > > > > > > >>>>>> currently only available for user-space Tables, > > >> against > > >> > > the > > >> > > > > > > > >>> hbase:meta > > >> > > > > > > > >>>>>> system Tables too; i.e. the primary replica > pushes > > >> edits > > >> > > to > > >> > > > > its > > >> > > > > > > > >>>> Replicas > > >> > > > > > > > >>>>> so > > >> > > > > > > > >>>>>> they run much closer to the primaries’ state. If > > >> clients > > >> > > > > could be > > >> > > > > > > > >>>>> satisfied > > >> > > > > > > > >>>>>> reading from Replicas, then we could have > improved > > >> > > > hbase:meta > > >> > > > > > > > >> uptimes > > >> > > > > > > > >>>> but > > >> > > > > > > > >>>>>> also, we can distribute load off of the primary > and > > >> > > > alleviate > > >> > > > > > > > >>>> hbase:meta > > >> > > > > > > > >>>>>> Table (read) hotspotting. > > >> > > > > > > > >>>>>> > > >> > > > > > > > >>>>>> Each PR that comprises the feature branch has > been > > >> > > reviewed > > >> > > > > before > > >> > > > > > > > >>>>> commit. > > >> > > > > > > > >>>>>> > > >> > > > > > > > >>>>>> * For the design, see [2]. > > >> > > > > > > > >>>>>> * For an amalgamated PR of the 5 or 6 reviewed > PRs > > >> that > > >> > > > > comprise > > >> > > > > > > > >>> this > > >> > > > > > > > >>>>>> feature, see [3]. > > >> > > > > > > > >>>>>> * For a PE report that compared performance > before > > >> and > > >> > > > after, > > >> > > > > see > > >> > > > > > > > >>>>>> HBASE-25127 (no regression). > > >> > > > > > > > >>>>>> * A report on ITBLL runs is pending to be > attached > > to > > >> > > > > HBASE-18070 > > >> > > > > > > > >>> but > > >> > > > > > > > >>>>>> runs so far show no regression with the feature > > >> enabled > > >> > > > (ITBLL > > >> > > > > > > runs > > >> > > > > > > > >>>> were > > >> > > > > > > > >>>>>> done against a backport of this feature to > branch-2 > > >> as > > >> > the > > >> > > > > ITBLL > > >> > > > > > > > >>> state > > >> > > > > > > > >>>> of > > >> > > > > > > > >>>>>> master is currently an unknown). > > >> > > > > > > > >>>>>> > > >> > > > > > > > >>>>>> Testing continues mainly looking for further > > >> improvement > > >> > > and > > >> > > > > to > > >> > > > > > > > >>> better > > >> > > > > > > > >>>>>> understand this feature in operation. > Documentation > > >> is > > >> > > > > included. > > >> > > > > > > > >>> There > > >> > > > > > > > >>>>> are > > >> > > > > > > > >>>>>> some follow-ons that have been identified but > these > > >> can > > >> > > land > > >> > > > > > > later. > > >> > > > > > > > >>>>>> > > >> > > > > > > > >>>>>> Thanks and thanks to all who contributed to this > > >> > feature; > > >> > > > the > > >> > > > > > > > >>> reviewers > > >> > > > > > > > >>>>>> and the testers in particular. > > >> > > > > > > > >>>>>> > > >> > > > > > > > >>>>>> S > > >> > > > > > > > >>>>>> > > >> > > > > > > > >>>>>> 1. > > >> > > http://hbase.apache.org/book.html#_asnyc_wal_replication > > >> > > > > > > > >>>>>> 2. > > >> > > > > > > > >>>>>> > > >> > > > > > > > >>>>> > > >> > > > > > > > >>>> > > >> > > > > > > > >>> > > >> > > > > > > > >> > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > https://docs.google.com/document/d/1jJWVc-idHhhgL4KDRpjMsQJKCl_NRaCLGiH3Wqwd3O8/edit# > > >> > > > > > > > >>>>>> This patch is currently missing HBASE-25280, a > bug > > >> found > > >> > > in > > >> > > > > > > > >> testing. > > >> > > > > > > > >>>>>> 3. https://github.com/apache/hbase/pull/2643 > > >> > > > > > > > >>>>>> > > >> > > > > > > > >>>>> > > >> > > > > > > > >>>> > > >> > > > > > > > >>> > > >> > > > > > > > >> > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > -- > > >> > > > > > > Best regards, > > >> > > > > > > Andrew > > >> > > > > > > > > >> > > > > > > Words like orphans lost among the crosstalk, meaning torn > > from > > >> > > > truth's > > >> > > > > > > decrepit hands > > >> > > > > > > - A23, Crosstalk > > >> > > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > -- > > >> > > Best regards, > > >> > > Andrew > > >> > > > > >> > > Words like orphans lost among the crosstalk, meaning torn from > > truth's > > >> > > decrepit hands > > >> > > - A23, Crosstalk > > >> > > > > >> > > > >> > > > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk >
