[tickets] [opensaf:tickets] #3348 mds: fix typo error

[Nagendra Kumar via Opensaf-tickets]

---

**[tickets:#3348] mds: fix typo error**

**Status:** unassigned
**Milestone:** 5.24.09
**Created:** Wed Feb 28, 2024 06:13 PM UTC by Nagendra Kumar
**Last Updated:** Wed Feb 28, 2024 06:13 PM UTC
**Owner:** nobody


The following fixes the typo:
diff -rupN ori/src/mds/mds_svc_op.c mod/src/mds/mds_svc_op.c
--- ori/src/mds/mds_svc_op.c2023-03-28 01:00:36.0 +0100
+++ mod/src/mds/mds_svc_op.c2024-01-16 16:43:47.506848477 +
@@ -642,8 +642,8 @@ uint32_t mds_svc_op_unsubscribe(const NC
mds_subtn_tbl_del(svc_hdl, info->info.svc_cancel.i_svc_ids[i]);
MDS_SVC_LOG_INFO(UNSUBSCRIBE_TAG, info,
"Unsubscribe to svc_id = %s(%d) successful",
-   get_svc_names(info->info.svc_subscribe.i_svc_ids[i]),
-   info->info.svc_subscribe.i_svc_ids[i]);
+   get_svc_names(info->info.svc_cancel.i_svc_ids[i]),
+   info->info.svc_cancel.i_svc_ids[i]);
}
m_MDS_LEAVE();
return NCSCC_RC_SUCCESS;



---

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] #2526 amfd: Command unlock nodegroup timeout if su failover is escalated (>= 2SIs)

[Nagendra Kumar via Opensaf-tickets]

Trying to reproduce it on latest OpenSAF.
Thanks
-Nagendra
High Availability Solutions(www.GetHighAvailability.com)


---

