HBASE-28149 move_servers_namespaces_rsgroup is not changing the new r…

[chrajeshbabu]

…s group in namespace description

[Apache-HBase]

:confetti_ball: +1 overall

Vote	Subsystem	Runtime	Comment
+0 :ok:	reexec	0m 13s	Docker mode activated.
		_ Prechecks _
+1 :green_heart:	dupname	0m 0s	No case conflicting files found.
+1 :green_heart:	@author	0m 0s	The patch does not contain any @author tags.
		_ master Compile Tests _
+1 :green_heart:	mvninstall	3m 2s	master passed
+1 :green_heart:	spotless	0m 44s	branch has no errors when running spotless:check.
		_ Patch Compile Tests _
+1 :green_heart:	mvninstall	2m 40s	the patch passed
-0 :warning:	rubocop	0m 5s	The patch generated 6 new + 17 unchanged - 1 fixed = 23 total (was 18)
+1 :green_heart:	whitespace	0m 0s	The patch has no whitespace issues.
+1 :green_heart:	spotless	0m 41s	patch has no errors when running spotless:check.
		_ Other Tests _
+1 :green_heart:	asflicense	0m 12s	The patch does not generate ASF License warnings.
		8m 42s

Subsystem	Report/Notes
Docker	ClientAPI=1.44 ServerAPI=1.44 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/1/artifact/yetus-general-check/output/Dockerfile
GITHUB PR	https://github.com/apache/hbase/pull/5661
Optional Tests	dupname asflicense javac spotless rubocop
uname	Linux c4f28afd2211 5.4.0-166-generic #183-Ubuntu SMP Mon Oct 2 11:28:33 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / c4e332a93b
Default Java	Eclipse Adoptium-11.0.17+8
rubocop	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/1/artifact/yetus-general-check/output/diff-patch-rubocop.txt
Max. process+thread count	77 (vs. ulimit of 30000)
modules	C: hbase-shell U: hbase-shell
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/1/console
versions	git=2.34.1 maven=3.8.6 rubocop=1.37.1
Powered by	Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

[chrajeshbabu]

Actually hbase:rsgroup table should be single source of truth for all the rsgroup information. Currently namespace specific rsgroup information stored in namespace descriptor which can be also can be stored in hbase:rsgroup table. @Apache9 @ndimiduk @bbeaudreault wdyt? If you can confirm will work on to make the namespace specific rsgroup info also to be managed through hbase:rsgroup table.

[Apache-HBase]

:confetti_ball: +1 overall

Vote	Subsystem	Runtime	Comment
+0 :ok:	reexec	0m 26s	Docker mode activated.
-0 :warning:	yetus	0m 4s	Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck
		_ Prechecks _
		_ master Compile Tests _
+1 :green_heart:	mvninstall	2m 49s	master passed
+1 :green_heart:	javadoc	0m 10s	master passed
		_ Patch Compile Tests _
+1 :green_heart:	mvninstall	2m 26s	the patch passed
+1 :green_heart:	javadoc	0m 8s	the patch passed
		_ Other Tests _
+1 :green_heart:	unit	7m 42s	hbase-shell in the patch passed.
		14m 46s

Subsystem	Report/Notes
Docker	ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile
GITHUB PR	https://github.com/apache/hbase/pull/5661
Optional Tests	javac javadoc unit
uname	Linux a427ee4836d1 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / c4e332a93b
Default Java	Temurin-1.8.0_352-b08
Test Results	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/1/testReport/
Max. process+thread count	1970 (vs. ulimit of 30000)
modules	C: hbase-shell U: hbase-shell
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/1/console
versions	git=2.34.1 maven=3.8.6
Powered by	Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

[Apache-HBase]

:broken_heart: -1 overall

Vote	Subsystem	Runtime	Comment
+0 :ok:	reexec	0m 38s	Docker mode activated.
-0 :warning:	yetus	0m 3s	Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck
		_ Prechecks _
		_ master Compile Tests _
+1 :green_heart:	mvninstall	4m 17s	master passed
+1 :green_heart:	javadoc	0m 20s	master passed
		_ Patch Compile Tests _
+1 :green_heart:	mvninstall	3m 44s	the patch passed
+1 :green_heart:	javadoc	0m 11s	the patch passed
		_ Other Tests _
