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: Christopher Allan Webber
Subject: Re: (Exposing?) config files and non-start/stop operations
Date: Mon, 21 Nov 2016 10:21:50 -0600
User-agent: mu4e 0.9.16; emacs 25.1.1

Ludovic Courtès writes:

> 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?

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






reply via email to

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