Ludovic Courtès writes:
> Hello!
>
> Christopher Allan Webber <cweb...@dustycloud.org> 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?
That's probably fine in most cases; if you read my reply to the other
Chris Marusich you'll see that there are still some cases where you
might need to run commands manually... eg a "dumpdb" type command.
Maybe that could be handled by #2, but it seeems like in a dumpdb type
command you might need to be able to pass in arguments. It seems like
Shepherd actions are the right case for such a thing?
- Chris
