Modular services meeting #1 2026-05-26

Development
1

modular services meeting #1 2026-05-26

Hi everyone,

Today we met to sync up on modular services design and development. We’ll meet again in about 2 weeks time; join #modular-services on the NixOS Matrix if you’d like to participate.

These are not top notch meeting notes as we were all engaged in conversation and thought, but at least they give an impression of the topics discussed.

—–

Attendees today: @aanderse @lassulus @kiara @Eveeifyeve @roberth

lassulus ideas (written up before meeting)

  • want to expose services (for long running packges)
  • wants to support wrapped packages (for long running and short running packages)
  • wants to map execve as a very small base layer execve(2) - Linux manual page
    • basically everything uses execve under the hood
    • we can add additional stuff around it that basically maps to execve later on
  • we should start small and expand later (out of tree experiments are fine)
    • for the beginning only systemd and wrapper support

meeting minutes

  • status: for now keep things experimental, should find what works rather than get stuck on bad interfaces
  • contracts?
    • don’t need to abstract over package differences
  • negative feedback at tracking issue, modular services thread
    • tried to better explain at tracking issue and by reaching out
    • one concern seemed preventing doing a flakes, tho to get things going we need to attract contributors too
  • how do services relate with e.g. databases?
    • implicit like in nixos? → default to sub-services
    • explicit? → contracts, potentially between nodes
      • e.g. k8s likes to see services separately to know what’s healthy vs what failed and needs to be brought up again
    • → status: needs more experimenting
  • manual entry
    • add link to matrix channel + tracking issue?
  • idea on renaming to package modules
    • no objections, mostly a documentation thing
    • wrapper PR rebasing TODO@lassulus
  • how to extract options
    • maybe don’t
    • get it from pkg.modules.default etc
    • mynginx = { imports = [ nginx.modules.default ]; options.....; }
  • kiara: should we not separate generic services modules vs system-specific ones (living in the systems’ repos)? cuz these need system-specific options
    • aanderse: then what’s the value proposition for consuming systems like finix? get the data model correct in nixpkgs, e.g. on reloading.
    • kiara: would robert’s idea of shims address this concern, adapting to a given system based on the info exposed in a modular service?
    • aanderse: potentially yes
  • modular services option set:
    • aanderse: we should expand what we offer, not every implementation needs to use every option
    • let’s add a reload command as well as a notification protocol
  • meeting cadence:
    • attendants found this meeting useful
    • let’s try every 2 weeks
    • TODO@lassulus make new crabfit
    • TODO@lassulus add to official calendar (and link it in the matrix)
  • action items
    • provide more info to other service managers
    • roberth: finish platform-generic “compliance” test
    • roberth: review environment PR
    • kiara: continue on docs/user-service/(environment) PRs
    • roberth: post this to discourse
8 Likes
Modular services meeting #2 2026-06-12