[WIP] Example: Moonray renderer Container example with OpenJD WRAP_ACTIONS job template and enviornment

containers/README.md

@@ -4,11 +4,12 @@ These samples provide Dockerfiles and related resources for building container i
 
 ## Sample index
 
-This table covers both user-selectable container samples below `containers/`. Supporting scripts and image assets remain with their sample.
+This table covers the user-selectable container samples below `containers/`. Supporting scripts and image assets remain with their sample.
 
 | Sample | What it demonstrates | Start here when |
 |---|---|---|
 | [AL2023 worker-equivalent image](al2023-deadline/) | Reproducing a point-in-time service-managed fleet package set on Amazon Linux 2023 | You need to test packages or software against worker-compatible system libraries |
 | [Blender application container](blender/blender-aswf-ci-base/) | Packaging Blender, the Deadline Cloud adaptor, and GPU support in an application image | You want to render Blender workloads from a purpose-built container |
+| [MoonRay application container](moonray/) | Compiling MoonRay from source for CPU rendering on Rocky Linux 9 | You want to render with MoonRay, or need a specific MoonRay revision |
 
-The worker-equivalent image is useful for local compatibility work and package builds. The Blender image is an application-container example and includes its own deployment resources and instructions.
+The worker-equivalent image is useful for local compatibility work and package builds. The Blender and MoonRay images are application-container examples; Blender includes its own deployment resources and instructions, and MoonRay builds the renderer from source.

containers/moonray/.gitignore

@@ -0,0 +1,4 @@
+# Downloaded example scenes (~700 MB) and render output stay local.
+scenes/
+output/
+example_scenes.zip

containers/moonray/README.md

