[jira] [Resolved] (HBASE-27485) HBaseTestingUtility minicluster requires log4j2

2023-01-03 Thread Duo Zhang (Jira) 


 [ 
https://issues.apache.org/jira/browse/HBASE-27485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang resolved HBASE-27485.
---
Fix Version/s: 2.6.0
   3.0.0-alpha-4
   2.5.3
 Hadoop Flags: Reviewed
   Resolution: Fixed

Pushed to branch-2.5+.

Thanks [~chrajeshbab...@gmail.com] for reviewing!


> HBaseTestingUtility minicluster requires log4j2
> ---
>
> Key: HBASE-27485
> URL: https://issues.apache.org/jira/browse/HBASE-27485
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Reporter: Nick Dimiduk
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 2.6.0, 3.0.0-alpha-4, 2.5.3
>
>
> Using the HBaseMiniCluster now requires addition of log4j-api and log4j-core 
> to the classpath. This can be demonstrated by updating hbase-downstreamer for 
> 2.5.1.
> https://github.com/saintstack/hbase-downstreamer



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [DISCUSS] Allow namespace admins to clone snapshots created by them

2023-01-03 Thread Duo Zhang 
+1 on releasing 2.6.0 sooner.

And I think it is time to EOL 2.4.x after we release 2.6.0?

Bryan Beaudreault  于2023年1月3日周二 21:02写道：
>
> I think development is done on TLS. We are just waiting on requested
> testing. Andor was working on that, but I believe he had some stuff come up
> at his work.
>
> I also want to get backups in place, but there is 1 backwards compatibility
> issue to work through. Hoping to have that squared away soon.
>
> On Sat, Dec 31, 2022 at 9:32 PM Andrew Purtell 
> wrote:
>
> > +1
> >
> > If this is needed soon in a release we could start on 2.6.0?
> >
> > (How is TLS RPC coming along? - that would be the big ticket item.)
> >
> > > On Dec 23, 2022, at 7:06 AM, 张铎  wrote:
> > >
> > > This is a behavior change, it makes non admin users can clone snapshot.
> > >
> > > For me I do not think we should include changes like this in a patch
> > > release, unless it is considered as a critical bug which must be
> > > fixed.
> > >
> > > Thanks.
> > >
> > > Szabolcs Bukros  于2022年11月30日周三 00:06写道：
> > >>
> > >> This should not break any existing use case so I see no reason to not
> > add
> > >> this to branch-2.5 and
> > >> branch-2.4.
> > >>
> > >>> On Thu, Nov 24, 2022 at 3:03 AM 张铎(Duo Zhang) 
> > wrote:
> > >>>
> > >>> I'm OK with this change.
> > >>>
> > >>> But maybe we still need to determine which branches we can apply this
> > >>> change to? Is it OK to include this change for branch-2.5 and
> > >>> branch-2.4?
> > >>>
> > >>> Tak Lon (Stephen) Wu  于2022年11月22日周二 06:31写道：
> > 
> >  FYI the PR is https://github.com/apache/hbase/pull/4885
> > 
> > and
> >  https://issues.apache.org/jira/browse/HBASE-27493
> > 
> > .
> > 
> >  the proposal seems to be, should we allow cloning snapshot to any
> >  namespace if they're not the global admin.
> > 
> >  logically, it should be fine because they're the admin for the
> >  namespace, and should be able to do whatever within that namespace.
> > 
> >  Thanks,
> >  Stephen
> > 
> > 
> >  On Mon, Nov 21, 2022 at 11:38 AM Szabolcs Bukros
> >   wrote:
> > >
> > > Hi Everyone,
> > >
> > > Creating a snapshot requires table admin permissions. But cloning it
> > > requires global admin permissions unless the user owns the snapshot
> > and
> > > wants to recreate the original table the snapshot was based on using
> > >>> the
> > > same table name. This puts unnecessary load on the few users having
> > >>> global
> > > admin permissions on the cluster. I would like to relax this rule a
> > >>> bit and
> > > allow the owner of the snapshot to clone it into any namespace where
> > >>> they
> > > have admin permissions regardless of the table name used.
> > >
> > > Please let me know what you think about this proposal. And if you
> > find
> > >>> it
> > > acceptable which branch do you think this could land on.
> > >
> > > Thanks,
> > > Szabolcs Bukros
> > >>>
> >

[jira] [Resolved] (HBASE-26300) Skip archived master wals during incremental backups

2023-01-03 Thread Bryan Beaudreault (Jira) 


 [ 
https://issues.apache.org/jira/browse/HBASE-26300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Beaudreault resolved HBASE-26300.
---
Fix Version/s: 3.0.0-alpha-4
   Resolution: Fixed

Thanks [~jlee] !

> Skip archived master wals during incremental backups
> 
>
> Key: HBASE-26300
> URL: https://issues.apache.org/jira/browse/HBASE-26300
> Project: HBase
>  Issue Type: Bug
>Reporter: Bryan Beaudreault
>Priority: Major
> Fix For: 3.0.0-alpha-4
>
>
> I've been reading through the incremental backup implementation in master 
> branch to see how it handled some scenarios our own internal incremental 
> backup process has to handle. One such failure we recently encountered as 
> part of our ongoing hbase2 upgrade is the new $masterlocalwal$ suffixed files 
> in the oldWALs dir. Our parsing of the WAL files assumed that the last part 
> of the file name would be a timestamp, which is not the case for these 
> MasterRegion WALs.
> I see [IncrementalBackupManager excludes 
> ProcV2Wals|https://github.com/apache/hbase/blob/master/hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/impl/IncrementalBackupManager.java#L104-L117],
>  but I think that was replaced in 
> https://issues.apache.org/jira/browse/HBASE-24408 with a MasterRegion. The 
> new MasterRegion uses normal WALs, but archives them with a suffix 
> "$masterlocalwal$".
> I believe this would fail [around line 222 of 
> IncrementalBackupManager|https://github.com/apache/hbase/blob/master/hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/impl/IncrementalBackupManager.java#L222],
>  because 
> [BackupUtils.getCreationTime|https://github.com/apache/hbase/blob/master/hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/util/BackupUtils.java#L383-L390]
>  similarly expects the file names to end with a timestamp.
> Unfortunately I am not set up to run master branch or test the backup/restore 
> functionality, but I wanted to log this because I happened to stumble upon it.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (HBASE-27550) [hbase-connectors] org.apache.hadoop.hbase.spark.TestJavaHBaseContext failing with HBase 2.5.x

2023-01-03 Thread Rajeshbabu Chintaguntla (Jira) 


 [ 
https://issues.apache.org/jira/browse/HBASE-27550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajeshbabu Chintaguntla resolved HBASE-27550.
-
Resolution: Duplicate

[~zhangduo]  Thanks for the info. HBASE-27485 good fix. Hence closing this as 
duplicate.

> [hbase-connectors] org.apache.hadoop.hbase.spark.TestJavaHBaseContext failing 
> with HBase 2.5.x
> --
>
> Key: HBASE-27550
> URL: https://issues.apache.org/jira/browse/HBASE-27550
> Project: HBase
>  Issue Type: Bug
>  Components: hbase-connectors
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
>
> {noformat}
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running org.apache.hadoop.hbase.spark.TestJavaHBaseContext
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.157 
> s <<< FAILURE! - in org.apache.hadoop.hbase.spark.TestJavaHBaseContext
> [ERROR] org.apache.hadoop.hbase.spark.TestJavaHBaseContext  Time elapsed: 
> 5.142 s  <<< ERROR!
> java.lang.NoClassDefFoundError: org/apache/logging/log4j/Level
>     at 
> org.apache.hadoop.hbase.spark.TestJavaHBaseContext.setUpBeforeClass(TestJavaHBaseContext.java:98)
> Caused by: java.lang.ClassNotFoundException: org.apache.logging.log4j.Level
>     at 
> org.apache.hadoop.hbase.spark.TestJavaHBaseContext.setUpBeforeClass(TestJavaHBaseContext.java:98)
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Errors:
> [ERROR]   TestJavaHBaseContext.setUpBeforeClass:98 » NoClassDefFound 
> org/apache/logging/...
> [INFO]
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO]
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [DISCUSS] Allow namespace admins to clone snapshots created by them

2023-01-03 Thread Bryan Beaudreault 
I think development is done on TLS. We are just waiting on requested
testing. Andor was working on that, but I believe he had some stuff come up
at his work.

I also want to get backups in place, but there is 1 backwards compatibility
issue to work through. Hoping to have that squared away soon.

On Sat, Dec 31, 2022 at 9:32 PM Andrew Purtell 
wrote:

> +1
>
> If this is needed soon in a release we could start on 2.6.0?
>
> (How is TLS RPC coming along? - that would be the big ticket item.)
>
> > On Dec 23, 2022, at 7:06 AM, 张铎  wrote:
> >
> > This is a behavior change, it makes non admin users can clone snapshot.
> >
> > For me I do not think we should include changes like this in a patch
> > release, unless it is considered as a critical bug which must be
> > fixed.
> >
> > Thanks.
> >
> > Szabolcs Bukros  于2022年11月30日周三 00:06写道：
> >>
> >> This should not break any existing use case so I see no reason to not
> add
> >> this to branch-2.5 and
> >> branch-2.4.
> >>
> >>> On Thu, Nov 24, 2022 at 3:03 AM 张铎(Duo Zhang) 
> wrote:
> >>>
> >>> I'm OK with this change.
> >>>
> >>> But maybe we still need to determine which branches we can apply this
> >>> change to? Is it OK to include this change for branch-2.5 and
> >>> branch-2.4?
> >>>
> >>> Tak Lon (Stephen) Wu  于2022年11月22日周二 06:31写道：
> 
>  FYI the PR is https://github.com/apache/hbase/pull/4885
> 
> and
>  https://issues.apache.org/jira/browse/HBASE-27493
> 
> .
> 
>  the proposal seems to be, should we allow cloning snapshot to any
>  namespace if they're not the global admin.
> 
>  logically, it should be fine because they're the admin for the
>  namespace, and should be able to do whatever within that namespace.
> 
>  Thanks,
>  Stephen
> 
> 
>  On Mon, Nov 21, 2022 at 11:38 AM Szabolcs Bukros
>   wrote:
> >
> > Hi Everyone,
> >
> > Creating a snapshot requires table admin permissions. But cloning it
> > requires global admin permissions unless the user owns the snapshot
> and
> > wants to recreate the original table the snapshot was based on using
> >>> the
> > same table name. This puts unnecessary load on the few users having
> >>> global
> > admin permissions on the cluster. I would like to relax this rule a
> >>> bit and
> > allow the owner of the snapshot to clone it into any namespace where
> >>> they
> > have admin permissions regardless of the table name used.
> >
> > Please let me know what you think about this proposal. And if you
> find
> >>> it
> > acceptable which branch do you think this could land on.
> >
> > Thanks,
> > Szabolcs Bukros
> >>>
>

[jira] [Created] (HBASE-27550) org.apache.hadoop.hbase.spark.TestJavaHBaseContext failing with HBase 2.5.2

2023-01-03 Thread Rajeshbabu Chintaguntla (Jira) 
Rajeshbabu Chintaguntla created HBASE-27550:
---

 Summary: org.apache.hadoop.hbase.spark.TestJavaHBaseContext 
failing with HBase 2.5.2
 Key: HBASE-27550
 URL: https://issues.apache.org/jira/browse/HBASE-27550
 Project: HBase
  Issue Type: Bug
  Components: hbase-connectors
Reporter: Rajeshbabu Chintaguntla
Assignee: Rajeshbabu Chintaguntla


{noformat}

[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO] Running org.apache.hadoop.hbase.spark.TestJavaHBaseContext
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.157 s 
<<< FAILURE! - in org.apache.hadoop.hbase.spark.TestJavaHBaseContext
[ERROR] org.apache.hadoop.hbase.spark.TestJavaHBaseContext  Time elapsed: 5.142 
s  <<< ERROR!
java.lang.NoClassDefFoundError: org/apache/logging/log4j/Level
    at 
org.apache.hadoop.hbase.spark.TestJavaHBaseContext.setUpBeforeClass(TestJavaHBaseContext.java:98)
Caused by: java.lang.ClassNotFoundException: org.apache.logging.log4j.Level
    at 
org.apache.hadoop.hbase.spark.TestJavaHBaseContext.setUpBeforeClass(TestJavaHBaseContext.java:98)

[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]   TestJavaHBaseContext.setUpBeforeClass:98 » NoClassDefFound 
org/apache/logging/...
[INFO]
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
[INFO]

{noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (HBASE-27549) [hbase-thirdparty] Upgrade Netty to 4.1.86.Final

2023-01-03 Thread Rajeshbabu Chintaguntla (Jira) 


 [ 
https://issues.apache.org/jira/browse/HBASE-27549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajeshbabu Chintaguntla resolved HBASE-27549.
-
Resolution: Fixed

Thanks for review [~zhangduo]

> [hbase-thirdparty] Upgrade Netty to 4.1.86.Final
> 
>
> Key: HBASE-27549
> URL: https://issues.apache.org/jira/browse/HBASE-27549
> Project: HBase
>  Issue Type: Bug
>  Components: thirdparty
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Fix For: thirdparty-4.1.4
>
>
> Netty version - 4.1.86.Final has fix some CVEs.
> CVE-2022-41915,
> CVE-2022-41881
> Upgrade to latest version.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (HBASE-27548) Bump jettison from 1.5.1 to 1.5.2

2023-01-03 Thread Duo Zhang (Jira) 


 [ 
https://issues.apache.org/jira/browse/HBASE-27548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang resolved HBASE-27548.
---
Hadoop Flags: Reviewed
  Resolution: Fixed

Pushed to branch-2.4+.

> Bump jettison from 1.5.1 to 1.5.2
> -
>
> Key: HBASE-27548
> URL: https://issues.apache.org/jira/browse/HBASE-27548
> Project: HBase
>  Issue Type: Task
>  Components: dependabot, dependencies, security
>Reporter: Duo Zhang
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)