[OCF] Re: question about membership in Event Notification API

[Ram]

On Wed, 2005-03-09 at 12:36, Guochun Shi wrote:
> Ram, thanks for quick reply
> 
> At 11:44 AM 3/9/2005 -0800, you wrote:
> >On Wed, 2005-03-09 at 09:42, Guochun Shi wrote:
> >> Hi, list,
> >> 
> >> I am maintaining Cluster Membership Consensus (CCM)  which was written by Ram Pai. I have a few quesions about membership events.
> >> 
> >> In [OCF]Event Notification API Proposal (draft 3) 
> >> 
> >> "
> >>      typedef enum {
> >>                 OC_EV_MS_INVALID =3D OC_EV_SET_CLASS(OC_EV_MEMB_CLASS, 0),
> >>                 OC_EV_MS_NEW_MEMBERSHIP,
> >>                 OC_EV_MS_NOT_PRIMARY,
> >>                 OC_EV_MS_PRIMARY_RESTORED,
> >>                 OC_EV_MS_EVICTED
> >>         } oc_memb_event_t;
> >> 
> >> 
> >>         Membership Events:
> >>         -----------------
> >> 
> >>         OC_EV_MS_NEW_MEMBERSHIP is delivered to nodes in the primary
> >>         sub-cluster (active node membership) when a membership change
> >>         occurs.
> >> 
> >>         OC_EV_MS_NOT_PRIMARY is delivered to nodes when membership
> >>         agreement is no longer possible and this node can not
> >>         accurately determine if it is part of the primary sub-cluster
> >>         (active node membership).  For example, this event might be
> >>         delivered in a HiAv cluster to nodes that have lost quorum.
> >> 
> >>         OC_EV_MS_PRIMARY_RESTORED is delivered when connectivity is
> >>         restored after a transient outage and membership returns to the
> >>         exact same state as it was before the OC_EV_NOT_PRIMARY event.
> >> 
> >>         OC_EV_MS_EVICTED is delivered when connectivity is restored and
> >>         a new primary sub-cluster (active node membership) has been
> >>         accepted elsewhere in the cluster which no longer includes the
> >>         local node.  If delivered, this will be the last event delivered
> >>         to the called function, and membership notification service
> >>         terminates.
> >> 
> >>         Applications are not expected to gracefully recover from this
> >>         event.  Usually, there is too much invalid or stale state
> >>         that must be flushed.
> >> 
> >>         An implementation may choose to handle eviction in its own
> >>         way, and NOT deliver this event.  Most implementations will
> >>         reboot or be killed by their peers.  Delivery of this event
> >>          is optional for  implementations that handle eviction by
> >>         alternate means, such as STONITH...
> >>         NOTE: no attempt has been made to allow re-connection of
> >>         an evicted member node.
> >> 
> >> 
> >> "
> >>  Since I see some difference in CCM implementation and the draft description, I want to make sure I understand it correctly.
> >> 
> >> 1. In CCM,  a membership without quorum is delivered as OC_EV_MS_INVALID but interpreted in client side as "NO QUORUM MEMBERSHIP"
> >> event. According the draft, it should be OC_EV_MS_NOT_PRIMARY event.
> >
> >brushing my rather old memory: there is a difference between
> >OC_EV_MS_INVALID and OC_EV_MS_NOT_PRIMARY
> >
> >OC_EV_MS_INVALID: means I am exactly sure that I am not part of any
> >membership.
> 
> In CCM, OC_EV_MS_INVALID is overloaded as no-quorum memberhip, if the special flag is set to true.

If I recall correctly, yes it is overloaded from CCM implementation
point of view. Not from the spec point of view. I had to overload it in
CCM, because I did not have a good way in the spec to get that
information.  I dont' say the spec is
perfect. There are many things it does not have which has to be thought
through.

> 
All the other stuff is involved without recalling the exact details  I
dont want to add more confusion. Will get back on this
after recalling the details.


RP