HBASE-29691: Change TableName.META_TABLE_NAME from being a global static

[Kota-SH]

Jira: https://issues.apache.org/jira/browse/HBASE-29691

[Apache-HBase]

🎊 +1 overall

Vote	Subsystem	Runtime	Logfile	Comment
+0 🆗	reexec	0m 42s		Docker mode activated.
			_ Prechecks _
+1 💚	dupname	0m 1s		No case conflicting files found.
+0 🆗	codespell	0m 0s		codespell was not available.
+0 🆗	detsecrets	0m 0s		detect-secrets was not available.
+1 💚	@author	0m 0s		The patch does not contain any @author tags.
+1 💚	hbaseanti	0m 0s		Patch does not have any anti-patterns.
			_ master Compile Tests _
+0 🆗	mvndep	0m 17s		Maven dependency ordering for branch
+1 💚	mvninstall	4m 14s		master passed
+1 💚	compile	13m 42s		master passed
+1 💚	checkstyle	5m 47s		master passed
+1 💚	spotbugs	10m 38s		master passed
+1 💚	spotless	1m 12s		branch has no errors when running spotless:check.
			_ Patch Compile Tests _
+0 🆗	mvndep	0m 13s		Maven dependency ordering for patch
+1 💚	mvninstall	4m 6s		the patch passed
+1 💚	compile	12m 49s		the patch passed
+1 💚	javac	12m 49s		the patch passed
+1 💚	blanks	0m 0s		The patch has no blanks issues.
-0 ⚠️	checkstyle	0m 16s	/results-checkstyle-hbase-common.txt	hbase-common: The patch generated 3 new + 2 unchanged - 0 fixed = 5 total (was 2)
+1 💚	rubocop	0m 15s		No new issues.
+1 💚	spotbugs	12m 43s		the patch passed
+1 💚	hadoopcheck	12m 45s		Patch does not cause any errors with Hadoop 3.3.6 3.4.1.
+1 💚	spotless	0m 51s		patch has no errors when running spotless:check.
			_ Other Tests _
+1 💚	asflicense	2m 5s		The patch does not generate ASF License warnings.
		100m 7s

Subsystem	Report/Notes
Docker	ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7558/2/artifact/yetus-general-check/output/Dockerfile
GITHUB PR	#7558
JIRA Issue	HBASE-29691
Optional Tests	dupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless rubocop
uname	Linux 7b9f17878fcd 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 / 3f4fdde
Default Java	Eclipse Adoptium-17.0.11+9
Max. process+thread count	95 (vs. ulimit of 30000)
modules	C: hbase-common hbase-hadoop-compat hbase-client hbase-zookeeper hbase-balancer hbase-server hbase-mapreduce hbase-diagnostics hbase-testing-util hbase-thrift hbase-shell hbase-backup hbase-it hbase-rest U: .
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7558/2/console
versions	git=2.34.1 maven=3.9.8 spotbugs=4.7.3 rubocop=1.37.1
Powered by	Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

[Apache-HBase]

🎊 +1 overall

Vote	Subsystem	Runtime	Logfile	Comment
+0 🆗	reexec	0m 13s		Docker mode activated.
-0 ⚠️	yetus	0m 3s		Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck
			_ Prechecks _
			_ master Compile Tests _
+0 🆗	mvndep	0m 13s		Maven dependency ordering for branch
+1 💚	mvninstall	2m 51s		master passed
+1 💚	compile	3m 59s		master passed
+1 💚	javadoc	2m 52s		master passed
+1 💚	shadedjars	5m 14s		branch has no errors when building our shaded downstream artifacts.
			_ Patch Compile Tests _
+0 🆗	mvndep	0m 10s		Maven dependency ordering for patch
+1 💚	mvninstall	2m 29s		the patch passed
+1 💚	compile	3m 43s		the patch passed
+1 💚	javac	3m 43s		the patch passed
+1 💚	javadoc	2m 56s		the patch passed
+1 💚	shadedjars	4m 24s		patch has no errors when building our shaded downstream artifacts.
			_ Other Tests _
+1 💚	unit	1m 53s		hbase-common in the patch passed.
+1 💚	unit	0m 27s		hbase-hadoop-compat in the patch passed.
+1 💚	unit	1m 12s		hbase-client in the patch passed.
+1 💚	unit	0m 37s		hbase-zookeeper in the patch passed.
+1 💚	unit	7m 57s		hbase-balancer in the patch passed.
+1 💚	unit	195m 31s		hbase-server in the patch passed.
+1 💚	unit	15m 59s		hbase-mapreduce in the patch passed.
+1 💚	unit	1m 49s		hbase-diagnostics in the patch passed.
+1 💚	unit	1m 45s		hbase-testing-util in the patch passed.
+1 💚	unit	6m 7s		hbase-thrift in the patch passed.
+1 💚	unit	6m 47s		hbase-shell in the patch passed.
+1 💚	unit	12m 4s		hbase-backup in the patch passed.
+1 💚	unit	0m 39s		hbase-it in the patch passed.
+1 💚	unit	2m 49s		hbase-rest in the patch passed.
		291m 18s

Subsystem	Report/Notes
Docker	ClientAPI=1.48 ServerAPI=1.48 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7558/2/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile
GITHUB PR	#7558
JIRA Issue	HBASE-29691
Optional Tests	javac javadoc unit compile shadedjars
uname	Linux 46047f12d54f 6.8.0-1024-aws #26~22.04.1-Ubuntu SMP Wed Feb 19 06:54:57 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / 3f4fdde
Default Java	Eclipse Adoptium-17.0.11+9
Test Results	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7558/2/testReport/
Max. process+thread count	4421 (vs. ulimit of 30000)
modules	C: hbase-common hbase-hadoop-compat hbase-client hbase-zookeeper hbase-balancer hbase-server hbase-mapreduce hbase-diagnostics hbase-testing-util hbase-thrift hbase-shell hbase-backup hbase-it hbase-rest U: .
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7558/2/console
versions	git=2.34.1 maven=3.9.8
Powered by	Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

[Apache9]

I do not think this is the correct way, at least you should not let clients config meta table name right? They should ask the meta table name from bootstrap node.

Theoretically, we can even support changing meta table name at runtime, clients and region servers can ask meta table name from master when they hit table not found exception when accessing meta.

And if we think this is a bit difficult to implement, and maybe there is no need to change meta table name after initialization, then maybe we can introduce a config to set meta table name when bootstraping a cluster, then we record this name in master local region or on HDFS directly. But anyway, clients and region servers still need to ask for the meta table name from master, not from configuration. But they just do not need to deal with meta table name change when running.

Thanks.

[Apache9]

I do not think this is a good practise, as this is still static, what if a client wants to connect different read replica clusters? And it will difficult to write UTs when you want to set up two clusters with different meta table names...