0.3.1

Release notes for simrun 0.3.1

Faster images and a run on the k3d test cluster which takes about as long as on the machine itself: the smoke workflows run every analysis of sbmlsim and the HCTZ model of pkdb_models through simrun, and their timelines show where the time of a run goes. A retry with more memory, which never fitted its node, now does.

Features

• Smoke workflows. tests/smoke/run.py runs the analyses of sbmlsim (simulate, fit, identifiability, fisher, report, petab, scan, sensitivity, uncertainty) and the simulations, a fit and the build of the models of pkdb_models through simrun, from the checkouts of both, locally (--local) or on the local test system (--k3d). After every run it prints the timeline of its tasks (tests/smoke/timeline.py): the wait for the dependencies, the pod, its admission and its start, the preparation, the work, the merge, the cpu and the CPU throttling of every task, and the seconds of the environment and the image. On the same machine sbmlsim takes 78 s on k3d and 60 s locally, pkdb_models about 250 s both. See Smoke workflows.
• Faster images. The images compile the bytecode of their packages, so a pod no longer compiles at every import, and keep the downloads of uv in a cache of BuildKit, whose state is now on a volume and outlives its pod. A cold image of sbmlsim builds in 47 s instead of 85 s, an image after a change of simrun in 6 s, and is 378 MiB instead of 583 MiB.
• Git in the images. The image of an environment installs git when a dependency is locked from a git repository, e.g. sbmlsim from GitHub in the lock of pkdb_models.
• The reports of the workers. A report carries when its harness started, the seconds it prepared (the install of the sources, the restart, the imports), the cpu of its units and, in a pod, the seconds its CPU quota held it back (started, prepare_seconds, cpu_seconds, throttled_seconds). The service reads the report of a newer harness and ignores the fields it does not know. The coordinator logs the seconds of its merge.

Fixes

• A retry with more memory waited for Kueue forever when its memory, e.g. 5 GiB times the retry factor, came out a hair above a whole GiB and was rounded up beyond the memory of every node: a pod is now sized to whole GiB without the noise of floating point.
• A watch of the workflows which the API server or a proxy cut starts again at once with a note in the log, instead of with a warning after 5 s.
• BuildKit asks for one core in k3d and may use four, so the controllers still fit the server node of a runner with four cores, and the setup of the k3d cluster fails at once on an error of the manifests instead of after ten minutes.

Upgrading

• Apply deploy/cluster again: BuildKit gets the volume buildkitd-state (local-path, 50 GiB) and a rolling update of one pod at a time.
• Every model builds its image once more on its first run, as the Dockerfile changed.