[Linux-HA] stickiness for master in master/slave resource?

[Andrew Beekhof]

On 7/12/07, Andreas Kurz <andreas.kurz at gmail.com> wrote:
> On 7/12/07, Andrew Beekhof <beekhof at gmail.com> wrote:
> > On 7/12/07, Andrew Beekhof <beekhof at gmail.com> wrote:
> > > On 7/12/07, Andreas Kurz <andreas.kurz at gmail.com> wrote:
> > > > On 7/12/07, Andrew Beekhof <beekhof at gmail.com> wrote:
> > > > > On 7/12/07, Andreas Kurz <andreas.kurz at gmail.com> wrote:
> > > > > > Hello all,
> > > > > >
> > > > > > I am using hearbeat 2.1.0 on CentOS 4.5 and drbd 8.0.3. I know drbd8
> > > > > > is currently not supported but I give it a try ;-).
> > > > > >
> > > > > > I adopted the drbd ocf RA and configured a master/slave resource with
> > > > > > resource_stickiness INFINITY and a location constraint to define the
> > > > > > prefered master. I killed heartbeat on the drbd master and the second
> > > > > > node does the failover as expected .... but .... when the stonithed
> > > > > > node comes up again the drbd master resource stays on the second node
> > > > > > as expected, but in a first attempt to negotiate who is the master for
> > > > > > the drbd resource heartbeat demotes the drbd resource, including a
> > > > > > stop of the drbd resource. Then the second nodes gets promoted again
> > > > > > and the drbd starts up again on the second node.
> > > > > >
> > > > > > Is this a known behaviour, or is there something wrong with my
> > > > > > configuration or is this a drbd8 problem?
> > > > >
> > > > > can you please attach the files
> > > > >    /var/lib/heartbeat/pengine/pe-warn-72.bz2
> > > > >    /var/lib/heartbeat/pengine/pe-warn-73.bz2
> > > > > from smsdb06?
> > > >
> > > > of course, thanks for your help!
> > >
> > > ouch - we're not behaving properly here at all.
> > > i'll get back to when its fixed.
> >
> > Not "fixed", but I can offer a simple work-around
> >
> > Change:
> >            <nvpair id="remove-after-stop" name="remove-after-stop"
> > value="true"/>
> > to
> >            <nvpair id="remove-after-stop" name="remove-after-stop"
> > value="false"/>
> >
> > That particular option is not well tested, I'd not advise turning it on.
> > Was there any particular reason you had it on?
>
> When reading the description of this option I found it a good idea to
> use it, but I think I can live without it. I will test this
> work-around.

and the fix is here:
   http://hg.linux-ha.org/dev/rev/6a7f891e099c