Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Kernel On-Demand Driver Builds: what it means for fleet coverage


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 9079
Topic starter  

TL;DR: A demand-driven kernel build pipeline checks for an existing artifact first, then dispatches a targeted GitHub Actions build only when a node boots on an unbuilt kernel, reducing wasted CI work and waiting time for the driver to load, according to Riptides. The operational lesson is that fleet-specific build coverage beats speculative precompilation when the long tail keeps changing.

NHIMG editorial — based on content published by Riptides: Kernel On-Demand Driver Builds: How We Replaced Speculative Kernel Builds with a Demand-Driven Pipeline

By the numbers:

Questions worth separating out

Q: How should teams handle kernel variants that are not in the prebuilt set?

A: Teams should route those misses through a demand-driven build path that first checks for an existing artifact, then dispatches a precise build only when the exact kernel, architecture, and distribution combination is absent.

Q: Why does distro version matter for kernel module builds?

A: Distro version matters because compiler toolchains and module metadata can differ across releases even when the kernel family is the same.

Q: What breaks when kernel header sources age out of standard mirrors?

A: Long-tail kernels become unbuildable if the pipeline depends only on ordinary repositories.

Practitioner guidance

  • Check for an existing artifact before dispatching a build Return the prebuilt package immediately when GitHub Releases already contains the exact kernel, architecture, distribution, and distro version combination.
  • Validate the full kernel identity before triggering compilation Reject requests that do not include a well-formed kernel version, architecture, distribution, and distro version.
  • Maintain a fallback chain for rolled-off kernel headers Use DNF first, then explicit kernel URLs, then Koji or CBS for RPM-based systems so old kernels remain buildable after standard mirrors age them out.

What's in the full article

Riptides' full blog post covers the operational detail this post intentionally leaves for the source:

  • Step-by-step build-service request handling, including status polling and deduplication logic.
  • The exact GitHub Actions workflow dispatch pattern used to turn a kernel miss into a build run.
  • Distribution-specific fallback handling for Fedora, CentOS Stream, Debian, Ubuntu, and Amazon Linux.
  • Artifact naming, package loading, and cache-key design across host, VM, and Kubernetes environments.

👉 Read Riptides' post on demand-driven kernel driver builds →

Kernel On-Demand Driver Builds: what it means for fleet coverage?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 8508
 

Demand-driven coverage is a governance model, not just an optimisation. The article shows that speculative prebuilds reach a ceiling once kernel variance outpaces the nightly matrix. What matters is not simply building fewer artifacts, but proving that the build system can bind execution to the exact runtime target. For identity programmes, that is the same control problem seen in just-in-time privilege: scope must be resolved at the moment of need, not only at planning time. Practitioners should treat build dispatch, artifact reuse, and variant matching as part of the control surface.

A few things that frame the scale:

  • Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
  • 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

A question worth separating out:

Q: How should platform teams decide whether to prebuild or build on demand?

A: They should prebuild the common case and reserve on-demand execution for the long tail that the fleet actually encounters. That approach reduces wasted CI time while still preserving readiness for unusual kernels. The decision signal is real runtime demand, not how many possible variants exist in theory.

👉 Read our full editorial: Demand-driven kernel driver builds reduce coverage gaps and wait time



   
ReplyQuote
Share: