[jira] [Created] (HBASE-24591) get_table_rsgroup ignored the existence of rsgroup config for namespace

[Sun Xin (Jira)]

Sun Xin created HBASE-24591:
---

 Summary: get_table_rsgroup ignored the existence of rsgroup config 
for namespace
 Key: HBASE-24591
 URL: https://issues.apache.org/jira/browse/HBASE-24591
 Project: HBase
  Issue Type: Bug
  Components: rsgroup
Affects Versions: 3.0.0-alpha-1
Reporter: Sun Xin
Assignee: Sun Xin
 Fix For: 3.0.0-alpha-1


{code:java}
public GetRSGroupInfoOfTableResponse getRSGroupInfoOfTable(RpcController 
controller,
  GetRSGroupInfoOfTableRequest request) throws ServiceException {
  TableName tableName = ProtobufUtil.toTableName(request.getTableName());
  ...
  try {
...
GetRSGroupInfoOfTableResponse resp;
TableDescriptor td = master.getTableDescriptors().get(tableName);
if (td == null) {
  resp = GetRSGroupInfoOfTableResponse.getDefaultInstance();
} else {
  RSGroupInfo rsGroupInfo = null;
  if (td.getRegionServerGroup().isPresent()) {
rsGroupInfo = 
master.getRSGroupInfoManager().getRSGroup(td.getRegionServerGroup().get());
  }
  if (rsGroupInfo == null) {
rsGroupInfo = 
master.getRSGroupInfoManager().getRSGroup(RSGroupInfo.DEFAULT_GROUP);
  }
  resp = GetRSGroupInfoOfTableResponse.newBuilder()
.setRSGroupInfo(ProtobufUtil.toProtoGroupInfo(rsGroupInfo)).build();
}
...
return resp;
  } catch (IOException e) {
throw new ServiceException(e);
  }
}

{code}
In method MasterRpcServices#getRSGroupInfoOfTable, ignored namespace 
hbase.rsgroup.name config. 
 
It should be replaced by RSGroupUtil#getRSGroupInfo. 
 



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

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Duo Zhang]

On NettyRpcClientConfigHelper I think it is fine. It is designed to be an
'util' class, so in HBASE-23956 we made it final and added a private
constructor. It only has static methods and is not expected to be extended
or instantiated by end users.

On ByteBufferUtils, it is IA.Private on master branch?

On the replication related classes, all the constructors are marked as
IA.Private, so I think they are all fine. Anyway, we should have a better
design, maybe something like the ClusterMetrics, where we introduce an
interface get the metrics.


Nick Dimiduk  于2020年6月19日周五 上午6:26写道：

> I've done some accounting of the source-incompatible changes. I'm not
> listing every item here, only the ones that I think might raise eyebrows or
> warrant further discussion. Here are my findings.
>
> I think these problems sink the RC. I plan to reopen the various tickets
> here and start a discussion with the authors for getting an addendum posted
> that addresses the problems. Before I do that, please speak up if you think
> anything here I've -1 are actually justified.
>
> Thanks,
> Nick
>
> Removed Methods:
>  * org.apache.hadoop.hbase.rest.client.{RemoteAdmin,RemoteHTable} -- these
> were dropped intentionally and with discussion via HBASE-24115, +1.
>  * org.apache.hadoop.hbase.util.ByteBufferUtils.findCommonPrefix (...) --
> looks like this method was refactored away as part of HBASE-22504. However,
> it is present in an IA.Public class, so it needs a deprecation cycle before
> removal, -1.
>  * org.apache.hadoop.hbase.HRegionInfo.compareTo -- the Comparable
> implementation was moved up to the interface via default method, so I think
> this is acceptable, via HBASE-23753. +1.
>  * org.apache.hadoop.hbase.replication.ReplicationLoadSink -- Additional
> constructor arguments added in HBASE-21406, -1.
>  * org.apache.hadoop.hbase.replication.ReplicationLoadSource -- Additional
> constructor arguments added in HBASE-21505, -1.
>  * org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
> constructor arguments added in HBASE-22648, -1.
>  *
> org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad(...)
> -- Method signature change on a protected method via HBASE-24221, -1.
>  * org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob --
> Method parameter removed via HBASE-21773, -1.
>
> Problems with Data Types, High Severity:
>  * org.apache.hadoop.hbase.HConstants#HBASE_NON_USER_TABLE_DIRS -- Field
> removed via HBASE-23055, -1.
>  * org.apache.hadoop.hbase.HRegionInfo Removed super-interface
> java.lang.Comparable -- same as HBASE-23753 above. Missing
> interface moved to the super-interface, preserved. +1.
>  * A number of interfaces seeing new methods. These interfaces look like
> API we expect a client to consume, not implement. Book says under Client
> API compatibility: "New APIs introduced in a patch version will only be
> added in a source compatible way [1]: i.e. code that implements public APIs
> will continue to compile." Strictly speaking, I think these are breaking
> changes for a minor release, but since this is an interface we don't expect
> clients to implement, only to consume, I'm -0.
>  * org.apache.hadoop.hbase.ipc.NettyRpcClientConfigHelper -- class became
> final, via HBASE-23956. We don't want clients (or anyone) to extend this
> class. +1.
>  * org.apache.hadoop.hbase.replication.ReplicationLoadSource -- class
> became final, via HBASE-21505. We don't want clients (or anyone) to extend
> this class. +1.
>  * org.apache.hadoop.hbase.mapreduce.RowCounter -- removed interface Tool,
> via HBASE-21773. Now extends AbstractHBaseTool, which does implement
> Tool. +1.
>  * org.apache.hadoop.hbase.util.RegionMover -- 6 public fields made
> private, via HBASE-24102. -1.
>
> Problems with Methods, High Severity:
> * org.apache.hadoop.hbase.ipc.NettyRpcClientConfigHelper -- default
> constructor made private, via HBASE-23956. -1.
>
> Problems with Methods, Medium Severity:
>  * org.apache.hadoop.hbase.rest.filter.RestCsrfPreventionFilter.init(...)
> -- removed declared thrown exception, via HBASE-23661. Clients don't extend
> this class, +1.
>  * org.apache.hadoop.hbase.client.RegionInfo.isEncodedRegionName(...) --
> removed thrown exception, via HBASE-23326. Clients don't extend this
> class, +1.
>  *
>
>
> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk  wrote:
>
> > Please vote on this Apache hbase release candidate,
> > hbase-2.3.0RC0
> >
> > The VOTE will remain open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache hbase 2.3.0
> > [ ] -1 Do not release this package because ...
> >
> > The tag to be voted on is 2.3.0RC0:
> >
> >   https://github.com/apache/hbase/tree/2.3.0RC0
> >
> > The release files, including signatures, digests, as well as CHANGES.md
> > and RELEASENOTES.md included in this RC can be found at:
> >
> >   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
> >
> > Maven artifacts are available in a staging repository at:
> >
> >