-1 :x:	unit	14m 36s	hbase-shell in the patch failed.
		24m 49s

Subsystem	Report/Notes
Docker	ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile
GITHUB PR	https://github.com/apache/hbase/pull/5661
Optional Tests	javac javadoc unit
uname	Linux 41d1b8493c5f 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / c4e332a93b
Default Java	Eclipse Adoptium-11.0.17+8
unit	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/1/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-shell.txt
Test Results	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/1/testReport/
Max. process+thread count	1986 (vs. ulimit of 30000)
modules	C: hbase-shell U: hbase-shell
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/1/console
versions	git=2.34.1 maven=3.8.6
Powered by	Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

[Apache9]

Actually hbase:rsgroup table should be single source of truth for all the rsgroup information. Currently namespace specific rsgroup information stored in namespace descriptor which can be also can be stored in hbase:rsgroup table. @Apache9 @ndimiduk @bbeaudreault wdyt? If you can confirm will work on to make the namespace specific rsgroup info also to be managed through hbase:rsgroup table.

IIRC we intentionally changed the rs group information for a table or a namespace to its descriptor in the past. Now the hbase:rsgroup table only stores the rsgroup <-> region server relationships.

[chrajeshbabu]

Got it @Apache9 from HBASE-22514. Moving the rsgroup to table configs which will reopen regions to move to the RS group servers automatically is good idea. Thanks for the info.

[chrajeshbabu]

There is a test case timeout which is not related to this. {noformat} Error test timed out after 780 seconds Stacktrace org.junit.runners.model.TestTimedOutException: test timed out after 780 seconds at [email protected]/jdk.internal.misc.Unsafe.park(Native Method) at [email protected]/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234) at [email protected]/java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1798) at [email protected]/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3128) at [email protected]/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1868) at [email protected]/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021) at app//org.apache.hadoop.hbase.util.FutureUtils.get(FutureUtils.java:196) at app//org.apache.hadoop.hbase.client.Admin.deleteTable(Admin.java:309) at jdk.internal.reflect.GeneratedMethodAccessor276.invoke(Unknown Source) at [email protected]/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at [email protected]/java.lang.reflect.Method.invoke(Method.java:566) at app//org.jruby.javasupport.JavaMethod.invokeDirectWithExceptionHandling(JavaMethod.java:457) at app//org.jruby.javasupport.JavaMethod.invokeDirect(JavaMethod.java:318) at app//org.jruby.java.invokers.InstanceMethodInvoker.call(InstanceMethodInvoker.java:42) at app//org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:173) at app//org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:316) at app//org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72) at app//org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:86) at app//org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:201) at app//org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:188) at app//org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:218) at app//org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:173) at app//org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:316) at app//org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72) at app//org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:86) at app//org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:201) at app//org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:188) at app//org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:218) at app//org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:173) at app//org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:316) at app//org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72) at app//org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:80) at app//org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:164) at app//org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:151) at app//org.jruby.RubyClass.finvokeWithRefinements(RubyClass.java:497) at app//org.jruby.RubyBasicObject.send(RubyBasicObject.java:1707) at app//org.jruby.RubyBasicObject$INVOKER$i$send.call(RubyBasicObject$INVOKER$i$send.gen) {noformat}

[Apache-HBase]

:confetti_ball: +1 overall

Vote	Subsystem	Runtime	Comment
+0 :ok:	reexec	0m 12s	Docker mode activated.
		_ Prechecks _
+1 :green_heart:	dupname	0m 0s	No case conflicting files found.
+1 :green_heart:	@author	0m 0s	The patch does not contain any @author tags.
		_ master Compile Tests _
+1 :green_heart:	mvninstall	3m 3s	master passed
+1 :green_heart:	spotless	0m 44s	branch has no errors when running spotless:check.
		_ Patch Compile Tests _
+1 :green_heart:	mvninstall	2m 43s	the patch passed
-0 :warning:	rubocop	0m 4s	The patch generated 6 new + 17 unchanged - 1 fixed = 23 total (was 18)
+1 :green_heart:	whitespace	0m 0s	The patch has no whitespace issues.
+1 :green_heart:	spotless	0m 42s	patch has no errors when running spotless:check.
		_ Other Tests _
