Re: [PATCH] improve nginx-service

[ludo@gnu.org (Ludovic Courtès)]

Hi, and sorry for the delay!

julien lepiller <julien@lepiller.eu> skribis:

> Le 2016-11-22 23:20, Hartmut Goebel a écrit :
>> Am 20.11.2016 um 13:49 schrieb Julien Lepiller:
>>> What do you think? should I continue in that direction, or should I go
>>> back to what I was doing before?
>>
>> Thanks for working on this. I will give it a try the next days. But I
>> want to share two points going around in my head:
>>
>> 1) I propose moving the nginx service into a package
>> gnu/service/nginx.scm. Imagine we will implement an equal complex
>> config
>> schema for apache. Then we will get a beast of code with lots of
>> useless
>> "nginx-" prefixes.
>>
>> 2) Is it possible to add some magic to e.g. "nginx-service-type" so
>> that
>> all identifiers within are searched in the "nginx" scope. Example:
>>
>>       (service-extension
>>         nginx-service-type
>>          (const (list (server    ;; taken from "nginx" scope
>>                         (blocks (list))
>>                         (configs (list
>>                                   (option (type 'server_name)     ;;
>> taken from "nginx" scope
>>                                           (value (list 'default)))
>
> I am quite new to scheme, but as far as I can tell, there is no notion
> of scope. Here, (option ...) can be independent from nginx or apache
> (because there is nothing specific), but probably not (server),
> because it is a notion specific to nginx and because what it can
> contain is different in the apache world and nginx world. Also, how
> would the two types be recognized when you want both apache and nginx
> (probably not useful, but it may happen)?
>
> I've been rethinking it, and I would like to use define-configuration
> (from cups and dovecot) because it looks really good. But I don't want
> to define the same config option for each possible block it can appear
> in, and that's why I used (option). So I'm looking for a way to
> dynamically define records for each block type, so they can be used
> more consistently with what we have. Unfortunately, I don't see how I
> could do that, if that is possible at all... Ludo, any idea? I'd like
> to be able to write:
>
> (define-record-type* <nginx-option>
>   ...)
>
> (define-syntax option
>   (syntax-rule ()
>     (option mname mtype mdef mdoc mblocks))
>     (nginx-option (name mname) (type mtype) ...)))
>
> (define option-list (list
>   (option 'server-name server-name 'default "the name of the server
> that is served by the http block" (list 'http))
>   ...))
>
> and then be able to create the block records by filtering that list:
>
> (define-nginx-configuration nginx-http-block
>   (filter ... option-list))
>
> (define-nginx-configuration nginx-events-block
>   (filter ... option-list))
>
> (define-nginx-configuration nginx-server-block
>   (filter ... option-list))
>
> So the user would then be able to write the service configuration as
> they would for any other service we have. What I don't know is how to
> write define-nginx-configuration (ideally it would call
> define-configuration). With it, I can probably do the rest just
> fine. Or maybe there is a better way I don't see yet?

I’ve played a bit with nginx and I think its configuration syntax is far
from trivial.  Services for Dovecot, Kerberos, glibc’s name service
switch, PAM, etc. are pretty clear: it’s quite easy to find out what
data structures the config defines, and to write Scheme bindings for
those structures.

In the case of nginx, it’s much more complex: there’s a notion of scope
and inheritance (some key/value pairs are inherited from the “parent”
context), there are conditionals, variables, keys associated with more
than one value, etc.  Tricky.

So there are two ways to approach it:

  1. Choose a small subset of the functionality, like you’ve done with
     vhosts, and provide bindings for that subset.  It’ll be less
     expressive than nginx’s config files (so users need a way to
     provide nginx-language config when needed), but it can still be
     useful.  And it’s not too hard to implement.

  2. Write bindings for the whole configuration language, such that
     there is no loss of expressivity.  This is the grail, but obviously
     it requires a very good understanding of that language, and it’s
     going to be much more work.

I think it would make sense to stick to #1 in the short- to medium term.
But if you’re an nginx wizard, you might find that #2 is piece of cake;
you’ll have to decide!  :-)

Back to the original comment about “vhost”, I think we could simply
replace “vhost” with “server” in the code, since those
<nginx-vhost-configuration> objects map to ‘server’ blocks.

WDYT?

Thanks,
Ludo’.