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

[Christopher Allan Webber]

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?

 - Chris