[jira] [Created] (HBASE-25273) fix typo in StripeStoreFileManager java doc
Hossein Zolfi created HBASE-25273: - Summary: fix typo in StripeStoreFileManager java doc Key: HBASE-25273 URL: https://issues.apache.org/jira/browse/HBASE-25273 Project: HBase Issue Type: Improvement Reporter: Hossein Zolfi See StripeCompactionPolicy on how the stripes are determined; this class doesn't care. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25269) [hbase-thirdparty] Set version as 3.4.1 in prep for first RC
[ https://issues.apache.org/jira/browse/HBASE-25269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-25269. --- Fix Version/s: thirdpart-3.4.1 Hadoop Flags: Reviewed Assignee: Duo Zhang Resolution: Fixed Merged to master. Thanks [~zghao] for reviewing. > [hbase-thirdparty] Set version as 3.4.1 in prep for first RC > > > Key: HBASE-25269 > URL: https://issues.apache.org/jira/browse/HBASE-25269 > Project: HBase > Issue Type: Sub-task > Components: thirdparty >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: thirdpart-3.4.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25272) Support scan on a specific replica
Duo Zhang created HBASE-25272: - Summary: Support scan on a specific replica Key: HBASE-25272 URL: https://issues.apache.org/jira/browse/HBASE-25272 Project: HBase Issue Type: Improvement Components: Client, scan Reporter: Duo Zhang Assignee: Duo Zhang Fix For: 2.4.0 This is a missing part of the client library for sync client on branch-2, and it is necessary when implementing meta replicas read. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25269) [hbase-thirdparty] Set version as 3.4.1 in prep for first RC
Duo Zhang created HBASE-25269: - Summary: [hbase-thirdparty] Set version as 3.4.1 in prep for first RC Key: HBASE-25269 URL: https://issues.apache.org/jira/browse/HBASE-25269 Project: HBase Issue Type: Sub-task Components: thirdparty Reporter: Duo Zhang -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25270) [hbase-thirdparty] Generate CHANGES.md and RELEASENOTES.md for 3.4.1
Duo Zhang created HBASE-25270: - Summary: [hbase-thirdparty] Generate CHANGES.md and RELEASENOTES.md for 3.4.1 Key: HBASE-25270 URL: https://issues.apache.org/jira/browse/HBASE-25270 Project: HBase Issue Type: Sub-task Components: thirdparty Reporter: Duo Zhang -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25271) [hbase-thirdarty] Put up 3.4.0RC1
Duo Zhang created HBASE-25271: - Summary: [hbase-thirdarty] Put up 3.4.0RC1 Key: HBASE-25271 URL: https://issues.apache.org/jira/browse/HBASE-25271 Project: HBase Issue Type: Sub-task Reporter: Duo Zhang -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25268) [hbase-thirdparty] Release 3.4.1
Duo Zhang created HBASE-25268: - Summary: [hbase-thirdparty] Release 3.4.1 Key: HBASE-25268 URL: https://issues.apache.org/jira/browse/HBASE-25268 Project: HBase Issue Type: Umbrella Reporter: Duo Zhang -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25265) [hbase-thirdparty] Bump dependencis in hbase-thirdparty
[ https://issues.apache.org/jira/browse/HBASE-25265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-25265. --- Hadoop Flags: Reviewed Resolution: Fixed Merged to master. Thanks [~GeorryHuang] for contributing. > [hbase-thirdparty] Bump dependencis in hbase-thirdparty > --- > > Key: HBASE-25265 > URL: https://issues.apache.org/jira/browse/HBASE-25265 > Project: HBase > Issue Type: Task > Components: dependencies, hbase-thirdparty >Reporter: Duo Zhang >Assignee: Zhuoyue Huang >Priority: Major > Fix For: thirdpart-3.4.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25264) [hbase-thirdparty] Update jersey version in hbase-thirdparty
[ https://issues.apache.org/jira/browse/HBASE-25264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-25264. --- Hadoop Flags: Reviewed Resolution: Fixed Merged to master. Thanks [~GeorryHuang] for contributing. > [hbase-thirdparty] Update jersey version in hbase-thirdparty > > > Key: HBASE-25264 > URL: https://issues.apache.org/jira/browse/HBASE-25264 > Project: HBase > Issue Type: Task > Components: dependencies, hbase-thirdparty >Reporter: Duo Zhang >Assignee: Zhuoyue Huang >Priority: Major > Fix For: thirdpart-3.4.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
+1 on what Sean proposed to include the changes started from the first major release. Sean Busbey 于2020年11月10日周二 下午7:37写道： > I thought we had written up a guide before for what goes in the changes > file, but I can't find it at the moment. > > For branch 2.3 I am surprised at 0.99 stuff. I would expect: > > * 2.0.0 > * 2.1.0 > * 2.2.0 > * 2.3.[0-z] > > Because that would be enough that if I was coming from the prior major > release I could see everything that might matter getting to the release. > > If we just include 2.3.z changes then I have to go look at each of the > previous minor releases on the release line as well. > > We've talked for some time about possibly including release notes / changes > for just those things in each individual release on the website before. > Would adding something like that be sufficient for the use you're thinking > of? > > > > > On Mon, Nov 9, 2020, 15:35 Nick Dimiduk wrote: > > > Heya, > > > > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big > for > > Github to render. Its content covers back to 0.99. This isn't really > usable > > by someone who wants to easily see what's new in the latest patch > release. > > > > I propose we truncate these changes files to what's new for the release > > branch. It probably needs some more work, but the git-jira audit script > [0] > > is able to generate a report of what's new (never previously released) > for > > a target release-line branch. We could use this as the basis for the > > CHANGES file when starting a new release-line branch. From then on, Yetus > > takes care of the patch release updates. > > > > What do you think? > > > > Thanks, > > Nick > > > > [0]: > > > > > https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit > > >
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
On Tue, Nov 10, 2020 at 3:37 AM Sean Busbey wrote: > We've talked for some time about possibly including release notes / changes > for just those things in each individual release on the website before. > Would adding something like that be sufficient for the use you're thinking > of? > Having a page on the site dedicated to this would suit my needs, but maybe it's overkill if we can just "get it right" for the release tags visible on github. My objective is giving a user-friendly and self-service answer to an operator or developer asking, "why should I upgrade? / what's new in this release?" The existing CHANGES.md file on the release tag would work, except that the markdown doesn't render on Github due to size. On Mon, Nov 9, 2020, 15:35 Nick Dimiduk wrote: > > > Heya, > > > > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big > for > > Github to render. Its content covers back to 0.99. This isn't really > usable > > by someone who wants to easily see what's new in the latest patch > release. > > > > I propose we truncate these changes files to what's new for the release > > branch. It probably needs some more work, but the git-jira audit script > [0] > > is able to generate a report of what's new (never previously released) > for > > a target release-line branch. We could use this as the basis for the > > CHANGES file when starting a new release-line branch. From then on, Yetus > > takes care of the patch release updates. > > > > What do you think? > > > > Thanks, > > Nick > > > > [0]: > > > > > https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit > > >
Failure: HBase Generate Website
Build status: FAILURE The HBase website has not been updated to incorporate recent HBase changes. See https://ci-hadoop.apache.org/job/HBase/job/hbase_generate_website/89/console
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Idea was CHANGEs.md + RELEASENOTES.md would have all changes listed, not some subset, per Seans' text diagram. Should be accumulative. The build scripts take care of making the new additions for you. If the files have become large, lets add links to files that list changes <1.0.0 and then changes between 1.0.0 and 2.0.0 on the tail of these files? S On Tue, Nov 10, 2020 at 3:37 AM Sean Busbey wrote: > I thought we had written up a guide before for what goes in the changes > file, but I can't find it at the moment. > > For branch 2.3 I am surprised at 0.99 stuff. I would expect: > > * 2.0.0 > * 2.1.0 > * 2.2.0 > * 2.3.[0-z] > > Because that would be enough that if I was coming from the prior major > release I could see everything that might matter getting to the release. > > If we just include 2.3.z changes then I have to go look at each of the > previous minor releases on the release line as well. > > We've talked for some time about possibly including release notes / changes > for just those things in each individual release on the website before. > Would adding something like that be sufficient for the use you're thinking > of? > > > > > On Mon, Nov 9, 2020, 15:35 Nick Dimiduk wrote: > > > Heya, > > > > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big > for > > Github to render. Its content covers back to 0.99. This isn't really > usable > > by someone who wants to easily see what's new in the latest patch > release. > > > > I propose we truncate these changes files to what's new for the release > > branch. It probably needs some more work, but the git-jira audit script > [0] > > is able to generate a report of what's new (never previously released) > for > > a target release-line branch. We could use this as the basis for the > > CHANGES file when starting a new release-line branch. From then on, Yetus > > takes care of the patch release updates. > > > > What do you think? > > > > Thanks, > > Nick > > > > [0]: > > > > > https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit > > >
[jira] [Created] (HBASE-25267) Make SSL keystore type configurable in HBase RESTServer
Mate Szalay-Beko created HBASE-25267:
Summary: Make SSL keystore type configurable in HBase RESTServer
Key: HBASE-25267
URL: https://issues.apache.org/jira/browse/HBASE-25267
Project: HBase
Issue Type: Improvement
Components: REST
Reporter: Mate Szalay-Beko
Assignee: Mate Szalay-Beko
The keystore configuration of the RESTServer currently relies on the following
parameters to configure SSL:
* hbase.rest.ssl.enabled
* hbase.rest.ssl.keystore.store
* hbase.rest.ssl.keystore.password
* hbase.rest.ssl.keystore.keypassword
* hbase.rest.ssl.exclude.cipher.suites
* hbase.rest.ssl.include.cipher.suites
* hbase.rest.ssl.exclude.protocols
* hbase.rest.ssl.include.protocols
In this patch I want to introduce the {{hbase.rest.ssl.keystore.type}}
parameter, enabling us to customize the keystore type for the REST server. If
the parameter is not provided, then we should fall-back to the current
behaviour (which assumes keystore type JKS).
(this is similar how we already do in the InfoServer with the
\{{ssl.server.keystore.type}} parameter)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (HBASE-25266) [hbase-operator-tools] Add a repair tool for moving stale regions dir not present in meta away from table dir
Wellington Chevreuil created HBASE-25266: Summary: [hbase-operator-tools] Add a repair tool for moving stale regions dir not present in meta away from table dir Key: HBASE-25266 URL: https://issues.apache.org/jira/browse/HBASE-25266 Project: HBase Issue Type: New Feature Reporter: Wellington Chevreuil Assignee: Wellington Chevreuil This adds a new tool under *hbase-tools* module, that allows for moving aways regions dirs existing under table's hdfs dir, but not in meta. This is useful in cases where the region is not present in meta, but still has data on hdfs, yet no holes in the table region chain is detected. On such cases, the existing *HBCK2 addFsRegionsMissingInMeta* command isn't ideal, as it would bring the region back in meta and cause overlaps. This tool performs the following actions: 1) Identifies regions in hdfs but not in meta using *HBCK2.reportTablesWithMissingRegionsInMeta*; 2) For each of these regions, sidelines the related dir to a temp folder; 3) Bulkload hfiles from each sidelined region to the related table; Sidelined regions are never removed from temp folder. Operators should remove those manually, after they certified on data integrity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
I thought we had written up a guide before for what goes in the changes file, but I can't find it at the moment. For branch 2.3 I am surprised at 0.99 stuff. I would expect: * 2.0.0 * 2.1.0 * 2.2.0 * 2.3.[0-z] Because that would be enough that if I was coming from the prior major release I could see everything that might matter getting to the release. If we just include 2.3.z changes then I have to go look at each of the previous minor releases on the release line as well. We've talked for some time about possibly including release notes / changes for just those things in each individual release on the website before. Would adding something like that be sufficient for the use you're thinking of? On Mon, Nov 9, 2020, 15:35 Nick Dimiduk wrote: > Heya, > > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big for > Github to render. Its content covers back to 0.99. This isn't really usable > by someone who wants to easily see what's new in the latest patch release. > > I propose we truncate these changes files to what's new for the release > branch. It probably needs some more work, but the git-jira audit script [0] > is able to generate a report of what's new (never previously released) for > a target release-line branch. We could use this as the basis for the > CHANGES file when starting a new release-line branch. From then on, Yetus > takes care of the patch release updates. > > What do you think? > > Thanks, > Nick > > [0]: > > https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit >
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
+1 for restricting CHANGES.md contents with what’s new after latest release on the respective release line. On Tue, 10 Nov 2020 at 3:05 AM, Nick Dimiduk wrote: > Heya, > > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big for > Github to render. Its content covers back to 0.99. This isn't really usable > by someone who wants to easily see what's new in the latest patch release. > > I propose we truncate these changes files to what's new for the release > branch. It probably needs some more work, but the git-jira audit script [0] > is able to generate a report of what's new (never previously released) for > a target release-line branch. We could use this as the basis for the > CHANGES file when starting a new release-line branch. From then on, Yetus > takes care of the patch release updates. > > What do you think? > > Thanks, > Nick > > [0]: > > https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit >
[jira] [Created] (HBASE-25265) [hbase-thirdparty] Bump dependencis in hbase-thirdparty
Duo Zhang created HBASE-25265: - Summary: [hbase-thirdparty] Bump dependencis in hbase-thirdparty Key: HBASE-25265 URL: https://issues.apache.org/jira/browse/HBASE-25265 Project: HBase Issue Type: Task Components: dependencies, hbase-thirdparty Reporter: Duo Zhang -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25264) [hbase-thirdparty] Upgrade jersey to 2.32
Duo Zhang created HBASE-25264: - Summary: [hbase-thirdparty] Upgrade jersey to 2.32 Key: HBASE-25264 URL: https://issues.apache.org/jira/browse/HBASE-25264 Project: HBase Issue Type: Task Components: dependencies, hbase-thirdparty Reporter: Duo Zhang Fix For: thirdpart-3.4.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25262) [hbase-thirdparty] Update jetty version in hbase-thirdparty
[ https://issues.apache.org/jira/browse/HBASE-25262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-25262. --- Hadoop Flags: Reviewed Resolution: Fixed Merged to master. Thanks [~weichiu] for contributing. > [hbase-thirdparty] Update jetty version in hbase-thirdparty > --- > > Key: HBASE-25262 > URL: https://issues.apache.org/jira/browse/HBASE-25262 > Project: HBase > Issue Type: Improvement > Components: hbase-thirdparty >Reporter: Wei-Chiu Chuang >Assignee: Wei-Chiu Chuang >Priority: Major > Fix For: thirdpart-3.4.1 > > > The master branch of hbase-thirdparty is on Jetty 9.4.31. The latest 9.4.x is > Jetty 9.4.34. We should update to the latest. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25263) Change encryption key generation algorithm used in the HBase shell
Mate Szalay-Beko created HBASE-25263: Summary: Change encryption key generation algorithm used in the HBase shell Key: HBASE-25263 URL: https://issues.apache.org/jira/browse/HBASE-25263 Project: HBase Issue Type: Improvement Components: encryption, shell Reporter: Mate Szalay-Beko Assignee: Mate Szalay-Beko This ticket is a follow-up of HBASE-25181, where several issues were discussed on the PR: 1. Currently we use `PBKDF2WithHmacSHA1` key generation algorithm to generate a secret key for HFile / WalFile encryption, when the user is defining a string encryption key in the hbase shell. This algorithm is not secure enough and not allowed in certain environments (like on FIPS compliant clusters). Our plan is to change it to e.g. `PBKDF2WithHmacSHA384`. If this would break backward compatibility, then we should make this algorithm configurable. 2. In `EncryptionUtil.createEncryptionContext` the various encryption config checks should throw IllegalStateExceptions instead of RuntimeExceptions. 3. Test cases in `TestEncryptionTest.java` should be broken down into smaller tests. 4. `TestEncryptionDisabled.java` should use `ExpectedException` JUnit rule to validate exceptions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
