To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant.
- name: zrt
- description: zrt (HP Z Runtime) is a CLI tool that wraps the vLLM inference engine to provide a streamlined experience for serving large language models on Linux. It handles Python environment setup, model lifecycle management (pull, serve, stop), and exposes an OpenAI-compatible HTTP API - making it easy to deploy and observe LLM workloads on GPU-equipped systems.
- snapcraft: N/A (proprietary, repository not publicly available)
- upstream: PRIVATE
- upstream-relation: HP Inc. is both the publisher and the upstream developer of this software.
- supported-category: HPC or orchestration agents/software for running workloads on systems without traditional users where the systems are otherwise managed outside of the agent
- reasoning: zrt orchestrates GPU-accelerated LLM inference workloads using vLLM as its backend engine. Strict confinement is insufficient for the following technical reasons:
- CUDA and GPU runtime libraries on the host: vLLM requires deep access to NVIDIA CUDA runtime libraries for GPU-accelerated inference. The opengl interface covers basic CUDA compute access but is insufficient for the full set of libraries, device character files, and runtime paths that vLLM requires.
- Python environment management at arbitrary host paths: zrt manages Python virtual environments via uv at user-configurable locations on the host (defaulting to /opt/hp/zrt in system mode and ~/.local/share/zrt in user mode). These environments contain compiled C-extension modules that link against host libraries and must function correctly within the host’s dynamic linker namespace. Strict confinement’s mount namespace would break these host-linked extensions.
- Execution of dynamically-installed binaries at host paths: zrt manages and spawns vLLM as a child process. vLLM is installed by uv into a Python virtual environment at a user-configurable host path that is outside the snap. Under strict confinement we would need to bundle the entire vLLM stack (including all CUDA-linked native extensions) inside the snap which is not feasible given the size and host-driver dependencies involved.
- Large model file storage at user-defined paths: LLM models range from several gigabytes to hundreds of gigabytes. Users require the ability to store them on specific mount points (external drives, NFS shares, dedicated data partitions) at paths that cannot be anticipated in advance.
(check) I understand that strict confinement is generally preferred over classic.
(check) I’ve tried the existing interfaces to make the snap to work under strict confinement.
Note that snappy-debug can be used to identify possible required interfaces. See https://snapcraft.io/docs/debug-snaps for more information.