Codecov Report

Attention: Patch coverage is 51.61290% with 30 lines in your changes missing coverage. Please review.

Project coverage is 53.42%. Comparing base (8849c3f) to head (d6f1083).
Report is 48 commits behind head on master.

@@            Coverage Diff             @@
##           master     #727      +/-   ##
==========================================
- Coverage   54.26%   53.42%   -0.84%     
==========================================
  Files          64       64              
  Lines        6164     6560     +396     
==========================================
+ Hits         3345     3505     +160     
- Misses       2549     2777     +228     
- Partials      270      278       +8     

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

@pjiang-dev @crenshaw-dev could we not do something similar as kubernetes/kubernetes#124191 where we'd force ownership of all fields, given that we opt-in to this behavior by adding another sync option? Something like OverwriteFieldManagers=true?

@pjiang-dev @crenshaw-dev could we not do something similar as kubernetes/kubernetes#124191 where we'd force ownership of all fields, given that we opt-in to this behavior by adding another sync option? Something like OverwriteFieldManagers=true?

@blakepettersson That PR works by manipulating managed fields and adds the 'last-applied-configuration' to all field managers before doing SSA. Kubernetes recommends against doing so and also i don't know what side affects this may have. I think its safer to use what k8s already provides. Also some users may want to keep certain field managers.

However, i do think what we can do is provide an additional annotation with SSA that allows users to specify their own field manager to migrate fields. This would replace the 'kubectl-client-side-apply' field manager in this PR with their own with something like this:
argocd.argoproj.io/sync-options: ServerSideApply=true, OverwriteFieldManager=<your-field-manager>
this way they can have the flexibility to migrate whichever field manager they choose. We would still want to keep kubectl-client-side-apply as the default for this though.

However, i do think what we can do is provide an additional annotation with SSA that allows users to specify their own field manager to migrate fields. This would replace the 'kubectl-client-side-apply' field manager in this PR with their own with something like this

Sounds good to me! Could we have that option for multiple field managers, e.g

 argocd.argoproj.io/sync-options: ServerSideApply=true, OverwriteFieldManagers=<your-field-manager-1>,<your-field-manager-1>

(the default still being kubectl-client-side-apply)

provide an additional annotation with SSA that allows users to specify their own field manager to migrate fields. This would replace the 'kubectl-client-side-apply' field manager in this PR with their own with something like this:
argocd.argoproj.io/sync-options: ServerSideApply=true, OverwriteFieldManager=<your-field-manager>
this way they can have the flexibility to migrate whichever field manager they choose. We would still want to keep kubectl-client-side-apply as the default for this though.

Unfortunately, we cannot do multiple field managers at once because 'last-applied-configuration' can only belong to one field manager at a time without manipulating managed fields. I think it won't be too much burden for users to just change the manager and re-sync if they have multiple managers though.

For this PR i will leave as is and create a follow up PR to make the field manager to migrate fields configurable to the user

For this PR i will leave as is and create a follow up PR to make the field manager to migrate fields configurable to the user

I think the only thing missing in this PR is the ability to turn this feature on/off

Added option to disable this migration using this annotation in argocd:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  syncPolicy:
    syncOptions:
      - DisableClientSideApplyMigration=true  # Feature disabled

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud