Hi Minh,
si_rt_attr_cb() is invoked in AMFD context. So I think, this function can take
into account fsm state to count only AVD_SU_SI_STATE_ASGND for updating
saAmfSINumCurrActiveAssignments and saAmfSINumCurrStandbyAssignments.
For quiescing state, when AMFND gets Response() from component for quiescing
state (before quiescing complelte), AMFND can send a data update message to
AMFD. Based on this data update, AMFD can update IMM for quiescing state. After
quiescing complete AMFD gets response from AMFND for assignment, now AMFD can
update IMM for queisced state.
Although saAmfSIAssignmentState is a runtime attribut, it is coupled with
configurable attributes saAmfSIPrefActive/StandbyAssignments. So I think this
attribute only reflects whether a SI is assigned in full capacilty or not. This
attribute does not indicate if some assignment is happening or not because in
N-Way and N-Way active model, a SI can go to many SUs, so its
saAmfSIAssignmentState may remain in PARTIALLY_ASSIGNED state for a long time.
I think root cause of most issues is AMFD unecesary plays with "Curr" types of
attributes by incrementing and decrementing them for SU and SI. For these
attributes in SI and SU, all calcurations should be done dynamically inside the
callbacks su_rt_attr_cb() and si_rt_attr_cb(). If this gets fixed I think what
remians is updation of HA state in SUSI/COMPCSI. updation of
saAmfSIAssignmentState in SI and notifications. Can we evalate to get rid of
updating "Curr" attributes and work without them. In some red models these
"Curr" attributes are used in assignment algorithm.Those can be replaced with
their function equivalent like su->get_saAmfSUNumCurrActiveSIs(). These same
functions can be called from callbacks also and these functions can take into
acount fsm states, list_of_sisu etc.
Will this help and make things consistent? We will have to evaluate this.
But that will more like an enhancmement and #1354 can be made an ehnacment to
bring such consistency.
Can we fix #2134 and #2133 in the existing way and document, if required, in PR?
Thanks,
Praveen
---
** [tickets:#2134] AMF: Update RTA saAmfSISUHAState to IMM**
**Status:** unassigned
**Milestone:** 5.2.FC
**Created:** Thu Oct 20, 2016 07:58 PM UTC by Minh Hon Chau
**Last Updated:** Mon Oct 24, 2016 01:23 PM UTC
**Owner:** nobody
In scenario of 2N Si-swap, when AMFD sends QUIESCED su_si assignment msg (for
example) to AMFND that changes the HA State of SUSI assignment, AMFD updates
its local state AVD_SU_SI_REL::state, checkpoint this change to standby AMFD.
However, AMFD does not updates saAmfSISUHAState untill receiving su_si
assignment response. Question:
(1). Whether AMFD should update the runtime attribute saAmfSISUHAState to IMM
as long as local @state gets updated in implementer; to make IMM, active AMFD,
standby AMFD all are synced
(2). Or AMFD updates saAmfSISUHAState to IMM only if AMFD receives su_si
assignment from AMFND, as it has been implemented currently for some reason
(not expose the change of saAmfSISUHAState to user too early?)
grep "avd_susi_update" which updates saAmfSISUHAState to IMM, there is also an
inconsistency in usage. For avd_susi_mod_send() sends su_si msg and also
updates saAmfSISUHAState immediately, while avd_sg_su_si_mod_snd does
otherwise.
Since the headless recovery relies on IMM to restore the state. If
saAmfSISUHAState is not updated punctually and the node is reboot during
headless stage, so after headless saAmfSISUHAState read from IMM does not fit
with many other states (SG fsm, SUSI fsm, saAmfSISUHAState of the other SUSIs).
My question is if doing (1) will cause any problem for normal cluster? Pending
patches #1725 part 2 currently implement (1).
---
Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net 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.
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
