Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-8855

Retry with newer commits after timeout

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • None
    • False
    • Hide

      None

      Show
      None
    • False

      There is upstream work in progress to add support for retrying a sync with a newer commit after a timeout. This feature is to support the upstream work, help get it merged, and include it in the operator. 

      Goals

      Today if a sync times out, the application goes out of sync. If there have been more commits to the repo since the sync was initiated, it would be useful to have the option for the sync to try again with the latest commit. 

      Requirements

      Requirements Notes IS MVP
      Add an option to retry syncs after timeouts if there have been newer commits to the repo    
      Feature is available in the operator     
           

      Use Cases

      Case 03872873, SBB:

      We use ArgoCD 2.9.15 for managing OpenShift namespaces. All definitions are Helm charts. As we use git ops only, we want to avoid (and forbid) any manual interaction with ArgoCD, like pressing "sync" or "terminate" buttons. 

      Now if there is a problem with the deployment and OpenShift keeps waiting for resources forever (for example due to missconfiguration), ArgoCD is stuck in "syncing" status. Even if you push a new version, ArgoCD is stays busy with syncing the previous version.

      We would like to operate ArgoCD in a safe way to protect it from this situation. Ideas we discussed:

      1) Allow specification of a timeout, after which the sync stops

      2) Allow pushing a new version, which cancels the previous sync

      Out of scope

      Additional upstream work outside the in-flight PR in the upstream

      Dependencies

      None known

      Background, and strategic fit

      Upstream PR in progress but has stalled: https://github.com/argoproj/argo-cd/pull/15603 

      Assumptions

      None known

      Customer Considerations

      See use cases section

      Documentation/QE Considerations

      Docs needed: 

      • Upstream docs update with the new feature
      • Downstream release notes

      Impact

      None known

      Related Architecture/Technical Documents

      N/A

      Definition of Ready

      • The objectives of the feature are clearly defined and aligned with the business strategy.
      • All feature requirements have been clearly defined by Product Owners.
      • The feature has been broken down into epics.
      • The feature has been stack ranked.
      • Definition of the business outcome is in the Outcome Jira (which must have a parent Jira).

       

              Unassigned Unassigned
              halawren@redhat.com Harriet Lawrence (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: