Init pm

[AntonFomichev-Flant]

Description

Migrate DVP runtime images to base/distroless + Flant package manager (pm)

Why do we need it, and what problem does it solve?

Previously, every runtime dependency was compiled from source inside dedicated images/packages/* build recipes — a slow, fragile approach that required maintaining custom werf stages for each library. Any version bump meant touching multiple places across the repository.

The Flant package manager (pm) solves this by treating dependencies as OCI artifacts: pm install resolves the full dependency graph, verifies content digests, and places binaries and libraries in a single deterministic operation. No more hand-crafted build stages per library, no more ABI surprises between build and runtime.

Migrated

The following packages — previously built from source as individual images/packages/* werf stages — are now delivered via pm install:

• acl, bzip2, cyrus-sasl2, dmidecode, dtc, e2fsprogs, file, gcc, glib2
• glibc, gnutls, keyutils, krb5, libaio, libattr, libaudit, libbrotli, libbsd
• libburn, libcap, libcap-ng, libcapstone, libcurl, libffi, libfuse2, libfuse3, libgcrypt
• libgmp, libgpg-error, libgsasl, libidn, libidn2, libisoburn, libisofs, libjansson4, libjson-c5
• libjson-glib, libmd, libmnl, libnbd, libnftnl, libnl3, libntlm, libpixman, libpng
• libpsl, libqpl, libseccomp, libslirp, libssh, libssh2, libtasn1, libtirpc, libtpms
• libunistring, liburing, libuserspace-rcu, libvirt, libxcrypt, libxkbcommon, libxml2, linux-pam, lvm2
• lz4, lzo, multipath-tools, nbdkit, ncurses, nettle, nftables, nghttp2, nghttp3
• ngtcp2, numactl, openldap, openssl, p11-kit, pcre2, rdma-core, readline, selinux
• snappy, swtpm, systemd, ubdsrv, util-linux, xz, zlib, zstd

Switching to base/distroless as the final base image aligns the runtime environment with the build environment, eliminating the class of issues where a binary compiled on ALT would behave differently at runtime.

What is the expected result?

The following final-stage images are now based on base/distroless with runtime dependencies managed via pm install:

• virt-launcher
• virt-handler
• dvcr
• dvcr-importer
• dvcr-uploader
• pvc-importer

Additionally, the build stages for virt-artifact and pvc-artifact have been migrated from builder/golang-alt-1.25 to builder/golang-1.25, aligning the glibc version across build and runtime environments.

Image sizes reduced by ~91 MB per image (e.g. virt-launcher: 279 MB → 187 MB).

images/packages/ legacy build recipes and version pins in base-images-pins.yml are transitional — see TODO below.

TODO (follow-up)

1. images/packages/ migration — legacy per-library build recipes are still present and should be removed once pm fully covers all runtime dependencies.

2. Builder stages migration — the following build-stage images still use builder/golang-alt-1.25 and are candidates for migration:

   • dvcr-artifact — uses CGO, needs builder/golang-1.25 (gcc + go + pm)
   • bounder, hooks, kube-api-rewriter, pre-delete-hook, virtualization-artifact, virtualization-dra, vm-route-forge — pure Go, no CGO; should be migrated to builder/golang-1.25
   • edk2 remains on ALT intentionally — requires a full native toolchain (clang with BPF target, acpica, nasm) not yet available in container-factory

3. Remove version pins — base-images-pins.yml currently pins base/distroless and builder/distroless to specific container-factory digests. In the ideal world there should be no manual pins: the module should track container-factory releases automatically. The pins are a transitional measure.

4. Go 1.26 upgrade — builder/golang-1.26 is already available in container-factory. Once build stages are fully migrated off ALT, upgrading to 1.26 is a straightforward one-line change per image.

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.

Changelog entries

section: images
type: feature
summary: "Migrate runtime images to base/distroless + pm install, replacing per-library build recipes and reducing image sizes by ~91 MB."