[serve] Resolve bundled ray-haproxy binary before RAY_SERVE_HAPROXY_BINARY_PATH#63829
Merged
eicherseiji merged 2 commits intoJun 4, 2026
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request updates the HAProxy binary resolution logic in Ray Serve. When the RAY_SERVE_EXPERIMENTAL_PIP_HAPROXY flag is enabled, the system now unconditionally uses the bundled ray-haproxy package binary, ignoring RAY_SERVE_HAPROXY_BINARY_PATH and raising a FileNotFoundError if loading fails, rather than falling back to other binaries. Unit tests have been updated to align with this new behavior. There are no review comments, so I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
eicherseiji
force-pushed
the
seiji/haproxy-experimental-flag-forces-bundled
branch
from
5958a8c to
7cdc6f7
Compare
eicherseiji
changed the title
…INARY_PATH RAY_SERVE_EXPERIMENTAL_PIP_HAPROXY was a no-op whenever the runtime image sets RAY_SERVE_HAPROXY_BINARY_PATH (the Ray images set it to /usr/local/bin/haproxy): _resolve_haproxy_binary() honored that explicit path before ever trying the bundled ray-haproxy wheel, so the *.aws.pip_haproxy release variants silently ran the image's system build instead of the pip binary they meant to test. Try the bundled ray-haproxy binary first so the flag takes precedence over an image-baked RAY_SERVE_HAPROXY_BINARY_PATH. The explicit-path and system-PATH fallbacks are unchanged for when the package is unavailable. Signed-off-by: Seiji Eicher <seiji@anyscale.com>
eicherseiji
force-pushed
the
seiji/haproxy-experimental-flag-forces-bundled
branch
from
7cdc6f7 to
2f4d555
Compare
eicherseiji
added
go
akyang-anyscale
approved these changes
Jun 3, 2026
…rder With the bundled ray-haproxy binary now resolved before the explicit RAY_SERVE_HAPROXY_BINARY_PATH override, the explicit-path branch is only reached when the package is unavailable. The CI/servebuild image has ray-haproxy installed, so patch ray_haproxy absent in this test to exercise the override branch. Signed-off-by: Seiji Eicher <seiji@anyscale.com>
rueian
pushed a commit
to rueian/ray
that referenced
this pull request
Jun 4, 2026
…INARY_PATH (ray-project#63829) ## Why `RAY_SERVE_EXPERIMENTAL_PIP_HAPROXY=1` is supposed to make Ray Serve use the HAProxy binary bundled in the `ray-haproxy` PyPI package. In practice it was a **no-op** whenever the runtime image sets `RAY_SERVE_HAPROXY_BINARY_PATH` — which the Ray images do (`docker/base-deps/Dockerfile` sets `RAY_SERVE_HAPROXY_BINARY_PATH=/usr/local/bin/haproxy`). `_resolve_haproxy_binary()` honored the explicit-path override *before* trying the bundled wheel, so with the flag on it returned `/usr/local/bin/haproxy` and never reached the `ray_haproxy` package. As a result the `*.aws.pip_haproxy` nightly release variants (`serve_controller_benchmark_haproxy`, `pytest_serve_autoscaling_load_test`) silently benchmarked the image's system build, not the pip binary they were meant to validate. Confirmed from a `pip_haproxy` release run's proxy logs: every proxy logged `Using HAProxy binary: /usr/local/bin/haproxy`; the wheel path never appeared. ## What - Resolve the bundled `ray-haproxy` binary **first**, so the flag takes precedence over an image-baked `RAY_SERVE_HAPROXY_BINARY_PATH`. - The explicit-path override and system-PATH fallback are unchanged, and still apply when the `ray-haproxy` package is unavailable. - Flag-off (default) behavior is unchanged: return `RAY_SERVE_HAPROXY_BINARY_PATH` verbatim. No change needed in `release_tests.yaml`: the existing `pip_haproxy` variants now actually exercise the pip binary. ## Testing Existing `python/ray/serve/tests/unit/test_haproxy_binary.py` suite passes against the new ordering (4 tests). Docstring updated to reflect the resolution order. --------- Signed-off-by: Seiji Eicher <seiji@anyscale.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
RAY_SERVE_EXPERIMENTAL_PIP_HAPROXY=1is supposed to make Ray Serve use the HAProxy binary bundled in theray-haproxyPyPI package. In practice it was a no-op whenever the runtime image setsRAY_SERVE_HAPROXY_BINARY_PATH— which the Ray images do (docker/base-deps/DockerfilesetsRAY_SERVE_HAPROXY_BINARY_PATH=/usr/local/bin/haproxy)._resolve_haproxy_binary()honored the explicit-path override before trying the bundled wheel, so with the flag on it returned/usr/local/bin/haproxyand never reached theray_haproxypackage. As a result the*.aws.pip_haproxynightly release variants (serve_controller_benchmark_haproxy,pytest_serve_autoscaling_load_test) silently benchmarked the image's system build, not the pip binary they were meant to validate.Confirmed from a
pip_haproxyrelease run's proxy logs: every proxy loggedUsing HAProxy binary: /usr/local/bin/haproxy; the wheel path never appeared.What
ray-haproxybinary first, so the flag takes precedence over an image-bakedRAY_SERVE_HAPROXY_BINARY_PATH.ray-haproxypackage is unavailable.RAY_SERVE_HAPROXY_BINARY_PATHverbatim.No change needed in
release_tests.yaml: the existingpip_haproxyvariants now actually exercise the pip binary.Testing
Existing
python/ray/serve/tests/unit/test_haproxy_binary.pysuite passes against the new ordering (4 tests). Docstring updated to reflect the resolution order.