fix bug: avoid updating directly cached resource template

[whitewindmills]

What type of PR is this?
/kind bug

What this PR does / why we need it:
avoid updating directly cached resource template.

Which issue(s) this PR fixes:
Fixes #3878

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

`karmada-controller-manager`: Avoid updating directly cached resource templates.

[codecov-commenter]

Codecov Report

Merging #3879 (931f1e4) into master (d916d87) will decrease coverage by 0.02%.
Report is 2 commits behind head on master.
The diff coverage is 0.00%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@            Coverage Diff             @@
##           master    #3879      +/-   ##
==========================================
- Coverage   54.98%   54.97%   -0.02%     
==========================================
  Files         228      228              
  Lines       21786    21791       +5     
==========================================
  Hits        11980    11980              
- Misses       9167     9172       +5     
  Partials      639      639              

Flag	Coverage Δ
unittests	54.97% <0.00%> (-0.02%)	⬇️

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

Files Changed	Coverage Δ
pkg/detector/detector.go	0.00% <0.00%> (ø)
pkg/detector/policy.go	0.00% <0.00%> (ø)

[XiShanYongYe-Chang]

Thanks a lot.

In order to prevent other places where the utility methods are called from modifying the objects in the cache, I think it would be better to directly make modifications within the utility methods.

Furthermore, this issue indicates that we do not have an end-to-end (E2E) coverage for this scenario. If possible, could you please provide an additional E2E use case or create an issue to track this task?

[whitewindmills]

I think it would be better to directly make modifications within the utility methods.

The number of resources may be huge, and the calling frequency of this utility function is very high. It is obviously not necessary to perform a deep copy every time we read a resource through this utility function. We only make a deep copy in a few places that need to be modified.

Furthermore, this issue indicates that we do not have an end-to-end (E2E) coverage for this scenario. If possible, could you please provide an additional E2E use case or create an issue to track this task?

good suggestion.
tracked issue: #3884

[XiShanYongYe-Chang]

The number of resources may be huge, and the calling frequency of this utility function is very high. It is obviously not necessary to perform a deep copy every time we read a resource through this utility function. We only make a deep copy in a few places that need to be modified.

In this case, should we consider adding some comments in the utility func to indicate the need for attention when modifying cache issues, so as to prevent overlooking this factor when using it in new places?

[whitewindmills]

In this case, should we consider adding some comments in the utility func to indicate the need for attention when modifying cache issues, so as to prevent overlooking this factor when using it in new places?

👍

[whitewindmills]

ptal @XiShanYongYe-Chang @RainbowMango @chaunceyjiang

[XiShanYongYe-Chang]

Thanks
/lgtm

[chaunceyjiang]

/lgtm

[RainbowMango]

/assign

[XiShanYongYe-Chang]

@whitewindmills can you help update the release note? Maybe we need to cherry-pick it to the previous branch.

[whitewindmills]

done

[RainbowMango]

/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:

• OWNERS [RainbowMango]

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

[whitewindmills]

@XiShanYongYe-Chang @RainbowMango should we cherry-pick it to the previous branch?

[XiShanYongYe-Chang]

@XiShanYongYe-Chang @RainbowMango should we cherry-pick it to the previous branch?

I think it is necessary.

[RainbowMango]

+1