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

[Andrew Beekhof]

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.

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