You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.
Is your feature request related to a problem? Please describe.
We have an open ticket with HashiSupport on why the consul-dataplane container does not fully load in some cases but that problem revealed another shortcoming of the consul-dataplane container: It does not have any readinessProbe (or livenessProbe for that matter). What this means in reality is that if the consul-dataplane container does not start correctly (something in the initialization process gets wedged), we end up with a Pod that is never going to recover.
Feature Description
I proper for consul-k8s to set a startupProbe like this:
What will need to be configurable is mostly the total time to wait for the container to start listening on its application port. In our case it can take sometimes close to a minute so some annotation on the Pod for some combination of FailureThreshold and PeriodSeconds will be required.
Use Case(s)
Described already
Contributions
Yes, if you think you will accept such a feature
The text was updated successfully, but these errors were encountered:
Community Note
Is your feature request related to a problem? Please describe.
We have an open ticket with HashiSupport on why the consul-dataplane container does not fully load in some cases but that problem revealed another shortcoming of the consul-dataplane container: It does not have any readinessProbe (or livenessProbe for that matter). What this means in reality is that if the consul-dataplane container does not start correctly (something in the initialization process gets wedged), we end up with a Pod that is never going to recover.
Feature Description
I proper for consul-k8s to set a startupProbe like this:
What will need to be configurable is mostly the total time to wait for the container to start listening on its application port. In our case it can take sometimes close to a minute so some annotation on the Pod for some combination of
FailureThreshold
andPeriodSeconds
will be required.Use Case(s)
Described already
Contributions
Yes, if you think you will accept such a feature
The text was updated successfully, but these errors were encountered: