[WIP] Example: Moonray renderer Container example with OpenJD WRAP_ACTIONS job template and enviornment - #272
Draft
leongdl wants to merge 6 commits into
Draft
[WIP] Example: Moonray renderer Container example with OpenJD WRAP_ACTIONS job template and enviornment#272leongdl wants to merge 6 commits into
leongdl wants to merge 6 commits into
Conversation
Signed-off-by: David Leong <116610336+leongdl@users.noreply.github.com>
The MoonRay build step configured cmake by hand and never pointed at the
dependencies built by the previous step, so the build failed after about
50 minutes with:
CMake Error ... Could NOT find JsonCpp (missing: JsonCpp_LIBRARIES)
building/Rocky9/CMakeLists.txt installs the dependency stack to
/opt/MoonRay/installs (its InstallRoot default), not to /installs. The
official docs configure MoonRay through the rocky9-release preset in
CMakeLinuxPresets.json, which supplies CMAKE_PREFIX_PATH and the
per-dependency *_ROOT variables pointing there, along with the /build
binary dir, the /installs/openmoonray install prefix, and
PYTHON_EXECUTABLE / BOOST_PYTHON_COMPONENT_NAME / ABI_VERSION. Use the
preset. Its build preset runs the install target, so the separate
cmake --install is gone.
The image then built but could not render: moonray defaults to
-auto_affinity on, which calls mbind(2), and Docker's default seccomp
profile only permits that syscall with CAP_SYS_NICE, so a plain
docker run aborted at render startup with
numaNodeMBInd() sysCallMBind() failed. numaNodeId:0 size:33554432
The upstream docs pass --security-opt seccomp=unconfined. The README now
documents two narrower options and uses --cap-add SYS_NICE in the
docker run examples; -auto_affinity off also works with no capability
change. hd_render needs neither.
Also pin OPENMOONRAY_REF to the released tag v2026.29.1 instead of main
so a rebuild reproduces the same MoonRay, and record the requested ref
and resolved commit in the image at /openmoonray-ref.txt.
Verified on x86_64: image builds (7.43 GB, v2026.29.1 d96c6e30),
moonray renders testdata/rectangle.rdla in 3.9s and hd_render renders
testdata/sphere.usd, both to valid EXRs.
The mbind section sat directly after the Build section, which read as a build requirement. It is not: docker build needs no added capability or seccomp change. Move the section down next to the render commands, retitle it, and say so outright.
The containers/ sample index still listed only AL2023 and Blender, and described itself as covering "both" samples, so the moonray sample added on this branch was unreachable from it.
Adds containers/moonray/templates/, an Open Job Description job that renders a MoonRay example scene inside the rocky9-cpu image using the WRAP_ACTIONS and EXPR extensions. The container concern is kept out of the job template. moonray-render-job.yaml declares only EXPR and describes the render as a plain `moonray -in ... -out ...` invocation, so it also runs unchanged on a host with moonray on PATH. local-docker-wrap-env.yaml supplies the three WRAP_ACTIONS hooks that re-run each action via `docker run`, forwarding the wrapped command with repr_sh() as the single argument the image's `bash -lc` ENTRYPOINT expects. On a farm the same hooks would arrive as a queue environment instead. run-render.sh downloads the official example scenes, points TMPDIR at ./sessions so session working directories land beside the templates rather than in /tmp, bind mounts that directory into the container, and runs the job with the Python CLI, the Rust CLI, or both, verifying the .exr artifact rather than trusting the exit code. The hooks pass --cap-add SYS_NICE: MoonRay binds NUMA memory with mbind(2), which docker's default seccomp profile blocks, and without the capability every render aborts in initTLS. Verified with the Rust openjd CLI on a 16-core x86_64 host: veach-mis renders in 149s to a valid 1280x720 RGBA OpenEXR, within 0.5% of the reference scene.exr shipped with the scene. Both templates pass `openjd check` on the Python and Rust implementations.
github-actions
Bot
added
the
waiting-on-maintainers
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| render_with() { | ||
| local impl="$1" bindir="$2" | ||
| local log="$LOG_DIR/render-$impl.log" | ||
| local expected="$OUTPUT_DIR/$impl-$SCENE.exr" |
There was a problem hiding this comment.
The SCENE env override is only half wired up. Here the artifact path and the fetch/verify checks (lines 81, 98, 107) all use $SCENE, but render_with never forwards it as an OpenJD parameter — and the job template's Scene task parameter is a hardcoded range: [veach-mis] (moonray-render-job.yaml:70-73), with the in-container output path built from Task.Param.Scene (out_exr, line 80).
So SCENE=<anything-but-veach-mis> ./run-render.sh will fetch/verify that scene, but the render still produces veach-mis.exr inside the container while the host checks for $impl-$SCENE.exr — the file never appears and the run is reported as FAILED even though MoonRay succeeded. Either drop the SCENE override from the documented interface, or pass it through (e.g. -p Scene=$SCENE plus widening the task range) so the two sides agree.
The script already ran either CLI, but nothing recorded which one, so a log or an .exr could only be traced back to an implementation by recognising the log format. Each run now resolves its openjd up front and writes the resolved path and version into the top of its log, and echoes both while running. Adds a third choice, `path`, for a normally installed CLI rather than the two source-checkout locations that `python` and `rust` assume, and validates the selection before starting: a missing or mislocated binary now fails immediately naming the variable to set, instead of surfacing as `openjd: command not found` from inside a session. openjd-cli implements --version; the Rust CLI does not, so the version line says so rather than reporting nothing. Records both implementations in the README's verified run. python and rust render veach-mis to outputs that differ by exactly 3 bytes, all inside the EXR capDate header attribute - the capture timestamp. Every pixel is identical, so the wrap environment behaves the same under both.
| ;; | ||
| python|rust|path|both) ;; | ||
| -h|--help) | ||
| sed -n '2,36p' "${BASH_SOURCE[0]}" | sed 's/^# \{0,1\}//' |
There was a problem hiding this comment.
The --help handler prints past the header comment block. The comment block ends at line 29 (# VENV=... RUST_BIN=...); line 30 is blank and lines 31-36 are code (set -u -o pipefail, TEMPLATE_DIR=..., JOB_TEMPLATE=..., WRAP_ENV=...). Because sed -n 2,36p includes those non-comment lines and the trailing sed only strips a leading hash-space prefix (leaving code lines untouched), ./run-render.sh --help prints raw script lines after the usage text -- e.g. set -u -o pipefail and the TEMPLATE_DIR=... / JOB_TEMPLATE=... assignments.
Change the range to 2,29p (or anchor it to the end of the comment block) so only the intended header is shown.
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
1 participant
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.
Fixes:
What was the problem/requirement? (What/Why)
What was the solution? (How)
What is the impact of this change?
How was this change tested?
Was this change documented?
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.