[jira] [Created] (HBASE-24590) Clone snapshot with optional table level property overrides

[Bharath Vissapragada (Jira)]

Bharath Vissapragada created HBASE-24590:


 Summary: Clone snapshot with optional table level property 
overrides
 Key: HBASE-24590
 URL: https://issues.apache.org/jira/browse/HBASE-24590
 Project: HBase
  Issue Type: Improvement
  Components: API, master, shell
Affects Versions: 1.6.0, 3.0.0-alpha-1, 2.3.0
Reporter: Bharath Vissapragada


We have this use case where we try to clone from snapshots of a table with 
replication enabled. Cloning process just reads the TableDescriptor from the 
manifest and uses it for the new target table.

In our case, the moment we clone it, replication kicks in and attempts to 
replicate table to peers but since the target table doesn't exist, it keeps 
throwing TNFE in a loop. I propose to add additional *optional* parameters to 
clone_snapshot that takes the target table property overrides (table leve/cf 
level).

For example:

{noformat}
clone_snapshot 'snapshotName', 'tableName'# default
clone_snapshot 'snapshotName', 'tableName', {NAME => 'f1', REPLICATION_SCOPE => 
0 }
clone_snapshot 'snapshotName, 'tableName', {MERGE_ENABLED => false}
.
{noformat}
 

Implementation wise, this just adds a {{ModifyTableProcedure}} as a child 
procedure (if args are provided) for {{CloneSnapshotProcedure}} after 
{{CLONE_SNAPSHOT_ADD_TO_META}}, so we reuse most of the "modifyTable" code. 

Also, since clone puts the table in a disabled state, using 
"ModifyTableProcedure" shouldn't cause any issues.

 Thoughts? Is there any easier way to do it?

 



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

[jira] [Created] (HBASE-24589) In HBase UI, srcChecksum has bad content

[Matthew Foley (Jira)]

Matthew Foley created HBASE-24589:
-

 Summary: In HBase UI, srcChecksum has bad content
 Key: HBASE-24589
 URL: https://issues.apache.org/jira/browse/HBASE-24589
 Project: HBase
  Issue Type: Bug
  Components: UI
Affects Versions: 3.0.0-alpha-1, 2.3.0
Reporter: Matthew Foley
Assignee: Matthew Foley


The value of srcChecksum displayed in the HBase UI is generated at build time 
by 
https://github.com/apache/hbase/blob/master/hbase-common/src/saveVersion.sh#L53-L61

On a Linux build host,
if `openssl`(v 1.1.1) is available, the resulting value of srcChecksum is 
`(stdin)=`
else if `gpg` (v 2.2.19) is available, the value is only the first 8-character 
substring of the sha512 hash.

On a Mac build host,
if `openssl`(LibreSSL 2.8.3) is available, the resulting value of srcChecksum 
is correct
else if `gpg` (v 2.2.19) is available, the value is again the first 8-character 
substring of the sha512 hash.





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

[jira] [Created] (HBASE-24588) Normalizer plan execution is not consistent between plan types

[Nick Dimiduk (Jira)]

Nick Dimiduk created HBASE-24588:


 Summary: Normalizer plan execution is not consistent between plan 
types
 Key: HBASE-24588
 URL: https://issues.apache.org/jira/browse/HBASE-24588
 Project: HBase
  Issue Type: Bug
  Components: master, Normalizer
Affects Versions: 2.3.0
Reporter: Nick Dimiduk


