[Nix-dev] Service composition

[Ludovic Courtès]

Ertugrul Söylemez <ertesx at gmx.de> skribis:

>> FWIW, Guix uses an approach along these lines: the ‘bitlbee-service’
>> function, for instance, returns a ‘service’ object as a monadic value
>> (see
>> <http://www.gnu.org/software/guix/manual/guix.html#Defining-Services>
>> for details.)
>
> The way I understand the section on the store monad is that it's really
> a state monad with a view on the current store (they should really show
> the underlying types to make this easier to understand).

Yes.

>> What’s unsatisfying (and thus subject to change) is that
>> ‘operating-system’ objects (which are pure declarations) end up with
>> monadic values in their ‘services’ field.  That makes it inconvenient
>> to, say, filter items from that list, or to tweak their configuration,
>> because one first needs to bind them.  That said, it’s probably not a
>> problem for Nix, because every Nix function is really a function in
>> what we call the “store monad”.
>
> You could think of it that way, if you wanted.  I prefer to think of
> what Nix does as the same magic that functional languages do with other
> resources like memory (alloc and GC).

Sure.  You realize there’s no magic when you actually implement the
store in a general-purpose language.  ;-)

> As a first approximation there would be a Service monoid, which would
> combine certain typical attributes about a service, including startup
> scripts, required bind-mounts, required system resources and if really
> necessary shutdown scripts (most programs should shutdown properly when
> the container goes down).
>
>     Service : Mon
>
> Its identity idS would be the empty service, which you can think of as
> an empty group of processes with no mounts, no resources, etc.
>
> The Bitlbee service would be constructed through a regular function that
> takes the typical bitlbee options.  Nothing special here:
>
>     bitlbee : BitlbeeConf -> Service

OK.  I suppose ‘Service’ would specify required user accounts, PAM
services, etc., right?

> The nginx function is more interesting.  It involves a second monoid,
> the monoid of web services (identity idW):
>
>     WebService : Mon
>
> Then nginx is a monoid morphism,
>
>     nginx : WebService -> Service
>
> that is a function with additional structure, in particular:
>
>     nginx x ◇ nginx y ≡ nginx (x ◇ y)
>     nginx idW ≡ idS

Very interesting.  I wonder what other types of services would benefit
from similar treatment.

[...]

> I hope this gives a first impression of how everything would fit
> together.

Definitely.  That gives me a fair amount of food for thought.

Thank you!

Ludo’.