guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (Exposing?) config files and non-start/stop operations


From: Ludovic Courtès
Subject: Re: (Exposing?) config files and non-start/stop operations
Date: Mon, 21 Nov 2016 15:18:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Hello!

Christopher Allan Webber <address@hidden> skribis:

> Christopher Allan Webber writes:
>
>> Hello,
>>
>> I'm writing a service for dirvish, and I realized that if I'm following
>> current guix service routes, I might not be able to run all the
>> operations I need to.  It seems that the current route for Guix is to
>> have your service write out a config that more or less becomes part of
>> the environment for starting / stopping a daemon via Shepherd.  But what
>> if that's not all you need to do?
>>
>> Aside from just "running as a daemon", plenty of (especially
>> applications which manage state) will need to have other commands that
>> are unlikely to be run from shepherd.  For example:
>>
>>  - Initializing a data store.  For example, in dirvish I need to run
>>    a command to initialize a "vault" where I will be storing my data.
>>  - Manually invoking a garbage collection utility.
>>  - Manually invoking an integrity check utility.
>>  - Possibly some side effect involving querying the network.
>>  - Running schema migrations.
>>
>> All sorts of things!  Most of them (all?) involve state or side effects,
>> but plenty of our most important services will be "state overlords" of
>> some type.
>>
>> So it seems to me that one of two things will be needed... either:
>>
>>  - Expose the configuration file directly, possibly by putting in
>>    `${profile}/etc/foo'
>>  - Expose "wrapped" utilities.  For example, instead of invoking
>>    "dirvish" directly, I might invoke a wrapped dirvish.
>
> Talking about this with Ricardo Wurmus on irc, the idea of launching
> such a utility from shepherd itself came to mind.
>
> So imagine you want to run a tool like this:
>
>   foo-db --config=/path/to/foodb-config.cfg gc --aggressive
>
> It looks like shepherd has an "action" slot/method:
>
>   
> https://www.gnu.org/software/shepherd/manual/html_node/Slots-of-services.html#Slots-of-services
>   
> https://www.gnu.org/software/shepherd/manual/html_node/Service-Convenience.html#Service-Convenience
>
> So I wonder if we could add additional actions, and do something like
> this:
>
>   herd gc foo-db --aggressive
>
> Or, even more lazy (but maybe not as good?):
>
>   herd run-cmd foo-db gc --aggressive
>
> Anyway, either of these examples would call the appropriate command but
> implicitly pass in the --config parameter appropriately.
>
> It looks like (gnu services shepherd) doesn't expose the "actions" slot,
> but couldn't we do that?
>
> This seems like the right route.  What do others think?

We could do that (and custom actions would probably be useful in other
contexts), but like the other Chris ;-), I’m not sure whether this is
necessary.

So it seems to be that the state-management commands (initialization
commands, DB schema migration commands, etc.) could be run either:

  1. By an “activation snippet”, by extending ‘activation-service-type’
     like many services do.

  2. By an auxiliary Shepherd service, say ‘dirvish-init’, that the main
     service, say ‘dirvish’, would depend on.

How does that sound?

HTH,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]