** [tickets:#2526] amfd: Command unlock nodegroup timeout if su failover is 
escalated (>= 2SIs)**

**Status:** accepted
**Milestone:** future
**Labels:** nodegroup timeout 
**Created:** Wed Jul 12, 2017 04:23 AM UTC by Minh Hon Chau
**Last Updated:** Mon Oct 10, 2022 12:20 PM UTC
**Owner:** Nagendra Kumar
**Attachments:**

- 
[app3_twon3su3si.xml](https://sourceforge.net/p/opensaf/tickets/2526/attachment/app3_twon3su3si.xml)
 (14.6 kB; text/xml)


- Configuration: 2N app, 3SI (model is attached), SU4/SU5 are hosted on PL4/PL5 
respectively
- Steps:
. Create nodegroup consists of PL4/PL5
. Unlock ng
. SU4 is assigned ACTIVE
. While component of SU5 is being assigned STANDBY, kill a component of SU4 to 
escalate to a SuFailover
. SU4 is now getting STANDBY assignment, SU5 is getting ACTIVE assignment
. But the command unlock ng is being hold until TIMEOUT

Note: Repeat the same test with only **1 SI**, the command unlock ng returns OK


---

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] #2526 amfd: Command unlock nodegroup timeout if su failover is escalated (>= 2SIs)

[Nagendra Kumar via Opensaf-tickets]

- **status**: assigned --> accepted



---

** [tickets:#2526] amfd: Command unlock nodegroup timeout if su failover is 
escalated (>= 2SIs)**

**Status:** accepted
**Milestone:** future
**Labels:** nodegroup timeout 
**Created:** Wed Jul 12, 2017 04:23 AM UTC by Minh Hon Chau
**Last Updated:** Mon Oct 10, 2022 12:19 PM UTC
**Owner:** Nagendra Kumar
**Attachments:**

- 
[app3_twon3su3si.xml](https://sourceforge.net/p/opensaf/tickets/2526/attachment/app3_twon3su3si.xml)
 (14.6 kB; text/xml)


- Configuration: 2N app, 3SI (model is attached), SU4/SU5 are hosted on PL4/PL5 
respectively
- Steps:
. Create nodegroup consists of PL4/PL5
. Unlock ng
. SU4 is assigned ACTIVE
. While component of SU5 is being assigned STANDBY, kill a component of SU4 to 
escalate to a SuFailover
. SU4 is now getting STANDBY assignment, SU5 is getting ACTIVE assignment
. But the command unlock ng is being hold until TIMEOUT

Note: Repeat the same test with only **1 SI**, the command unlock ng returns OK


---

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] #2526 amfd: Command unlock nodegroup timeout if su failover is escalated (>= 2SIs)

[Nagendra Kumar via Opensaf-tickets]

- **status**: unassigned --> assigned
- **assigned_to**: Nagendra Kumar



---

** [tickets:#2526] amfd: Command unlock nodegroup timeout if su failover is 
escalated (>= 2SIs)**

**Status:** assigned
**Milestone:** future
**Labels:** nodegroup timeout 
**Created:** Wed Jul 12, 2017 04:23 AM UTC by Minh Hon Chau
**Last Updated:** Wed Jan 09, 2019 09:43 PM UTC
**Owner:** Nagendra Kumar
**Attachments:**

- 
[app3_twon3su3si.xml](https://sourceforge.net/p/opensaf/tickets/2526/attachment/app3_twon3su3si.xml)
 (14.6 kB; text/xml)


- Configuration: 2N app, 3SI (model is attached), SU4/SU5 are hosted on PL4/PL5 
respectively
- Steps:
. Create nodegroup consists of PL4/PL5
. Unlock ng
. SU4 is assigned ACTIVE
. While component of SU5 is being assigned STANDBY, kill a component of SU4 to 
escalate to a SuFailover
. SU4 is now getting STANDBY assignment, SU5 is getting ACTIVE assignment
. But the command unlock ng is being hold until TIMEOUT

Note: Repeat the same test with only **1 SI**, the command unlock ng returns OK


---

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] #3204 amf: support of node repair feature

[Nagendra Kumar via Opensaf-tickets]

Hi Thang,
I just now tested this scenario. It returns TRY_AGAIN and a log in the syslog 
saying SC-2 is not part of CLM cluster. The log in the syslog, will be because 
to repair a disabled node, the differentiation has to be with CLM whether the 
node is down or faulty.
When you test using amf-adm or immadm then when amf/someother-service returns 
TRY_AGAIN, then it will try again and will not return try_again to you until it 
times out.
Thanks
-Nagu


---

** [tickets:#3204] amf: support of node repair feature**

**Status:** review
**Milestone:** 5.20.08
**Created:** Mon Jul 20, 2020 11:57 PM UTC by Anand Sundararaj
**Last Updated:** Mon Jul 27, 2020 07:43 AM UTC
**Owner:** Anand Sundararaj


Support of Administrative operation "SA_AMF_ADMIN_REPAIRED" on Amf Node
Amf Specs B.4.1 section: 9.4.10 SA_AMF_ADMIN_REPAIRED


---

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] Re: #3205 amf: remove hard-coding in amfnd

[Nagendra Kumar via Opensaf-tickets]

That's right, Thang.
Thanks
-Nagu


---

** [tickets:#3205] amf: remove hard-coding in amfnd**

**Status:** review
**Milestone:** 5.20.08
**Created:** Tue Jul 21, 2020 12:35 AM UTC by Anand Sundararaj
**Last Updated:** Mon Jul 27, 2020 06:30 AM UTC
**Owner:** Anand Sundararaj
**Attachments:**

- 
[amfnd_non_root_default.patch](https://sourceforge.net/p/opensaf/tickets/3205/attachment/amfnd_non_root_default.patch)
 (1.2 kB; application/octet-stream)


Amfnd is hard-coded to run as root:
"src/amf/amfnd/main.cc":
  daemonize_as_user("root", argc, argv);
This needs to be removed.

This is with reference to User Query and the patch(attached) was provided by 
Praveen:

On 13-Apr-17 7:27 PM, Carroll, James R wrote:
> Hi,
> 
> I am using openSAF 5.0, and it appears that some of the openSAF (amfnd) 
> daemons are hard-coded to run as root.
> Is there any way to disable this feature, so that I do not have to run the 
> daemon as root?
> 
> I see the following note in the README documentation:
> Only two processes are running as root, amfnd and smfnd. Reason is 
> that amfnd need todo that for backwards compatible reasons and the programs 
> it starts might be designed to require root access.
> 
> We are trying to run all of our programs as non-root.  Regarding the 
> documentation noted above, if we can start all our programs as non-root, then 
> we would not need to run the opensaf as root.

As of now, it is hard-coded in amfnd to run as root.
Attached are patches on default and 5.0 branch to enable amfnd to start as 
non-root.
After installation of OpenSAF, uncomment "#AMFND_NON_ROOT=1" line in amfnd.conf 
to enable amfnd to run as a user  as mentioned in amfnd.conf. 
By default it will run as root.

Thanks
Praveen


---

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] #3205 amf: remove hard-coding in amfnd

[Nagendra Kumar via Opensaf-tickets]

Hi Thang,
1. This is the option/flexibility being provided, not breaking anything. It is 
by default off.
2. As you can see in the tickt description, the requirement was reported in the 
user's list, so it looks real use case. This helps in increasing OpenSAF' 
adaptation across the globe.
3. Many users doesn't use Smf and they start from 5.20.05 onwards, needn't 
worry about a release 4.2, which was released 6 or 7 years back. So, no 
backward compatibility issue, agree ??
Please suggest.
Thanks
-Nagendra


---

** [tickets:#3205] amf: remove hard-coding in amfnd**

**Status:** review
**Milestone:** 5.20.08
**Created:** Tue Jul 21, 2020 12:35 AM UTC by Anand Sundararaj
**Last Updated:** Mon Jul 27, 2020 03:33 AM UTC
**Owner:** Anand Sundararaj
**Attachments:**

- 
[amfnd_non_root_default.patch](https://sourceforge.net/p/opensaf/tickets/3205/attachment/amfnd_non_root_default.patch)
 (1.2 kB; application/octet-stream)


Amfnd is hard-coded to run as root:
"src/amf/amfnd/main.cc":
  daemonize_as_user("root", argc, argv);
This needs to be removed.

This is with reference to User Query and the patch(attached) was provided by 
Praveen:

On 13-Apr-17 7:27 PM, Carroll, James R wrote:
> Hi,
> 
> I am using openSAF 5.0, and it appears that some of the openSAF (amfnd) 
> daemons are hard-coded to run as root.
> Is there any way to disable this feature, so that I do not have to run the 
> daemon as root?
> 
> I see the following note in the README documentation:
> Only two processes are running as root, amfnd and smfnd. Reason is 
> that amfnd need todo that for backwards compatible reasons and the programs 
> it starts might be designed to require root access.
> 
> We are trying to run all of our programs as non-root.  Regarding the 
> documentation noted above, if we can start all our programs as non-root, then 
> we would not need to run the opensaf as root.

As of now, it is hard-coded in amfnd to run as root.
Attached are patches on default and 5.0 branch to enable amfnd to start as 
non-root.
After installation of OpenSAF, uncomment "#AMFND_NON_ROOT=1" line in amfnd.conf 
to enable amfnd to run as a user  as mentioned in amfnd.conf. 
By default it will run as root.

Thanks
Praveen


---

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] #2898 imm: syslog number of recent fevs messages when immnd down

[Nagendra Kumar via Opensaf-tickets]

- **Component**: plm --> imm



---

** [tickets:#2898] imm: syslog number of recent fevs messages when immnd down**

**Status:** fixed
**Milestone:** 5.18.09
**Created:** Tue Jul 17, 2018 05:22 AM UTC by Vu Minh Nguyen
**Last Updated:** Sat Sep 29, 2018 01:17 PM UTC
**Owner:** Danh Vo


We has  encountered "OUT OF ORDER" error sometimes, and it is not easy to find 
out which message has been lost.

It would help if imm is able to syslog a number of recent fevs (e.g. 05) when 
detecting immnd down for any reason, showing recent sequence numbers and 
message ids. 


---

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] #2898 imm: syslog number of recent fevs messages when immnd down

[Nagendra Kumar via Opensaf-tickets]

- **Component**: imm --> plm



---

** [tickets:#2898] imm: syslog number of recent fevs messages when immnd down**

**Status:** fixed
**Milestone:** 5.18.09
**Created:** Tue Jul 17, 2018 05:22 AM UTC by Vu Minh Nguyen
**Last Updated:** Thu Aug 30, 2018 12:45 PM UTC
**Owner:** Danh Vo


We has  encountered "OUT OF ORDER" error sometimes, and it is not easy to find 
out which message has been lost.

It would help if imm is able to syslog a number of recent fevs (e.g. 05) when 
detecting immnd down for any reason, showing recent sequence numbers and 
message ids. 


---

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] #2928 osaf: Programmer's Reference and README need update

[Nagendra Kumar via Opensaf-tickets]

- **Component**: unknown --> ais
- **Part**: - --> doc



---

** [tickets:#2928] osaf: Programmer's Reference and README need update**

**Status:** unassigned
**Milestone:** 5.18.09
**Created:** Mon Sep 17, 2018 01:24 PM UTC by Nagendra Kumar
**Last Updated:** Mon Sep 17, 2018 01:24 PM UTC
**Owner:** nobody


Programmer's Reference and README need to be updated for better usability, 
readability and its coherence with OpenSAF functionalities.

Few of the things to be corrected are:
- References of devel lists tickets, which no longer exists.
- Formatting of different sections are different.
- Reference to old code structure: opensaf/osaf/, osaf/tools
- References to devel lists tickets, which are inaccessible.
- Sample output doesn't match with the current demo output.
- Spelling mistakes.

Some specific issues are:
Ntf:
The following command mentioned in Ntf PR doesn't work:
ntfsend -T 0x5000 -s 4 --probableCause 74 -a “additional information”

Smf;
Mentioned in PR: smf-bundle-import, smf-bundle-remove, smf-backup-restore 
doesn't exists.

Clm:
Mentioned in PR:  (see 1818). There is no links to it.


---

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] #2928 osaf: Programmer's Reference and README need update

[Nagendra Kumar via Opensaf-tickets]

---

** [tickets:#2928] osaf: Programmer's Reference and README need update**

**Status:** unassigned
**Milestone:** 5.18.09
**Created:** Mon Sep 17, 2018 01:24 PM UTC by Nagendra Kumar
**Last Updated:** Mon Sep 17, 2018 01:24 PM UTC
**Owner:** nobody


Programmer's Reference and README need to be updated for better usability, 
readability and its coherence with OpenSAF functionalities.

Few of the things to be corrected are:
- References of devel lists tickets, which no longer exists.
- Formatting of different sections are different.
- Reference to old code structure: opensaf/osaf/, osaf/tools
- References to devel lists tickets, which are inaccessible.
- Sample output doesn't match with the current demo output.
- Spelling mistakes.

Some specific issues are:
Ntf:
The following command mentioned in Ntf PR doesn't work:
ntfsend -T 0x5000 -s 4 --probableCause 74 -a “additional information”

Smf;
Mentioned in PR: smf-bundle-import, smf-bundle-remove, smf-backup-restore 
doesn't exists.

Clm:
Mentioned in PR:  (see 1818). There is no links to it.


---

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] #209 plmd crashed while deleting plm entities at various points.

[Nagendra Kumar via Opensaf-tickets]

This looks so easy to reproduce,  it should be critical.


---

** [tickets:#209] plmd crashed while deleting plm entities at various points.**

**Status:** assigned
**Milestone:** 5.18.09
**Created:** Wed May 15, 2013 07:02 AM UTC by Mathi Naickan
**Last Updated:** Sat Sep 15, 2018 11:26 AM UTC
**Owner:** MeenakshiTK


When the command , "immcfg -d safHE=7220_slot_1,safDomain=domain_1" is ran plm 
crashed with segmentation fault.
the above object has three childs dpb_1,dpb_2 and PL-13
plmd crashed with the following backtrace :
Program terminated with signal 11, Segmentation fault.
#0 0x08089af6 in plms_ent_to_ent_list_add (ent=0x80fe450, list=0xbbc5d9f8) at 
plms_utils.c:1360
1360 if (0 == strcmp(tail->plm_entity->dn_name_str,
(gdb) bt fH[[K
#0 0x08089af6 in plms_ent_to_ent_list_add (ent=0x80fe450, list=0xbbc5d9f8) at 
plms_utils.c:1360
#1 0x08088c8d in plms_chld_get (ent=0x80fe450, chld_list=0xbbc5d9f8) at 
plms_utils.c:842
#2 0x0805ca90 in plms_delete_objects (obj_type=6, obj_name=0x810a2a8) at 
plms_imm.c:697
#3 0x0805fa05 in plms_imm_ccb_apply_cbk (imm_oi_hdl=68719608079, ccb_id=2) at 
plms_imm.c:1425
#4 0x032fc46f in imma_process_callback_info (cb=) at imma_proc.c:2005
#5 0x032fb393 in imma_hdl_callbk_dispatch_one (cb=) at imma_proc.c:1592
#6 0x032ebcfd in saImmOiDispatch (immOiHandle=) at imma_oi_api.c:548
#7 0x08051bff in main (argc=2, argv=0xbbc5e414) at plms_main.c:484
#8 0x033aee0c in libc_start_main () from /lib/libc.so.6
#9 0x0804c401 in _start ()

While deleting the entity, which doesn't have any child, it crashed with the 
following backtrace
#0 0x0805cb14 in plms_delete_objects (obj_type=7, obj_name=0x8109588) at 
plms_imm.c:707
#1 0x0805fa05 in plms_imm_ccb_apply_cbk (imm_oi_hdl=824633852431, ccb_id=6) at 
plms_imm.c:1425
#2 0x0189c46f in imma_process_callback_info (cb=) at imma_proc.c:2005
#3 0x0189b393 in imma_hdl_callbk_dispatch_one (cb=) at imma_proc.c:1592
#4 0x0188bcfd in saImmOiDispatch (immOiHandle=) at imma_oi_api.c:548
#5 0x08051bff in main (argc=2, argv=0xbe1d6db4) at plms_main.c:484
#6 0x0194ee0c in libc_start_main () from /lib/libc.so.6
#7 0x0804c401 in _start ()

Also, check the following issue : 
Crash in plmc_err callback when ee_id is passed as empty string.


---

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] #2916 amfd: SU remains OUT_OF_SERVICE when unlock SU during cluster start up

[Nagendra Kumar via Opensaf-tickets]

Can you please update the ticket with the change sets?


---

** [tickets:#2916] amfd: SU remains OUT_OF_SERVICE when unlock SU during 
cluster start up**

**Status:** fixed
**Milestone:** 5.18.08
**Created:** Tue Aug 21, 2018 11:09 PM UTC by Minh Hon Chau
**Last Updated:** Thu Aug 23, 2018 10:16 PM UTC
**Owner:** Minh Hon Chau


The problem happens in NWay Active SUs, all SUs have the assignment, except SU 
in the SC-1.
Scenario: It is single step upgrade, after cluter reboot, SMF will issue unlock 
command during cluster startup.
During cluster starting up, SC-2 has already joined cluster and before the SC-1 
(standby) joins the cluster, issue unlock the SUs in SC-1 and SC-2. Only SU in 
SC-2 becomes IN_SERVICE.

  3001 2018-08-16T02:52:00.986+0200  SC-2 safApp=safAmfService NO: "Admin 
op "UNLOCK" initiated for 'safSu=SC-1,safSg=NWA,safApp=QWE-ABC-Amfproxy', 
invocation: 425201762315"
  3002 2018-08-16T02:52:00.987+0200  SC-2 safApp=safAmfService NO: 
"safSu=SC-1,safSg=NWA,safApp=QWE-ABC-Amfproxy AdmState LOCKED => UNLOCKED"
  3003 2018-08-16T02:52:00.988+0200  SC-2 safApp=safAmfService NO: "Admin 
op done for invocation: 425201762315, result 1"
  3004 2018-08-16T02:52:00.990+0200  SC-2 safApp=safAmfService NO: "Admin 
op "UNLOCK" initiated for 'safSu=SC-2,safSg=NWA,safApp=QWE-ABC-Amfproxy', 
invocation: 429496729612"
  3005 2018-08-16T02:52:00.990+0200  SC-2 safApp=safAmfService NO: 
"safSu=SC-2,safSg=NWA,safApp=QWE-ABC-Amfproxy AdmState LOCKED => UNLOCKED"
  3006 2018-08-16T02:52:00.991+0200  SC-2 safApp=safAmfService NO: 
"safSu=SC-2,safSg=NWA,safApp=QWE-ABC-Amfproxy ReadinessState OUT_OF_SERVICE => 
IN_SERVICE"

When "cluster init timeout" amfd will start assignment of all SUs

  3069 2018-08-16T02:52:10.058+0200  SC-2 safApp=safAmfService NO: "Cluster 
startup timeout, assigning SIs to SUs"

so we can see the other SUs were being assigned

  3080 2018-08-16T02:52:10.129+0200  SC-2 safApp=safAmfService NO: 
"safSi=ABC.main-NWA-1,safApp=QWE-ABC-Amfproxy assigned to 
safSu=SC-2,safSg=NWA,safApp=QWE-ABC-Amfproxy HA State 'ACTIVE'"

  3311 2018-08-16T02:53:55.745+0200  SC-2 safApp=safAmfService NO: 
"safSu=PL-4,safSg=NWA,safApp=QWE-ABC-Amfproxy PresenceState INSTANTIATING => 
INSTANTIATED"
  3312 2018-08-16T02:53:55.745+0200  SC-2 safApp=safAmfService NO: 
"safSu=PL-4,safSg=NWA,safApp=QWE-ABC-Amfproxy ReadinessState OUT_OF_SERVICE => 
IN_SERVICE"

  3313 2018-08-16T02:53:55.750+0200  SC-2 safApp=safAmfService NO: 
"safSi=ABC.main-NWA-1,safApp=QWE-ABC-Amfproxy assigned to 
safSu=PL-4,safSg=NWA,safApp=QWE-ABC-Amfproxy HA State 'ACTIVE'"

  3360 2018-08-16T02:54:06.555+0200  SC-2 safApp=safAmfService NO: 
"safSu=PL-3,safSg=NWA,safApp=QWE-ABC-Amfproxy PresenceState INSTANTIATING => 
INSTANTIATED"
  3361 2018-08-16T02:54:06.555+0200  SC-2 safApp=safAmfService NO: 
"safSu=PL-3,safSg=NWA,safApp=QWE-ABC-Amfproxy ReadinessState OUT_OF_SERVICE => 
IN_SERVICE"

  3362 2018-08-16T02:54:06.560+0200  SC-2 safApp=safAmfService NO: 
"safSi=ABC.main-NWA-1,safApp=QWE-ABC-Amfproxy assigned to 
safSu=PL-3,safSg=NWA,safApp=QWE-ABC-Amfproxy HA State 'ACTIVE'"

The only SU in SC-1 is not assigned, because it is still OUT_OF_SERVICE
The unlock command does not get the SU IN_SERVICE, because node SC-1 is still 
DISABLED.


---

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] #162 amfnd used 90 + % CPU on CLM unconfigured node because of saclmDispatch

[Nagendra Kumar via Opensaf-tickets]

- **assigned_to**: Nagendra Kumar -->  nobody 
- **Blocker**: True --> False



---

** [tickets:#162] amfnd used 90 + % CPU on CLM unconfigured node because of 
saclmDispatch**

**Status:** unassigned
**Milestone:** future
**Created:** Tue May 14, 2013 04:33 AM UTC by Nagendra Kumar
**Last Updated:** Mon Aug 28, 2017 07:00 AM UTC
**Owner:** nobody


Migrated from http://devel.opensaf.org/ticket/1339

Steps to reproduce:


1) Bring up 2 controller and 2 payloads
2) Lock one payload(CLM Node)and delete that node from database using immcfg 
utility
3) Lock another payload(CLM Node)


Payload one amfnd shows 100% CPU utilization


Reason:
CLM agent doesnot destroy the message delivered for unconfigured node.


Changed 3 years ago by rameshb ¶
  ■owner changed from sangeeta_meena to Nagendra 
■status changed from new to assigned 
■component changed from CLM to AvSv 
There should not be any dispatch of pending cbks in case of unconfigured node, 
I see amfnd should handle this in case of "SA_AIS_ERR_UNAVAILABLE" return code 
(say through CLM-finalize or through reboot the node).


Changed 2 years ago by jfournier ¶
  ■owner changed from Nagendra to nagendra 
Changed 2 years ago by jfournier ¶
  ■milestone changed from 4.0.RC1 to 4.0.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] #333 amf: saAmfHealthcheckStart returns SA_AIS_ERR_NOT_EXIST when SA_AMF_COMPONENT_NAME is not exported.

[Nagendra Kumar via Opensaf-tickets]

- **assigned_to**: Nagendra Kumar -->  nobody 



---

** [tickets:#333] amf: saAmfHealthcheckStart returns SA_AIS_ERR_NOT_EXIST when 
SA_AMF_COMPONENT_NAME is not exported.**

**Status:** unassigned
**Milestone:** 5.17.10
**Created:** Mon May 27, 2013 04:48 AM UTC by Praveen
**Last Updated:** Mon Aug 28, 2017 06:59 AM UTC
**Owner:** nobody


Migrated from http://devel.opensaf.org/ticket/2113.





Unless SA_AMF_COMPONENT_NAME is not exported, health check is not started for 
unregistered process.
 

As APPENDIX B on page 442 specifies that saAmfHealthcheckStart can be called in 
the context of any process , whether it is not registered or not



---

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] #399 amf: SU admin state not updated after doing controller switchover and admin lock of SU.

[Nagendra Kumar via Opensaf-tickets]

- **assigned_to**: Nagendra Kumar -->  nobody 



---

** [tickets:#399] amf: SU admin state not updated after doing controller 
switchover and admin lock of SU.**

**Status:** unassigned
**Milestone:** future
**Created:** Fri May 31, 2013 05:21 AM UTC by Praveen
**Last Updated:** Mon Aug 28, 2017 06:59 AM UTC
**Owner:** nobody


Migrated from http://devel.opensaf.org/ticket/2879.

changeset : 3796, 4.2.2
 model : NpluM
 

Initial Configuration:-
 =
 SI equal distribution
 saAmfSGNumPrefInserviceSUs=5 -a saAmfSGMaxActiveSIsperSU=2 -a 
saAmfSGMaxStandbySIsperSU=3 -a saAmfSGNumPrefActiveSUs=3 -a 
saAmfSGNumPrefStandbySUs=2
 saAmfSGAutoAdjust=1
 

6 SIs in locked state.
 saAmfSIPrefActiveAssignments=1 -a saAmfSIPrefStandbyAssignments=1
 

5SUs with same SURank set to 5.Each SUs admin state was locked-instantiation 
state.
 SU1, SU4, SU5 spawned on SC-1
 SU2 on SC-2
 SU3 on PL-4
 

Steps:-
 1. Brought up the NplusM model with above configuration.
 2. Performed unlock-instantiation operation on each SUs (SU1 to SU5)
 3. Performed unlock operation on each SUs (SU1 to SU5).
 4. Performed unlock of each SIs (SI1 to SI6)
 

Here observed that SUSI assignments were equally distributed.
 

5. Now on SC-1, command line trigger controller switchover
 and immediately on SC-2, trigger the admin lock on SU1.
 

Here observed that controller switchover successfully completed
 but the admin lock on SU1 failed with SA_AIS_ERR_TIMEOUT.
 

Again tried to lock the SU1, but this time it got failed with SA_AIS_ERR_NO_OP. 
It was failing with the same error SA_AIS_ERR_NO_OP after reties. amf-state su 
states was showing the admin state of SU1 as UNLOCKED. Hence admin state of SU1 
was not getting changed. 
Observed that all the SUSI assignments from SU1 got removed but the 


/var/log/messages was printing the below messages:-
 

Oct 23 13:01:53 SLOT2 osafimmnd[7176]: Timeout on syncronous admin operation 1
 Oct 23 13:03:47 SLOT2 osafamfd[7225]: Admin operation (2) has no effect on 
current state (2)
 Oct 23 13:06:15 SLOT2 osafamfd[7225]: Admin operation (2) has no effect on 
current state (2)
 

safSu=d_NplusM_1Norm_1,safSg=SG_d_npm,safApp=NpMApp
 


saAmfSUAdminState=UNLOCKED(1)
 saAmfSUOperState=ENABLED(1)
 saAmfSUPresenceState=INSTANTIATED(3)
 saAmfSUReadinessState=IN-SERVICE(2)
 

safSu=d_NplusM_1Norm_2,safSg=SG_d_npm,safApp=NpMApp
 


saAmfSUAdminState=UNLOCKED(1)
 saAmfSUOperState=ENABLED(1)
 saAmfSUPresenceState=INSTANTIATED(3)
 saAmfSUReadinessState=IN-SERVICE(2)
 

safSu=d_NplusM_1Norm_3,safSg=SG_d_npm,safApp=NpMApp
 


saAmfSUAdminState=UNLOCKED(1)
 saAmfSUOperState=ENABLED(1)
 saAmfSUPresenceState=INSTANTIATED(3)
 saAmfSUReadinessState=IN-SERVICE(2)
 

safSu=d_NplusM_1Norm_4,safSg=SG_d_npm,safApp=NpMApp
 


saAmfSUAdminState=UNLOCKED(1)
 saAmfSUOperState=ENABLED(1)
 saAmfSUPresenceState=INSTANTIATED(3)
 saAmfSUReadinessState=IN-SERVICE(2)
 

safSu=d_NplusM_1Norm_5,safSg=SG_d_npm,safApp=NpMApp
 


saAmfSUAdminState=UNLOCKED(1)
 saAmfSUOperState=ENABLED(1)
 saAmfSUPresenceState=INSTANTIATED(3)
 saAmfSUReadinessState=IN-SERVICE(2)
 

safSISU=safSu=SC-1\,safSg=NoRed?\,safApp=OpenSAF,safSi=NoRed?2,safApp=OpenSAF
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF
 


saAmfSISUHAState=STANDBY(2)
 

safSISU=safSu=SC-2\,safSg=NoRed?\,safApp=OpenSAF,safSi=NoRed?1,safApp=OpenSAF
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=PL-3\,safSg=NoRed?\,safApp=OpenSAF,safSi=NoRed?4,safApp=OpenSAF
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=PL-4\,safSg=NoRed?\,safApp=OpenSAF,safSi=NoRed?3,safApp=OpenSAF
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=d_NplusM_1Norm_4\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_6,safApp=NpMApp
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=d_NplusM_1Norm_2\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_3,safApp=NpMApp
 


saAmfSISUHAState=STANDBY(2)
 

safSISU=safSu=d_NplusM_1Norm_2\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_1,safApp=NpMApp
 


saAmfSISUHAState=STANDBY(2)
 

safSISU=safSu=d_NplusM_1Norm_2\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_2,safApp=NpMApp
 


saAmfSISUHAState=STANDBY(2)
 

safSISU=safSu=d_NplusM_1Norm_5\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_1,safApp=NpMApp
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=d_NplusM_1Norm_3\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_2,safApp=NpMApp
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=d_NplusM_1Norm_5\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_4,safApp=NpMApp
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=d_NplusM_1Norm_4\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_3,safApp=NpMApp
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=d_NplusM_1Norm_3\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_5,safApp=NpMApp
 


saAmfSISUHAState=ACTIVE(1)


Changed 7 months ago by shareef 




Same issue also 

[tickets] [opensaf:tickets] #178 escalation policy is not happening till the restart count exceeds, instead of reaching saAmfSGCompRestartMax for NPI components

[Nagendra Kumar via Opensaf-tickets]

- **assigned_to**: Nagendra Kumar -->  nobody 
- **Blocker**: False --> True



---

** [tickets:#178] escalation policy is not happening till the restart count 
exceeds, instead of reaching saAmfSGCompRestartMax for NPI components**

**Status:** unassigned
**Milestone:** future
**Created:** Tue May 14, 2013 06:24 AM UTC by Nagendra Kumar
**Last Updated:** Mon Aug 28, 2017 07:00 AM UTC
**Owner:** nobody


Migrated from http://devel.opensaf.org/ticket/2144

error escalation is not happening till the restart count exceeds 
saAmfSGCompRestartMax for the components brought up in NPI.


But according to spec, first level escalation should happen when the restart 
count reaches the saAmfSGCompRestartMax


Mentioned in the spec, 3.11.2.2 page NO: 203,


If this count reaches the saAmfSGCompRestartMax value before the end of the
"component restart" probation period, the Availability Management Framework per-
forms the first level of recovery escalation for that service unit: the 
Availability Man-
agement Framework restarts the entire service unit





---

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] #1795 AMF : haState should be marked QUIESCING in PG callback for shutdown op

[Nagendra Kumar via Opensaf-tickets]

- **assigned_to**: Nagendra Kumar -->  nobody 



---

** [tickets:#1795] AMF : haState should be marked QUIESCING in PG callback for 
shutdown op**

**Status:** unassigned
**Milestone:** future
**Created:** Fri Apr 29, 2016 07:24 AM UTC by Srikanth R
**Last Updated:** Mon Aug 28, 2017 06:59 AM UTC
**Owner:** nobody


Changeset : 7434

For the shutdown operation on the SI, the haState is filled up with the value 
SA_AMF_HA_QUIESCED (3), instead of SA_AMF_HA_QUIESCING (4)  in the protection 
group callback.


PROTECTION GROUP CALLBACK IS INVOKED
error :  1
numberOfMembers :  2
csiName :  safCsi=CSI1,safSi=TestApp_SI1,safApp=TestApp_TwoN
number of items in notification buffer is  2
{0: {'member': {'haState': 2, 'compName': 
safComp=COMP1,safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN, 'rank': 
1, 'haReadinessState': 1}, 'change': 1}, 1: {'member': {'haState': **3**, 
'compName': 
safComp=COMP1,safSu=TestApp_SU2,safSg=TestApp_SG1,safApp=TestApp_TwoN, 'rank': 
2, 'haReadinessState': 1}, 'change': 4}}



---

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] #1799 AMF : csiName and csiFlags are not properly populated, during assignment removal ( proxy)

[Nagendra Kumar via Opensaf-tickets]

- **assigned_to**: Nagendra Kumar -->  nobody 



---

** [tickets:#1799] AMF : csiName and csiFlags are not properly populated, 
during assignment removal ( proxy)**

**Status:** unassigned
**Milestone:** future
**Created:** Sat Apr 30, 2016 06:17 AM UTC by Srikanth R
**Last Updated:** Mon Aug 28, 2017 06:58 AM UTC
**Owner:** nobody


Changeset : 7436
Setup :2N redmodel with both proxy and proxied hosted on the same node.


* Initially the proxy and proxied are in  fully assigned  state.
* Now perform lock operation on proxy SU, for which quiesced callback and csi 
removal callback is populating the csiFlags as SA_AMF_CSI_TARGET_ALL  and 
csiName is populated as NULL. But the proxy component is having active 
assignments , which is to be removed according to the callback .  Similar is 
for lock operation is on proxied SU.

 So expectation is that for lock operation on either proxy / proxied SU 
,csiFlags should be populated as SA_AMF_CSI_TARGET_ONE  with the corresponding 
csi.



---

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] #1532 AMF : SI should be reverted to unlocked state, after shutdown operation of SI is rejected

[Nagendra Kumar via Opensaf-tickets]

- **assigned_to**: Nagendra Kumar -->  nobody 



---

** [tickets:#1532] AMF : SI should be reverted to unlocked state, after 
shutdown operation of SI is rejected**

**Status:** unassigned
**Milestone:** future
**Created:** Thu Oct 08, 2015 11:20 AM UTC by Srikanth R
**Last Updated:** Mon Aug 28, 2017 06:59 AM UTC
**Owner:** nobody


Changeset : 6901
Application  : 2n ( two SUs and 4 SIs with SI1 as sponsor for the remaining SIs)

Steps :

 * Initially all the SIs are in assigned state.
 * Invoked shutdown operation on one of the dependent SI .i.e SI2.
 *  For the quiescing callback, component responded with FAILED_OP

Oct  8 16:27:20 SYSTEST-PLD-1 osafamfnd[4535]: NO Assigning 
'safSi=TestApp_SI2,safApp=TestApp_TwoN' QUIESCING to 
'safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN'
Oct  8 16:27:30 SYSTEST-PLD-1 osafamfnd[4535]: NO Performing failover of 
'safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN' (SU failover count: 2)
Oct  8 16:27:30 SYSTEST-PLD-1 osafamfnd[4535]: NO 
'safComp=COMP2,safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN' faulted 
due to 'csiSetcallbackTimeout' : Recovery is 'componentFailover'

 * After recovery of SU1, SI2 assignments are also done, which is not expected.

Oct  8 16:27:30 SYSTEST-PLD-1 osafamfnd[4535]: NO 
'safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN' Presence State 
TERMINATING => INSTANTIATED
Oct  8 16:27:30 SYSTEST-PLD-1 osafamfnd[4535]: NO Assigning 
'safSi=TestApp_SI1,safApp=TestApp_TwoN' STANDBY to 
'safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN'
Oct  8 16:27:30 SYSTEST-PLD-1 osafamfnd[4535]: NO Assigning 
'safSi=TestApp_SI2,safApp=TestApp_TwoN' STANDBY to 
'safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN'
Oct  8 16:27:30 SYSTEST-PLD-1 osafamfnd[4535]: NO Assigning 
'safSi=TestApp_SI3,safApp=TestApp_TwoN' STANDBY to 
'safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN'

 * Below is the SI state after the shutdown operation
 safSi=TestApp_SI2,safApp=TestApp_TwoN
saAmfSIAdminState=LOCKED(2)
saAmfSIAssignmentState=FULLY_ASSIGNED(2)

* Further unlock operation of SI resulted in TIMEOUT return op.


---

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] #162 amfnd used 90 + % CPU on CLM unconfigured node because of saclmDispatch

[Nagendra Kumar via Opensaf-tickets]

- **status**: assigned --> unassigned
- **Blocker**:  --> True



---

** [tickets:#162] amfnd used 90 + % CPU on CLM unconfigured node because of 
saclmDispatch**

**Status:** unassigned
**Milestone:** future
**Created:** Tue May 14, 2013 04:33 AM UTC by Nagendra Kumar
**Last Updated:** Tue Sep 20, 2016 06:04 PM UTC
**Owner:** Nagendra Kumar


Migrated from http://devel.opensaf.org/ticket/1339

Steps to reproduce:


1) Bring up 2 controller and 2 payloads
2) Lock one payload(CLM Node)and delete that node from database using immcfg 
utility
3) Lock another payload(CLM Node)


Payload one amfnd shows 100% CPU utilization


Reason:
CLM agent doesnot destroy the message delivered for unconfigured node.


Changed 3 years ago by rameshb ¶
  ■owner changed from sangeeta_meena to Nagendra 
■status changed from new to assigned 
■component changed from CLM to AvSv 
There should not be any dispatch of pending cbks in case of unconfigured node, 
I see amfnd should handle this in case of "SA_AIS_ERR_UNAVAILABLE" return code 
(say through CLM-finalize or through reboot the node).


Changed 2 years ago by jfournier ¶
  ■owner changed from Nagendra to nagendra 
Changed 2 years ago by jfournier ¶
  ■milestone changed from 4.0.RC1 to 4.0.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] #178 escalation policy is not happening till the restart count exceeds, instead of reaching saAmfSGCompRestartMax for NPI components

[Nagendra Kumar via Opensaf-tickets]

- **status**: assigned --> unassigned
- **Blocker**:  --> False



---

** [tickets:#178] escalation policy is not happening till the restart count 
exceeds, instead of reaching saAmfSGCompRestartMax for NPI components**

**Status:** unassigned
**Milestone:** future
**Created:** Tue May 14, 2013 06:24 AM UTC by Nagendra Kumar
**Last Updated:** Tue Sep 20, 2016 06:04 PM UTC
**Owner:** Nagendra Kumar


Migrated from http://devel.opensaf.org/ticket/2144

error escalation is not happening till the restart count exceeds 
saAmfSGCompRestartMax for the components brought up in NPI.


But according to spec, first level escalation should happen when the restart 
count reaches the saAmfSGCompRestartMax


Mentioned in the spec, 3.11.2.2 page NO: 203,


If this count reaches the saAmfSGCompRestartMax value before the end of the
"component restart" probation period, the Availability Management Framework per-
forms the first level of recovery escalation for that service unit: the 
Availability Man-
agement Framework restarts the entire service unit





---

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] #333 amf: saAmfHealthcheckStart returns SA_AIS_ERR_NOT_EXIST when SA_AMF_COMPONENT_NAME is not exported.

[Nagendra Kumar via Opensaf-tickets]

- **status**: assigned --> unassigned



---

** [tickets:#333] amf: saAmfHealthcheckStart returns SA_AIS_ERR_NOT_EXIST when 
SA_AMF_COMPONENT_NAME is not exported.**

**Status:** unassigned
**Milestone:** 5.17.10
**Created:** Mon May 27, 2013 04:48 AM UTC by Praveen
**Last Updated:** Thu Jul 20, 2017 07:59 AM UTC
**Owner:** Nagendra Kumar


Migrated from http://devel.opensaf.org/ticket/2113.





Unless SA_AMF_COMPONENT_NAME is not exported, health check is not started for 
unregistered process.
 

As APPENDIX B on page 442 specifies that saAmfHealthcheckStart can be called in 
the context of any process , whether it is not registered or not



---

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] #1795 AMF : haState should be marked QUIESCING in PG callback for shutdown op

[Nagendra Kumar via Opensaf-tickets]

- **status**: assigned --> unassigned
- **Blocker**:  --> False



---

** [tickets:#1795] AMF : haState should be marked QUIESCING in PG callback for 
shutdown op**

**Status:** unassigned
**Milestone:** future
**Created:** Fri Apr 29, 2016 07:24 AM UTC by Srikanth R
**Last Updated:** Tue Sep 20, 2016 05:46 PM UTC
**Owner:** Nagendra Kumar


Changeset : 7434

For the shutdown operation on the SI, the haState is filled up with the value 
SA_AMF_HA_QUIESCED (3), instead of SA_AMF_HA_QUIESCING (4)  in the protection 
group callback.


PROTECTION GROUP CALLBACK IS INVOKED
error :  1
numberOfMembers :  2
csiName :  safCsi=CSI1,safSi=TestApp_SI1,safApp=TestApp_TwoN
number of items in notification buffer is  2
{0: {'member': {'haState': 2, 'compName': 
safComp=COMP1,safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN, 'rank': 
1, 'haReadinessState': 1}, 'change': 1}, 1: {'member': {'haState': **3**, 
'compName': 
safComp=COMP1,safSu=TestApp_SU2,safSg=TestApp_SG1,safApp=TestApp_TwoN, 'rank': 
2, 'haReadinessState': 1}, 'change': 4}}



---

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] #1799 AMF : csiName and csiFlags are not properly populated, during assignment removal ( proxy)

[Nagendra Kumar via Opensaf-tickets]

- **status**: assigned --> unassigned
- **Blocker**:  --> False



---

** [tickets:#1799] AMF : csiName and csiFlags are not properly populated, 
during assignment removal ( proxy)**

**Status:** unassigned
**Milestone:** future
**Created:** Sat Apr 30, 2016 06:17 AM UTC by Srikanth R
**Last Updated:** Tue Sep 20, 2016 06:04 PM UTC
**Owner:** Nagendra Kumar


Changeset : 7436
Setup :2N redmodel with both proxy and proxied hosted on the same node.


* Initially the proxy and proxied are in  fully assigned  state.
* Now perform lock operation on proxy SU, for which quiesced callback and csi 
removal callback is populating the csiFlags as SA_AMF_CSI_TARGET_ALL  and 
csiName is populated as NULL. But the proxy component is having active 
assignments , which is to be removed according to the callback .  Similar is 
for lock operation is on proxied SU.

 So expectation is that for lock operation on either proxy / proxied SU 
,csiFlags should be populated as SA_AMF_CSI_TARGET_ONE  with the corresponding 
csi.



---

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] #399 amf: SU admin state not updated after doing controller switchover and admin lock of SU.

[Nagendra Kumar via Opensaf-tickets]

- **status**: assigned --> unassigned
- **Blocker**:  --> False



---

** [tickets:#399] amf: SU admin state not updated after doing controller 
switchover and admin lock of SU.**

**Status:** unassigned
**Milestone:** future
**Created:** Fri May 31, 2013 05:21 AM UTC by Praveen
**Last Updated:** Tue Sep 20, 2016 06:04 PM UTC
**Owner:** Nagendra Kumar


Migrated from http://devel.opensaf.org/ticket/2879.

changeset : 3796, 4.2.2
 model : NpluM
 

Initial Configuration:-
 =
 SI equal distribution
 saAmfSGNumPrefInserviceSUs=5 -a saAmfSGMaxActiveSIsperSU=2 -a 
saAmfSGMaxStandbySIsperSU=3 -a saAmfSGNumPrefActiveSUs=3 -a 
saAmfSGNumPrefStandbySUs=2
 saAmfSGAutoAdjust=1
 

6 SIs in locked state.
 saAmfSIPrefActiveAssignments=1 -a saAmfSIPrefStandbyAssignments=1
 

5SUs with same SURank set to 5.Each SUs admin state was locked-instantiation 
state.
 SU1, SU4, SU5 spawned on SC-1
 SU2 on SC-2
 SU3 on PL-4
 

Steps:-
 1. Brought up the NplusM model with above configuration.
 2. Performed unlock-instantiation operation on each SUs (SU1 to SU5)
 3. Performed unlock operation on each SUs (SU1 to SU5).
 4. Performed unlock of each SIs (SI1 to SI6)
 

Here observed that SUSI assignments were equally distributed.
 

5. Now on SC-1, command line trigger controller switchover
 and immediately on SC-2, trigger the admin lock on SU1.
 

Here observed that controller switchover successfully completed
 but the admin lock on SU1 failed with SA_AIS_ERR_TIMEOUT.
 

Again tried to lock the SU1, but this time it got failed with SA_AIS_ERR_NO_OP. 
It was failing with the same error SA_AIS_ERR_NO_OP after reties. amf-state su 
states was showing the admin state of SU1 as UNLOCKED. Hence admin state of SU1 
was not getting changed. 
Observed that all the SUSI assignments from SU1 got removed but the 


/var/log/messages was printing the below messages:-
 

Oct 23 13:01:53 SLOT2 osafimmnd[7176]: Timeout on syncronous admin operation 1
 Oct 23 13:03:47 SLOT2 osafamfd[7225]: Admin operation (2) has no effect on 
current state (2)
 Oct 23 13:06:15 SLOT2 osafamfd[7225]: Admin operation (2) has no effect on 
current state (2)
 

safSu=d_NplusM_1Norm_1,safSg=SG_d_npm,safApp=NpMApp
 


saAmfSUAdminState=UNLOCKED(1)
 saAmfSUOperState=ENABLED(1)
 saAmfSUPresenceState=INSTANTIATED(3)
 saAmfSUReadinessState=IN-SERVICE(2)
 

safSu=d_NplusM_1Norm_2,safSg=SG_d_npm,safApp=NpMApp
 


saAmfSUAdminState=UNLOCKED(1)
 saAmfSUOperState=ENABLED(1)
 saAmfSUPresenceState=INSTANTIATED(3)
 saAmfSUReadinessState=IN-SERVICE(2)
 

safSu=d_NplusM_1Norm_3,safSg=SG_d_npm,safApp=NpMApp
 


saAmfSUAdminState=UNLOCKED(1)
 saAmfSUOperState=ENABLED(1)
 saAmfSUPresenceState=INSTANTIATED(3)
 saAmfSUReadinessState=IN-SERVICE(2)
 

safSu=d_NplusM_1Norm_4,safSg=SG_d_npm,safApp=NpMApp
 


saAmfSUAdminState=UNLOCKED(1)
 saAmfSUOperState=ENABLED(1)
 saAmfSUPresenceState=INSTANTIATED(3)
 saAmfSUReadinessState=IN-SERVICE(2)
 

safSu=d_NplusM_1Norm_5,safSg=SG_d_npm,safApp=NpMApp
 


saAmfSUAdminState=UNLOCKED(1)
 saAmfSUOperState=ENABLED(1)
 saAmfSUPresenceState=INSTANTIATED(3)
 saAmfSUReadinessState=IN-SERVICE(2)
 

safSISU=safSu=SC-1\,safSg=NoRed?\,safApp=OpenSAF,safSi=NoRed?2,safApp=OpenSAF
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF
 


saAmfSISUHAState=STANDBY(2)
 

safSISU=safSu=SC-2\,safSg=NoRed?\,safApp=OpenSAF,safSi=NoRed?1,safApp=OpenSAF
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=PL-3\,safSg=NoRed?\,safApp=OpenSAF,safSi=NoRed?4,safApp=OpenSAF
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=PL-4\,safSg=NoRed?\,safApp=OpenSAF,safSi=NoRed?3,safApp=OpenSAF
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=d_NplusM_1Norm_4\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_6,safApp=NpMApp
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=d_NplusM_1Norm_2\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_3,safApp=NpMApp
 


saAmfSISUHAState=STANDBY(2)
 

safSISU=safSu=d_NplusM_1Norm_2\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_1,safApp=NpMApp
 


saAmfSISUHAState=STANDBY(2)
 

safSISU=safSu=d_NplusM_1Norm_2\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_2,safApp=NpMApp
 


saAmfSISUHAState=STANDBY(2)
 

safSISU=safSu=d_NplusM_1Norm_5\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_1,safApp=NpMApp
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=d_NplusM_1Norm_3\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_2,safApp=NpMApp
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=d_NplusM_1Norm_5\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_4,safApp=NpMApp
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=d_NplusM_1Norm_4\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_3,safApp=NpMApp
 


saAmfSISUHAState=ACTIVE(1)
 

safSISU=safSu=d_NplusM_1Norm_3\,safSg=SG_d_npm\,safApp=NpMApp,safSi=d_NplusM_1Norm_5,safApp=NpMApp
 


saAmfSISUHAState=ACTIVE(1)


Changed 7 months ago by shareef 

[tickets] [opensaf:tickets] #1532 AMF : SI should be reverted to unlocked state, after shutdown operation of SI is rejected

[Nagendra Kumar via Opensaf-tickets]

- **Blocker**:  --> False



---

** [tickets:#1532] AMF : SI should be reverted to unlocked state, after 
shutdown operation of SI is rejected**

**Status:** unassigned
**Milestone:** future
**Created:** Thu Oct 08, 2015 11:20 AM UTC by Srikanth R
**Last Updated:** Tue Jun 07, 2016 11:22 AM UTC
**Owner:** Nagendra Kumar


Changeset : 6901
Application  : 2n ( two SUs and 4 SIs with SI1 as sponsor for the remaining SIs)

Steps :

 * Initially all the SIs are in assigned state.
 * Invoked shutdown operation on one of the dependent SI .i.e SI2.
 *  For the quiescing callback, component responded with FAILED_OP

Oct  8 16:27:20 SYSTEST-PLD-1 osafamfnd[4535]: NO Assigning 
'safSi=TestApp_SI2,safApp=TestApp_TwoN' QUIESCING to 
'safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN'
Oct  8 16:27:30 SYSTEST-PLD-1 osafamfnd[4535]: NO Performing failover of 
'safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN' (SU failover count: 2)
Oct  8 16:27:30 SYSTEST-PLD-1 osafamfnd[4535]: NO 
'safComp=COMP2,safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN' faulted 
due to 'csiSetcallbackTimeout' : Recovery is 'componentFailover'

 * After recovery of SU1, SI2 assignments are also done, which is not expected.

Oct  8 16:27:30 SYSTEST-PLD-1 osafamfnd[4535]: NO 
'safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN' Presence State 
TERMINATING => INSTANTIATED
Oct  8 16:27:30 SYSTEST-PLD-1 osafamfnd[4535]: NO Assigning 
'safSi=TestApp_SI1,safApp=TestApp_TwoN' STANDBY to 
'safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN'
Oct  8 16:27:30 SYSTEST-PLD-1 osafamfnd[4535]: NO Assigning 
'safSi=TestApp_SI2,safApp=TestApp_TwoN' STANDBY to 
'safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN'
Oct  8 16:27:30 SYSTEST-PLD-1 osafamfnd[4535]: NO Assigning 
'safSi=TestApp_SI3,safApp=TestApp_TwoN' STANDBY to 
'safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN'

 * Below is the SI state after the shutdown operation
 safSi=TestApp_SI2,safApp=TestApp_TwoN
saAmfSIAdminState=LOCKED(2)
saAmfSIAssignmentState=FULLY_ASSIGNED(2)

* Further unlock operation of SI resulted in TIMEOUT return op.


---

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] #248 "amf: Incorrect return code from saAmfComponentErrorReport_4 () and saAmfComponentErrorClear_4()".

[Nagendra Kumar via Opensaf-tickets]

- **status**: review --> fixed
- **Comment**:

commit 4a65aa761b8eb399f96325793f0b1b87edc7e44e
Author: Nagendra Kumar 
Date:   Mon Aug 28 12:15:24 2017 +0530

amfa: return BAD HANDLE in error report or error clear [#248]




---

** [tickets:#248] "amf: Incorrect return code from saAmfComponentErrorReport_4 
() and saAmfComponentErrorClear_4()". **

**Status:** fixed
**Milestone:** 5.17.10
**Created:** Thu May 16, 2013 06:41 AM UTC by Praveen
**Last Updated:** Thu Jul 20, 2017 08:01 AM UTC
**Owner:** Nagendra Kumar


Migrated from http://devel.opensaf.org/ticket/2817.

Changeset:3728
 When saAmfComponentErrorReport_4() and saAmfComponentErrorClear_4() are called 
after finalizing the amfHandle(calling saAmfFinalize()), both of them returns 
SA_AIS_ERR_VERSION instead of SA_AIS_ERR_BAD_HANDLE.



---

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] #248 "amf: Incorrect return code from saAmfComponentErrorReport_4 () and saAmfComponentErrorClear_4()".

[Nagendra Kumar via Opensaf-tickets]

The basic reason for returning SA_AIS_ERR_VERSION(3) from non-registered after 
finalise is that in Finalize(), pend_dis is zero  and ncs_ava_shutdown() is 
called, which in turn call ncs_ava_shutdown()->ava_destroy(). ava_destroy() 
deletes cb and makes gl_ava_hdl zero.
So, when ComponentErrorReport_4() is called ava_B4_ver_used(0) returns zero 
because neither cb nor gl_ava_hdl exists and then the following code returns 
SA_AIS_ERR_VERSION:
  /* Version is previously set in in initialize function */
  if (!ava_B4_ver_used(0)) {
TRACE_2(
"Invalid AMF version, set correct AMF version using saAmfInitialize_4. "
"Required version is: ReleaseCode = 'B', majorVersion = 0x04");
rc = SA_AIS_ERR_VERSION;
goto done;
  }

WHen called from registered process in Dispatch context, pend_dis is not zero 
and ncs_ava_shutdown() is not called and hence ava_B4_ver_used(0) returns true 
and code proceeds and returns BAD_HANDLE from later point of call.


---

** [tickets:#248] "amf: Incorrect return code from saAmfComponentErrorReport_4 
() and saAmfComponentErrorClear_4()". **

**Status:** assigned
**Milestone:** 5.2.FC
**Created:** Thu May 16, 2013 06:41 AM UTC by Praveen
**Last Updated:** Wed Jul 19, 2017 06:41 AM UTC
**Owner:** Nagendra Kumar


Migrated from http://devel.opensaf.org/ticket/2817.

Changeset:3728
 When saAmfComponentErrorReport_4() and saAmfComponentErrorClear_4() are called 
after finalizing the amfHandle(calling saAmfFinalize()), both of them returns 
SA_AIS_ERR_VERSION instead of SA_AIS_ERR_BAD_HANDLE.



---

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] #333 amf: saAmfHealthcheckStart returns SA_AIS_ERR_NOT_EXIST when SA_AMF_COMPONENT_NAME is not exported.

[Nagendra Kumar via Opensaf-tickets]

- **status**: unassigned --> assigned
- **assigned_to**: Nagendra Kumar
- **Part**: - --> nd
- **Blocker**:  --> False
- **Milestone**: future --> 5.17.10



---

** [tickets:#333] amf: saAmfHealthcheckStart returns SA_AIS_ERR_NOT_EXIST when 
SA_AMF_COMPONENT_NAME is not exported.**

**Status:** assigned
**Milestone:** 5.17.10
**Created:** Mon May 27, 2013 04:48 AM UTC by Praveen
**Last Updated:** Mon Apr 03, 2017 06:47 PM UTC
**Owner:** Nagendra Kumar


Migrated from http://devel.opensaf.org/ticket/2113.





Unless SA_AMF_COMPONENT_NAME is not exported, health check is not started for 
unregistered process.
 

As APPENDIX B on page 442 specifies that saAmfHealthcheckStart can be called in 
the context of any process , whether it is not registered or not



---

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] #248 "amf: Incorrect return code from saAmfComponentErrorReport_4 () and saAmfComponentErrorClear_4()".

[Nagendra Kumar via Opensaf-tickets]

The patch is tested on CS #8791


---

** [tickets:#248] "amf: Incorrect return code from saAmfComponentErrorReport_4 
() and saAmfComponentErrorClear_4()". **

**Status:** review
**Milestone:** 5.17.10
**Created:** Thu May 16, 2013 06:41 AM UTC by Praveen
**Last Updated:** Thu Jul 20, 2017 07:56 AM UTC
**Owner:** Nagendra Kumar


Migrated from http://devel.opensaf.org/ticket/2817.

Changeset:3728
 When saAmfComponentErrorReport_4() and saAmfComponentErrorClear_4() are called 
after finalizing the amfHandle(calling saAmfFinalize()), both of them returns 
SA_AIS_ERR_VERSION instead of SA_AIS_ERR_BAD_HANDLE.



---

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] #248 "amf: Incorrect return code from saAmfComponentErrorReport_4 () and saAmfComponentErrorClear_4()".

[Nagendra Kumar via Opensaf-tickets]

Attched the patch


Attachments:

- 
[248_1.patch](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/e78dae72/2a55/attachment/248_1.patch)
 (1.1 kB; application/octet-stream)


---

** [tickets:#248] "amf: Incorrect return code from saAmfComponentErrorReport_4 
() and saAmfComponentErrorClear_4()". **

**Status:** assigned
**Milestone:** 5.2.FC
**Created:** Thu May 16, 2013 06:41 AM UTC by Praveen
**Last Updated:** Thu Jul 20, 2017 07:55 AM UTC
**Owner:** Nagendra Kumar


Migrated from http://devel.opensaf.org/ticket/2817.

Changeset:3728
 When saAmfComponentErrorReport_4() and saAmfComponentErrorClear_4() are called 
after finalizing the amfHandle(calling saAmfFinalize()), both of them returns 
SA_AIS_ERR_VERSION instead of SA_AIS_ERR_BAD_HANDLE.



---

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] #248 "amf: Incorrect return code from saAmfComponentErrorReport_4 () and saAmfComponentErrorClear_4()".

[Nagendra Kumar via Opensaf-tickets]

- **status**: assigned --> review
- **Milestone**: 5.2.FC --> 5.17.10



---

** [tickets:#248] "amf: Incorrect return code from saAmfComponentErrorReport_4 
() and saAmfComponentErrorClear_4()". **

**Status:** review
**Milestone:** 5.17.10
**Created:** Thu May 16, 2013 06:41 AM UTC by Praveen
**Last Updated:** Thu Jul 20, 2017 07:55 AM UTC
**Owner:** Nagendra Kumar


Migrated from http://devel.opensaf.org/ticket/2817.

Changeset:3728
 When saAmfComponentErrorReport_4() and saAmfComponentErrorClear_4() are called 
after finalizing the amfHandle(calling saAmfFinalize()), both of them returns 
SA_AIS_ERR_VERSION instead of SA_AIS_ERR_BAD_HANDLE.



---

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] #248 "amf: Incorrect return code from saAmfComponentErrorReport_4 () and saAmfComponentErrorClear_4()".

[Nagendra Kumar via Opensaf-tickets]

- **status**: unassigned --> assigned
- **Blocker**:  --> False



---

** [tickets:#248] "amf: Incorrect return code from saAmfComponentErrorReport_4 
() and saAmfComponentErrorClear_4()". **

**Status:** assigned
**Milestone:** 5.2.FC
**Created:** Thu May 16, 2013 06:41 AM UTC by Praveen
**Last Updated:** Wed Apr 12, 2017 06:50 AM UTC
**Owner:** Nagendra Kumar


Migrated from http://devel.opensaf.org/ticket/2817.

Changeset:3728
 When saAmfComponentErrorReport_4() and saAmfComponentErrorReport_4() are 
called after finalizing the amfHandle(calling saAmfFinalize()), both of them 
returns SA_AIS_ERR_VERSION instead of SA_AIS_ERR_BAD_HANDLE.



---

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] #243 amf:Response_4 fails with ERR_VERSION even when invoked with correct versioned handle

[Nagendra Kumar via Opensaf-tickets]

- **status**: assigned --> invalid
- **Milestone**: future --> never
- **Comment**:

So, marking as invalid



---

** [tickets:#243] amf:Response_4 fails with ERR_VERSION even when invoked with 
correct versioned handle**

**Status:** invalid
**Milestone:** never
**Created:** Thu May 16, 2013 06:32 AM UTC by Praveen
**Last Updated:** Wed Jul 19, 2017 05:47 AM UTC
**Owner:** Nagendra Kumar
**Attachments:**

- 
[amf_demo_243.c](https://sourceforge.net/p/opensaf/tickets/243/attachment/amf_demo_243.c)
 (15.4 kB; application/octet-stream)


Migrated from http://devel.opensaf.org/ticket/2877.

The issue is seen on SLES 64bit VMs.
 

Migrated from http://devel.opensaf.org/ticket/2877.

The component initially initializes with B.4.1. Another initialize is invoked 
with B.1.1 version. When callbacks arrived at the component, Response_4 is 
invoked with the handle obtained from B.4.1 initialization. Response_4 returned 
SA_AIS_ERR_VERSION.

Output from the component log:
Invoking the function  with the arguments 
(4289724417, 4271898630L, None, 1)
 ('Return Value of the function : <—', 1) ==> Response_4 invoked before doing 
Initialize with B.1.1 version
Invoking the function  
('Return Value of the function : <—', [1, 4290772994])
Invoking the function  with the arguments 
(4289724417, 4287627277L, None, 1) 
('Return Value of the function : <—', 3) ===> same handle as used before but 
got ERR_VERSION now.
 

Traces can be shared if required.



---

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] #243 amf:Response_4 fails with ERR_VERSION even when invoked with correct versioned handle

[Nagendra Kumar via Opensaf-tickets]

Jul 19 11:11:24 PM_SC-1 osafamfnd[30940]: NO 
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1' Presence State INSTANTIATING => 
INSTANTIATED
Jul 19 11:11:24 PM_SC-1 amf_demo[31113]: HC started with AMF 4
Jul 19 11:11:24 PM_SC-1 amf_demo[31113]: 1. saAmfComponentRegister FAILED, But 
Continueing 14
Jul 19 11:11:24 PM_SC-1 amf_demo[31113]: HC started with AMF for 1
Jul 19 11:11:24 PM_SC-1 amf_demo[31113]: Registered with AMF
Jul 19 11:11:24 PM_SC-1 amf_demo[31113]: Health check 1
Jul 19 11:11:34 PM_SC-1 amf_demo[31113]: Health check 2
Jul 19 11:11:44 PM_SC-1 amf_demo[31113]: Health check 3
Jul 19 11:11:54 PM_SC-1 amf_demo[31113]: Health check 4

The response was given to Amf 4.1 callback.


---

** [tickets:#243] amf:Response_4 fails with ERR_VERSION even when invoked with 
correct versioned handle**

**Status:** assigned
**Milestone:** future
**Created:** Thu May 16, 2013 06:32 AM UTC by Praveen
**Last Updated:** Wed Jul 19, 2017 05:45 AM UTC
**Owner:** Nagendra Kumar
**Attachments:**

- 
[amf_demo_243.c](https://sourceforge.net/p/opensaf/tickets/243/attachment/amf_demo_243.c)
 (15.4 kB; application/octet-stream)


Migrated from http://devel.opensaf.org/ticket/2877.

The issue is seen on SLES 64bit VMs.
 

Migrated from http://devel.opensaf.org/ticket/2877.

The component initially initializes with B.4.1. Another initialize is invoked 
with B.1.1 version. When callbacks arrived at the component, Response_4 is 
invoked with the handle obtained from B.4.1 initialization. Response_4 returned 
SA_AIS_ERR_VERSION.

Output from the component log:
Invoking the function  with the arguments 
(4289724417, 4271898630L, None, 1)
 ('Return Value of the function : <—', 1) ==> Response_4 invoked before doing 
Initialize with B.1.1 version
Invoking the function  
('Return Value of the function : <—', [1, 4290772994])
Invoking the function  with the arguments 
(4289724417, 4287627277L, None, 1) 
('Return Value of the function : <—', 3) ===> same handle as used before but 
got ERR_VERSION now.
 

Traces can be shared if required.



---

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] #243 amf:Response_4 fails with ERR_VERSION even when invoked with correct versioned handle

[Nagendra Kumar via Opensaf-tickets]

Please find attached sample file, used in testing.
I tested on CS #8791. I didn't get any issue. Health check continued.


---

** [tickets:#243] amf:Response_4 fails with ERR_VERSION even when invoked with 
correct versioned handle**

**Status:** assigned
**Milestone:** future
**Created:** Thu May 16, 2013 06:32 AM UTC by Praveen
**Last Updated:** Wed Jul 19, 2017 05:43 AM UTC
**Owner:** Nagendra Kumar
**Attachments:**

- 
[amf_demo_243.c](https://sourceforge.net/p/opensaf/tickets/243/attachment/amf_demo_243.c)
 (15.4 kB; application/octet-stream)


Migrated from http://devel.opensaf.org/ticket/2877.

The issue is seen on SLES 64bit VMs.
 

Migrated from http://devel.opensaf.org/ticket/2877.

The component initially initializes with B.4.1. Another initialize is invoked 
with B.1.1 version. When callbacks arrived at the component, Response_4 is 
invoked with the handle obtained from B.4.1 initialization. Response_4 returned 
SA_AIS_ERR_VERSION.

Output from the component log:
Invoking the function  with the arguments 
(4289724417, 4271898630L, None, 1)
 ('Return Value of the function : <—', 1) ==> Response_4 invoked before doing 
Initialize with B.1.1 version
Invoking the function  
('Return Value of the function : <—', [1, 4290772994])
Invoking the function  with the arguments 
(4289724417, 4287627277L, None, 1) 
('Return Value of the function : <—', 3) ===> same handle as used before but 
got ERR_VERSION now.
 

Traces can be shared if required.



---

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] #243 amf:Response_4 fails with ERR_VERSION even when invoked with correct versioned handle

[Nagendra Kumar via Opensaf-tickets]

- Attachments has changed:

Diff:



--- old
+++ new
@@ -0,0 +1 @@
+amf_demo_243.c (15.4 kB; application/octet-stream)






---

** [tickets:#243] amf:Response_4 fails with ERR_VERSION even when invoked with 
correct versioned handle**

**Status:** assigned
**Milestone:** future
**Created:** Thu May 16, 2013 06:32 AM UTC by Praveen
**Last Updated:** Tue Jul 18, 2017 10:34 AM UTC
**Owner:** Nagendra Kumar
**Attachments:**

- 
[amf_demo_243.c](https://sourceforge.net/p/opensaf/tickets/243/attachment/amf_demo_243.c)
 (15.4 kB; application/octet-stream)


Migrated from http://devel.opensaf.org/ticket/2877.

The issue is seen on SLES 64bit VMs.
 

Migrated from http://devel.opensaf.org/ticket/2877.

The component initially initializes with B.4.1. Another initialize is invoked 
with B.1.1 version. When callbacks arrived at the component, Response_4 is 
invoked with the handle obtained from B.4.1 initialization. Response_4 returned 
SA_AIS_ERR_VERSION.

Output from the component log:
Invoking the function  with the arguments 
(4289724417, 4271898630L, None, 1)
 ('Return Value of the function : <—', 1) ==> Response_4 invoked before doing 
Initialize with B.1.1 version
Invoking the function  
('Return Value of the function : <—', [1, 4290772994])
Invoking the function  with the arguments 
(4289724417, 4287627277L, None, 1) 
('Return Value of the function : <—', 3) ===> same handle as used before but 
got ERR_VERSION now.
 

Traces can be shared if required.



---

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] #243 amf:Response_4 fails with ERR_VERSION even when invoked with correct versioned handle

[Nagendra Kumar via Opensaf-tickets]

- **status**: unassigned --> assigned
- **assigned_to**: Nagendra Kumar
- **Part**: - --> lib
- **Blocker**:  --> False



---

** [tickets:#243] amf:Response_4 fails with ERR_VERSION even when invoked with 
correct versioned handle**

**Status:** assigned
**Milestone:** future
**Created:** Thu May 16, 2013 06:32 AM UTC by Praveen
**Last Updated:** Mon Apr 03, 2017 06:47 PM UTC
**Owner:** Nagendra Kumar


Migrated from http://devel.opensaf.org/ticket/2877.

The issue is seen on SLES 64bit VMs.
 

Migrated from http://devel.opensaf.org/ticket/2877.

The component initially initializes with B.4.1. Another initialize is invoked 
with B.1.1 version. When callbacks arrived at the component, Response_4 is 
invoked with the handle obtained from B.4.1 initialization. Response_4 returned 
SA_AIS_ERR_VERSION.

Output from the component log:
Invoking the function  with the arguments 
(4289724417, 4271898630L, None, 1)
 ('Return Value of the function : <—', 1) ==> Response_4 invoked before doing 
Initialize with B.1.1 version
Invoking the function  
('Return Value of the function : <—', [1, 4290772994])
Invoking the function  with the arguments 
(4289724417, 4287627277L, None, 1) 
('Return Value of the function : <—', 3) ===> same handle as used before but 
got ERR_VERSION now.
 

Traces can be shared if required.



---

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] #2477 amfd: Cyclic reboot after SC absence period (in large cluster)

[Nagendra Kumar via Opensaf-tickets]

Hi Minh,
But I agree that we need to avoid rebooting the controllers, 
but by avoiding assert, I am not sure, let me check.

Thanks
-Nagu


---

** [tickets:#2477] amfd: Cyclic reboot after SC absence period (in large 
cluster)**

**Status:** review
**Milestone:** 5.17.06
**Labels:** assignment failover during stop of both SC 2416 
**Created:** Fri Jun 02, 2017 06:17 AM UTC by Minh Hon Chau
**Last Updated:** Wed Jun 07, 2017 09:00 AM UTC
**Owner:** Minh Hon Chau


The scenario of the problem in this ticket happens in the same scenario 
reported in #2416

After SC absence period, amfd gets into osafassert(), causes coredump, and the 
problem repeatedly happens 

One of patches of #2416 had tried to call IMM sync as soon as possible, and it 
works fine with a small cluster (5 nodes). But a large cluster consists of 
about 75 nodes, the change of IMM sync calls takes mostly no effect. 

In #2416, a problem had been seen with an assumption of unreliable IMM sync 
calls in which after SC absence period, amfd had 3 assignments for a 2N SG, 2 
STANDBY SUSIs , and 1 ACTIVE SUSI. It was fixed by commit :"amfd: Add iteration 
to failover all absent assignments [#2416]" (refer to: 
https://sourceforge.net/p/opensaf/tickets/2416/#f83b)

Another variant problem of unreliable IMM calls before both SC go down, is that 
amfd can have both SUs with ACTIVE assignments, that leads to assert. This 
problem can only be seen in large cluster so far


Details of coredump:
 
~~~
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/lib64/opensaf/osafamfd'.
Program terminated with signal SIGABRT, Aborted.
#0  0x7f784279b0c7 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: zypper install 
opensaf-amf-director-debuginfo-5.2.0-469.0.6128a2d.sle12.x86_64
(gdb) bt full
#0  0x7f784279b0c7 in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x7f784279c478 in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x7f78435fdf4e in __osafassert_fail (__file=, 
__line=, __func=, 
__assertion=) at ../../opensaf/src/base/sysf_def.c:286
No locals.
#3  0x7f78445671e8 in avd_sg_2n_act_susi (sg=, 
stby_susi=stby_susi@entry=0x7ffeef034998, cb=0x7f78447f2e80 <_control_block>)
at ../../opensaf/src/amf/amfd/sg_2n_fsm.cc:596
susi = 
a_susi_2 = 0x7f7845e0d0c0
s_susi_1 = 0x7f7845e0d0c0
su_2 = 
t_ = {trace_leave_called = false, file_ = 0x0, function_ = 0x0}
s_susi_2 = 0x7f7845e2a030
a_susi = 0x0
a_susi_1 = 0x7f7845e2a030
s_susi = 0x0
su_1 = 0x7f7845d69e60
#4  0x7f784456d5d6 in SG_2N::node_fail (this=0x7f7845d5f4f0, 
cb=0x7f78447f2e80 <_control_block>, su=0x7f7845d69e60)
at ../../opensaf/src/amf/amfd/sg_2n_fsm.cc:3402
a_susi = 
s_susi = 0x7f7845d69a68
o_su = 
flag = 
__FUNCTION__ = "node_fail"
su_ha_state = 
t_ = {trace_leave_called = false, file_ = 0x0, function_ = 0x0}
#5  0x7f784455de1a in AVD_SG::failover_absent_assignment 
(this=0x7f7845d5f4f0) at ../../opensaf/src/amf/amfd/sg.cc:2307
t_ = {trace_leave_called = false, file_ = 0x0, function_ = 0x0}
__FUNCTION__ = "failover_absent_assignment"
failed_su = 0x7f7845d69e60
#6  0x7f7844514125 in avd_cluster_tmr_init_evh (cb=0x7f78447f2e80 
<_control_block>, evt=)
at ../../opensaf/src/amf/amfd/cluster.cc:103
i_sg = 0x7f7845d5f4f0
__for_range = @0x7f7845ca2a90: {db = {_M_t = {
  _M_impl = 
{ const, AVD_SG*> > >> = 
{<__gnu_cxx::new_allocator const, AVD_SG*> > >> = {}, }, 
_M_key_compare = {, std::basic_string, bool>> = {}, 
}, _M_header = {_M_color = std::_S_red, 
  _M_parent = 0x7f7845d515e0, _M_left = 0x7f7845d03ed0, 
_M_right = 0x7f7845d81580}, _M_node_count = 28
t_ = {trace_leave_called = false, file_ = 0x0, function_ = 0x0}
__FUNCTION__ = "avd_cluster_tmr_init_evh"
su = 0x0
node = 
#7  0x7f784453ca2c in process_event (cb_now=0x7f78447f2e80 
<_control_block>, evt=0x7f78340013d0) at ../../opensaf/src/amf/amfd/main.cc:775
t_ = {trace_leave_called = false, file_ = 0x0, function_ = 0x0}
__FUNCTION__ = "process_event"
#8  0x7f78444f6abe in main_loop () at ../../opensaf/src/amf/amfd/main.cc:691
pollretval = 
evt = 0x7f78340013d0
polltmo = 0
term_fd = 24
cb = 0x7f78447f2e80 <_control_block>
error = 
old_sync_state = AVD_STBY_OUT_OF_SYNC
#9  main (argc=, argv=) at 
../../opensaf/src/amf/amfd/main.cc:848
No locals.
~~~



---

[tickets] [opensaf:tickets] #2477 amfd: Cyclic reboot after SC absence period (in large cluster)

[Nagendra Kumar via Opensaf-tickets]

Also, to note, it is documented as limitations in Amf PR Doc as below, so this 
ticket qualifies as Enhancement (could have been #2416 as well):
2.2.11.3Limitations
•   Possible loss of RTA updates and SI assignment messages
If both SCs go down abruptly (SCs are immediately powered-off for instance), 
AMFD could fail to update RTA to IMM, the SI assignment messages sent from 
AMFND could not reach to AMFD, or vice versa. In such cases,  recovery could be 
impossible, applications may have inappropriate assignment states.



---

** [tickets:#2477] amfd: Cyclic reboot after SC absence period (in large 
cluster)**

**Status:** review
**Milestone:** 5.17.06
**Labels:** assignment failover during stop of both SC 2416 
**Created:** Fri Jun 02, 2017 06:17 AM UTC by Minh Hon Chau
**Last Updated:** Mon Jun 05, 2017 10:18 AM UTC
**Owner:** Minh Hon Chau


The scenario of the problem in this ticket happens in the same scenario 
reported in #2416

After SC absence period, amfd gets into osafassert(), causes coredump, and the 
problem repeatedly happens 

One of patches of #2416 had tried to call IMM sync as soon as possible, and it 
works fine with a small cluster (5 nodes). But a large cluster consists of 
about 75 nodes, the change of IMM sync calls takes mostly no effect. 

In #2416, a problem had been seen with an assumption of unreliable IMM sync 
calls in which after SC absence period, amfd had 3 assignments for a 2N SG, 2 
STANDBY SUSIs , and 1 ACTIVE SUSI. It was fixed by commit :"amfd: Add iteration 
to failover all absent assignments [#2416]" (refer to: 
https://sourceforge.net/p/opensaf/tickets/2416/#f83b)

Another variant problem of unreliable IMM calls before both SC go down, is that 
amfd can have both SUs with ACTIVE assignments, that leads to assert. This 
problem can only be seen in large cluster so far


Details of coredump:
 
~~~
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/lib64/opensaf/osafamfd'.
Program terminated with signal SIGABRT, Aborted.
#0  0x7f784279b0c7 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: zypper install 
opensaf-amf-director-debuginfo-5.2.0-469.0.6128a2d.sle12.x86_64
(gdb) bt full
#0  0x7f784279b0c7 in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x7f784279c478 in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x7f78435fdf4e in __osafassert_fail (__file=, 
__line=, __func=, 
__assertion=) at ../../opensaf/src/base/sysf_def.c:286
No locals.
#3  0x7f78445671e8 in avd_sg_2n_act_susi (sg=, 
stby_susi=stby_susi@entry=0x7ffeef034998, cb=0x7f78447f2e80 <_control_block>)
at ../../opensaf/src/amf/amfd/sg_2n_fsm.cc:596
susi = 
a_susi_2 = 0x7f7845e0d0c0
s_susi_1 = 0x7f7845e0d0c0
su_2 = 
t_ = {trace_leave_called = false, file_ = 0x0, function_ = 0x0}
s_susi_2 = 0x7f7845e2a030
a_susi = 0x0
a_susi_1 = 0x7f7845e2a030
s_susi = 0x0
su_1 = 0x7f7845d69e60
#4  0x7f784456d5d6 in SG_2N::node_fail (this=0x7f7845d5f4f0, 
cb=0x7f78447f2e80 <_control_block>, su=0x7f7845d69e60)
at ../../opensaf/src/amf/amfd/sg_2n_fsm.cc:3402
a_susi = 
s_susi = 0x7f7845d69a68
o_su = 
flag = 
__FUNCTION__ = "node_fail"
su_ha_state = 
t_ = {trace_leave_called = false, file_ = 0x0, function_ = 0x0}
#5  0x7f784455de1a in AVD_SG::failover_absent_assignment 
(this=0x7f7845d5f4f0) at ../../opensaf/src/amf/amfd/sg.cc:2307
t_ = {trace_leave_called = false, file_ = 0x0, function_ = 0x0}
__FUNCTION__ = "failover_absent_assignment"
failed_su = 0x7f7845d69e60
#6  0x7f7844514125 in avd_cluster_tmr_init_evh (cb=0x7f78447f2e80 
<_control_block>, evt=)
at ../../opensaf/src/amf/amfd/cluster.cc:103
i_sg = 0x7f7845d5f4f0
__for_range = @0x7f7845ca2a90: {db = {_M_t = {
  _M_impl = 
{ const, AVD_SG*> > >> = 
{<__gnu_cxx::new_allocator const, AVD_SG*> > >> = {}, }, 
_M_key_compare = {, std::basic_string, bool>> = {}, 
}, _M_header = {_M_color = std::_S_red, 
  _M_parent = 0x7f7845d515e0, _M_left = 0x7f7845d03ed0, 
_M_right = 0x7f7845d81580}, _M_node_count = 28
t_ = {trace_leave_called = false, file_ = 0x0, function_ = 0x0}
__FUNCTION__ = "avd_cluster_tmr_init_evh"
su = 0x0
node = 
#7  0x7f784453ca2c in process_event (cb_now=0x7f78447f2e80 
<_control_block>, evt=0x7f78340013d0) at ../../opensaf/src/amf/amfd/main.cc:775
t_ = {trace_leave_called = false, file_ = 0x0, function_ = 0x0}
__FUNCTION__ =