Re: [DISCUSS] releasing hbase-connector 1.1.0 ?
Just go ahead and make the release :) Tak Lon (Stephen) Wu 于2023年10月8日周日 01:48写道： > > we should have a new release.the last round I was asking and it was > blocked by the log4j, it should be fine...now but we need to check again. > > not sure about how normal uses use it, but at our end, we upgrade those > necessary dependencies and run with those connectors. > > if no one would like to do it, I will give a try after the Community over > code. > > Thanks, > Stephen > > On Sat, Oct 7, 2023 at 4:25 AM 张铎(Duo Zhang) wrote: > > > So any updates here? > > > > There are several commits to hbase connectors repo recently. > > > > I wonder how our users will make use of it without a new release... > > > > Reid Chan 于2023年8月4日周五 13:22写道： > > > > > > Seems no upgrade for the release plan > > > > > > hope it could be re-start again > > > > > > --- > > > > > > Best regards, > > > R.C > > > > > > > > > On Wed, Mar 16, 2022 at 6:45 AM Tak Lon (Stephen) Wu > > > wrote: > > > > > > > sorry for the delay, I'm back on this track, > > > > > > > > all the planned tasks for hbase-connector 1.1.0 > > > > https://issues.apache.org/jira/projects/HBASE/versions/12349655 and > > > > hbase-connector 1.0.1 > > > > https://issues.apache.org/jira/projects/HBASE/versions/12345436 have > > > > been completed. > > > > > > > > somehow, I'm wondering if we should fix the log4j issue (replaced with > > > > reload4j?) before a new release, such that I filed > > > > https://github.com/apache/hbase-connectors/pull/94 but I think the > > > > best is to wait till upstream hbase, hadoop and spark-core have fixed > > > > the log4j issue. > > > > > > > > so, if we postpone the release for hbase-connector till then, what do > > you > > > > think? > > > > > > > > Thanks, > > > > Stephen > > > > > > > > On Thu, Dec 9, 2021 at 10:09 AM Tak Lon (Stephen) Wu < > > tak...@apache.org> > > > > wrote: > > > > > > > > > > 1. to Sean's point of "convenience binaries compiled against Spark 3 > > as > > > > > well", sorry that I didn't get your words at the beginning, I will > > make > > > > > sure the 1.1.0 release will have compiled binaries for spark 2 and > > spark > > > > 3 > > > > > (if anything fails spark3, I will file JIRAs for them) > > > > > > > > > > 2. (cont.) update on this thread, HBASE-16247 has been sidelined > > (thanks > > > > > Sean), HBASE-24356 and HBASE-22338 should be the blockers, and let's > > see > > > > > how the communication goes (I may pick up them if needed). > > > > > In addition, I'm proposing to have a 1.1.0 instead of 1.0.1 release, > > and > > > > > move all the removed JIRAs with a fixed version of 1.0.1 to 1.1.0. > > > > > > > > > > I should be actively working on them next week before doing the > > actual > > > > > release. > > > > > > > > > > (sorry that I used a different email in my last reply) > > > > > > > > > > -Stephen > > > > > > > > > > > > > > > On Tue, Dec 7, 2021 at 10:29 AM Stephen Wu > > > > > > > wrote: > > > > > > > > > > > Thanks Sean and Duo for your inputs, I have few questions before we > > > > > > move forward. > > > > > > > > > > > > 1. For Spark 3.0 support, HBASE-25326 seems to already allow > > building > > > > > > it with spark-3.0, or doesn't it work? > > > > > > 2. For the upcoming release version, after reviewing the comments > > on > > > > > > HBASE-26491, I found two pending releases, 1.1.0 (3 overall item, 0 > > > > > > pending issues) and 1.0.1 (46 issues, 3 pending issues, > > HBASE-22338, > > > > > > HBASE-25326, HBASE-16247). should we have a 1.0.1 release? > > > > > > > > > > > > Thanks, > > > > > > Stephen > > > > > > > > > > > > > > > > > > On Tue, Dec 7, 2021 at 12:26 AM 张铎(Duo Zhang) < > > palomino...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > Thank you Tak Lon Wu. This is really a great news. > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/HBASE-26491 > > > > > > > > > > > > > > In this issue, we noticed that the problem has already been fixed > > > > but not > > > > > > > released yet... > > > > > > > > > > > > > > It will be good if we could have a 1.1.0 release soon. > > > > > > > > > > > > > > Sean Busbey 于2021年12月7日周二 07:45写道： > > > > > > > > > > > > > > > That'd be great! > > > > > > > > > > > > > > > > I can help with release process. > > > > > > > > > > > > > > > > I'd like us to ensure this go around we have convenience > > binaries > > > > > > compiled > > > > > > > > against Spark 3 as well. That's been a long standing need. > > > > > > > > > > > > > > > > On Mon, Dec 6, 2021, 16:43 Tak Lon (Stephen) Wu < > > tak...@apache.org > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Hi guys, > > > > > > > > > > > > > > > > > > While I'm learning how to release a minor version of hbase > > via > > > > > > > > > https://hbase.apache.org/book.html#releasing and an example > > of > > > > 2.3.7 > > > > > > > > > via HBASE-26373, I found hbase-connector was last released on > > > > 2019 > > > > > > > > > April. > > > > > > > >
[jira] [Created] (HBASE-28151) hbck -o should not allow bypassing pre transit check by default
Viraj Jasani created HBASE-28151:
Summary: hbck -o should not allow bypassing pre transit check by
default
Key: HBASE-28151
URL: https://issues.apache.org/jira/browse/HBASE-28151
Project: HBase
Issue Type: Improvement
Reporter: Viraj Jasani
When operator uses hbck assigns or unassigns with "-o", the override will also
skip pre transit checks. While this is one of the intentions with "-o", the
primary purpose should still be to only unattach existing procedure from
RegionStateNode so that newly scheduled assign proc can take exclusive region
level lock.
We should restrict bypassing preTransitCheck by only providing it as site
config.
If bypassing preTransitCheck is configured, only then any hbck "-o" should be
allowed to bypass this check, otherwise by default they should go through the
check.
It is important to keep "unset of the procedure from RegionStateNode" and
"bypassing preTransitCheck" separate so that when the cluster state is bad, we
don't explicitly deteriorate it further e.g. if a region was successfully split
and now if operator performs "hbck assigns \{region} -o" and if it bypasses the
transit check, master would bring the region online and it could compact store
files and archive the store file which is referenced by daughter region. This
would not allow daughter region to come online.
Let's introduce hbase site config to allow bypassing preTransitCheck, it should
not be doable only by operator using hbck alone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (HBASE-28150) Too many master region WAL cause HDFS disk space full
chaijunjie created HBASE-28150: -- Summary: Too many master region WAL cause HDFS disk space full Key: HBASE-28150 URL: https://issues.apache.org/jira/browse/HBASE-28150 Project: HBase Issue Type: Improvement Affects Versions: 2.4.14 Reporter: chaijunjie -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28149) move_servers_namespaces_rsgroup is not changing the new rs group in namespace description
Rajeshbabu Chintaguntla created HBASE-28149:
---
Summary: move_servers_namespaces_rsgroup is not changing the new
rs group in namespace description
Key: HBASE-28149
URL: https://issues.apache.org/jira/browse/HBASE-28149
Project: HBase
Issue Type: Improvement
Reporter: Rajeshbabu Chintaguntla
Assignee: Rajeshbabu Chintaguntla
{noformat}
hbase:024:0> list_rsgroups
NAME SERVER / TABLE
rs1 server
hostname2:16020
table hbase:meta
table hbase:acl
table
hbase:namespace
table
hbase:rsgroup
default server
hostname3:16020
table ns_R:ta
tenant_group1
tenant_group server
hostname1:16020
table ns:tb1
table ns:tab
table ns:t2
4 row(s)
Took 0.0129 seconds
hbase:025:0> move_servers_namespaces_rsgroup 'rs1',['hostname1:16020'], ['ns']
Took 0.0302 seconds
hbase:026:0> list_rsgroups
NAME SERVER / TABLE
rs1 server
hostname1:16020
server
hostname2:16020
table ns:tb1
table ns:tab
table hbase:meta
table hbase:acl
table ns:t2
table
hbase:namespace
table
hbase:rsgroup
default server
hostname2:16020
table ns_R:ta
tenant_group1
tenant_group
4 row(s)
Took 0.0140 seconds
hbase:027:0> describe_namespace 'ns'
DESCRIPTION
{NAME => 'ns', hbase.rsgroup.name => 'tenant_group'}
Quota is disabled
Took 0.0093 seconds
hbase:028:0>
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (HBASE-28135) Specify -Xms for tests
[ https://issues.apache.org/jira/browse/HBASE-28135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi resolved HBASE-28135. --- Fix Version/s: 2.6.0 2.4.18 2.5.6 3.0.0-beta-1 Resolution: Fixed Pushed to branch-2.4+. Thanks [~stoty]! > Specify -Xms for tests > -- > > Key: HBASE-28135 > URL: https://issues.apache.org/jira/browse/HBASE-28135 > Project: HBase > Issue Type: Improvement > Components: test >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Fix For: 2.6.0, 2.4.18, 2.5.6, 3.0.0-beta-1 > > > The default -Xms value is JVM dependent, but the host memory size is usually > included in the calculation. > -Xms in turn is used to calculate some GC parameters, for example NewSize and > OldSize, which affect the behaviour of tests. > As the memory consumption on the tests is not dependent on the host VM size, > we could set -Xms for the tests explictly, and enjoy more consistent test > results. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (HBASE-28147) Bump gitpython from 3.1.35 to 3.1.37 in /dev-support/flaky-tests
[ https://issues.apache.org/jira/browse/HBASE-28147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-28147. --- Hadoop Flags: Reviewed Resolution: Fixed Pushed to branch-2.4+. > Bump gitpython from 3.1.35 to 3.1.37 in /dev-support/flaky-tests > > > Key: HBASE-28147 > URL: https://issues.apache.org/jira/browse/HBASE-28147 > Project: HBase > Issue Type: Task > Components: dependabot, scripts, security >Reporter: Duo Zhang >Priority: Major > Fix For: 2.6.0, 2.4.18, 3.0.0-beta-1, 2.5.7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (HBASE-28148) Bump gitpython from 3.1.35 to 3.1.37 in /dev-support/git-jira-release-audit
[ https://issues.apache.org/jira/browse/HBASE-28148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-28148. --- Hadoop Flags: Reviewed Resolution: Fixed Merged to master. > Bump gitpython from 3.1.35 to 3.1.37 in /dev-support/git-jira-release-audit > --- > > Key: HBASE-28148 > URL: https://issues.apache.org/jira/browse/HBASE-28148 > Project: HBase > Issue Type: Task > Components: dependabot, scripts, security >Reporter: Duo Zhang >Priority: Major > Fix For: 4.0.0-alpha-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28148) Bump gitpython from 3.1.35 to 3.1.37 in /dev-support/git-jira-release-audit
Duo Zhang created HBASE-28148: - Summary: Bump gitpython from 3.1.35 to 3.1.37 in /dev-support/git-jira-release-audit Key: HBASE-28148 URL: https://issues.apache.org/jira/browse/HBASE-28148 Project: HBase Issue Type: Task Components: dependabot, scripts, security Reporter: Duo Zhang Fix For: 4.0.0-alpha-1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28147) Bump gitpython from 3.1.35 to 3.1.37 in /dev-support/flaky-tests
Duo Zhang created HBASE-28147: - Summary: Bump gitpython from 3.1.35 to 3.1.37 in /dev-support/flaky-tests Key: HBASE-28147 URL: https://issues.apache.org/jira/browse/HBASE-28147 Project: HBase Issue Type: Task Components: dependabot, scripts, security Reporter: Duo Zhang Fix For: 2.6.0, 2.4.18, 3.0.0-beta-1, 2.5.7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
