[jira] [Resolved] (HBASE-25313) [branch-1] Fix the broken pre-commit

[Viraj Jasani (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-25313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Viraj Jasani resolved HBASE-25313.
--
Hadoop Flags: Reviewed
  Resolution: Fixed

> [branch-1] Fix the broken pre-commit
> 
>
> Key: HBASE-25313
> URL: https://issues.apache.org/jira/browse/HBASE-25313
> Project: HBase
>  Issue Type: Bug
>  Components: jenkins
>Reporter: Reid Chan
>Assignee: Reid Chan
>Priority: Major
> Fix For: 1.7.0
>
>
> {code}
> Archive JUnit-formatted test results
> [2020-11-20T02:58:50.501Z] Recording test results
> [2020-11-20T02:58:50.641Z] No test report files were found. Configuration 
> error?
> {code}
> branch-1's pre-commit keeps failing with error above, we need to fix it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-25317) [github]rename HBASE-18070-ROOT_hbase:meta_Region_Replicas.pdf

[Bo Cui (Jira)]

Bo Cui created HBASE-25317:
--

 Summary: [github]rename 
HBASE-18070-ROOT_hbase:meta_Region_Replicas.pdf
 Key: HBASE-25317
 URL: https://issues.apache.org/jira/browse/HBASE-25317
 Project: HBase
  Issue Type: Bug
Reporter: Bo Cui
 Attachments: image-2020-11-21-14-48-23-794.png

use git pull to obtain an exception

!image-2020-11-21-14-48-23-794.png!

workaround:git config core.protectNTFS false

[~stack] i think we can ranme filename...

.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-25316) Release a hbase-thirdparty with hbase-shaded-miscellaneous suitable for branch-1

[Andrew Kyle Purtell (Jira)]

Andrew Kyle Purtell created HBASE-25316:
---

 Summary: Release a hbase-thirdparty with 
hbase-shaded-miscellaneous suitable for branch-1
 Key: HBASE-25316
 URL: https://issues.apache.org/jira/browse/HBASE-25316
 Project: HBase
  Issue Type: Task
Affects Versions: 1.7.0
 Environment: R
Reporter: Andrew Kyle Purtell
Assignee: Andrew Kyle Purtell






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Heads up: 2.4.0RC0

[Andrew Purtell]

HBASE-18070 has been merged.

The 2.4.0 RC0 cuts Monday.

Thank you everyone in advance for your patience. Unfortunately due to the
Thanksgiving holiday the work week will be short, but I hope there will be
sufficient +1 votes (and no significant issues, or -1 votes) by the end of
the month to support a release at that time -- 30/11/2020.


On Mon, Nov 16, 2020 at 8:51 AM Andrew Purtell  wrote:

> Update.
>
> On the thread "HEAD-UP: Merging HBASE-18070 "Enable memstore replication
> for meta replica" to master and then back to branch-2" I was asked to
> wait so the participants in that discussion can resolve a misunderstanding.
>
> I hope and encourage a timely resolution to the conflict so we can all be
> unblocked, thank you in advance.
>
>
> On Mon, Nov 16, 2020 at 7:45 AM Andrew Purtell 
> wrote:
>
>> Spinning the bits today. Pre-flight checks will take about 24 hours. Any
>> last minute work has that much time to make the train.
>>
>>
>> --
>> 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

[jira] [Resolved] (HBASE-25126) Add load balance logic in hbase-client to distribute read load over meta replica regions.

[Michael Stack (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-25126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Stack resolved HBASE-25126.
---
Hadoop Flags: Reviewed
Release Note: See parent issue, HBASE-18070, release notes for how to 
enable.
  Resolution: Fixed

Resolving [~huaxiangsun]  I see this patch in master and 2.4 so presume it is 
done. Reopening if I have it wrong.

> Add load balance logic in hbase-client to distribute read load over meta 
> replica regions.
> -
>
> Key: HBASE-25126
> URL: https://issues.apache.org/jira/browse/HBASE-25126
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 3.0.0-alpha-1
>Reporter: Huaxiang Sun
>Assignee: Huaxiang Sun
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.4.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Clarifying guidance around Signed-off-by in commit messages

[Stack]

Thanks for taking the time to do a write up Josh.

Looks good to me.

When Sean started in on the 'Signed-off-by:' I didn't get it (especially
after reading the git definition). Sean then set me straight explaining our
use is a bit of a perversion of the original. I notice his definition is
not in the refguide. Suggest a sentence preamble definition of
'Signed-off-by:' and that we intentionally are different from the
definition cited by Bharath.

I like the Bharath idea on 'Reviewed-by' too. We can talk up 'Reviewed-by'
credits as a way to earn standing in the community, of how they are given
weight evaluating whether to make a candidate a committer/PMC'er or not.

S

On Fri, Nov 20, 2020 at 3:13 PM Josh Elser  wrote:

> On 11/20/20 1:07 PM, Bharath Vissapragada wrote:
> >> * All individuals mentioned in a sign-off*must*  be capable of giving a
> >> binding vote (i.e. they are an HBase committer)
> >>
> > It appears that the original intent
> > <
> http://web.archive.org/web/20160507011446/http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
> >of
> > this sign-off feature in git mandates that the signing-off party to be a
> > maintainer. So agree with you in theory. However, most times
> non-committers
> > also give great feedback and help with the code review process (code
> > reviews, testing, perf etc). I think acknowledging their contribution in
> > some form would be nice and that encourages potential-future-committers
> to
> > actively review PRs IMO. So how about we annotate their names with
> > Reviewed-by tags? A related discussion
> >   on a
> > different open source project has more tag definitions if we are
> interested
> > in taking that route.
> >
> > (I know you are only talking about the "signed-off by" tag but I thought
> > this discussion would be relevant when documenting this in the dev
> > guidelines, hence bringing it up). What do you think?
>
> I would be happy with distinguishing Signed-off-by and Reviewed-by as a
> way to better track metrics on contributors who review others' code.
>
> Great idea!
>

[jira] [Resolved] (HBASE-25291) Document how to enable the meta replica load balance mode for the client and clean up around hbase:meta read replicas

[Michael Stack (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-25291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Stack resolved HBASE-25291.
---
Hadoop Flags: Reviewed
  Resolution: Fixed

Backported to branch-2 after merge of HBASE-18070.branch-2 feature branch into 
branch-2.

> Document how to enable the meta replica load balance mode for the client and 
> clean up around hbase:meta read replicas
> -
>
> Key: HBASE-25291
> URL: https://issues.apache.org/jira/browse/HBASE-25291
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 2.4.0
>Reporter: Huaxiang Sun
>Assignee: Michael Stack
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.4.0
>
>
> Need to document how to enable meta replica Load Balance mode for clients.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Clarifying guidance around Signed-off-by in commit messages

[Josh Elser]

On 11/20/20 1:07 PM, Bharath Vissapragada wrote:

* All individuals mentioned in a sign-off*must*  be capable of giving a
binding vote (i.e. they are an HBase committer)


It appears that the original intent
of
this sign-off feature in git mandates that the signing-off party to be a
maintainer. So agree with you in theory. However, most times non-committers
also give great feedback and help with the code review process (code
reviews, testing, perf etc). I think acknowledging their contribution in
some form would be nice and that encourages potential-future-committers to
actively review PRs IMO. So how about we annotate their names with
Reviewed-by tags? A related discussion
  on a
different open source project has more tag definitions if we are interested
in taking that route.

(I know you are only talking about the "signed-off by" tag but I thought
this discussion would be relevant when documenting this in the dev
guidelines, hence bringing it up). What do you think?


I would be happy with distinguishing Signed-off-by and Reviewed-by as a 
way to better track metrics on contributors who review others' code.


Great idea!

[jira] [Created] (HBASE-25315) Follow-on tasks that came of "HBASE-18070 Enable memstore replication for meta replica"

[Michael Stack (Jira)]

Michael Stack created HBASE-25315:
-

 Summary: Follow-on tasks that came of "HBASE-18070 Enable memstore 
replication for meta replica"
 Key: HBASE-25315
 URL: https://issues.apache.org/jira/browse/HBASE-25315
 Project: HBase
  Issue Type: Umbrella
  Components: meta replicas
Reporter: Michael Stack


The HBASE-18070 _Enable memstore replication for meta replica_ 
turned up _follow-ons:_ tests, doc, guardrails and enhancements. Let me give 
them their own issue so they do not crowd the original and so I can resolve the 
original against the version that carries the first implementation of the 
enhancement (Want to avoid the alternative of an issue that stays open for 
ever).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-25314) branch-1 docker mode for yetus fails

[Andrew Kyle Purtell (Jira)]

Andrew Kyle Purtell created HBASE-25314:
---

 Summary: branch-1 docker mode for yetus fails
 Key: HBASE-25314
 URL: https://issues.apache.org/jira/browse/HBASE-25314
 Project: HBase
  Issue Type: Bug
Reporter: Andrew Kyle Purtell


{noformat}
15:30:41  Step 28/33 : RUN gem install rubocop:'<= 0.81'
15:30:41   ---> Running in 21103fb7944c
15:30:42  Building native extensions.  This could take a while...
15:30:43  [91mERROR:  Error installing rubocop:
15:30:43parallel requires Ruby version >= 2.5.
15:30:43  [0mSuccessfully installed jaro_winkler-1.5.4
15:30:44  The command '/bin/sh -c gem install rubocop:'<= 0.81'' returned a 
non-zero code: 1
15:30:44  ERROR: Docker failed to build yetus/hbase:b249092a5f. 
{noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Clarifying guidance around Signed-off-by in commit messages

[Bharath Vissapragada]

Makes sense to me except a nit (inline).

On Fri, Nov 20, 2020 at 9:20 AM Josh Elser  wrote:

> Hi!
>
> As most of you know, we've been using the "Signed-off-by: 
> " line in out commit messages more and more lately to indicate
> who reviewed some change.
>
> We've recently had an event in which one of these Signed-off-by lines
> showed up with someone's name who didn't consider themselves to have
> signed-off on the change. This is akin to saying someone gave a +1 for
> some change when they did not. As an RTC community, that's worrisome.
>
> I went reading the HBase book and was surprised to not find guidance on
> how we expect this to work, so I'd like to have some discussion about
> how we should treat these lines. I'll start this off by making
> suggestions about what seems reasonable to me.
>
> When a committer is applying some change in a commit:
>
> * All individuals mentioned in a sign-off *must* be capable of giving a
> binding vote (i.e. they are an HBase committer)
>

It appears that the original intent
of
this sign-off feature in git mandates that the signing-off party to be a
maintainer. So agree with you in theory. However, most times non-committers
also give great feedback and help with the code review process (code
reviews, testing, perf etc). I think acknowledging their contribution in
some form would be nice and that encourages potential-future-committers to
actively review PRs IMO. So how about we annotate their names with
Reviewed-by tags? A related discussion
 on a
different open source project has more tag definitions if we are interested
in taking that route.

(I know you are only talking about the "signed-off by" tag but I thought
this discussion would be relevant when documenting this in the dev
guidelines, hence bringing it up). What do you think?


> * Any individual in a sign-off *must* have given approval via an
> explicit "+1" or the "Approved" via the Github Pull Request review
> function.
> * Approval *must* be publicly visible and memorialized on the code
> review (e.g. no private emails or chat message to give approval)
> * The committer _should_ (not *must*) create a sign-off line for each
> binding reviewer who gave approval
>
> I think these are generally how we have been operating, but it would be
> good to make sure they are documented as such.
>
> Thoughts/concerns?
>
> - Josh
>

[DISCUSS] Clarifying guidance around Signed-off-by in commit messages

[Josh Elser]

Hi!

As most of you know, we've been using the "Signed-off-by:  
" line in out commit messages more and more lately to indicate 
who reviewed some change.


We've recently had an event in which one of these Signed-off-by lines 
showed up with someone's name who didn't consider themselves to have 
signed-off on the change. This is akin to saying someone gave a +1 for 
some change when they did not. As an RTC community, that's worrisome.


I went reading the HBase book and was surprised to not find guidance on 
how we expect this to work, so I'd like to have some discussion about 
how we should treat these lines. I'll start this off by making 
suggestions about what seems reasonable to me.


When a committer is applying some change in a commit:

* All individuals mentioned in a sign-off *must* be capable of giving a 
binding vote (i.e. they are an HBase committer)
* Any individual in a sign-off *must* have given approval via an 
explicit "+1" or the "Approved" via the Github Pull Request review function.
* Approval *must* be publicly visible and memorialized on the code 
review (e.g. no private emails or chat message to give approval)
* The committer _should_ (not *must*) create a sign-off line for each 
binding reviewer who gave approval


I think these are generally how we have been operating, but it would be 
good to make sure they are documented as such.


Thoughts/concerns?

- Josh

[jira] [Created] (HBASE-25313) [branch-1] Fix the broken pre-commit

[Reid Chan (Jira)]

Reid Chan created HBASE-25313:
-

 Summary: [branch-1] Fix the broken pre-commit
 Key: HBASE-25313
 URL: https://issues.apache.org/jira/browse/HBASE-25313
 Project: HBase
  Issue Type: Bug
Reporter: Reid Chan
Assignee: Reid Chan






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] HBASE-25299 Scan#setRowPrefixFilter Unexpected behavior

[唐天航]

Thanks for suggestion and review.
UT updated.

Viraj Jasani  于2020年11月20日周五 下午5:36写道：

> +1 to deprecating setRowPrefixFilter. PR looks good, as I commented
> yesterday, if you could include your nice example as a unit test with this
> PR, that would be really great.
> Thanks for this nice find!
>
>
> On Thu, 19 Nov 2020 at 6:02 AM, Guanghao Zhang  wrote:
>
> > I am +1 to deprecated setRowPrefixFilter method. This method name is
> > setRowPrefixFilter but not use filter and only set start row and end
> row. I
> > thought this could be done by user.
> >
> > 唐天航  于2020年11月19日周四 上午12:45写道：
> >
> > > Hi,
> > >   I have opened an issue HBASE-25299
> > >  about
> > > Scan#setRowPrefixFilter
> > > Unexpected behavior.
> > >
> > > e.g.
> > >
> > > startRow : "112"
> > >
> > > rowPrefixFilter : "11"
> > >
> > > The Result of this scan might contain : "111", which is unexpected.
> > >
> > >   public Scan setRowPrefixFilter(byte[] rowPrefix) {
> > > if (rowPrefix == null) {
> > >   setStartRow(HConstants.EMPTY_START_ROW);
> > >   setStopRow(HConstants.EMPTY_END_ROW);
> > > } else {
> > >   this.setStartRow(rowPrefix);
> > >
>  this.setStopRow(calculateTheClosestNextRowKeyForPrefix(rowPrefix));
> > > }
> > > return this;
> > >   }
> > >
> > >  Scan#setRowPrefixFilter achieves this function by setting startRow and
> > > stopRow, ignoring the situation that startRow may have been set.
> > >
> > >
> > > I have discussed this issue with @infraio and he suggested to deprecate
> > > this method because modifying it may cause compatibility issues.
> > >
> > > Is this plan acceptable? Hope to get some suggestions.
> > >
> > >
> > > Thank you. Regards
> > >
> >
>

[jira] [Created] (HBASE-25312) Remove class DeadServer

[yuqi (Jira)]

yuqi created HBASE-25312:


 Summary: Remove class DeadServer 
 Key: HBASE-25312
 URL: https://issues.apache.org/jira/browse/HBASE-25312
 Project: HBase
  Issue Type: Improvement
Reporter: yuqi
Assignee: yuqi






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] HBASE-25299 Scan#setRowPrefixFilter Unexpected behavior

[Viraj Jasani]

+1 to deprecating setRowPrefixFilter. PR looks good, as I commented
yesterday, if you could include your nice example as a unit test with this
PR, that would be really great.
Thanks for this nice find!


On Thu, 19 Nov 2020 at 6:02 AM, Guanghao Zhang  wrote:

> I am +1 to deprecated setRowPrefixFilter method. This method name is
> setRowPrefixFilter but not use filter and only set start row and end row. I
> thought this could be done by user.
>
> 唐天航  于2020年11月19日周四 上午12:45写道：
>
> > Hi,
> >   I have opened an issue HBASE-25299
> >  about
> > Scan#setRowPrefixFilter
> > Unexpected behavior.
> >
> > e.g.
> >
> > startRow : "112"
> >
> > rowPrefixFilter : "11"
> >
> > The Result of this scan might contain : "111", which is unexpected.
> >
> >   public Scan setRowPrefixFilter(byte[] rowPrefix) {
> > if (rowPrefix == null) {
> >   setStartRow(HConstants.EMPTY_START_ROW);
> >   setStopRow(HConstants.EMPTY_END_ROW);
> > } else {
> >   this.setStartRow(rowPrefix);
> >   this.setStopRow(calculateTheClosestNextRowKeyForPrefix(rowPrefix));
> > }
> > return this;
> >   }
> >
> >  Scan#setRowPrefixFilter achieves this function by setting startRow and
> > stopRow, ignoring the situation that startRow may have been set.
> >
> >
> > I have discussed this issue with @infraio and he suggested to deprecate
> > this method because modifying it may cause compatibility issues.
> >
> > Is this plan acceptable? Hope to get some suggestions.
> >
> >
> > Thank you. Regards
> >
>

[jira] [Created] (HBASE-25311) hbase ui throws NPE

[Bo Cui (Jira)]

Bo Cui created HBASE-25311:
--

 Summary: hbase ui throws NPE
 Key: HBASE-25311
 URL: https://issues.apache.org/jira/browse/HBASE-25311
 Project: HBase
  Issue Type: Bug
Affects Versions: 2.2.3, 3.0.0-alpha-1
Reporter: Bo Cui


https://github.com/apache/hbase/blob/eca904e0fb438461a8da3f37cea3eaf496988be9/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java#L3624

 if rs has invalid znode, and restart master, ui will throw NPE.
i encountered this problem during the upgrade.

workaround: restart HBase.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-25310) HBASE-18070 makes for NPEs in some hbase-backup tests on master

[Michael Stack (Jira)]

Michael Stack created HBASE-25310:
-

 Summary: HBASE-18070 makes for NPEs in some hbase-backup tests on 
master
 Key: HBASE-25310
 URL: https://issues.apache.org/jira/browse/HBASE-25310
 Project: HBase
  Issue Type: Sub-task
  Components: test
Reporter: Michael Stack


Let me work on this as a distinct issue. The hbase-backup tests are 
complex/massive so need to do some study.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)