[Pacemaker] ignoring transitional memberships

[Alan Jones]

On Fri, Feb 26, 2010 at 2:57 AM, Andrew Beekhof <andrew at beekhof.net> wrote:

> Not only safe but essential, otherwise B would kill A for no reason.
> Transitional memberships are just corosync's way of saying "i;m still
> working, but this is what I have so far".
>
The best explanation I've found for the transitional membership is in:
"Group Communication Specifications: A Comprehensive Study" 1999
Vitenberg/Chockler/Keidar/Dolev
It relates to support for positionable memberships.  In Pacemaker it
might be the case that for B to
become DC and modify the CIB without A, B would have to STONITH A.  If
that is the case, then when
A gets a new membership including B he can assume that B has not
modified the CIB without him.
However, I'm not convinced that he can assume that B has received all
the same messages during
the transition.  If Pacemaker clobbers B's CIB after a new membership
then it doesn't matter.


> > How is the CIB replicated?
> Thats not related to the above question is it?
>
> It is.  I'm trying to understand when and how copies of the CIB are
synchronized.  To that end
I've created a simplified graph of crmd's finite state automata using
graphviz which others might
find useful (attached).  I'll try to break this question up:
1. When the CIB is updated, are the none DC copies updated by coping the
entire CIB or with a message that represents only the change?
2. Is the update sent to each copy separately or using corosync's multicast?
3. When a new DC is elected, what steps are taken to assure that it's copy
of the CIB is up-to-date?
For example, a new member that has not finished incorporating the CIB should
not be eligible for the role of DC; how is this accomplished.

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20100226/96d0b313/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fsanoterm.dot
Type: application/octet-stream
Size: 3923 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20100226/96d0b313/attachment-0001.obj>