[ClusterLabs] Antw: Re: Antw: Doing reload right
abeekhof at redhat.com
Thu Jul 14 00:20:40 EDT 2016
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
> 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).
More information about the Users