modelgrid.com/inferencemanager
3
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 3 Wiki Activity

3 Releases 6 Tags

RSS Feed
  • v2.0.3 396ccad7f6
    Compare

    ModelGrid v2.0.3
    CI / Build & Test (push) Successful in 1m32s
    Details
    Release / build-and-release (push) Successful in 6m46s
    Details
    Stable

    jkunz released this 2026-10-16 17:52:54 +00:00 | 0 commits to main since this release

    Fixes

    • a stopped installer script (the Docker convenience script at its time limit or output limit, or on Ctrl+C, SIGTERM or SIGHUP) counts as ended once none of its processes is running; processes that ended but were never reaped (zombies) no longer count. In a container without an init process nothing reaps the ended commands the script started, so the stop used to wait out the SIGTERM and SIGKILL grace periods and then fail with Process group <id> is still running after SIGKILL although every process had ended. On Linux the state is read from /proc.

    Maintenance

    • pnpm 12.11.2 (tooling)
    Downloads
  • v2.0.2 2626db3e11
    Compare

    ModelGrid v2.0.2
    CI / Build & Test (push) Failing after 1m57s
    Details
    Release / build-and-release (push) Successful in 9m50s
    Details
    Stable

    jkunz released this 2026-10-16 17:03:16 +00:00 | 3 commits to main since this release

    Fixes

    • modelgrid update reads the newest release through curl -fsSL without a shell and stops with a clear error when the releases API answers with an HTTP error or anything other than release JSON with a tag_name; it used to parse an error page as the release and fail with a JSON syntax error. The releases API request and the installer download each end after 30 s with an error that names the time limit; before, a stalled connection hung the update.
    • the NVIDIA Container Toolkit setup downloads its signing key, apt source list and yum repository file with curl -fsSL without a shell and checks them before writing: a failed download or gpg --dearmor, an empty file or an error page stops the setup with a clear error, and the keyring and source files are written whole (0644) or not at all. It used to pipe curl through gpg, sed and tee without failing on a download error, so an error page or an empty keyring could land in /etc/apt/sources.list.d, /etc/yum.repos.d or /usr/share/keyrings.
    • Docker installation adds Docker's apt key and source list the same way (key checked by gpg --dearmor, the source entry refused when the codename or the dpkg architecture is empty or not a plain name, files written whole or not at all) instead of curl … | gpg --dearmor and echo … > through the shell, and the convenience-script fallback downloads https://get.docker.com first, refuses an empty or failed download and runs it with sh from a private temporary file that is removed afterwards, instead of curl https://get.docker.com | sh, which ran whatever arrived. The script runs in its own process group, so its 10-minute time limit also ends the apt-get, dpkg and curl it started instead of leaving them running, and Ctrl+C, SIGTERM or SIGHUP to ModelGrid stops that group before ModelGrid ends.
    • Docker's apt repository uses the release codename from /etc/os-release (UBUNTU_CODENAME, else VERSION_CODENAME, as Docker documents) and stops with a clear error when it names none; it used lsb_release -cs, which minimal Debian installations lack and which gives an Ubuntu derivative's own codename, unknown to Docker's repository. The codename is read before anything changes, and the source is written only after Docker's Release file for that codename has been read and checked, before old Docker packages are removed; a release Docker does not publish stops with an error naming the repository and codename instead of writing a docker.list that breaks every later apt-get update.
    • the Intel graphics and oneAPI repositories and the AMD ROCm and AMDGPU repositories are added the same way: keys downloaded and checked by gpg --dearmor into /usr/share/keyrings, source entries bound to them with signed-by= and checked before anything is written, list and yum repository files written whole or not at all. They used to pipe wget into gpg --dearmor, tee or the deprecated apt-key add and write the sources with echo … > and cat <<EOF > through the shell, so a failed download could leave an empty keyring or no trusted key behind a written source list.
    • the Intel graphics repository is added for Ubuntu 22.04 (jammy) only, the one release whose suite Intel's graphics repository publishes; other releases stop with an error that names jammy and points to Intel's intel-graphics PPA guide for Ubuntu 24.04 and 26.04. It used to map every release other than 24.04 to jammy, and 24.04 to a noble suite the repository does not serve, which broke apt-get update.
    • the ROCm and AMDGPU repositories use the Ubuntu release codename from /etc/os-release as their suite, as AMD's install documentation does, and are added only after the repository's Release file for that release has been read and checked; an unpublished release stops with an error naming the repository and release. The ROCm source used the suite ubuntu, which serves focal packages on every release, and the AMDGPU source mapped every release other than 22.04 to focal. A requested ROCm version must be a version such as 6.0 or 6.1.3 and is checked before anything changes; any other value, which used to go into the repository URLs unchecked, is refused.
    • the NVIDIA driver on Ubuntu installs the server driver Ubuntu's NVIDIA driver guide describes for servers and compute instead of nvidia-driver-535 from the graphics-drivers PPA, which is no longer added: the -server series that ubuntu-drivers list --gpgpu --recommended names for the GPU, from Ubuntu's archive with Ubuntu's pre-built, signed kernel modules (linux-modules-nvidia-<series>-server-<kernel flavour> and the modules of the running kernel, installed before the driver metapackage), so Secure Boot works. A requested driver version (the driverVersion install option, such as 580 or 580-server-open) selects that series' -server packages. The installation stops before the driver is installed when ubuntu-drivers recommends no server driver, prints anything else, or apt has no candidate for one of the packages; it never runs ubuntu-drivers install, which exits 0 when apt fails. curl and gnupg are installed before the CUDA and container toolkit downloads.
    • the NVIDIA driver on Debian installs Debian's packages as its NVIDIA driver guide describes: the release's packaged series (Debian 12: 535, Debian 13: 550) as nvidia-kernel-dkms and nvidia-driver, with the header metapackage of the running kernel's flavour (such as linux-headers-amd64 or linux-headers-cloud-amd64) so DKMS builds for later kernels too. It checks first that apt offers nvidia-driver from Debian's series and stops with an error that names the contrib, non-free and non-free-firmware components when it does not. A requested driver version Debian does not package, another Debian release, a backports kernel or an unknown kernel is refused with a named error before anything is changed. It used to request Ubuntu's nvidia-driver-535, which Debian does not have. Ubuntu driver versions are checked to be a version (such as 550 or 550-server) before they reach apt.
    • the Intel driver on Fedora enables the intel/oneapi Copr repository with dnf copr enable without a shell and reports its failure: xpu-smi is optional, so a failed Copr or xpu-smi step is a warning that names the failure. It used to run dnf copr enable -y intel/oneapi || true and ignore a failed Copr step.
    • a driver installation with container support (NVIDIA, AMD, Intel) reports the installation as failed when the container support step fails; it used to ignore that step's result and report the installation as completed.
    • the NVIDIA Container Toolkit apt source is NVIDIA's stable deb list from its current install guide, for every Debian and Ubuntu release; it used the per-release libnvidia-container/<id><version>/ lists, which do not exist for Debian 12 (404).
    • the CUDA repository keyring is chosen for the running release and architecture (Ubuntu 20.04, 22.04, 24.04, 26.04 and Debian 11, 12, 13; x86_64, and sbsa for arm64 except Debian 11) and an unsupported release stops with an error naming the supported ones before the driver or anything else is installed; it used to install the Ubuntu 22.04 x86_64 repository on every Debian and Ubuntu system. A requested CUDA toolkit version must be <major> or <major>.<minor> (such as 12.4, installed as cuda-toolkit-12-4) and is checked at the same point; any other value, which used to reach apt-get through the shell, is refused.
    • the CUDA repository keyring package is downloaded with curl -fsSL, refused unless it is a Debian package, and installed with dpkg -i without a shell from a private temporary directory that is removed afterwards; it used wget … -O /tmp/cuda-keyring.deb && dpkg -i /tmp/cuda-keyring.deb, a fixed path in /tmp that root installed from.
    • the documented one-liner, the installer's --help examples and the release notes use curl -fsSL, so an HTTP error makes curl fail instead of piping the error page into bash; install.sh and .gitea/workflows/release.yml are regenerated with @git.zone/cli 9.2.2, which also pins the release workflow's actions by commit and checks out without persisted credentials.
    • the NVIDIA driver on Debian refuses a backports kernel before anything changes, as Debian's NVIDIA driver guide requires the driver from backports with it: backports kernels carry the release's +deb<N> in their name (trixie-backports, bookworm-backports 6.12), so they are now recognised by the Debian package version the kernel reports (~bpo). It used to treat them as release kernels and install the release's driver with the release's header package, which does not build the module for the running kernel. A kernel that names no Debian package version is refused as not a Debian kernel.
    • the NVIDIA driver on RHEL, Rocky Linux, AlmaLinux (8, 9, 10) and Fedora 44 installs as NVIDIA's driver installation guide describes for each: EPEL and its prerequisite repositories (RHEL: AppStream, BaseOS and CodeReady Builder with subscription-manager, then epel-release-latest-<major>; Rocky Linux and AlmaLinux: CRB, or PowerTools on 8, then epel-release), the running kernel's development packages, NVIDIA's CUDA repository of the release and architecture (x86_64, and sbsa for aarch64), the nvidia-driver:open-dkms module stream on 8 and 9, and nvidia-open; the CUDA toolkit is cuda-toolkit (or the requested cuda-toolkit-<version>). Every step runs without a shell and stops the installation with an error naming it. The release and architecture are checked and the repository file downloaded and checked before anything changes, and the file is written whole to /etc/yum.repos.d. It used to add the x86_64 rhel<major> repository on every system, Fedora included, unchecked through dnf config-manager --add-repo (which dnf 5 on Fedora 41 and later no longer has), install dkms without EPEL and ask for nvidia-driver-latest-dkms, which NVIDIA's repositories no longer carry, so the installation always failed. CentOS and other releases are refused, naming the supported ones.
    • modelgrid gpu install sets up container support once, as a step of the driver installation; it used to run the container support step a second time after a successful installation.
    • Docker installation removes only the conflicting packages that are installed (Docker's documented list for Ubuntu, Debian, RHEL, CentOS-family and Fedora systems, asked from dpkg-query or rpm without a shell) and stops with an error naming the packages when the query or the removal fails, for example on a held dpkg lock; it used to run apt-get remove … || true or dnf remove … || true and ignore every failure.
    • Docker installation on dnf systems uses the repository Docker documents for the system (RHEL: linux/rhel; CentOS, Rocky Linux and AlmaLinux: linux/centos; Fedora: linux/fedora), downloads and checks its repository file before anything changes and writes it whole to /etc/yum.repos.d, the same way under dnf 4 and dnf 5. It used to add the CentOS repository on RHEL and run dnf config-manager --add-repo, which dnf 5 (Fedora 41 and later) no longer has.
    • the AMD and Intel drivers add the sudo user to the groups the vendor documents for GPU access (AMD: video and render; Intel: render) without a shell, stop with an error naming the user and groups when that fails, and log which groups users need when there is no sudo user; they used to run usermod … $SUDO_USER || true and ignore every failure. Container support no longer runs chmod 666 on /dev/kfd and the render nodes: it made the GPUs writable for every local user until the next reboot, while containers reach the devices through --device and --group-add.
    • the readme's manual NVIDIA Container Toolkit, ROCm and oneAPI install steps save and check every download before installing it and run each step only after the previous one succeeded, instead of piping downloads into gpg and tee; the ROCm steps no longer point at an installer package that no longer exists.

    Maintenance

    • pnpm 12.11.1 (tooling)
    Downloads
  • v2.0.1 02bcf2bf0e
    Compare

    ModelGrid v2.0.1
    CI / Build & Test (push) Successful in 1m23s
    Details
    Release / build-and-release (push) Successful in 7m18s
    Details
    Stable

    jkunz released this 2026-10-15 12:51:13 +00:00 | 9 commits to main since this release

    Fixes

    • install and update work again without a code.foss.global sign-in: every release carries install.sh as a release asset, the documented one-liner is curl -sSL https://code.foss.global/modelgrid.com/modelgrid/releases/download/latest/install.sh | sudo bash, and modelgrid update downloads the installer of the release it installs instead of the sign-in-only raw file, and fails on a download error instead of running the error page (installer, cli)
      • modelgrid update on 2.0.0 still fetches the raw file and fails; update a 2.0.0 host once with the one-liner.

    Maintenance

    • @git.zone/tsbundle 3.7.0 (tooling)
    Downloads