+1 :green_heart:	asflicense	0m 11s	The patch does not generate ASF License warnings.
		8m 45s

Subsystem	Report/Notes
Docker	ClientAPI=1.44 ServerAPI=1.44 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/2/artifact/yetus-general-check/output/Dockerfile
GITHUB PR	https://github.com/apache/hbase/pull/5661
Optional Tests	dupname asflicense javac spotless rubocop
uname	Linux 197e82d609c2 5.4.0-166-generic #183-Ubuntu SMP Mon Oct 2 11:28:33 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / c4e332a93b
Default Java	Eclipse Adoptium-11.0.17+8
rubocop	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/2/artifact/yetus-general-check/output/diff-patch-rubocop.txt
Max. process+thread count	79 (vs. ulimit of 30000)
modules	C: hbase-shell U: hbase-shell
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/2/console
versions	git=2.34.1 maven=3.8.6 rubocop=1.37.1
Powered by	Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

[Apache-HBase]

:confetti_ball: +1 overall

Vote	Subsystem	Runtime	Comment
+0 :ok:	reexec	0m 26s	Docker mode activated.
-0 :warning:	yetus	0m 3s	Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck
		_ Prechecks _
		_ master Compile Tests _
+1 :green_heart:	mvninstall	2m 43s	master passed
+1 :green_heart:	javadoc	0m 10s	master passed
		_ Patch Compile Tests _
+1 :green_heart:	mvninstall	2m 23s	the patch passed
+1 :green_heart:	javadoc	0m 8s	the patch passed
		_ Other Tests _
+1 :green_heart:	unit	7m 45s	hbase-shell in the patch passed.
		14m 29s

Subsystem	Report/Notes
Docker	ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile
GITHUB PR	https://github.com/apache/hbase/pull/5661
Optional Tests	javac javadoc unit
uname	Linux 82b7665c4635 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / c4e332a93b
Default Java	Temurin-1.8.0_352-b08
Test Results	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/2/testReport/
Max. process+thread count	1948 (vs. ulimit of 30000)
modules	C: hbase-shell U: hbase-shell
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/2/console
versions	git=2.34.1 maven=3.8.6
Powered by	Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

[Apache-HBase]

:confetti_ball: +1 overall

Vote	Subsystem	Runtime	Comment
+0 :ok:	reexec	0m 29s	Docker mode activated.
-0 :warning:	yetus	0m 2s	Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck
		_ Prechecks _
		_ master Compile Tests _
+1 :green_heart:	mvninstall	3m 16s	master passed
+1 :green_heart:	javadoc	0m 10s	master passed
		_ Patch Compile Tests _
+1 :green_heart:	mvninstall	2m 54s	the patch passed
+1 :green_heart:	javadoc	0m 9s	the patch passed
		_ Other Tests _
+1 :green_heart:	unit	7m 41s	hbase-shell in the patch passed.
		15m 32s

Subsystem	Report/Notes
Docker	ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile
GITHUB PR	https://github.com/apache/hbase/pull/5661
Optional Tests	javac javadoc unit
uname	Linux fbcc6e240d44 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / c4e332a93b
Default Java	Eclipse Adoptium-11.0.17+8
Test Results	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/2/testReport/
Max. process+thread count	2019 (vs. ulimit of 30000)
modules	C: hbase-shell U: hbase-shell
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5661/2/console
versions	git=2.34.1 maven=3.8.6
Powered by	Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

[Apache9]

I'm not very familiar with the shell command here, so what does move_servers_namespaces_rsgroup actually do?

[chrajeshbabu]

I'm not very familiar with the shell command here, so what does move_servers_namespaces_rsgroup actually do?

@Apache9 move_namespaces_rsgroup 'dest',['ns1','ns2'] -> moves tables in the namespaces to RS Group move_servers_namespaces_rsgroup 'dest',['server1:port','server2:port'],['ns1','ns2'] -> moves tables in the namespaces and servers to rsgroup.