I left a comment on a merged 
[commit|https://github.com/apache/hbase/commit/5d0e0fc5fd09bddb2d766d1e24e28e472961f454#r39987289]
 where a little discussion has blossomed. Right now the normalizer produces two 
types of plans: "split" or "merge". The master receives the list of plans and 
executes them in a simple loop. The way it does the actual execution is 
delegated off to the plan implementation.

The bug I noticed is that the two implementations are subtly different. Both 
use async APIs to submit procedures, but "split" blocks on completion while 
"merge" does not. Furthermore, because "split" blocks, it's able to capture any 
exception that's thrown, while "merge" cannot.

These implementations should be made consistent. My thinking at the moment is 
this {{execute}} method should instead be named {{submit}}, creating and 
returning the {{Future}} that represents whatever work it submitted, and the 
calling context should handle the resolution of those futures in a single place.



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

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

I've done some accounting of the source-incompatible changes. I'm not
listing every item here, only the ones that I think might raise eyebrows or
warrant further discussion. Here are my findings.

I think these problems sink the RC. I plan to reopen the various tickets
here and start a discussion with the authors for getting an addendum posted
that addresses the problems. Before I do that, please speak up if you think
anything here I've -1 are actually justified.

Thanks,
Nick

Removed Methods:
 * org.apache.hadoop.hbase.rest.client.{RemoteAdmin,RemoteHTable} -- these
were dropped intentionally and with discussion via HBASE-24115, +1.
 * org.apache.hadoop.hbase.util.ByteBufferUtils.findCommonPrefix (...) --
looks like this method was refactored away as part of HBASE-22504. However,
it is present in an IA.Public class, so it needs a deprecation cycle before
removal, -1.
 * org.apache.hadoop.hbase.HRegionInfo.compareTo -- the Comparable
implementation was moved up to the interface via default method, so I think
this is acceptable, via HBASE-23753. +1.
 * org.apache.hadoop.hbase.replication.ReplicationLoadSink -- Additional
constructor arguments added in HBASE-21406, -1.
 * org.apache.hadoop.hbase.replication.ReplicationLoadSource -- Additional
constructor arguments added in HBASE-21505, -1.
 * org.apache.hadoop.hbase.client.SnapshotDescription -- Additional
constructor arguments added in HBASE-22648, -1.
 * org.apache.hadoop.hbase.tool.LoadIncrementalHFiles.tryAtomicRegionLoad(...)
-- Method signature change on a protected method via HBASE-24221, -1.
 * org.apache.hadoop.hbase.mapreduce.RowCounter.createSubmittableJob --
Method parameter removed via HBASE-21773, -1.

Problems with Data Types, High Severity:
 * org.apache.hadoop.hbase.HConstants#HBASE_NON_USER_TABLE_DIRS -- Field
removed via HBASE-23055, -1.
 * org.apache.hadoop.hbase.HRegionInfo Removed super-interface
java.lang.Comparable -- same as HBASE-23753 above. Missing
interface moved to the super-interface, preserved. +1.
 * A number of interfaces seeing new methods. These interfaces look like
API we expect a client to consume, not implement. Book says under Client
API compatibility: "New APIs introduced in a patch version will only be
added in a source compatible way [1]: i.e. code that implements public APIs
will continue to compile." Strictly speaking, I think these are breaking
changes for a minor release, but since this is an interface we don't expect
clients to implement, only to consume, I'm -0.
 * org.apache.hadoop.hbase.ipc.NettyRpcClientConfigHelper -- class became
final, via HBASE-23956. We don't want clients (or anyone) to extend this
class. +1.
 * org.apache.hadoop.hbase.replication.ReplicationLoadSource -- class
became final, via HBASE-21505. We don't want clients (or anyone) to extend
this class. +1.
 * org.apache.hadoop.hbase.mapreduce.RowCounter -- removed interface Tool,
via HBASE-21773. Now extends AbstractHBaseTool, which does implement
Tool. +1.
 * org.apache.hadoop.hbase.util.RegionMover -- 6 public fields made
private, via HBASE-24102. -1.

Problems with Methods, High Severity:
* org.apache.hadoop.hbase.ipc.NettyRpcClientConfigHelper -- default
constructor made private, via HBASE-23956. -1.

Problems with Methods, Medium Severity:
 * org.apache.hadoop.hbase.rest.filter.RestCsrfPreventionFilter.init(...)
-- removed declared thrown exception, via HBASE-23661. Clients don't extend
this class, +1.
 * org.apache.hadoop.hbase.client.RegionInfo.isEncodedRegionName(...) --
removed thrown exception, via HBASE-23326. Clients don't extend this
class, +1.
 *


On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk  wrote:

> Please vote on this Apache hbase release candidate,
> hbase-2.3.0RC0
>
> The VOTE will remain open for at least 72 hours.
>
> [ ] +1 Release this package as Apache hbase 2.3.0
> [ ] -1 Do not release this package because ...
>
> The tag to be voted on is 2.3.0RC0:
>
>   https://github.com/apache/hbase/tree/2.3.0RC0
>
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
>
>   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
>
> Maven artifacts are available in a staging repository at:
>
>   https://repository.apache.org/content/repositories/orgapachehbase-1393/
>
> Artifacts were signed with the ndimi...@apache.org key which can be found
> in:
>
>   https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> To learn more about Apache hbase, please see
>
>   http://hbase.apache.org/
>
> Thanks,
> Your HBase Release Manager
>

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

Duo,

Thank you for taking the time. I saw quite a bit of delta in the
compatibility report, which is concerning to me as well. Let me get back to
you here after spending some time with it. I'll also look more closely at
the size of the client tarball. This is a feature of our releases that I
have no experience with, so maybe someone here who's more familiar can take
a look?

Thanks,
Nick

On Wed, Jun 17, 2020 at 11:31 PM 张铎(Duo Zhang) 
wrote:

> +1(binding), thanks for your great work Nick.
>
> Checked sigs and sums: Matched
> Rat check: Passed
> Run all UTs: Passed. Excellent.
> Compatibility report: Fine, as said above.
> Started a local cluster and
> Checked the Web UI: Nothing strange.
> Then used the client bin and
> Run basic shell command: OK
> Run LTT with read/write 10k rows: Passed
>
> My only concerns is that, the client-bin is even larger than the bin, 308
> MB vs 260 MB. Is this expected? The main difference is the docs directory,
> in bin it is 65 MB while in client-bin it is 681 MB.
>
> Thanks.
>
> 张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：
>
> > I'm still testing but let me post something about the compatibility
> report
> > first.
> >
> > There is an incompatible item about removing a method from the Admin
> > interface, which should not happen for a minor release.
> >
> > package org.apache.hadoop.hbase.client
> > Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
> >
> >
> org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
> >
> > Checked the release note and found out that it was done in HBASE-22001,
> by
> > me...
> > I just changed the return value from void to Future, so the
> > compatibility report tells that the method which returns void has been
> > removed.
> >
> > I think this is fine. We do not guarantee drop in replacement for a minor
> > release, and it will not be a problem if users recompile their code.
> >
> > Thanks.
> >
> > Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
> >
> >> Thanks. I'm switching my vote to +1.
> >>
> >> - Signatures match (src/bin)
> >> - Checksums match (src/bin)
> >> - Compiled src from scratch
> >> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
> >> - Started a local mini cluster from compiled-src and bin artifacts and
> ran
> >> some smoke tests - No issues
> >> - Skimmed through the release notes.
> >>
> >> Thanks Nick for putting together such a high quality release, especially
> >> all the work around docs/test flakes etc.
> >>
> >> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
> >> wrote:
> >>
> >> > I have updated the KEYS file with revision 40069.
> >> >
> >> > I have also verified the content of the file on people.apache.org is
> >> up to
> >> > date, https://people.apache.org/keys/committer/ndimiduk.asc
> >> >
> >> > Thanks,
> >> > Nick
> >> >
> >> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
> >> wrote:
> >> >
> >> > > Ah, could be. I did update the expiration date. Let me update the
> KEYS
> >> > > file and double-check id.a.o.
> >> > >
> >> > > Thanks for the reminder.
> >> > >
> >> > > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada <
> >> bhara...@apache.org>
> >> > > wrote:
> >> > >
> >> > >> -1 (binding)
> >> > >>
> >> > >> Looks like your key from the KEYS file has expired?  Per Apache
> FAQs
> >> > >> , "A
> >> > >> signature is valid, if gpg verifies the .asc as a good signature,
> and
> >> > >> doesn't complain about expired or revoked keys."
> >> > >>
> >> > >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
> >> > >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
> >> > >> > gpg:using RSA key
> >> > >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
> >> > >> > gpg:issuer "ndimi...@apache.org"
> >> > >> > gpg: Good signature from "Nick Dimiduk "
> >> > [expired]
> >> > >> > gpg: aka "Nick Dimiduk "
> >> > [expired]
> >> > >> > gpg: Note: This key has expired!
> >> > >> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36 33F1
> >> 8644
> >> > >> EEB6
> >> > >> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90 3907
> >> 1C34
> >> > >> 89BD
> >> > >>
> >> > >>
> >> > >> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk 
> >> > wrote:
> >> > >>
> >> > >> > Please vote on this Apache hbase release candidate,
> >> > >> > hbase-2.3.0RC0
> >> > >> >
> >> > >> > The VOTE will remain open for at least 72 hours.
> >> > >> >
> >> > >> > [ ] +1 Release this package as Apache hbase 2.3.0
> >> > >> > [ ] -1 Do not release this package because ...
> >> > >> >
> >> > >> > The tag to be voted on is 2.3.0RC0:
> >> > >> >
> >> > >> >   https://github.com/apache/hbase/tree/2.3.0RC0
> >> > >> >
> >> > >> > The release files, including signatures, digests, as well as
> >> > CHANGES.md
> >> > >> > and RELEASENOTES.md included in this RC can be found at:
> >> > >> >
> >> > >> >   https://dist.apache.org/repos/dist/dev

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

Andrew,

Your test failure sounds like
https://issues.apache.org/jira/browse/HBASE-23970.

Thanks,
Nick

On Thu, Jun 18, 2020 at 1:15 PM Andrew Purtell  wrote:

> +1 (binding)
>
> * Signature: ok
> * Checksum : ok
> * Rat check (1.8.0_232): ok
>  - mvn clean apache-rat:check
> * Built from source (1.8.0_232): ok
>  - mvn clean install -DskipTests
> * Unit tests pass (1.8.0_232): failed
>  - mvn package -P runAllTests
>
> TestUsersOperationsWithSecureHadoop failed for me, but it's because of a
> local kerberos configuration issue.
>
> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk  wrote:
>
> > Please vote on this Apache hbase release candidate,
> > hbase-2.3.0RC0
> >
> > The VOTE will remain open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache hbase 2.3.0
> > [ ] -1 Do not release this package because ...
> >
> > The tag to be voted on is 2.3.0RC0:
> >
> >   https://github.com/apache/hbase/tree/2.3.0RC0
> >
> > The release files, including signatures, digests, as well as CHANGES.md
> > and RELEASENOTES.md included in this RC can be found at:
> >
> >   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
> >
> > Maven artifacts are available in a staging repository at:
> >
> >
> https://repository.apache.org/content/repositories/orgapachehbase-1393/
> >
> > Artifacts were signed with the ndimi...@apache.org key which can be
> found
> > in:
> >
> >   https://dist.apache.org/repos/dist/release/hbase/KEYS
> >
> > To learn more about Apache hbase, please see
> >
> >   http://hbase.apache.org/
> >
> > Thanks,
> > Your HBase Release Manager
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Nick Dimiduk]

