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)