On Tue, 2017-10-31 at 09:33 +0100, Ferenc Wágner wrote: > Ken Gaillot <kgail...@redhat.com> writes: > > > On Fri, 2017-10-20 at 15:52 +0200, Ferenc Wágner wrote: > > > > > Ken Gaillot <kgail...@redhat.com> writes: > > > > > > > On Fri, 2017-09-22 at 18:30 +0200, Ferenc Wágner wrote: > > > > > > > > > Ken Gaillot <kgail...@redhat.com> writes: > > > > > > > > > > > Hmm, stop+reload is definitely a bug. Can you attach (or > > > > > > email it > > > > > > to me privately, or file a bz with it attached) the above > > > > > > pe-input > > > > > > file with any sensitive info removed? > > > > > > > > > > I sent you the pe-input file privately. It indeed shows the > > > > > issue: > > > > > > > > > > $ /usr/sbin/crm_simulate -x pe-input-1033.bz2 -RS > > > > > [...] > > > > > Executing cluster transition: > > > > > * Resource action: vm-alder stop on vhbl05 > > > > > * Resource action: vm-alder reload on vhbl05 > > > > > [...] > > > > > > > > > > Hope you can easily get to the bottom of this. > > > > > > > > This turned out to have the same underlying cause as CLBZ#5309. > > > > I > > > > have a fix pending review, which I expect to make it into the > > > > soon-to-be-released 1.1.18. > > > > > > Great! > > > > > > > It is a regression introduced in 1.1.15 by commit 2558d76f. The > > > > logic for reloads was consolidated in one place, but that > > > > happened > > > > to be before restarts were scheduled, so it no longer had the > > > > right > > > > information about whether a restart was needed. Now, it sets an > > > > ordering flag that is used later to cancel the reload if the > > > > restart > > > > becomes required. I've also added a regression test for it. > > > > > > Restarts shouldn't even enter the picture here, so I don't get > > > your > > > explanation. But I also don't know the code, so that doesn't > > > mean a > > > thing. I'll test the next RC to be sure. > > > > :-) > > > > Reloads are done in place of restarts, when circumstances allow. So > > reloads are always related to (potential) restarts. > > > > The problem arose because not all of the relevant circumstances are > > known at the time the reload action is created. We may figure out > > later > > that a resource the reloading resource depends on must be > > restarted, > > therefore the reloading resource must be fully restarted instead of > > reloaded. E.g. a database resource might otherwise be able to > > reload, > > but not if the filesystem it's using is going away. > > > > Previously in those cases, we would end up scheduling both the > > reload > > and the restart. Now, we schedule only the restart. > > Hi Ken, > > 1.1.18-rc3 indeed schedules a restart, not a reload, like 1.1.16 did. > However, this wasn't my problem, I really expect a reload on the > change > of a non-unique parameter. Them problem was that 1.1.16 also > executed a > stop action in parallel with the reload. > > Maybe I test it wrong: I just copied the pe-input file to another > system > (which doesn't even know this resource agent) running 1.1.18-rc3 and > gave it to crm_simulate. Does the pe-input file contain all the > information necessary to decide between restart and reload? The > op-force-restart attribute does not contain the name of the changed > parameter, but I can't find any info on what changed at all. Should > I > see a clean reload in this test setup at all?
The pe-input is indeed entirely sufficient. I forgot to check why the reload was not possible in this case. It turns out it is this: trace: check_action_definition: Resource vm-alder doesn't know how to reload Does the resource agent implement the "reload" action and advertise it in the <actions> section of its metadata? -- Ken Gaillot <kgail...@redhat.com> _______________________________________________ Users mailing list: Users@clusterlabs.org http://lists.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