- **status**: unassigned --> duplicate
- **Comment**:
Closing as duplicate of #2160
---
** [tickets:#2094] Standby controller goes for reboot on stopping openSaf with
STONITH enabled cluster**
**Status:** duplicate
**Milestone:** 5.2.RC1
**Created:** Wed Oct 05, 2016 07:28 AM UTC by Chani
I suggest to close this ticket as a duplicate of ticket #2160
---
** [tickets:#2094] Standby controller goes for reboot on stopping openSaf with
STONITH enabled cluster**
**Status:** unassigned
**Milestone:** 5.2.RC1
**Created:** Wed Oct 05, 2016 07:28 AM UTC by Chani Srivastava
**Last
Agree, "Suggestion: 1" document that admin needs to perform clm admin lock of
standby is a good suggestion. The node will then not be a member of the cluster
and not affected by remote fencing
---
** [tickets:#2094] Standby controller goes for reboot on stopping openSaf with
STONITH enabled
in a) doing /etc/init.d/opensafd stop doesn't reboot the node, but stops
opensaf on that node and saClmNodeIsMember is set to false. The active
controller will then not perform remote fencing of that node.
in b) "graceful" reboot after opensafd stop, should work fine without any
involvemnet of
There are two scenarios where "opensafd stop" is invoked on any opensaf
controller.
SCENARIO-1) Where /etc/init.d/opensafd script is invoked manually on command
prompt when the system is running and up.
SCENARIO-2) Software on a controller ( other than opensafd) invoked "reboot"
for which
Ticket [#2160] will add support to differentiate between a hung versus a
stopped node, no additional documentation will be needed.
---
** [tickets:#2094] Standby controller goes for reboot on stopping openSaf with
STONITH enabled cluster**
**Status:** unassigned
**Milestone:** 5.2.FC
Can you provide the documentation on how to stop opensaf in a controlled manner
so that I can close the ticket.
---
** [tickets:#2094] Standby controller goes for reboot on stopping openSaf with
STONITH enabled cluster**
**Status:** unassigned
**Milestone:** 5.2.FC
**Created:** Wed Oct 05,
Split brain may only happen between the system controllers.
---
** [tickets:#2094] Standby controller goes for reboot on stopping openSaf with
STONITH enabled cluster**
**Status:** unassigned
**Milestone:** 5.2.FC
**Created:** Wed Oct 05, 2016 07:28 AM UTC by Chani Srivastava
**Last
Is Stonith applicable only for controllers? As no reboot observed while
stopping opensaf on Payload.
---
** [tickets:#2094] Standby controller goes for reboot on stopping openSaf with
STONITH enabled cluster**
**Status:** unassigned
**Milestone:** 5.2.FC
**Created:** Wed Oct 05, 2016 07:28
I think the procedure for stopping OpenSAF in a controlled way is to first lock
the node using CLM. The CLM lock admin operation will remove the node from
cluster membership. The it should be safe to stop OpenSAF on that node without
getting fenced - i.e. we should not fence a node that we lost
This seems to be a case of differentiating a hung node versus a node on which
the middleware is stopped.
Is there any standard means to detect a "hung" node?
IF there is such a mechanism to detect a hung node, then
Upon receiving "NODE_DOWN" i.e. below event
"Oct 5 13:01:24 SC-1
This is the same behaviour as running without stontih or PLM. Without stonith
opensaf tries to reboot the standby controller at opensafd stop, but needs
either PLM or stonith to succeed. Perhaps it is needed to stop opensaf and not
trigger remote fencing? Is this an upgrade case? Perhaps we
12 matches
Mail list logo
