mirror of
https://github.com/vmware-tanzu/velero.git
synced 2026-01-04 20:24:02 +00:00
Document schedule skipImmediately (#8802)
Some checks failed
Run the E2E test on kind / build (push) Failing after 5m59s
Run the E2E test on kind / setup-test-matrix (push) Successful in 2s
Run the E2E test on kind / run-e2e-test (push) Has been skipped
Main CI / Build (push) Failing after 35s
Close stale issues and PRs / stale (push) Successful in 8s
Trivy Nightly Scan / Trivy nightly scan (velero, main) (push) Failing after 1m15s
Trivy Nightly Scan / Trivy nightly scan (velero-restore-helper, main) (push) Failing after 55s
Some checks failed
Run the E2E test on kind / build (push) Failing after 5m59s
Run the E2E test on kind / setup-test-matrix (push) Successful in 2s
Run the E2E test on kind / run-e2e-test (push) Has been skipped
Main CI / Build (push) Failing after 35s
Close stale issues and PRs / stale (push) Successful in 8s
Trivy Nightly Scan / Trivy nightly scan (velero, main) (push) Failing after 1m15s
Trivy Nightly Scan / Trivy nightly scan (velero-restore-helper, main) (push) Failing after 55s
Fixes #8787 Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
This commit is contained in:
@@ -71,6 +71,20 @@ type ScheduleSpec struct {
|
||||
}
|
||||
```
|
||||
|
||||
**Note:** The Velero server automatically patches the `skipImmediately` field back to `false` after it's been used. This is because `skipImmediately` is designed to be a one-time operation rather than a persistent state. When the controller detects that `skipImmediately` is set to `true`, it:
|
||||
1. Sets the flag back to `false`
|
||||
2. Records the current time in `schedule.Status.LastSkipped`
|
||||
|
||||
This "consume and reset" pattern ensures that after skipping one immediate backup, the schedule returns to normal behavior for subsequent runs. The `LastSkipped` timestamp is then used to determine when the next backup should run.
|
||||
|
||||
```go
|
||||
// From pkg/controller/schedule_controller.go
|
||||
if schedule.Spec.SkipImmediately != nil && *schedule.Spec.SkipImmediately {
|
||||
*schedule.Spec.SkipImmediately = false
|
||||
schedule.Status.LastSkipped = &metav1.Time{Time: c.clock.Now()}
|
||||
}
|
||||
```
|
||||
|
||||
`LastSkipped` will be added to `ScheduleStatus` struct to track the last time a schedule was skipped.
|
||||
```diff
|
||||
// ScheduleStatus captures the current state of a Velero schedule
|
||||
@@ -97,6 +111,8 @@ type ScheduleStatus struct {
|
||||
}
|
||||
```
|
||||
|
||||
The `LastSkipped` field is crucial for the schedule controller to determine the next run time. When a backup is skipped, this timestamp is used instead of `LastBackup` to calculate when the next backup should occur, ensuring the schedule maintains its intended cadence even after skipping a backup.
|
||||
|
||||
When `schedule.spec.SkipImmediately` is `true`, `LastSkipped` will be set to the current time, and `schedule.spec.SkipImmediately` set to nil so it can be used again.
|
||||
|
||||
The `getNextRunTime()` function below is updated so `LastSkipped` which is after `LastBackup` will be used to determine next run time.
|
||||
|
||||
@@ -9,6 +9,22 @@ The `Schedule` API type is used as a repeatable request for the Velero server to
|
||||
Velero Server will start the backup process. It will then wait for the next valid point of the given cron expression and execute the backup
|
||||
process on a repeating basis.
|
||||
|
||||
### Schedule Control Fields
|
||||
|
||||
The Schedule API provides several fields to control backup execution behavior:
|
||||
|
||||
- **paused**: When set to `true`, the schedule is paused and no new backups will be created. When set back to `false`, the schedule is unpaused and will resume creating backups according to the cron schedule.
|
||||
|
||||
- **skipImmediately**: Controls whether to skip an immediate backup when a schedule is created or unpaused. By default (when `false`), if a backup is due immediately upon creation or unpausing, it will be executed right away. When set to `true`, the controller will:
|
||||
1. Skip the immediate backup
|
||||
2. Record the current time in the `lastSkipped` status field
|
||||
3. Automatically reset `skipImmediately` back to `false` (one-time use)
|
||||
4. Schedule the next backup based on the cron expression, using `lastSkipped` as the reference time
|
||||
|
||||
- **lastSkipped**: A status field (not directly settable) that records when a backup was last skipped due to `skipImmediately` being `true`. The controller uses this timestamp, if more recent than `lastBackup`, to calculate the next scheduled backup time.
|
||||
|
||||
This "consume and reset" pattern for `skipImmediately` ensures that after skipping one immediate backup, the schedule returns to normal behavior for subsequent runs without requiring user intervention.
|
||||
|
||||
## API GroupVersion
|
||||
|
||||
Schedule belongs to the API group version `velero.io/v1`.
|
||||
@@ -32,6 +48,10 @@ metadata:
|
||||
spec:
|
||||
# Paused specifies whether the schedule is paused or not
|
||||
paused: false
|
||||
# SkipImmediately specifies whether to skip backup if schedule is due immediately when unpaused or created.
|
||||
# This is a one-time flag that will be automatically reset to false after being consumed.
|
||||
# When true, the controller will skip the immediate backup, set LastSkipped timestamp, and reset this to false.
|
||||
skipImmediately: false
|
||||
# Schedule is a Cron expression defining when to run the Backup
|
||||
schedule: 0 7 * * *
|
||||
# Specifies whether to use OwnerReferences on backups created by this Schedule.
|
||||
@@ -189,6 +209,8 @@ status:
|
||||
phase: ""
|
||||
# Date/time of the last backup for a given schedule
|
||||
lastBackup:
|
||||
# Date/time when a backup was last skipped due to skipImmediately being true
|
||||
lastSkipped:
|
||||
# An array of any validation errors encountered.
|
||||
validationErrors:
|
||||
```
|
||||
|
||||
@@ -9,6 +9,22 @@ The `Schedule` API type is used as a repeatable request for the Velero server to
|
||||
Velero Server will start the backup process. It will then wait for the next valid point of the given cron expression and execute the backup
|
||||
process on a repeating basis.
|
||||
|
||||
### Schedule Control Fields
|
||||
|
||||
The Schedule API provides several fields to control backup execution behavior:
|
||||
|
||||
- **paused**: When set to `true`, the schedule is paused and no new backups will be created. When set back to `false`, the schedule is unpaused and will resume creating backups according to the cron schedule.
|
||||
|
||||
- **skipImmediately**: Controls whether to skip an immediate backup when a schedule is created or unpaused. By default (when `false`), if a backup is due immediately upon creation or unpausing, it will be executed right away. When set to `true`, the controller will:
|
||||
1. Skip the immediate backup
|
||||
2. Record the current time in the `lastSkipped` status field
|
||||
3. Automatically reset `skipImmediately` back to `false` (one-time use)
|
||||
4. Schedule the next backup based on the cron expression, using `lastSkipped` as the reference time
|
||||
|
||||
- **lastSkipped**: A status field (not directly settable) that records when a backup was last skipped due to `skipImmediately` being `true`. The controller uses this timestamp, if more recent than `lastBackup`, to calculate the next scheduled backup time.
|
||||
|
||||
This "consume and reset" pattern for `skipImmediately` ensures that after skipping one immediate backup, the schedule returns to normal behavior for subsequent runs without requiring user intervention.
|
||||
|
||||
## API GroupVersion
|
||||
|
||||
Schedule belongs to the API group version `velero.io/v1`.
|
||||
@@ -32,6 +48,10 @@ metadata:
|
||||
spec:
|
||||
# Paused specifies whether the schedule is paused or not
|
||||
paused: false
|
||||
# SkipImmediately specifies whether to skip backup if schedule is due immediately when unpaused or created.
|
||||
# This is a one-time flag that will be automatically reset to false after being consumed.
|
||||
# When true, the controller will skip the immediate backup, set LastSkipped timestamp, and reset this to false.
|
||||
skipImmediately: false
|
||||
# Schedule is a Cron expression defining when to run the Backup
|
||||
schedule: 0 7 * * *
|
||||
# Specifies whether to use OwnerReferences on backups created by this Schedule.
|
||||
@@ -189,6 +209,8 @@ status:
|
||||
phase: ""
|
||||
# Date/time of the last backup for a given schedule
|
||||
lastBackup:
|
||||
# Date/time when a backup was last skipped due to skipImmediately being true
|
||||
lastSkipped:
|
||||
# An array of any validation errors encountered.
|
||||
validationErrors:
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user