multiService: Add `depends_on` as a default option

[shivaraj-bh]

multiService defines a few options defaults like enable, namespace and dataDir, which can reasonably expected to be defined by all the services.

I propose to also include depends_on here.

Why?

• Often we end up splitting depends_on config for a service away from the service config, see

  {
    open-webui."open-webui1" = {
       enable = true;
        …
    };
  
    # Start the Open WebUI service after the Ollama service has finished initializing and loading the models
     settings.processes.open-webui1.depends_on.ollama1-models.condition = "process_completed_successfully";
  }

  (code snippet from example/llm)

  If this proposal is implemented, it can be changed to:

  {
    open-webui."open-webui1" = {
       enable = true;
       depends_on.ollama1-models.condition = "process_completed_successfully";
        …
    };
  }

• depends_on is an option almost always used while defining complex service dependency relationship.

[shivaraj-bh]

Note: As of now, you can define a depends_on option in the module and merge it with settings.processes.<name>.depends_on in outputs.settings.<name> inside config. This issue is to avoid the manual definition and allow this by default.

[srid]

Maybe:

{
  open-webui."open-webui1" = {
     enable = true;
     processSettings = {
       namespace = "foo";
       depends_on.ollama1-models.condition = "process_completed_successfully";
     };
  };
}

The idea being that processSettings would be submodule taking arbitrary process-compose options.

Then we can use that directly here (where namespace is currently hardcoded):

services-flake/nix/lib.nix

Lines 39 to 41 in 4104b44

	default = {
	namespace = lib.mkDefault config.namespace;
	};

[shivaraj-bh]

Maybe:

{
  open-webui."open-webui1" = {
     enable = true;
     processSettings = {
       namespace = "foo";
       depends_on.ollama1-models.condition = "process_completed_successfully";
     };
  };
}

Ah, much better.

[shivaraj-bh]

I am stuck on #617

Dumping my thoughts here to revisit:

I implemented the processSettings option from above, with a slight modification - to use the type lazyAttrsOf deferredModule instead of just a deferredModule, as a service can define multiple processes. (#617 (comment))

While setting processSettings.<name> works as expected, it is unrestricted - in that, one can modify the settings for any process from here.