AppSet: Allow configuring ignoreApplicationDifferences globally

[leoluz]

Summary

Introduce a new ApplicationSet controller configuration to allow defining ignoreApplicationDifferences fields globally.

Motivation

Companies often define internal labels and annotations to categorize their Argo CD Applications. Those labels/annotations can be managed by external controllers. When the Argo CD Application is managed by an ApplicationSet it causes conflict making both controller to "fight" for the desired state. The ApplicationSet spec defines the field ignoreApplicationDifferences that can be used to avoid this issue. However, differently from the Application controller, the ApplicationSet controller doesn't expose a configuration to globally configure the ignored differences. This is causes issues when ApplicationSets aren't managed centralized causing configuration inconsistencies.

Proposal

Similarly to the Application controller, the ApplicationSet controller should expose a configuration to allow Argo CD Admins to globally configure ignoreApplicationDifferences.

The new configuration can be provided as part of the argocd-cmd-params-cm configmap.
Example:

applicationsetcontroller.ignoreApplicationDifferences.jqPathExpressions: ".metadata.labels[some-company/some-label],.metadata.labels[some-company/another-label]"
applicationsetcontroller.ignoreApplicationDifferences.jsonPointers: "/spec/syncPolicy"
applicationsetcontroller.ignoreApplicationDifferences.managedFieldsManagers: "manager1,manager2"

[agaudreault]

I think 2 requirements for this proposal is to

1. Use the same configuration format currently used by https://argo-cd.readthedocs.io/en/stable/user-guide/diffing/#system-level-configuration
2. Support managedFieldsManagers

[leoluz]

@agaudreault I agree about the managedFieldsManagers. Updated the proposal

Use the same configuration format currently used by https://argo-cd.readthedocs.io/en/stable/user-guide/diffing/#system-level-configuration

I don't think we can do that. The Application controller configurations are living in the configmap and directly consumed by the controller as yamls. On the other hand, all ApplicationSet configurations are provided as env vars consumed from the argocd-cmd-params-cm. The Application controller configs are embedded yamls that can't be provided as env vars. For this reason the format needs to be slightly different in this case.

[crenshaw-dev]

Any interest in breaking that pattern? Env vars were great when the appset controller was in labs, but maybe it time to transition to a more first-class config experience.

[leoluz]

Any interest in breaking that pattern?

@crenshaw-dev I don't see big advantages in refactoring this code compared with the amount of effort that it would require to implement and stabilize it. If we want to spend time improving existing config patterns, maybe dedicating effort on the Application controller accepting yamls as strings would bring more concrete benefits.

Env vars were great when the appset controller was in labs, but maybe it time to transition to a more first-class config experience.

Users already have a first-class config experience. All AppSet controller configs are available in the argocd-cmd-params-cm configmap. How that config is propagated to the controller is "invisible" to the user.