fix: prune deployment revision annotation

[a7i]

What type of PR is this?

/kind bug

What this PR does / why we need it:

We noticed that karmada and member cluster controller-manager are fighting against each other where we get over 6k updates for a single deployment per hour.

the culprit seems to be the revision annotation.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

while generally the karmdaa setup doesn't run the Deployment controller on the karmada-apiserver, it does support promoting resources which can lead to having these annotations cause a diff with the member cluster(s).

Does this PR introduce a user-facing change?:

fix: prune deployment revision annotations

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 53.31%. Comparing base (3314771) to head (3dfa5b5).

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

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4946      +/-   ##
==========================================
- Coverage   53.32%   53.31%   -0.01%     
==========================================
  Files         252      252              
  Lines       20485    20489       +4     
==========================================
+ Hits        10923    10924       +1     
- Misses       8841     8844       +3     
  Partials      721      721              

Flag	Coverage Δ
unittests	53.31% <100.00%> (-0.01%)	⬇️

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.

[XiShanYongYe-Chang]

Hi @a7i I think that the requirement proposed by #4945 can solve the issue raised by the current PR.

[RainbowMango]

while generally the karmdaa setup doesn't run the Deployment controller on the karmada-apiserver, it does support promoting resources which can lead to having these annotations cause a diff with the member cluster(s).

Do you mean you promoted a Deployment resource from the member cluster, which has the annotation deployment.kubernetes.io/revision and deployment.kubernetes.io/revision-history, the conflict comes when Karmada tries to update them back?

[RainbowMango]

Hi @a7i I think that the requirement proposed by #4945 can solve the issue raised by the current PR.

Yes, but before that, what's your opinion on this PR?
It makes sense to me to remove those annotations from Deployment as it is the Kubernetes native resources.

[XiShanYongYe-Chang]

Previous view: Can we put the conflicts caused by controllers that are not enabled into the new hook point?

Previous view: It makes sense to me to remove those annotations from Deployment as it is the Kubernetes native resources.

Based on this, new view: For Kubernetes native resources, we can put it into the default behavior.

[a7i]

the conflict comes when Karmada tries to update them back?

That's correct!

I think that the requirement proposed by #4945 can solve the issue raised by the current PR.

Retain or Prune will work here. With Retain, we'll just get an extra Update after first creation but ignored after that.

Given it's kubernetes native annotation, I think it makes sense to make it a default behavior but will defer to you all.

[RainbowMango]

Given it's kubernetes native annotation, I think it makes sense to make it a default behavior but will defer to you all.

+1
LGTM
But seems you might need to rebase and resolve the conflicts.

[RainbowMango]

@a7i Can you help to rebase this PR and resolve the conflicts?

[RainbowMango]

/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/resourceinterpreter/OWNERS [RainbowMango]

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