On Wed, Jul 6, 2016 at 12:57 AM, Ken Gaillot <[email protected]> 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). _______________________________________________ Users mailing list: [email protected] http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
