[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
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: 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 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
[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
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 query that is made during these assignments. But when admin operation or any escalation finishes then value will remain same in each query. Thanks, Praveen --- ** [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:** Mon Dec 12, 2016 11:35 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.-- 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
[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
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 recommended/supported. User should only read this attribute if admin operation/failover completes. Do you agree? Thanks, Minh --- ** [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 24, 2016 05:25 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
[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
- **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 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.-- ___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
- **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 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
[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
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 it's unlikely to happen since the other one - avd_susi_mod_send() has been done in opposite way. Thanks, Minh --- ** [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 Nov 10, 2016 05:30 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.-- 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
[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
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 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
[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
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 --- ** [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 04: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 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
[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
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 IMM before AMFND sends assignment response message to AMFD. Now the update of saAmfSISUHaState is consistent for both cases (avd_sg_su_si_mod_snd, avd_susi_mod_send), which were not before. Prior to #1725 part 2, avd_susi_mod_send() and avd_sg_su_si_mod_snd() had saAmfSISUHaState updated differently, so applications possibly have not used this attribute during component's assignment so far, since otherwise application would see this attribute working inconsistently and we would have had defect tickets for it before #1354? The change of saAmfSISUHaState is necessary for #1725 to know correct HaState of absent SUSIs to failover them. If you agree on this change of saAmfSISUHaState in #1725 then I think I can close #2134 for now. The inconsistent issue in #2133 is different, it is a decision to be made if failover during admin operation (rollback or continuation). I will mark #2133 as a defect for future work. Thanks, Minh --- ** [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:** Tue Nov 08, 2016 06:22 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.-- 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
[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
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
[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
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 shutting down SI, after component returns by saAmfCSIQuiescingComplete(), the HAState carried in assignment response to AMFD will be QUIESCED. Then in this case, AMFD will never have QUIESCING appeared to IMM? I have also looked up the user list email "Re: [users] CSI and SI assignments are updated in runtime attributes early". I think the right attribute we should consider is saAmfSIAssignmentState instead since the enquiry seemed about whether assignment actually is happening (AssignmentState), not assignment role (HaState) My suggesstion for #1354 is: - AMFD updates saAmfHAState at the time sending assignment request to AMFND, do not update saAmfSIAssignmentState (initially for fresh assignment would be UNASSIGNED) - When AMFND responds OK to assignment request, now a real assignment has completed actually and AMFD update counter and saAmfSIAssignmentState to (PARTIALLY_ASSIGNED or FULLY_ASSIGNED up on preferred configuration). Error like node failover, e.g... also can force an update saAmfSIAssignmentState to reflect the current status of assignment state. - Notification update is needed after assignment response. By doing this, user can know whether or a SI assignment has been completed, and this stays close to definition of 3.2.3.2 Assignment State, page 88 What do you think? Thanks, Minh --- ** [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 07:15 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
[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
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 red models based on HA state changes. Function avd_susi_update_assignment_counters() contains those rules. Counters saAmfSINumCurrActiveAssignments and saAmfSINumCurrStandbyAssignments and other similar are updated when IMM gives callback to AMF i.e for SI in si_rt_attr_cb(). So we counter is incremented inside avd_susi_mod_send() it will not be visible to user until user makes an explicitt request to AMFD via IMM. If a user query comes during assignments transition then in si_rt_attr_cb() dynamically count only those SUSIs which have fsm state ASSIGNED. Thus there will be consistency. 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:20 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
[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
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 update the assignment counter/saAmfSISUHAState at the time role of SUSI changes. It would be not appropriate if we don't update ha state but we increase/decrease the related counters (saAmfSINumCurrActiveAssignments, saAmfSINumCurrStandbyAssignments) to IMM. The ticket #1870 is quite old and I don't find description/motivation in details for this ticket. Do you know what it was for? Thanks, Minh --- ** [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:** Fri Oct 21, 2016 06:31 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
[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
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 assignment, runtime objects(SISU and CSICOMP) can be crated in IMM but wihout updating the HA state. Here susi->fsm state can be updated as AVD_SU_SI_STATE_ASGN (not required buy user). I think IMM will show HA sate as empty in this case. When AMFND responds to AMFD for the completion of assignment via susi_assign_event() then AMFD can update HA state, fsm state as AVD_SU_SI_STATE_ASGND and send the notification also. 2)For modify operation, I think state should be updated after AMFD gets assignment response from AMFND and also notification should be sent that time only. What do you think? Will it handle headless case also? 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:** Thu Oct 20, 2016 07:58 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.-- 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
[tickets] [opensaf:tickets] #2134 AMF: Update RTA saAmfSISUHAState to IMM
--- ** [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 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
