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: Sat, 26 Nov 2016 04:40:20 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Christopher Allan Webber <address@hidden> writes:

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

The speed and cost of an operation are orthogonal to whether or not that
operation requires access to a 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.

Putting stuff into /etc seems undesirable because (1) putting things
outside the immutable store seems like an invitation to meddle with the
files, and (2) the possibility of file name conflicts exists, which you
are already aware of.  However, this might be the simplest solution, so
if nothing else seems better, I think it would be reasonable to do.

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

This seems less desirable than putting things into /etc because it
doesn't seem to be in line with the intended use of Shepherd.  My
understanding is that Shepherd's job is to nanny the system's processes.
Responding to queries about the location of the services' config files
doesn't seem germane to that job.

As I see it, there is another possible solution: Modify the
service/daemon/tool so that it is no longer necessary to expose the
config file location in the first place.  I'm still not sure which
daemon/service we're talking about here, but surely the daemon/service
knows where its configuration file is when it starts up.  Surely it
could be made to remember that, if it doesn't already.  Surely a tool
could be made which queries the service/daemon for that information if
necessary.  Surely the service/daemon could be made to perform
operations like a database dump without being told where its own
configuration file is.

If it's easier to modify the service/daemon/tool so that we don't have
to explicitly provide a config file, maybe we should do that instead of
trying to modify Shepherd.

-- 
Chris

Attachment: signature.asc
Description: PGP signature


reply via email to

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