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

[Chris Marusich]

Christopher Allan Webber <address@hidden> writes:

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

I agree that's true.  I admittedly don't know a lot about Shepherd
(yet!), but I would think that as long as invoking "herd dump-db
my-database" doesn't block Shepherd from performing its duties, the
duration of that invocation shouldn't matter.

However, since Ludo' explicitly said that "actions are expected to be
non-blocking," I think we should probably keep the actions non-blocking.

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

In my experience, people often meddle with the system config files
because it is often the path of least resistance for ad-hoc changes.  If
you put a scary warning in there like "YOUR CHANGES WILL BE OVERRIDDEN"
then maybe they're less likely to do it, but a mechanism to enforce that
(e.g., by storing the config file in the immutable store) is better.

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

After thinking about it a little more, I'm not so sure I agree with what
I originally said.  At this point, I'm inclined to agree with Ludo', who
said we should decide what to do for each service on a case-by-case
basis.  So, if adding an action makes more sense to you here, then let's
do that.  We can see if a pattern emerges over time for other services.

-- 
Chris

signature.asc
Description: PGP signature