[Argo-Workflows] Lesson17: Retry strategy

Khi một task bị fail thì chúng ta sẽ cần phải retry lại task đó 1 vài lần.
chẳng hạn, như bạn connect vào Database nếu không được thì bạn sẽ muốn retry lại.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: wf-retrystrategy-
spec:
  entrypoint: dag-template
  arguments:
    parameters:
    - name: messageA
      value: A

  templates:
  - name: dag-template
    inputs:
      parameters:
      - name: messageA
    dag:
      tasks:
      - name: Task1
        arguments:
          parameters: [{name: text, value: "{{inputs.parameters.messageA}}"}]
        template: task-decision
      - name: TaskA
        template: task-a
        depends: Task1.Succeeded
        when: "{{tasks.Task1.outputs.result}} == A"


  - name: task-decision
    inputs:
      parameters: 
      - name: text
    script:
      image: python:3.8-slim
      command: 
      source: |
        p = "{{inputs.parameters.text}}"
        print(p)

  - name: task-a
    retryStrategy:
      limit: 10
      retryPolicy: "Always"
      backoff:
        duration: "1"
        factor: 2
        maxiDuration: "1m"
    script:
      image: python:3.8-slim
      command: 
      source: |
        print("Task A was executed)

Certainly! The retryStrategy section in your Argo Workflow task definition specifies how many times the task will be retried if it fails and how the retries will be spaced out.

Here’s a breakdown of the different parameters:

• limit: This parameter specifies how many times the task will be retried before giving up. In this case, the limit is set to 2, which means that the task will be executed up to 3 times in total (the initial attempt plus two retries).
• retryPolicy: This parameter specifies when the task should be retried. In this case, the value is set to “Always”, which means that the task will be retried regardless of the reason for the failure (e.g., a network error or a syntax error in the script).
• backoff: This parameter specifies how the retries will be spaced out. Specifically, it defines the duration of each retry attempt, the factor by which the duration will increase with each subsequent retry, and the maximum duration for any single retry.
  • duration: This parameter specifies the initial duration for the first retry attempt. In this case, the duration is set to “1”, which means that the first retry attempt will be executed after a one-second delay.
  • factor: This parameter specifies the multiplier used to calculate the duration of each subsequent retry attempt. In this case, the factor is set to 2, which means that the duration of each subsequent retry attempt will be double the duration of the previous attempt.
  • maxDuration: This parameter specifies the maximum duration for any single retry attempt. In this case, the maximum duration is set to “1m”, which means that the duration of each retry attempt will not exceed one minute.

Together, these parameters define a retry strategy that will attempt to execute the task up to 3 times, with each retry attempt spaced out by an exponentially increasing delay, up to a maximum of one minute per retry. This strategy can be useful in scenarios where the task may encounter intermittent errors, network issues or where the task’s environment may not be stable or consistent.