[bug] Not possible to configure httpGet under health probes. #694

New Issue

2024-07-29T19:11:00Z

CompPhy commented

2024-07-29 19:11:00 +00:00

(Migrated from gitea.com)

We wanted to configure the /api/healthz URL under our liveness probes, as defined here: https://docs.gitea.com/installation/install-on-kubernetes#health-check-endpoint. However, something about in helm chart isn't allowing this. We even tried overwriting the tcpSocket block with an empty dictionary and this didn't help either.

I'm not even sure what's up here. The templates/gitea/deployment.yaml file looks like it should just overwrite the entire probe section, but that does not appear to be what's happening here. We even tried removing the helm deployment entirely and reinstalling fresh.

Error:

Error: INSTALLATION FAILED: failed to create resource: Deployment.apps "gitea" is invalid: spec.template.spec.containers[0].livenessProbe.tcpSocket: Forbidden: may not specify more than 1 handler type

Example values:

gitea:
  livenessProbe:
    enabled: true
    httpGet:
      path: /api/healthz
      port: http
    initialDelaySeconds: 200
    timeoutSeconds: 1
    periodSeconds: 10
    successThreshold: 1
    failureThreshold: 10
  readinessProbe:
    enabled: true
    httpGet:
      path: /api/healthz
      port: http
    initialDelaySeconds: 5
    timeoutSeconds: 1
    periodSeconds: 10
    successThreshold: 1
    failureThreshold: 3

We wanted to configure the `/api/healthz` URL under our liveness probes, as defined here: https://docs.gitea.com/installation/install-on-kubernetes#health-check-endpoint. However, something about in helm chart isn't allowing this. We even tried overwriting the tcpSocket block with an empty dictionary and this didn't help either. I'm not even sure what's up here. The `templates/gitea/deployment.yaml` file looks like it should just overwrite the entire probe section, but that does not appear to be what's happening here. We even tried removing the helm deployment entirely and reinstalling fresh. Error: ``` Error: INSTALLATION FAILED: failed to create resource: Deployment.apps "gitea" is invalid: spec.template.spec.containers[0].livenessProbe.tcpSocket: Forbidden: may not specify more than 1 handler type ``` Example values: ```yaml gitea: livenessProbe: enabled: true httpGet: path: /api/healthz port: http initialDelaySeconds: 200 timeoutSeconds: 1 periodSeconds: 10 successThreshold: 1 failureThreshold: 10 readinessProbe: enabled: true httpGet: path: /api/healthz port: http initialDelaySeconds: 5 timeoutSeconds: 1 periodSeconds: 10 successThreshold: 1 failureThreshold: 3 ```

👍 1 👀 1

mlhynfield commented

2024-09-12 14:11:53 +00:00

(Migrated from gitea.com)

I can reproduce this issue in my environment; I'm unable to install the gitea chart with httpGet or exec liveness or readiness probes. It seems this is because tcpSocket is specified in the defaults as a populated dict, and the deployment.yaml template takes whatever is under gitea.livenessProbe or gitea.readinessProbe with the toYaml function. The only way I could think of to get around this while using the official chart is to set tcpSocket explicitly to null, but whether this is intended or not it seems Helm doesn't remove the entry from values but still uses the default. If that is a bug, I believe it should be brought to the Helm project as an issue, but in the meantime there may be a way to work around this with a helper function so that tcpSocket can be easily removed as needed while remaining the default.

I will also say personally I think it makes more sense to have the httpGet probe to /api/healthz as the default, but regardless I think it should be configurable.

I can reproduce this issue in my environment; I'm unable to install the gitea chart with httpGet or exec liveness or readiness probes. It seems this is because tcpSocket is specified in the defaults as a populated dict, and the deployment.yaml template takes whatever is under gitea.livenessProbe or gitea.readinessProbe with the toYaml function. The only way I could think of to get around this while using the official chart is to set tcpSocket explicitly to null, but whether this is intended or not it seems Helm doesn't remove the entry from values but still uses the default. If that is a bug, I believe it should be brought to the Helm project as an issue, but in the meantime there may be a way to work around this with a helper function so that tcpSocket can be easily removed as needed while remaining the default. I will also say personally I think it makes more sense to have the httpGet probe to /api/healthz as the default, but regardless I think it should be configurable.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lunny/helm-chart#694