Feature request: noDB flag

[leenaars]

It doesn't make sense (especially on systems with scarce resources) to have many instances of similar services looking after databases that will never not exist. My test setup has a limited amount of inodes, which is eaten up by a very large nix store. That situation is likely to be quite common in cheap hosting. Database software is big (>3000 inodes for postgresql in the nix store) so this helps ...

[qknight]

i'm a bit confused, do you request support for https://github.com/Miserlou/NoDB?

My test setup has a limited amount of inodes, which is eaten up by a very large nix store.
having multiple databases, one per webservice, helps in separation of concerns and mainly requires more RAM and not so much more inodes.

[leenaars]

No, the suggestion I'm making is that currently every instance of a webservice adds a .service for a database component - even if there is not a database required. That pollutes the service overview, and produces cruft. For instance for leaps there is no database required... So a way to indicate somewhere, somehow that the webservice does not use a database nor ever will.

(Perhaps similar to how you can indicate which phases you want to run in nixpkgs - which speeds things up)

[qknight]

sounds like something we should do

[aszlig]

@leenaars: I'm not quite sure what you mean exactly, because the actual database service is only enabled whenever there are databases defined.

The only unit that's really always there is database.target, which is used for ordering instance startup:

$ nix-store -qR $(nix-instantiate tests -A webservices.leaps) | grep database
warning: you did not specify '--add-root'; the result might be removed by the garbage collector
/nix/store/g07divd6myf8w90z34mdkqchczm82snp-unit-leaps-bar-database.target.drv
/nix/store/xrvdcv4dfjm4w4lyryj8r6gnb71ym25k-unit-leaps-foo-database.target.drv
$

[leenaars]

Lots of empty targets clutter the user understanding (these are still listed with the 'real' targets and services when the end user looks at it). There are cases where I would expect many identical instances to live alongside each other, with databases categorically not needed (like when hosting tens of different tiny static sites or web apps).

Having an optional flag to turn these 'boilerplate services' off generically in the service definition seems an easy win to reduce clutter.

[aszlig]

@leenaars: I think using such a flag for something that we can figure out automatically would add even more confusion, so now (ce59aed) the targets are no longer there if no databases are assigned.

Does that address your issue?

[leenaars]

Even better. Thanks!