Feri, I have a follow-up question: We are trying to achieve an NDU for our Master/Slave resource - this is why the resource parameter is being updated. The desired sequence of events is as follows: Resource parameter is updated in pacemaker. Slave instance is reloaded (or restarted) to pickup the new parameter. This may take several minutes with out resource. Once Slave is back online, Master is demoted and Slave is promoted. Former master is reloaded (or restarted) to pickup the new parameter. This seems to me as a fairly standard sequence for updating any Master/Slave resource - restarting both instances at the same time is never a good thing. I can't come up with a way to create such a sequence. The best I can come up with is to implement a reload action in our resource agent, which for the slave instance would restart it immediately, and for the master instance would wait a fixed time (3 min) to give Slave time to reload, and then return OCF_ERR_GENERIC to force a failover. This kind of works, but is quite hacky - there is no guarantee that the Slave will be done reloading in 3 min, and we also returning error intentionally. I thought of using notify action, but there is no notify about the reload action, so it does not work. Any other suggestions? Thanks a lot Ilia
> On Jun 10, 2016, at 3:13 AM, Ferenc Wágner <wf...@niif.hu> wrote: > > Ilia Sokolinski <i...@clearskydata.com> writes: > >> We have a custom Master-Slave resource running on a 3-node pcs cluster on >> CentOS 7.1 >> >> As part of what is supposed to be an NDU we do update some properties of the >> resource. >> For some reason this causes both Master and Slave instances of the resource >> to be restarted. >> >> Since restart takes a fairly long time for us, the update becomes very much >> disruptive. >> >> Is this expected? > > Yes, if you changed a parameter declared with unique="1" in your resource > agent metadata. > >> We have not seen this behavior with the previous release of pacemaker. > > I'm surprised... > -- > Feri
_______________________________________________ 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
