guarantee the promotion can be rolled back safely

[wulemao]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Let karmadactl promote command leverage migration rollback feature to guarantee the promotion can be rolled back safely.

To address the issue #3004 sent by @chaunceyjiang .

Which issue(s) this PR fixes:

Fixes part of #5577
Fixes #3004

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

karmadactl: set `PreserveResourcesOnDeletion` by default in auto-created propagation policy during promotion process 

[wulemao]

the result is like this:

$ karmadactl --karmada-context karmada-apiserver promote deployment nginx3 -C member2
ResourceTemplate (default/nginx3) is created successfully
PropagationPolicy (default/nginx3-6d7f8d5f5b) is created successfully
Resource "apps/v1, Resource=deployments"(default/nginx3) is promoted successfully

$ kubectl get pp nginx3-6d7f8d5f5b -o jsonpath='{.spec.preserveResourcesOnDeletion}'      
true#   

$ karmadactl --karmada-context karmada-apiserver promote clusterrole pod-reader -C member2
ResourceTemplate (default/pod-reader) is created successfully
ClusterPropagationPolicy pod-reader-54499c54c is created successfully
Resource "rbac.authorization.k8s.io/v1, Resource=clusterroles"(pod-reader) is promoted successfully

$ kubectl get cpp pod-reader-54499c54c -o jsonpath='{.spec.preserveResourcesOnDeletion}'
true# 

[RainbowMango]

/assign @chaosi-zju

[chaosi-zju]

generally looks good, thanks

Although it doesn't affect the functionality, I think we should proactively set conflictResolution to overwrite for the automatically created policy.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 0% with 18 lines in your changes missing coverage. Please review.

Project coverage is 35.05%. Comparing base (5f7fc4f) to head (7f082af).
Report is 14 commits behind head on master.

Files with missing lines	Patch %	Lines
pkg/karmadactl/promote/promote.go	0.00%	18 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5601      +/-   ##
==========================================
+ Coverage   34.84%   35.05%   +0.20%     
==========================================
  Files         645      645              
  Lines       44861    44869       +8     
==========================================
+ Hits        15633    15727      +94     
+ Misses      28021    27927      -94     
- Partials     1207     1215       +8     

Flag	Coverage Δ
unittests	35.05% <0.00%> (+0.20%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[wulemao]

generally looks good, thanks

Although it doesn't affect the functionality, I think we should proactively set conflictResolution to overwrite for the automatically created policy.

done

[chaosi-zju]

/lgtm

cc @RainbowMango

[RainbowMango]

cc @chaunceyjiang Would you like to take a look? This is the issue you care about. :)

[RainbowMango]

generally looks good, thanks

Although it doesn't affect the functionality, I think we should proactively set conflictResolution to overwrite for the automatically created policy.

Why do you think that? On the contrary, I think Overwrite is not the expected behavior in a promotion scenario. During the promotion process, we should try our best to ensure that the existing workload won't be changed.

That is, we can leave conflictResolution unset(it will take the default Abort), or set it with Abort explicitly.

[chaosi-zju]

generally looks good, thanks
Although it doesn't affect the functionality, I think we should proactively set conflictResolution to overwrite for the automatically created policy.

Why do you think that? On the contrary, I think Overwrite is not the expected behavior in a promotion scenario. During the promotion process, we should try our best to ensure that the existing workload won't be changed.

That is, we can leave conflictResolution unset(it will take the default Abort), or set it with Abort explicitly.

What you said makes certain sense, but there are two problematic points:

• The resource template is generated by us according to member cluster's resource, why there is a change?
• Actually, we already set conflictResolution=Overwrite through the annotation of resource template, otherwise execute_controller can't promote it

[RainbowMango]

Yeah, thanks for the reminder. Yes, we need overwrite to take over resources from member clusters.

The "Overwrite" might be useful when migrating legacy cluster resources to Karmada, in which case conflict is predictable and can be instructed to Karmada take over the resource by overwriting.

/lgtm
/approve

[karmada-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: RainbowMango

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/karmadactl/OWNERS [RainbowMango]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment