Introduce Control Server as Control Plane

[em3s]

Background

Actionbase was originally designed for a single-tenant, single-cluster deployment model.

Today, production environments are becoming more complex:

• Multiple tenants
• Active/Standby deployments
• Dedicated read clusters
• Environment-specific policies (dev/test/prod)
• User-level authorization
• Audit requirements
• Operational workflows such as cleanup

In these environments, operational actions such as DDL, cleanup, and cluster management must be coordinated across multiple Actionbase clusters.

Currently, topology awareness and orchestration logic are distributed across Console and other operational tools. This makes operational logic difficult to reuse and introduces coupling between clients and deployment topology.

To address this, introduce a dedicated control-server that acts as the Actionbase Control Plane.

Task

• Create a new control-server module
• Support tenant and cluster topology configuration
• Implement request routing to Actionbase servers
• Support active/standby fanout orchestration
• Implement authorization based on environment, tenant, resource, operation, and side
• Add audit logging for operational actions

Done When

• control-server can act as the operational entry point for Console and CLI.
• Topology information is managed centrally.
• Active/Standby orchestration is handled by control-server.
• Authorization is enforced centrally.
• Audit logs are recorded for operational actions.
• Existing server APIs remain compatible without modification.

Notes

Architecture

Console / CLI
        ↓
  control-server
        ↓
      server
        ↓
      HBase

Control Plane vs Data Plane

The terms Control Plane and Data Plane are used from an architectural perspective.

• Data Plane: Handles data access and cluster-local request execution.
• Control Plane: Handles topology, authorization, operational policies, orchestration, and auditing.

server continues to provide Query, DML, and DDL APIs and remains unchanged.

From a system-wide perspective, server is used as the execution endpoint for individual Actionbase clusters and therefore serves as the Data Plane.

control-server acts as the Control Plane by managing topology, authorization, operational workflows, audit logging, and multi-cluster orchestration.

DDL is inherently a control-plane operation. However, actual DDL execution remains in server, while control-server is responsible for authorization, policy enforcement, auditing, and orchestration.

Initial Responsibilities

• Tenant and cluster topology management
• Active/Standby orchestration
• Authorization management
• Audit logging
• Cross-cluster operational APIs

Storage

control-server maintains operational metadata and uses Actionbase as its metadata store.

Examples:

• Permissions
• Audit logs
• Topology information
• Operational metadata