Velero Operator lifecycle

charm
, ,
1

Charm lifecycle

This guide describes the details of each event handler in the Velero Operator charm.

Install

This event verifies the charm is deployed with --trust, ensuring permissions to manage cluster-scoped resources.

It checks whether Velero is already installed, using the Command Line Interface (CLI). If not, it installs Velero via velero install, configuring:

  • The image from the config.
  • Namespace based on the Juju model.
  • Node agent setup if use-node-agent is enabled.

At this stage, no storage or plugin configuration is done. Only the core Velero deployment is installed.

After installation, the charm immediately evaluates the system state, via update-status logic, and sets the unit status accordingly.

Remove

All Velero-related resources are deleted from the cluster using the Velero client abstraction. This includes the Velero deployment, Custom Resource Definitions (CRDs), secrets, service accounts, roles, backup locations, and node agents, if any.

The charm sets the unit status to Maintenance during removal to reflect progress.

Update-status

This event is used to verify the health and readiness of Velero’s system. The charm checks:

  • If the Velero deployment is available.
  • If use-node-agent=true, whether the DaemonSet is deployed and ready.
  • That only one storage relation is present.
  • That a valid storage provider is configured and Velero reports it as Available.

If any of these checks fail, the unit status is set to Blocked with a descriptive message. Otherwise, the charm sets its status to Active.

Config-changed

Config is re-validated using Pydantic models. If the Velero image or plugin image settings changed, the charm updates the Deployment/initContainer accordingly.

If the node agent setting, use-node-agent, was toggled:

  • When enabled, the agent is deployed.
  • When disabled, the DaemonSet is removed.

After applying changes, the charm re-runs status checks to reflect the updated state.

Storage integrator relation changed

When an S3 or Azure relation is created or updated, the charm:

  • Validates that only one storage backend is connected.
  • Retrieves credentials using the appropriate library (S3 or Azure).
  • Constructs and applies a Kubernetes secret with those credentials.
  • Installs the appropriate Velero plugin.
  • Configures a BackupStorageLocation for the cloud provider via velero backup-location create.

This configuration only runs if Velero is already installed and the storage location is not yet present.

Storage integrator relation broken

When a relation with a storage integrator is removed, the charm:

  • Deletes the Kubernetes secret associated with that backend.
  • Removes the configured BackupStorageLocation and disables the plugin.

The charm sets the unit to Blocked if no other valid relation is present, indicating a missing storage configuration.

Charm action

The charm exposes a run action that allows execution of a specific Velero CLI subcommand.

Before executing, the charm:

  • Validates that a storage provider is configured.
  • Parses and verifies that the command is one of the allowed subcommands: backup, restore, or schedule.

The CLI is invoked if the command is valid, and the output is logged to the Juju action. If the command is not allowed or fails, the action also fails, outputting an error message.