Cap on retryStrategy backoff?

[eiriklid]

Is it possible to cap the backoff in retryStrategy?

I want to have quick retries in the beginning, but not have to have a exponential backoff as well.
The Pod Backoff Failure Policy from Kubernetes have been ideal:

... Job are recreated by the Job controller with an exponential back-off delay (10s, 20s, 40s ...) capped at six minutes.

[agilgur5]

That's what the maxDuration field is for, per the backoff example.

Argo's backoff also inherits from k8s apimachinery's wait package

[eiriklid]

Not according to the documentation.

MaxDuration is the maximum amount of time allowed for a workflow in the backoff strategy. It is important to note that if the workflow template includes activeDeadlineSeconds, the pod's deadline is initially set with activeDeadlineSeconds. However, when the workflow fails, the pod's deadline is then overridden by maxDuration. This ensures that the workflow does not exceed the specified maximum duration when retries are involved.

When I set

retryStrategy:
      when: "Failed"
      limit: 100
      backoff:
        duration: 10s
        factor: 2
        maxDuration: 6m

The workflow is killed after 6 minutes, while with a Kubernetes Job/Cronjob it would retry after 10, 20, 40, 80, 160, 320, 360, 360, ... until it hits the limit or activeDeadlineSeconds.

[agilgur5]

Not according to the documentation.

Yea, my bad, you're correct. I keep mixing up what maxDuration means and that specific doc was recently updated actually: #13068.
Now that I'm remembering, I called out this specific field as super unclear in feedback when I beta tested the CNCF Argo Certification back in January 😅 (there was a question specifically on it and I advocated to remove that question)

Argo's backoff also inherits from k8s apimachinery's wait package

In another layer of confusion, the Argo Backoff spec actually differs from apimachinery's Backoff apparently. In apimachinery, Backoff.Cap sounds like what you're looking for, literally.
Looking at the blames, it's possible that Cap didn't exist at the time Argo's Backoff was created: kubernetes/apimachinery@e52d7e0 / kubernetes/kubernetes#71088 was a year before #1782, but using an older k8s version might've prevented usage.

Would you like to file a feature request for this? Can reference this discussion and the above
EDIT: Feature request was filed in #13772

[eiriklid]

I would very much like a feature request for this! :) Thank you for your thorough investigation on the issue. How do we proceed with creating the feature request?

[Joibel]

Raise an issue at https://github.com/argoproj/argo-workflows/issues by choosing New Issue and then Feature. Please ensure you refer to this discussion, which you can do by putting the text #13584 in the issue.

[agilgur5]

Feature request was filed in #13772