These commands utilizing the rsadmin APIs provided in ruby to move existing tables in the namespaces to the dest RS group but not setting the new rsgroup name in the namenode descriptor.Without which any new tables created after running this command might go to old rsgroup servers which leads to inconsistent state. Since the core APIs not supporting the setting the rsgroup name in the namespace descriptor utilising the alter_namespace command in the above two commands.

I would like to suggest simple admin API called moveNamespaceToRSGroup also along with existing RS group APIs so that setting configuration value for RS Group namespace in namespace descriptor can be taken care within the API level.

[Apache9]

I would like to suggest simple admin API called moveNamespaceToRSGroup also along with existing RS group APIs so that setting configuration value for RS Group namespace in namespace descriptor can be taken care within the API level.

This is exactly what I concern here...

It is a bit strange that why we need to an extra step after calling an admin method, is this because we are calling an old API in RSGroupAdmin, not the method in Admin interface?

I'm still a bit confused by 'moves tables in the namespaces and servers to rsgroup.'. Why we need to care about tables here? Just change the namespace descriptor and also move the servers is enough?

[chrajeshbabu]

It is a bit strange that why we need to an extra step after calling an admin method, is this because we are calling an old API in RSGroupAdmin, not the method in Admin interface?

After the update HBASE-23807, the old APIs in RSGroupAdmin are no longer being utilized in shell commands. The commands related to moving namespaces only move tables belonging to the namespaces to a new RS group without modifying the namespace descriptor itself. This behavior has remained same since the initial development of commands like move_namespaces_rsgroup and move_servers_namespaces_rsgroup (HBASE-19336). Having Admin API would be beneficial to control moving the namespace to new RS group programmatically.

I'm still a bit confused by 'moves tables in the namespaces and servers to rsgroup.'. Why we need to care about tables here? Just change the namespace descriptor and also move the servers is enough?\

If we just change the namespace descriptor and don't move the tables in the namespace then the existing tables belong to old RS group and what ever the tables created after that will be with new RS group so with in the the same namespace tables belongs to multiple rs groups in that case. If we are still ok to have such behavior then just changing the namespace descriptor is fine.

[chrajeshbabu]

This code in RSGroupUtil helps to get the rsgroup of the tables belongs to namespace but since first priority is given to checking at table descriptor and rsgroup info which gives old rsgroup first so if we don't move tables while moving namespace there could be possible tables within the namespace belongs to multiple groups.

NamespaceDescriptor nd = clusterSchema.getNamespace(tableName.getNamespaceAsString()); String groupNameOfNs = nd.getConfigurationValue(RSGroupInfo.NAMESPACE_DESC_PROP_GROUP); if (groupNameOfNs == null) { return Optional.empty(); } return Optional.ofNullable(manager.getRSGroup(groupNameOfNs));

[Apache9]

It is a bit strange that why we need to an extra step after calling an admin method, is this because we are calling an old API in RSGroupAdmin, not the method in Admin interface?

After the update HBASE-23807, the old APIs in RSGroupAdmin are no longer being utilized in shell commands. The commands related to moving namespaces only move tables belonging to the namespaces to a new RS group without modifying the namespace descriptor itself. This behavior has remained same since the initial development of commands like move_namespaces_rsgroup and move_servers_namespaces_rsgroup (HBASE-19336). Having Admin API would be beneficial to control moving the namespace to new RS group programmatically.

I'm still a bit confused by 'moves tables in the namespaces and servers to rsgroup.'. Why we need to care about tables here? Just change the namespace descriptor and also move the servers is enough?\

If we just change the namespace descriptor and don't move the tables in the namespace then the existing tables belong to old RS group and what ever the tables created after that will be with new RS group so with in the the same namespace tables belongs to multiple rs groups in that case. If we are still ok to have such behavior then just changing the namespace descriptor is fine.

OK, finally I understand the problem here. We are simulating the old behavior of move_namespaces_rsgroup and move_servers_namespaces_rsgroup, where there was no rs group information in namespace descriptor yet, so we just change all the rs group information for the tables in the namespace.

I think in the old time, newly created tables will still be in the default rs group if you do not set it manually right? So in the HBase OP's view, usually if they want to change the rs group of a namespace, they will

1. change the create table script, so new table created will be in the new rs group
2. call move_namespaces_rsgroup, to move the current tables in the namespace to the new rs group.

