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: Fri, 25 Nov 2016 01:27:43 -0600
User-agent: mu4e 0.9.16; emacs 25.1.1

Ludovic Courtès writes:

>> True.  Though we still run, potentially, into problems where multiple
>> instances of some service are provided, eg multiple mediagoblin servers
>> or mail daemons or etc.
>
> Sure, definitely.  All I meant was that populating /etc can be done as a
> quick stop-gap measure when it makes sense, but it’s not a great
> solution, notably because of the multiple-instance problem you describe.

Right.

>> Speaking of I/O from commands, I wonder how you'd give any kind of
>> output back through an action to the herd?  Afaict the protocol supports
>> it and allows sending back "messages" that will be displayed, but
>> nothing uses it yet.  There's a <command-reply> record type that afaict
>> nothing uses at all.
>
> <command-reply> is used for every reply sent by the daemon, in
> (shepherd).
>
> However, this hasn’t been thought to provide interactive commands and
> such things; I’m not sure it would be a great idea to support
> interactive commands, dunno.

Yeah, I didn't think a "feeding back input" option was likely to be
possible.  I understand why it isn't.

> 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, we need some way
to expose the config file.

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



reply via email to

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