Duo Zhang created HBASE-23933:
-
Summary: Separate an hbase-balancer or hbase-assignment module
Key: HBASE-23933
URL: https://issues.apache.org/jira/browse/HBASE-23933
Project: HBase
Issue Type:
[
https://issues.apache.org/jira/browse/HBASE-23931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Stack resolved HBASE-23931.
---
Resolution: Cannot Reproduce
Resolving as incomplete for the moment.
Merge should be
>
> I took a look at master branch. Its not in same state as branch-2. Looking
> at nightlies, it seems a bit worse, I see backup tests failing (we don't
> have this in branch-2).
>
The backup ut may related to HBASE-23912. Let me take a look.
Stack 于2020年3月5日周四 上午8:06写道：
> On Wed, Mar 4, 2020
Nick Dimiduk created HBASE-23932:
Summary: Region Normalizer is disruptive while running hbck2 fix
meta
Key: HBASE-23932
URL: https://issues.apache.org/jira/browse/HBASE-23932
Project: HBase
[
https://issues.apache.org/jira/browse/HBASE-23926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Stack resolved HBASE-23926.
---
Fix Version/s: 2.3.0
3.0.0
Resolution: Fixed
Attached what I
On Wed, Mar 4, 2020 at 3:24 PM 张铎(Duo Zhang) wrote:
> OK, let's keep an eye on the flaky list of master and branch-2 till this
> weekend.
>
> If it is in a bad state then let's discussion again.
>
>
Agree.
On the rerunning of flakies, I downed the ferocity. It was NOT 0.5C as I'd
thought but
Oh missed the last part
>
> IMHO, we already treat master as the "dev complete"
> branch, so what's the benefit of doing so also with branch-2?
>
This is because of our release model. We consider master and 3.0.0. That
exactly matches the semantic versioning, master is for the next major
release
Nick Dimiduk 于2020年3月5日周四 上午12:44写道：
> > What will be the criterion for a new patch release with this model?
>
> From my previous RM experience, I really liked the process of the RM coming
> around once/month, check the branch for activity, and if there's enough
> fixes to justify, do a release.
Michael Stack created HBASE-23931:
-
Summary: CatalogJanitor consistency check adds merging regions to
orphan list (tooo)
Key: HBASE-23931
URL: https://issues.apache.org/jira/browse/HBASE-23931
OK, let's keep an eye on the flaky list of master and branch-2 till this
weekend.
If it is in a bad state then let's discussion again.
Stack 于2020年3月5日周四 上午12:41写道：
> On Wed, Mar 4, 2020 at 3:42 AM 张铎(Duo Zhang)
> wrote:
>
> > And speak a little more on increasing the forkCount. In fact, the
Nick Dimiduk created HBASE-23930:
Summary: Shell should attempt to format `timestamp` attributes as
ISO-8601
Key: HBASE-23930
URL: https://issues.apache.org/jira/browse/HBASE-23930
Project: HBase
Nick Dimiduk created HBASE-23929:
Summary: Shell formatter for for meta table should pretty-print
values of info:merge columns
Key: HBASE-23929
URL: https://issues.apache.org/jira/browse/HBASE-23929
Nick Dimiduk created HBASE-23928:
Summary: Add hbck2 command to "completebulkload" a batch of
orphaned regions
Key: HBASE-23928
URL: https://issues.apache.org/jira/browse/HBASE-23928
Project: HBase
Nick Dimiduk created HBASE-23927:
Summary: hbck2 assigns command should accept a file containing a
list of region names
Key: HBASE-23927
URL: https://issues.apache.org/jira/browse/HBASE-23927
Heya,
I want to send a head's up for those not following along the efforts toward
2.3.x and the thread "[DISCUSS] Drop support for code contribution via Jira
attached patch". The summary is outlined at the end of that thread, but to
copy over here.
> I'm going to disable the Jira PreCommit job
> If it is not easy to add JDK11 support for the PreCommit-HBASE-Build job
then I'm +1 with stopping it.
It's a bit of work to bring Jira PreCommit up to feature parity with GitHub
PreCommit, especially seeing the work that was necessary to get GitHub
PreCommit to do JDK11. From what I can tell,
Michael Stack created HBASE-23926:
-
Summary: [Flakey Tests] Down the flakies re-run ferocity; it makes
for too many fails.
Key: HBASE-23926
URL: https://issues.apache.org/jira/browse/HBASE-23926
> What will be the criterion for a new patch release with this model?
>From my previous RM experience, I really liked the process of the RM coming
around once/month, check the branch for activity, and if there's enough
fixes to justify, do a release. In my proposed model, that monthly cadence
On Wed, Mar 4, 2020 at 3:34 AM 张铎(Duo Zhang) wrote:
> Due to the resource limit I do not think it is a good idea to increase the
> forkCount...
>
>
Which fork count are you referring too? The fork count is about what it
always was after doing the math just that now we size based off the machine
On Wed, Mar 4, 2020 at 3:42 AM 张铎(Duo Zhang) wrote:
> And speak a little more on increasing the forkCount. In fact, the test
> category is not too rough. The LargeTests just means the test will run a
> bit long, does not mean it will consume more resources. Maybe the tests
> just have lots of
[
https://issues.apache.org/jira/browse/HBASE-23791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wellington Chevreuil resolved HBASE-23791.
--
Resolution: Fixed
> [operator tools] Remove reference to I.A. Private
Ok.
If there are no objections I will remove the 1.5.0 release from dist/ when
I send out the announcement regarding 1.6.0. I'll wait one day in case
there are any additional responses here.
On Tue, Mar 3, 2020 at 8:56 AM Sean Busbey wrote:
> The older releases are still easily gotten from
And speak a little more on increasing the forkCount. In fact, the test
category is not too rough. The LargeTests just means the test will run a
bit long, does not mean it will consume more resources. Maybe the tests
just have lots of Thread.sleep so we declare it as LargeTests.
What I can see is
Due to the resource limit I do not think it is a good idea to increase the
forkCount...
FWIW, can we do this on a feature branch and move master and branch-2 back?
See here
https://github.com/apache/hbase/pull/1221
We tried several times and always got a large amount of failed UTs which
are
24 matches
Mail list logo
