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 <vjas...@apache.org> 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) <palomino...@gmail.com> 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) <palomino...@gmail.com> 于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<Void>, 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 <bhara...@apache.org> 于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 <ndimi...@apache.org> > > >> 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 <ndimi...@apache.org> > > >> 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 > > >> > >> <https://infra.apache.org/release-signing#verifying-signature>, > "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 <ndimi...@apache.org>" > > >> > [expired] > > >> > >> > gpg: aka "Nick Dimiduk <ndimi...@gmail.com>" > > >> > [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 < > ndimi...@apache.org> > > >> > 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 > > >> > >> > > > >> > >> > > >> > > > > >> > > > >> > > > > > >
