Server-side apply

[sathieu]

See argoproj/argo-cd#2267

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

No Coverage information
4.5% Duplication

[alexmt]

LGTM! Thank you @sathieu !

@leoluz can you please take a look as well? I think you know more about server side apply than me.

[codecov]

Codecov Report

Merging #363 (811ec7f) into master (a586397) will decrease coverage by 0.03%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##           master     #363      +/-   ##
==========================================
- Coverage   54.23%   54.20%   -0.04%     
==========================================
  Files          41       41              
  Lines        3055     3059       +4     
==========================================
+ Hits         1657     1658       +1     
- Misses       1235     1238       +3     
  Partials      163      163              

Impacted Files	Coverage Δ
pkg/sync/common/types.go	58.82% <ø> (ø)
pkg/utils/kube/resource_ops.go	0.00% <0.00%> (ø)
pkg/sync/sync_context.go	71.10% <50.00%> (-0.19%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a586397...811ec7f. Read the comment docs.

[leoluz]

Thanks for the PR @sathieu

What is the manager associated with the patch in the resources metadata.managedFields attribute when you sync in ArgoCD with server-side apply enabled?

When using server-side apply it is important to define the fieldManager to set the fields ownership to the proper actor. This is a required field for application/apply-patch patches which is the one used by SSA.

Im not sure if this the behaviour using the go client but in kubectl CLI if we don't provide the fieldManager it will automatically assign the manager as "kubectl" which is also undesirable.

I believe that we should expose a configuration to also set the manager when choosing server-side apply.

[jannfis]

I believe that we should expose a configuration to also set the manager when choosing server-side apply.

I agree. Ideally, multiple consumers of gitops-engine (e.g. Argo CD instances) would be able to manage different parts of the same resource as well, as this is one of the main advantages of SSA. For Argo CD, we would need a unique identifier (maybe argocd-<installation_namespace> as the manager.

Also I wonder about what happens with the applicationInstance label, currently used to identify (exclusively) managed resources. Will Argo CD still set that label on a resource that is managed using Server-Side-Apply? How could we have multiple instances of Argo CD manage different parts of the same resource without them overwriting the label, or triggering a shared resource warning?

[varunsatokar]

When is this feature planned for release?

[leoluz]

@varunsatokar We are currently discussing the proposal and analysing the impact it will bring.
You are welcome to participate in the review if you have something to add:
argoproj/argo-cd#8812

[leoluz]

FYI, I rebased this branch with upstream/master to address a conflict and fix CI build

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

No Coverage information
4.7% Duplication

[leoluz]

Reached an agreement with @alexmt to merge this PR as-is and continue the work to implement argoproj/argo-cd#8812 in a new branch