Describe the bug
During startup of BRO we will see all existing Backups get processed. This is normal, however the current execution path and logging seems to have room for improvement. Specifically it should be clarified better that existing completed backups (specifically one-off) are not actually being reprocessed and taken again. As if they were it would overwrite the existing backup which is bad.
To Reproduce
N/A - to replicate just use BRO, take a few backups, and observe BRO logs when the pods startup.
Expected behavior
We will adjust the execution flow to either:
a) return faster for completed one-off backups,
b) adjust log message templates to clarify actual results,
c) reduce the default verbosity level of some logging.
Likely a mix of all 3 to find our goldilocks solution.
Describe the bug During startup of BRO we will see all existing Backups get processed. This is normal, however the current execution path and logging seems to have room for improvement. Specifically it should be clarified better that existing completed backups (specifically one-off) are not actually being reprocessed and taken again. As if they were it would overwrite the existing backup which is bad.
To Reproduce N/A - to replicate just use BRO, take a few backups, and observe BRO logs when the pods startup.
Expected behavior We will adjust the execution flow to either:
For option a - we could create a new
isSingularAndCompleteBackup(or something) and call it here: https://github.com/rancher/backup-restore-operator/blob/release/v5.0/pkg/controllers/backup/controller.go#L89To return even sooner.