docs(proposal): share sync strategies across ApplicationSets

[alexymantha]

Relates to #15313 and #14458

Is also a follow up of the original proposal: #9979

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.
• 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).
• 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.

[codecov]

Codecov Report

Patch and project coverage have no change.

Comparison is base (df714ac) 50.00% compared to head (5d85889) 50.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #15408   +/-   ##
=======================================
  Coverage   50.00%   50.00%           
=======================================
  Files         266      266           
  Lines       45631    45631           
=======================================
  Hits        22818    22818           
  Misses      20581    20581           
  Partials     2232     2232           

see 1 file with indirect coverage changes

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

[alexymantha]

While writing this proposal, I realized that maybe there should be a mechanism to offer optional/opt-in CRDs for this kind of purpose. I realize that adding CRDs for a specific feature that is used by a minority is a significant drawback but that may be mitigated by making them optional.

This could also extend to other features where there is significant repetition, such as when defining sync windows. The same pattern could be used where we can specify a syncWindow ref that refers to a CRDs that defines the configuration for the sync window. This is out of scope, but I think this proposal could set a precedent for other similar features.

[jannfis]

Thank you, @alexymantha! Do you see a chance to bring up this proposal to our weekly contributors meeting for broader discussion?

[alexymantha]

Following our discussion in the contributor's meeting, I tried using Kustomize to inject the strategy in the ApplicationSets. It works, but it has a caveat that I want to highlight.

Our setup is the following: we have >10 GitOps repositories, each containing the ApplicationSets for the teams using that repo. Here's a visual example:

• gitops-org1
  • applications/ <- ApplicationSets are here
    • team1-application1.yaml
    • team2-application1.yaml
• gitops-org2
  • applications/
    • team3-application1.yaml
    • team4-application1.yaml

We can fairly easily use Kustomize to inject a SyncStrategy into the ApplicationSets but this only partly solves the duplication issue. As far as I can tell, Kustomize does not support referencing a Git repo in a patch. This means that although the strategy is not duplicated within 1 repository, it still needs to be duplicated in every other repo.

IMO due to how we structure repositories, this is a significant drawback compared to using CRDs

Note: I'm very new to Kustomize and there might be a solution I'm overlooking so I'm more than happy if you have other suggestions.

[alexymantha]

I'm wondering if, as an alternative to CRDs, we could use a ConfigMap instead. We could achieve the same behaviour with a CM, the only drawback is that it will not have the automatic validation that a CRD provides