Viraj,

Do you happen to have the junit xml output from a failed run? You could
open a Flakey test ticket with the run log? I haven't looked at this test
specifically, but I've observed that these replication tests spin up
multiple miniclusters, which puts a huge strain on the system, and their
resource accounting doesn't always accommodate the slowdown of the system.
We could dig in some more.

Thanks,
Nick

On Thu, Jun 18, 2020 at 6:14 AM Viraj Jasani  wrote:

> +1
>
> * Signature: ok
> * Checksum : ok
> * Rat check (1.8.0_251): ok
>  - mvn clean apache-rat:check
> * Built from source (1.8.0_251): ok
>  - mvn clean install -DskipTests
> * Unit tests pass (1.8.0_251): failed
>  - mvn package -P runAllTests
>
> [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 29.212 s <<< FAILURE! - in
> org.apache.hadoop.hbase.replication.TestReplicationStatus
> [ERROR]
> org.apache.hadoop.hbase.replication.TestReplicationStatus.testReplicationStatusSink
> Time elapsed: 1.016 s  <<< FAILURE!
> java.lang.AssertionError: expected:<1592477704810> but was:<1592477719964>
> at
> org.apache.hadoop.hbase.replication.TestReplicationStatus.testReplicationStatusSink(TestReplicationStatus.java:134)
>
> After test results, I ran TestReplicationStatus separately on local and it
> passed, checked flaky and nightly dashboards, nightly is all good and flaky
> does't report TestReplicationStatus failures in available builds (at least
> for the past 3 days).
> The above failure indicates there are chances few edits are replicated
> before we even insert some data as part of the test.
>   //First checks if status of timestamp of last applied op is same as
> RS start, since no edits
>   //were replicated yet
>   assertEquals(loadSink.getTimestampStarted(),
> loadSink.getTimestampsOfLastAppliedOp());
>
> Anyways, locally this test looks all good. We can't run it in a loop
> within TestReplicationStatus as per the nature of the test, but all
> separate runs (mvn test
> -Dtest=org.apache.hadoop.hbase.replication.TestReplicationStatus) are
> passing.
>
>
>
> On 2020/06/18 06:31:04, 张铎(Duo Zhang)  wrote:
> > +1(binding), thanks for your great work Nick.
> >
> > Checked sigs and sums: Matched
> > Rat check: Passed
> > Run all UTs: Passed. Excellent.
> > Compatibility report: Fine, as said above.
> > Started a local cluster and
> > Checked the Web UI: Nothing strange.
> > Then used the client bin and
> > Run basic shell command: OK
> > Run LTT with read/write 10k rows: Passed
> >
> > My only concerns is that, the client-bin is even larger than the bin, 308
> > MB vs 260 MB. Is this expected? The main difference is the docs
> directory,
> > in bin it is 65 MB while in client-bin it is 681 MB.
> >
> > Thanks.
> >
> > 张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：
> >
> > > I'm still testing but let me post something about the compatibility
> report
> > > first.
> > >
> > > There is an incompatible item about removing a method from the Admin
> > > interface, which should not happen for a minor release.
> > >
> > > package org.apache.hadoop.hbase.client
> > > Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
> > >
> > >
> org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
> > >
> > > Checked the release note and found out that it was done in
> HBASE-22001, by
> > > me...
> > > I just changed the return value from void to Future, so the
> > > compatibility report tells that the method which returns void has been
> > > removed.
> > >
> > > I think this is fine. We do not guarantee drop in replacement for a
> minor
> > > release, and it will not be a problem if users recompile their code.
> > >
> > > Thanks.
> > >
> > > Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
> > >
> > >> Thanks. I'm switching my vote to +1.
> > >>
> > >> - Signatures match (src/bin)
> > >> - Checksums match (src/bin)
> > >> - Compiled src from scratch
> > >> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
> > >> - Started a local mini cluster from compiled-src and bin artifacts
> and ran
> > >> some smoke tests - No issues
> > >> - Skimmed through the release notes.
> > >>
> > >> Thanks Nick for putting together such a high quality release,
> especially
> > >> all the work around docs/test flakes etc.
> > >>
> > >> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
> > >> wrote:
> > >>
> > >> > I have updated the KEYS file with revision 40069.
> > >> >
> > >> > I have also verified the content of the file on people.apache.org
> is
> > >> up to
> > >> > date, https://people.apache.org/keys/committer/ndimiduk.asc
> > >> >
> > >> > Thanks,
> > >> > Nick
> > >> >
> > >> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
> > >> wrote:
> > >> >
> > >> > > Ah, could be. I did update the expiration date. Let me update the
> KEYS
> > >> > > file and double-check id.a.o.
> > >> > >
> > >> > > Thanks for the reminder.
> > >> > >
> > >> > > On Tue, Jun 16, 2020 at 15:39 Bharat

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Andrew Purtell]

