- **status**: accepted --> review
---
** [tickets:#1861] amfnd: reboot immediately if local amfd process terminates**
**Status:** review
**Milestone:** 4.7.2
**Created:** Fri Jun 03, 2016 01:03 AM UTC by Gary Lee
**Last Updated:** Fri Jun 03, 2016 01:03 AM UTC
**Owner:** Gary Lee
If headless
---
** [tickets:#1861] amfnd: reboot immediately if local amfd process terminates**
**Status:** accepted
**Milestone:** 4.7.2
**Created:** Fri Jun 03, 2016 01:03 AM UTC by Gary Lee
**Last Updated:** Fri Jun 03, 2016 01:03 AM UTC
**Owner:** Gary Lee
If headless mode is enabled and local amfd
- **Milestone**: future --> 5.1.FC
---
** [tickets:#1574] CKPT: Support DNs longer than 255 bytes**
**Status:** review
**Milestone:** 5.1.FC
**Created:** Wed Oct 28, 2015 09:46 AM UTC by Pham Hoang Nhat
**Last Updated:** Mon Mar 28, 2016 06:26 AM UTC
**Owner:** Pham Hoang Nhat
Ticket [#191]
- Description has changed:
Diff:
--- old
+++ new
@@ -14,3 +14,5 @@
When FM detects its peer is not available, both active and standby, in an
virtualized environment the active FM system controller will use STONITH to
power fence the FM standby system controller, (not power reset). The FM
- Attachments has changed:
Diff:
--- old
+++ new
@@ -1 +1,2 @@
1845.tgz (10.6 MB; application/x-compressed-tar)
+ticket1845.diff (1.1 kB; text/x-patch)
- **Component**: nid --> clm
- **Comment**:
Hi Srikanth. Could you re-run the test with a new build where you have applied
the at
the division and priority looks fine. Good to start with the stonith fencing,
should be a smaller task and also reduce pressure to solving split-brain cases.
Introducing Raft for AMF could also remove the director node director division
and the messaging to maintain their state machines, this sh
This (come up with a plan to split down these changes into smaller milestones
probably spread across 5.1 and 5.2) is an important agenda for the upcoming TLC
meeting during the week of 20 - 23rd.
Basically to define an order (of implementation) of the following changes
- this ticket
- introduce
Yes, fencing as a clustering functionality is a part of the raft changes(needs
to be done in a phased manner tlil which point stonith integration could be
done with FM).
True, raft is being seen as a candidate for replacing MBCsv (perhaps IMM FEVS
too, if necessary).
But using raft for MBCSv (i
Implementing support for fencing is likely needed also when using Raft and
adding support for fencing should also be a smaller task, doable in the 5.1
release.
If fencing support is implemented the identified split-brain cases will be
handled.
One use case for Raft can also be to reduce complex
I can not pre-produce the issue with above step in current OpenSAF code.
Could you please help produce this issue? and show the osaflogd in SC2 node?
Thanks.
---
** [tickets:#865] LOG: standby controller went for reboot after s/w followed by
immnd kill**
**Status:** assigned
**Milestone:** 4
- **status**: unassigned --> assigned
- **assigned_to**: Canh Truong
---
** [tickets:#865] LOG: standby controller went for reboot after s/w followed by
immnd kill**
**Status:** assigned
**Milestone:** 4.7.2
**Created:** Mon Apr 21, 2014 10:51 AM UTC by surender khetavath
**Last Updated:** We
- **summary**: fm: Split-brain avoidance in OpenSAF using fencing --> fm: Add
support for STONITH fencing
- **Milestone**: 4.7.2 --> 5.1.FC
- **Comment**:
As per the description of the ticket, the idea is to use STONITH for fencing.
Just as a note - there are multiple other tickets around the to
12 matches
Mail list logo