Hi Jim, Please find my responses inlined with [NK].
Thanks & Best Regards -Nagendra, +91-9866424860 www.GetHighAvailability.com Get High Availability Today! NJ, USA: +1 508-422-7725 | Hyderabad, India: +91 798-992-5293 -----Original Message----- From: Carroll, James R [mailto:[email protected]] Sent: 12 December 2019 02:36 To: [email protected] Subject: [users] [RESEND] Clarification of CSISet timeout vs HA state Resending, based on following ambiguous response received: Your mail to 'Opensaf-users' with the subject Clarification of CSISet timeout vs HA state Is being held until the list moderator can review it for approval. The reason it is being held: Message has implicit destination Is this mailing list still Active and valid? Thanks. Original message follows: ======================= Hi all, I am looking for a clarification of the expected SAF behavior in response to an AMF issued CSISetCallback() command. We are using OpenSAF 5.2.0, and have observed the following anomaly. 1. We are using a 2N redundancy model. 2. A component has (intentionally) configured an extremely long CSISetCallbackTimeout. Note - by specification, this number is of type SaTimeT, and can represent a number in the range of up to ~292 years. 3. For this example case, the Assignment of ACTIVE has occurred as expected, with no issues or anomalies. 4. Now, continuing with the example, when the Assignment of STANDBY occurs, the component is dependent upon other external resources, and since it has a very long csisetcallbacktimtout, it chooses to NOT RESPOND at all to the AMF. [NK]: Are those external resources, a part of Amf cluster or Amf component? You can chose to use instantiation level dependency or SI Dependency if they suites your need. 5. The AMF, without having received either an ERROR response, or a TIMEOUT response, has "assumed" the component has complied with its request. This results in the following behavior: * An almost instantaneous notification that the Service Instance Assignment has completed. * The HA State is reported as STANDBY i. This gives a misleading/false representation of the system. If OpenSAF has reported that both an ACTIVE and a STANDBY are available, then I should be able to failover from the ACTIVE to the STANDBY. But, in this case, the STANDBY has not acknowledged his role, so the failover will not succeed. This does not seem like expected behavior for a High Availability System. [NK]: Yes, this is the behaviour since the beginning, definitely need to be corrected. Are you dependent only on notifications? Can you chose to use PG tracking? ii. We also considered using the HAReadinessStateSet() API, but after reviewing the documentation, we see that this feature is currently not implemented in OpenSAF. Is this feature expected to be included in any near term release? [NK]: There is an enhancement ticket https://sourceforge.net/p/opensaf/tickets/83/ . So, it seems like the AMF should be more restrictive in reporting out these state changes - they should be based on actual acknowledgement of the intended roles, not assumed. Can someone please clarify this AMF behavior. Thanks. Jim _______________________________________________ Opensaf-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-users _______________________________________________ Opensaf-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-users
