docs: appset progressive rollout strategy proposal (#9437)

[wmgroot]

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).
• 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? No
• I've updated documentation as required by this PR.
• Optional. My organization is added to USERS.md.
• 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).

Closes #9437
Pull Request: #10048

[codecov]

Codecov Report

Base: 45.60% // Head: 46.13% // Increases project coverage by +0.53% 🎉

Coverage data is based on head (0728e25) compared to base (309654c).
Patch has no changes to coverable lines.

❗ Current head 0728e25 differs from pull request most recent head aed4b7d. Consider uploading reports for the commit aed4b7d to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #9979      +/-   ##
==========================================
+ Coverage   45.60%   46.13%   +0.53%     
==========================================
  Files         237      228       -9     
  Lines       28914    27960     -954     
==========================================
- Hits        13185    12900     -285     
+ Misses      13913    13314     -599     
+ Partials     1816     1746      -70     

Impacted Files	Coverage Δ
cmd/argocd/commands/version.go	0.00% <0.00%> (-38.15%)	⬇️
util/grpc/useragent.go	45.83% <0.00%> (-10.42%)	⬇️
util/cache/redis.go	48.83% <0.00%> (-6.43%)	⬇️
util/grpc/errors.go	47.16% <0.00%> (-5.38%)	⬇️
cmd/argocd/commands/root.go	2.00% <0.00%> (-3.89%)	⬇️
server/application/websocket.go	7.54% <0.00%> (-3.57%)	⬇️
pkg/apis/application/v1alpha1/app_project_types.go	59.53% <0.00%> (-3.30%)	⬇️
util/cmp/stream.go	52.23% <0.00%> (-2.72%)	⬇️
util/dex/dex.go	57.14% <0.00%> (-1.48%)	⬇️
server/server.go	51.54% <0.00%> (-1.39%)	⬇️
... and 58 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[crenshaw-dev]

This is really well written and thought out. I think my main concerns are around handling of "partial rollouts" (where some, but not all, apps receive updates in a given reconciliation cycle).

The only other question mark lingering in my mind is how this compares with / would interact with an Application dependency DAG (which is something I hope we'll implement). My instinct is that this will serve sometimes-intersecting, but not identical purposes. I just haven't thought it out very far.

Thanks very much for your effort on this!

[romuduck]

Stupid question: i get how we could control how applications are rolled out when updating the parent appset, but I'm not so sure how to do the same when applications repo get updated...
I guess we need to disable auto sync but as well ensure all generated apps watch the same repo/branch no?

[wmgroot]

I'm not so sure how to do the same when applications repo get updated

I believe this concern should now be addressed with the addition of a RollingSync strategy that triggers syncs based on noticing Applications that are OutOfSync.

[agaudreault]

Congrats on the work! ❤️ 🎉 Not sure if this is the right issue for improvement suggestions. If not, let me know!

What do you think if the RollingSync strategy was a CRD on it's own? We have a lot of applicationSet, and they would pretty much all use the same matchExpression, etc. to define common deployment patterns. So we would like to reduce the level of copy-paste necessary.

I think it would be useful to have the RollingSync strategy defined once, and we can refer to it by its key. Something like this:

apiVersion: argoproj.io/v1alpha1
kind: RolloutStrategy
metadata:
  name: default-progressive-rollout
  namespace: argocd
spec:
  description: Deploys in dev, then QA, then prod   
  type: RollingSync
  rollingSync:
    steps:
      - matchExpressions:
          - key: env
            operator: In
            values:
              - env-dev
        #maxUpdate: 100%  # if undefined, all applications matched are updated together (default is 100%)
      - matchExpressions:
          - key: env
            operator: In
            values:
              - env-qa
        maxUpdate: 0      # if 0, no matched applications will be updated
      - matchExpressions:
          - key: env
            operator: In
            values:
              - env-prod
        maxUpdate: 10%    # maxUpdate supports both integer and percentage string values (rounds down, but floored at 1 Application for >0%)

Then in the ApplicationSet, you would refer to it like this. It should still be possible to define an inline strategy IMO.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
  strategy:
    type: RolloutStrategy  # could also be RollingSync or AllAtOnce
    name: default-progressive-rollout # Necessary field when type=RolloutStrategy