[ClusterLabs] Antw: Re: Antw: Doing reload right

[Ken Gaillot]

On 07/13/2016 11:20 PM, Andrew Beekhof wrote:
> On Wed, Jul 6, 2016 at 12:57 AM, Ken Gaillot <kgaillot at redhat.com> wrote:
>> On 07/04/2016 02:01 AM, Ulrich Windl wrote:
>>> For the case of changing the contents of an external configuration file, the
>>> RA would have to provide some reloadable dummy parameter then (maybe like
>>> "config_generation=2").
>>
>> That is a widely recommended approach for the current "reload"
>> implementation, but I don't think it's desirable. It still does not
>> distinguish changes in the Pacemaker resource configuration from changes
>> in the service configuration.
>>
>> For example, of an RA has one parameter that is agent-reloadable and
>> another that is service-reloadable, and it gets a "reload" action, it
>> has no way of knowing which of the two (or both) changed. It would have
>> to always reload all agent-reloadable parameters, and trigger a service
>> reload. That seems inefficient to me. Also, only Pacemaker should
>> trigger agent reloads, and only the user should trigger service reloads,
>> so combining them doesn't make sense to me.
> 
> Totally disagree :-)
> 
> The whole reason service reloads exist is that they are more efficient
> than a stop/start cycle.
> 
> So I'm not seeing how calling one, on the rare occasion that the
> parameters change and allow a reload, when it wasn't necessary can be
> classed as inefficient.   On the contrary, trying to avoid it seems
> like over-optimizing when we should be aiming for correctness - ie.
> reloading the whole thing.

I just don't see any logical connection between modifying a service's
Pacemaker configuration and modifying its service configuration file.

Is the idea that people will tend to change them together? I'd expect
that in most environments, the Pacemaker configuration (e.g. where the
apache config file is) will remain much more stable than the service
configuration (e.g. adding/modifying websites).

Service reloads can sometimes be expensive (e.g. a complex/busy postfix
or apache installation) even if they are less expensive than a full restart.

> The most in-efficient part in all this is the current practice of
> updating a dummy attribute to trigger a reload after changing the
> application config file.  That we can address by supporting
> --force-reload for crm_resource like we do for start/stop/monitor (and
> exposing it nicely in pcs).