+1 (binding)

* Signature: ok
* Checksum : ok
* Rat check (1.8.0_232): ok
 - mvn clean apache-rat:check
* Built from source (1.8.0_232): ok
 - mvn clean install -DskipTests
* Unit tests pass (1.8.0_232): failed
 - mvn package -P runAllTests

TestUsersOperationsWithSecureHadoop failed for me, but it's because of a
local kerberos configuration issue.

On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk  wrote:

> Please vote on this Apache hbase release candidate,
> hbase-2.3.0RC0
>
> The VOTE will remain open for at least 72 hours.
>
> [ ] +1 Release this package as Apache hbase 2.3.0
> [ ] -1 Do not release this package because ...
>
> The tag to be voted on is 2.3.0RC0:
>
>   https://github.com/apache/hbase/tree/2.3.0RC0
>
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
>
>   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
>
> Maven artifacts are available in a staging repository at:
>
>   https://repository.apache.org/content/repositories/orgapachehbase-1393/
>
> Artifacts were signed with the ndimi...@apache.org key which can be found
> in:
>
>   https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> To learn more about Apache hbase, please see
>
>   http://hbase.apache.org/
>
> Thanks,
> Your HBase Release Manager
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Peter Somogyi]

+1 (binding)

* Signature: ok
* Checksum : ok
* Rat check (1.8.0_252): ok
  - mvn clean apache-rat:check
* Built from source (1.8.0_252): ok
  - mvn clean install -DskipTests
* Unit tests pass (1.8.0_252): ok
  - mvn package -P runAllTests
* LTT 1M rows write: ok
* Simple shell operations: ok
* Logs: ok

nit: VersionInfo does not have SHA512 checksum. UI shows "From source with
checksum = (stdin)="

Thanks for the release Nick!

Peter


On Thu, Jun 18, 2020 at 3:15 PM Wellington Chevreuil <
wellington.chevre...@gmail.com> wrote:

