2 Commits

Include renames

Author	SHA1	Message	Date
jakman85andClaude Opus 5	78bf68493d	feat(gpu): satisfy hardware.gpu: intel-quicksync with gpu.intel.com/i915, not a /dev/dri hostPath ... The hostPath mechanism was MEASURED NOT TO WORK. In the live Plex pod on k3s-prod-2, 2026-10-01: the device node was VISIBLE in the container (`crw-rw---- root video2 226,128 renderD128`) and could not be opened -- `uid 0 O_RDWR -> EPERM` and `uid 1000 O_RDWR -> EPERM`. EPERM from the DEVICE CGROUP, not EACCES from file permissions, proven three ways: root on the HOST opens the same device rc=0; the node is unified cgroup2fs; and the container's runc config.json read `linux.resources.devices: [{allow: False, access: 'rwm'}]` with `linux.devices: None` -- one deny-all rule, no allow entry for major 226. A hostPath is a filesystem operation: it binds the device node in but adds no cgroup allow rule, because Kubernetes cannot infer one from a volume. The Intel GPU device plugin produces that allow rule (`createDeviceSpecsFromDrmFiles` emits `DeviceSpec{..., Permissions: "rw"}`). It shipped as #36 and is live: all three prod nodes advertise `gpu.intel.com/i915: 1`, DaemonSet 3/3/3 (measured 2026-10-01). ZERO ServiceDefinition field changes, which was the entire point of making the field an enum of capability classes rather than a device path. `catalog/plex.yaml`'s `hardware:` block comes through byte-identical; only its comment changes, because it restated the old mechanism. Contract invariant 8 holds, now demonstrated rather than claimed. - catalog/render.py: `DRI_VOLUME_NAME`/`DRI_DEVICE_DIR` retired for `QUICKSYNC_RESOURCE`; the hardware branch now sets `resources.limits["gpu.intel.com/i915"] = 1` on the APP container only (never a sidecar) and emits no volume, no mount, no securityContext, no nodeSelector. `limits` not `requests` is mandatory: Kubernetes mirrors requests from limits, and a requests-only extended resource is invalid. This is the only app-container `resources` render path and is deliberately narrow -- no general CPU/memory feature was invented. - selftests: resources dict asserted EXACTLY; hostPath/mount asserted ABSENT; the no-`hardware` negative extended to `resources`; the podSecurityContext pass-through and the no-synthesised-securityContext assertions kept; one new assertion that the limit never reaches the oauth2-proxy sidecar. Mutation-tested: 8/8 mutants caught (requests-instead-of-limits, emission dropped, hostPath re-added, emitted unconditionally, supplementalGroups synthesised, wrong resource name, quantity as a string, limit leaked onto the sidecar). - apps/wave-0/plex.yaml: six hostPath lines removed, a three-line resources block added. Only golden touched; keycloak/vm-demo unchanged. THE REGRESSION, STATED RATHER THAN SOLD. Before: device missing -> `DirectoryOrCreate` mounted an empty dir -> Plex ran and SILENTLY software-transcoded (invisible, harmless to everything else). After: resource unavailable (plugin broken, removed, or not yet reconciled) -> Plex is UNSCHEDULABLE, and `apps-wave-0` is `wait: true` with `apps-wave-1` dependsOn it, so that STALLS THE APP TIER. Unavoidable: an extended resource is a hard scheduling constraint, and it is also the only thing that produces the cgroup allow rule. There is no graceful-degradation variant. Plex's schedulability is now coupled to the intel-gpu-plugin DaemonSet. Escape hatch, one field and no code change: delete the `hardware:` block from catalog/plex.yaml and re-render. Documented in the contract, the runbook (its own top-of-page section and a "Plex will not schedule" procedure) and the handoff. HARDWARE TRANSCODING IS STILL NOT OBSERVED WORKING. The decisive open() test cannot be re-run until this merges and Flux reconciles, and the Plex-side `HardwareAcceleratedCodecs` toggle is still unset. A green gate proves the manifest renders. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-10-01 23:21:28 -05:00
jakman85andClaude Opus 5	0fee584e3a	feat(plex): opt into hardware.gpu: intel-quicksync, and write the runbook for the step GitOps cannot reach ... Plex has been transcoding in software on hardware that can do it in the iGPU. This opts its ServiceDefinition into the `hardware` capability from #27 and re-renders. catalog/plex.yaml gains four lines of YAML and the comment that explains them: hardware: gpu: intel-quicksync which renders exactly two things into apps/wave-0/plex.yaml and nothing else — a `dri` hostPath volume (/dev/dri, type: DirectoryOrCreate) and a read-write /dev/dri volumeMount on the app container. Whole-tree render diff: 6 added lines, one file. The comment records what is not obvious from the four lines: the device exists on ALL THREE prod nodes with i915 bound (so no nodeSelector is rendered and none is wanted); why `supplementalGroups` would be INERT rather than a hardening (the image's cont-init hook adds the plex user to the device's group inside the container, and s6-setuidgid then REPLACES the process group list from /etc/group, discarding anything Kubernetes supplied); and why `DirectoryOrCreate` is load-bearing (apps-wave-0 is wait:true with apps-wave-1 depending on it, so a failed mount would stall the whole app tier for a feature that is not). THE FEATURE IS INERT UNTIL A HUMAN CLICKS A BOX, and that is the part this commit is really about. Mounting the device does not enable hardware transcoding; Plex's `HardwareAcceleratedCodecs` preference does, and it is ABSENT from Preferences.xml — the toggle has never been on. It cannot be automated: a bounded grep across the running image's entire init surface (/etc/cont-init.d, /etc/services.d, /etc/fix-attrs.d, /plex-common.sh, /usr/local/bin) found ZERO PLEX_PREFERENCE* support, and the six setPref keys the image does write are all unrelated. So runbooks/plex-quicksync.md is the procedure, registered in the configMapGenerator (a runbook in git with no generator entry is reviewed, merged, and still a 404) and indexed in runbooks/README.md. It covers the GitOps/manual boundary, the toggle and the real preference keys (including the widely-cited one that does not exist and the upstream misspelling nobody should "fix"), verification via `Transcode (hw)` on the Plex dashboard — stated plainly as the ONLY proof, because Plex renders no ServiceMonitor and an alert could never fire — the device-cgroup failure to expect first with its Intel-device-plugin fallback, and the floating-`:latest` caveat. Stacked on #27 (feat/sd-hardware-capability), which is open and unmerged; that branch's commit is in this range by design and this must merge after it. NOT VERIFIED, and the handoff says so at length: hardware transcoding has not been observed working. Whether containerd's device cgroup lets a non-privileged pod open() a bind-mounted char device is an open question that only deploying settles, and the Plex-side toggle was still unset at the time of writing. A green gate proves the manifest renders; it proves nothing about transcoding. Gate (pinned toolbox, worktree): rc 3 — UNDETERMINED, not green. Passed: decisions-log, lint, l0, render-golden, l1, approval-policy. Skipped (the known local ceiling): spec-immutability (no sibling spec repo), gitea-settings (no SETTINGS_API_TOKEN), conformance (CLUSTER_AVAILABLE unset, so L2/L3 did not run). No fourth skip, nothing failed. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-10-01 21:05:17 -05:00