-
Notifications
You must be signed in to change notification settings - Fork 101
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
Support deployments/workloads probe overrides #1247
Conversation
There was a problem hiding this 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 ReportBase: 79.40% // Head: 79.61% // Increases project coverage by
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
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. |
a81bd84
to
23892c0
Compare
gentle ping @houshengbo @nak3 |
// +optional | ||
ReadinessProbes []ProbesRequirementsOverride `json:"readinessProbes,omitempty"` | ||
|
||
// LivenessProbes overrides liveness probes for the containers. | ||
// +optional | ||
LivenessProbes []ProbesRequirementsOverride `json:"livenessProbes,omitempty"` |
There was a problem hiding this comment.
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!
Let's have a knative/docs issue as well, so we describe this valuable feature! |
LGTM |
I will create a doc PR for this too once it is approved. @houshengbo gentle ping. |
pkg/apis/operator/base/common.go
Outdated
// 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"` | ||
} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
pkg/apis/operator/base/common.go
Outdated
// The container name | ||
Container string `json:"container"` | ||
// The desired ProbeRequirements | ||
Probe corev1.Probe `json:"probe,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we prevent setting the ProbeHandler
field and allow only these fields https://github.com/skonto/operator/blob/23892c03b5a5caeb2e41691a4bff41248903dd73/vendor/k8s.io/api/core/v1/types.go#L2194-L2226.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need to all fields under |
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? |
Just keep
in the CRDs. Remove the others. @skonto |
Missed your comment I will add the rest, I used an even smaller subset. |
@houshengbo kept those six fields. Adapted the PR. |
@skonto Plz do another rebase. I will merge this pr. |
df48d31
to
f929955
Compare
@houshengbo sorry missed it I was off. Let's see if tests pass. |
/hold let me check crds first |
/unhold |
There was a problem hiding this 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
[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 |
/unhold |
Proposed Changes
Release Note