Hi Minh,
It looks ok.
I think we should not keep it for long time and make everything
consistent as soon as possible.
Thanks,
Praveen
On 15-Dec-16 8:28 AM, Minh Hon Chau wrote:
> Attach documentation regarding the attr saAmfSISUHaState
>
> Attachments:
>
> * OpenSAF_AMF_PR_2134.odt
>
> <https://sourceforge.net/p/opensaf/tickets/_discuss/thread/104962dd/cf00/attachment/OpenSAF_AMF_PR_2134.odt>
> (130.6 kB; application/vnd.oasis.opendocument.text)
>
> ------------------------------------------------------------------------
>
> *[tickets:#2134] <https://sourceforge.net/p/opensaf/tickets/2134/> AMF:
> Update RTA saAmfSISUHAState to IMM*
>
> *Status:* wontfix
> *Milestone:* never
> *Created:* Thu Oct 20, 2016 07:58 PM UTC by Minh Hon Chau
> *Last Updated:* Tue Dec 13, 2016 06:49 AM 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 you indicated interest in
> https://sourceforge.net/p/opensaf/tickets/2134/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>
---
** [tickets:#2134] AMF: Update RTA saAmfSISUHAState to IMM**
**Status:** wontfix
**Milestone:** never
**Created:** Thu Oct 20, 2016 07:58 PM UTC by Minh Hon Chau
**Last Updated:** Thu Dec 15, 2016 02:58 AM 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.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
