v0.3.1

v0.3.1

Opt-in organization CA bundle injection and automatic GPU scheduling tolerations. Both are no-ops for existing deployments — upgrading from v0.3.0 requires no changes to your values.

Highlights

🔐 Organization CA bundle injection (#16)

For clusters behind a TLS-inspecting proxy (Netskope, Zscaler, BlueCoat, internal corporate CAs), the chart can now inject an organization CA into the Ray head and worker pods so outbound HTTPS succeeds. Opt in by pointing orgCABundle.configMapName at a ConfigMap containing your root CA:

orgCABundle:
  configMapName: org-ca-bundle

When enabled, an initContainer builds a combined bundle (system trust + org CA) and the pods get SSL_CERT_FILE, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, and GIT_SSL_CAINFO pointed at it — covering requests, urllib3, curl, pip, torch.hub, and git (incl. pip install git+https://…). When unset (the default), zero CA-related output is rendered — byte-identical to v0.3.0.

• ⚠️ ArgoCD users: the README's example sync policy ignores /spec/rayClusterConfig, which silently drops the CA injection under server-side apply. See the "ArgoCD footgun" note in the README before enabling orgCABundle.
• httpx caveat: httpx's default verify=True ignores SSL_CERT_FILE; app code must use verify=ssl.create_default_context(). Documented in the README.

🎮 Automatic GPU tolerations (#18)

GPU workloads (pods requesting nvidia.com/gpu) now get an nvidia.com/gpu toleration injected automatically, so they schedule onto tainted GPU nodes (e.g. NIC's auto-tainted AWS GPU node groups) without manual configuration. A user-supplied toleration for the same key is respected as an intentional override and not duplicated. Non-GPU pods are unaffected.

📚 Documentation site (#12)

Added a Docusaurus-based landing page / docs site for the pack, published to GitHub Pages.

Upgrade notes

No action required. All changes are opt-in or fire only for GPU workloads; existing values produce the same Ray deployment as v0.3.0.

Versioning

This is the first release under EffVer (effort-based versioning). Per EffVer's pre-1.0 guidance (0.MACRO.MICRO), a release that's a no-op for existing users is a micro bump → 0.3.0 → 0.3.1. The chart appVersion stays 2.43.0 (tracks Ray, not the pack).

What's changed

• Inject org CA into Ray head + worker pods via ConfigMap by @oren-openteams in #16
• Add nvidia.com/gpu toleration to Ray Serve GPU workloads by @tylerpotts in #18
• Add placeholder landing page / docs site by @killua156 in #12

Full changelog: v0.3.0...v0.3.1

v0.3.0

Conformant EffVer re-tag of nebari-rayserve-pack-0.3.0 at the same commit (5456c40). The original tag and release remain valid; this standardizes on the vMAJOR.MINOR.MICRO convention. No code change.

nebari-rayserve-pack-0.3.0

What's new

Worker pods now reach Ready on a fresh install

Previously, KubeRay's default worker readiness/liveness probe chained raylet healthz with wget http://localhost:8000/-/healthz | grep success. The Serve check requires both a deployed Serve application and a local Serve HTTP proxy — neither of which holds on a fresh chart install. Worker pods would stay 0/1 Ready indefinitely with the confusing message Readiness probe failed: success.

This release overrides KubeRay's default worker probes with raylet-only checks. Kubernetes pod readiness now reflects whether the Ray node itself is healthy; Serve application health is tracked separately by the Serve controller and no longer gates K8s readiness.

New configurable values

• serve.proxyLocation (default EveryNode) — controls where Ray Serve runs HTTP proxies. EveryNode places a proxy on every Ray pod, which matches typical KubeRay usage.
• worker.readinessProbe, worker.livenessProbe — exposed for tuning. Defaults to a raylet-only check; set to ~ (null) to fall back to KubeRay defaults.
• head.readinessProbe, head.livenessProbe — exposed for symmetry. Defaults to {} so KubeRay defaults apply unchanged.

Test coverage

The standalone integration test now installs with worker.replicas=1 and waits for the worker pod to reach Ready. Previously the test ran with replicas=0, which couldn't catch worker-side regressions.

References

• Issue: #7 — full diagnosis of the readiness-probe failure
• PR: #8 — implementation

Upgrade notes

For consumers pinning to a specific tag (e.g., ArgoCD targetRevision), update from nebari-rayserve-pack-0.1.0-alpha.1 to nebari-rayserve-pack-0.3.0.

If you were using the manual workaround of running serve.shutdown(); serve.start(proxy_location='EveryNode'); serve.run(...) to make workers Ready, that's no longer required — a fresh deploy of this chart will produce a healthy cluster without any Serve apps deployed.

v0.0.1-alpha

Initial release

What's Changed

• feat: add landingPage support to dashboard NebariApp by @oren-openteams in #3
• Add runtimeClassName support for GPU workloads by @oren-openteams in #5

New Contributors

• @oren-openteams made their first contribution in #3

Full Changelog: https://github.com/nebari-dev/nebari-rayserve-pack/commits/v0.0.1-alpha

nebari-rayserve-pack-0.1.0-alpha.1

What's Changed

• feat: add landingPage support to dashboard NebariApp by @oren-openteams in #3
• Add runtimeClassName support for GPU workloads by @oren-openteams in #5

New Contributors

• @oren-openteams made their first contribution in #3

Full Changelog: https://github.com/nebari-dev/nebari-rayserve-pack/commits/nebari-rayserve-pack-v0.1.0-alpha.1