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] AMF:
Hi Minh,
I think we cannot use "not supported". Instead we should use the word not
recommended. Suppose SG is in transition state because of assignments going on,
if a user makes some query at this time then user will surely get some value of
attribute but this value will be changing with each
Hi Praveen,
Although part 2 #1725 is pushed, there is a chance that both
avd_sg_su_si_mod_snd() and avd_susi_mod_send() are updating this attribute
differently. To avoid backward incompatibility in future, I would like to
document that reading saAmfSISUState while assignment is ongoing not
- **Milestone**: 5.2.FC --> never
---
** [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 Nov 10, 2016 06:48 AM UTC
**Owner:** nobody
In scenario of 2N
- **status**: unassigned --> wontfix
---
** [tickets:#2134] AMF: Update RTA saAmfSISUHAState to IMM**
**Status:** wontfix
**Milestone:** 5.2.FC
**Created:** Thu Oct 20, 2016 07:58 PM UTC by Minh Hon Chau
**Last Updated:** Thu Nov 10, 2016 06:47 AM UTC
**Owner:** nobody
In scenario of 2N
Hi Praveen,
I have updated #2133, #1354. Since part 2 of #1725 has been pushed, so I close
this ticket.
There is a very small probability that application may still require this
attribute updated after assignment sequence as before, this drops into the case
of avd_sg_su_si_mod_snd() . But
Hi MInh,
Any update on this.
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:** Wed Nov 09, 2016 06:52 AM UTC
**Owner:** nobody
In
Hi Minh,
What I get is : With part 2 of #1725, updation to IMM becomes consistent in the
existing manner. If this is the case, I agree to close this ticket. In that
case please update #1354 and #2133 with this ticket link so that discussion can
be recolleted in future.
Thanks,
Praveen
---
Hi Praveen,
Agree that if the *Curr* related attributes consider fsm state in rt_attr_cb(),
then it would be suitable for reflecting the current status of assignment,
which is required by user of #1354
The part 2 of #1725 has been pushed, that contains a change to update
saAmfSISUHaState to
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
Hi Praveen,
As I see the code inside si_rt_attr_cb() updates
saAmfSINumCurrActiveAssignments and saAmfSINumCurrStandbyAssignments to IMM
without any check of fsm state, or maybe I am wrong?
If we do update new saAmfHAState after AMFD receives assignment response from
AMFND, in case of
Hi Minh,
Ticket #1870 was realated counters in SI and SU. Before #1870, counters were
updated for all HA states in all red models without any definite rule. Because
of this good number of issues related to AMFD crashes were reported. Ticket
#1870 was for updatig counters uniformly in all the
Hi Praveen,
I have found a commit that updates saAmfSISUHAState right after sending su_si
assignment in function avd_susi_mod_send, which is:
changeset: 3016:8f4d14ab88e4
summary: AVSv:Updating susi assignment countrs at the time of role sending
#1870
I think this commit was meant to
Hi Minh,
Ticket #1354 is based on a user list complaint. This ticket is related to
states and runtime objects.
Other ticket #1306 is related to notification that AMFD seds but talks almost
similar problem from notification perspective.
I think we can do something like this:
1)For fresh
---
** [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:** Thu Oct 20, 2016 07:58 PM UTC
**Owner:** nobody
In scenario of 2N Si-swap, when AMFD sends QUIESCED
15 matches
Mail list logo
