Add status patching retry configuration design.

[kaovilai]

Signed-off-by: Tiger Kaovilai [email protected]

Thank you for contributing to Velero!

Please add a summary of your change

Does your change fix a particular issue?

Design for #7207

Please indicate you've done the following:

• Accepted the DCO. Commits without the DCO will delay acceptance.
• Created a changelog file or added /kind changelog-not-required as a comment on this pull request.
• Updated the corresponding documentation in site/content/docs/main.

[kaovilai]

/kind changelog-not-required

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 59.07%. Comparing base (d9ca147) to head (eebc4af).
Report is 95 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8063      +/-   ##
==========================================
+ Coverage   58.88%   59.07%   +0.18%     
==========================================
  Files         351      364      +13     
  Lines       29367    30307     +940     
==========================================
+ Hits        17294    17904     +610     
- Misses      10639    10960     +321     
- Partials     1434     1443       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kaovilai]

Maybe this should also cover #7799?

[sseago]

@kaovilai I think 7799 should be handled separately. That addresses non-APIServer errors, where retry isn't required, and where status updates are possible -- i.e. that issue is where we're not trying to update status but we could. Here we have the opposite problem -- we're trying to update status but can't.

[sseago]

I'm not sure there are cases here where the transition is to Failed or FailedValidation -- FailedValidation -- in those cases, I think we're mostly moving from New, so a future reconcile can just handle it normally. Although maybe retry is still appropriate there?

[kaovilai]

Future reconcile isn't generally handled. So we should still retry or it can be stuck in a phase other than new. New or "" is the only phase being retried via future reconcile.

	switch restore.Status.Phase {
	case "", api.RestorePhaseNew:
		// only process new restores
	default:
		r.logger.WithFields(logrus.Fields{
			"restore": kubeutil.NamespaceAndName(restore),
			"phase":   restore.Status.Phase,
		}).Debug("Restore is not handled")
		return ctrl.Result{}, nil
	}

[sseago]

@kaovilai well the various WaitingForPluginOperations will also be retried on future reconcile, since the backup/restore operations controller re-reconcile to check progress on a periodic basis rather than on a cr-updated basis.

[sseago]

But those aren't handled by the backup/restore controller, which only handles new CRs.

[sseago]

I guess we could retry for WaitingForPluginOperations->final -- but since the backup/restore operations controllers re-reconcile all WaitingForPluginOperations CRs every 10 seconds by default anyway, it's probably unnecessary. Finalizing CRs definitely need retry though.

[kaovilai]

Easily removable if deemed unnecessary and already covered by opreation controllers

[kaovilai]

feedbacks from Shubham

[kaovilai]

fixed DCO