On Fri, Jul 15, 2016 at 2:33 AM, Ken Gaillot <kgail...@redhat.com> wrote: > On 07/13/2016 11:20 PM, Andrew Beekhof wrote: >> On Wed, Jul 6, 2016 at 12:57 AM, Ken Gaillot <kgail...@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). _______________________________________________ Users mailing list: Users@clusterlabs.org 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