+1 on merge from me.
It removes the complicated multi-threaded edifice we'd built client-side to
fake an async behavior replacing it with an actual async implementation.
Users will immediately notice a radical plummet in working thread count on
the client side.
For the cleanup of old idioms
HBASE-21935 tries to automate the generation of RELEASENOTES.md and
CHANGES.md. It has yetus interpolates those that made the current RC (if
new RC, it scrubs the old and regenerates them). It is trying to make the
upkeep of RELEASENOTES and CHANGES painless.
Could do a version of what Duo (and
On Mon, Jun 10, 2019 at 9:08 AM Andrew Purtell
wrote:
> ...How big would a Yetus generated release notes file be if it includes
> changes all the way back to HBASE-1?
>
RELEASENOTES.md in branch-2.0 is almost 500k.
CHANGES.md is coming up on a megabyte.
HBase 2.0 branch has the yetus generated
Zhaobo,
PMC members @Bigtop, they had a talk at the Linaro conf. I hope this helps
you to understand what they have done to support the AArch64[1][2] for
Bigtop.
Thanks,
Youngwoo
1. https://sched.co/LJq5
2. https://www.youtube.com/watch?v=a0acq7zI1wI
On Tue, Jun 11, 2019 at 12:09 PM Youngwoo
No it is just the way it’s been done on branch-1 and going back to 0.x, long
before Yetus was a thing. The practice of using Yetus for change logs in 2.x
releases is an improvement for sure.
On Jun 10, 2019, at 8:08 PM, Guanghao Zhang wrote:
>>
>> We use JIRA’s change log generation feature
Zhaobo,
HBase requires Zookeeper, Hadoop and other libs. As you mentioned,
integration of each component is important.
To solve this problem, We are using test infrastructures and containers for
AArch64[1][2] but Bigtop CI is not for unit test or pre-commit test while
developing the each
>
> We use JIRA’s change log generation feature instead.
>
Do we have any document about this?
Andrew Purtell 于2019年6月11日周二 上午10:44写道：
> We don’t use Yetus to generate release notes in 1.x releases. We use
> JIRA’s change log generation feature instead. There is no overlap in the
> 1.5.0
We don’t use Yetus to generate release notes in 1.x releases. We use JIRA’s
change log generation feature instead. There is no overlap in the 1.5.0 release
candidate changes file. I managed fix versions in JIRA for 1.5.0 for that
purpose if you recall hundreds of fix version updates a couple of
Hi Youngwoo Kim,
Thanks for introducing BitTop, it supports AArch64 ARCH, it contains many
big data and data analytics projects with the specific version. So it can
not to make sure the master Hbase code support ARM ARCH. The stack will
just use the stable project release. That's why I think
[
https://issues.apache.org/jira/browse/HBASE-22160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang reopened HBASE-22160:
Reopened to revert this from branch-2.2. Will commit it again after I roll a
new RC for
[
https://issues.apache.org/jira/browse/HBASE-22116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang reopened HBASE-22116:
Reopened to revert this from branch-2.2. Will commit it again after I roll a
new RC for
[
https://issues.apache.org/jira/browse/HBASE-22550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang reopened HBASE-22550:
---
The problem is still there...
> Do not use Threads.newDaemonThreadFactory in
Hi ZhaoBo,
Apache Bigtop supports the AArch64(arm) architecture since version 1.3.0.
Bigtop is not a CI for the software stack but a distribution of open source
software for big data and data analytics.
Folks from Linaro are contributing to Bigtop to support ARM architecture
for the stack
https://issues.apache.org/jira/browse/HBASE-21512
"Reimplement sync client based on async client"
The jira title tells everything. This is what I promised when I first
introduced the async client in HBase, about three years ago, that the sync
client can be implemented on top of the async client,
HBASE-22160 and HBASE-22116 are new features, I think you can revert them
first, and then tag the RC6, and then re-apply them so we could make 2.2.0
out soon.
Guanghao Zhang 于2019年6月11日周二 上午9:35写道：
> Checked the recent commits in
>
>
Hi, Jean
Thanks for reply. I try to compile and build HBASE master on ARM, (not
success easily as hit protobuf-2.5.0 didn't have a arm release.) And I test
HBASE on ARM, it works fine.
The reason I post the issue in JIRA(
https://issues.apache.org/jira/browse/HBASE-22468) is proposing a ARM
Checked the recent commits in
https://gitbox.apache.org/repos/asf?p=hbase.git;a=shortlog;h=refs/heads/branch-2.2.
I thought there are no critical changes since 2.2.0RC5.
张铎(Duo Zhang) 于2019年6月11日周二 上午9:08写道：
> Are there any critical changes recently?
>
> Guanghao Zhang 于2019年6月11日周二 上午8:54写道：
We used to have a build step that compressed our logs for us. I don't think
Jenkins can read the test results if we do the xml files from surefire, so
I'm not sure how much space we can save. That's where I'd start though.
On Mon, Jun 10, 2019, 19:46 张铎(Duo Zhang) wrote:
> Does surefire have
Are there any critical changes recently?
Guanghao Zhang 于2019年6月11日周二 上午8:54写道：
> >
> > The only RN is on HBASE-21075, which
> > does not carry a fix version of 2.2.0.
> >
> HBASE-21075 is only committed to branch-2.0 and branch-2.1. It is a issue
> for 2.0 and 2.1, not for 2.2. So the fix
[
https://issues.apache.org/jira/browse/HBASE-21970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang resolved HBASE-21970.
Resolution: Fixed
Release Note:
Upgrade from 2.0 or 2.1 to 2.2+
[
https://issues.apache.org/jira/browse/HBASE-21970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang reopened HBASE-21970:
Reopen to update the release note.
> Document that how to upgrade from 2.0 or 2.1 to 2.2+
>
>
> The only RN is on HBASE-21075, which
> does not carry a fix version of 2.2.0.
>
HBASE-21075 is only committed to branch-2.0 and branch-2.1. It is a issue
for 2.0 and 2.1, not for 2.2. So the fix version didn't contains 2.2.0.
Two possible fixes: add 2.2.0
> as a fixversion for HBASE-21075, or
Does surefire have some options to truncate the test output if it is too
large? Or jenkins has some options to truncate or compress a file when
archiving?
Josh Elser 于2019年6月11日周二 上午8:40写道：
> Just a cursory glance at some build artifacts showed just test output
> which sometimes extended into
>
> The change log there is based on the 1.4.9 one and contains everyone later
> than 1.4.9 or new to 1.5.0.
>
So only generate the release note of 1.5.0 and append it to 1.4.9's release
note, then get a new release note for 1.5.0? If I am not wrong, the yetus
use issue's fix version to generate
Just a cursory glance at some build artifacts showed just test output
which sometimes extended into the multiple megabytes.
So everyone else knows, I just chatted with ChrisL in Slack and he
confirmed that our disk utilization is down already (after HBASE-22563).
He thanked us for the quick
Oh, it is the build artifacts, not the jars...
Most of our build artifacts are build logs, but maybe the problem is that
some of the logs are very large if the test hangs...
张铎(Duo Zhang) 于2019年6月11日周二 上午8:16写道：
> For flakey we just need the commit id in the console output then we can
> build
Maybe we could add a note at the bottom of the release note for each minor
release line, to mention that this release line contains all the changes in
the previous minor or major release?
For example, 2.1.0 contains all the changes in 2.0.0, and 2.0.0 contains
all the changes in 1.0.0. If users
Maybe we could amend the release note for HBASE-21075 to HBASE-20881? Or at
least reference HBASE-21075 in the release note for HBASE-20881? If this is
OK, I think we could make a RC6 with the release note change and give it a
one day vote window, if no objections we can push the release out.
Keeping artifacts and keeping build logs are two separate things. I don’t
see a need to keep any artifacts past the most recent green and most recent
red builds. Alternately if we need the artifacts let’s have Jenkins put
them somewhere rather than keeping them there. You can get back to whatever
That explains my machine shut down while testing.
On Mon, Jun 10, 2019, 5:57 PM Andrew Purtell wrote:
> +1
>
> Sums and signatures: ok
>
> RAT check passes: ok
>
> Built from source: ok
>
> Unit tests pass: no, several failures: TestClusterScopeQuotaThrottle
> (timeout),
+1
Sums and signatures: ok
RAT check passes: ok
Built from source: ok
Unit tests pass: no, several failures: TestClusterScopeQuotaThrottle
(timeout), TestEndToEndSplitTransaction (RetriesExhaustedException),
TestRegionMoveAndAbandon (RetriesExhaustedException and
ConnectTimeoutException),
https://issues.apache.org/jira/browse/HBASE-22563 for a quick bandaid (I
hope).
On 6/10/19 4:31 PM, Josh Elser wrote:
Eyes on.
Looking at master, we already have the linked configuration, set to
retain 30 builds.
We have some extra branches which we can lop off (branch-1.2,
branch-2.0,
Eyes on.
Looking at master, we already have the linked configuration, set to
retain 30 builds.
We have some extra branches which we can lop off (branch-1.2,
branch-2.0, maybe some feature branches too). A quick fix might be to
just pull back that 30 to 10.
Largely figuring out how this
Josh Elser created HBASE-22562:
--
Summary: PressureAwareThroughputController#skipControl never
invoked
Key: HBASE-22562
URL: https://issues.apache.org/jira/browse/HBASE-22562
Project: HBase
With five binding +1s including my own, four non-binding +1s, and no 0 or
-1 votes, this vote passes.
Thank you to all who voted on the release candidate!
On Wed, Jun 5, 2019 at 5:11 PM Andrew Purtell wrote:
> The second HBase 1.4.10 release candidate (RC1) is available for download
> at
>
With four binding +1s, including my own, three nonbinding +1s, and no 0 or
-1 votes, this vote passes.
Thank you to all who voted on the release candidate!
Per Jan's suggestion I cherry picked HBASE-18813 to branch-1.3 and it will
be included in a future 1.3 release.
On Wed, Jun 5, 2019 at
+1
- Build from source: OK
- Tests run, 160: OK
- Checksums and signatures: OK
- RAT: OK
--
Cloudera, Inc.
On Mon, Jun 10, 2019 at 2:08 PM Andrew Purtell wrote:
> +1
>
> Sums and signatures ok
> Built from source, ok
> RAT check passes
> Tests pass, Hadoop 2
> Tests pass, Hadoop 3
>
>
> On
+1
Sums and signatures ok
Built from source, ok
RAT check passes
Tests pass, Hadoop 2
Tests pass, Hadoop 3
On Fri, Jun 7, 2019 at 7:25 AM Wellington Chevreuil <
wellington.chevre...@gmail.com> wrote:
> Please vote on this first HBase FileSystem 1.0.0-alpha1 release candidate.
>
> The release
Hi,
HBase jobs are using more than 400GB based on this list.
Could someone take a look at the job configurations today? Otherwise, I
will look into it tomorrow morning.
Thanks,
Peter
-- Forwarded message -
From: Chris Lambertus
Date: Mon, Jun 10, 2019 at 7:57 PM
Subject: ACTION
Artem Ervits created HBASE-22561:
Summary: modify HFilePrettyPrinter to accept non-root.dir
directories
Key: HBASE-22561
URL: https://issues.apache.org/jira/browse/HBASE-22561
Project: HBase
Josh Elser created HBASE-22560:
--
Summary: Upgrade to Jetty 9.3.latest and Jackson 2.9.latest
Key: HBASE-22560
URL: https://issues.apache.org/jira/browse/HBASE-22560
Project: HBase
Issue Type:
+1 (non-binding)
- Hash, change log & release notes look good
- Rat check on clean tarball passes
- Contents looks correct
- Tests pass as expected with all profiles
On 2019/06/07 14:24:50, Wellington Chevreuil wrote:
> Please vote on this first HBase FileSystem 1.0.0-alpha1 release
candidate.>
-1
(reminder that -1s are not vetos on release votes)
bad:
* Release notes still have no call out / warning for folks about the
procedure needed to doing a rolling upgrade from earlier versions due
to the changes in HBASE-20881. The only RN is on HBASE-21075, which
does not carry a fix version of
1.5.0 will continue the practice. The change log there is based on the 1.4.9
one and contains everyone later than 1.4.9 or new to 1.5.0.
The branch-1 releases use the old practice of JIRA generated change logs, not
the far more verbose Yetus ones, and even then a list of objects ordered by
+1 (binding)
On Wed, Jun 5, 2019 at 7:11 PM Andrew Purtell wrote:
>
> The second HBase 1.4.10 release candidate (RC1) is available for download at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.10RC1/ and Maven
> artifacts are available in the temporary repository
>
+1 (binding)
* sigs/xsums good
* KEYS updated
* L seems kosher (both in src and generated JAR)
* apache-rat:check passes, exclusions reasonable (non, extra)
* Can build from src
* Tests pass! (on hadoop2 and 3)
On 6/7/19 10:24 AM, Wellington Chevreuil wrote:
Please vote on this first HBase
+1 (binding)
On Wed, Jun 5, 2019 at 7:07 PM Andrew Purtell wrote:
>
> The first HBase 1.3.5 release candidate (RC0) is available for download at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.5RC0/ and Maven
> artifacts are available in the temporary repository
>
+1 (non-binding)
used a modified version of hbase-vote script
* Signature: ok
* Checksum : ok
* Rat check (1.8.0_212): ok
- mvn clean apache-rat:check
* Built from source (1.8.0_212): ok
- mvn clean install -DskipTests
* Unit tests pass
Agree with Duo. I think changes in that minor release line are the most
meaningful to users without being too much of a burden for devs.
On 6/10/19 11:06 AM, 张铎(Duo Zhang) wrote:
I prefer we include all the diffs in this minor release line in the
CHANGES.md. For example, 2.1.1 will also
+1 (binding)
On 6/6/19 11:56 AM, Andrew Purtell wrote:
The dist URL is https://dist.apache.org/repos/dist/dev/hbase/1.3.5RC0/
On Jun 5, 2019, at 5:06 PM, Andrew Purtell wrote:
The first HBase 1.3.5 release candidate (RC0) is available for download at
+1 (binding)
On 6/6/19 11:56 AM, Andrew Purtell wrote:
The dist URL is https://dist.apache.org/repos/dist/dev/hbase/1.4.10RC1/
On Jun 5, 2019, at 5:11 PM, Andrew Purtell wrote:
The second HBase 1.4.10 release candidate (RC1) is available for download at
On Mon, Jun 10, 2019 at 8:05 AM Sean Busbey wrote:
> Back for the 1.2 release line I tried to include enough information
> that someone looking at the given 1.2 release coming from the prior
> major version would have everything.
>
> That meant:
>
> * 1.0.0 release notes
> * 1.1.0 release notes
I prefer we include all the diffs in this minor release line in the
CHANGES.md. For example, 2.1.1 will also contains the contents for 2.1.0.
But I do not think it is necessary to contain all the changes from the
beginning, it will be too large...
Stack 于2019年6月10日周一 下午10:54写道：
> I was under
Back for the 1.2 release line I tried to include enough information
that someone looking at the given 1.2 release coming from the prior
major version would have everything.
That meant:
* 1.0.0 release notes
* 1.1.0 release notes
* 1.2.z (for all z 0-12) release notes
On Mon, Jun 10, 2019 at 2:12 AM Guanghao Zhang wrote:
> >
> > We usually
> > aggregate them so the release notes has all release notes for all
> releases
> > (see 2.1.x releases).
> >
> I checked the release notes for branch-2.1. It only contains the issues for
> 2.1.*. So for 2.2.0, it should
I was under the impression that our CHANGES.md was a list of all changes
since the beginning of time but branch-2.2 only has 2.2.0 changes and
Guanghao points out that hbase-2.1 releases have CHANGES only since 2.1.0
(I'm RM on branch-2.1).
I see Sean say in another thread says
"Historically
+1 (binding)
* confirmed source artifact matches contents of the signed tag
"1.0.0-alpha1-RC0" which points at 2a6e8ce6cdb53ed78c908daf7f244dbb9e3d53eb
* confirmed source artifact on dist.a.o has proper signature and checksum
* confirmed staged maven repository has proper signature and checksum
Hi,
As long as you have a Java VM, it should work, no? Did you give it a try?
If you did, what kind of issues did you face? Were looking to get the
client running? Or the entire HBase cluster? I saw on the web someone
running an HDFS cluster on Raspberry Pi. So I guess HBase should work fine
too?
Reid Chan created HBASE-22559:
-
Summary: [RPC] set guard against CALL_QUEUE_HANDLER_FACTOR_CONF_KEY
Key: HBASE-22559
URL: https://issues.apache.org/jira/browse/HBASE-22559
Project: HBase
Issue
[
https://issues.apache.org/jira/browse/HBASE-22183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wellington Chevreuil resolved HBASE-22183.
--
Resolution: Fixed
> [hbck2] Update hbck2 README to explain new
>
> We usually
> aggregate them so the release notes has all release notes for all releases
> (see 2.1.x releases).
>
I checked the release notes for branch-2.1. It only contains the issues for
2.1.*. So for 2.2.0, it should only contain the issues for 2.2.0?
张铎(Duo Zhang) 于2019年6月9日周日 下午8:43写道：
Hi guys,
My name is ZhaoBo, a member from OpenLab CI Team, I had post a issue [1]
several days ago.
The reason to do this is for the ARM eco-system and make Hbase can be run
on more devices.
So I wish our HBASE core team members can leave some comments or
suggestions on it.
Thank you very much.
[
https://issues.apache.org/jira/browse/HBASE-22552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-22552.
---
Resolution: Fixed
Assignee: Duo Zhang
Hadoop Flags: Reviewed
Pushed to branch-2.2+.
63 matches
Mail list logo