> +1 (binding)
>
>  * Signature: ok
>
>  * Checksum : ok
>
>  * Rat check (1.8.0_222): ok
>
>- mvn clean apache-rat:check
>
>  * Built from source (1.8.0_222): ok
>
> - mvn clean install -DskipTests
>
>  * Unit tests pass (1.8.0_222): ok
>
> - mvn package -P runSmallTests
>
>
> Deployed pseudo distributed on local FS:
>
> * Web UI: ok
>
> * CRUD: ok
>
> * ltt 10 rows: ok
>
> Em qui., 18 de jun. de 2020 às 07:31, 张铎(Duo Zhang)  >
> escreveu:
>
> > +1(binding), thanks for your great work Nick.
> >
> > Checked sigs and sums: Matched
> > Rat check: Passed
> > Run all UTs: Passed. Excellent.
> > Compatibility report: Fine, as said above.
> > Started a local cluster and
> > Checked the Web UI: Nothing strange.
> > Then used the client bin and
> > Run basic shell command: OK
> > Run LTT with read/write 10k rows: Passed
> >
> > My only concerns is that, the client-bin is even larger than the bin, 308
> > MB vs 260 MB. Is this expected? The main difference is the docs
> directory,
> > in bin it is 65 MB while in client-bin it is 681 MB.
> >
> > Thanks.
> >
> > 张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：
> >
> > > I'm still testing but let me post something about the compatibility
> > report
> > > first.
> > >
> > > There is an incompatible item about removing a method from the Admin
> > > interface, which should not happen for a minor release.
> > >
> > > package org.apache.hadoop.hbase.client
> > > Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
> > >
> > >
> >
> org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
> > >
> > > Checked the release note and found out that it was done in HBASE-22001,
> > by
> > > me...
> > > I just changed the return value from void to Future, so the
> > > compatibility report tells that the method which returns void has been
> > > removed.
> > >
> > > I think this is fine. We do not guarantee drop in replacement for a
> minor
> > > release, and it will not be a problem if users recompile their code.
> > >
> > > Thanks.
> > >
> > > Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
> > >
> > >> Thanks. I'm switching my vote to +1.
> > >>
> > >> - Signatures match (src/bin)
> > >> - Checksums match (src/bin)
> > >> - Compiled src from scratch
> > >> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
> > >> - Started a local mini cluster from compiled-src and bin artifacts and
> > ran
> > >> some smoke tests - No issues
> > >> - Skimmed through the release notes.
> > >>
> > >> Thanks Nick for putting together such a high quality release,
> especially
> > >> all the work around docs/test flakes etc.
> > >>
> > >> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
> > >> wrote:
> > >>
> > >> > I have updated the KEYS file with revision 40069.
> > >> >
> > >> > I have also verified the content of the file on people.apache.org
> is
> > >> up to
> > >> > date, https://people.apache.org/keys/committer/ndimiduk.asc
> > >> >
> > >> > Thanks,
> > >> > Nick
> > >> >
> > >> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
> > >> wrote:
> > >> >
> > >> > > Ah, could be. I did update the expiration date. Let me update the
> > KEYS
> > >> > > file and double-check id.a.o.
> > >> > >
> > >> > > Thanks for the reminder.
> > >> > >
> > >> > > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada <
> > >> bhara...@apache.org>
> > >> > > wrote:
> > >> > >
> > >> > >> -1 (binding)
> > >> > >>
> > >> > >> Looks like your key from the KEYS file has expired?  Per Apache
> > FAQs
> > >> > >> ,
> "A
> > >> > >> signature is valid, if gpg verifies the .asc as a good signature,
> > and
> > >> > >> doesn't complain about expired or revoked keys."
> > >> > >>
> > >> > >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
> > >> > >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
> > >> > >> > gpg:using RSA key
> > >> > >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
> > >> > >> > gpg:issuer "ndimi...@apache.org"
> > >> > >> > gpg: Good signature from "Nick Dimiduk "
> > >> > [expired]
> > >> > >> > gpg: aka "Nick Dimiduk "
> > >> > [expired]
> > >> > >> > gpg: Note: This key has expired!
> > >> > >> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36
> 33F1
> > >> 8644
> > >> > >> EEB6
> > >> > >> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90
> 3907
> > >>

[jira] [Resolved] (HBASE-24574) Procedure V2 - Distributed WAL Splitting => LOGGING

[Michael Stack (Jira)]

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

Michael Stack resolved HBASE-24574.
---
Fix Version/s: 2.3.1
   3.0.0-alpha-1
 Hadoop Flags: Reviewed
   Resolution: Fixed

Merged to branch-2.3+ Thanks for reviews [~zghao] and @tianjingyun


> Procedure V2 - Distributed WAL Splitting => LOGGING
> ---
>
> Key: HBASE-24574
> URL: https://issues.apache.org/jira/browse/HBASE-24574
> Project: HBase
>  Issue Type: Sub-task
>  Components: wal
>Reporter: Michael Stack
>Assignee: Michael Stack
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.1
>
>
> The procedure-based distributed WAL splitter uses the old SplitLogManager 
> class. It registers it as a chore even though the chore #run immediately 
> skips out. Meantime we log SLM ran in #0ms frequently. For example...
> {code}
> ...
> 2020-06-17 17:48:30,567 DEBUG [localhost:16000.splitLogManager..Chore.1] 
> hbase.ScheduledChore: SplitLogManager Timeout Monitor execution time: 0 ms.
> 2020-06-17 17:48:31,567 DEBUG [localhost:16000.splitLogManager..Chore.1] 
> hbase.ScheduledChore: SplitLogManager Timeout Monitor execution time: 0 ms.
> 2020-06-17 17:48:32,570 DEBUG [localhost:16000.splitLogManager..Chore.1] 
> hbase.ScheduledChore: SplitLogManager Timeout Monitor execution time: 0 ms.
> 2020-06-17 17:48:33,567 DEBUG [localhost:16000.splitLogManager..Chore.1] 
> hbase.ScheduledChore: SplitLogManager Timeout Monitor execution time: 0 ms.
> 2020-06-17 17:48:34,569 DEBUG [localhost:16000.splitLogManager..Chore.1] 
> hbase.ScheduledChore: SplitLogManager Timeout Monitor execution time: 0 ms.
> 2020-06-17 17:48:35,569 DEBUG [localhost:16000.splitLogManager..Chore.1] 
> hbase.ScheduledChore: SplitLogManager Timeout Monitor execution time: 0 ms.
> 2020-06-17 17:48:36,568 DEBUG [localhost:16000.splitLogManager..Chore.1] 
> hbase.ScheduledChore: SplitLogManager Timeout Monitor execution time: 0 ms.
> ...
> {code}
> The new pv2 WAL splitter introduces new procedures that log their class name 
> only w/o detail on log that is being split or the server that is running the 
> split.



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

[jira] [Created] (HBASE-24587) hbck2 command should accept one or more files containing a list of region names

[Clara Xiong (Jira)]

Clara Xiong created HBASE-24587:
---

 Summary: hbck2 command should accept one or more files containing 
a list of region names
 Key: HBASE-24587
 URL: https://issues.apache.org/jira/browse/HBASE-24587
 Project: HBase
  Issue Type: Improvement
  Components: hbase-operator-tools, hbck2
Affects Versions: hbase-operator-tools-1.0.0
Reporter: Clara Xiong
Assignee: Clara Xiong


Currently many command accepts a list of region names/ table names/namespaces 
on the command line.  We should accept paths to one or more files that contains 
these encoded regions, one per line. That way, this command tails nicely into 
an operator's incantation using grep/sed over log files.

Similar work has been done in https://issues.apache.org/jira/browse/HBASE-23927



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

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Wellington Chevreuil]

+1 (binding)

 * Signature: ok

 * Checksum : ok

 * Rat check (1.8.0_222): ok

   - mvn clean apache-rat:check

 * Built from source (1.8.0_222): ok

