[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nix-dev
Subject:    Re: [Nix-dev] Service composition
From:       Ertugrul =?utf-8?Q?S=C3=B6ylemez?= <ertesx () gmx ! de>
Date:       2014-12-31 13:53:59
Message-ID: 878uho3oy0.fsf () phobos ! Speedport_W_723V_1_36_000
[Download RAW message or body]

Hi Ludovic,

>> 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?

Yes.  It specifies everything to build a machine for the purpose of
carrying out the task that the service denotes, but in such a way that
two such machines can be combined into a single machine.

I still need to figure out a few details though, especially since I'm
relying on a lot of Linux technology here.  I'd like to keep it
sufficiently general that users of other kernels (most notably FreeBSD)
can benefit from it as well.


>> 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.

It would split the view on the configuration into two parts:  services
and environment.  For example networking belongs to the environment, so
requirements on the network as well as networking options will be part
of a service.

This means that creating a bridge device amounts not to adding a
service, but to applying a service morphism:

    withBridge brCfg (br:
        service1 br <> service2 br)

This reminds me that it would be great if Nix would allow some way to
define custom infix operators or at least provide a few generic ones.
At this point we will need to use prefix notation, which might make this
a bit uglier:

    withBridge brCfg (br:
        compose (service1 br)
                (service2 br))

Although it's just monoid composition, so using a list argument would do
the trick.  Just a nice-to-have.


Greets,
Ertugrul
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[prev in list] [next in list] [prev in thread] [next in thread]