Reduce deployment updates

[norman465]

Proposed Changes

• eliminate redundant deployment updates
• if anything modifies the deployment spec of a knative managed deployment the current logic will do a redundant deployment update every reconile. This is i.e. visible when running with net-istio, which adds

        service.istio.io/canonical-name:
        service.istio.io/canonical-revision:

to spec.template.metadata.labels causing the semantic equality check to fail every reconile.

Release Note

NONE

[knative-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: norman465
Once this PR has been reviewed and has the lgtm label, please assign gauron99 for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.19%. Comparing base (4004491) to head (a573615).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #16361      +/-   ##
==========================================
+ Coverage   80.17%   80.19%   +0.02%     
==========================================
  Files         216      216              
  Lines       13440    13440              
==========================================
+ Hits        10775    10778       +3     
  Misses       2300     2300              
+ Partials      365      362       -3     

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

🚀 New features to boost your workflow:

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

[dprotaso]

Hey have you seen @SaschaSchwarze0 old PR - #13552 I'm curious if you saw that change but decided your implementation is preferred.

I originally put a hold on that PR while I explored server side apply - but unfortunately as I dug more into server side apply I realized it had a lot of limitations at the time.

I honestly thing doing the hash of the spec is really the simplest way. It will even handle defaulting that occurs on the PodSpec.

[dprotaso]

/hold

[norman465]

Hey have you seen @SaschaSchwarze0 old PR - #13552 I'm curious if you saw that change but decided your implementation is preferred.

I originally put a hold on that PR while I explored server side apply - but unfortunately as I dug more into server side apply I realized it had a lot of limitations at the time.

I honestly thing doing the hash of the spec is really the simplest way. It will even handle defaulting that occurs on the PodSpec.

Yes, I know of that. When looking at the 1.20 changes for propagated labels and annotations I just noticed that this very small change would achieve the same and so I just opened this PR to quickly address it.