Hi Praveen,
Just had a closer look at the idea of "AMFD self triggers susi_success".
Basically, two ways to do self triggering:
(1). AMFD needs to know the FSM state of SUSI before and after headless. If
there's a difference, then AMFD can knows that all CSIs complete during
headless, and AMFD can call susi_success() on the SU which has SUSI changed
between before and after headless.
To Achive this:
- AMFD needs to store FSM state of SUSI to IMM
- AMFD deduces the SUSI FSM state from extra field (assignment state) to be
added in state_info, this work has been introduced in comment ( 2016-04-27 ) in
this ticket.
- AMFD compares the change of SUSI FSM to trigger susi_success()
(2). AMFD explores its SUSI received from state_info and deduce the SU which
will be called on self triggering of susi_success()
To Achive this:
- AMFD deduces the SUSI FSM state from extra field (assignment state) in
state_info.
- AMFD if sees all SUSI FSM are in ASSIGNED but there's QUIESCED/QUIESCING
SUSI, next AMFD needs to deduce the SU which is called in susi_success().
For example in si-swap:
. If SU4 is QUIESCED, SU5 is STANDBY, SU4 should be called in susi_success() to
move SU5 to ACTIVE
. If SU4 is QUIESCED, SU5 is ACTIVE, then SU5 should be called in
susi_success() to move SU4 to STANDBY.
A completed deduction like above example would be more complicated in different
SG and with relevant AdminStates.
Back to (1), there's also a chance that AMFD sets SUSI as ASSIGNED, sends next
su_si event to continue the assignment sequence, but this su_si event hasn't
come to AMFND due to headless interruption (similiar as your raising point in
previous comment). This exceptional case of (1) would be solved in the way of
(2) after headless.
Do you think I should continue (2) to achive "AMFD self trigger susi_sucess()
if all CSIs complete during headless"? Any ideas?
Thanks,
Minh
---
** [tickets:#1725] AMF: Recover transient SUSIs left over from headless**
**Status:** review
**Milestone:** 5.1.FC
**Created:** Wed Apr 06, 2016 07:16 AM UTC by Minh Hon Chau
**Last Updated:** Sat Aug 13, 2016 10:18 AM UTC
**Owner:** Minh Hon Chau
This ticket is more likely an enhancement that targets on how AMFD detect and
recover the transients SUSI left over from headless. There are three major
situations:
(1) - Cluster goes headless, su/node failover on any payloads can happen, or
any payloads can be hard rebooted/powered off by operator, then cluster recover
(2) - issue admin op on any AMF entities, cluster goes headless. During
headless, the middle HA assignments of whole admin op sequence between AMFND
and components could be:
(2.1) The assignment completes, component returns OK with csi callback,
then cluster recover
(2.2) The assignment is under going, then cluster recover. The assignment
afterward could complete, or csi callback returns FAILED_OPERATION or error can
also happen
At the time cluster recover, amfd has collected all assignments from all
amfnd(s). These assignments can be in assigned or assigning states whilst its
HA states do not conform its SG redundancy. Any of (1) (2.1) (2.2) can happen
in a combination, which means while issuing admin op (2), cluster go headless
and any kinds of failover (1) can happen during headless.
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
