Cluster configurations

Cluster configuration is modeled around topology plus size.

Current model

The control plane catalogs cluster choices using:

• cluster_config for topology and node-count shape
• cluster_size_catalog for provider-agnostic size definitions
• cluster_size_variant for provider-specific purchasable variants

In the dashboard, this appears as an Instances tab where operators choose:

• cluster topology
• cluster size
• implied node count and monthly profile cost

How changes are applied

Instance changes do not mutate infrastructure immediately from the UI. The current flow is:

1. Resolve the requested selection from catalog metadata.
2. Compare it with the active profile.
3. Queue a shared upgrade workflow if anything changed.

Rollout behavior

The rollout model depends on provider and requested delta:

• rolling in place for mutations that can safely reuse the existing footprint
• backup-driven migration for GCP topology changes that need a new cluster shape while preserving data
• blocked on AWS for topology changes until restore-backed migration exists there

What operators should expect

• the active profile records requested shape and converged runtime state
• GCP topology changes create a fresh backup, restore that backup into the target shape, and cause controlled downtime during cutover
• AWS topology changes are rejected before workflow enqueue instead of silently reprovisioning
• allocation history remains the billing-facing history of effective cluster shape
• the Changes tab shows durable change outcomes, not every workflow step

See Replicas for replica-specific behavior.