Re: Service refactoring

[Christopher Allan Webber]

Ludovic Courtès writes:

> "Thompson, David" <address@hidden> skribis:
>
>> On Mon, Sep 21, 2015 at 12:00 PM, Ludovic Courtès <address@hidden> wrote:
>>> Andy Wingo <address@hidden> skribis:
>>>
>>>> On Sun 20 Sep 2015 15:42, address@hidden (Ludovic Courtès) writes:
>>>>
>>>>> I’m quite happy with the result, but comments are welcome!  I’ll convert
>>>>> some more services to see how it goes.
>>>>
>>>> Neat!  Sounds great.  One question: there are some services like colord
>>>> or geoclue that don't need to be managed by DMD, but are just declared
>>>> as services so that their users are created, there /var/foo directories
>>>> are created, etc.  The can be started by D-Bus as needed.  Does the new
>>>> design support services of this kind?
>>>
>>> Yes it does.
>>>
>>> ‘colord’ will “extend” the D-Bus service by giving it its package object
>>> (thus its .service files), it will extend the activation service by
>>> providing it #~(mkdir "/var/foo"), and it will extend the account
>>> service by passing it its user accounts/groups.
>>
>> I'm picturing an enhanced 'nginx-service' that is able to accept site
>> configuration files from other services (say, a MediaGoblin service)
>> and it sounds like a great feature.
>
> Yes, that’s the idea.

You've already heard me say it elsewhere, but I'm suuuuuuper excited
about this.  I've already written about it on the pumpiverse, so for
posterity, here's that link:

  https://identi.ca/cwebber/note/vNnKxmgtQBOO2W82r0ZgwA

Glad to see mediagoblin-service being used as an example too :)

>> Now, is the following scenario possible?: 'mediagoblin-service' can
>> extend both 'apache-service' and 'nginx-service', and when the system
>> configuration is realized, the web service the user has chosen is
>> extended.
>
> If it makes sense, there could be a single ‘web-service-type’ that both
> Apache httpd and NGINX would implement.  The MediaGoblin service would
> extend them by providing something like a vhost specification I suppose?

I think that's right.

> Now, perhaps we would need separate ‘httpd-service-type’ and
> ‘nginx-service-type’ if httpd and NGINX happen to be extensible in
> different ways.  I don’t really know these tools, but it would be good
> to see how we would do it.  WDYT?
>
> Ludo’.

So, nginx and apache have pretty drastically different config file
types.  However, most of the things users want I think are compatible
with both.  We probably want a "minimal" service that just accepts
whatever config files for apache and nginx, and just lets the user
specify that whole manually.  We can have more advanced procedures for
building up a config file by translating our world-of-s-expressions or
whatever schemey types into the config file format... but given "just
how much" you can do with nginx and apache that is just so wildly
different between the two, we probably want something that provides an
abastract representation of what most web applications need, some sort
of "medium common denominator" (I don't think we need to shoot for
lowest here!).  That way we can have a general way of letting
applications specify what they need from their web server, but also
allow a sysadmin to go "full on manual" if they need to with the config
file formats.

Dave / Ludo: Does that fit with what you two are thinking as well?

 - cwebb