Is it possible to define systemd services in a submodule?

maberggrav · February 9, 2024, 1:59pm

Is it possible to define top-level systemd config inside a submodule?

To elaborate more on the question, let’s say you define a module that has one option which is a submodule and is responsible for defining the systemd config of one type of service. Then you have another submodule responsible for defining the systemd config of another type of service. Since systemd is top-level config, it will not be accessible inside the submodule.

Is there a way of making it accessible?

I know it is possible to just flatten the structure and define one module called instance1 and one module called instance2, but when working with many module-instances it is beneficial to create a hierarchical structure so that the config is more easily organized.

Appreciate all help

{ config, lib, ... }:
with lib;
with types;
{
  options.myModule = {
    instance1 = mkOption {
      type = submodule {
        options = {
          # Define instance1 options here
          # ...
          # ...
        };
        config = {
          systemd.services = {
            # Define instance1 systemd service-config here
            # ...
          };
        };
      };
    };
    instance2 = mkOption {
      type = submodule {
        options = {
          # Define instance2 options here
          # ...
          # ...
        };
        config = {
          systemd.services = {
            # Define instance2 systemd service-config here
            # ...
          };
        };
      };
    };
  };
}

aanderse · February 9, 2024, 10:46pm

is there a problem with defining systemd services for each of the instances inside your top level module config, or you just want to structure it that way for mental clarity?

maberggrav · February 10, 2024, 3:21pm

Both for mental clarity and for the possibility of bulking systemd services together. I want to have an enable-option in my module which gets inherited to the instances. The idea is that i can enable/disable multiple systemd services at a time.

aanderse · February 11, 2024, 2:20pm

generally no you can’t do that

the main options you have are too create multiple systemd services with something like lib.mapAttrs, lib.genAttrs, etc…, or using systemd templates - let me know if you need any clarification on that

i will mention for fun that @roberth had some interesting ideas in RFC 163 to make something similar to what your want a possibility

roberth · February 11, 2024, 8:23pm

The short answer is indeed “no”, but you could manually forward information from a submodule to systemd.services and any other options that you want the submodule to affect.

@nbp and I have discussed such a feature before:

github.com/NixOS/nixpkgs

NixOS modules: Add mkSuperOptionAlias and mkForEachSubModule.

NixOS:master ← nbp:super-option-alias

opened 07:50PM - 30 Dec 21 UTC

nbp

+216 -9

Previously, getting values from submodules to modify the super-module options, …required more complex filtering logic which is dependent on the option type wrapping the submodule, as well as making sure that the types are coherent. This change makes it possible to easily set super-module options from submodule aliases. This change adds 2 major functions: `mkSuperOptionAlias` and `mkForEachSubModule`. `mkSuperOptionAlias` is made to create an option within a submodule, which inherit the type of a parent module option, if it exists as well as preventing any uses of its computed output. Previously, an easy mistake when implementing such aliases was to use the computed value of the option. Using the computed value is a problem as the type, which provide a `merge` and `apply` function is not garanteed to be idempotent. The work-around is to expose the `options` with the `submoduleWith` argument named `exportOptionsUnderConfig`. This flag, set to `false` to avoid regressions, when enabled, it will add the `options` attribute under the configuration produced by each submodule instance. This is mandatorry to extract option `definitions` using `mkAliasDefinitions`. `mkForEachSubModule` is made to abstract over the wrapping type of submodules, and forward definitions with `mkAliasDefinitions` or similar functions, to skip over complexity induced by the `merge` and `apply` function logic. This works by adding a new attribute named `extractSubValues` to each option type. This attribute is a function which is responsible from unpacking any wrapping types which are wrapping submodules, such as list or attribute sets, and return an unordered list of submodule instances. Each submodule instance is then iterated over and given as argument to the first argument, which is in charge of producing a valid module or option definition. This is best achieved with `mkAliasDefinitions` followed with the access to the option exported by the submodule, using `exportOptionsUnderConfig` flag of the `submoduleWith` type. The following example illustrates how these functions can be used to aggregate all definitions defined within multiple submodules, into the super-module which collect all these definitions. ``` { config, options, lib, ... }: let superOptions = options; in { # Suppose that the following option exists: # options.aggregate = lib.mkOption { .. }; # `namedAggregate` is a tiny submodule which exposes `super.aggregate`, and let # the use set parts of the aggregated content under a specific name, such as: # # namedAggregate.setupEtc.super.aggregate = " .. "; # namedAggregate.setupBin.super.aggregate = " .. "; # # All of which would be used as a definitions of the `aggregate` option. options.namedAggregates = mkOption { type = with lib.types; attrsOf submoduleWith { # Expose the eval.options attribute used as argument of `mkAliasDefinitions` exportOptionsUnderConfig = true; modules = [ # Create a sub-module which aliases the super-module option, if it exists. # # To explicit the fact that this option is used only by the super-module, # it is added under `super.` attribute set, which might be a convention. # # Using (.. or null) as argument is useful for submodules which can be # embedded in various super-modules. As, this will also work if the # option does not exists. ({ lib, ... }: { options.super.aggregate = lib.mkSuperOptionAlias (superOptions.aggregate or null); }) ]; }; }; config = { # Collect all options definitions from submodules, if they are defined. # `mkForEachSubModule` iterate over all submodule instances. Each instance # `eval` has an attribute named `options` exposed by `exportOptionsUnderConfig` # flag. This `options` attribute is the same as the `options` argument of # submodules and contains the hierachy of options declarations and definitions. # `mkAliasDefinitions` is then used to extract options definitions if the # option is set in the submodule. aggregate = lib.mkForEachSubModule (eval: lib.mkAliasDefinitions eval.options.super.aggregate) options.namedAggregates; }; } ``` ###### Things done Tested locally using: ``` cd <local-nixpkgs>/lib/tests NIX_PATH=<local-nixpkgs> ./modules.sh ``` All changes made here are new functions, or should be backward compatible.

However, this feature was not merged, and so “supermodules” are still a hypothetical feature, or perhaps an implementation pattern where a module forwards generic definitions from submodules to “cousin” options outside those submodules.
I think the PR stalled because it is non-trivial, yet does not add functionality that could not be expressed before.

RFC 163

Here’s an example of copying information from a submodule to its destination - systemd.services. Because that information is in the form of whole modules, it’d be quite a generic mechanism.

maberggrav · February 12, 2024, 8:41am

Thank you for your help! I looked into the “supermodules” idea and agree that it, if available, could be very beneficial. Currently i have found a work-around where i create a systemd service for each instance in the top-level module by using the instance-options and passing them through a “mkServiceConfig” function. However, this becomes difficult especially when having multiple submodule “layers”.

{ config, lib, ... }:
with lib;
with types;

let 
  cfg = config.myModule;

  mkServiceConfig = name: instance: 
  mkIf instance.enable {
    "${name}" = {
      wantedBy = [ ... ];
      # Systemd config here
      # ...
    };
  };
in {
  options.myModule = {

    enable = mkEnableOption "MyModule";

    instances = mkOption {
      type = attrsOf submodule ... ;
    };
    
  };

  config = {
    systemd.services = (mkMerge (
      map
        (name: mkServiceConfig name cfg.instances."${name}")
        (attrNames cfg.instances)
    ));
  };
}