You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, executing the command argocd app sync --dry-run affects both the application’s state and the internal metrics exposed by ArgoCD (eg: argocd_app_info).
The main issue is that if there are alerts based on these metrics, and the dry-run execution identifies an error (e.g., a change that violates a Kyverno policy or an invalid CRD schema), the application state changes to SyncErr. This also updates the metrics, which can potentially trigger alerts based on these metrics.
For example:
# alert manager alert definition
- alert: ArgoCDApplicationUnknownexpr: sum by (cluster) (argocd_app_info{sync_status="Unknown"}) > 0for: 15m
...
Since the definition of a dry-run is to execute requests without persistence, I wonder if it makes sense to handle it in a way that ensures no changes are made.
Alternatively, adding a dry_run label to differentiate operational requests from dry-run requests could also be an option (a similar change has been proposed for kyverno link).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello! I’d like to hear your thoughts.
Currently, executing the command
argocd app sync --dry-run
affects both the application’s state and the internal metrics exposed by ArgoCD (eg:argocd_app_info
).The main issue is that if there are alerts based on these metrics, and the dry-run execution identifies an error (e.g., a change that violates a Kyverno policy or an invalid CRD schema), the application state changes to
SyncErr
. This also updates the metrics, which can potentially trigger alerts based on these metrics.For example:
Since the definition of a
dry-run
is to execute requests without persistence, I wonder if it makes sense to handle it in a way that ensures no changes are made.Alternatively, adding a dry_run label to differentiate operational requests from dry-run requests could also be an option (a similar change has been proposed for kyverno link).
What do you think? Thanks!
Beta Was this translation helpful? Give feedback.
All reactions