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?
HTH,
Ludo’.
