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

[Christopher Allan Webber]

Chris Marusich writes:

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

But they aren't orthogonal to whether or not it's a shepherd action, if
a shepherd action is expected to be nonblocking.

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

Those are definitely concerns (though hopefully people wouldn't be
modifying things in /etc since "guix system reconfigure" will splat over
any changes).

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

I agree that it seems a bit strange, but no solution really seems great.
However, I don't think it's totally outside the reasonable realm of
shepherd.  Shepherd actions are to execute some operation on a process
that's running (or which could run).  Returning the contextual
information of what config file is being used can fit that paradigm.
But it does feel a bit like a shoehorn.

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

And where would the configuration file be?  And who would define it,
when?  That's effectively what imperative distributions do, and the
application "knows" to look in /etc/, for some user-mutated file.