fix: auto migrate kubectl-client-side-apply fields for SSA

[pjiang-dev]

fixes https://github.com/argoproj/argo-cd/issues/23214

When performing a Sync with ServerSideApply we will check if there is a kubectl-client-side-apply manager and run a client side apply with the field manager kubectl-client-side-apply. This will make the last-applied-confiugration field to be owned by kubectl-client-side-apply and then once the Sync with ServerSideApply executes it will trigger the auto-migration of fields to argocd-controller which is described in https://github.com/kubernetes/kubernetes/pull/112905

We need this in cases where a user created their resource with kubectl apply -f in the command line then later used argocd to manage it with SSA.

[codecov[bot]]

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.

Files with missing lines	Patch %	Lines
pkg/sync/sync_context.go	51.61%	30 Missing :warning:

Additional details and impacted files

@@            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     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[blakepettersson]

@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]

@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.

[blakepettersson]

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)

[pjiang-dev]

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.

[pjiang-dev]

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

[pjiang-dev]

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

[sonarqubecloud[bot]]

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