- mvn clean install -DskipTests

 * Unit tests pass (1.8.0_222): ok

- mvn package -P runSmallTests


Deployed pseudo distributed on local FS:

* Web UI: ok

* CRUD: ok

* ltt 10 rows: ok

Em qui., 18 de jun. de 2020 às 07:31, 张铎(Duo Zhang) 
escreveu:

> +1(binding), thanks for your great work Nick.
>
> Checked sigs and sums: Matched
> Rat check: Passed
> Run all UTs: Passed. Excellent.
> Compatibility report: Fine, as said above.
> Started a local cluster and
> Checked the Web UI: Nothing strange.
> Then used the client bin and
> Run basic shell command: OK
> Run LTT with read/write 10k rows: Passed
>
> My only concerns is that, the client-bin is even larger than the bin, 308
> MB vs 260 MB. Is this expected? The main difference is the docs directory,
> in bin it is 65 MB while in client-bin it is 681 MB.
>
> Thanks.
>
> 张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：
>
> > I'm still testing but let me post something about the compatibility
> report
> > first.
> >
> > There is an incompatible item about removing a method from the Admin
> > interface, which should not happen for a minor release.
> >
> > package org.apache.hadoop.hbase.client
> > Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
> >
> >
> org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
> >
> > Checked the release note and found out that it was done in HBASE-22001,
> by
> > me...
> > I just changed the return value from void to Future, so the
> > compatibility report tells that the method which returns void has been
> > removed.
> >
> > I think this is fine. We do not guarantee drop in replacement for a minor
> > release, and it will not be a problem if users recompile their code.
> >
> > Thanks.
> >
> > Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
> >
> >> Thanks. I'm switching my vote to +1.
> >>
> >> - Signatures match (src/bin)
> >> - Checksums match (src/bin)
> >> - Compiled src from scratch
> >> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
> >> - Started a local mini cluster from compiled-src and bin artifacts and
> ran
> >> some smoke tests - No issues
> >> - Skimmed through the release notes.
> >>
> >> Thanks Nick for putting together such a high quality release, especially
> >> all the work around docs/test flakes etc.
> >>
> >> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
> >> wrote:
> >>
> >> > I have updated the KEYS file with revision 40069.
> >> >
> >> > I have also verified the content of the file on people.apache.org is
> >> up to
> >> > date, https://people.apache.org/keys/committer/ndimiduk.asc
> >> >
> >> > Thanks,
> >> > Nick
> >> >
> >> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
> >> wrote:
> >> >
> >> > > Ah, could be. I did update the expiration date. Let me update the
> KEYS
> >> > > file and double-check id.a.o.
> >> > >
> >> > > Thanks for the reminder.
> >> > >
> >> > > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada <
> >> bhara...@apache.org>
> >> > > wrote:
> >> > >
> >> > >> -1 (binding)
> >> > >>
> >> > >> Looks like your key from the KEYS file has expired?  Per Apache
> FAQs
> >> > >> , "A
> >> > >> signature is valid, if gpg verifies the .asc as a good signature,
> and
> >> > >> doesn't complain about expired or revoked keys."
> >> > >>
> >> > >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
> >> > >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
> >> > >> > gpg:using RSA key
> >> > >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
> >> > >> > gpg:issuer "ndimi...@apache.org"
> >> > >> > gpg: Good signature from "Nick Dimiduk "
> >> > [expired]
> >> > >> > gpg: aka "Nick Dimiduk "
> >> > [expired]
> >> > >> > gpg: Note: This key has expired!
> >> > >> > Primary key fingerprint: 3A74 917C 0C45 844F B816  BB4A CA36 33F1
> >> 8644
> >> > >> EEB6
> >> > >> >  Subkey fingerprint: 6EF6 CEC7 4B89 B929 3B4D  9CD0 AD90 3907
> >> 1C34
> >> > >> 89BD
> >> > >>
> >> > >>
> >> > >> On Tue, Jun 16, 2020 at 9:36 AM Nick Dimiduk 
> >> > wrote:
> >> > >>
> >> > >> > Please vote on this Apache hbase release candidate,
> >> > >> > hbase-2.3.0RC0
> >> > >> >
> >> > >> > The VOTE will remain open for at least 72 hours.
> >> > >> >
> >> > >> > [ ] +1 Release this package as Apache hbase 2.3.0
> >> > >> > [ ] -1 Do not release this package because ...
> >> > >> >
> >> > >> > The tag to be voted on is 2.3.0RC0:
> >> > >> >
> >> > >> >   https://github.com/apache/hbase/tree/2.3.0RC0
> >> > >> >
> >> > >> > The release files, including signatures, digests, as well as
> >> > CHANGES.md
> >> > >> > and RELEASENOTES.md included in this RC can be found at:
> >> > >> >
> >> > >> >   https://dist.apache.org/repos/dist/dev/hbase/2.3.0RC0/
> >> > >> >
> >>

Re: [VOTE] First release candidate for HBase 2.3.0 (RC0) is available

[Viraj Jasani]

+1

* Signature: ok
* Checksum : ok
* Rat check (1.8.0_251): ok
 - mvn clean apache-rat:check
* Built from source (1.8.0_251): ok
 - mvn clean install -DskipTests
* Unit tests pass (1.8.0_251): failed
 - mvn package -P runAllTests

[ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 29.212 
s <<< FAILURE! - in org.apache.hadoop.hbase.replication.TestReplicationStatus
[ERROR] 
org.apache.hadoop.hbase.replication.TestReplicationStatus.testReplicationStatusSink
  Time elapsed: 1.016 s  <<< FAILURE!
java.lang.AssertionError: expected:<1592477704810> but was:<1592477719964>
at 
org.apache.hadoop.hbase.replication.TestReplicationStatus.testReplicationStatusSink(TestReplicationStatus.java:134)

After test results, I ran TestReplicationStatus separately on local and it 
passed, checked flaky and nightly dashboards, nightly is all good and flaky 
does't report TestReplicationStatus failures in available builds (at least for 
the past 3 days).
The above failure indicates there are chances few edits are replicated before 
we even insert some data as part of the test.
  //First checks if status of timestamp of last applied op is same as RS 
