Value Statement

If the user wants to restore some data on the hub, it would first need to delete the BackupSchedule because a restore cannot be executed while the scheduled backup is running.

With this change, the user can pause the BackupSchedule temporarily ( instead of deleting it ) , run the restore operation, then enable the BackupSchedule again 

Scenario:

• User has hub1 and hub2
• User wants to move some of the managed clusters from hub1 to hub2
• User updates hub2 storage location to point to hub1 so it can restore the backup data from hub1
• Without this change, the user needs to delete the BackupSchedule on hub2 before being able to run a restore operation with the data from hub1
• With this change, the user sets paused=true on the BackupSchedule resource on hub2. This removes the hub2 schedules, so now the user can update the storage location to hub1, restore the data, update the storage location back to hub2's storage location, then up-pause the BackupSchedule on hub2

Definition of Done for Engineering Story Owner (Checklist)

• BackupSchedule can be Paused

Changes:

• • introduces a new optional, BackupSchedule spec option, named paused; default value is false. If paused=true, the BackupSchedule doesn't generate any velero schedules, so is not generating any backups. When an existing, Enabled, BackupSchedule property changes to paused=true, all generated velero Scedules are deleted and the status of the BackupSchedule is changed to Paused
  • a BackupSchedule is considered not to be running if BackupSchedule is Paused
  • you can execute restore operations on the hub if the BackupSchedule is Paused
  • you can create a BackupSchedule with paused=true if a restore is still active
  • when checking for a BackupCollision situation, instead of verifying if the BackupSchedule creationTimestamp is older than the last cluster restore operation, it checks if the velero.Schedule.creationTimestamp( Schedule created by the BackupSchedule)  is older than the last cluster restore operation. This is because the BackupSchedule creationTimestamp is no longer relevant when checking the start time of a backup operation, since the BackupSchedule can be paused ( removing the velero schedules, so not generating backups ) and then unpaused ( starting generating velero schedules and backups )

Development Complete

• The code is complete.
• Functionality is working.
• Any required downstream Docker file changes are made.

Tests Automated

• [x] Unit/function tests have been automated and incorporated into the
  build.
• [ ] 100% automated unit/function test coverage for new or changed APIs.

Secure Design

• Security has been assessed and incorporated into your threat model. 

Multidisciplinary Teams Readiness

• [x] Create an informative documentation issue using the Customer https://issues.redhat.com/browse/ACM-13263

Portal Doc template that you can access from [The Playbook](

https://docs.google.com/document/d/1YTqpZRH54Bnn4WJ2nZmjaCoiRtqmrc2w6DdQxe_yLZ8/edit#heading=h.9fvyr2rdriby),

and ensure doc acceptance criteria is met.

• Call out this sentence as it's own action:

• [x] Link the development issue to the doc issue.

Support Readiness

• [ NA] The must-gather script has been updated.