-
Feature
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
None
-
False
-
-
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).
- is related to
-
GITOPS-6765 Retry with newer commits after timeout
-
- Release Pending
-
- relates to
-
RFE-5764 Timing out failed sync and retrying with newer commits in OpenShift GitOps
-
- Approved
-