-
-
Notifications
You must be signed in to change notification settings - Fork 231
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
feat: add support for configurable probe handlers #934
feat: add support for configurable probe handlers #934
Conversation
02a84ba
to
63061fb
Compare
Signed-off-by: Jordan Rodgers <[email protected]>
63061fb
to
7e3ecde
Compare
3f970e9
to
23e23e6
Compare
23e23e6
to
7e3ecde
Compare
@drivebyer any chance I could get a review of this? 🙏 Thanks! 🎉 |
@com6056 |
They shouldn't be breaking, the probes had all of the same fields as the corev1.Probe struct, so it should be a no-op for anyone that doesn't actually set a probe handler It looks like this was also originally added in #178, but then for some reason removed in #302 |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #934 +/- ##
==========================================
+ Coverage 35.20% 39.12% +3.92%
==========================================
Files 19 20 +1
Lines 3213 2717 -496
==========================================
- Hits 1131 1063 -68
+ Misses 2015 1583 -432
- Partials 67 71 +4 ☔ View full report in Codecov by Sentry. |
Does Kubernetes validate probe fields if set |
It doesn't appear that it does in CRDs (I'm guessing the operator would just fail to create the StatefulSet), and kubebuilder unfortunately doesn't seem to have a way to add validation to nested fields for this 😞 |
If we want to keep the existing validation we can just add the |
agree. BTW, I test this yaml:
|
add support for configurable probe handlers Signed-off-by: Jordan Rodgers <[email protected]> Signed-off-by: Matt Robinson <[email protected]>
Description
Add the ability to specify your own
ProbeHandler
, which switches theProbe
type to the upstreamcorev1.Probe
.It looks like this was originally added in #178, but then for some reason removed in #302 🤔
@iamabhishek-dubey can you provide any context here? Is this change reasonable?
Type of change
Checklist
Additional Context
For context, we really need to check more of the cluster state before rolling pods, so we want to add our own probe (something like this, although haven't tested it yet):
It looks like this was asked for in #170 as well, and I wonder if we should just build this functionality into the operator itself rather than having everyone have to figure out their own method for ensuring the cluster rolls safely.