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: Ludovic Courtès
Subject: Re: (Exposing?) config files and non-start/stop operations
Date: Sat, 26 Nov 2016 18:43:19 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Christopher Allan Webber <address@hidden> skribis:

> Ludovic Courtès writes:

[...]

>> The protocol currently is just: you connect, you send a request, you get
>> a reply, and you disconnect.  Actions are expected to be non-blocking.
>
> Okay, an expectation of non-blocking behaviour is useful to know.
> Especially because I'm not sure it's a guarantee we can provide.  Eg,
> imagine one of the previous commands, such as dumpdb or gc, on a really
> large database.  That could block for a bit.
>
> So shepherd actions are probably fine for something like "herd status
> mcron" but for running slow and expensive operations,

Right.

> we need some way to expose the config file.

Could be.

> SO, the two ways to do that seem to be:
>  - Populate those configs in /etc/ (maybe providing prefix/suffix option
>    for multiple instances)... probably ok since we expect situations
>    that need these configs to be relatively rare.
>  - We could also have a shepherd action like "herd config mediagoblin"
>    that would merely spit out the configuration file path... so someone
>    could do something like:
>      $ foo-db dump-db --config `herd config foo-db`
>
> WDYT?

Adding a ‘config’ action where we see fit would certainly make sense,
yes.  I guess it’ll have to be decided on a case-by-case basis, and
perhaps we’ll see that this pattern makes sense for a whole class of
services.

Ludo’.



reply via email to

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