bug#26830: Allow services to implement a 'reload' action

["Clément Lassieur" <clement@lassieur.org>]

Ludovic Courtès <ludo@gnu.org> writes:

> Heya,
>
> Clément Lassieur <clement@lassieur.org> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>> However, I think ‘reload’ might be confusing since in fact it doesn’t
>>> load Scheme code, contrary to what “herd load root foo.scm” does (maybe
>>> that’s what you meant?).  In fact it’s closer to what “herd restart
>>> foo” does.
>>>
>>> What about changing the name to ‘reconfigure’ or ‘upgrade’ to avoid the
>>> confusion?
>>
>> I think it's going to be even more confusing because the other init
>> systems (systemd, sysvinit) all call it 'reload'.  And, well, people are
>> probably more familiar with Systemd's 'reload' than with Shepherd's
>> 'reload root' :)  WDYT?
>
> I think it’s a valid argument!  However, if the choice is between
> internal consistency (on the use of the word “load” in Shepherd
> commands) and the rule of least surprise (choosing command names similar
> to those of other programs), I would favor internal consistency, I
> think.  WDYT?

Ok!  I like 'upgrade'.

>>> If the action took an argument, we could do:
>>>
>>>   herd reconfigure nginx /gnu/store/…-new-config.conf
>>>
>>> which would translate to:
>>>
>>>   nginx -s reload -c /gnu/store/…-new-config.conf
>>>
>>> Probably our best option.
>>
>> I don't see the point.  If the service has already been reloaded by the
>> 'guix system reconfigure' command (let's assume it does, but I know it
>> doesn't currently reload nor restart sevices...), why would a user want
>> to reload it again with the 'herd' command?  Or maybe you want this
>> feature as a workaround while the 'guix system reconfigure' that reloads
>> services isn't implemented?
>
> Sorry, I wasn’t clear.  Action can take arguments; most don’t, but some
> do (like ‘herd start cow-store /mnt’ when installing GuixSD.)  What I’m
> suggesting here is to add one/several arguments to this reload/upgrade
> action.  The meaning of these arguments would be defined by the service
> itself.
>
> For nginx, there could be one argument (the config file) or two (the
> config file and the nginx executable file name).  The reload/upgrade
> action would do “nginx -s reload -c …” and so on.
>
> The ‘upgrade-shepherd-services’ procedure would automatically call the
> reload/upgrade action with the right arguments.  For that, it needs to
> know what the arguments are.  An option would be to add an
> ‘upgrade-arguments’ field to <shepherd-service> that would return the
> arguments to pass to the upgrade action.
>
> Does that make sense?

Yes!  Thank you :)