-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(backup): delete backup in the backupstore asynchronously #3038
base: master
Are you sure you want to change the base?
feat(backup): delete backup in the backupstore asynchronously #3038
Conversation
c809fd8
to
707f44c
Compare
Test PlanNormal Case
Error Case (use nfs)
Controller Crashes Case (use nfs)
|
707f44c
to
4e74975
Compare
There is a regression |
4e74975
to
5e21ded
Compare
Fixed. |
5e21ded
to
cf4419c
Compare
change the backoff time to |
@ChanYiLin Is it ready for review? |
Yes, it is ready for review. |
Hi @derekbit |
if !backupDeleted { | ||
return nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR introduces deletingBackoff
for handling deletion backoff. Since handleErr()
can also achieve backoff after returning an error if the backup has not been deleted yet. Can we remove deletingBackoff and leverage handleErr() instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer not to do that, it is not an error after all.
Besides, inside the handleErr
we even print the logs Failed to sync Longhorn backup
I think that might confuse the users.
We actually use this backoff a lot in our controllers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another point is that, we can control the backOff period with this backoff
But with using k8s workqueue, we can't set different backOff time for this case from other error cases.
ref: longhorn/longhorn 8746 Signed-off-by: Jack Lin <jack.lin@suse.com>
cf4419c
to
25dcfe8
Compare
Hi @derekbit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, LGTM
deletingMapLock: &sync.Mutex{}, | ||
inProgressDeletingMap: map[string]*DeletingStatus{}, | ||
|
||
deletingBackoff: flowcontrol.NewBackOff(time.Minute*1, time.Hour*24), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make time.Minute*1, time.Hour*24
as a constant
// We should consider the backup exists even the backupInfo is nil when it is in progress. | ||
backupInfo, err := backupTargetClient.BackupGet(backupURL, backupTargetClient.Credential) | ||
if err != nil && !types.ErrorIsNotFound(err) && !types.ErrorIsInProgress(err) { | ||
log.WithError(err).Debugf("failed to check backup %v in the backupstore", backup.Name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
log.WithError(err).Debugf("failed to check backup %v in the backupstore", backup.Name) | |
log.WithError(err).Debugf("Failed to check backup %v in the backupstore", backup.Name) |
return false | ||
} | ||
if _, err := bc.ds.UpdateBackupStatus(backup); err != nil { | ||
log.WithError(err).Debugf("Backup %v update status error", backup.Name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
log.WithError(err).Debugf("Backup %v update status error", backup.Name) | |
log.WithError(err).Errorf("Backup %v update status error", backup.Name) |
ref: longhorn/longhorn#8746
follow LEP to implement: longhorn/longhorn#9152