[Feature]: Publish monailabel image and support MONAI Label in production compose - #949
Merged
atriaybagur merged 3 commits intoAug 12, 2026
Conversation
…mpose (#947) docker_build_monailabel.yml follows the orthanc pattern (direct push + workflow_dispatch + PR build, no test-workflow gate) with two additions: the job reclaims ~25GB of preinstalled runner toolchains before building — the image is ~10.4GB against ubuntu-latest's ~14GB free — and an import smoke (monailabel/torch/sam2/XNATDatastore + curl) runs between build and push, so a broken runtime stack never publishes. The Dockerfile's own build asserts already cover the unpatched-XNAT-auth and non-CUDA-12-torch states. compose_trust.production.monailabel.yml is image-only like the rest of the production compose; the Makefile's $(__DCKR_SUFFIX) machinery picks it up with no new wiring. The hard PROD refusal in require_monailabel_supported becomes an explicit warning: enabling MONAI Label re-introduces the OHIF viewer plugin the trust XNAT deliberately excludes (FLIP#662 bulk-import livelock), which is a per-trust judgement call, not a build limitation — intended for hybrid/on-prem annotation trusts. The GPU refusal stays hard: a GPU-less host cannot run it at all. Dev keeps building locally: pointing the dev overlay at ghcr :stag before a first publish exists would fail every `make up-trust` on pull. Signed-off-by: at24_bioeng625-pc <alexandre.triay_bagur@kcl.ac.uk>
github-actions
Bot
changed the title
|
✅ Acceptance criteria have been automatically imported from the linked issue(s) and added to the PR description. |
Mirrors the compose overlay: Deployment + Service + weights PVC, gated on monailabel.enabled (default false — the default render is proven unchanged, comment-only delta). The chart's XNAT already ships the ohif-viewer plugin in its roster, so unlike compose there is no plugin step and no FLIP#662 exclusion to weigh here. Chart-specific decisions: - The XNAT archive is read straight off xnat-web's data PVC (read-only `archive` subPath). That PVC is ReadWriteOnce by default, so the pod is pinned to xnat-web's node via required podAffinity (monailabel.coScheduleWithXnat, default true); RWX storage classes can disable it. - monailabel.publicUrl is `required` when enabled rather than defaulted: XNAT hands it to the OHIF viewer, which calls it from the clinician's browser — the chart cannot derive an outside-the-cluster URL, and a wrong default fails only at click time. The helm-template CI job asserts the guard fires. - Exposed as NodePort (default 30030) plus a scoped NetworkPolicy opening exactly that port on exactly this pod through the namespace's default-deny ingress (service.allowExternalIngress). - Startup probe allows 30 minutes: first start on a cold volume downloads pretrained weights including the ~900MB SAM checkpoint. - Render coverage lives in the helm-template job, NOT ci/test-values.yaml: the kind install deploys those values and waits for pod readiness, which a ~10.4GB GPU image can never satisfy there. Signed-off-by: at24_bioeng625-pc <alexandre.triay_bagur@kcl.ac.uk>
7 tasks
…ment [Feature]: MONAI Label deployment in the Kubernetes trust chart
atriaybagur
marked this pull request as ready for review
August 12, 2026 14:33
atriaybagur
merged commit Aug 12, 2026
9dc5948
into
55-feature-add-monailabel-to-ohif-viewer-plugin-xnat
12 tasks
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.
Description
Publishes the
monailabelimage to GHCR and lets the production trust compose run MONAI Label. Follow-up to #945 (stacked on its branch — do not merge before #945; GitHub will retarget this todevelopwhen it merges).docker_build_monailabel.yml— orthanc pattern (direct push +workflow_dispatch+ PR build; no test workflow to gate on). Two additions: reclaims ~25 GB of preinstalled runner toolchains before building (the image is ~10.4 GB vsubuntu-latest's ~14 GB free; plainrm, no third-party actions), and an import smoke (monailabel/torch/sam2/XNATDatastore+curl) between build and push so a broken runtime stack never publishes. Tags: immutablesha-<short7>+:stag(develop) /:prod(main), matching the fleet.compose_trust.production.monailabel.yml— image-only overlay; existing$(__DCKR_SUFFIX)machinery selects it, no new wiring.PRODguard: refusal → warning. The hard block existed because no image was published; that's now a per-trust judgement call instead — enabling MONAI Label re-introduces the OHIF viewer plugin trust XNAT deliberately excludes (trust XNAT: bulk image-pull wedges permanently — Reactor EventBus ring-buffer livelock (OHIF listener) + restart strands directArchive #662 bulk-import livelock). The warning says exactly that. The GPU refusal stays hard.:stagbefore a first publish exists would fail everymake up-truston pull. Flipping dev to pull-by-default can follow once the tag exists.Linked Issues
Fixes #947
Checklist
Type of Change
Testing
env:(same shape as orthanc's).docker compose config):monailabelpresent with the GHCR image, read-only archive mount, GPU reservation.make -n up-trust MONAI_LABEL=true PROD=stagshows the production overlay selected, the GPU guard intact, and the trust XNAT: bulk image-pull wedges permanently — Reactor EventBus ring-buffer livelock (OHIF listener) + restart strands directArchive #662 warning firing without exiting.workflow_dispatchon this branch, or let the develop merge publish:stag.Additional Notes
First real exercise of the disk-reclaim step happens on the first workflow run; if
ubuntu-latest's preinstalled set has shifted and space still runs out, the fallback is themaximize-build-spaceaction.Acceptance Criteria
Imported from issue #947
trust/monailabel/**to develop publishesghcr.io/londonaicentre/monailabel:stag(+ immutablesha-<short7>); main publishes:prod.make up-trust KIT=<CODE> MONAI_LABEL=true PROD=stagstarts the server from the published image on a GPU host, with a visible trust XNAT: bulk image-pull wedges permanently — Reactor EventBus ring-buffer livelock (OHIF listener) + restart strands directArchive #662 warning.MONAI_LABELunset, dev and prod stacks are unchanged.Follow-up to #55 / PR #945.