feat: Annotation to support per app refresh timeouts (soft & hard) - #9499

[4ch3los]

Hey together,

with this pr i added two new annotations to control the refresh timeouts(soft and hard) on a per app basis. This should solve the issue #9499 and also allow users to specify hard refresh intervals, when using plugins like argocd-vault-plugin, to refresh changed secrets(https://argocd-vault-plugin.readthedocs.io/en/stable/usage/#refreshing-values-from-secrets-managers)

Fixes #9499

Checklist:

• Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
• The title of the PR states what changed and the related issues number (used for the release note).
• The title of the PR conforms to the Toolchain Guide
• I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
• I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
• Does this PR require documentation updates?
• I've updated documentation as required by this PR.
• I have signed off all my commits as required by DCO
• I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
• My build is green (troubleshooting builds).
• My new feature complies with the feature status guidelines.
• I have added a brief description of why this PR is necessary and/or what this PR solves.
• Optional. My organization is added to USERS.md.
• Optional. For bug fixes, I've indicated what older releases this fix should be cherry-picked into (this may or may not happen depending on risk/complexity).

[bunnyshell]

✅ Preview Environment deployed on Bunnyshell

Component	Endpoints
argocd	https://argocd-yuzbn3.bunnyenv.com/
argocd-ttyd	https://argocd-web-cli-yuzbn3.bunnyenv.com/

See: Environment Details | Pipeline Logs

Available commands (reply to this comment):

• 🔴 /bns:stop to stop the environment
• 🚀 /bns:deploy to redeploy the environment
• ❌ /bns:delete to remove the environment

[codecov]

Codecov Report

Attention: Patch coverage is 60.00000% with 4 lines in your changes missing coverage. Please review.

Please upload report for BASE (master@c216ece). Learn more about missing BASE report.
Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
controller/appcontroller.go	60.00%	2 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##             master   #20422   +/-   ##
=========================================
  Coverage          ?   56.02%           
=========================================
  Files             ?      322           
  Lines             ?    44820           
  Branches          ?        0           
=========================================
  Hits              ?    25109           
  Misses            ?    17107           
  Partials          ?     2604           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jannfis]

Thanks for your PR.

I tend to think that giving users control over the refresh time would not be a good idea, as this will put unexpected strain on the application controller and repository server - especially in the case of a hard refresh.

I'm also not sure yet whether a setting such as this should be an annotation, or whether it is better housed in the spec.

IMHO, we should think this through, and come up with a proper way to allow/disallow users from actually leveraging this setting (e.g. by having a flag in the AppProject).

TL;DR: I think this needs further discussion.

[4ch3los]

Thanks for your PR.

I tend to think that giving users control over the refresh time would not be a good idea, as this will put unexpected strain on the application controller and repository server - especially in the case of a hard refresh.

I'm also not sure yet whether a setting such as this should be an annotation, or whether it is better housed in the spec.

IMHO, we should think this through, and come up with a proper way to allow/disallow users from actually leveraging this setting (e.g. by having a flag in the AppProject).

TL;DR: I think this needs further discussion.

Hey! I absolutely understand that having to low timeouts will harm performance, but at the moment, the user only has the option to set it on the global level(https://github.com/argoproj/argo-cd/blob/master/cmd/argocd-application-controller/commands/argocd_application_controller.go#L235) which can even more easily harm performance

Regarding the way of implementation, i just used annotations cause there was already a annotation for forcing a refresh, but i can also adjust it and define it via spec :)

[jannfis]

I think there is a subtle difference: It's not the user who has control over the global setting, but the Argo CD administrator or operator. With an annotation on the application, that control is handed over to a regular, low-privileged user.

[agaudreault]

I also think this needs further discussion. I agree with @jannfis on the different arguments above. Argo CD is a GitOps tool and react to git changes.

I think if there is a need to monitor an external non-git systems, like an artifact registry to detect non-gitops changes, this can be done by another controller. Then that controller can request a refresh of the application with the current annotation/api when it detects changes that would require a refresh. A naive implementation would be to do it periodically

[4ch3los]

I think there is a subtle difference: It's not the user who has control over the global setting, but the Argo CD administrator or operator. With an annotation on the application, that control is handed over to a regular, low-privileged user.

Ahh yeah, our perspective as serviceprovider, where we use argocd to baseline and are admin & user, there was not a big difference. But a global setting to limit the options or disable it overall should be usefull.

I also think this needs further discussion. I agree with @jannfis on the different arguments above. Argo CD is a GitOps tool and react to git changes.

I think if there is a need to monitor an external non-git systems, like an artifact registry to detect non-gitops changes, this can be done by another controller. Then that controller can request a refresh of the application with the current annotation/api when it detects changes that would require a refresh. A naive implementation would be to do it periodically

For issues like the linked, this could definitely be a option. Regarding the second usecase with config management plugins(like vault secret plugin), where the same source can result in a different result based on external conditions, this would need a whole restructuring of the plugin design from my perspective.