Since now, we have namespace descriptor support, seems the simplest way is to just set the rs group information in namespace descriptor, and then reopen all the tables under the namespace.

But there is another problem that, if we have rs group information in the table descriptor, it we just change the rs group information in namespace descriptor, it is not enough to move the table to the new rs group.

So the problem is we add a new dimension here, there are new combinations of configurations which makes old shell commands not enough to cover all the possibilities.

There are basically two ways, first is to change the old shell commands's behavior, like what we have done here, but not enough ,for me I think at least we should provide an option that whether we should override the rs group information in table descriptor.

Another way is to keep the old shell commands as is, and introduce new shell commands.

WDYT? I do not use rs group feature much, so I'm not sure which one is better.

Thanks.

[chrajeshbabu]

@Apache9 Thanks for response. Even I am thinking the same while moving namespaces to the new RS group would be better to have following options.

1. Move All Tables: This option involves moving all tables within a namespace to the new RS group, regardless of the current RS group they belong to. This would effectively consolidate all tables of the namespace into the new RS group. This is the same as the current implementation so it can be default behavior.

2. Move Tables present in current RS group: With this option, only tables belonging to the current RS group of the namespace would be moved to the new RS group. This provides more granular control, allowing users to choose specific tables to move based on their needs. If the namespace does not belong to any RS group, the namespace tables in the default RS group would be moved to the new RS group.

3. Move No Tables: This option involves changing the RS group of the namespace without moving any tables. Existing tables would remain in their current RS group. This could be useful if there's a desire to separate the namespaces by RS group but without immediately moving the tables.

With this options we can give control to user choose proper option based on the requirements. Will start working on it. Happy to add if any new options possible.

We wanted to use RS Groups for managing multiple tenants data in same cluster currently a namespace belongs to a tenant so first option is best fit for us.

[chrajeshbabu]

@Apache9 Thanks for response. Even I am thinking the same while moving namespaces to the new RS group would be better to have following options.

1. **Move All Tables:** This option involves moving all tables within a namespace to the new RS group, regardless of the current RS group they belong to. This would effectively consolidate all tables of the namespace into the new RS group. This is the same as the current implementation so it can be default behavior.

2. **Move Tables present in current  RS group**: With this option, only tables belonging to the current RS group of the namespace would be moved to the new RS group. This provides more granular control, allowing users to choose specific tables to move based on their needs. If the namespace does not belong to any RS group, the namespace tables in the default RS group would be moved to the new RS group.

3. **Move No Tables:** This option involves changing the RS group of the namespace without moving any tables. Existing tables would remain in their current RS group. This could be useful if there's a desire to separate the namespaces by RS group but without immediately moving the tables.

With this options we can give control to user choose proper option based on the requirements. Will start working on it. Happy to add if any new options possible.

We wanted to use RS Groups for managing multiple tenants data in same cluster currently a namespace belongs to a tenant so first option is best fit for us.

@Apache9 wdyt? Will create separate JIRA for this and work on it if it's fine.

[chrajeshbabu]

@Apache9 Thanks for response. Even I am thinking the same while moving namespaces to the new RS group would be better to have following options.

1. **Move All Tables:** This option involves moving all tables within a namespace to the new RS group, regardless of the current RS group they belong to. This would effectively consolidate all tables of the namespace into the new RS group. This is the same as the current implementation so it can be default behavior.

2. **Move Tables present in current  RS group**: With this option, only tables belonging to the current RS group of the namespace would be moved to the new RS group. This provides more granular control, allowing users to choose specific tables to move based on their needs. If the namespace does not belong to any RS group, the namespace tables in the default RS group would be moved to the new RS group.

3. **Move No Tables:** This option involves changing the RS group of the namespace without moving any tables. Existing tables would remain in their current RS group. This could be useful if there's a desire to separate the namespaces by RS group but without immediately moving the tables.

With this options we can give control to user choose proper option based on the requirements. Will start working on it. Happy to add if any new options possible. We wanted to use RS Groups for managing multiple tenants data in same cluster currently a namespace belongs to a tenant so first option is best fit for us.

@Apache9 wdyt? Will create separate JIRA for this and work on it if it's fine.

created HBASE-28406 to support this. Can we merge this to support existing behaviour till then.