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
What happened:
Liveness / readiness probes are failing when a different health path is configured.
What you expected to happen:
Be able to configure the liveness and readiness probe paths or if the value for health_handler_prefix is not empty, use that value for probes path, too.
How to reproduce it (as minimally and precisely as possible):
vmcqgo
changed the title
[bug] issue title
[bug] Hard-coded health path for readiness / liveness probes, yet ability to configure where it is exposed by Centrifugo
Aug 10, 2023
I think it's better to not use .Values.config.health_handler_prefix, but have a separate explicit option inside .Values.internalService
Sth like .Values.internalService.healthHttpEndpoint and use {{ .Values.internalService.healthHttpEndpoint | default "/health" }} for setting paths.
It's more configuration - two places instead of one, but feels more correct to me. Because Centrifugo's health_handler_prefix may be actually set over environment and using .Values.config.health_handler_prefix does not seem right from that perspective.
Describe the bug
While you can configure the health handler path for Centrifugo through the config key
health_handler_prefix
, the liveness and readiness probes' paths are hard-coded as/health
in the deployment template:https://github.com/centrifugal/helm-charts/blob/master/charts/centrifugo/templates/deployment.yaml#L154-L165
Version of Helm and Kubernetes:
Helm Version:
Kubernetes Version:
Which version of the chart:
10.0.3
What happened:
Liveness / readiness probes are failing when a different health path is configured.
What you expected to happen:
Be able to configure the liveness and readiness probe paths or if the value for
health_handler_prefix
is not empty, use that value for probes path, too.How to reproduce it (as minimally and precisely as possible):
values.yaml
The text was updated successfully, but these errors were encountered: