> -----Ursprüngliche Nachricht----- > Von: Ken Gaillot [mailto:kgail...@redhat.com] > Gesendet: Montag, 6. Juni 2016 23:31 > An: users@clusterlabs.org > Betreff: Re: [ClusterLabs] Pacemaker reload Master/Slave resource > > I think it depends on your point of view :) > > Reload is implemented as an alternative to stop-then-start. For m/s > clones, start leaves the resource in slave state.
I actually thought should reconfigure the resource WITHOUT restarting it and in my opinion this should be agnostic to the slave/master state of the resource. Just pass the new parameters so that it is reconfigured. But ACTUALLY this works just fine. The weird behavior I observed and described here was caused by my resource setting the master scores wrongly, or better to say always the same way (no matter if running slave or master). I did understand master score as a score that just helps the cluster manager to decide WHERE to run the resource so I did not see why it necessarily has to have different scores for different states. But obviously it does a bit more. After adjusting the master scores in a way that gives the current master a higher preference the problem went away. I can now reload my resource no matter if it is slave or master and it will NEITHER stop/start nor demote/stop/start/promote but just call reload() whatever this actually does internally - just as I imagined and what is just the most meaningful way I think. Reload returns with rc 0 and the cluster manager is happily assuming the resource still master (if it had been before). regards, Felix _______________________________________________ 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
