Whereas, from user standpoint, it makes sense to have a hierarchy of services. Say, a infra-switch service expands to both a postgres process and a process-tracker service, which then further expands to a Haskell process and its own postgres process. Here, we can define a custom service for postgres-tracker service, but not the infra-switch service, unless we give up on it being a multi-instance service.
graph TD
A[infra-switch service] --> B[postgres process]
A --> C[process-tracker service]
C --> D[Haskell process]
C --> E[postgres process]
style A fill:#f9f,stroke:#333,stroke-width:2px
style C fill:#ccf,stroke:#333,stroke-width:2px
style B fill:#cfc,stroke:#333,stroke-width:2px
style D fill:#cfc,stroke:#333,stroke-width:2px
style E fill:#cfc,stroke:#333,stroke-width:2px
In principle, we don't intend to run multiple instances of infra-switch ... however, making it multi-instance means we can leverage name in certain places, like namespace (cf. #258) and generally provide a consistent modular interface.
This restriction is so because by design we can only output processes (via
outputs.settings) not further services.https://github.com/juspay/services-flake/blob/7200b458b5719eaf08c72eb7110b889f25b8e26f/nix/lib.nix#L43-L54
https://community.flake.parts/services-flake/custom-service#multi-instance
--
Whereas, from user standpoint, it makes sense to have a hierarchy of services. Say, a
infra-switchservice expands to both a postgres process and aprocess-trackerservice, which then further expands to a Haskell process and its own postgres process. Here, we can define a custom service forpostgres-trackerservice, but not theinfra-switchservice, unless we give up on it being a multi-instance service.In principle, we don't intend to run multiple instances of
infra-switch... however, making it multi-instance means we can leveragenamein certain places, likenamespace(cf. #258) and generally provide a consistent modular interface.