start, since no edits
  //were replicated yet
  assertEquals(loadSink.getTimestampStarted(), 
loadSink.getTimestampsOfLastAppliedOp());

Anyways, locally this test looks all good. We can't run it in a loop within 
TestReplicationStatus as per the nature of the test, but all separate runs (mvn 
test -Dtest=org.apache.hadoop.hbase.replication.TestReplicationStatus) are 
passing.



On 2020/06/18 06:31:04, 张铎(Duo Zhang)  wrote: 
> +1(binding), thanks for your great work Nick.
> 
> Checked sigs and sums: Matched
> Rat check: Passed
> Run all UTs: Passed. Excellent.
> Compatibility report: Fine, as said above.
> Started a local cluster and
> Checked the Web UI: Nothing strange.
> Then used the client bin and
> Run basic shell command: OK
> Run LTT with read/write 10k rows: Passed
> 
> My only concerns is that, the client-bin is even larger than the bin, 308
> MB vs 260 MB. Is this expected? The main difference is the docs directory,
> in bin it is 65 MB while in client-bin it is 681 MB.
> 
> Thanks.
> 
> 张铎(Duo Zhang)  于2020年6月18日周四 上午9:55写道：
> 
> > I'm still testing but let me post something about the compatibility report
> > first.
> >
> > There is an incompatible item about removing a method from the Admin
> > interface, which should not happen for a minor release.
> >
> > package org.apache.hadoop.hbase.client
> > Admin.snapshotAsync ( SnapshotDescription p1 ) [abstract]  :  void
> >
> > org/apache/hadoop/hbase/client/Admin.snapshotAsync:(Lorg/apache/hadoop/hbase/client/SnapshotDescription;)V
> >
> > Checked the release note and found out that it was done in HBASE-22001, by
> > me...
> > I just changed the return value from void to Future, so the
> > compatibility report tells that the method which returns void has been
> > removed.
> >
> > I think this is fine. We do not guarantee drop in replacement for a minor
> > release, and it will not be a problem if users recompile their code.
> >
> > Thanks.
> >
> > Bharath Vissapragada  于2020年6月18日周四 上午5:17写道：
> >
> >> Thanks. I'm switching my vote to +1.
> >>
> >> - Signatures match (src/bin)
> >> - Checksums match (src/bin)
> >> - Compiled src from scratch
> >> - Ran unit-tests from src (-PrunSmallTests, Java8). No failures
> >> - Started a local mini cluster from compiled-src and bin artifacts and ran
> >> some smoke tests - No issues
> >> - Skimmed through the release notes.
> >>
> >> Thanks Nick for putting together such a high quality release, especially
> >> all the work around docs/test flakes etc.
> >>
> >> On Wed, Jun 17, 2020 at 11:46 AM Nick Dimiduk 
> >> wrote:
> >>
> >> > I have updated the KEYS file with revision 40069.
> >> >
> >> > I have also verified the content of the file on people.apache.org is
> >> up to
> >> > date, https://people.apache.org/keys/committer/ndimiduk.asc
> >> >
> >> > Thanks,
> >> > Nick
> >> >
> >> > On Tue, Jun 16, 2020 at 6:45 PM Nick Dimiduk 
> >> wrote:
> >> >
> >> > > Ah, could be. I did update the expiration date. Let me update the KEYS
> >> > > file and double-check id.a.o.
> >> > >
> >> > > Thanks for the reminder.
> >> > >
> >> > > On Tue, Jun 16, 2020 at 15:39 Bharath Vissapragada <
> >> bhara...@apache.org>
> >> > > wrote:
> >> > >
> >> > >> -1 (binding)
> >> > >>
> >> > >> Looks like your key from the KEYS file has expired?  Per Apache FAQs
> >> > >> , "A
> >> > >> signature is valid, if gpg verifies the .asc as a good signature, and
> >> > >> doesn't complain about expired or revoked keys."
> >> > >>
> >> > >> gpg --verify hbase-2.3.0-src.tar.gz.asc hbase-2.3.0-src.tar.gz
> >> > >> > gpg: Signature made Mon 15 Jun 2020 08:41:19 PM PDT
> >> > >> > gpg:using RSA key
> >> > >> 6EF6CEC74B89B9293B4D9CD0AD9039071C3489BD
> >> > >> > gpg:issuer "ndimi...@apache.or

[jira] [Resolved] (HBASE-24571) HBCK2 fix addFsRegionsMissingInMeta to add regions in CLOSED state again

[Wellington Chevreuil (Jira)]

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

Wellington Chevreuil resolved HBASE-24571.
--
Resolution: Fixed

> HBCK2 fix addFsRegionsMissingInMeta to add regions in CLOSED state again
> 
>
> Key: HBASE-24571
> URL: https://issues.apache.org/jira/browse/HBASE-24571
> Project: HBase
>  Issue Type: Bug
>  Components: hbase-operator-tools
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Major
> Fix For: hbck2 1.1.0
>
>
> Originally, _addFsRegionsMissingInMeta_ relied on _MetaTableAccessor_ to add 
> new regions, which correctly added new regions in CLOSED state. HBASE-23791 
> removed dependency on _MetaTableAccessor_ as to avoid relying on HBase IA 
> private methods. _MetaTableAccessor_ functions needed by HBCK2 were then 
> re-implemented on _HBCKMetaTableAccessor_. Implementation for 
> _addRegionToMeta_, though, was not fully ported, and it was not setting newly 
> added regions state. 
> This would cause attempts to assign the newly added regions to fail, as AM 
> ignore regions without state defined in meta, requiring extra calls for hbck2 
> setRegionState command for each of the newly added regions.
> Kudos for [~brfrn169] who identified this problem while 
> troubleshooting/fixing regions assignments issues with hbck2.
> This PR fix implementation of _HBCKMetaTableAccessor_._addRegionToMeta_ to 
> insert new regions with _CLOSED_ state, and also adds extra checks for this 
> behaviour on both _TestHBCKMetaTableAccessor_ and 
> _TestFsRegionsMetaRecoverer_ UTs.



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