feat(helm/raySpec): allow customizing the Ray head node readiness probe (#742)

[Anai-Guo]

Summary

Fixes #742.

The multi-node Ray head pod hard-codes its readiness probe in helm/templates/ray-cluster.yaml:

readinessProbe:
  httpGet:
    path: /health
    port: {{ include "chart.container-port" . }}
  failureThreshold: 1
  periodSeconds: 10

With failureThreshold: 1 and periodSeconds: 10, a single failed probe marks the head pod unready. On large multi-node deployments the head serving process can take longer than one 10s period to begin answering /health, so the pod flips to unready and never receives traffic (Readiness probe failed: ... connect: connection refused). As reported in #742, there was no way to relax it — setting readinessProbe under servingEngineSpec, modelSpec, or raySpec.headNode had no effect on the head node.

Change

Honor raySpec.headNode.readinessProbe when set, rendered verbatim via toYaml, and fall back to the existing default otherwise:

readinessProbe:
  {{- if $modelSpec.raySpec.headNode.readinessProbe }}
  {{- toYaml $modelSpec.raySpec.headNode.readinessProbe | nindent 14 }}
  {{- else }}
  httpGet:
    path: /health
    port: {{ include "chart.container-port" . }}
  failureThreshold: 1
  periodSeconds: 10
  {{- end }}

• Backward compatible: with the field unset the rendered output is byte-identical to before.
• Documents the field with an example in values.yaml.
• No values.schema.json change: raySpec.headNode is an open object in the schema (no additionalProperties: false), and the schema is generated from values.yaml in CI, so hand-editing it would just be reverted by the generator.

Example

raySpec:
  headNode:
    requestCPU: 16
    requestMemory: "32Gi"
    requestGPU: 2
    readinessProbe:
      httpGet:
        path: /health
        port: 8000
      failureThreshold: 10
      periodSeconds: 30

Notes

I don't have a multi-node GPU cluster to reproduce end-to-end, so I verified the template logic and the values change by inspection. helm template with the field set renders the overriding probe; with it unset it renders the original default unchanged.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces the ability to configure a custom readiness probe for the Ray head node in the Helm chart, updating the template, schema, and values files. The review feedback suggests guarding the nested field access in the Helm template with an 'and' condition to prevent potential nil pointer evaluation errors if 'headNode' is undefined.

[gemini-code-assist]

To prevent potential template rendering errors (such as nil pointer evaluating interface{}), it is safer to guard the nested field access by checking if headNode is defined before accessing readinessProbe.

              {{- if and $modelSpec.raySpec.headNode $modelSpec.raySpec.headNode.readinessProbe }}