Skip to main content

Operator And Server Responsibilities

Testudo is split into disaster-operator and disaster-server. Understanding the boundary is important for deployment, troubleshooting, and contribution.

disaster-operator​

The operator is the Kubernetes control plane extension. It reconciles actual state to the desired state expressed by CRDs.

Responsibilities:

  • Define and reconcile testudo.softcdata.com/v1 CRDs.
  • Access source and target clusters.
  • Create Velero Backup, Restore, Schedule, and BackupStorageLocation resources.
  • Maintain state machines, conditions, history, reasons, and messages.
  • Run failover, reprotection, undo, cancel, sync, and drill cleanup steps.
  • Emit Kubernetes Events.

The operator should own all actions that change runtime disaster recovery state.

disaster-server​

The server is the user entry point and aggregation layer.

Responsibilities:

  • Authentication, JWT, tracing, and recovery middleware.
  • REST APIs and Watch APIs.
  • Request validation and user-friendly errors.
  • DTO conversion from CRDs, Events, and statistics resources.
  • OpenAPI and Swagger.

The server should not bypass CRD state machines to write remote clusters directly.

Where A Change Belongs​

  • New execution step: usually disaster-operator.
  • New console action endpoint: usually disaster-server, backed by CRD changes.
  • New CRD field: operator API types first, then server DTOs and OpenAPI.
  • New statistics page: server aggregation if CRD status or Events already contain the data.
  • State convergence bug: start with disaster-operator.