@@ -0,0 +1,26 @@
+# MoonRay containers
+
+Container samples for running [MoonRay](https://openmoonray.org/), DreamWorks' open-source
+production path tracer, on the CPU.
+
+| Sample | What it demonstrates | Start here when |
+|---|---|---|
+| [Rocky Linux 9 CPU image](rocky9-cpu/) | Compiling MoonRay from source per the [official container build docs](https://docs.openmoonray.org/getting-started/installation/building-moonray/rocky9_container_build/) | You want an unprivileged CPU image, or need to build a specific MoonRay revision |
+
+The source build takes hours to compile but produces a self-contained image that runs as a normal
+unprivileged container, with no systemd, or `--privileged` requirement.
+
+## Where to get the sample scenes
+
+No scene files ship with this sample. MoonRay publishes the example scenes itself, and the sample's
+`.gitignore` keeps any local copy out of git — the archive unpacks to roughly 700 MB.
+
+* **Bundled test scenes** — small `.rdla` and `.usd` files already inside the image at
+  `/source/testdata`, from the [MoonRay source tree](https://github.com/dreamworksanimation/openmoonray).
+  Use these to confirm the build works.
+* **Official example scenes** — download
+  [example_scenes.zip](https://docs.openmoonray.org/assets/test-scenes/example_scenes.zip) from the
+  [MoonRay test scenes page](https://docs.openmoonray.org/getting-started/test-scenes/), then mount
+  the unpacked directory into the container.
+
+See [rocky9-cpu/README.md](rocky9-cpu/README.md) for the exact download and render commands.

containers/moonray/rocky9-cpu/Dockerfile

@@ -0,0 +1,90 @@
+# Builds MoonRay from source on Rocky Linux 9, following the official
+# container build procedure:
+# https://docs.openmoonray.org/getting-started/installation/building-moonray/rocky9_container_build/
+#
+# The docs run these steps interactively in a rockylinux:9 container and
+# `docker commit` the result; this Dockerfile encodes the same steps so the
+# image is reproducible with a single command:
+#
+#   docker build --platform linux/amd64 -t openmoonray-rocky9 .
+#
+# The build compiles MoonRay's third-party dependencies (OpenEXR, USD, ...)
+# and then MoonRay itself — expect it to take on the order of hours and to
+# need 8+ GB of RAM available to the Docker VM.
+#
+# CUDA/GPU (XPU) support is omitted (--nocuda / MOONRAY_USE_OPTIX=NO), per
+# the same docs, since GPUs are typically not available in containers.
+
+FROM rockylinux:9
+
+SHELL ["/bin/bash", "-c"]
+
+# The openmoonray repository uses submodules and Git LFS for test data.
+RUN dnf install -y git git-lfs \
+    && git lfs install
+
+ARG OPENMOONRAY_REPO=https://github.com/dreamworksanimation/openmoonray.git
+
+# Which MoonRay version to build. Defaults to a released tag rather than a
+# branch so that rebuilding this Dockerfile later produces the same MoonRay.
+# Pick another version from the tag list:
+#   https://github.com/dreamworksanimation/openmoonray/tags
+# Upstream publishes two tag series: the older openmoonray-<major>.<minor>.0.0
+# scheme (up to openmoonray-3.6.0.1) and the current date-based v<year>.<week>.<n>
+# scheme. Override with, for example:
+#   docker build --platform linux/amd64 \
+#       --build-arg OPENMOONRAY_REF=openmoonray-3.6.0.1 \
+#       -t openmoonray-rocky9 .
+# This is passed to `git clone --branch`, so it accepts a tag or a branch name
+# ("main" for the tip of development) but not a bare commit sha.
+ARG OPENMOONRAY_REF=v2026.29.1
+
+# The moonray/materialx_shaders submodule points at a repository that is not
+# public (404), so deactivate it and fetch the rest of the submodules.
+RUN git clone --branch "${OPENMOONRAY_REF}" "${OPENMOONRAY_REPO}" /source \
+    && cd /source \
+    && git config submodule."moonray/materialx_shaders".update none \
+    && git submodule update --init --recursive \
+    && echo "${OPENMOONRAY_REF} $(git rev-parse HEAD)" > /openmoonray-ref.txt
+
+# Step 1: install the system packages MoonRay's build needs.
+RUN source /source/building/Rocky9/install_packages.sh --nocuda \
+    && dnf clean all
+
+# The EPEL cmake links the system libuv and crashes in its SIGCHLD handler
+# when the image is built under x86_64 emulation (e.g. on Apple Silicon).
+# The pip wheel is the same cmake 3.x with a bundled libuv and works
+# everywhere; it installs to /usr/local/bin, which shadows /usr/bin.
+RUN pip3 install "cmake<4"
+
+# Step 2: build the remaining dependencies from source (installs under /installs).
+RUN mkdir /build \
+    && cd /build \
+    && cmake /source/building/Rocky9 \
+    && cmake --build . -- -j "$(nproc)"
+
+# Step 3: build and install MoonRay itself.
+#
+# This goes through the rocky9-release CMake preset (CMakeLinuxPresets.json),
+# as the official docs do, rather than a hand-written cmake invocation. The
+# preset is what connects this step to step 2: the dependencies install to
+# /opt/MoonRay/installs (the InstallRoot default in
+# building/Rocky9/CMakeLists.txt), and the preset sets CMAKE_PREFIX_PATH and
+# the per-dependency *_ROOT variables that point there. Configuring without
+# it fails immediately at the first dependency lookup:
+#   CMake Error ... Could NOT find JsonCpp (missing: JsonCpp_LIBRARIES)
+# The preset also sets the build directory to /build, the install prefix to
+# /installs/openmoonray, and PYTHON_EXECUTABLE / BOOST_PYTHON_COMPONENT_NAME /
+# ABI_VERSION; its build preset runs the `install` target, so there is no
+# separate `cmake --install`.
+RUN rm -rf /build/* \
+    && cd /source \
+    && cmake --preset rocky9-release -DMOONRAY_USE_OPTIX=NO \
+    && cmake --build --preset rocky9-release -- -j "$(nproc)" \
+    && rm -rf /build
+
+# setup.sh puts moonray, moonray_gui, and hd_render on PATH.
+RUN echo 'source /installs/openmoonray/scripts/setup.sh' > /etc/profile.d/openmoonray.sh
+
+ENTRYPOINT ["/bin/bash", "-lc"]
+CMD ["moonray"]

containers/moonray/rocky9-cpu/README.md

@@ -0,0 +1,138 @@
+# MoonRay on Rocky Linux 9 (CPU, source build)
+
+This sample builds [MoonRay](https://openmoonray.org/) from source in a
+[Rocky Linux 9](https://hub.docker.com/_/rockylinux) container, following the official
+[Rocky 9 container build procedure](https://docs.openmoonray.org/getting-started/installation/building-moonray/rocky9_container_build/).
+Where the official docs run the steps interactively and `docker commit` the result, this
+`Dockerfile` encodes the same steps so the image is reproducible with one command.
+
+The resulting image needs no snapd, no systemd, and no `--privileged` — MoonRay is compiled into
+`/installs/openmoonray` and runs in a plain unprivileged container.
+
+## Prerequisites
+
+* Docker (or a compatible CLI such as `finch`; substitute `finch` for `docker` below)
+* Time and resources: the build compiles MoonRay's dependency stack (OpenEXR, OpenVDB, USD, ...)
+  and then MoonRay itself. On a native x86_64 machine expect roughly 1–2 hours and 8+ GB of RAM;
+  under emulation on Apple Silicon it can take many hours.
+* ~20 GB of free disk for intermediate layers
+
+## Build
+
+```console
+docker build --platform linux/amd64 -t openmoonray-rocky9 .
+```
+
+### Choosing a MoonRay version
+
+`OPENMOONRAY_REF` selects which MoonRay to build. It defaults to the released tag
+`v2026.29.1` rather than a branch, so rebuilding this `Dockerfile` months from now produces the
+same MoonRay instead of whatever `main` happens to be that day.
+
+Available versions are listed on the
+[openmoonray tags page](https://github.com/dreamworksanimation/openmoonray/tags) (also on the
+[releases page](https://github.com/dreamworksanimation/openmoonray/releases)). Upstream has used
+two tag series: the older `openmoonray-<major>.<minor>.0.0` scheme, which ends at
+`openmoonray-3.6.0.1`, and the current date-based `v<year>.<week>.<n>` scheme.
+
+```console
+docker build --platform linux/amd64 \
+    --build-arg OPENMOONRAY_REF=openmoonray-3.6.0.1 \
+    -t openmoonray-rocky9:3.6.0.1 .
+```
+
+The value goes to `git clone --branch`, so a tag or a branch name works — pass `main` to build the
+tip of development — but a bare commit sha does not. Older tags are not tested by this sample and
+may need different system packages than `building/Rocky9/install_packages.sh` installs at the
+pinned version.
+
+The version that was actually built is recorded in the image at `/openmoonray-ref.txt`, as the
+requested ref plus the commit it resolved to:
+
+```console
+docker run --rm openmoonray-rocky9 'cat /openmoonray-ref.txt'
+```
+
+Two deviations from the official docs, both encoded in the `Dockerfile` with comments:
+
+* The `moonray/materialx_shaders` submodule points at a repository that is not public, so it is
+  deactivated before `git submodule update`.
+* cmake is installed from pip (`pip3 install "cmake<4"`): the EPEL cmake crashes in libuv's
+  signal handling when the build runs under x86_64 emulation on an arm64 host.
+
+MoonRay itself is configured through upstream's `rocky9-release` CMake preset, as the official
+docs do. The preset is what links step 3 to step 2: the dependencies install to
+`/opt/MoonRay/installs`, and the preset supplies the `CMAKE_PREFIX_PATH` and per-dependency
+`*_ROOT` variables that point there. Configuring by hand without it stops at
+`Could NOT find JsonCpp`.
+
+## Where to get the scenes
+
+No scene files ship with this sample. There are two sources:
+
+* **Bundled test scenes** — small `.rdla` and `.usd` files already present in the image at
+  `/source/testdata`, carried in from the
+  [MoonRay source tree](https://github.com/dreamworksanimation/openmoonray). Nothing to download.
+* **Official example scenes** — the larger `pbrt_scenes` set, published by MoonRay as
+  [example_scenes.zip](https://docs.openmoonray.org/assets/test-scenes/example_scenes.zip) on the
+  [test scenes page](https://docs.openmoonray.org/getting-started/test-scenes/). Download it
+  yourself; it unpacks to roughly 700 MB, and the sample's `.gitignore` keeps `scenes/`,
+  `output/`, and the zip out of git.
+
+## Running moonray needs `CAP_SYS_NICE`
+
+This is a run-time requirement only. `docker build` needs nothing beyond the flags shown above.
+
+`moonray` sets memory affinity by default (`-auto_affinity on`), which calls `mbind(2)` to bind
+memory to a NUMA node. Docker's default seccomp profile permits that syscall only when the
+container has `CAP_SYS_NICE`, so under a plain `docker run` the container starts and the scene
+loads, then the render thread aborts as it initializes:
+
+```
+what():  numaNodeMBInd() sysCallMBind() failed. numaNodeId:0 size:33554432
+```
+
+The official docs work around this with `--security-opt seccomp=unconfined`. Two narrower options
+work as well, and the `docker run` commands below use the first:
+
+* `--cap-add SYS_NICE` — keeps the default seccomp profile and leaves affinity control enabled.
+* `-auto_affinity off` on the `moonray` command line — no added capability or relaxed sandbox, at
+  the cost of NUMA-aware allocation. Sensible on a single-socket machine.
+
+`hd_render` is unaffected and needs neither.
+
+## Render the bundled test scene
+
+The source tree (kept at `/source` in the image) includes small test scenes:
+
+```console
+mkdir -p output
+docker run --rm --cap-add SYS_NICE -v "$(pwd)/output:/output" openmoonray-rocky9 \
+    'moonray -in /source/testdata/rectangle.rdla -out /output/rectangle.exr'
+```
+
+## Render the example scenes
+
+Download and unpack the example scenes, then mount them into the container:
+
+```console
+curl -LO https://docs.openmoonray.org/assets/test-scenes/example_scenes.zip
+mkdir -p scenes output
+unzip example_scenes.zip -d scenes/
+docker run --rm --cap-add SYS_NICE -v "$(pwd)/scenes:/scenes" -v "$(pwd)/output:/output" \
+    -w /scenes/example_scenes/pbrt_scenes/veach-mis openmoonray-rocky9 \
+    'moonray -in scene.rdla -in scene.rdlb -exec_mode scalar -out /output/veach-mis.exr'
+```
+
+`hd_render` (the USD Hydra delegate CLI) is also on `PATH`:
+
+```console
+docker run --rm -v "$(pwd)/output:/output" openmoonray-rocky9 \
+    'hd_render -in /source/testdata/sphere.usd -out /output/sphere.exr'
+```
+
+## Links
+
+* [Official Rocky 9 container build docs](https://docs.openmoonray.org/getting-started/installation/building-moonray/rocky9_container_build/)
+* [MoonRay test scenes (example_scenes.zip)](https://docs.openmoonray.org/getting-started/test-scenes/)
+* [OpenMoonRay source](https://github.com/dreamworksanimation/openmoonray)

containers/moonray/templates/.gitignore

@@ -0,0 +1,7 @@
+# The session root: session working directories, unpacked scenes, rendered
+# output and run logs. All generated, none of it belongs in git.
+sessions/
+
+# The example scenes archive (~700 MB) is downloaded on demand by run-render.sh.
+example_scenes.zip
+example_scenes.zip.part