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: Chris Marusich
Subject: Re: (Exposing?) config files and non-start/stop operations
Date: Sun, 20 Nov 2016 20:54:35 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Christopher Allan Webber <address@hidden> writes:

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

Why not?  I read the rest of your email but this wasn't clear to me.

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

Why do those activities need to be represented as actions in Shepherd?
If we're running a daemon or service that already exposes a mechanism
for manually running tasks like these, then can't we just use "the usual
mechanism" for doing it?  For example, if we're running a daemon that
already provides a script to perform garbage collection, can't we just
invoke that script?  It isn't clear to me why we would need to model
domain-specific actions like that in Shepherd, although I can see why it
might be convenient.  Am I missing something?

-- 
Chris

Attachment: signature.asc
Description: PGP signature


reply via email to

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