[jira] [Created] (HBASE-29782) Expose public Admin API to reopen table regions without moving

["Alex Hughes (Jira)" <ji...@apache.org>]

Alex Hughes created HBASE-29782:
-----------------------------------

             Summary: Expose public Admin API to reopen table regions without moving
                 Key: HBASE-29782
                 URL: https://issues.apache.org/jira/browse/HBASE-29782
             Project: HBase
          Issue Type: Improvement
          Components: Admin, master, proc-v2
            Reporter: Alex Hughes


Currently, when modifying a table descriptor with {{{}reopenRegions=false{}}}, there is no straightforward way to reopen regions without moving them to different servers. The only workaround is to call {{move()}} on each region individually, which is expensive as it triggers cross-server data transfers.

This limitation makes it difficult to gradually roll out table descriptor changes for large, latency-sensitive production tables. Operators need the ability to:
 # Reopen regions in-place (without server-to-server moves)
 # Target specific regions for canary testing before full rollout
 # Leverage existing batching/throttling (HBASE-28215) for controlled deployments

The {{ReopenTableRegionsProcedure}} already supports in-place region reopening via {{{}TransitRegionStateProcedure.reopen(){}}}, but this functionality is not exposed through the public {{Admin}} API.
h3. Motivation

For production environments, modifying table descriptors can be disruptive:
 * Setting {{reopenRegions=true}} causes simultaneous reopening of all regions, creating a "RIT storm" that impacts availability
 * Setting {{reopenRegions=false}} leaves regions unaware of changes, with no clean way to roll them out gradually
 * Using {{move()}} operations is unnecessarily expensive, involving network I/O and cross-server coordination when regions could simply reopen in-place

A public API for gradual, in-place region reopening enables safer, more controlled rollouts of table configuration changes, particularly for large tables serving latency-sensitive workloads.
h3. Proposed Solution:

 
{code:java}
// Reopen all regions for a table (in-place, no move)
void reopenTableRegions(TableName tableName)
Future<Void> reopenTableRegionsAsync(TableName tableName)
CompletableFuture<Void> reopenTableRegions(TableName tableName)
// Reopen specific regions (for canary testing)
void reopenTableRegions(TableName tableName, List<RegionInfo> regions)
Future<Void> reopenTableRegionsAsync(TableName tableName, List<RegionInfo> regions)
CompletableFuture<Void> reopenTableRegions(TableName tableName, List<RegionInfo> regions)
{code}
These methods will:
 * Invoke the existing {{ReopenTableRegionsProcedure}} with appropriate region targeting
 * Support batching/throttling via existing configurations ({{{}hbase.reopen.table.regions.progressive.batch.*{}}})
 * Validate that specified regions belong to the target table
 * Perform in-place reopens using {{TransitRegionStateProcedure.reopen()}}



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