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

[Andrew Beekhof]

On Fri, Jul 15, 2016 at 2:33 AM, Ken Gaillot <kgaillot at redhat.com> wrote:
> 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.

There isn't one beyond they are both bypassing a stop/start cycle.

>
> Is the idea that people will tend to change them together?

No, the idea is that the "penalty" of making sure both are up-to-date,
in the rare event that either one is changed, does not justify
splitting them up.

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

Right. But you just said that the pacemaker config is much less likely
(out of a thing thats already not very likely) to change. So why are
you optimizing for that scenario?

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