Support deployment probe overrides

[skonto]

Proposed Changes

• Customers are facing slow environments and need to adjust timeouts and other settings in probes.
• Some settings can be adjusted on the fly via changing the deployments eg. a deployment uses the probe defaults and given that the operator will not touch those (manifest uses apply) it does the trick. However this is a hack and we need a proper way to change probes and cover cases where reconciliation will touch the settings.

Release Note

Support is added for readiness, liveness probe overrides.

[codecov[bot]]

Codecov Report

Base: 79.40% // Head: 79.61% // Increases project coverage by +0.21% :tada:

Coverage data is based on head (cee945f) compared to base (59e506e). Patch coverage: 86.27% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1247      +/-   ##
==========================================
+ Coverage   79.40%   79.61%   +0.21%     
==========================================
  Files          35       36       +1     
  Lines        1602     1653      +51     
==========================================
+ Hits         1272     1316      +44     
- Misses        239      244       +5     
- Partials       91       93       +2     

Impacted Files	Coverage Δ
pkg/reconciler/common/probe_override.go	76.47% <76.47%> (ø)
pkg/reconciler/common/workload_override.go	85.82% <91.17%> (+1.95%)	:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[skonto]

gentle ping @houshengbo @nak3

[matzew]

Let's have a knative/docs issue as well, so we describe this valuable feature!

[matzew]

LGTM

[skonto]

I will create a doc PR for this too once it is approved. @houshengbo gentle ping.

[houshengbo]

Do we really need to all fields under livenessProbes??? If it is just a few fileds, like TimeoutSeconds, InitialDelaySeconds, etc, we do not need to add all the other fields. Just pick the ones related to the *** Seconds, that are necessary.

[skonto]

@houshengbo

If it is just a few fileds, like TimeoutSeconds, InitialDelaySeconds, etc, we do not need to add all the other fields. Just pick the ones related to the *** Seconds, that are necessary.

Anything that is timeout, threshold related are useful as a starting point in the field. I would just exclude ProbeHandler as @pierDipi mentioned above. Wdyth?

[houshengbo]

Just keep

InitialDelaySeconds int32 `json:"initialDelaySeconds,omitempty" protobuf:"varint,2,opt,name=initialDelaySeconds"`
	
	TimeoutSeconds int32 `json:"timeoutSeconds,omitempty" protobuf:"varint,3,opt,name=timeoutSeconds"`
	
	PeriodSeconds int32 `json:"periodSeconds,omitempty" protobuf:"varint,4,opt,name=periodSeconds"`
	
	SuccessThreshold int32 `json:"successThreshold,omitempty" protobuf:"varint,5,opt,name=successThreshold"`
	
	FailureThreshold int32 `json:"failureThreshold,omitempty" protobuf:"varint,6,opt,name=failureThreshold"`
	
	TerminationGracePeriodSeconds

in the CRDs. Remove the others. @skonto

[skonto]

Missed your comment I will add the rest, I used an even smaller subset.

[skonto]

@houshengbo kept those six fields. Adapted the PR.

[houshengbo]

@skonto Plz do another rebase. I will merge this pr.

[skonto]

@houshengbo sorry missed it I was off. Let's see if tests pass.

[skonto]

/hold let me check crds first

[skonto]

/unhold

[knative-prow[bot]]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: matzew, skonto

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~~ [matzew]

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

[skonto]

/unhold