Re: Services can now have a default value

[Carlo Zancanaro <carlo@zancanaro.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

On Fri, Apr 21 2017, Ludovic Courtès wrote:
> A ‘define-service-type’ macro or similar could generate either code the
> current framework (with <service-type> and <service> and
> <foo-configuration>) or for SRFI-99-style records if we later to go that
> route.
>
> So I think we should start by designing this macro.
>
> How does that sound?

Great! I think that it's sensible to not break things for now, and we
should be able to design the macro to do that.

I'll have a go at it later today and see what I can come up with. (I'm
not very familiar with guile/scheme libraries, but I have played around
a fair bit with macros.)

> Well I don’t know, perhaps in some cases it might make sense to
> automatically instantiate things depended on.  The advantage is that as
> a user of the service (exim for instance) you don’t have to be aware of
> the services it expects (improves separation of concern).
>
> So you could blissfully write just:
>
>   (cons (service mediagoblin-service-type)
>         %base-services)
>
> and behind the scenes it would add an nginx instance, an mcron instance
> with a couple of jobs, a rottlog instance, and so on.
>
> WDYT?

My main concern would be making sure that all of our services have safe
defaults that can be extended. It may lead to surprising outcomes if we
have services spun up which do more than you expect. As an example, if
someone requests exim to start as a dependency, we should make sure it
doesn't turn you into an open relay by default.

Carlo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]