[ClusterLabs] Pacemaker reload Master/Slave resource

[Felix Zachlod (Lists)]

> -----Ursprüngliche Nachricht-----
> Von: Ken Gaillot [mailto:kgaillot at redhat.com]
> Gesendet: Montag, 6. Juni 2016 23:31
> An: users at 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