Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support deployments/workloads probe overrides #1247

Merged
merged 5 commits into from
Oct 19, 2022

Conversation

skonto
Copy link
Contributor

@skonto skonto commented Oct 12, 2022

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.

@knative-prow knative-prow bot added the size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. label Oct 12, 2022
Copy link

@knative-prow knative-prow bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@skonto: 0 warnings.

In response to this:

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.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@codecov
Copy link

codecov bot commented Oct 12, 2022

Codecov Report

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

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%) ⬆️

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

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

@skonto skonto force-pushed the add_readiness_probe_configuration branch 2 times, most recently from a81bd84 to 23892c0 Compare October 13, 2022 10:09
@skonto
Copy link
Contributor Author

skonto commented Oct 13, 2022

gentle ping @houshengbo @nak3

Comment on lines +284 to +294
// +optional
ReadinessProbes []ProbesRequirementsOverride `json:"readinessProbes,omitempty"`

// LivenessProbes overrides liveness probes for the containers.
// +optional
LivenessProbes []ProbesRequirementsOverride `json:"livenessProbes,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

very valid to have these as overrides too! Good catch!

@matzew
Copy link
Member

matzew commented Oct 13, 2022

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

@matzew
Copy link
Member

matzew commented Oct 13, 2022

LGTM

@skonto
Copy link
Contributor Author

skonto commented Oct 14, 2022

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

Comment on lines 334 to 376
// ProbesRequirementsOverride enables the user to override any container's env vars.
type ProbesRequirementsOverride struct {
// The container name
Container string `json:"container"`
// The desired ProbeRequirements
Probe corev1.Probe `json:"probe,omitempty"`
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a thought unrelated to this particular change because it's affecting existing fields (env, etc).

I'm wondering if for v1 we should consider something simpler to work with:

Currently, overrides will endup being

deployments:
  resources:
  - container: webhook
    requests: # ...
  readinessProbes:
  - container: webhook
    probe: # ...

which seems repetitive and error prone.

For v1, a more podspec-like structure (with a subset of fields) would be easier to work with.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For v1, a more podspec-like structure (with a subset of fields) would be easier to work with.

yeah, currently is hard...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I would prefer a pod spec per workload to apply as an override.

// The container name
Container string `json:"container"`
// The desired ProbeRequirements
Probe corev1.Probe `json:"probe,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

@skonto skonto Oct 17, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didnt want to limit people on how they can use this (they could override the handler with their own custom thing) but we can keep it limited for now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not assume the options for users. If we plan to add some, what is the use case? Otherwise, limit to what is necessary. Drop ProbeHandler at least.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@houshengbo
Copy link
Contributor

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
Copy link
Contributor Author

skonto commented Oct 17, 2022

@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
Copy link
Contributor

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

@knative-prow knative-prow bot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Oct 18, 2022
@skonto
Copy link
Contributor Author

skonto commented Oct 18, 2022

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

@knative-prow knative-prow bot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Oct 18, 2022
@skonto
Copy link
Contributor Author

skonto commented Oct 18, 2022

@houshengbo kept those six fields. Adapted the PR.

@houshengbo
Copy link
Contributor

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

@knative-prow-robot knative-prow-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 18, 2022
@skonto skonto force-pushed the add_readiness_probe_configuration branch from df48d31 to f929955 Compare October 18, 2022 22:12
@knative-prow-robot knative-prow-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 18, 2022
@skonto
Copy link
Contributor Author

skonto commented Oct 18, 2022

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

@skonto
Copy link
Contributor Author

skonto commented Oct 18, 2022

/hold let me check crds first

@knative-prow knative-prow bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 18, 2022
@skonto
Copy link
Contributor Author

skonto commented Oct 18, 2022

/unhold

@knative-prow knative-prow bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 18, 2022
@skonto skonto changed the title Support deployment probe overrides Support deployment/workloads probe overrides Oct 18, 2022
@skonto skonto changed the title Support deployment/workloads probe overrides Support deployments/workloads probe overrides Oct 18, 2022
Copy link
Member

@matzew matzew left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

/hold
feel free to unhold

@knative-prow knative-prow bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 19, 2022
@knative-prow knative-prow bot added the lgtm Indicates that a PR is ready to be merged. label Oct 19, 2022
@knative-prow
Copy link

knative-prow bot commented Oct 19, 2022

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

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

@knative-prow knative-prow bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 19, 2022
@skonto
Copy link
Contributor Author

skonto commented Oct 19, 2022

/unhold

@knative-prow knative-prow bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 19, 2022
@knative-prow knative-prow bot merged commit 28c5b30 into knative:main Oct 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants