[Pacemaker] prevent the resource's start if it has "stop NG" history on the other node

[Andrew Beekhof]

On Mon, Mar 12, 2012 at 4:31 PM, Junko IKEDA <tsukishima.ha at gmail.com> wrote:
> Hi,
>
> I tried the latest code and the following commit worked well for our case, too.
> It means "unmanaged, stop failed resource" prevents Pacemaker's
> shutdown, great :)
> https://github.com/ClusterLabs/pacemaker/commit/8d2f237dc5f900381adf62a6e949ec71d1ee54e5
>
> but, I got the other case, it's "Master/Slave" configuration.
>
> 1) initial status;
> node-a = Master
> node-b = Slave
>
> 2) node-a -> shutdown Pacemaker
> 3) node-a -> failed to stop Master while the shutdown process
>
> 4) final status;
> node-a = unmanaged "Slave"
> node-b = Master
>
> In this case, "demote" operation goes well, so it makes sense to
> promote node-b as Master.

Is it though?  In the general case.
With one instance mis-behaving, in an unknown state and potentially
doing anything, I would not have thought this would be a good time to
promote another instance.

In any case, the 'block' applies to the whole resource, not just the
failed instance.

Even if I wanted to, I don't think we could change the behaviour in this case.
All instances that need to be demoted or stopped must be, before any
other instances can be started or promoted.
Bypassing that premise would probably cause the implementation to fall
apart :-)

> I think drbd RA can handle this situation,
> but pgsql RA (replication mode) will go into the unexpected dual master...
> this can be related to the following issue.
> http://www.gossamer-threads.com/lists/linuxha/pacemaker/78644
> I'll ask pgsql people this again for now.
>
> Many thanks,
> Junko
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org