KafkaRestore customizable backoffLimit

[markediez]

Currently, the underlying Job created by the KafkaRestore resource sets the backoffLimit to 3. At this point, it seems pretty undesirable to expect anything but 1. Because every restore appends/purges, I personally want to be intentional for each run.

[sionsmith]

Agreed — given that restores append/purge, implicit retries of a partially completed attempt are a data-duplication hazard, so we went with your reasoning fully.

In #33 (will release as 0.2.10):

• New spec.backoffLimit field on both KafkaRestore and KafkaBackup (applies to one-shot Jobs and scheduled CronJob runs).
• Restore Jobs now default to backoffLimit: 0 — exactly one attempt per restore; retries are opt-in:

apiVersion: kafkabackup.com/v1alpha1
kind: KafkaRestore
spec:
  backupRef:
    name: daily-backup
  strimziClusterRef:
    name: my-cluster
  backoffLimit: 2   # optional: opt into up to 2 pod retries (default 0)

Backup Jobs keep the previous default of 3, since re-running a backup is safe.

Combined with the #29 fix (a terminally failed restore is never re-created by the operator), a failing restore now makes exactly one attempt and reports Ready=False / RestoreFailed.

[sionsmith]

spec.backoffLimit (with the new defaults and examples for both CRDs) is now documented here: https://kafkabackup.com/strimzi-operator/job-behavior#controlling-pod-retries-specbackofflimit