Overview

A SchemaRegistryRestore is used for restoring schemas to a SchemaRegistry, from the data previously backed-up by a SchemaRegistryBackup in a Storage.

It is configured by creating a SchemaRegistryRestore resource in Kubernetes.

The Kannika Armory Operator creates a Job that runs the restore process, based on the configuration in the SchemaRegistryRestore resource.

Usage

A SchemaRegistryRestore can be managed using the kubectl command line tool, and are available by the name schemaregistryrestore or schemaregistryrestores.

$ kubectl get schemaregistryrestores
NAME                         STATUS
confluent-registry-restore   🌈 Ready

Restore Status

A SchemaRegistryRestore can have the following statuses:

Initializing The Restore process is being created;
Ready The Restore is configured but it has not been started yet;
Running The Restore is running and restoring to the registry;
Error The Restore has failed;
Done The Restore is complete.

Additionally, a Restore resource exposes a JobCompleted Condition to report on the state of the underlying Job. This condition’s status can either be ‘True’ or ‘False’, and the reason field gives additional context:

JobInitializing the job is being started;
JobRunning the job is running;
JobCompleted the job has completed successfully;
JobFailed the job has failed.

Configuring a SchemaRegistryRestore

The following is an example of a SchemaRegistryRestore.

apiVersion: kannika.io/v1alpha
kind: SchemaRegistryRestore
metadata:
  name: confluent-registry-restore
spec:
  enabled: true
  registry: confluent-registry
  registryCredentialsFrom:
    credentialsRef:
      name: "http-basic-creds"
  storage: gcs-schema-storage
  storageCredentialsFrom:
    credentialsRef:
      name: "gcp-creds"
  extraEnvVars:
  - name: RUST_LOG
    value: "debug"

In this example:

A SchemaRegistryRestore named confluent-registry-restore is created, as indicated by the .metadata.name field. This name will inherited by the Job running the restore process.
The spec.enabled flag is set to true to allow restore process to start. If it is omitted or set to false, the restore process will be created in a paused state until the flag is switched to true.
The SchemaRegistryRestore will pull data from the Storage called gcs-schema-storage as defined in the spec.storage field, and use the Credentials
The SchemaRegistryRestore will connect to the confluent-registry SchemaRegistry to restore schemas, as indicated by the .spec.registry field, and use the Credentials referenced by confluent-registry-creds for authentication.
The spec.extraEnvVars field is used to pass additional environment variables to the restore process. In this case, the RUST_LOG variable is set to debug to enable debug logging.

Import mode

Some registries such as the Confluent Cloud Schema Registry support an ‘import’ mode that will ensure that schemas will be restored with their original schema ID and version.

If the target registry’s import mode is enabled, a SchemaRegistryRestore may be configured to try and restore the original IDs and versions:

apiVersion: kannika.io/v1alpha
kind: SchemaRegistryRestore
metadata:
  name: confluent-registry-restore
spec:
  enabled: true
  importMode: true # New
  registry: confluent-registry
  registryCredentialsFrom:
    credentialsRef:
      name: "http-basic-creds"
  storage: gcs-schema-storage
  storageCredentialsFrom:
    credentialsRef:
      name: "gcp-creds"

Can I choose which schemas are restored?

Currently, a SchemaRegistryRestore will restore all data present in the Storage. In a future release, it will be possible to configure a subset of the data to restore.