date:20160920

- Description has changed:

Diff:



--- old
+++ new
@@ -4,33 +4,32 @@
 2/ Currently the root directory is "/srv/shared/saflog" . Change new root 
directory:
 immcfg -a logRootDirectory=/srv/shared logConfig=1,safApp=safLogService
 
-*Sep 21 11:02:28.045538 osaflogd [463:lgsutil.cc:0486] TR logsvrootdir 
"/srv/shared/saflog"
-Sep 21 11:02:28.045554 osaflogd [463:lgsutil.cc:0487] TR path "./test"
-Sep 21 11:02:28.045586 osaflogd [463:lgsfilehdl.cc:0341] >> makelogdirhdl
-Sep 21 11:02:28.045604 osaflogd [463:lgsfilehdl.cc:0343] TR rootpath 
"/srv/shared/saflog"
-Sep 21 11:02:28.045621 osaflogd [463:lgsfilehdl.cc:0344] TR relpath "./test"
-Sep 21 11:02:28.045643 osaflogd [463:lgsfilehdl.cc:0368] TR makelogdirhdl - 
Path to create "/srv/shared/saflog/./test/"
-Sep 21 11:02:28.045682 osaflogd [463:lgsfilehdl.cc:0389] TR makelogdirhdl - 
Dir "/srv/shared/saflog/./test/" created
-Sep 21 11:02:28.045701 osaflogd [463:lgsfilehdl.cc:0393] << makelogdirhdl: 
mldhrc = 0
-Sep 21 11:02:28.046676 osaflogd [463:lgsutil.cc:0511] << lgsmakereldirh: rc = 0
-Sep 21 11:02:28.047021 osaflogd [463:lgsutil.cc:0104] TR lgscreateconfigfileh 
- Config file path "/srv/shared/./test/TestApp7.cfg"
-Sep 21 11:02:28.047075 osaflogd [463:lgsfilehdl.cc:0156] >> createconfigfilehdl
-Sep 21 11:02:28.047096 osaflogd [463:lgsfilehdl.cc:0158] TR 
createconfigfilehdl - filepath "/srv/shared/./test/TestApp7.cfg"
-Sep 21 11:02:28.048062 osaflogd [463:lgsfilehdl.cc:0168] NO Could not open 
'/srv/shared/./test/TestApp7.cfg' - No such file or directory
-Sep 21 11:02:28.048192 osaflogd [463:lgsfilehdl.cc:0218] << 
createconfigfilehdl: rc = -1
-Sep 21 11:02:28.048255 osaflogd [463:lgsutil.cc:0165] << lgscreateconfigfileh: 
rc = -1
-Sep 21 11:02:28.049655 osaflogd [463:lgsimm.cc:1868] ER New config file could 
not be created for stream: safLgStrCfg=TestApp7
-Sep 21 11:02:28.049820 osaflogd [463:lgsstream.cc:0667] >> logfileopen
-Sep 21 11:02:28.049847 osaflogd [463:lgsstream.cc:0671] TR logfileopen - 
Opening file "/srv/shared/./test/TestApp720160921110227.log"
-Sep 21 11:02:28.049865 osaflogd [463:lgsstream.cc:0066] >> fileopenh
-Sep 21 11:02:28.049883 osaflogd [463:lgsstream.cc:0082] TR fileopenh - 
filepath "/srv/shared/./test/TestApp720160921110227.log"
-Sep 21 11:02:28.050923 osaflogd [463:lgsfilehdl.cc:0417] >> fileopenhdl
-Sep 21 11:02:28.050993 osaflogd [463:lgsfilehdl.cc:0419] TR fileopenhdl - 
filepath "/srv/shared/./test/TestApp720160921110227.log"
-Sep 21 11:02:28.051185 osaflogd [463:lgsfilehdl.cc:0436] IN Could not open: 
/srv/shared/./test/TestApp720160921110227.log - No such file or directory
-Sep 21 11:02:28.051232 osaflogd [463:lgsfilehdl.cc:0457] << fileopenhdl
-Sep 21 11:02:28.051285 osaflogd [463:lgsstream.cc:0100] << fileopenh
-Sep 21 11:02:28.051314 osaflogd [463:lgsstream.cc:0678] << logfileopen
-Sep 21 11:02:28.051686 osaflogd [463:lgsimm.cc:1878] ER New log file could not 
be created for stream: safLgStrCfg=TestApp7*
-
+Sep 21 11:02:28.045538 osaflogd [463:lgs_util.cc:0486] TR logsv_root_dir 
"/srv/shared/saflog"
+Sep 21 11:02:28.045554 osaflogd [463:lgs_util.cc:0487] TR path "./test"
+Sep 21 11:02:28.045586 osaflogd [463:lgs_filehdl.cc:0341] >> make_log_dir_hdl 
+Sep 21 11:02:28.045604 osaflogd [463:lgs_filehdl.cc:0343] TR rootpath 
"/srv/shared/saflog"
+Sep 21 11:02:28.045621 osaflogd [463:lgs_filehdl.cc:0344] TR relpath "./test"
+Sep 21 11:02:28.045643 osaflogd [463:lgs_filehdl.cc:0368] TR make_log_dir_hdl 
- Path to create "/srv/shared/saflog/./test/"
+Sep 21 11:02:28.045682 osaflogd [463:lgs_filehdl.cc:0389] TR make_log_dir_hdl 
- Dir "/srv/shared/saflog/./test/" created
+Sep 21 11:02:28.045701 osaflogd [463:lgs_filehdl.cc:0393] << make_log_dir_hdl: 
mldh_rc = 0
+Sep 21 11:02:28.046676 osaflogd [463:lgs_util.cc:0511] << lgs_make_reldir_h: 
rc = 0
+Sep 21 11:02:28.047021 osaflogd [463:lgs_util.cc:0104] TR 
lgs_create_config_file_h - Config file path "/srv/shared/./test/TestApp7.cfg"
+Sep 21 11:02:28.047075 osaflogd [463:lgs_filehdl.cc:0156] >> 
create_config_file_hdl 
+Sep 21 11:02:28.047096 osaflogd [463:lgs_filehdl.cc:0158] TR 
create_config_file_hdl - file_path "/srv/shared/./test/TestApp7.cfg"
+Sep 21 11:02:28.048062 osaflogd [463:lgs_filehdl.cc:0168] NO Could not open 
'/srv/shared/./test/TestApp7.cfg' - No such file or directory
+Sep 21 11:02:28.048192 osaflogd [463:lgs_filehdl.cc:0218] << 
create_config_file_hdl: rc = -1
+Sep 21 11:02:28.048255 osaflogd [463:lgs_util.cc:0165] << 
lgs_create_config_file_h: rc = -1
+Sep 21 11:02:28.049655 osaflogd [463:lgs_imm.cc:1868] ER New config file could 
not be created for stream: safLgStrCfg=TestApp7
+Sep 21 11:02:28.049820 osaflogd [463:lgs_stream.cc:0667] >> log_file_open 
+Sep 21 11:02:28.049847 osaflogd [463:lgs_stream.cc:0671] TR log_file_open - 
Opening file "/srv/shared/./test/TestApp7_20160921_110227.log"
+Sep 21 11:02:28.049865 osaflogd [463:lgs_stream.cc:0066] >> fileopen_h 
+Sep 21 11:02:28.049883 osaflogd [463:lgs_stream.cc:0082] TR fileopen_h - 
filepath

[tickets] [opensaf:tickets] #2054 log: creating new directory wrongly when changing new logRootDirectory

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2054] log: creating new directory wrongly when changing new 
logRootDirectory**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Wed Sep 21, 2016 04:18 AM UTC by Canh Truong
**Last Updated:** Wed Sep 21, 2016 04:19 AM UTC
**Owner:** nobody


Step to produce issue:
1/ Create new appstream with pathname: 
immcfg -c SaLogStreamConfig  safLgStrCfg=TestApp7 -a 
saLogStreamPathName=./test -a saLogStreamFileName=TestApp7
2/ Currently the root directory is "/srv/shared/saflog" . Change new root 
directory:
immcfg -a logRootDirectory=/srv/shared logConfig=1,safApp=safLogService

*Sep 21 11:02:28.045538 osaflogd [463:lgsutil.cc:0486] TR logsvrootdir 
"/srv/shared/saflog"
Sep 21 11:02:28.045554 osaflogd [463:lgsutil.cc:0487] TR path "./test"
Sep 21 11:02:28.045586 osaflogd [463:lgsfilehdl.cc:0341] >> makelogdirhdl
Sep 21 11:02:28.045604 osaflogd [463:lgsfilehdl.cc:0343] TR rootpath 
"/srv/shared/saflog"
Sep 21 11:02:28.045621 osaflogd [463:lgsfilehdl.cc:0344] TR relpath "./test"
Sep 21 11:02:28.045643 osaflogd [463:lgsfilehdl.cc:0368] TR makelogdirhdl - 
Path to create "/srv/shared/saflog/./test/"
Sep 21 11:02:28.045682 osaflogd [463:lgsfilehdl.cc:0389] TR makelogdirhdl - Dir 
"/srv/shared/saflog/./test/" created
Sep 21 11:02:28.045701 osaflogd [463:lgsfilehdl.cc:0393] << makelogdirhdl: 
mldhrc = 0
Sep 21 11:02:28.046676 osaflogd [463:lgsutil.cc:0511] << lgsmakereldirh: rc = 0
Sep 21 11:02:28.047021 osaflogd [463:lgsutil.cc:0104] TR lgscreateconfigfileh - 
Config file path "/srv/shared/./test/TestApp7.cfg"
Sep 21 11:02:28.047075 osaflogd [463:lgsfilehdl.cc:0156] >> createconfigfilehdl
Sep 21 11:02:28.047096 osaflogd [463:lgsfilehdl.cc:0158] TR createconfigfilehdl 
- filepath "/srv/shared/./test/TestApp7.cfg"
Sep 21 11:02:28.048062 osaflogd [463:lgsfilehdl.cc:0168] NO Could not open 
'/srv/shared/./test/TestApp7.cfg' - No such file or directory
Sep 21 11:02:28.048192 osaflogd [463:lgsfilehdl.cc:0218] << 
createconfigfilehdl: rc = -1
Sep 21 11:02:28.048255 osaflogd [463:lgsutil.cc:0165] << lgscreateconfigfileh: 
rc = -1
Sep 21 11:02:28.049655 osaflogd [463:lgsimm.cc:1868] ER New config file could 
not be created for stream: safLgStrCfg=TestApp7
Sep 21 11:02:28.049820 osaflogd [463:lgsstream.cc:0667] >> logfileopen
Sep 21 11:02:28.049847 osaflogd [463:lgsstream.cc:0671] TR logfileopen - 
Opening file "/srv/shared/./test/TestApp720160921110227.log"
Sep 21 11:02:28.049865 osaflogd [463:lgsstream.cc:0066] >> fileopenh
Sep 21 11:02:28.049883 osaflogd [463:lgsstream.cc:0082] TR fileopenh - filepath 
"/srv/shared/./test/TestApp720160921110227.log"
Sep 21 11:02:28.050923 osaflogd [463:lgsfilehdl.cc:0417] >> fileopenhdl
Sep 21 11:02:28.050993 osaflogd [463:lgsfilehdl.cc:0419] TR fileopenhdl - 
filepath "/srv/shared/./test/TestApp720160921110227.log"
Sep 21 11:02:28.051185 osaflogd [463:lgsfilehdl.cc:0436] IN Could not open: 
/srv/shared/./test/TestApp720160921110227.log - No such file or directory
Sep 21 11:02:28.051232 osaflogd [463:lgsfilehdl.cc:0457] << fileopenhdl
Sep 21 11:02:28.051285 osaflogd [463:lgsstream.cc:0100] << fileopenh
Sep 21 11:02:28.051314 osaflogd [463:lgsstream.cc:0678] << logfileopen
Sep 21 11:02:28.051686 osaflogd [463:lgsimm.cc:1878] ER New log file could not 
be created for stream: safLgStrCfg=TestApp7*


The new directory is created then creating new log/cfg file in there. But lgsv 
uses old root directory and pathname to create new directory. So actually the 
new directory is not created.


---

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] #2054 log: creating new directory wrongly when changing new logRootDirectory

- Description has changed:

Diff:



--- old
+++ new
@@ -1,7 +1,7 @@
 Step to produce issue:
 1/ Create new appstream with pathname: 
 immcfg -c SaLogStreamConfig  safLgStrCfg=TestApp7 -a 
saLogStreamPathName=./test -a saLogStreamFileName=TestApp7
-2/ Currently the root directory is "/srv/shared/saflog" . Chang new root 
directory:
+2/ Currently the root directory is "/srv/shared/saflog" . Change new root 
directory:
 immcfg -a logRootDirectory=/srv/shared logConfig=1,safApp=safLogService
 
 *Sep 21 11:02:28.045538 osaflogd [463:lgsutil.cc:0486] TR logsvrootdir 
"/srv/shared/saflog"






---

** [tickets:#2054] log: creating new directory wrongly when changing new 
logRootDirectory**

**Status:** unassigned
**Milestone:** 4.7.2
**Created:** Wed Sep 21, 2016 04:18 AM UTC by Canh Truong
**Last Updated:** Wed Sep 21, 2016 04:18 AM UTC
**Owner:** nobody


Step to produce issue:
1/ Create new appstream with pathname: 
immcfg -c SaLogStreamConfig  safLgStrCfg=TestApp7 -a 
saLogStreamPathName=./test -a saLogStreamFileName=TestApp7
2/ Currently the root directory is "/srv/shared/saflog" . Change new root 
directory:
immcfg -a logRootDirectory=/srv/shared logConfig=1,safApp=safLogService

*Sep 21 11:02:28.045538 osaflogd [463:lgsutil.cc:0486] TR logsvrootdir 
"/srv/shared/saflog"
Sep 21 11:02:28.045554 osaflogd [463:lgsutil.cc:0487] TR path "./test"
Sep 21 11:02:28.045586 osaflogd [463:lgsfilehdl.cc:0341] >> makelogdirhdl
Sep 21 11:02:28.045604 osaflogd [463:lgsfilehdl.cc:0343] TR rootpath 
"/srv/shared/saflog"
Sep 21 11:02:28.045621 osaflogd [463:lgsfilehdl.cc:0344] TR relpath "./test"
Sep 21 11:02:28.045643 osaflogd [463:lgsfilehdl.cc:0368] TR makelogdirhdl - 
Path to create "/srv/shared/saflog/./test/"
Sep 21 11:02:28.045682 osaflogd [463:lgsfilehdl.cc:0389] TR makelogdirhdl - Dir 
"/srv/shared/saflog/./test/" created
Sep 21 11:02:28.045701 osaflogd [463:lgsfilehdl.cc:0393] << makelogdirhdl: 
mldhrc = 0
Sep 21 11:02:28.046676 osaflogd [463:lgsutil.cc:0511] << lgsmakereldirh: rc = 0
Sep 21 11:02:28.047021 osaflogd [463:lgsutil.cc:0104] TR lgscreateconfigfileh - 
Config file path "/srv/shared/./test/TestApp7.cfg"
Sep 21 11:02:28.047075 osaflogd [463:lgsfilehdl.cc:0156] >> createconfigfilehdl
Sep 21 11:02:28.047096 osaflogd [463:lgsfilehdl.cc:0158] TR createconfigfilehdl 
- filepath "/srv/shared/./test/TestApp7.cfg"
Sep 21 11:02:28.048062 osaflogd [463:lgsfilehdl.cc:0168] NO Could not open 
'/srv/shared/./test/TestApp7.cfg' - No such file or directory
Sep 21 11:02:28.048192 osaflogd [463:lgsfilehdl.cc:0218] << 
createconfigfilehdl: rc = -1
Sep 21 11:02:28.048255 osaflogd [463:lgsutil.cc:0165] << lgscreateconfigfileh: 
rc = -1
Sep 21 11:02:28.049655 osaflogd [463:lgsimm.cc:1868] ER New config file could 
not be created for stream: safLgStrCfg=TestApp7
Sep 21 11:02:28.049820 osaflogd [463:lgsstream.cc:0667] >> logfileopen
Sep 21 11:02:28.049847 osaflogd [463:lgsstream.cc:0671] TR logfileopen - 
Opening file "/srv/shared/./test/TestApp720160921110227.log"
Sep 21 11:02:28.049865 osaflogd [463:lgsstream.cc:0066] >> fileopenh
Sep 21 11:02:28.049883 osaflogd [463:lgsstream.cc:0082] TR fileopenh - filepath 
"/srv/shared/./test/TestApp720160921110227.log"
Sep 21 11:02:28.050923 osaflogd [463:lgsfilehdl.cc:0417] >> fileopenhdl
Sep 21 11:02:28.050993 osaflogd [463:lgsfilehdl.cc:0419] TR fileopenhdl - 
filepath "/srv/shared/./test/TestApp720160921110227.log"
Sep 21 11:02:28.051185 osaflogd [463:lgsfilehdl.cc:0436] IN Could not open: 
/srv/shared/./test/TestApp720160921110227.log - No such file or directory
Sep 21 11:02:28.051232 osaflogd [463:lgsfilehdl.cc:0457] << fileopenhdl
Sep 21 11:02:28.051285 osaflogd [463:lgsstream.cc:0100] << fileopenh
Sep 21 11:02:28.051314 osaflogd [463:lgsstream.cc:0678] << logfileopen
Sep 21 11:02:28.051686 osaflogd [463:lgsimm.cc:1878] ER New log file could not 
be created for stream: safLgStrCfg=TestApp7*


The new directory is created then creating new log/cfg file in there. But lgsv 
uses old root directory and pathname to create new directory. So actually the 
new directory is not created.


---

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] #2054 log: creating new directory wrongly when changing new logRootDirectory




---

** [tickets:#2054] log: creating new directory wrongly when changing new 
logRootDirectory**

**Status:** unassigned
**Milestone:** 4.7.2
**Created:** Wed Sep 21, 2016 04:18 AM UTC by Canh Truong
**Last Updated:** Wed Sep 21, 2016 04:18 AM UTC
**Owner:** nobody


Step to produce issue:
1/ Create new appstream with pathname: 
immcfg -c SaLogStreamConfig  safLgStrCfg=TestApp7 -a 
saLogStreamPathName=./test -a saLogStreamFileName=TestApp7
2/ Currently the root directory is "/srv/shared/saflog" . Chang new root 
directory:
immcfg -a logRootDirectory=/srv/shared logConfig=1,safApp=safLogService

*Sep 21 11:02:28.045538 osaflogd [463:lgsutil.cc:0486] TR logsvrootdir 
"/srv/shared/saflog"
Sep 21 11:02:28.045554 osaflogd [463:lgsutil.cc:0487] TR path "./test"
Sep 21 11:02:28.045586 osaflogd [463:lgsfilehdl.cc:0341] >> makelogdirhdl
Sep 21 11:02:28.045604 osaflogd [463:lgsfilehdl.cc:0343] TR rootpath 
"/srv/shared/saflog"
Sep 21 11:02:28.045621 osaflogd [463:lgsfilehdl.cc:0344] TR relpath "./test"
Sep 21 11:02:28.045643 osaflogd [463:lgsfilehdl.cc:0368] TR makelogdirhdl - 
Path to create "/srv/shared/saflog/./test/"
Sep 21 11:02:28.045682 osaflogd [463:lgsfilehdl.cc:0389] TR makelogdirhdl - Dir 
"/srv/shared/saflog/./test/" created
Sep 21 11:02:28.045701 osaflogd [463:lgsfilehdl.cc:0393] << makelogdirhdl: 
mldhrc = 0
Sep 21 11:02:28.046676 osaflogd [463:lgsutil.cc:0511] << lgsmakereldirh: rc = 0
Sep 21 11:02:28.047021 osaflogd [463:lgsutil.cc:0104] TR lgscreateconfigfileh - 
Config file path "/srv/shared/./test/TestApp7.cfg"
Sep 21 11:02:28.047075 osaflogd [463:lgsfilehdl.cc:0156] >> createconfigfilehdl
Sep 21 11:02:28.047096 osaflogd [463:lgsfilehdl.cc:0158] TR createconfigfilehdl 
- filepath "/srv/shared/./test/TestApp7.cfg"
Sep 21 11:02:28.048062 osaflogd [463:lgsfilehdl.cc:0168] NO Could not open 
'/srv/shared/./test/TestApp7.cfg' - No such file or directory
Sep 21 11:02:28.048192 osaflogd [463:lgsfilehdl.cc:0218] << 
createconfigfilehdl: rc = -1
Sep 21 11:02:28.048255 osaflogd [463:lgsutil.cc:0165] << lgscreateconfigfileh: 
rc = -1
Sep 21 11:02:28.049655 osaflogd [463:lgsimm.cc:1868] ER New config file could 
not be created for stream: safLgStrCfg=TestApp7
Sep 21 11:02:28.049820 osaflogd [463:lgsstream.cc:0667] >> logfileopen
Sep 21 11:02:28.049847 osaflogd [463:lgsstream.cc:0671] TR logfileopen - 
Opening file "/srv/shared/./test/TestApp720160921110227.log"
Sep 21 11:02:28.049865 osaflogd [463:lgsstream.cc:0066] >> fileopenh
Sep 21 11:02:28.049883 osaflogd [463:lgsstream.cc:0082] TR fileopenh - filepath 
"/srv/shared/./test/TestApp720160921110227.log"
Sep 21 11:02:28.050923 osaflogd [463:lgsfilehdl.cc:0417] >> fileopenhdl
Sep 21 11:02:28.050993 osaflogd [463:lgsfilehdl.cc:0419] TR fileopenhdl - 
filepath "/srv/shared/./test/TestApp720160921110227.log"
Sep 21 11:02:28.051185 osaflogd [463:lgsfilehdl.cc:0436] IN Could not open: 
/srv/shared/./test/TestApp720160921110227.log - No such file or directory
Sep 21 11:02:28.051232 osaflogd [463:lgsfilehdl.cc:0457] << fileopenhdl
Sep 21 11:02:28.051285 osaflogd [463:lgsstream.cc:0100] << fileopenh
Sep 21 11:02:28.051314 osaflogd [463:lgsstream.cc:0678] << logfileopen
Sep 21 11:02:28.051686 osaflogd [463:lgsimm.cc:1878] ER New log file could not 
be created for stream: safLgStrCfg=TestApp7*


The new directory is created then creating new log/cfg file in there. But lgsv 
uses old root directory and pathname to create new directory. So actually the 
new directory is not created.


---

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] #1890 Doc : Headless feature documentation

2016-09-20 Thread Minh Hon Chau

Hi Mathi,

IMM has updated the README with formal naming for headless feature as the term 
of SC Absence:
. Rename README[]HEADLESS as README.SC_ABSENCE
. Replace *Headless* by *SC absence* in content of readme

I think we could follow it, do you agree?

Thanks,
Minh


---

** [tickets:#1890] Doc : Headless feature documentation **

**Status:** accepted
**Milestone:** 5.1.0
**Created:** Tue Jun 21, 2016 11:02 AM UTC by Srikanth R
**Last Updated:** Tue Sep 20, 2016 05:36 PM UTC
**Owner:** Mathi Naickan


Version : Opensaf 5.0. GA


 1) Documentation about headless feature should be updated in 
Opensaf_Overview_PR.odt / Opensaf_Extentsions. The documentation should list 
out services which provide functionality, when the cluster goes headless.
  
 2) The  README.HYDRA file in the ntfsv folder should be renamed to 
README.HEADLESS for uniformity in naming the files across all the folders.
 
 3) CLM folder doesn't have README for the headless feature.
 
 4) The headless files across all folders should have same naming convention.

./osaf/services/saf/amf/README_HEADLESS
./osaf/services/saf/logsv/README-HEADLESS
./osaf/services/saf/cpsv/README.HEADLESS





---

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] #1897 Incorrect ER messages in syslog

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1897] Incorrect ER messages in syslog**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Tue Jun 28, 2016 07:51 AM UTC by elunlen
**Last Updated:** Tue Jun 28, 2016 07:51 AM UTC
**Owner:** nobody


Several incorrectly prioritized syslog messages found in SG_2N::si_swap in 
sg_2n_fsm.cc
LOG_ER is used when problem is easily recoverable e.g. return value is 
SA_AIS_ERR_TRY_AGAIN


---

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] #1919 amf: Improper lock operation sequence in NpM model.

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1919] amf: Improper lock operation sequence in NpM model.**

**Status:** unassigned
**Milestone:** 5.0.2
**Labels:** NpM 
**Created:** Mon Jul 18, 2016 11:32 AM UTC by Praveen
**Last Updated:** Mon Jul 18, 2016 11:32 AM UTC
**Owner:** nobody
**Attachments:**

- [npm.tgz](https://sourceforge.net/p/opensaf/tickets/1919/attachment/npm.tgz) 
(15.2 kB; application/x-compressed)


In Npm Model lock operation sequence is inconsistent with what is mentioned in 
AMF spec section 10.5.
Here is the sequence of events based on AMF traces for lock operation on SU:
1) AMFD sends quiesced:
 Jul 13 14:51:40.651539 osafamfd [10039:sgproc.cc:2231] >> 
avd_sg_su_si_mod_snd: 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1', state 3
Jul 13 14:51:40.651547 osafamfd [10039:mbcsv_api.c:0773] >> 
mbcsv_process_snd_ckpt_request: Sending checkpoint data to all STANDBY p
2) Quiesced respnse comes:
Jul 13 14:51:40.655170 osafamfd [10039:sgproc.cc:1051] >> avd_su_si_assign_evh: 
id:101, node:2010f, act:5, 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1', '', ha:3, 
err:1, single:0
3) Now AMFD sends active to standby SU and deletion to quiesced SU 
simultaneously:
Jul 13 14:51:40.655335 osafamfd [10039:sg_npm_fsm.cc:2338] << 
avd_sg_get_curr_act_cnt: current Active SUs :0
Jul 13 14:51:40.655342 osafamfd [10039:sgproc.cc:2231] >> avd_sg_su_si_mod_snd: 
'safSu=SU2,safSg=AmfDemo,safApp=AmfDemo1', state 1

Jul 13 14:51:40.655707 osafamfd [10039:sg_npm_fsm.cc:2455] << 
avd_sg_npm_stdbysu_role_change
Jul 13 14:51:40.655714 osafamfd [10039:sgproc.cc:2340] >> avd_sg_su_si_del_snd: 
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 
4)Deletion should be sent after receiving successful active response from SU2. 

Generally SUs are hosted on different nodes,so problem could not be noticed 
easily. But hosting both the SUs on same node shows it clearly in syslog itself:
Jul 13 14:51:40 SC-1 osafamfnd[10049]: NO Assigning 
'safSi=AmfDemo,safApp=AmfDemo1' QUIESCED to 
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 amf_demo[10268]: =CSI SET>
Jul 13 14:51:40 SC-1 amf_demo[10268]: 
Comp>:'safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 amf_demo[10268]: CSI FLAG->:SA_AMF_CSI_TARGET_ALL(4)
Jul 13 14:51:40 SC-1 amf_demo[10268]: HAState>:Quiesced
Jul 13 14:51:40 SC-1 amf_demo[10268]: <
Jul 13 14:51:40 SC-1 osafamfnd[10049]: NO Assigned 
'safSi=AmfDemo,safApp=AmfDemo1' QUIESCED to 
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 osafamfnd[10049]: NO Assigning 
'safSi=AmfDemo,safApp=AmfDemo1' ACTIVE to 
'safSu=SU2,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 amf_demo[10290]: =CSI SET>
Jul 13 14:51:40 SC-1 amf_demo[10290]: 
Comp>:'safComp=AmfDemo,safSu=SU2,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 amf_demo[10290]: CSI FLAG->:SA_AMF_CSI_TARGET_ALL(4)
Jul 13 14:51:40 SC-1 amf_demo[10290]: HAState>:Active
Jul 13 14:51:40 SC-1 amf_demo[10290]: transitionDescriptor: 
SA_AMF_CSI_NEW_ASSIGN
Jul 13 14:51:40 SC-1 amf_demo[10290]: activeCompName:
Jul 13 14:51:40 SC-1 amf_demo[10290]: <
Jul 13 14:51:40 SC-1 osafamfnd[10049]: NO Removing 
'safSi=AmfDemo,safApp=AmfDemo1' from 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 amf_demo[10268]: >CSI Remove=>
Jul 13 14:51:40 SC-1 amf_demo[10268]: 
Comp>:'safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 amf_demo[10268]: CSI FLAG --->: 
SA_AMF_CSI_TARGET_ALL
Jul 13 14:51:40 SC-1 amf_demo[10268]: <===
Jul 13 14:51:40 SC-1 osafamfnd[10049]: NO Removed 
'safSi=AmfDemo,safApp=AmfDemo1' from 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 amf_demo[10268]: saAmfResponse after lopp- 1
Jul 13 14:51:41 SC-1 amf_demo[10290]: Waiting for the flag being set
Jul 13 14:51:41 SC-1 osafamfnd[10049]: NO Assigned 
'safSi=AmfDemo,safApp=AmfDemo1' ACTIVE to 
'safSu=SU2,safSg=AmfDemo,safApp=AmfDemo1'

So removal compelted in SU1 even before SU2 becomes active.

Valid for lock/shutdown operation on Node, SU and with  #1454 it will be valid 
for lock/shutdown on NG also. Will check for lock operatiion on SI.

Attached are traces and configuration.




---

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] #1895 ntf: ER in syslog: ER NtfAdmin::subscriptionRemoved client 12 not found

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1895] ntf: ER in syslog: ER NtfAdmin::subscriptionRemoved client 
12 not found**

**Status:** accepted
**Milestone:** 5.0.2
**Created:** Fri Jun 24, 2016 03:24 AM UTC by Vo Minh Hoang
**Last Updated:** Thu Sep 15, 2016 04:15 AM UTC
**Owner:** Canh Truong
**Attachments:**

- 
[1895.tgz](https://sourceforge.net/p/opensaf/tickets/1895/attachment/1895.tgz) 
(471.5 kB; application/x-compressed)


Failed when run test suit 2: 

Sep 15 11:13:41.191010 osafntfd [476:mds_dt_trans.c:0608] >> 
mdtm_process_poll_recv_data_tcp 
Sep 15 11:13:41.191034 osafntfd [476:mbcsv_mds.c:0244] << mbcsv_mds_send_msg: 
success
Sep 15 11:13:41.191038 osafntfd [476:mbcsv_util.c:0492] << 
mbcsv_send_ckpt_data_to_all_peers 
Sep 15 11:13:41.191041 osafntfd [476:mbcsv_api.c:0868] << 
mbcsv_process_snd_ckpt_request: retval: 1
Sep 15 11:13:41.191044 osafntfd [476:ntfs_mbcsv.c:1365] << 
ntfs_send_async_update 
Sep 15 11:13:41.191047 osafntfd [476:ntfs_com.c:0093] << client_removed_res_lib 
Sep 15 11:13:41.191049 osafntfd [476:ntfs_evt.c:0304] << proc_finalize_msg 
Sep 15 11:13:41.191055 osafntfd [476:ntfs_evt.c:0357] >> proc_unsubscribe_msg: 
client_id 8, subscriptionId 111
Sep 15 11:13:41.191140 osafntfd [476:NtfAdmin.cc:0520] ER 
NtfAdmin::subscriptionRemoved client 8 not found
Sep 15 11:13:41.191146 osafntfd [476:ntfs_evt.c:0369] << proc_unsubscribe_msg 

The issue here is when test case 4 of test suit2 is executed, the unsubcribe 
and Finalize is runing in parallel. Ntfd receive API request from Finalize 
before unsubcribe, so client and all of relating to its will be removed before 
ntfd process request from ubsubcribe. 
The error is printed out in this case. And unsubcribe action is failed. But in 
the test case the return code is re-assigned to ok for test case passed.

The step in test case to call API in ntf may be wrong.

Similiar ticket: https://sourceforge.net/p/opensaf/tickets/1818/


---

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] #1920 amf: issues related faults during shutdown operation in NpM Model.

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1920] amf: issues related faults during shutdown operation in NpM 
Model.**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Tue Jul 19, 2016 10:38 AM UTC by Praveen
**Last Updated:** Tue Jul 19, 2016 10:38 AM UTC
**Owner:** nobody
**Attachments:**

- 
[1454_NpM.xml_1SI_2Comps_1plus1](https://sourceforge.net/p/opensaf/tickets/1920/attachment/1454_NpM.xml_1SI_2Comps_1plus1)
 (10.5 kB; application/octet-stream)
- 
[1454_NpM.xml_2SI_2plus2](https://sourceforge.net/p/opensaf/tickets/1920/attachment/1454_NpM.xml_2SI_2plus2)
 (13.3 kB; application/octet-stream)
- 
[issue1.tgz](https://sourceforge.net/p/opensaf/tickets/1920/attachment/issue1.tgz)
 (88.0 kB; application/x-compressed)
- 
[issue2.tgz](https://sourceforge.net/p/opensaf/tickets/1920/attachment/issue2.tgz)
 (31.7 kB; application/x-compressed)


Observed two issues related to shutdown opreation on SU1. Issues will be valid 
for shutdown on Node also.

Steps to reproduce:
1)Bring attached configuration(s) up.
2)Issue shutdown operation on active SU and make sure one comp faults with 
comp-failover recovery while processing quiescing callback.
3)observed two issues:
-In one issue: AMFD switchovers faulted SU when comps in faulted SU are 
still processing quiesced assignment.
-In second issue: AMFND is gets stuck in Terminating state and sg remained 
in unstable state.


 AMFD events in issue1:
1)Shutdown of SU1, AMFD sends quiescing state:
Jul 19 12:41:05.81 osafamfd [8965:sgproc.cc:2231] >> avd_sg_su_si_mod_snd: 
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1', state 4
2)Comp faults with comp-failover recovery while handling quiescing state. After 
cleanup AMFD get
recovery request:
Jul 19 12:41:25.636739 osafamfd [8965:sgproc.cc:0655] >> avd_su_oper_state_evh: 
id:229, node:2010f, 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1' state:2
AMFD sends quiesced state for remaining comp and failed comp:
Jul 19 12:41:25.640935 osafamfd [8965:sg_npm_fsm.cc:1417] >> su_fault: 2
Jul 19 12:41:25.640947 osafamfd [8965:sgproc.cc:2231] >> avd_sg_su_si_mod_snd: 
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1', state 3

3)AMFD gets quiescing state response:
Jul 19 12:41:25.655939 osafamfd [8965:sgproc.cc:1051] >> avd_su_si_assign_evh: 
id:230, node:2010f, act:5, 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1', '', ha:3, 
err:1, single:0
It sends Active HA state to SU3:
Jul 19 12:41:25.656835 osafamfd [8965:sgproc.cc:2231] >> avd_sg_su_si_mod_snd: 
'safSu=SU3,safSg=AmfDemo,safApp=AmfDemo1', state 1
and sends delete to SU1:
Jul 19 12:41:25.660426 osafamfd [8965:sgproc.cc:2340] >> avd_sg_su_si_del_snd: 
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'

4)AMFD gets quiesced response for SU1:
Jul 19 12:41:25.675860 osafamfd [8965:sgproc.cc:1051] >> avd_su_si_assign_evh: 
id:232, node:2010f, act:5, 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1', '', ha:3, 
err:1, single:0
It sends delete again to SU1:
Jul 19 12:41:25.676132 osafamfd [8965:sgproc.cc:2340] >> avd_sg_su_si_del_snd: 
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
5)Delete response of SU1:
Jul 19 12:41:25.679196 osafamfd [8965:sgproc.cc:1051] >> avd_su_si_assign_evh: 
id:233, node:2010f, act:4, 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1', '', ha:3, 
err:1, single:0

6)Active response for SU3:
Jul 19 12:41:25.686997 osafamfd [8965:sgproc.cc:1051] >> avd_su_si_assign_evh: 
id:139, node:2020f, act:5, 'safSu=SU3,safSg=AmfDemo,safApp=AmfDemo1', '', ha:1, 
err:1, single:0
Problems in this case are:
-AMFD sends active to SU3 while SU1 is still getting quiesced.
-AMFD sends 2 times deletion of assignment to SU1

Attached are AMFD and AMFND traces for both issues.




---

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] #1934 amf: amfd fail-overs su to failed node during node-switchover recovery.

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1934] amf: amfd fail-overs su to failed node during 
node-switchover recovery. **

**Status:** review
**Milestone:** 5.0.2
**Created:** Thu Aug 04, 2016 11:46 AM UTC by Praveen
**Last Updated:** Fri Aug 26, 2016 12:54 PM UTC
**Owner:** Praveen
**Attachments:**

- 
[nodeswitch.xml](https://sourceforge.net/p/opensaf/tickets/1934/attachment/nodeswitch.xml)
 (11.1 kB; text/xml)


Conf: 
Two SUs hosted on standby controller with 2N model. Recovery is 
node-switchover with su-failover flag enabled for SU1.

Steps to reproduce:
1)Bring attached configuration up. 
2) kill comp in SU1(active SU).

When AMFD gets recovery request for standby SC, it failovers SU1 and gives 
active to SU2 as a part of SU1 recovery. For SU2 recovery, it then sends 
quiesced assignment. This is a wrong sequence. Since SU2 is hosted on failed 
node, AMFD should not failover SU1 to SU2,

>From code perpective: AMFD marks all SUs of failed node OOS only in INIT_DONE 
>state. In APP_STATE this needs to be done by respective reocovery funtion. In 
>case of node-failvoer recovery avd_node_down_appl_susi_failover() is marking 
>SUs OOS before performing failover. But perform_nodeswitchover_recovery() is 
>not marking all the SUs OOS before performing failover/switchover of any SU.



---

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] #1928 amfd: admin ops return with SA_AIS_ERR_TIMEOUT

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1928] amfd: admin ops return with SA_AIS_ERR_TIMEOUT**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Fri Jul 22, 2016 06:12 AM UTC by Gary Lee
**Last Updated:** Fri Jul 22, 2016 06:12 AM UTC
**Owner:** nobody


Sometimes IMM can take a long time when AMFD updates persistent runtime 
attributes. During this period, if an admin op is issued towards AMFD, AMFD 
will not be able to respond and the admin op results in TIMEOUT. Furthermore, 
IMM marks AMFD's OI handle as BAD.

2016-07-04 17:39:50 SC-1 osafimmnd[436]: WA ERR_BAD_HANDLE: Client 120259215631 
not found in server

We probably need to create a thread in AMFD whose job is to update runtime 
attributes.


---

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] #1935 amfnd: amfnd is not resetting escalations params.

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1935] amfnd: amfnd is not resetting escalations params.**

**Status:** review
**Milestone:** 5.0.2
**Created:** Thu Aug 04, 2016 12:51 PM UTC by Praveen
**Last Updated:** Fri Sep 02, 2016 05:36 AM UTC
**Owner:** Praveen
**Attachments:**

- 
[add_su.xml](https://sourceforge.net/p/opensaf/tickets/1935/attachment/add_su.xml)
 (2.4 kB; text/xml)
- 
[messages](https://sourceforge.net/p/opensaf/tickets/1935/attachment/messages) 
(79.5 kB; application/octet-stream)
- 
[nodeswitch.xml](https://sourceforge.net/p/opensaf/tickets/1935/attachment/nodeswitch.xml)
 (9.5 kB; text/xml)
- 
[osafamfd](https://sourceforge.net/p/opensaf/tickets/1935/attachment/osafamfd) 
(11.0 MB; application/octet-stream)
- 
[osafamfnd](https://sourceforge.net/p/opensaf/tickets/1935/attachment/osafamfnd)
 (3.7 MB; application/octet-stream)


When AMFND sends node-switchover recovery request to AMFD, it performs 
failover/switchover of SUs on the failed node. After removal of assignments of 
all application SUs on the failed node. AMFD reboots the node if NodeAutoRepair 
is enabled. 
Consider the case when NodeAutoRepair is not enabled. In this case, AMFD will 
node reboot the failed node. 
So this failed node is present and in repair pending state. Now a user perfoms 
floowing operations:
1)Deletes the failed SU from the failed node along with the comps after lock 
and lock-in the SU. 
2)Adds agains same SU and comp
3)Performs unlock-in operations.
Because of unlock-in operation, AMFND at failed node will instantiate the SU. 
This will act as trigger and AMFND in avnd_su_pres_fsm_run() will try to inform 
for node-switchover again since AMFND has not clear some global variables 
related to escalation. Here AMFND may crash. In once case crash was observed 
and in another case, AMFND was successful to send to AMFD recovery request 
again.
In the crashed case, AMFND is accessing illegal memory. 
In successful case SU had got same address :
Aug  4 17:42:13.658513 osafamfnd [14409:susm.cc:1412] NO Informing director of 
Nodeswitchover
Aug  4 17:42:13.658519 osafamfnd [14409:di.cc:0724] >> avnd_di_oper_send: SU 
'0x2534350', recv '4'
Aug  4 17:42:13.658525 osafamfnd [14409:di.cc:0737] TR SU 
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1, su oper '2'

Aug  4 17:42:58.449067 osafamfnd [14409:susm.cc:1412] NO Informing director of 
Nodeswitchover
Aug  4 17:42:58.449080 osafamfnd [14409:di.cc:0724] >> avnd_di_oper_send: SU 
'0x2534350', recv '4'
Aug  4 17:42:58.449093 osafamfnd [14409:di.cc:0737] TR SU 
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1, su oper '1'

Attached is the configuration and traces, steps to reproduce:
1)Bring up the configuration by disabling nodeautorepair flag.
2)Kill comp in SU1.
3)Lock and lock-in the SU and the delete it.
4)Now add su again by using the attached add_su.xml.
5)Unlock-in the SU.




---

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] #1939 2N SG unstable after failover while locking SI

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1939] 2N SG unstable after failover while locking SI**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Tue Aug 09, 2016 03:49 AM UTC by Minh Hon Chau
**Last Updated:** Tue Aug 09, 2016 03:50 AM UTC
**Owner:** nobody
**Attachments:**

- [48.tgz](https://sourceforge.net/p/opensaf/tickets/1939/attachment/48.tgz) 
(807.2 kB; application/x-compressed)


Configuration:  
2N SG, SU4 hosted on PL4, SU5 hosted on PL5, spare SU5B hosted on PL5
1 comp per SU
3 SI(s), each CSI for per SI
No SI dependency

Steps:
Lock SI
delay csi REMOVE cbk in SU4
reboot PL4
release csi REMOVE cbk
unlock SI

Observation:
Can not unlock SI, with following error in amfd trace
Aug  9 11:02:34.440761 osafamfd [494:si.cc:0799] >> si_admin_op_cb: 
safSi=AmfDemoTwon,safApp=AmfDemoTwon op=1
Aug  9 11:02:34.440768 osafamfd [494:imm.cc:1998] >> report_admin_op_error: 
inv:115964116993, res:6, Error String: 'SI unlock of 
safSi=AmfDemoTwon,safApp=AmfDemoTwon failed, SG not stable'


---

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] #1940 Su operation fails due to unclear node admin operation in failover

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1940] Su operation fails due to unclear node admin operation in 
failover**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Tue Aug 09, 2016 04:07 AM UTC by Minh Hon Chau
**Last Updated:** Tue Aug 09, 2016 04:08 AM UTC
**Owner:** nobody
**Attachments:**

- [153.tgz](https://sourceforge.net/p/opensaf/tickets/1940/attachment/153.tgz) 
(820.9 kB; application/x-compressed)


Configuration:
2N SG, SU4 hosted on PL4, SU5 hosted on PL5, spare SU5B hosted on PL5
1 comp per SU
3 SI(s), each CSI for per SI
No SI dependency

Steps:
Bring 2N model up, SU4 has active assignment, SU5 has standby assignment
Lock PL5
Unlock PL5
delay csi STANDBY cbk in SU5
reboot PL4
release csi STANDBY cbk
Lock SU5

Observation:
Fail to lock SU5 with following error in amfd trace
Aug  9 14:03:13.521216 osafamfd [490:su.cc:1159] >> su_admin_op_cb: 
124554051585, 'safSu=SU5,safSg=AmfDemoTwon,safApp=AmfDemoTwon', 2
Aug  9 14:03:13.521308 osafamfd [490:imm.cc:1940] >> report_admin_op_error: 
inv:124554051585, res:6, Error String: 
'Node'safAmfNode=PL-5,safAmfCluster=myAmfCluster' hosting 
SU'safSu=SU5,safSg=AmfDemoTwon,safApp=AmfDemoTwon', undergoing admin 
operation'1''



---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1944 amf: two actives for same SI after sufailover recovery during su lock/shutdown, NWAY.

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1944] amf: two actives for same SI after sufailover recovery 
during su lock/shutdown, NWAY.**

**Status:** accepted
**Milestone:** 5.0.2
**Created:** Tue Aug 09, 2016 09:23 AM UTC by Praveen
**Last Updated:** Tue Aug 09, 2016 09:24 AM UTC
**Owner:** Praveen
**Attachments:**

- 
[two_actives.tgz](https://sourceforge.net/p/opensaf/tickets/1944/attachment/two_actives.tgz)
 (69.1 kB; application/x-compressed)


Attached are traces and conf.

steps to reproduce:
1)Bring the configuration up.
2)Lock active SU.
3)While processing remove callback, one comp must fault sufailover recovery.
4)Amf will make Su3 also active for both the SIs when Su2 is already make 
active after quiesced assignments.

Assignments before su lock
safSISU=safSu=SU2\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo,safApp=AmfDemo1
saAmfSISUHAState=STANDBY(2)
safSISU=safSu=SU2\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1
saAmfSISUHAState=STANDBY(2)
safSISU=safSu=SU3\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo,safApp=AmfDemo1
saAmfSISUHAState=STANDBY(2)
safSISU=safSu=SU3\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1
saAmfSISUHAState=STANDBY(2)
safSISU=safSu=SU1\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo,safApp=AmfDemo1
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SU1\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1
saAmfSISUHAState=ACTIVE(1)

Assignments after SU lock:
safSISU=safSu=SU2\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo,safApp=AmfDemo1
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SU2\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SU3\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo,safApp=AmfDemo1
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SU3\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1
saAmfSISUHAState=ACTIVE(1)

Issue will be applicable to Nore lock/shutdown also.


---

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] #1950 Amf: cleanup command is called during termination after health check failure

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1950] Amf: cleanup command is called during termination after 
health check failure**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Fri Aug 12, 2016 09:38 AM UTC by Nagendra Kumar
**Last Updated:** Wed Aug 17, 2016 10:27 AM UTC
**Owner:** nobody


Steps to reproduce
--
When NPI component is in termination state and health check also running 
concurrently, then there is rare chance that health check may return failure 
because of inability of component to respond during termination.
In such case, after healtch check(HC) reported failure, Amf is sending the 
cleanup command to the component.

Observed behaviour
   --
During cleanup command, there may be contention of resources and there are fair 
chances that cleanup command uses fiorceful termination of component resulting 
in generating core dump.

Expected behaviour
--
The expected behavious can be either of :
1.Amf detecting that HC failure during component termination is a false 
alarm and ignore the error and ler termination command succeed and then let the 
rest follows.
2. Amf runs clean up command as explained in the description above. This is 
because of inability of Amf to detect wherther health check is because of 
termination command or because of genuine issue that component was undergoing 
and it has reported HC failure just after issuing of terminate command. If Amf 
doesn't take any action then there is likely possibility of termination command 
timeout as erraneous component can't be trusted. This will delay the repair and 
recovery for configured timeout period. This is unwanted for sure. Please note 
that PI component is also being cleaned up in the similar way.

So, we need to converge the understanding and evaluate which one is better 
solution from use case point of view.



---

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] #1809 msg: APIs returning SA_AIS_OK even when cluster node has left cluster membership

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1809] msg: APIs returning SA_AIS_OK even when cluster node has 
left cluster membership**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Thu May 05, 2016 09:52 AM UTC by Chani Srivastava
**Last Updated:** Thu May 05, 2016 09:54 AM UTC
**Owner:** nobody
**Attachments:**

- 
[mqsv_demo_app.c](https://sourceforge.net/p/opensaf/tickets/1809/attachment/mqsv_demo_app.c)
 (4.0 kB; text/x-c)


Setup:
Changeset- 7436
Version - opensaf 5.0
The issue is observed with last two releases also.

Issue: When a node is locked by clm service, saMsgQueueOpen() return SA_AIS_OK 
when it is should have returned SA_AIS_ERR_UNAVAILABLE according to the spec as 
mentioned blow:

If the cluster node has left the cluster membership or is being administratively
evicted from the cluster membership, the Message Service behaves as follows
towards processes residing on that node and using or attempting to use the 
service:
⇒ Calls to saMsgInitialize() will fail with SA_AIS_ERR_UNAVAILABLE.
⇒ All Message Service APIs that are invoked by the process and that operate on
handles already acquired by the process will fail with
SA_AIS_ERR_UNAVAILABLE with the following exceptions, assuming that the
handle msgHandle has already been acquired:

Step to Reproduce:
1. Compile and build the attached test code.
2. After Initialization, test sleep for 10 sec
3. During this sleep, lock the CLM node from another node in cluster
4. saMsgQueueOpen returns successfully.

Expected: saMsgQueueOpen should fail with rc = 31 


---

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] #1960 MDS: MDS does not handle dropped TIPC packages

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1960] MDS: MDS does not handle dropped TIPC packages **

**Status:** assigned
**Milestone:** 5.0.2
**Created:** Fri Aug 19, 2016 08:39 AM UTC by Hans Nordebäck
**Last Updated:** Fri Aug 19, 2016 07:11 PM UTC
**Owner:** Hans Nordebäck


TIPC is run in connection less mode by OpenSAF, i.e. SOCK_RDM, reliable 
datagram where ordering is guaranteed but packages can be dropped at e.g. 
overload situations.
This is not handled by OpenSAF and may cause undetermined behaviour in the 
system.




---

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] #1964 mds: Missing protection against priority inversion

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1964] mds: Missing protection against priority inversion**

**Status:** accepted
**Milestone:** 5.0.2
**Created:** Tue Aug 23, 2016 03:23 PM UTC by Anders Widell
**Last Updated:** Tue Aug 23, 2016 03:23 PM UTC
**Owner:** Anders Widell


The MDS thread is running with real-time priority, but the MDS mutex is not 
created with the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol. This 
could lead to priority inversion when the mutex is locked by another thread.


---

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] #1965 mds: Unfairness in the TIPC poll() loop in the MDS thread

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1965] mds: Unfairness in the TIPC poll() loop in the MDS thread**

**Status:** accepted
**Milestone:** 5.0.2
**Created:** Tue Aug 23, 2016 04:08 PM UTC by Anders Widell
**Last Updated:** Tue Aug 23, 2016 04:10 PM UTC
**Owner:** Anders Widell


The poll() loop in the MDS thread for TIPC does not handle events for its file 
descriptors in a fair way. In cases where the MDS thread is heavily loaded, 
this can lead to starvation.


---

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] #1990 AMF : Extra notification is received for lock operation on unlocked SG.

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1990] AMF :  Extra notification is received for lock operation on 
unlocked SG.**

**Status:** review
**Milestone:** 5.0.2
**Created:** Wed Aug 31, 2016 06:40 AM UTC by Srikanth R
**Last Updated:** Thu Sep 15, 2016 09:58 AM UTC
**Owner:** Praveen


Changeset : 5.1 FC (7997 changeset)

 Extra notification is received for lock operation on unlocked SG.
 
 amf-adm lock safSg=AmfDemo,safApp=AmfDemo
===  Aug 30 15:22:27 - State Change  ===
eventType = SA_NTF_OBJECT_STATE_CHANGE
notificationObject = "safSg=AmfDemo,safApp=AmfDemo"
notifyingObject = "safApp=safAmfService"
notificationClassId = SA_NTF_VENDOR_ID_SAF.SA_SVC_AMF.103 (0x67)
additionalText = "Admin state of safSg=AmfDemo,safApp=AmfDemo changed"
sourceIndicator = SA_NTF_MANAGEMENT_OPERATION
State ID = SA_AMF_ADMIN_STATE
Old State: SA_AMF_ADMIN_UNLOCKED
New State: SA_AMF_ADMIN_LOCKED

===  Aug 30 15:22:27 - State Change  ===
eventType = SA_NTF_OBJECT_STATE_CHANGE
notificationObject = "safSg=AmfDemo,safApp=AmfDemo"
notifyingObject = "safApp=safAmfService"
notificationClassId = SA_NTF_VENDOR_ID_SAF.SA_SVC_AMF.103 (0x67)
additionalText = "Admin state of safSg=AmfDemo,safApp=AmfDemo changed"
sourceIndicator = SA_NTF_MANAGEMENT_OPERATION
State ID = SA_AMF_ADMIN_STATE
Old State: SA_AMF_ADMIN_LOCKED
New State: SA_AMF_ADMIN_LOCKED



---

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] #1992 Standby controller rebooted during switchover as EDS faulted due to csiSetcallbackTimeout

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#1992] Standby controller rebooted during switchover as EDS faulted 
due to csiSetcallbackTimeout**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Thu Sep 01, 2016 05:46 AM UTC by Ritu Raj
**Last Updated:** Thu Sep 01, 2016 05:46 AM UTC
**Owner:** nobody
**Attachments:**

- 
[SC-1.tar.bz2](https://sourceforge.net/p/opensaf/tickets/1992/attachment/SC-1.tar.bz2)
 (2.1 MB; application/x-bzip)
- 
[SC-2.tar.bz2](https://sourceforge.net/p/opensaf/tickets/1992/attachment/SC-2.tar.bz2)
 (2.0 MB; application/x-bzip)


setup:
Version - OpenSAF 5.1.FC : changeset - 6997
4-Node cluster
1PBE with 30K objects

* Issue Observed:
Standby rebooted during switchover as EDS faulted due to 
csiSetcallbackTimeout


* Steps Performed:
> Perform controller switchover
> After couple of successful switchover, Standby Controller (SC-2) got 
rebooted when it is being promoted to ACTIVE state as EDS faulted due to 
csiSetcallbackTimeout
   
Aug 31 16:49:50 sofo-s2 osafamfnd[11489]: NO 
'safComp=EDS,safSu=SC-2,safSg=2N,safApp=OpenSAF' faulted due to 
'csiSetcallbackTimeout' : Recovery is 'nodeFailfast'
Aug 31 16:49:50 sofo-s2 osafamfnd[11489]: ER 
safComp=EDS,safSu=SC-2,safSg=2N,safApp=OpenSAF Faulted due 
to:csiSetcallbackTimeout Recovery is:nodeFailfast
Aug 31 16:49:50 sofo-s2 osafamfnd[11489]: Rebooting OpenSAF NodeId = 131599 EE 
Name = , Reason: Component faulted: recovery is node failfast, OwnNodeId = 
131599, SupervisionTime = 60
Aug 31 16:49:50 sofo-s2 opensaf_reboot: Rebooting local node; timeout=60


Notes:
1. EDS trace not enabled
2. Syslog of both controller attahced
3. osafamfnd trace attached


---

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] #2004 SMF: smfd got crashed when triggered campaign for application upgrade.

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2004] SMF: smfd got crashed when triggered campaign for 
application upgrade.**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Tue Sep 06, 2016 08:35 AM UTC by Madhurika Koppula
**Last Updated:** Thu Sep 08, 2016 05:47 AM UTC
**Owner:** nobody
**Attachments:**

- [smf.tgz](https://sourceforge.net/p/opensaf/tickets/2004/attachment/smf.tgz) 
(1.6 MB; application/octet-stream)


**Environment Details:**

OS : Suse 64bit
Changeset : 7997 ( 5.1.FC)
Setup : 4 nodes ( 2 controllers and 2 payloads with headless feature disabled & 
1PBE enabled ).

**summary:**

smfd got crashed due to segfault on active controller.

**Steps followed & Observed behaviour:**

Test SGupgrade of 2N model with valid configurations.

**Observations:**

Active controller went for reboot due to avadown for smfd.

Below is the snippet of syslog on active controller:

Sep  6 11:52:19 SLES-M-SLOT-1 osafsmfd[3745]: NO 
SmfProcedureThread::getImmProcedure, IMM data for procedure 
safSmfProc=amfClusterProc-1,safSmfCampaign=Campaign2,safApp=safSmfService not 
found
Sep  6 11:52:19 SLES-M-SLOT-1 osafimmnd[3661]: NO Implementer connected: 20 
(safSmfProc1) <662, 2010f>
Sep  6 11:52:19 SLES-M-SLOT-1 osafsmfd[3745]: NO PROC: Start upgrade procedure 
safSmfProc=amfClusterProc-1
Sep  6 11:52:19 SLES-M-SLOT-1 osafsmfd[3745]: NO PROC: Start procedure init 
actions

Sep  6 11:52:19 SLES-M-SLOT-1 osafamfnd[3726]: NO 
'safComp=SMF,safSu=SC-1,safSg=2N,safApp=OpenSAF' faulted due to 'avaDown' : 
Recovery is 'nodeFailfast'

**Sep  6 11:52:19 SLES-M-SLOT-1 osafamfnd[3726]: ER 
safComp=SMF,safSu=SC-1,safSg=2N,safApp=OpenSAF Faulted due to:avaDown Recovery 
is:nodeFailfast**

Sep  6 11:52:19 SLES-M-SLOT-1 osafamfnd[3726]: Rebooting OpenSAF NodeId = 
131343 EE Name = , Reason: Component faulted: recovery is node failfast, 
OwnNodeId = 131343, SupervisionTime = 60

Below is the snippet of osafsmfd trace on active controller:

Sep  6 11:52:19.808986 osafsmfd [3745:SmfUpgradeProcedure.cc:0741] TR 
SmfUpgradeProcedure::calculateRollingSteps:calculateRollingSteps new SW install 
step added safSmfStep=0003 (with no act/deact unit) for node 
safAmfNode=PL-4,safAmfCluster=myAmfCluster
Sep  6 11:52:19.808995 osafsmfd [3745:SmfUpgradeProcedure.cc:1876] >> 
addStepModifications
Sep  6 11:52:19.809002 osafsmfd [3745:SmfUpgradeProcedure.cc:1931] >> 
addStepModificationsNode
Sep  6 11:52:19.809008 osafsmfd [3745:imma_om_api.c:0160] >> saImmOmInitialize
Sep  6 11:52:19.809015 osafsmfd [3745:imma_om_api.c:0186] TR OM client version 
A.2.1
Sep  6 11:52:19.809021 osafsmfd [3745:imma_om_api.c:0228] >> initialize_common
Sep  6 11:52:19.809026 osafsmfd [3745:imma_init.c:0275] >> imma_startup: use 
count 1
Sep  6 11:52:19.809032 osafsmfd [3745:imma_init.c:0298] << imma_startup: use 
count 2
Sep  6 11:52:19.809040 osafsmfd [3745:imma_om_api.c:0246] T2 IMMA library 
syncronous timeout set to:3
Sep  6 11:52:19.809263 osafsmfd [3745:imma_om_api.c:0349] T1 Trying to add OM 
client id:727 node:2010f
Sep  6 11:52:19.809280 osafsmfd [3745:imma_om_api.c:0442] << initialize_common
Sep  6 11:52:19.809287 osafsmfd [3745:imma_om_api.c:0214] << saImmOmInitialize
Sep  6 11:52:19.809293 osafsmfd [3745:imma_om_api.c:0931] >> 
saImmOmAdminOwnerInitialize
Sep  6 11:52:19.811060 osafsmfd [3745:imma_om_api.c:1143] T1 Admin owner init 
successful
Sep  6 11:52:19.811076 osafsmfd [3745:imma_om_api.c:1144] << 
saImmOmAdminOwnerInitialize
Sep  6 11:52:19.811083 osafsmfd [3745:imma_om_api.c:5528] >> 
saImmOmAccessorInitialize
Sep  6 11:52:19.811091 osafsmfd [3745:imma_om_api.c:5626] << 
saImmOmAccessorInitialize
Sep  6 12:21:09.873661 osafsmfd [2421:ncs_main_pub.c:0220] TR
NCS:PROCESS_ID=2421

Attachments:
Active Controller:
1)syslog
2)osafsmfd, osafsmfnd traces.
3)osafimmnd traces.



---

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] #2009 AMF: App Si is moving to UNASSIGNED state after middleware failover

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2009] AMF: App Si is moving to UNASSIGNED state after middleware 
failover**

**Status:** assigned
**Milestone:** 5.0.2
**Created:** Thu Sep 08, 2016 06:07 AM UTC by Srikanth R
**Last Updated:** Wed Sep 14, 2016 08:48 AM UTC
**Owner:** Praveen


Environment details
--
OS : Suse 64bit 
Changeset : 7997  ( 5.1.FC)
Setup : 5 nodes ( 2 controllers and 3 payloads with headless feature enabled & 
no PBE )
AMF Application : 2N model with SUs mapped on PL-3,PL-4  ( si-si deps enabled)


Summary :
--
Application SIs are moving to UNASSIGNED state after middleware failover.


Steps followed & Observed behaviour
--
 -> Initially brought up AMF application (2n model) on two payloads.
 -> All the SIs are fully assigned state and SUs are in INSERVICE state.
 -> Performed middleware failover.
 -> After standby became active controller, SIs moved to unassigned state. But 
'amf-state siass' is showing proper output.
 -> Application received CSI remove callbacks after locking the SUs


Expected behaviour
--
-> As no fault happened on the application, SIs should not move to UNASSIGNED 
state for middleware failover.


---

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] #2010 IMM: library receives wrong response when a ccb is aborted

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2010] IMM: library receives wrong response when a ccb is aborted**

**Status:** accepted
**Milestone:** 5.0.2
**Created:** Thu Sep 08, 2016 07:10 AM UTC by Hung Nguyen
**Last Updated:** Thu Sep 08, 2016 07:16 AM UTC
**Owner:** Hung Nguyen
**Attachments:**

- [logs.7z](https://sourceforge.net/p/opensaf/tickets/2010/attachment/logs.7z) 
(6.8 MB; application/octet-stream)


When receiving the ccb abort message (D2ND_ABORT_CCB) over fevs, IMMND will 
abort the message and send response to client if it's the originating node. See 
immnd_evt_proc_ccb_finalize().

In some cases the client is not in a sync call (i.e. not waiting for response) 
but IMMND still sends that response to the client. One example is when the OI 
attaches/deattaches. That may cause the client to receive unexpected response 
if the client at that time calls an sync IMM api.

Details of the problem is explained here
http://sequencediagram.org/index.html?initialData=A4QwTgLglgxloDsIAICSBZdBBAUKSs8ISamAcgCJ7jRyIobpU5gBGA9gB7LsBuApmFJMAXFmQwYrALQgOkZFADOyAOb8EgkBH4ATADoIA7gAsNyAPKpk2iCBgmoCVQHpd-W-cfOcORhWkAYlUwfg0APkZKEQoAJkoAfSwAIQsAJQAVBIBhbOTkAApAgEYASj9MLCDWABsAV35I8goxeIocvKSABS6AGQBNQsDY8pYObj5BYWioimRgMHYYfiUlFYkpWXkUAFslVWQAM0Wd4QpDYl1kNYRdFVClYHYENeQIdh4wKFUnbScDhDsdyGNb8RQ7HboIH8GoJSSsLDbAqjWZBUK6JrYESUWJYBKMBIAUTSaXSCViyCMUAgJmQADEsKheoT2hYusSsBlUBYyEMAMylQwAKhFGUcKmUbzMEmeawAjg0EMseIdkCVfGwuDwBEJGFgRHrkKFllABCoaWCHk8XmDLlKnABrc0mbSUkDOy0ra1rQyHdhCYYAGmQrDqKHsEDqIBqNQAnooIAByFQAKzqSnDMptCo0yvYqpKhkMhuN-FN6wtlMWziNXtlYNDKF0UF0CETKBgYHdtLMoUMrH4MBA6bBFh2uQRwGAceRNkk-GAEBUOLxBOJpLS5I1421Uz1IjH2SkWCnM9KtcjYBe9MZzNZXUMJ+nsD+zyz0AQDRUVJplh2WF0HYnAsIxNDAOlfhqKAAC9+GRXw9WqepGlmVpEiwCh0AsBI6VQMgsF6VAAC1CSGAAWUZNQmHVphaWZkEBIxrg0O4pU9R56yOf01ViBDmjRPRMX1Fd8UwIkSTJCkf1pBkmRZBI2Q5LkeX5QUEBFIUxUlSVKytTi-QDXixi1SZdUqA1KhsVQQCcWsTTNGxAQtIQjGrA49JtIsEFQDsuyUMxnR0qAdgbQdh1eMcAKAhAQLAiCEGjGC4LU3R2BWNtw3n
 RdkBEtcJM3XigA

~~~
09:45:58 SC-2-2 osafimmnd[3918]: NO ERR_TRY_AGAIN: ccb 1266 is active on object 
CmwSwMswMId=1 of class CmwSwMSwM. Can not add class implementer
09:45:58 SC-2-2 osafimmnd[3918]: NO Trying to abort ccb 1266 to allow 
implementer CoreMwSwM to protect class CmwSwMSwM
09:45:58 SC-2-2 osafimmnd[3918]: NO implementer for class 'CmwIspConfig' is 
CmwIsp => class extent is safe.
09:45:58 SC-2-2 osafimmnd[3918]: NO Implementer disconnected 169 <0, 2010f> 
(@ClusMonEE)
09:45:58 SC-2-2 osafimmnd[3918]: NO Ccb 1266 ABORTED 
(CoreMwEcimSwMBackgroundThread)
09:45:58 SC-2-2 ecimswm: ImmUtils::doImmOperations:saImmOmCcbApply failed 
SaAisErrorT=21
09:45:58 SC-2-2 ecimswm: EcimSwmAsyncImmOperation::main() failed with rc = 
21(SA_AIS_ERR_FAILED_OPERATION)
09:45:58 SC-2-2 ecimswm: imma_om_api.c:8769: saImmOmAdminOwnerFinalize: 
Assertion 'out_evt->info.imma.type == IMMA_EVT_ND2A_IMM_ERROR' failed.
09:45:58 SC-2-2 osafimmnd[3918]: NO Implementer connected: 173 (ClusMonEE) <0, 
2010f>
09:45:58 SC-2-2 osafimmnd[3918]: WA >>s_info->to_svc == 0<< reply context 
destroyed before this reply could be made
09:45:58 SC-2-2 osafimmnd[3918]: WA Failed to send response to agent/client 
over MDS
~~~

Attached is syslog and IMM traces


---

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] #2011 ckptd seg faulted on active controller when trying to create checkpoint

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2011] ckptd seg faulted on active controller when trying to create 
checkpoint**

**Status:** accepted
**Milestone:** 5.0.2
**Created:** Thu Sep 08, 2016 07:28 AM UTC by Ritu Raj
**Last Updated:** Mon Sep 12, 2016 10:06 AM UTC
**Owner:** A V Mahesh (AVM)
**Attachments:**

- 
[ckptd_bt](https://sourceforge.net/p/opensaf/tickets/2011/attachment/ckptd_bt) 
(2.6 kB; application/octet-stream)
- 
[messages-20160907.bz2](https://sourceforge.net/p/opensaf/tickets/2011/attachment/messages-20160907.bz2)
 (380.1 kB; application/x-bzip)
- [syslog2](https://sourceforge.net/p/opensaf/tickets/2011/attachment/syslog2) 
(1.4 MB; application/octet-stream)


Environment details

OS : Suse 64bit
Changeset : 7997 ( 5.1.FC)
Setup : 4 nodes ( 2 controllers and 2 payloads with headless feature disabled & 
1PBE enabled with 30K objects )

Summary :

ckptd crashed on active controller when trying to create checkpoint during 
failover

Steps followed & Observed behaviour

1. Initially ran some CKPT test scenarios, along with failovers. After the end 
of the test scenarios, The following IMM objects &  replicas are not deleted 
sofo-s3:/dev/shm # immfind | grep 101
safCkpt=all_replicas_ckpt_name_101
safCkpt=collocated_ckpt_name_101
safReplica=safNode=PL-3\,safCluster=myClmCluster,safCkpt=all_replicas_ckpt_name_101
safReplica=safNode=PL-3\,safCluster=myClmCluster,safCkpt=collocated_ckpt_name_101
safReplica=safNode=SC-1\,safCluster=myClmCluster,safCkpt=all_replicas_ckpt_name_101
safReplica=safNode=SC-2\,safCluster=myClmCluster,safCkpt=all_replicas_ckpt_name_101

2.  When ckpt is created with the earlier name (all_replicas_ckpt_name_101)  
observed the following error in syslog. Also CkptOpen failed with ERR_LIBRARY.

>>   saImmOiRtObjectCreate_2 failed with error = 14
>>
Sep  7 17:21:11 sofo-s2 osafimmnd[2137]: NO PBE-OI established on this SC. 
Dumping incrementally to file imm.db
Sep  7 17:21:12 sofo-s2 osafckptd[2284]: ER create_runtime_ckpt_object - 
saImmOiRtObjectCreate_2 failed with error = 14
Sep  7 17:21:12 sofo-s2 osafckptd[2284]: ER create runtime ckpt object failed 
with error: 14
Sep  7 17:21:12 sofo-s2 osafckptd[2284]: ER cpd db add ckpt_node failed for 
ckpt_id:2


4. After some time cpktd seg faulted on active controller
>>
Sep  7 17:21:43 sofo-s2 osafamfnd[2187]: NO 
'safComp=CPD,safSu=SC-2,safSg=2N,safApp=OpenSAF' faulted due to 'avaDown' : 
Recovery is 'nodeFailfast'
Sep  7 17:21:43 sofo-s2 osafamfnd[2187]: ER 
safComp=CPD,safSu=SC-2,safSg=2N,safApp=OpenSAF Faulted due to:avaDown Recovery 
is:nodeFailfast
Sep  7 17:21:43 sofo-s2 osafamfnd[2187]: Rebooting OpenSAF NodeId = 131599 EE 
Name = , Reason: Component faulted: recovery is node failfast, OwnNodeId = 
131599, SupervisionTime = 60
Sep  7 17:21:43 sofo-s2 opensaf_reboot: Rebooting local node; timeout=60

5. Below is the bt

0-  0x7fbbd5ffcb20 in memcmp () from /lib64/libc.so.6
1-  0x7fbbd7a10929 in ncs_patricia_tree_get (pTree=0x67b4c8, 
pKey=0x7d22531c "\017\001\002") at patricia.c:435

2-  0x0040800d in cpd_cpnd_info_node_get (cpnd_tree=0x67b4c8, 
dest=0x67ec60, cpnd_info_node=0x7d225350) at cpd_db.c:706

3-  0x0040cd56 in cpd_evt_proc_mds_evt (cb=0x67b340, evt=0x67ec50) at 
cpd_evt.c:1378

4-  0x004091cb in cpd_process_evt (evt=0x67ec40) at cpd_evt.c:107
5-  0x0041185f in cpd_main_process (cb=0x67b340) at cpd_init.c:661
6 - 0x00411b89 in main (argc=1, argv=0x7d225578) at cpd_main.c:74


Notes:
1. Syslog attached
2. bt attached 
3. ckptd traces not enabled


---

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] #2016 amf: active amfd may flush imm jobs when IMM returns BAD_HANDLE.

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2016] amf: active amfd may flush imm jobs when IMM returns 
BAD_HANDLE.**

**Status:** review
**Milestone:** 5.0.2
**Created:** Fri Sep 09, 2016 10:19 AM UTC by Praveen
**Last Updated:** Fri Sep 09, 2016 12:17 PM UTC
**Owner:** Praveen
**Attachments:**

- 
[comp_fail.xml](https://sourceforge.net/p/opensaf/tickets/2016/attachment/comp_fail.xml)
 (11.0 kB; text/xml)
- 
[is_imp.tgz](https://sourceforge.net/p/opensaf/tickets/2016/attachment/is_imp.tgz)
 (14.0 kB; application/x-compressed)


AMF pushes IMM updates in a queue to be updated in after finishing main job.
Currently, standby amfd as a applier flushes job queue if it no. of elements 
reaches to 200.
Since the check is on implementer status, active controller may flush it when 
it loses implementer status and goes for reinit with IMM(one case is when IMM 
returns BAD_HANDLE, a rare case):
if (!avd_cb->is_implementer) {
check_and_flush_job_queue_standby_amfd();
return JOB_EINVH;
}

In the attached tar, there is a patch which forces amfd to finalize with IMM. 
After finalizing, when it goes to update attributes in IMM, it gets BAD_HANDLE 
and it reinitializes with IMM by setting its implemeter status flag as false 
temporarily.
steps to reproduce with the patch:
1)Bring one controller up.
2)Bring up the attached model.
3)kill the only comonent. AMF will finzlize with IMM and it will flush job 
queue.
Because of this amf-state su will show su in terminating state:
safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1
saAmfSUAdminState=UNLOCKED(1)
saAmfSUOperState=ENABLED(1)
saAmfSUPresenceState=TERMINATING(4)
saAmfSUReadinessState=OUT-OF-SERVICE(1)
But it is actually moved in UNINSTANTIATED state. This can be verified by 
dumping amf state:
 dn: safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1
saAmfSUPreInstantiable: 1
saAmfSUOperState: DISABLED
saAmfSUAdminState: LOCKED_INSTANTIATION
saAmfSuReadinessState: OUT_OF_SERVICE
saAmfSUPresenceState: UNINSTANTIATED
saAmfSUHostedByNode: safAmfNode=SC-1,safAmfCluster=myAmfCluster

All state machines inside AMF are correct. But a use may not be able to see 
correct state of AMF entities.






---

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] #2020 AMF : Additional features for csiAttributeChangeCallback

- **Milestone**: 4.7.2 --> 5.2.FC



---

** [tickets:#2020] AMF : Additional features for csiAttributeChangeCallback **

**Status:** unassigned
**Milestone:** 5.2.FC
**Created:** Sat Sep 10, 2016 05:53 AM UTC by Srikanth R
**Last Updated:** Sat Sep 10, 2016 05:53 AM UTC
**Owner:** nobody


The following features can be considered additionally for 
csiAttributeChangeCallback implementation.

-> Currently both active and standby receives csiAttributeChangeCallback 
simultaneously. But csiAttributeChangeCallback should be handled in a way like 
csiSet callback.  Initially Component with active assignment should receive the 
callback and later the standby should receive.

   There might be scenario in user application that standby shall try to access 
an object, which is associated with a CSI and should be created by active. If 
both the components simultaneously gets callback, then standby may behave 
erroneoulsy if it processes the callback before  a busy active  component 
processes the callback.
   
   
 ->  Currnelty, the csiAttributeChangeCallback is invoked only when values are 
added to existing csi attrib class. But if a new csi attribute class is 
created, callback is not invoked. 
 
   Callback should be invoked for every modification of csi attrib objects. All 
the operations create, modify and delete should be supported. 





---

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] #2025 Cluster reset happend during headless as CLMNA faulted due to healthCheckcallbackTimeout

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2025] Cluster reset happend  during headless as CLMNA  faulted due 
to healthCheckcallbackTimeout**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Mon Sep 12, 2016 07:32 AM UTC by Ritu Raj
**Last Updated:** Mon Sep 12, 2016 08:18 AM UTC
**Owner:** nobody
**Attachments:**

- 
[PL-4.tar.bz2](https://sourceforge.net/p/opensaf/tickets/2025/attachment/PL-4.tar.bz2)
 (38.4 kB; application/x-bzip)
- 
[PL-5.tar.bz2](https://sourceforge.net/p/opensaf/tickets/2025/attachment/PL-5.tar.bz2)
 (59.0 kB; application/x-bzip)
- 
[SC-1.tar.bz2](https://sourceforge.net/p/opensaf/tickets/2025/attachment/SC-1.tar.bz2)
 (160.7 kB; application/x-bzip)
- 
[SC-2.tar.bz2](https://sourceforge.net/p/opensaf/tickets/2025/attachment/SC-2.tar.bz2)
 (107.4 kB; application/x-bzip)
- 
[SC-3.tar.bz2](https://sourceforge.net/p/opensaf/tickets/2025/attachment/SC-3.tar.bz2)
 (109.8 kB; application/x-bzip)


#Environment details
OS : Suse 64bit
Changeset : 7997 ( 5.1.FC)
Setup : 5 nodes ( 3 controllers and 2 payloads with headless feature enabled & 
1PBE with 10K objects

#Summary :
Cluster reset happend  during headless as CLMNA  faulted due to 
healthCheckcallbackTimeout

#Steps followed & Observed behaviour
1. Invoked headless by killing Active followed by Standby and Spare Controller,
maintaining gap of 6 sec between controller reboot

2. After couple of failover, CLMNA faulted on PL-4 and PL-5 due to 
healthCheckcallbackTimeout, and cluster reset happened.

Sep 10 17:52:46 SCALE_SLOT-74 osafamfnd[12421]: NO SU failover probation timer 
started (timeout: 12000 ns)
Sep 10 17:52:46 SCALE_SLOT-74 osafamfnd[12421]: NO Performing failover of 
'safSu=PL-4,safSg=NoRed,safApp=OpenSAF' (SU failover count: 1)
Sep 10 17:52:46 SCALE_SLOT-74 osafamfnd[12421]: NO 
'safComp=CLMNA,safSu=PL-4,safSg=NoRed,safApp=OpenSAF' recovery action escalated 
from 'componentFailover' to 'suFailover'
Sep 10 17:52:46 SCALE_SLOT-74 osafamfnd[12421]: NO 
'safComp=CLMNA,safSu=PL-4,safSg=NoRed,safApp=OpenSAF' faulted due to 
'healthCheckcallbackTimeout' : Recovery is 'suFailover'
Sep 10 17:52:46 SCALE_SLOT-74 osafamfnd[12421]: ER 
safComp=CLMNA,safSu=PL-4,safSg=NoRed,safApp=OpenSAF Faulted due 
to:healthCheckcallbackTimeout Recovery is:suFailover
Sep 10 17:52:46 SCALE_SLOT-74 osafamfnd[12421]: Rebooting OpenSAF NodeId = 
132111 EE Name = , Reason: Component faulted: recovery is node failfast, 
OwnNodeId = 132111, SupervisionTime = 60


Notes:
1. There is time gap between system
With respect to PL-4(Sep 10 17:52:46 SCALE_SLOT-74) the corresponding time for 
other system as:
Sep 27 18:46:53: SC-1
Oct 03 10:02:54: SC-2
Oct 03 10:26:44: SC-3
Sep 10 17:54:46: PL-5
There is No syslog logged on controller's during above time. 

2. Syslog of SC-1,SC-2,SC-3, PL-4 and PL-5 attached
3. clmnd traces not enabled


---

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] #2037 IMM: Immd asserted on active controller in backward compatability

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2037] IMM: Immd asserted on active controller in backward 
compatability**

**Status:** assigned
**Milestone:** 5.0.2
**Created:** Thu Sep 15, 2016 06:51 AM UTC by Madhurika Koppula
**Last Updated:** Thu Sep 15, 2016 10:31 AM UTC
**Owner:** Neelakanta Reddy
**Attachments:**

- 
[immnd_immd_cores.rtf](https://sourceforge.net/p/opensaf/tickets/2037/attachment/immnd_immd_cores.rtf)
 (8.5 kB; application/rtf)


**Environment Details:**

OS : Suse 64bit
Setup : 4 nodes ( 2 controllers and 2 payloads with headless feature disabled & 
1PBE enabled ).

Backward Compatability:
Opensaf versions on nodes:
SC-1 (5.0), SC-2 (5.1 FC), PL-3 (5.0), PL-4(5.1FC).

**Summary:** IMMD asserted on active controller after immnd crash.

**Steps followed & Observed behaviour:**

1) SC-1 is with role standby, SC-2 is with role active.
2) Sequence of api's called as below. 
a) saImmOiInitialize() 
b) saImmOiImplementerSet() 
c) kill -9 `pidof osafimmnd` d) saImmOiRtObjectDelete() 
 e) saImmOiFinalize()

Observations:

1) First immnd asserted on active controller  when calling 
immnd_evt_proc_fevs_rcv
2) Second active controller rebooted with immd assertion failed.

Below is the snippet of active controller SC-2:

Sep 20 20:52:47 SCALE_SLOT-42 osafntfimcnd[15091]: NO saImmOiDispatch() Fail 
SA_AIS_ERR_BAD_HANDLE (9)
Sep 20 20:52:47 SCALE_SLOT-42 osafimmnd[15114]: Started
Sep 20 20:52:47 SCALE_SLOT-42 osafimmnd[15114]: NO Persistent Back-End 
capability configured, Pbe file:imm.db (suffix may get added)
Sep 20 20:52:47 SCALE_SLOT-42 osafimmd[12159]: NO MDS event from svc_id 25 
(change:3, dest:565216648273948)
Sep 20 20:52:47 SCALE_SLOT-42 osafimmnd[15114]: NO IMMD service is UP ... 
ScAbsenseAllowed?:0 introduced?:0
Sep 20 20:52:47 SCALE_SLOT-42 osafimmnd[15114]: NO SERVER STATE: 
IMM_SERVER_ANONYMOUS --> IMM_SERVER_CLUSTER_WAITING
Sep 20 20:52:47 SCALE_SLOT-42 osafimmnd[15114]: immnd_evt.c:9146: 
immnd_evt_proc_fevs_rcv: Assertion '!reply_dest || (reply_dest == 
cb->immnd_mdest_id) || isObjSync' failed.
Sep 20 20:52:47 SCALE_SLOT-42 python2.5: WA imma_mds_svc_evt: 
mds_auth_server_connect failed
Sep 20 20:52:47 SCALE_SLOT-42 osafimmd[12159]: NO MDS event from svc_id 25 
(change:4, dest:565216648273948)
Sep 20 20:52:47 SCALE_SLOT-42 osafamfnd[12239]: NO Restarting a component of 
'safSu=SC-2,safSg=NoRed,safApp=OpenSAF' (comp restart count: 6)
Sep 20 20:52:47 SCALE_SLOT-42 osafamfnd[12239]: NO 
'safComp=IMMND,safSu=SC-2,safSg=NoRed,safApp=OpenSAF' faulted due to 'avaDown' 
: Recovery

Sep 20 20:52:47 SCALE_SLOT-42 osafimmnd[15136]: WA Error code 2 returned for 
message type 82 - ignoring
Sep 20 20:52:47 SCALE_SLOT-42 osafimmd[12159]: NO Extended intro from node 2020f
Sep 20 20:52:47 SCALE_SLOT-42 osafimmd[12159]: immd_evt.c:816: 
immd_accept_node: Assertion 'node_info->immnd_key != cb->node_id' failed.
Sep 20 20:52:47 SCALE_SLOT-42 osafamfnd[12239]: NO 
'safComp=IMMD,safSu=SC-2,safSg=2N,safApp=OpenSAF' faulted due to 'avaDown' : 
Recovery is 'nodeFailfast'

Sep 20 20:52:47 SCALE_SLOT-42 osafamfnd[12239]: ER 
safComp=IMMD,safSu=SC-2,safSg=2N,safApp=OpenSAF Faulted due to:avaDown Recovery 
is:nodeFailfast

Sep 20 20:52:47 SCALE_SLOT-42 osafamfnd[12239]: Rebooting OpenSAF NodeId = 
131599 EE Name = , Reason: Component faulted: recovery is node failfast, 
OwnNodeId = 131599, SupervisionTime = 60

After reboot timestamp is as below:

Sep 20 20:52:47 SCALE_SLOT-42 opensaf_reboot: Rebooting local node; timeout=60
Sep 20 20:52:47 SCALE_SLOT-42 osafimmnd[15136]: WA DISCARD DUPLICATE FEVS 
message:12996
Sep 20 20:52:47 SCALE_SLOT-42 osafimmnd[15136]: WA Error code 2 returned for 
message type 82 - ignoring
Sep 20 20:52:48 SCALE_SLOT-42 osafimmnd[15136]: NO SERVER STATE: 
IMM_SERVER_CLUSTER_WAITING --> IMM_SERVER_LOADING_PENDING
Sep 20 20:52:48 SCALE_SLOT-42 osafimmnd[15136]: NO SERVER STATE: 
IMM_SERVER_LOADING_PENDING --> IMM_SERVER_SYNC_PENDING
Sep 22 02:13:05 SCALE_SLOT-42 syslog-ng[1133]: syslog-ng starting up; 
version='2.0.9'
Sep 22 02:13:06 SCALE_SLOT-42 sm-notify[1650]: Version 1.2.3 starting
Sep 22 02:13:06 SCALE_SLOT-42 sm-notify[1650]: Backgrounding to notify hosts...
Sep 22 02:13:06 SCALE_SLOT-42 sm-notify[1651]: Running as root.  chown 
/var/lib/nfs to choose different user
Sep 22 02:13:06 SCALE_SLOT-42 sm-notify[1651]: DNS resolution of CONN-PC 
failed; retrying later
Sep 22 02:13:06 SCALE_SLOT-42 rpc.statd[1662]: Version 1.2.3 starting
Sep 22 02:13:06 SCALE_SLOT-42 rpc.statd[1662]: Flags: TI-RPC
Sep 22 02:13:06 SCALE_SLOT-42 rpc.statd[1662]: Running as root.  chown 
/var/lib/nfs to choose different user
Sep 22 02:13:07 SCALE_SLOT-42 opensafd: Starting OpenSAF Services(5.1.FC - ) 
(Using TIPC)
Sep 22 02:13:07 SCALE_SLOT-42 osafclmna[1745]: Started
Sep 22 02:13:07 SCALE_SLOT-42 osafclmna[1745]: NO 
safNode=SC-2,safCluster=myClmCluster Joined cluster, nodeid=2020f
Sep 22 02:13:07 SCALE_SLOT-42 osafrded[1754]: Started
Sep 22 02:13:08

[tickets] [opensaf:tickets] #2036 build : make rpm fails, if installation directories are specified

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2036] build : make rpm fails, if installation directories are 
specified**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Thu Sep 15, 2016 06:03 AM UTC by Srikanth R
**Last Updated:** Thu Sep 15, 2016 06:03 AM UTC
**Owner:** nobody


Environment : 
Setup : SLES 64bit gcc 6.1

Steps performed :

Ran the following commands after downloading the opensaf from hg.
-> ./bootstrap.sh
-> ./configure CFLAGS="-g " CXXFLAGS="-g " --enable-tipc --enable-imm-pbe 
--enable-ntf-imcn   --sysconfdir=/opt/etc  --localstatedir=/opt/var 
--libdir=/opt/usr/lib
-> make rpm

 The last step fails with the following error.
 
 
 Checking for unpackaged file(s): /usr/lib/rpm/check-files 
/home/pinv/Srikanth/SAF_7997/rpms/tmp/opensaf-5.1.FC-1-root-root
error: Installed (but unpackaged) file(s) found:
   /opt/etc/opensaf/amfd.conf
   /opt/etc/opensaf/amfnd.conf
   /opt/etc/opensaf/amfwdog.conf
   /opt/etc/opensaf/chassis_id
   /opt/etc/opensaf/ckptd.conf
   /opt/etc/opensaf/ckptnd.conf
   /opt/etc/opensaf/clmd.conf
   /opt/etc/opensaf/clmna.conf
   /opt/etc/opensaf/dtmd.conf


RPM build errors:
File not found: 
/home/pinv/Srikanth/SAF_7997/rpms/tmp/opensaf-5.1.FC-1-root-root/usr/lib64/opensaf
File not found: 
/home/pinv/Srikanth/SAF_7997/rpms/tmp/opensaf-5.1.FC-1-root-root/etc/opensaf
File not found: 
/home/pinv/Srikanth/SAF_7997/rpms/tmp/opensaf-5.1.FC-1-root-root/var/lib/opensaf
File not found: 
/home/pinv/Srikanth/SAF_7997/rpms/tmp/opensaf-5.1.FC-1-root-root/var/log/opensaf
File not found: 
/home/pinv/Srikanth/SAF_7997/rpms/tmp/opensaf-5.1.FC-1-root-root/var/run/opensaf
File not found: 
/home/pinv/Srikanth/SAF_7997/rpms/tmp/opensaf-5.1.FC-1-root-root/etc/opensaf/chassis_id
File not found: 
/home/pinv/Srikanth/SAF_7997/rpms/tmp/opensaf-5.1.FC-1-root-root/etc/opensaf/slot_id
.
File not found by glob: 
/home/pinv/Srikanth/SAF_7997/rpms/tmp/opensaf-5.1.FC-1-root-root/usr/lib64/libSa*.a
Installed (but unpackaged) file(s) found:
   /opt/etc/opensaf/amfd.conf
   /opt/etc/opensaf/amfnd.conf
   /opt/etc/opensaf/amfwdog.conf
   /opt/etc/opensaf/chassis_id
   /opt/etc/opensaf/ckptd.conf
   /opt/etc/opensaf/ckptnd.conf
   /opt/etc/opensaf/clmd.conf
   /opt/etc/opensaf/clmna.conf
   /opt/etc/opensaf/dtmd.conf
  ...
 /opt/usr/lib/pkgconfig/opensaf-smf.pc
   /opt/usr/lib/pkgconfig/opensaf.pc
make: *** [rpm] Error 1






---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2039 NTF: Missleading returned code of ntftest when tests are failed

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2039] NTF: Missleading returned code of ntftest when tests are 
failed**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Thu Sep 15, 2016 09:11 AM UTC by Minh Hon Chau
**Last Updated:** Thu Sep 15, 2016 09:11 AM UTC
**Owner:** nobody


If running a test case of ntftest suite 37 (38, or 39) and it fails, the 
reported error is always SA_AIS_ERR_FAILED_OPERATION, but the actual failure 
code is different.
The actual error code should be memorized and reported in test result.


---

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] #2040 clmd seg faulted on active controller during switchover

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2040] clmd seg faulted on active controller during switchover**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Fri Sep 16, 2016 11:30 AM UTC by Ritu Raj
**Last Updated:** Fri Sep 16, 2016 11:30 AM UTC
**Owner:** nobody
**Attachments:**

- 
[SC-1.tar.bz2](https://sourceforge.net/p/opensaf/tickets/2040/attachment/SC-1.tar.bz2)
 (3.6 MB; application/x-bzip)
- [clmd_bt](https://sourceforge.net/p/opensaf/tickets/2040/attachment/clmd_bt) 
(3.2 kB; application/octet-stream)


# Environment details
OS : Suse 64bit
Changeset : 7997 ( 5.1.FC)
Setup : 4 nodes ( 2 controllers and 2 payloads with headless feature disabled & 
 1PBE with 30K objects)


#Summary 
clmd seg faulted on active controller during controller switchover 

#Steps followed & Observed behaviour
1. Incoked controller switchover (SC-1 is the Active)
2. During role change, on SC-1 clmd got crashed and node went for reboot as 
'safComp=CLM,safSu=SC-1,safSg=2N,safApp=OpenSAF' faulted due to 'avaDown'
3. After, Active controller went for reboot,
>>NTFD crashed on Standby controller  and cluster reset happend -- Regarding 
>>NTFD crashed a ticket is already raised -- 
>>https://sourceforge.net/p/opensaf/tickets/1999/

*Syslog :

Sep 16 15:33:30 sofo-s1 osafamfnd[2162]: NO 
'safComp=CLM,safSu=SC-1,safSg=2N,safApp=OpenSAF' faulted due to 'avaDown' : 
Recovery is 'nodeFailfast'
Sep 16 15:33:30 sofo-s1 osafamfnd[2162]: ER 
safComp=CLM,safSu=SC-1,safSg=2N,safApp=OpenSAF Faulted due to:avaDown Recovery 
is:nodeFailfast
Sep 16 15:33:30 sofo-s1 osafamfnd[2162]: Rebooting OpenSAF NodeId = 131343 EE 
Name = , Reason: Component faulted: recovery is node failfast, OwnNodeId = 
131343, SupervisionTime = 60


*Below is the bt:

0  0x7f3db18e1b55 in raise () from /lib64/libc.so.6
1  0x7f3db18e3131 in abort () from /lib64/libc.so.6
2  0x7f3db191ec2f in __libc_message () from /lib64/libc.so.6
3  0x7f3db1924358 in malloc_printerr () from /lib64/libc.so.6
4  0x7f3db19292fc in free () from /lib64/libc.so.6
5  0x7f3db223db52 in timer_delete@@GLIBC_2.3.3 () from /lib64/librt.so.1
6  0x004055b3 in amf_quiesced_state_handler (cb=0x633820 <_clms_cb>, 
invocation=4288675847) at clms_amf.c:123
7  0x00405795 in clms_amf_csi_set_callback (invocation=4288675847, 
compName=0x6bac88, new_haState=SA_AMF_HA_QUIESCED, csiDescriptor=...) at 
clms_amf.c:223
8  0x7f3db332e1f1 in ava_hdl_cbk_rec_prc (info=0x6bac70, 
reg_cbk=0x7fff3e5fafe0) at ava_hdl.cc:645
9  0x7f3db332d896 in ava_hdl_cbk_dispatch_all (cb=0x7fff3e5fb0b0, 
hdl_rec=0x7fff3e5fb0b8) at ava_hdl.cc:446
10 0x7f3db332d376 in ava_hdl_cbk_dispatch (cb=0x7fff3e5fb0b0, 
hdl_rec=0x7fff3e5fb0b8, flags=SA_DISPATCH_ALL) at ava_hdl.cc:320
11 0x7f3db3325a49 in AmfAgent::Dispatch (hdl=4285530114, 
flags=SA_DISPATCH_ALL) at amf_agent.cc:283
12 0x7f3db332588e in saAmfDispatch (hdl=4285530114, flags=SA_DISPATCH_ALL) 
at amf_agent.cc:244
13 0x00413966 in main (argc=2, argv=0x7fff3e5fb208) at clms_main.c:515


*Notes:
1. Issue is random
2. Syslog, clmd trace and bt file attached 


---

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] #2041 Msg: saMsgInitialize is returning continuous TRY_AGAINS after mqsv ndrestarts in backward compatability.

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2041] Msg: saMsgInitialize is returning continuous TRY_AGAINS 
after mqsv ndrestarts in backward compatability.**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Fri Sep 16, 2016 12:13 PM UTC by Madhurika Koppula
**Last Updated:** Tue Sep 20, 2016 04:59 AM UTC
**Owner:** nobody
**Attachments:**

- 
[messages-20160921.bz2](https://sourceforge.net/p/opensaf/tickets/2041/attachment/messages-20160921.bz2)
 (240.9 kB; application/octet-stream)


**Environment Details:**
OS : Suse 64bit
Setup : 4 nodes ( 2 controllers and 2 payloads with headless feature disabled & 
1PBE enabled ).

Backward Compatability:
Opensaf versions on nodes:
SC-1 (5.0), SC-2 (5.1 FC), PL-3 (5.0), PL-4(5.1FC).

**Summary:**  saMsgInitialize is returning continuous TRY_AGAINS after 
mqnd_imm_initialize failed with ERR_TIMEOUT.

**Steps followed & Observed behaviour:**

Mqsv test application is being ran by continuously killing mqnd.

Observations:

saMsgInitialize failed with continuous TRY_AGAIN. Below is the snapshot. 

100|0| Version : B.3.1
100|0| RETRY   : saMsgInitialize with all valid parameters
100|0| Return Value: SA_AIS_ERR_TRY_AGAIN
100|0|
100|0|
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1 Retry Count : 10
100|0|
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1 Retry Count : 20
100|0|
100|0| Version : B.3.1
100|0| Version  Sun Sep 18 11:51:19 IST 2016
100|0|Sun Sep 18 11:51:19 IST 2016
100|0|Sun Sep 18 11:51:59 IST 2016
100|0|Sun Sep 18 11:51:59 IST 2016
100|0|Sun Sep 18 11:52:39 IST 2016
100|0|Sun Sep 18 11:52:39 IST 2016

100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1 Retry Count : 30
100|0|
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1
100|0| Version : B.3.1 Retry Count : 40
100|0| Try again count exceeded* TEST CASE FAILED 

Below is the snippet of syslog of SC-1:


Sep 18 11:48:32 SCALE_SLOT-41 osafimmnd[19813]: NO Implementer (applier) 
connected: 2462 (@OpenSafImmReplicatorA) <20504, 2010f>
Sep 18 11:48:32 SCALE_SLOT-41 osafntfimcnd[19819]: NO Started
Sep 18 11:48:39 SCALE_SLOT-41 osafamfd[1816]: NO Re-initializing with IMM
Sep 18 11:48:39 SCALE_SLOT-41 osafimmnd[19813]: NO Implementer connected: 2463 
(safAmfService) <20506, 2010f>
Sep 18 11:48:39 SCALE_SLOT-41 osafamfd[1816]: NO Finished re-initializing with 
IMM

**Sep 18 11:48:39 SCALE_SLOT-41 osafmsgnd[19792]: ER mqnd_imm_initialize 
Failed: 5**

Sep 18 11:48:39 SCALE_SLOT-41 osafamfnd[1826]: 
'safComp=MQND,safSu=SC-1,safSg=NoRed,safApp=OpenSAF'unregistered
Sep 18 11:48:39 SCALE_SLOT-41 osafmsgnd[19792]: CR Destroying the shared memory 
segment failed
Sep 18 11:48:39 SCALE_SLOT-41 osafmsgnd[19792]: ER saAmfComponentUnregister 
Failed with error 9
Sep 18 11:48:39 SCALE_SLOT-41 osafmsgnd[19792]: ER Cb is NULL
Sep 18 11:48:49 SCALE_SLOT-41 osafimmnd[19813]: NO Implementer connected: 2464 
(MsgQueueService131343) <20507, 2010f>
Sep 18 11:48:49 SCALE_SLOT-41 osafimmnd[19813]: NO Implementer locally 
disconnected. Marking it as doomed 2464 <20507, 2010f> (MsgQueueService131343)

Attachments:
1)Syslog of SC-1.



---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2042 EVT : Application segfaulted in MDS callback processing

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2042] EVT : Application segfaulted in MDS callback processing**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Fri Sep 16, 2016 12:22 PM UTC by Srikanth R
**Last Updated:** Fri Sep 16, 2016 12:24 PM UTC
**Owner:** nobody
**Attachments:**

- [eda_bt](https://sourceforge.net/p/opensaf/tickets/2042/attachment/eda_bt) 
(59.5 kB; application/octet-stream)


Setup : 7997 5.1.FC 

Issue :
 Application segfaulted on payload in MDS  callback processing  by EVT thread.
 Below is the backtrace.
 
 0  0x7ff2f5282d64 in ncs_decode_32bit (stream=0x7ff2f6b95c98) at 
hj_dec.c:197
1  0x7ff2f5f181e4 in eda_mds_dec (info=0x7ff2f6b95dd0) at eda_mds.c:1285
2  0x7ff2f5f185fa in eda_mds_callback (info=0x7ff2f6b95dd0) at 
eda_mds.c:1440
3  0x7ff2f52b887b in mds_mcm_do_decode_full_or_flat (svccb=0x639c40, 
cbinfo=0x7ff2f6b95dd0, recv_msg=0x7aace8, orig_msg=0x0) at mds_c_sndrcv.c:4915
4  0x7ff2f52b7841 in mds_mcm_process_recv_snd_msg_common (svccb=0x639c40, 
recv=0x7aace8) at mds_c_sndrcv.c:4255
5  0x7ff2f52b7f24 in mcm_recv_normal_snd (svccb=0x639c40, recv=0x7aace8) at 
mds_c_sndrcv.c:4389
6  0x7ff2f52b7305 in mds_mcm_ll_data_rcv (recv=0x7aace8) at 
mds_c_sndrcv.c:4067
7  0x7ff2f52a54ac in mdtm_process_recv_message_common (flag=0 '\000', 
buffer=0x61424a "\252", len=167, transport_adest=72075191086465088, 
seq_num_check=30108, buff_dump=0x7ff2f6b961bc) at mds_dt_common.c:505
8  0x7ff2f52a626f in mdtm_process_recv_data (buffer=0x614242 "", len=175, 
transport_adest=72075191086465088, buff_dump=0x7ff2f6b961bc) at 
mds_dt_common.c:949
9  0x7ff2f52c952f in mdtm_process_recv_events () at mds_dt_tipc.c:793
10 0x7ff2f586c7b6 in start_thread () from /lib64/libpthread.so.0
11 0x7ff2f55c89cd in clone () from /lib64/libc.so.6

The entire backtrace is attached as an attachment. This issue is observed in 
earlier releases also.



---

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] #2047 amf: SG unstable when NPI comp in PI SU moves to TERM_FAILED state during fresh assignments.

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2047] amf: SG unstable when NPI comp in PI SU moves to TERM_FAILED 
state during fresh assignments.**

**Status:** assigned
**Milestone:** 5.0.2
**Created:** Mon Sep 19, 2016 11:31 AM UTC by Praveen
**Last Updated:** Mon Sep 19, 2016 11:34 AM UTC
**Owner:** Praveen
**Attachments:**

- 
[pinpi_issue.tgz](https://sourceforge.net/p/opensaf/tickets/2047/attachment/pinpi_issue.tgz)
 (21.9 kB; application/x-compressed)


Conf: 2N model, one NPI and one PI comp in SU.
Steps to reproduce:
1)Add application using immcfg command.
2)Lock SG.
3)Unlock-in and unlock SUs.
4)Make provisions so that instantiation and clean up scripts of NPI comp 
returns with non-zero status.
5)Unlock SG.
When SG is unlocked, AMFND initiates active assignments by issuing callback to 
PI comp and by instantiating NPI component. After instantiation failure of NPI 
comp, AMFND tries to clean up it. Cleanup fails. AMFND marks comp and SU in 
TERM_FAILED state and terminates PI comp also, but AMFND neither responds to 
AMFD for the completion of assignment nor it sends any recovery request. 
Because of this SG remains unstable in REALIGN state.In this state, no admin 
operation is allowed.
Attached are traces and configuration.
Even though issue seems to be similar to #538, it is different in one aspect. 
In #538, SU moves to TERM_FAILED state and there is possibiltiy of 
failover/switchover as standby assignments are present.
In the present case, it happened during initial assignments and thus there is 
no standby to switchover/failover to.


---

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] #2045 logd faulted due to 'csiSetcallbackFailed' on STANDBY during role_change in Headless scenario

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2045] logd faulted due to 'csiSetcallbackFailed' on STANDBY during 
role_change in Headless scenario**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Mon Sep 19, 2016 06:42 AM UTC by Ritu Raj
**Last Updated:** Tue Sep 20, 2016 08:42 AM UTC
**Owner:** nobody
**Attachments:**

- 
[SC-2.tar.bz2](https://sourceforge.net/p/opensaf/tickets/2045/attachment/SC-2.tar.bz2)
 (14.9 MB; application/x-bzip)
- 
[syslogSC-1](https://sourceforge.net/p/opensaf/tickets/2045/attachment/syslogSC-1)
 (3.8 MB; application/octet-stream)
- 
[syslogSC-2](https://sourceforge.net/p/opensaf/tickets/2045/attachment/syslogSC-2)
 (2.9 MB; application/octet-stream)


# Environment details

OS : Suse 64bit
Changeset : 7997 ( 5.1.FC)
Setup : 6 nodes ( 3 controllers and 3 payloads with headless feature enabled & 
1PBE with 10K objects)

# Summary
NCS_MBCSV_OP_CHG_ROLE FAILED on STANBY controller and logd faulted due to 
'csiSetcallbackFailed'

# Steps followed & Observed behaviour
1. Invoked headless by killing Active followed by Standby and Spare Controller,
maintaining gap of 11 sec between controller reboot
2. After 81 successful failover, during role change from STNADBY to ACTIVE, on  
STANDBY(SC-2) logd faulted due to 'csiSetcallbackFailed' 
[also .. NCS_MBCSV_OP_CHG_ROLE FAILED] 

*Syslog:
Sep 16 22:26:39 SCALE_SLOT-72 osaflogd[1770]: ER ncs_mbcsv_svc 
NCS_MBCSV_OP_CHG_ROLE FAILED
Sep 16 22:26:39 SCALE_SLOT-72 osafamfnd[1810]: NO 
'safComp=LOG,safSu=SC-2,safSg=2N,safApp=OpenSAF' faulted due to 
'csiSetcallbackFailed' : Recovery is 'nodeFailfast'
Sep 16 22:26:39 SCALE_SLOT-72 osafamfnd[1810]: ER 
safComp=LOG,safSu=SC-2,safSg=2N,safApp=OpenSAF Faulted due 
to:csiSetcallbackFailed Recovery is:nodeFailfast
Sep 16 22:26:39 SCALE_SLOT-72 osafamfnd[1810]: Rebooting OpenSAF NodeId = 
131599 EE Name = , Reason: Component faulted: recovery is node failfast, 
OwnNodeId = 131599, SupervisionTime = 60
Sep 16 22:26:39 SCALE_SLOT-72 opensaf_reboot: Rebooting local node; timeout=60
 

*Notes:
1. There is time gap between systems [node's are not sync]
With respect to SC-1 and SC-2, SC-3  is >> +6:24:07
2. Syslog of controller's and  amfd and clmd trace's of SC-2 is attached
3. logd traces are not enabled



---

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] #2048 opensaf/doc: no separate branches for 4.7 and 5.0.

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2048] opensaf/doc: no separate branches for 4.7 and 5.0.**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Mon Sep 19, 2016 11:43 AM UTC by Praveen
**Last Updated:** Mon Sep 19, 2016 02:53 PM UTC
**Owner:** nobody


It seems there are no separate branches for 4.7 and 5.0 for documentation.
Even they are not listed in closed brnaches.
Here is output of hg commands:
\# hg branch
default
\# hg branches
default  189:e4d420f962d3
\# hg branches -c
default  189:e4d420f962d3
opensaf-4.6.x181:0a4b9b47c55c (closed)
opensaf-4.5.x167:650e49539772 (closed)
opensaf-4.4.x155:81bbe5de2f18 (closed)
opensaf-4.3.x134:ff16f59fe449 (closed)
opensaf-4.2.x 98:b97c89fb2890 (closed)



---

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] #2052 immtools: SC/PL field in nodes.cfg is not used

- **Milestone**: 4.7.2 --> 5.0.2



---

** [tickets:#2052] immtools: SC/PL field in nodes.cfg is not used**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Tue Sep 20, 2016 09:41 AM UTC by Ritu Raj
**Last Updated:** Tue Sep 20, 2016 02:00 PM UTC
**Owner:** nobody


# Environment details
OS : Suse 64bit
Changeset : 7997 ( 5.1.FC)

# Summary
Controller able to join with invalid node_name

# Steps followed & Observed behaviour
1. Mistakenly configured controller node_name with PL-3 and the remaining 
configuration files are properly installed and updated apart from 
/etc/opensaf/node_name.
2. Bringup OpenSAF, OpneSAF still able to comeup with misconfigured node_name

Opensaf status:
fos1:/opt/goahead/tetware/opensaffire/suites/avsv/api/suites # 
/etc/init.d/opensafd status
safSISU=safSu=PL-3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)

#  Expected
OpenSAF should come up with only SC-1 / SC-2, as immxml generated with :
 ./immxml-clustersize -s 2 -p 2
 ./immxml-configure




---

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] #2029 imm: fevs message lost during failover

- **Milestone**: 4.7.2 --> 5.0.1



---

** [tickets:#2029] imm: fevs message lost during failover**

**Status:** review
**Milestone:** 5.0.1
**Created:** Tue Sep 13, 2016 11:05 AM UTC by Hung Nguyen
**Last Updated:** Tue Sep 20, 2016 05:38 AM UTC
**Owner:** Hung Nguyen
**Attachments:**

- [logs.7z](https://sourceforge.net/p/opensaf/tickets/2029/attachment/logs.7z) 
(250.9 kB; application/octet-stream)


There's fevs message loss when failing over between 2 SCs.


~~~
Sep  8 11:50:00 SC-2-1 osafimmnd[4241]: NO Implementer locally disconnected. 
Marking it as doomed 232 <754, 2010f> (@OpenSafImmPBE)
Sep  8 11:50:00 SC-2-1 osafimmnd[4241]: NO Implementer locally disconnected. 
Marking it as doomed 233 <755, 2010f> (OsafImmPbeRt_B)
...
Sep  8 11:50:00 SC-2-1 osafimmnd[4241]: NO Implementer disconnected 233 <755, 
2010f> (OsafImmPbeRt_B)
~~~


The IMMNDs never receive the D2ND_DISCARD_IMPL for @OpenSafImmPBE, so that 
applier keeps being mark as dying


~~~
Sep  8 11:50:02 SC-2-1 osafimmnd[4241]: NO ImmModel::getPbeBSlave reports 
missing PbeBSlave locally => unsafe
Sep  8 11:50:03 SC-2-1 osafimmnd[4241]: NO ImmModel::getPbeBSlave reports 
missing PbeBSlave locally => unsafe
Sep  8 11:50:04 SC-2-1 osafimmnd[4241]: NO ImmModel::getPbeBSlave reports 
missing PbeBSlave locally => unsafe
...
Sep  8 11:59:08 SC-2-1 osafimmnd[4241]: NO ImmModel::getPbeBSlave reports 
missing PbeBSlave locally => unsafe
Sep  8 11:59:09 SC-2-1 osafimmnd[4241]: NO ImmModel::getPbeBSlave reports 
missing PbeBSlave locally => unsafe
Sep  8 11:59:10 SC-2-1 osafimmnd[4241]: NO ImmModel::getPbeBSlave reports 
missing PbeBSlave locally => unsafe
...
~~~

The main problem is the standby IMMD also broadcast D2ND_DISCARD_NODE message 
when it receives an NCSMDS_DOWN from IMMND. See immd_process_immnd_down().

If the NCSMDS_DOWN event comes to the 2 IMMDs at the same time, the 2 
D2ND_DISCARD_NODE messages will be stamped with the same number. One of the 2 
will be discarded by IMMNDs, no problem here.
But if there's a latency of NCSMDS_DOWN event, an other fevs message (in this 
case it's D2ND_DISCARD_IMPL for @OpenSafImmPBE) will be discarded by IMMNDs, 
that will cause fevs message loss.

Details of the problem is explained here


http://sequencediagram.org/index.html?initialData=A4QwTgLglgxloDsIAICSBZdARAjACgGUAVAIQEoAoUSWeEJNTLAJjwEEBhIy66ORFBnQA5LAGcKFMACMA9gA9ksgG4BTMI2z5i5ADRCW7LmQBcMAK5gwqhgDNVysQRsATDrPNITyHAAYALADMAGySMgpKahpComImMVhKCMgEHMzIUGLILrIA7ghhcooq6pq4hKSmwhwE2AQA+lgA8gDqwsgONhCSkgbalQC0AMTWLgB8CXEsoo2oqWwASlj1wk1YAKLIYhAgALbAqi7IuVAQABY+AYEA7L1MrJzcADxD0gA25qoDkyaizMtYOYcRbLDAABQAMshbLINAABJoHBAEEC2VC7XZgkjrQoRErRe5GbgmeyOZwINweBiZZAIWQoczAFwgCCHZAQWQAc1U51KJ3OZRwAB0ECKxLIMihtntgFlechdqoxGIQNzjqcLn4grcKAYHsZhqMJphYiZpgCgSD6uCodL9mz+Zqrjq+hVyC9OdYbN9CY9TOgSBwxMoFUqVWqYRotTdccUooK3aYwWAoAwPCh5blwAhU5yRSKWmxkOgw6rVMgYFSICZo9dkABqHzIACEAF5LtqeuE46UfkQzuXJtlMjBwEdzbN5ktrehIaHlWX8whpKpR+YxOXZLZsoy3rAWWzSVkEOZdiuwEv+yyAORZXJnACeyARSJRaIxWM2NLpKFs5jebxPi4I5jocsaRL2vrGL8NR1I0rTtJ0SCXmcNJISglaKnKEp6sgbwHho5z0IKQA


~~~
Sep  8 11:50:00 SC-2-1 osafimmd[4226]: WA IMMND DOWN on active controller 2 
detected at standby immd!! 1. Possible failover
...
Sep  8 11:50:00 SC-2-1 osafimmd[4226]: WA Message count:10437 + 1 != 10437
Sep  8 11:50:00 SC-2-1 osafimmnd[4241]: WA DISCARD DUPLICATE FEVS message:10437
Sep  8 11:50:00 SC-2-1 osafimmnd[4241]: WA Error code 2 returned for message 
type 82 - ignoring
~~~


Attached is the logs


---

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] #1598 leap: PAYLOAD_BUF_SIZE value is suppose to be equal to MDS_DIRECT_BUF_MAXSIZE

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1598] leap: PAYLOAD_BUF_SIZE value is suppose to be equal to 
MDS_DIRECT_BUF_MAXSIZE**

**Status:** assigned
**Milestone:** 5.0.2
**Created:** Tue Nov 17, 2015 07:00 AM UTC by A V Mahesh (AVM)
**Last Updated:** Wed May 04, 2016 07:29 PM UTC
**Owner:** A V Mahesh (AVM)


The  PAYLOAD_BUF_SIZE value is suppose to be equal to
MDS_DIRECT_BUF_MAXSIZE (65535 maximum packet size)-(56 MDS header) ,
but this was NOT changed as part of the patch `MDS: Performance improvement 
[#654]`  in release 4.5.FC,
because of the previous releases of Opensaf  below 4.5.FC  the value of MDS
MDTM_RECV_BUFFER_SIZE (mds_dt_tipc.c) was limited to (8000+MDS header )
, so to support  in-service Upgrade to  below 4.5.FC  , this was NOT changed  
in 4.5.FC.

Now from 4.7  to  4.6/4.5  releases , we can send message  size of
MDS_DIRECT_BUF_MAXSIZE ((65535 maximum packet size)-(56 MDS header)) value
so for the current release it is limited  PAYLOAD_BUF_SIZE 8000 can be  
possibly adjusted
to  MDS_DIRECT_BUF_MAXSIZE (65535 maximum packet size)-(56 MDS header).


For example :  ( of course not as Static array , we may need to do malloc() )

-#define PAYLOAD_BUF_SIZE 8000 /* default size of packet_data bufrs */
+#define PAYLOAD_BUF_SIZE  ((65535 / 100) * 91)  /* default size of packet_data 
bufrs */



---

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] #1650 IMM: When Ccb is aborted with BAD_OPERATION, wrong error string is received at the OM side

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1650] IMM: When Ccb is aborted with BAD_OPERATION, wrong error 
string is received at the OM side**

**Status:** assigned
**Milestone:** 5.0.2
**Created:** Mon Dec 21, 2015 12:28 PM UTC by Chani Srivastava
**Last Updated:** Wed May 04, 2016 07:29 PM UTC
**Owner:** Hung Nguyen


Following are the steps to execute:
1. Enable long dn on one node only and initialize Ccb on that node
2. On other node create OI which does not supports long dns
3. Convert parent name and object name to long DN names and call ccbObjectCreate
4. Ccb will be aborted with FAILED_OPERATION at OM side
5. Call getErrorStrings to check the reason of abort.

Result:
3. As OI does not support long DN, it returns BAD_OPERATION
5. Error string returned is - Resource abort: Upcall failed with error code: 20

Expected:
In this case Validation Abort error string should be set by IMM 


---

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] #1655 cpsv: Replica IMM objects are not created after opening a checkpoint

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1655] cpsv: Replica IMM objects are not created after opening a 
checkpoint**

**Status:** review
**Milestone:** 5.0.2
**Created:** Tue Jan 05, 2016 08:07 AM UTC by Pham Hoang Nhat
**Last Updated:** Wed May 04, 2016 05:01 PM UTC
**Owner:** Pham Hoang Nhat


The replica IMM objects are not created after opening a checkpoint in following 
scenario:

1. Open a checkpoint with flag SA_CKPT_CHECKPOINT_CREATE 
2. Unlink the checkpoint ( the checkpoint is still being used)
3. Open a checkpoint with flag SA_CKPT_CHECKPOINT_CREATE with same name as the 
on in 1. 

After 3. although the checkpoint is opened successfully, the replica IMM 
objects are not created.

Measurement:
The problem happens because the CPD doesn’t delete relating nodes from 
ckpt_reploc_tree when unlink the checkpoint in 2.


---

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] #1684 Incorrect error codes returned in IMM callbacks

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1684] Incorrect error codes returned in IMM callbacks**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Mon Feb 29, 2016 09:56 AM UTC by elunlen
**Last Updated:** Wed May 04, 2016 05:02 PM UTC
**Owner:** nobody


In the object implementer in the director (imm.cc) function 
ccb_object_create_cb() returns an invalid return code. Returns 
SA_AIS_ERR_INVALID_PARAM. This is not according to IMM AIS the return code 
shpild be SA_AIS_ERR_BAD_OPERATION.
In general the return codes for all IMM callbacks should be checked
The impact of the problem is confusing error logs


---

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] #1742 amfd: reject admin ops during headless recovery

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1742] amfd: reject admin ops during headless recovery**

**Status:** accepted
**Milestone:** 5.0.2
**Created:** Fri Apr 08, 2016 01:48 AM UTC by Gary Lee
**Last Updated:** Wed May 04, 2016 04:16 PM UTC
**Owner:** Gary Lee


During the headless recovery period (waiting for node_ups from payloads / 
adjusting assignments), admin ops should be rejected.


---

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] #1703 smfd: downgrade from 4.7 -> any previous version doesn't work

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1703] smfd: downgrade from 4.7 -> any previous version doesn't 
work**

**Status:** accepted
**Milestone:** 5.0.2
**Created:** Fri Mar 18, 2016 12:27 AM UTC by Alex Jones
**Last Updated:** Wed May 04, 2016 07:29 PM UTC
**Owner:** Alex Jones


  It looks like the issue stems from changeset f3f0141f63cf from ticket #1126. 
Looks like this was introduced in 4.7. In 4.7 
SmfCampaignThread::createImmHandle the implementor handle changed. Looks like 
it is compatible with upgrade, but not downgrade.

 It seems that if downgrade is to be supported from 4.7 to something lower 
(even 4.6), then this handle will have to use the old campaign name. Not sure 
how this would work.

  This is the error from the new active after the si-swap. This controller has 
been downgraded to 4.5.1:

Mar 15 10:15:02 q50-s2 osafsmfd[10017]: NO SmfProcedureThread::getImmProcedure, 
Using campaign IMM handle safSmfProc2
Mar 15 10:15:02 q50-s2 osafimmnd[9832]: NO ERR_BAD_OPERATION: Not a correct 
implementer handle or object 
smfCampaignRestartIndicator=smf,safApp=safSmfService is not handled by the 
provided implementer named safSmfCampaign=10.0.0.0,safApp=safSmfService 
(!=0x8df100 )
Mar 15 10:15:11 q50-s2 osafimmnd: Last message 'NO ERR_BAD_OPERATION' repeated 
9 times, suppressed by syslog-ng on q50-s2
Mar 15 10:15:11 q50-s2 osafsmfd[10017]: NO Could not remove 
OpenSafSmfCampRestart object 
dn=smfCampaignRestartIndicator=smf,safApp=safSmfService


  This is the error from the new standby after the si-swap. This controller is 
still running 4.7.0.


Mar 15 10:15:02 q50-s1 osafimmnd[45738]: NO ERR_BAD_OPERATION: Not a correct 
implementer handle or object 
smfCampaignRestartIndicator=smf,safApp=safSmfService is not handled by the 
provided implementer named safSmfCampaign=10.0.0.0,safApp=safSmfService 
(!=0x973a90 )
Mar 15 10:15:02 q50-s1 osafsmfd[45850]: NO SA_AMF_ADMIN_SI_SWAP [rc=1] 
successfully initiated
Mar 15 10:15:02 q50-s1 osafsmfd[45850]: NO Campaign thread terminated after 
SA_AMF_ADMIN_SI_SWAP
Mar 15 10:15:03 q50-s1 osafimmnd[45738]: NO ERR_BAD_OPERATION: Not a correct 
implementer handle or object 
smfCampaignRestartIndicator=smf,safApp=safSmfService is not handled by the 
provided implementer named safSmfCampaign=10.0.0.0,safApp=safSmfService 
(!=0x973a90 )


---

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] #1747 IMMND trying to start PBE process while stopping OpenSAF services

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1747] IMMND trying to start PBE process while stopping OpenSAF 
services**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Mon Apr 11, 2016 10:30 AM UTC by Chani Srivastava
**Last Updated:** Wed May 04, 2016 04:54 PM UTC
**Owner:** nobody


Setup:
Changeset- 7436
Version - opensaf 5.0
1-PBE enabled
Issue is not observed always.

Apr 11 13:32:52 OSAF-SC1 opensafd: Stopping OpenSAF Services
Apr 11 13:32:52 OSAF-SC1 osafamfnd[29960]: NO Shutdown initiated
Apr 11 13:32:52 OSAF-SC1 osafamfnd[29960]: NO Terminating all AMF components
Apr 11 13:32:52 OSAF-SC1 osafimmpbed: NO IMM PBE received SIG_TERM, closing db 
handle
Apr 11 13:32:52 OSAF-SC1 osafimmpbed: IN IMM PBE process EXITING...
Apr 11 13:32:53 OSAF-SC1 osafimmnd[29899]: NO Implementer locally disconnected. 
Marking it as doomed 18 <545, 2010f> (OpenSafImmPBE)
Apr 11 13:32:53 OSAF-SC1 osafimmnd[29899]: NO Implementer disconnected 18 <545, 
2010f> (OpenSafImmPBE)
Apr 11 13:32:53 OSAF-SC1 osafimmnd[29899]: WA Persistent back-end process has 
apparently died.
Apr 11 13:32:53 OSAF-SC1 osafimmnd[29899]: NO STARTING PBE process.
Apr 11 13:32:53 OSAF-SC1 osafimmnd[29899]: NO 
pbe-db-file-path:/home/chani/immPBE/imm.db VETERAN:1 B:0
Apr 11 13:32:53 OSAF-SC1 osafckptnd[30049]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osafsmfd[29976]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osaflckd[30057]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osafimmnd[29899]: NO Implementer locally disconnected. 
Marking it as doomed 2412 <321, 2010f> (safLckService)
Apr 11 13:32:53 OSAF-SC1 osafimmnd[29899]: NO Implementer disconnected 2412 
<321, 2010f> (safLckService)
Apr 11 13:32:53 OSAF-SC1 osaflcknd[30032]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osafclmna[29860]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osafimmd[29888]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osaffmd[29878]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osafrded[29869]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osafevtd[30088]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osafimmnd[29899]: NO Implementer locally disconnected. 
Marking it as doomed 2413 <315, 2010f> (safEvtService)
Apr 11 13:32:53 OSAF-SC1 osafckptd[30097]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osafimmnd[29899]: NO Implementer locally disconnected. 
Marking it as doomed 2411 <330, 2010f> (safCheckPointService)
Apr 11 13:32:53 OSAF-SC1 osafimmnd[29899]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osafmsgd[30011]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osafmsgnd[29995]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osafsmfnd[29978]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osaflogd[29914]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osafntfimcnd[5780]: NO saImmOiDispatch() Fail 
SA_AIS_ERR_BAD_HANDLE (9)
Apr 11 13:32:53 OSAF-SC1 osafclmd[29940]: exiting for shutdown
Apr 11 13:32:53 OSAF-SC1 osafimmpbed: IN arg[0] == 
'/usr/lib64/opensaf/osafimmpbed'
Apr 11 13:32:53 OSAF-SC1 osafimmpbed: IN arg[1] == '--recover'
Apr 11 13:32:53 OSAF-SC1 osafimmpbed: IN arg[2] == '--pbe'
Apr 11 13:32:53 OSAF-SC1 osafimmpbed: IN arg[3] == '/home/chani/immPBE/imm.db'
Apr 11 13:32:53 OSAF-SC1 osafimmpbed: ER osafimmpbe is not started by osafimmnd



---

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

- **Milestone**: 5.0.1 --> 5.0.2



---

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

**Status:** assigned
**Milestone:** 5.0.2
**Created:** Fri Apr 29, 2016 07:24 AM UTC by Srikanth R
**Last Updated:** Wed May 04, 2016 05:13 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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1797 Spare controller failed to become active when both ACTIVE and STANDBY SC rebooted

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1797] Spare controller failed to become active when both ACTIVE 
and STANDBY SC rebooted**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Fri Apr 29, 2016 09:36 AM UTC by Ritu Raj
**Last Updated:** Wed May 04, 2016 05:12 PM UTC
**Owner:** nobody


setup:
Changeset- 7436
Version - opensaf 5.0 FC

* Issue Observed:
Spare controller failed to become active when both ACTIVE and STANDBY SC 
rebooted resulted cluster reset.

* Steps To Reproduce:
1. Brought up cluster, where SC-1 took active role SC-2 standby and SC-3 in 
quiesced state, PL-6 and PL-7 are payloads.
2. Kill any director of active and standby followed by 2 second
3. Observed that quiesced controller failed to took active role and cluster 
reset happened

>>
SCALE_SLOT-93:~ # May  2 18:25:33 SCALE_SLOT-93 osafimmnd[1767]: NO Implementer 
disconnected 5 <0, 2010f> (safAmfService)
May  2 18:25:34 SCALE_SLOT-93 osafamfnd[1817]: WA AMF director unexpectedly 
crashed
May  2 18:25:34 SCALE_SLOT-93 osafamfnd[1817]: Rebooting OpenSAF NodeId = 
131855 EE Name = , Reason: local AVD down(Adest) or both AVD down(Vdest) 
received, OwnNodeId = 131855, SupervisionTime = 60
May  2 18:25:34 SCALE_SLOT-93 osafimmnd[1767]: NO Implementer disconnected 17 
<0, 2020f> (@safAmfService2020f)
May  2 18:25:34 SCALE_SLOT-93 opensaf_reboot: Rebooting local node; timeout=60
May  2 18:25:38 SCALE_SLOT-93 kernel: [273050.885507] md: stopping all md 
devices.
May  2 18:25:38 SCALE_SLOT-93 kernel: [273051.878473] sd 0:0:0:0: [sda] 
Synchronizing SCSI cache
<<



---

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] #1812 amfd: saClmDispatch FAILED on newly promoted SC

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1812] amfd: saClmDispatch FAILED on newly promoted SC**

**Status:** accepted
**Milestone:** 5.0.2
**Created:** Fri May 06, 2016 05:56 AM UTC by Gary Lee
**Last Updated:** Thu Jul 14, 2016 04:59 AM UTC
**Owner:** Gary Lee
**Attachments:**

- 
[amfd_coredump_bt.txt](https://sourceforge.net/p/opensaf/tickets/1812/attachment/amfd_coredump_bt.txt)
 (8.0 kB; text/plain)


Enable headless and roaming features. Then:

Stop active SC (SC-1) and then standby SC (SC-2)

On the newly promoted SC, saClmDispatch FAILED 9 can be seen followed by a 
coredump.

2016-05-04 05:33:48 SC-5 osafamfd[474]: ER main: saClmDispatch FAILED 9




---

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] #1815 mds: suspected message loss in large cluster deployments

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1815] mds: suspected message loss in large cluster deployments**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Mon May 09, 2016 06:45 AM UTC by Gary Lee
**Last Updated:** Fri May 13, 2016 05:56 AM UTC
**Owner:** nobody


It has been observed that CLM callbacks to amfd can become 'lost'
in a large cluster. It seems to be occurring in MDS, when the callbacks are
sent around the same time as amfd is calling avd_imm_config_get().

It seems avd_imm_config_get() generates a large
amount of traffic through MDS.


---

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] #1869 AMF: SG in unstable for SI lock operation, after HEADLESS

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1869] AMF: SG in unstable for SI lock operation, after HEADLESS **

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Thu Jun 09, 2016 07:24 AM UTC by Srikanth R
**Last Updated:** Thu Jun 09, 2016 08:01 AM UTC
**Owner:** nobody


Opensaf version : 5.0. GA.
Setup : 5 nodes with 3 controllers. PL-5, PL-4  hosted active, standby 
assignments for application 2n SU. where as SC-3 hosted spare SU.

Steps performed:

-> Brought down all the controllers and headless scenario is created.
->Now stopped opensafd on PL-5, where SU2 is hosting active assignment 
-> SU1 on PL-4 did not get active assignment. It remained in standby assignment.
-> After the controllers joined back the cluster, following is the error 
message printed on the PL-4. 

Aug 26 17:21:34 SCALE_SLOT-94 osafamfnd[19347]: CR SU-SI record addition 
failed, SU= safSu=SU1,safSg=AmfDemo,safApp=AmfDemo : 
SI=safSi=AmfDemo,safApp=AmfDemo


SCALE_SLOT-94:~ # immlist safSi=AmfDemo,safApp=AmfDemo
Name   Type Value(s)
saAmfSIPrefStandbyAssignments  SA_UINT32_T  1 (0x1)
saAmfSIPrefActiveAssignments   SA_UINT32_T  1 (0x1)
saAmfSINumCurrStandbyAssignments   SA_UINT32_T  2 (0x2)
saAmfSINumCurrActiveAssignmentsSA_UINT32_T  0 (0x0)
saAmfSIAssignmentState SA_UINT32_T  3 (0x3)


-> Lock operation on SI resulted in SG unstable operation. 


46 04:30:46 07/23/2016 NO safApp=safAmfService "Cluster startup 
timeout, assigning SIs to SUs"
47 04:30:46 07/23/2016 NO safApp=safAmfService 
"safSi=AmfDemo,safApp=AmfDemo assigned to 
safSu=SU1,safSg=AmfDemo,safApp=AmfDemo HA State 'STANDBY'"
48 04:30:46 07/23/2016 NO safApp=safAmfService "Autorepair not done for 
'safSu=SC-3,safSg=2N,safApp=OpenSAF'"
49 04:30:46 07/23/2016 NO safApp=safAmfService "Autorepair not done for 
'safSu=SU3_Spare,safSg=AmfDemo,safApp=AmfDemo'"
50 07:49:21 07/23/2016 NO safApp=safAmfService "Admin op "LOCK" 
initiated for 'safSi=AmfDemo,safApp=AmfDemo', invocation: 219043332097"
51 07:49:21 07/23/2016 NO safApp=safAmfService "Admin op invocation: 
219043332097, err: 'SI lock of 'safSi=AmfDemo,safApp=AmfDemo' failed, SG not 
stable'"
52 07:49:21 07/23/2016 NO safApp=safAmfService "Admin op done for 
invocation: 219043332097, result 6"
53 07:49:22 07/23/2016 NO safApp=safAmfService "Admin op "LOCK" 
initiated for 'safSi=AmfDemo,safApp=AmfDemo', invocation: 2190


---

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] #1857 amf: spare controller didnot get rebooted when amfd is killed on spare controller with headless feature enabled.

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1857] amf: spare controller didnot get rebooted when amfd is 
killed on spare controller with headless feature enabled.**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Wed Jun 01, 2016 07:48 AM UTC by Madhurika Koppula
**Last Updated:** Wed Jun 01, 2016 07:48 AM UTC
**Owner:** nobody


Setup:  Brought up 5 nodes cluster (Active, standby, spare controllers, PL-4 
and PL-5 ) with headless feature enabled.

spare controller didnot get rebooted when amfd is killed on spare controller.


---

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] #1867 HEADLESS : Payloads went for reboot, in headless state as CPSV got TIMEOUT rc for CLM API

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1867] HEADLESS : Payloads went for reboot, in headless state as 
CPSV got TIMEOUT rc for CLM API**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Wed Jun 08, 2016 10:54 AM UTC by Srikanth R
**Last Updated:** Wed Jun 08, 2016 10:54 AM UTC
**Owner:** nobody


Version : Opensaf 5.0. GA
Setup : Two payloads with three controllers.

 Steps performed :
 
 -> Initially all the nodes are part of the cluster.
 -> Induced failover by bringing down active, standby and spare in the order.
 Aug  7 20:30:08 SCALE_SLOT-94 kernel: [5993776.936794] TIPC: Lost contact with 
<1.1.1>
Aug  7 20:30:08 SCALE_SLOT-94 osafimmnd[2748]: NO Sleep done registering IMMND 
with MDS
Aug  7 20:30:08 SCALE_SLOT-94 osafimmnd[2748]: NO MDS: mds_register_callback: 
dest 2040fa5bb6016 already exist
Aug  7 20:30:08 SCALE_SLOT-94 osafimmnd[2748]: NO SUCCESS IN REGISTERING IMMND 
WITH MDS
Aug  7 20:30:08 SCALE_SLOT-94 osafimmnd[2748]: NO Re-introduce-me 
highestProcessed:6859 highestReceived:6859
Aug  7 20:30:13 SCALE_SLOT-94 osafimmnd[2748]: WA MDS Send Failed to 
service:IMMD rc:2
Aug  7 20:30:14 SCALE_SLOT-94 osafamfnd[2767]: WA AMF director unexpectedly 
crashed

 -> On the both payloads, CKPTND restarted with the following error in syslog.
 
 Aug  7 20:30:17 SCALE_SLOT-94 osafckptnd[2787]: ER cpnd clm node get failed 
with return value:5
Aug  7 20:30:17 SCALE_SLOT-94 osafamfnd[2767]: NO 
'safComp=CPND,safSu=PL-4,safSg=NoRed,safApp=OpenSAF' faulted due to 'avaDown' : 
Recovery is 'componentRestart'
Aug  7 20:30:17 SCALE_SLOT-94 osafckptnd[14434]: Started

-> But CKPTND Instantation failed and finally the node went for reboot.

Aug  7 20:30:27 SCALE_SLOT-94 osafimmnd[2748]: NO Re-introduce-me 
highestProcessed:6859 highestReceived:6859
Aug  7 20:30:27 SCALE_SLOT-94 osafimmnd[2748]: WA MDS Send Failed to 
service:IMMD rc:2
Aug  7 20:30:27 SCALE_SLOT-94 osafamfnd[2767]: NO Instantiation of 
'safComp=CPND,safSu=PL-4,safSg=NoRed,safApp=OpenSAF' failed
Aug  7 20:30:27 SCALE_SLOT-94 osafamfnd[2767]: NO Reason: component 
registration timer expired
Aug  7 20:30:27 SCALE_SLOT-94 osafckptnd[14451]: Started
...

Aug  7 20:30:38 SCALE_SLOT-94 osafamfnd[2767]: NO Instantiation of 
'safComp=CPND,safSu=PL-4,safSg=NoRed,safApp=OpenSAF' failed
Aug  7 20:30:38 SCALE_SLOT-94 osafamfnd[2767]: NO Reason: component 
registration timer expired
Aug  7 20:30:38 SCALE_SLOT-94 osafimmnd[2748]: NO Re-introduce-me 
highestProcessed:6859 highestReceived:6859
Aug  7 20:30:38 SCALE_SLOT-94 osafimmnd[2748]: WA MDS Send Failed to 
service:IMMD rc:2
Aug  7 20:30:38 SCALE_SLOT-94 osafamfnd[2767]: WA 
'safComp=CPND,safSu=PL-4,safSg=NoRed,safApp=OpenSAF' Presence State RESTARTING 
=> INSTANTIATION_FAILED
Aug  7 20:30:38 SCALE_SLOT-94 osafamfnd[2767]: NO avnd_di_oper_send() deferred 
as AMF director is offline
Aug  7 20:30:38 SCALE_SLOT-94 osafamfnd[2767]: WA Director is down. Remove all 
SIs from 'safSu=PL-4,safSg=NoRed,safApp=OpenSAF'
Aug  7 20:30:38 SCALE_SLOT-94 osafamfnd[2767]: NO Component Failover trigerred 
for 'safSu=PL-4,safSg=NoRed,safApp=OpenSAF': Failed component: 
'safComp=CPND,safSu=PL-4,safSg=NoRed,safApp=OpenSAF'
Aug  7 20:30:38 SCALE_SLOT-94 osafamfnd[2767]: ER 
'safComp=CPND,safSu=PL-4,safSg=NoRed,safApp=OpenSAF'got Inst failed
Aug  7 20:30:38 SCALE_SLOT-94 osafamfnd[2767]: Rebooting OpenSAF NodeId = 
132111 EE Name = , Reason: NCS component Instantiation failed, OwnNodeId = 
132111, SupervisionTime = 60



---

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] #1872 smf: ER messages when handling smfnd node up

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1872] smf: ER messages when handling smfnd node up**

**Status:** accepted
**Milestone:** 5.0.2
**Created:** Fri Jun 10, 2016 08:41 AM UTC by elunlen
**Last Updated:** Fri Jun 10, 2016 08:41 AM UTC
**Owner:** elunlen


The following error messages is written in syslog:
2016-05-09 21:47:01 SC-2 osafsmfd[595]: ER saClmClusterNodeGet failed, 
rc=SA_AIS_ERR_NOT_EXIST (12)
2016-05-09 21:47:01 SC-2 osafsmfd[595]: ER node id [2030f] not found for state 
update DOWN

This happen when MDS detects node up but when SMF asks CLM for node information 
for the node it is down again resuling in a NOT EXIST answer from CLM


---

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] #1885 CLM : LIbrary gives false success for couple of APIs , once controller joins back from headless

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1885] CLM : LIbrary gives false success for couple of APIs , once 
controller joins back from headless**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Mon Jun 20, 2016 09:17 AM UTC by Srikanth R
**Last Updated:** Mon Jun 20, 2016 09:18 AM UTC
**Owner:** nobody


Setup : 
5 nodes setup with 3 controllers.
Version : opensaf 5.0 GA


Steps performed :

-> Invoke saClmInitialize_4
-> Create a thread by calling saClmDispatch with DISPATCH_BLOCKING as argument.
-> Invoke saClmClusterNodeGet_4 
-> Create headless state.
-> Invoke saClmClusterTrack_4 with TRACK_CURRENT and TRACK_START_STEP
-> Invoke saClmClusterNodeGet_4 

Observed behavior :


 The first three apis successfully returned SA_AIS_OK. 
 
 Once the headless scenario is induced, saClmClusterTrack_4 api returned 
TRY_AGAIN until one of the controller joined as active controller. Here the api 
returned SA_AIS_OK, but  no callback with CURRENT nodes info is delivered. 

 The thread in which Dispatch is called, returned with SA_AIS_OK. 
 
Even though internally, the handle is marked as BAD_HANDLE. The subsequent 
calls to saClmClusterTrack and saClmClusterNodeGet_4  returned successfully.


Aug  2 19:36:22.990719 clma [10058:clma_api.c:1035] TR RC before give handle 
flagsTrack 6
Aug  2 19:36:22.990730 clma [10058:clma_api.c:1038] << clmaclustertrack
Aug  2 19:36:22.990740 clma [10058:clma_api.c:0938] << saClmClusterTrack_4
Aug  2 19:36:26.998572 clma [10058:clma_api.c:0934] >> saClmClusterTrack_4
Aug  2 19:36:26.998625 clma [10058:clma_api.c:0968] >> clmaclustertrack
Aug  2 19:36:26.998636 clma [10058:clma_api.c:0986] TR CLMS down
Aug  2 19:36:26.998642 clma [10058:clma_api.c:1035] TR RC before give handle 
flagsTrack 6
Aug  2 19:36:26.998648 clma [10058:clma_api.c:1038] << clmaclustertrack
Aug  2 19:36:26.998657 clma [10058:clma_api.c:0938] << saClmClusterTrack_4
Aug  2 19:36:30.837965 clma [10058:clma_mds.c:0947] T2 CLMA Rcvd MDS subscribe 
evt from svc 34
Aug  2 19:36:30.837983 clma [10058:clma_mds.c:0978] T2 MSG from CLMS 
NCSMDS_NEW_ACTIVE/UP
Aug  2 19:36:30.837989 clma [10058:clma_mds.c:0989] TR ** Marking handle as 
BAD**
Aug  2 19:36:30.839058 clma [10058:sysf_ipc.c:0363] TR IN LEAP_DBG_SINK
Aug  2 19:36:30.839070 clma [10058:clma_util.c:0625] << clma_hdl_cbk_dispatch
Aug  2 19:36:30.839076 clma [10058:clma_api.c:0793] << saClmDispatch
Aug  2 19:36:31.259065 clma [10058:clma_api.c:0934] >> saClmClusterTrack_4
Aug  2 19:36:31.259088 clma [10058:clma_api.c:0968] >> clmaclustertrack
Aug  2 19:36:31.259097 clma [10058:clma_util.c:0036] >> clma_validate_version
Aug  2 19:36:31.259103 clma [10058:clma_util.c:0042] << clma_validate_version
Aug  2 19:36:31.259108 clma [10058:clma_api.c:1009] TR B.4.1 version
Aug  2 19:36:31.259113 clma [10058:clma_api.c:0140] >> 
clma_validate_flags_buf_4: flags=0x15
Aug  2 19:36:31.259118 clma [10058:clma_api.c:0176] << clma_validate_flags_buf_4
Aug  2 19:36:31.259124 clma [10058:clma_api.c:1020] TR RC after validate 
flagsTrack 1
Aug  2 19:36:31.259129 clma [10058:clma_util.c:0036] >> clma_validate_version
Aug  2 19:36:31.259140 clma [10058:clma_util.c:0042] << clma_validate_version
Aug  2 19:36:31.259145 clma [10058:clma_mds.c:1274] >> clma_mds_msg_async_send
Aug  2 19:36:31.259158 clma [10058:clma_mds.c:0317] >> clma_mds_enc
Aug  2 19:36:31.259166 clma [10058:clma_mds.c:0352] T2 msgtype: 0
Aug  2 19:36:31.259171 clma [10058:clma_mds.c:0366] T2 api_info.type: 2
Aug  2 19:36:31.259177 clma [10058:clma_mds.c:0118] >> clma_enc_track_start_msg
Aug  2 19:36:31.259182 clma [10058:clma_mds.c:0134] << clma_enc_track_start_msg
Aug  2 19:36:31.259187 clma [10058:clma_mds.c:0407] << clma_mds_enc
Aug  2 19:36:31.259260 clma [10058:clma_mds.c:1296] << clma_mds_msg_async_send
Aug  2 19:36:31.259272 clma [10058:clma_api.c:0455] << clma_send_md

 If Dispatch api is called once AGAIN after the controller joins , BAD_HANDLE 
is returned.
 
 
 Expected behavior :
 
  If the handle is marked as BAD internally, the apis saClmClusterTrack_4 and 
saClmClusterNodeGet_4 should also return BAD_HANDLE once the controller joins 
back. Currently Dispatch returns 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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1886 CLM : Initialize API returns 31, once controllers join back from headless

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1886] CLM : Initialize API returns 31, once controllers  join back 
from headless**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Mon Jun 20, 2016 10:32 AM UTC by Srikanth R
**Last Updated:** Mon Jun 20, 2016 10:32 AM UTC
**Owner:** nobody
**Attachments:**

- 
[clmd_1888](https://sourceforge.net/p/opensaf/tickets/1886/attachment/clmd_1888)
 (490.9 kB; application/octet-stream)


setup:
Version - opensaf 5.0.GA
5-Node cluster( 3 controllers and  PL:4,PL-5 Payloads)

Create headless scenario and call saClmInitialize_4 api on a healthy payload 
PL-5.

The saClmInitialize_4 should return TRY_AGAIN untill the controllers are up.

In some cases, 31 return code is returned. This is observed 2 out of 5 times.


MBCSV:MBCA:OFF
Aug  2 20:56:58.379408 clma [13326:clma_mds.c:1124] >> clma_mds_init
Aug  2 20:56:58.379582 clma [13326:clma_mds.c:1170] << clma_mds_init
Aug  2 20:57:26.122341 clma [13326:clma_mds.c:0947] T2 CLMA Rcvd MDS subscribe 
evt from svc 34
Aug  2 20:57:26.122361 clma [13326:clma_mds.c:0978] T2 MSG from CLMS 
NCSMDS_NEW_ACTIVE/UP
Aug  2 20:57:26.123651 clma [13326:clma_util.c:0120] << clma_startup: rc: 1, 
clma_use_count: 1
Aug  2 20:57:26.123665 clma [13326:clma_mds.c:1227] >> clma_mds_msg_sync_send
Aug  2 20:57:26.123704 clma [13326:clma_mds.c:0317] >> clma_mds_enc
Aug  2 20:57:26.123717 clma [13326:clma_mds.c:0352] T2 msgtype: 0
Aug  2 20:57:26.123723 clma [13326:clma_mds.c:0366] T2 api_info.type: 0
Aug  2 20:57:26.123729 clma [13326:clma_mds.c:0045] >> clma_enc_initialize_msg
Aug  2 20:57:26.123735 clma [13326:clma_mds.c:0060] << clma_enc_initialize_msg
Aug  2 20:57:26.123742 clma [13326:clma_mds.c:0407] << clma_mds_enc
Aug  2 20:57:26.152653 clma [13326:clma_mds.c:0697] >> clma_mds_dec
Aug  2 20:57:26.152674 clma [13326:clma_mds.c:0729] T2 CLMSV_CLMA_API_RESP_MSG 
rc = 31
Aug  2 20:57:26.152682 clma [13326:clma_mds.c:0809] << clma_mds_dec
Aug  2 20:57:26.152717 clma [13326:clma_mds.c:1253] << clma_mds_msg_sync_send
Aug  2 20:57:26.152728 clma [13326:clma_api.c:0636] TR CLMS return FAILED
Aug  2 20:57:26.152752 clma [13326:clma_util.c:0656] >> clma_msg_destroy
Aug  2 20:57:26.153200 clma [13326:clma_util.c:0680] << clma_msg_destroy
Aug  2 20:57:26.153219 clma [13326:clma_api.c:0663] T2 CLMA INIT FAILED
Aug  2 20:57:26.153226 clma [13326:clma_util.c:0133] >> clma_shutdown: 
clma_use_count: 1
Aug  2 20:57:26.153232 clma [13326:clma_mds.c:1190] >> clma_mds_finalize
Aug  2 20:57:26.153412 clma [13326:clma_mds.c:1203] << clma_mds_finalize
Aug  2 20:57:26.153580 clma [13326:sysf_def.c:0153] TR DESTROYING LEAP 
ENVIRONMENT
Aug  2 20:57:26.153663 clma [13326:sysf_def.c:0170] TR DONE DESTROYING LEAP 
ENVIRONMENT
Aug  2 20:57:26.153679 clma [13326:clma_util.c:0146] << clma_shutdown: rc: 1, 
clma_use_count: 0
Aug  2 20:57:26.153686 clma [13326:clma_api.c:0668] << clmainitialize
Aug  2 20:57:26.153692 clma [13326:clma_api.c:0580] << saClmInitialize_4


CLM director trace on new active controller is attached.


---

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] #1889 Immnd crashed on Payload during headless operation

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1889] Immnd crashed on Payload during headless operation**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Tue Jun 21, 2016 09:50 AM UTC by Ritu Raj
**Last Updated:** Wed Jul 27, 2016 11:49 AM UTC
**Owner:** nobody
**Attachments:**

- 
[SC-1.tar.bz2](https://sourceforge.net/p/opensaf/tickets/1889/attachment/SC-1.tar.bz2)
 (7.6 MB; application/x-bzip)
- 
[SCALE_SLOT-75.tar.bz2](https://sourceforge.net/p/opensaf/tickets/1889/attachment/SCALE_SLOT-75.tar.bz2)
 (4.8 MB; application/x-bzip)


setup:
Version - opensaf 5.0.GA
6-Node cluster(SC-1:Active, SC-2:Standby, SC-3:Spare PL:4,PL-5: Payloads)

* Issue Observed:
Immnd crashed on Payload during headless operation

* Steps performed: 
(1). Invoke headless 
(2). Created logsv application stream after headless
(3). Closed the stream after performing write operation
(4). While reverting back to default configuration one of the CCB operation 
failed

>> SCALE_SLOT-75 osafimmnd[18906]: WA ERR_FAILED_OPERATION: ccb 1 is not in an 
>> expected state: 11 rejecting ccbObjectModify operation
>>
immcfg -a saLogStreamLogFullAction=3 
safLgStrCfg=saLogNotification,safApp=safLogService
error - saImmOmCcbObjectModify_2 FAILED: SA_AIS_ERR_FAILED_OPERATION (21)
OI reports: IMM: Resource abort: CCB is not in an expected state
error - saImmOmCcbApply FAILED: SA_AIS_ERR_FAILED_OPERATION (21)

(5). On invoking second headless immnd crashed on both the payload

>>
Jun 21 14:27:53 SCALE_SLOT-75 osafimmnd[18906]: ImmModel.cc:648: 
immModel_abortNonCriticalCcbs: **Assertion 'immModel_ccbAbort(cb, (*i3)->mId, 
, , , , , )' 
failed**.
Jun 21 14:27:53 SCALE_SLOT-75 osafamfnd[18925]: NO 
'safSu=PL-5,safSg=NoRed,safApp=OpenSAF' component restart probation timer 
started (timeout: 600 ns)
Jun 21 14:27:53 SCALE_SLOT-75 osafamfnd[18925]: NO Restarting a component of 
'safSu=PL-5,safSg=NoRed,safApp=OpenSAF' (comp restart count: 1)
Jun 21 14:27:53 SCALE_SLOT-75 osafamfnd[18925]: NO 
'**safComp=IMMND,safSu=PL-5,safSg=NoRed,safApp=OpenSAF' faulted** due to 
'avaDown' : Recovery is 'componentRestart'
Jun 21 14:27:53 SCALE_SLOT-75 osafimmnd[19167]: Started


* Syslog and Immnd trace file is attached


---

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] #1956 IMM: AugmentCcbInitialize crashed when called inside completed callback

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1956] IMM: AugmentCcbInitialize crashed when called inside 
completed callback**

**Status:** accepted
**Milestone:** 5.0.2
**Created:** Wed Aug 17, 2016 12:22 PM UTC by Chani Srivastava
**Last Updated:** Tue Aug 30, 2016 05:58 AM UTC
**Owner:** Neelakanta Reddy
**Attachments:**

- 
[AugInit.7z](https://sourceforge.net/p/opensaf/tickets/1956/attachment/AugInit.7z)
 (1.3 MB; application/octet-stream)


Opensaf Version 5.0
immnd traces and coredump attached

###0  0x7fa056226b55 in raise () from /lib64/libc.so.6
###1  0x7fa056228131 in abort () from /lib64/libc.so.6
###2  0x7fa0559ac08e in getAdmoName () from /usr/lib64/libSaImmOi.so.0
###3  0x7fa0559acb48 in saImmOiAugmentCcbInitialize () from 
/usr/lib64/libSaImmOi.so.0
###4  0x7fa055fda86f in _wrap_saImmOiAugmentCcbInitialize () at 
saImmOiA211_wrap.c:5917
###5  0x00418243 in PyObject_Call (func=0x4d8f, arg=0x4d8f, kw=0x6) at 
Objects/abstract.c:1860
###6  0x00487437 in ext_do_call (nk=, na=, flags=, pp_stack=, func=)
at Python/ceval.c:3846




---

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] #1961 Issues in Opensaf PLMS services with openHPI

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1961] Issues in Opensaf PLMS services with openHPI**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Fri Aug 19, 2016 07:59 PM UTC by Subrata Nath
**Last Updated:** Thu Sep 01, 2016 06:54 PM UTC
**Owner:** nobody


Hello,

I have installed opensaf 5.0.0 without the PLMS fine for contoller node HA 
purpose and it's works fine. Now I would like to use opensaf PLMS with the 
openHPI.  

My configure script command is  -

./configure CPPFLAGS=-DRUNASROOT OSAF_HARDEN_FLAGS="-fstack-protector-all 
-D_FORTIFY_SOURCE=2" HPI_LIBS="-L/usr/local/lib -lopenhpimarshal -lopenhpiutils 
-lopenhpi" --enable-hpi --with-openhpi --with-hpi-interface=B03 
--enable-tipc=yes --enable-imm-pbe=yes --enable-ais-plm --enable-ais-smf 
--enable-ais-msg --enable-ais-lck --enable-ais-evt --enable-ais-ckpt 
--enable-ntf-imcn 

Following issue is observed. have made a work around code fix but i would like 
to check if these issues were found already and fix is planned in next releases 
-

 opensaf-5.0.0/osaf/services/saf/plmsv/plms/plms_main.c the global declaration 
of 

*static PLMSCB  _plms_cb;
PLMSCB *plms_cb = &_plms_cb;

is being masked out by the line 558 in 
/opensaf-5.0.0/osaf/libs/common/plmsv/include/plms.h which declares the same 
var. So with this, /osaf/services/saf/plmsv/plms/hpi_intf/hpi_hsm getting NULL 
value for the plms_cb pointer.

Similar issue is applicable for the following global variable as well 

HSM_HA_STATE hsm_ha_state = {PTHREAD_MUTEX_INITIALIZER,
 PTHREAD_COND_INITIALIZER,
 SA_AMF_HA_ACTIVE};
HRB_HA_STATE hrb_ha_state = {PTHREAD_MUTEX_INITIALIZER,
 PTHREAD_COND_INITIALIZER,
 SA_AMF_HA_ACTIVE};
  
They are defined in plms.h without extern and hence 
/osaf/services/saf/plmsv/plms/hpi_intf/hpi_hsm.c or plms_hrb.c, is not able to 
find the same values as assigined by plms_main.c

WA fix i made is as described below. But please let me know if it's known issue 
or not and if there is any correction in upcoming releases.

1.  Declare with extern in 
opensaf-5.0.0/osaf/libs/common/plmsv/include/plms.h.
2.  Make the two separate global copies with the same name – one in 
osaf/services/saf/plmsv/plms/plms_main.c (PLMS_CB *plms_cb; ) and another one 
in 
/home/system/opensaf-5.0.0/osaf/services/saf/plmsv/plms/hpi_intf/plms_hsm.c(PLMS_CB
 *plms_cb;). So all the files in osaf/services/saf/plmsv/plms/ will see the 
global copy from osaf/services/saf/plmsv/plms/plms_main.c and all the files 
under 5.0.0/osaf/services/saf/plmsv/plms/hpi_intf/ will see the global copy in 
5.0.0/osaf/services/saf/plmsv/plms/hpi_intf/plms_hsm.c.
3.  Now osaf/services/saf/plmsv/plms/plms_main.c allocates the memory for 
it’s own copy of the global variable and during the first function call to 
5.0.0/osaf/services/saf/plmsv/plms/hpi_intf/plms_hsm.c, pass the point as 
pointer argument.  This function parameter now assigned to the 
5.0.0/osaf/services/saf/plmsv/plms/hpi_intf/plms_hsm.c – global variable. 

SaUint32T plms_hsm_initialize(PLMS_HPI_CONFIG *hpi_cfg,PLMS_CB 
**plms_cb1) ---newly added parameters
 {
 plms_cb = *plms_cb1;
 

4.  Now both the global variables are pointing to the same memory location.

Similar correction is made for HSM_HA_STATE hsm_ha_state and HRB_HA_STATE 
hrb_ha_state as well.

Regards,
Subrata




---

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] #1969 smf: One step upgrade with cluster reboot does not wait for nodes to start

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#1969] smf: One step upgrade with cluster reboot does not wait for 
nodes to start**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Wed Aug 24, 2016 01:01 PM UTC by elunlen
**Last Updated:** Thu Sep 15, 2016 10:36 AM UTC
**Owner:** nobody


When using the one step upgrade feature with a cluster reboot all nodes will 
restart including the SC-nodes. This is done as the last action in the upgrade 
step. After the active SC-node is up again SMF will continue with the procedure 
wrapup. When collecting information in order to prepare the wrapup the node 
destination for all nodes in the campaign is requested. However this 
information can only be collected from nodes that are started and has joined 
the cluster (unlocked).
The problem is that SMF does not seems wait in order to give all nodes a chance 
to join the cluster and if SMF fails to get node destination from any of the 
nodes the campaign will fail as seen in the log below. When reading node 
destination there is a 10 sec “try again” loop waiting for “node up” for each 
node. It is not unlikely that the active SC-node comes up before some of the 
other nodes and that it will take more than 10 sec after that before some of 
the other nodes joins the cluster. If that's the case the campaign will fail


---

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] #2028 log: write_log_record_hdl get bad file descriptor

- **Milestone**: 5.0.1 --> 5.0.2



---

** [tickets:#2028] log: write_log_record_hdl get bad file descriptor**

**Status:** review
**Milestone:** 5.0.2
**Created:** Tue Sep 13, 2016 09:54 AM UTC by Vu Minh Nguyen
**Last Updated:** Wed Sep 14, 2016 02:37 AM UTC
**Owner:** Vu Minh Nguyen


In current code, logsv passes the `WRITE REQUEST` to the handle thread even the 
file descriptor is invalid.
Here is some code of log_stream_write_h()@lgs_stream.cc
``` C
log_initiate_stream_files(stream);

if (*stream->p_fd == -1) {
  TRACE("%s - Initiating stream files \"%s\" Failed", __FUNCTION__,
stream->name.c_str());
} else {
  TRACE("%s - stream files initiated", __FUNCTION__);
}
```
In that case - `p_fd = -1`, `log_stream_write_h` should inform the client 
TRY_AGAIN.

Besides, there is an other problem at file closing. Look at the functions 
`fileclose_hdl` and `fileclose_h`.  The file descriptor should be set to 
`invalid` in `fileclose_hdl`,  otherwise `close file` request will re-send to 
the file handle thread even that file is already closed. 

Above cases usually happens when the file sytem is busy.  Extract from syslog:

> 2016-07-02 00:32:48 SC-1 osaflogd[460]: NO fileclose failed Device or 
> resource busy
> 2016-07-02 00:32:50 SC-1 osaflogd[460]: NO fileclose failed Device or 
> resource busy
> 2016-07-02 00:32:52 SC-1 osaflogd[460]: ER write_log_record_hdl - write 
> FAILED: Bad file descriptor





---

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] #2049 smf: Delete node group if already exist when creating

- **Milestone**: 5.1.RC2 --> 5.1.0



---

** [tickets:#2049] smf: Delete node group if already exist when creating**

**Status:** accepted
**Milestone:** 5.1.0
**Created:** Mon Sep 19, 2016 12:52 PM UTC by elunlen
**Last Updated:** Mon Sep 19, 2016 12:52 PM UTC
**Owner:** elunlen


If for some reason a node a node group for admin operation already exist when 
trying to create one the existing node group shall be deleted and a new attempt 
to create the node group shall be done


---

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] #2046 smf: Recreate IMM handles if bad handle when deleting node group

- **Milestone**: 5.1.RC2 --> 5.1.0



---

** [tickets:#2046] smf: Recreate IMM handles if bad handle when deleting node 
group**

**Status:** accepted
**Milestone:** 5.1.0
**Created:** Mon Sep 19, 2016 11:23 AM UTC by elunlen
**Last Updated:** Mon Sep 19, 2016 11:23 AM UTC
**Owner:** elunlen


When doing an admin operation on AMF a fail may cause the handles that was 
created when the admin operation C++ object was created to be invalid. If that 
happen a node group that was created before the admin operation cannot be 
deleted, will fail with bad handle.
The node group must always be deleted.
The deleteNodeGroup() method must be fixed so that if the delete operation 
fails with bad handles new handles has to be created so that the node group can 
be deleted


---

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] #2033 AMF: Update documentation for admin op continuation after headless

- **Milestone**: 5.1.RC2 --> 5.1.0



---

** [tickets:#2033] AMF: Update documentation for admin op continuation after 
headless**

**Status:** assigned
**Milestone:** 5.1.0
**Created:** Wed Sep 14, 2016 06:09 AM UTC by Minh Hon Chau
**Last Updated:** Wed Sep 14, 2016 06:09 AM UTC
**Owner:** Minh Hon Chau


Need to update README/PR doc for #1987 (fixed) and maybe #1988 (review)


---

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] #2043 log: ER no stream exists

- **Milestone**: 5.1.RC2 --> 5.1.1



---

** [tickets:#2043] log: ER no stream exists**

**Status:** review
**Milestone:** 5.1.1
**Created:** Mon Sep 19, 2016 05:20 AM UTC by Vu Minh Nguyen
**Last Updated:** Mon Sep 19, 2016 09:10 AM UTC
**Owner:** Vu Minh Nguyen


Logsv used following code to iterate all existing log streams:

```C
  /* check existing streams */
  num = get_number_of_streams();
  stream = log_stream_get_by_id(--num);
  if (!stream)
LOG_ER("No streams exist!");
  while (stream != NULL) {
stream = log_stream_get_by_id(--num);
  }
```

If we create 02 log streams, then delete them in the following order, above 
code will run incorrectly.

1) Create streamA
2) Create streamB
3) Delete streamA
4) Reboot active node

We will get following in syslog:

> Sep 19 12:08:22 SC-2 local0.err osaflogd[453]: ER No streams exist!



---

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] #1997 IMM: immnd fails to update si while bringing up opensaf with 2PBE

- **Milestone**: 5.1.RC2 --> 5.1.1



---

** [tickets:#1997] IMM: immnd fails to update si while bringing up opensaf with 
2PBE**

**Status:** assigned
**Milestone:** 5.1.1
**Created:** Fri Sep 02, 2016 11:46 AM UTC by Chani Srivastava
**Last Updated:** Tue Sep 20, 2016 08:25 AM UTC
**Owner:** Long HB Nguyen
**Attachments:**

- 
[LogAMF.zip](https://sourceforge.net/p/opensaf/tickets/1997/attachment/LogAMF.zip)
 (432.4 kB; application/zip)


setup:
Version - OpenSAF 5.1.FC : changeset - 7997
4-Node cluster
2PBE enabled

Bring up opensaf on a controller with 2PBE enable. IMMND throwing error
Attachments: syslog, amfd and immnd traces

Sep  2 16:54:13 SLOT1 osafimmpbed: WA Start prepare for ccb: 
10004/4294967300 towards slave PBE returned: '12' from Immsv
Sep  2 16:54:13 SLOT1 osafimmpbed: WA PBE-A failed to prepare PRTA update 
Ccb:10004/4294967300 towards PBE-B
Sep  2 16:54:13 SLOT1 osafimmpbed: NO 2PBE Error (18) in PRTA update 
(ccbId:10004)
**Sep  2 16:54:13 SLOT1 osafimmnd[3632]: WA update of PERSISTENT runtime 
attributes in object 'safSi=NoRed3,safApp=OpenSAF' REVERTED. PBE rc:18
Sep  2 16:54:13 SLOT1 osafamfd[3698]: ER exec: update FAILED 18**
Sep  2 16:54:14 SLOT1 osafimmnd[3632]: NO PBE-OI established on this SC. 
Dumping incrementally to file imm.db

Note- 1. OpenSAF is successfully started
 2. Issue not seen with 1PBE

Once controller is up, amf-state si gives

safSi=SC-2N,safApp=OpenSAF
saAmfSIAdminState=UNLOCKED(1)
saAmfSIAssignmentState=PARTIALLY_ASSIGNED(3)
safSi=NoRed4,safApp=OpenSAF
saAmfSIAdminState=UNLOCKED(1)
saAmfSIAssignmentState=UNASSIGNED(1)
safSi=NoRed1,safApp=OpenSAF
saAmfSIAdminState=UNLOCKED(1)
saAmfSIAssignmentState=FULLY_ASSIGNED(2)
safSi=NoRed2,safApp=OpenSAF
saAmfSIAdminState=UNLOCKED(1)
saAmfSIAssignmentState=UNASSIGNED(1)
safSi=NoRed3,safApp=OpenSAF
saAmfSIAdminState=UNLOCKED(1)
saAmfSIAssignmentState=UNASSIGNED(1)




---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1983 plm: Build failure with gcc 6.1.1 on 32-bit system

- **Milestone**: 5.1.RC2 --> 5.1.1



---

** [tickets:#1983] plm: Build failure with gcc 6.1.1 on 32-bit system**

**Status:** unassigned
**Milestone:** 5.1.1
**Created:** Mon Aug 29, 2016 08:44 PM UTC by Anders Widell
**Last Updated:** Tue Sep 13, 2016 10:10 AM UTC
**Owner:** nobody


PLM fails to bulild with gcc 6.1.1 on a 32-bit system:

~~~
make[3]: Entering directory '/home/opensaf/opensaf-staging/tests/plmsv/plms'
  CC   plmtest-test_saPlmEntityGroupAdd.o
test_saPlmEntityGroupAdd.c: In function 'saPlmEntityGroupAdd_05':
test_saPlmEntityGroupAdd.c:57:28: error: cast from pointer to integer of 
different size [-Werror=pointer-to-int-cast]
 rc=saPlmEntityGroupAdd((SaPlmEntityGroupHandleT), 
_slot_1_dn , entityNamesNumber,SA_PLM_GROUP_SINGLE_ENTITY);
^
cc1: all warnings being treated as errors
Makefile:638: recipe for target 'plmtest-test_saPlmEntityGroupAdd.o' failed
~~~


---

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] #1929 osaf: Build fails with GCC 6.1.0

- **Milestone**: 5.1.RC2 --> 5.1.1



---

** [tickets:#1929] osaf: Build fails with GCC 6.1.0**

**Status:** assigned
**Milestone:** 5.1.1
**Created:** Tue Aug 02, 2016 09:21 AM UTC by A V Mahesh (AVM)
**Last Updated:** Tue Sep 13, 2016 10:11 AM UTC
**Owner:** A V Mahesh (AVM)


OpenSAF fails to build with GCC 6.1.0, due to new compiler warnings:
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-6.1.0/configure --prefix=/usr --enable-shared 
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu 
--enable-languages=c,c++ --disable-multilib --disable-bootstrap 
--with-system-zlib --with-gmp=/usr/local/gmp-6.1.1 
--with-mpfr=/usr/local/mpfr-3.1.4 --with-mpc=/usr/local/mpc-1.0.3
Thread model: posix
gcc version 6.1.0 (GCC)


make[5]: Entering directory `/avm/opensaf/osaf/tools/safimm/immdump'
g++ -DHAVE_CONFIG_H -I. -I../../../..  -DSA_EXTENDED_NAME_SOURCE 
-I../../../../osaf/libs/saf/include -I../../../../osaf/libs/core/include 
-I../../../../osaf/libs/core/leap/include 
-I../../../../osaf/libs/core/mds/include 
-I../../../../osaf/libs/core/common/include  
-I../../../../osaf/libs/common/immsv/include  -Wall -fno-strict-aliasing 
-Werror -fPIC -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -fstack-protector 
-DINTERNAL_VERSION_ID='""'  -I/usr/include/libxml2 -g -O2 -MT 
immdump-imm_dumper.o -MD -MP -MF .deps/immdump-imm_dumper.Tpo -c -o 
immdump-imm_dumper.o `test -f 'imm_dumper.cc' || echo './'`imm_dumper.cc
imm_dumper.cc: In function â€˜int main(int, char**)â€™:
imm_dumper.cc:144:5: error: this â€˜ifâ€™ clause does not guard... 
[-Werror=misleading-indentation]
 if ((c = getopt_long(argc, argv, "hp:x:c:", long_options, NULL)) == -1)
 ^~
imm_dumper.cc:147:13: note: ...this statement, but the latter is misleadingly 
indented as if it is guarded by the â€˜ifâ€™
 switch (c) {
 ^~
cc1plus: all warnings being treated as errors
make[5]: *** [immdump-imm_dumper.o] Error 1
make[5]: Leaving directory `/avm/opensaf/osaf/tools/safimm/immdump'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/avm/opensaf/osaf/tools/safimm'


---

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] #1890 Doc : Headless feature documentation

- **Milestone**: 5.1.RC2 --> 5.1.0



---

** [tickets:#1890] Doc : Headless feature documentation **

**Status:** accepted
**Milestone:** 5.1.0
**Created:** Tue Jun 21, 2016 11:02 AM UTC by Srikanth R
**Last Updated:** Thu Sep 15, 2016 12:50 PM UTC
**Owner:** Mathi Naickan


Version : Opensaf 5.0. GA


 1) Documentation about headless feature should be updated in 
Opensaf_Overview_PR.odt / Opensaf_Extentsions. The documentation should list 
out services which provide functionality, when the cluster goes headless.
  
 2) The  README.HYDRA file in the ntfsv folder should be renamed to 
README.HEADLESS for uniformity in naming the files across all the folders.
 
 3) CLM folder doesn't have README for the headless feature.
 
 4) The headless files across all folders should have same naming convention.

./osaf/services/saf/amf/README_HEADLESS
./osaf/services/saf/logsv/README-HEADLESS
./osaf/services/saf/cpsv/README.HEADLESS





---

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] #1837 TIPC: loading model gives: "osafimmpbed: ER Failed in saImmOmSearchNext_2:5 - exiting" and "osafimmpbed: ER immpbe.cc dumpObjectsToPbe failed - exiting (line:265)

- **Milestone**: 5.1.RC2 --> 5.1.1



---

** [tickets:#1837] TIPC: loading model gives: "osafimmpbed: ER Failed in 
saImmOmSearchNext_2:5 - exiting" and "osafimmpbed: ER immpbe.cc 
dumpObjectsToPbe failed - exiting (line:265)**

**Status:** unassigned
**Milestone:** 5.1.1
**Created:** Wed May 18, 2016 05:41 AM UTC by beatriz brandao
**Last Updated:** Tue Sep 13, 2016 10:12 AM UTC
**Owner:** nobody
**Attachments:**

- 
[C:\Docs\lixo\osaftestLog-2016-04-19_04-04-26.gz](https://sourceforge.net/p/opensaf/tickets/1837/attachment/C%3A%5CDocs%5Clixo%5CosaftestLog-2016-04-19_04-04-26.gz)
 (1.4 MB; application/x-gzip-compressed)


Testcase:
osaftest.tests.amf.functest.config_changes.test_comptype_attr_chg.Test.test_chg_ct_def_disable_restart
Note: this testcase are run with TIPC enabled.

Testcase starts @:
2016-04-19 03:44:28 INFO - TestCase:setUp Start | 
test_chg_ct_def_disable_restart (osaftest.tests.amf.functest.
config_changes.test_comptype_attr_chg.Test)

Testcase ends @:
2016-04-19 03:45:16 DEBUG: Powered off cluster

First analysis done by Zoran:
>From syslogs, I cannot see what was the problem for causing ERR_TIMEOUT in 
>searchNext().

According to MDS logs, it seems that this might be an MDS problem.

>From MDS logs:
Apr 19  3:44:36.237379 osaflogd[446] NOTIFY  |MDTM: svc up event for svc_id = 
LGA(21), subscri. by svc_id = LGS(20) 
pwe_id=1 Adest = 
Apr 19  3:44:36.238518 osafntfd[461] NOTIFY  |MDTM: svc up event for svc_id = 
NTFA(29), subscri. by svc_id = NTFS(28) 
pwe_id=1 Adest = 
Apr 19  3:44:36.239261 osafclmd[477] NOTIFY  |MDTM: svc up event for svc_id = 
CLMA(35), subscri. by svc_id = CLMS(34) 
pwe_id=1 Adest = 
Apr 19  3:44:38.788267 osaflogd[446] NOTIFY  |MDTM: svc up event for svc_id = 
LGA(21), subscri. by svc_id = LGS(20) 
pwe_id=1 Adest = 
Apr 19  3:44:44.911298 osafimmpbed[453] ERR  |MDS_SND_RCV: Timeout or Error 
occured
Apr 19  3:44:44.912049 osafimmpbed[453] ERR  |MDS_SND_RCV: Timeout occured on 
sndrsp message
Apr 19  3:44:44.912128 osafimmpbed[453] ERR  |MDS_SND_RCV: 
Adest=<0x0002010f,1637493776>
Apr 19  3:44:44.919827 osafimmnd[432] NOTIFY  |MDTM: svc down event for svc_id 
= IMMA_OM(26), subscri. by svc_id = 
IMMND(25) pwe_id=1 Adest = 
Apr 19  3:44:45.413550 osafimmpbed[679] NOTIFY  |BEGIN MDS LOGGING| 
PID= | ARCHW=a|64bit=1

the was no any MDS message between 3:44:38.788267 and 3:44:44.911298.

At 3:44:44.911298, MDS send/receive PBE request was timed out.



---

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] #1993 amf: amfnd crashes during su lock if CSI attribute name or value is a long dn.

- **Milestone**: 5.1.RC2 --> 5.1.0

---

** [tickets:#1993] amf: amfnd crashes during su lock if CSI attribute name or
value is a long dn.**

**Status:** review
**Milestone:** 5.1.0
**Created:** Thu Sep 01, 2016 11:09 AM UTC by Praveen
**Last Updated:** Tue Sep 13, 2016 10:09 AM UTC
**Owner:** Praveen
**Attachments:**

-
[amfnd_crash.tgz](https://sourceforge.net/p/opensaf/tickets/1993/attachment/amfnd_crash.tgz)
(69.4 kB; application/x-compressed)

Configuration:
In the long dn amf demo, add csi attribute for the CSI keeping attribute value
a longdn.
1)Bring the configuration up.
2)Lock the SU.
3)AMFND crashes.

AMFND uses memcpy() and thus works with orignal csi attribute values from
csi_rec.
It frees the memory in avsv_amf_cbk_free() when CSI_SET callback arrives.
During SU lock, it agian tries to free the memory while deleting the record.
At AMFND and AMFD, all SaNameT handling should be done using
osaf_extended_name_alloc() API.

Issue will be applicable in case of messages related to CSI Attribute change
callback also.

---

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] #2017 Update the SMF PR document with information about faster upgrade

- **Milestone**: 5.1.RC2 --> 5.1.0



---

** [tickets:#2017] Update the SMF PR document with information about faster 
upgrade**

**Status:** accepted
**Milestone:** 5.1.0
**Created:** Fri Sep 09, 2016 12:22 PM UTC by elunlen
**Last Updated:** Thu Sep 15, 2016 01:07 PM UTC
**Owner:** elunlen


Update the SMF PR document with information about:
* Balanced In Service Upgrade (BISU) [#1685]
* Parallel swBundle removal and installation [#1633]
* NG lock and unlock in single step upgrade [#1634]


---

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] #2050 PLM: update PR doc to address new virtualization configuration

- **Milestone**: 5.1.RC2 --> 5.1.0



---

** [tickets:#2050] PLM: update PR doc to address new virtualization 
configuration**

**Status:** review
**Milestone:** 5.1.0
**Created:** Mon Sep 19, 2016 01:58 PM UTC by Alex Jones
**Last Updated:** Mon Sep 19, 2016 02:02 PM UTC
**Owner:** Alex Jones


This ticket is for updating the PLM PR doc to reflect virtualization 
enhancement in 5.1


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2052 immtools: SC/PL field in nodes.cfg is not used

Hi,

I'm not playing a lot with nodes.cfg, but as I know, the first column tells if 
a node is a system controller or a payload. Base on the first column, immxml 
tools knows which template will be used.
The second column is AMF node name.
The third column is CLM node name.

AMF and CLM node don't need to be the same.
If you set that a system controller node name is PL-3 then a node with node 
name PL-3 is a system controller.
Node names don't need to start with SC or PL. It can be any name.


---

** [tickets:#2052] immtools: SC/PL field in nodes.cfg is not used**

**Status:** unassigned
**Milestone:** 4.7.2
**Created:** Tue Sep 20, 2016 09:41 AM UTC by Ritu Raj
**Last Updated:** Tue Sep 20, 2016 12:20 PM UTC
**Owner:** nobody


# Environment details
OS : Suse 64bit
Changeset : 7997 ( 5.1.FC)

# Summary
Controller able to join with invalid node_name

# Steps followed & Observed behaviour
1. Mistakenly configured controller node_name with PL-3 and the remaining 
configuration files are properly installed and updated apart from 
/etc/opensaf/node_name.
2. Bringup OpenSAF, OpneSAF still able to comeup with misconfigured node_name

Opensaf status:
fos1:/opt/goahead/tetware/opensaffire/suites/avsv/api/suites # 
/etc/init.d/opensafd status
safSISU=safSu=PL-3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)

#  Expected
OpenSAF should come up with only SC-1 / SC-2, as immxml generated with :
 ./immxml-clustersize -s 2 -p 2
 ./immxml-configure




---

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] #2053 amf: add support for cluster reboot

2016-09-20 Thread Hans Nordebäck




---

** [tickets:#2053] amf: add support for cluster reboot**

**Status:** review
**Milestone:** 5.2.FC
**Created:** Tue Sep 20, 2016 12:54 PM UTC by Hans Nordebäck
**Last Updated:** Tue Sep 20, 2016 12:54 PM UTC
**Owner:** Hans Nordebäck


Add support for cluster reboot via command  immadm -a safAmfService -o 100 
safAmfService


---

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] #2052 immtools: SC/PL field in nodes.cfg is not used

2016-09-20 Thread Ritu Raj

I want to add this one too:
So, if we start second node SC-2, it will failed to join the cluster
And both node will go for reboot
 **and finally after reboot when node join back:
 
 >>SC-2 will join with "ACTIVE" role and first node(PL-3) will join as 
 >>"QUIESCED"


Syslog of SC-2:
Sep 20 17:27:18 TestBed-R2 osafimmd[27361]: ER Failed to find candidate for new 
IMMND coordinator (ScAbsenceAllowed:0 RulingEpoch:0
Sep 20 17:27:18 TestBed-R2 osafimmd[27361]: ER Active IMMD has to restart the 
IMMSv. All IMMNDs will restart
Sep 20 17:27:18 TestBed-R2 osafimmd[27361]: NO Cluster failed to load => IMMDs 
will not exit.
Sep 20 17:27:18 TestBed-R2 osafimmd[27361]: NO MDS event from svc_id 25 
(change:4, dest:564114851160080)
Sep 20 17:27:18 TestBed-R2 osafimmd[27361]: IN Added IMMND node with dest 
564114851160080
Sep 20 17:27:18 TestBed-R2 osafimmd[27361]: IN Added IMMND node with dest 
565216431636496
Sep 20 17:27:18 TestBed-R2 osafimmd[27361]: WA Error returned from processing 
message err:0 msg-type:14
Sep 20 17:27:18 TestBed-R2 osafimmnd[27372]: ER IMMND forced to restart on 
order from IMMD, exiting
Sep 20 17:27:18 TestBed-R2 osafimmd[27361]: NO MDS event from svc_id 25 
(change:4, dest:565216431636496)
Sep 20 17:27:18 TestBed-R2 osafamfnd[27422]: NO 
'safSu=SC-2,safSg=NoRed,safApp=OpenSAF' component restart probation timer 
started (timeout: 600 ns)
Sep 20 17:27:18 TestBed-R2 osafamfnd[27422]: NO Restarting a component of 
'safSu=SC-2,safSg=NoRed,safApp=OpenSAF' (comp restart count: 1)
Sep 20 17:27:18 TestBed-R2 osafamfnd[27422]: NO 
'safComp=IMMND,safSu=SC-2,safSg=NoRed,safApp=OpenSAF' faulted due to 'avaDown' 
: Recovery is 'componentRestart

.

Sep 20 17:27:23 TestBed-R2 osafclmd[27402]: NO ERR_INVALID_PARAM: Implementer 
safClmService already set for this handle when trying to set safClmService
Sep 20 17:27:23 TestBed-R2 osafclmd[27402]: ER saImmOiImplementerSet failed, rc 
= 7
Sep 20 17:27:23 TestBed-R2 osafamfnd[27422]: NO 
'safComp=CLM,safSu=SC-2,safSg=2N,safApp=OpenSAF' faulted due to 'avaDown' : 
Recovery is 'nodeFailfast'
Sep 20 17:27:23 TestBed-R2 osafamfnd[27422]: ER 
safComp=CLM,safSu=SC-2,safSg=2N,safApp=OpenSAF Faulted due to:avaDown Recovery 
is:nodeFailfast
Sep 20 17:27:23 TestBed-R2 osafamfnd[27422]: Rebooting OpenSAF NodeId = 131599 
EE Name = , Reason: Component faulted: recovery is node failfast, OwnNodeId = 
131599, SupervisionTime = 60
Sep 20 17:27:23 TestBed-R2 opensaf_reboot: Rebooting local node; timeout=60



Syslog of firstnode:
Sep 20 17:28:10 TestBed-R1 osafimmnd[31481]: ER No IMMD service => cluster 
restart, exiting
Sep 20 17:28:10 TestBed-R1 osafamfnd[30949]: NO Restarting a component of 
'safSu=PL-3,safSg=NoRed,safApp=OpenSAF' (comp restart count: 2)
Sep 20 17:28:10 TestBed-R1 osafamfnd[30949]: NO 
'safComp=IMMND,safSu=PL-3,safSg=NoRed,safApp=OpenSAF' faulted due to 'avaDown' 
: Recovery is 'componentRestart'
Sep 20 17:28:10 TestBed-R1 osafntfimcnd[31487]: NO saImmOiDispatch() Fail 
SA_AIS_ERR_BAD_HANDLE (9)
Sep 20 17:28:10 TestBed-R1 osafamfd[30935]: NO Node 'SC-2' left the cluster
Sep 20 17:28:10 TestBed-R1 osafamfd[30935]: safSu=SC-2,safSg=2N,safApp=OpenSAF 
OperState ENABLED => DISABLED
Sep 20 17:28:10 TestBed-R1 opensaf_reboot: Rebooting local node; timeout=60
Sep 20 17:28:10 TestBed-R1 osafamfd[30935]: ER sendStateChangeNotificationAvd: 
saNtfNotificationSend Failed (6)
Sep 20 17:28:10 TestBed-R1 osafamfd[30935]: safSu=SC-2,safSg=2N,safApp=OpenSAF 
PresenceState INSTANTIATED => UNINSTANTIATED
Sep 20 17:28:10 TestBed-R1 osafamfd[30935]: ER sendStateChangeNotificationAvd: 
saNtfNotificationSend Failed (6)
Sep 20 17:28:10 TestBed-R1 osafamfd[30935]: safSu=SC-2,safSg=2N,safApp=OpenSAF 
ReadinessState IN_SERVICE => OUT_OF_SERVICE



---

** [tickets:#2052] immtools: SC/PL field in nodes.cfg is not used**

**Status:** unassigned
**Milestone:** 4.7.2
**Created:** Tue Sep 20, 2016 09:41 AM UTC by Ritu Raj
**Last Updated:** Tue Sep 20, 2016 11:58 AM UTC
**Owner:** nobody


# Environment details
OS : Suse 64bit
Changeset : 7997 ( 5.1.FC)

# Summary
Controller able to join with invalid node_name

# Steps followed & Observed behaviour
1. Mistakenly configured controller node_name with PL-3 and the remaining 
configuration files are properly installed and updated apart from 
/etc/opensaf/node_name.
2. Bringup OpenSAF, OpneSAF still able to comeup with misconfigured node_name

Opensaf status:
fos1:/opt/goahead/tetware/opensaffire/suites/avsv/api/suites # 
/etc/init.d/opensafd status
safSISU=safSu=PL-3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)

#  Expected
OpenSAF should come up with only SC-1 / SC-2, as immxml generated with :
 ./immxml-clustersize -s 2 -p 2
 ./immxml-configure




---

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

[tickets] [opensaf:tickets] #2052 immtools: SC/PL field in nodes.cfg is not used

2016-09-20 Thread Mathi Naickan

- **summary**: Controller able to join with invalid node_name --> immtools: 
SC/PL field in nodes.cfg is not used
- **Type**: defect --> discussion
- **Comment**:

Had a discussion with ritu and Tagging this ticket as a discussion topic and 
assigning to immtools.

The issue can be reproduced as below:
Generate imm.xml for 4 nodes with names set to SC-1, SC-2, PL-3 ,PL-4 in the 
nodes.cfg

SC SC-1 SC-1
SC SC-2 SC-2
PL PL-3 PL-3
PL PL-4 PL-4


Now, start the first node with node_name set to PL-4. OpenSAF comes up fine.

Since the nodes.cfg is exposed to the end user, I guess Ritu is questioning the 
need for the first column in nodes.cfg i.e. 'differentiation based on 'SC' 
versus 'PL'.

This could be discussed further.



---

** [tickets:#2052] immtools: SC/PL field in nodes.cfg is not used**

**Status:** unassigned
**Milestone:** 4.7.2
**Created:** Tue Sep 20, 2016 09:41 AM UTC by Ritu Raj
**Last Updated:** Tue Sep 20, 2016 09:41 AM UTC
**Owner:** nobody


# Environment details
OS : Suse 64bit
Changeset : 7997 ( 5.1.FC)

# Summary
Controller able to join with invalid node_name

# Steps followed & Observed behaviour
1. Mistakenly configured controller node_name with PL-3 and the remaining 
configuration files are properly installed and updated apart from 
/etc/opensaf/node_name.
2. Bringup OpenSAF, OpneSAF still able to comeup with misconfigured node_name

Opensaf status:
fos1:/opt/goahead/tetware/opensaffire/suites/avsv/api/suites # 
/etc/init.d/opensafd status
safSISU=safSu=PL-3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)

#  Expected
OpenSAF should come up with only SC-1 / SC-2, as immxml generated with :
 ./immxml-clustersize -s 2 -p 2
 ./immxml-configure




---

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] #2051 clm: clmd crashes due to different content in SaNameT value

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

opensaf-5.1.x:

changeset:   8115:502d50e0dead
branch:  opensaf-5.1.x
parent:  8113:6bb937c0cd8e
user:Zoran Milinkovic 
date:Tue Sep 20 11:15:58 2016 +0200
summary: clm: fill SaNameT value with zeros [#2051]

-

default(5.2):

changeset:   8116:be0f5c394a01
tag: tip
parent:  8114:dc9bd3080ee5
user:Zoran Milinkovic 
date:Tue Sep 20 11:15:58 2016 +0200
summary: clm: fill SaNameT value with zeros [#2051]



---

** [tickets:#2051] clm: clmd crashes due to different content in SaNameT value**

**Status:** fixed
**Milestone:** 5.1.RC2
**Created:** Tue Sep 20, 2016 08:42 AM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 20, 2016 09:01 AM UTC
**Owner:** Zoran Milinkovic


When SaNameT string is decoded from network transport, only string of SaNameT 
lenght is copied. The rest of SaNameT value may have random characters.
When node name (type of SaNameT) is stored in patricia tree, it may happen that 
the node name cannot be found due to random characters in SaNameT value after 
SaNameT (length + 1) position.

Core dump generated due to node name mismatch in patricia tree:
~~~
#0  0x7f308d80c0a7 in raise () from /lib64/libc.so.6
#1  0x7f308d80d458 in abort () from /lib64/libc.so.6
#2  0x7f308f20b2ae in __osafassert_fail (__file=__file@entry=0x424ef0 
"../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_mbcsv.c", 
__line=__line@entry=467, 
__func=__func@entry=0x4259c0 <__FUNCTION__.11621> "ckpt_proc_node_rec", 
__assertion=__assertion@entry=0x424a85 "0") at 
../../../../../../opensaf/osaf/libs/core/leap/sysf_def.c:281
#3  0x00413526 in ckpt_proc_node_rec (cb=, 
data=0xf53320) at 
../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_mbcsv.c:467
#4  0x00417584 in ckpt_decode_async_update (cbk_arg=, 
cb=0x62d7a0 <_clms_cb>) at 
../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_mbcsv.c:2309
#5  ckpt_decode_cbk_handler (cbk_arg=0x7ffd702755d0) at 
../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_mbcsv.c:1996
#6  mbcsv_callback (arg=0x7ffd702755d0) at 
../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_mbcsv.c:718
#7  0x7f308f21b786 in ncs_mbscv_rcv_decode (peer=peer@entry=0xf525a0, 
evt=evt@entry=0x7f3088004fd0) at 
../../../../../../opensaf/osaf/libs/core/mbcsv/mbcsv_act.c:393
#8  0x7f308f21b956 in ncs_mbcsv_rcv_async_update (peer=0xf525a0, 
evt=0x7f3088004fd0) at 
../../../../../../opensaf/osaf/libs/core/mbcsv/mbcsv_act.c:440
#9  0x7f308f222540 in mbcsv_process_events (rcvd_evt=0x7f3088004fd0, 
mbcsv_hdl=mbcsv_hdl@entry=4293918753) at 
../../../../../../opensaf/osaf/libs/core/mbcsv/mbcsv_pr_evts.c:168
#10 0x7f308f2226ab in mbcsv_hdl_dispatch_all (mbcsv_hdl=4293918753, 
mbx=mbx@entry=4283432961) at 
../../../../../../opensaf/osaf/libs/core/mbcsv/mbcsv_pr_evts.c:272
#11 0x7f308f21ced2 in mbcsv_process_dispatch_request (arg=0x7ffd70275740) 
at ../../../../../../opensaf/osaf/libs/core/mbcsv/mbcsv_api.c:423
#12 0x00413cce in clms_mbcsv_dispatch (mbcsv_hdl=) at 
../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_mbcsv.c:686
#13 0x00405538 in main (argc=, argv=) at 
../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_main.c:536
~~~



---

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] #2022 AMF : amfd asserted for NG lock operation ( quiesced timeout - Nway model))

2016-09-20 Thread Praveen

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

changeset:   8113:6bb937c0cd8e
branch:  opensaf-5.1.x
parent:  8111:15646cff9e26
user:praveen.malv...@oracle.com
date:Tue Sep 20 16:38:37 2016 +0530
summary: amfd: do not send duplicate removal of assignment, N-Way model 
[#2022]

changeset:   8114:dc9bd3080ee5
tag: tip
parent:  8112:780130c6de15
user:praveen.malv...@oracle.com
date:Tue Sep 20 16:38:56 2016 +0530
summary: amfd: do not send duplicate removal of assignment, N-Way model 
[#2022]





---

** [tickets:#2022] AMF : amfd asserted for NG lock operation ( quiesced timeout 
- Nway model))**

**Status:** fixed
**Milestone:** 5.1.RC2
**Created:** Sat Sep 10, 2016 09:58 AM UTC by Srikanth R
**Last Updated:** Mon Sep 19, 2016 06:55 AM UTC
**Owner:** Praveen
**Attachments:**

- 
[createAppTestApp.sh](https://sourceforge.net/p/opensaf/tickets/2022/attachment/createAppTestApp.sh)
 (15.8 kB; text/x-shellscript)
- 
[messages](https://sourceforge.net/p/opensaf/tickets/2022/attachment/messages) 
(11.2 kB; application/octet-stream)
- 
[osafamfd](https://sourceforge.net/p/opensaf/tickets/2022/attachment/osafamfd) 
(452.8 kB; application/octet-stream)


Environment details
--
OS : Suse 64bit 
Changeset : 7997  ( 5.1.FC)
Setup : 5 nodes ( 2 controllers and 3 payloads with headless feature enabled & 
no PBE )
AMF Application : NPM model with SUs mapped on SC-2,PL-3,PL-4


Summary :
--
AMFD on both controllers asserted, if Nway application failed in CSI SET 
QUIESCED callback in lock operation of node group 


Steps followed & Observed behaviour
--

-> Hosted nway application on PL-3,PL-4 and SC-2 and brought up the 
application. Configuration is attached to the ticket.
-> Created a node group with all the three nodes.
-> Ensured that one of component will not respond to quiesced callback
-> Now performed the lock operation on the node group
-> amfd on both controllers asserted with the following back trace.


0  0x7f66fbc6fb55 in raise () from /lib64/libc.so.6
1  0x7f66fbc71131 in abort () from /lib64/libc.so.6
2  0x7f66fda6816a in __osafassert_fail (__file=0x51214d "su.cc", 
__line=2022, __func=0x513aa0 "dec_curr_stdby_si", __assertion=0x51355f 
"saAmfSUNumCurrStandbySIs > 0") at sysf_def.c:281

3  0x004d68cd in AVD_SU::dec_curr_stdby_si (this=0x7ccf40) at su.cc:2022
4  0x004be804 in avd_susi_update_assignment_counters (susi=0x78c670, 
action=AVSV_SUSI_ACT_DEL, current_ha_state=0, new_ha_state=0) at siass.cc:783
5  0x004be59b in avd_susi_del_send (susi=0x78c670) at siass.cc:714
6  0x004af12e in avd_sg_nway_node_fail_stable (cb=0x751b80, 
su=0x800470, susi=0x0) at sg_nway_fsm.cc:3022
7  0x004b025d in avd_sg_nway_node_fail_sg_realign (cb=0x751b80, 
su=0x800470) at sg_nway_fsm.cc:3493
8  0x004a8042 in SG_NWAY::node_fail (this=0x797c50, cb=0x751b80, 
su=0x800470) at sg_nway_fsm.cc:497
9  0x004b209e in sg_su_failover_func (su=0x800470) at sgproc.cc:525
10 0x004b2d16 in avd_su_oper_state_evh (cb=0x751b80, 
evt=0x7f66f4002940) at sgproc.cc:838
11 0x00450ba9 in process_event (cb_now=0x751b80, evt=0x7f66f4002940) at 
main.cc:768
12 0x004508cd in main_loop () at main.cc:689
13 0x00450e43 in main (argc=2, argv=0x7fff0f81ab18) at main.cc:841







---

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] #2021 AMF : active compname is improperly populated in Standby callback (NPM)

2016-09-20 Thread Praveen

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

changeset:   8112:780130c6de15
tag: tip
parent:  8110:3093e3a87a7e
user:praveen.malv...@oracle.com
date:Tue Sep 20 16:32:28 2016 +0530
summary: amf: fix activeCompName in csiStateDescriptor used in CSI SET cbk 
[#2021]

changeset:   8111:15646cff9e26
branch:  opensaf-5.1.x
parent:  8109:849706863a78
user:praveen.malv...@oracle.com
date:Tue Sep 20 16:32:03 2016 +0530
summary: amf: fix activeCompName in csiStateDescriptor used in CSI SET cbk 
[#2021]




---

** [tickets:#2021] AMF :  active compname is improperly populated in Standby 
callback (NPM)**

**Status:** fixed
**Milestone:** 5.1.RC2
**Created:** Sat Sep 10, 2016 06:52 AM UTC by Srikanth R
**Last Updated:** Thu Sep 15, 2016 09:42 AM UTC
**Owner:** Praveen


 For an application with NPM model, active compName in the standby descriptor 
is having corrupted value in the standby callback.


Breakpoint 1, pycbk_SaAmfCSISetCallbackT (invocation=4287627278, 
compName=0x941a28, haState=SA_AMF_HA_STANDBY, csiDescriptor=...) at 
saAmf_wrap.c:2914
2914saAmf_wrap.c: No such file or directory.
(gdb) p csiDescriptor 
$1 = {csiFlags = 1, csiName = {length = 48, value = 
"safCsi=CSI1,safSi=TestApp_SI4,safApp=TestApp_Npm", '\000' }, csiStateDescriptor = {activeDescriptor = {transitionDescriptor = 
1634926660, 
  activeCompName = {length = 0, value = 
"\000mp=CO\000\000\000\000\000\000\000\000u=TestApp_SU2,safSg=TestApp_SG1,safApp=TestApp_Npm",
 '\000' }}, standbyDescriptor = {activeCompName = {
length = 68, value = 
"**sa\000\000\000mp=CO\000\000\000\000\000\000\000\000u=TestApp_SU2,safSg=TestApp_SG1,safApp=TestApp_Npm**",
 '\000' }, standbyRank = 0}}, csiAttr = {attr = 0x7642a0, 
number = 1}}


 In the above callback ( in gdb ), the  active component name in standby 
descriptor in standby callback  should be 
safComp=COMP1,safSu=TestApp_SU3,safSg=TestApp_SG1,safApp=TestApp_Npm, but it  
is populated with improper value :
 
sa\000\000\000mp=CO\000\000\000\000\000\000\000\000u=TestApp_SU2,safSg=TestApp_SG1,safApp=TestApp_Npmapo


---

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] #2052 Controller able to join with invalid node_name

2016-09-20 Thread Ritu Raj




---

** [tickets:#2052] Controller able to join with invalid node_name**

**Status:** unassigned
**Milestone:** 4.7.2
**Created:** Tue Sep 20, 2016 09:41 AM UTC by Ritu Raj
**Last Updated:** Tue Sep 20, 2016 09:41 AM UTC
**Owner:** nobody


# Environment details
OS : Suse 64bit
Changeset : 7997 ( 5.1.FC)

# Summary
Controller able to join with invalid node_name

# Steps followed & Observed behaviour
1. Mistakenly configured controller node_name with PL-3 and the remaining 
configuration files are properly installed and updated apart from 
/etc/opensaf/node_name.
2. Bringup OpenSAF, OpneSAF still able to comeup with misconfigured node_name

Opensaf status:
fos1:/opt/goahead/tetware/opensaffire/suites/avsv/api/suites # 
/etc/init.d/opensafd status
safSISU=safSu=PL-3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)

#  Expected
OpenSAF should come up with only SC-1 / SC-2, as immxml generated with :
 ./immxml-clustersize -s 2 -p 2
 ./immxml-configure




---

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] #1864 log: get ER syslog when running logtest 5 2

2016-09-20 Thread Vu Minh Nguyen

- **status**: review --> fixed
- **assigned_to**: Canh Truong -->  nobody 
- **Milestone**: 4.7.2 --> 5.0.1
- **Comment**:

changeset:   8110:3093e3a87a7e
tag: tip
parent:  8106:18f09b25f3dd
user:Canh Van Truong 
date:Tue Sep 20 13:35:59 2016 +0700
summary: log: fix ER syslog when running logtest 5 2 [#1864]

changeset:   8109:849706863a78
branch:  opensaf-5.1.x
parent:  8107:2fe7d71cc3f4
user:Canh Van Truong 
date:Tue Sep 20 13:35:59 2016 +0700
summary: log: fix ER syslog when running logtest 5 2 [#1864]

changeset:   8108:b56c07165af9
branch:  opensaf-5.0.x
parent:  8093:bcd8675c17b3
user:Canh Van Truong 
date:Tue Sep 20 13:35:59 2016 +0700
summary: log: fix ER syslog when running logtest 5 2 [#1864]




---

** [tickets:#1864] log: get ER syslog when running logtest 5 2**

**Status:** fixed
**Milestone:** 5.0.1
**Created:** Wed Jun 08, 2016 02:32 AM UTC by Vu Minh Nguyen
**Last Updated:** Fri Sep 16, 2016 09:39 AM UTC
**Owner:** nobody


When running `logtest 5 2` sometimes gets following ER message in syslog:
> 2016-04-27 02:39:57 SC-1 osaflogd[462]: ER Old log files could not be renamed 
> and closed for stream: safLgStrCfg=saLogNotification,safApp=safLogService
> 2016-04-27 02:39:57 SC-1 osaflogd[462]: ER Old log files could not be renamed 
> and closed for stream: safLgStrCfg=saLogSystem,safApp=safLogService

The problem is in logtest app - Test case #2 of suite #5.

"logtest 5 2" does following steps:
1) Create `xxtest` directory 
2) Change default `logRootDirectory` to above directory
3) Change `logRootDirectory` back to default value
4) **Remove all log files in `xxtest` directory**

In step #2 or #3, there is one step to rename the openning log files by 
appending the closed time to the log file names in `IMM apply callback`. The 
problem happens because the step #4 done while LOG service not yet completed 
`IMM apply callback` due to #2 or #3.

Can reproduce the problem by making logsv high load while performing `logtest 5 
2`:
1) Open 2 terminals
2) On terminal #1, in loop, using `saflogger` tool sending log record to alarm 
stream while on other terminal performing `logtest 5 2` in loop.


---

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] #2032 ckpt: ckpttest for long dn (5 55, 5 57, 7 12) is failing

2016-09-20 Thread A V Mahesh (AVM)

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

searching for changes
changeset:   8106:18f09b25f3dd
user:Hoang Vo 
date:Tue Sep 20 14:17:25 2016 +0530
summary: cpsvtest: fix ckpttest following new LongDN function [#2032]
 
changeset:   8107:2fe7d71cc3f4
branch:  opensaf-5.1.x
tag: tip
parent:  8104:554cfde112e2
user:Hoang Vo 
date:Tue Sep 20 14:18:19 2016 +0530
summary: cpsvtest: fix ckpttest following new LongDN function [#2032]
 



---

** [tickets:#2032] ckpt: ckpttest for long dn (5 55, 5 57, 7 12) is failing**

**Status:** fixed
**Milestone:** 5.1.RC2
**Created:** Wed Sep 14, 2016 04:40 AM UTC by Quyen Dao
**Last Updated:** Tue Sep 20, 2016 06:22 AM UTC
**Owner:** Vo Minh Hoang


Changeset: 8064:99410ba8cc21

root@SC-1:~# immcfg -a longDnsAllowed=1 
opensafImm=opensafImm,safApp=safImmService
root@SC-1:~# export SA_ENABLE_EXTENDED_NAMES=1

root@SC-1:~# ckpttest 5 55

Suite 5: CKPT API saCkptCheckpointOpen()
   55  FAILED   To verify creating a ckpt with invalid extended name length 
(expected OUT_OF_RANGE, got SA_AIS_OK (1));

=

   Test Result:
  Total:  1
  Passed: 0
  Failed: 1

root@SC-1:~# ckpttest 5 57

Suite 5: CKPT API saCkptCheckpointOpen()
   57  FAILED   To verify openAsync a ckpt with invalid extended name length 
(expected OUT_OF_RANGE, got SA_AIS_OK (1));

=

   Test Result:
  Total:  1
  Passed: 0
  Failed: 1
root@SC-1:~# ckpttest 7 12

Suite 7: CKPT API saCkptCheckpointUnlink()
   12  FAILED   To test unlink a ckpt with invalid extended name (expected 
OUT_OF_RANGE, got SA_AIS_OK (1));

=

   Test Result:
  Total:  1
  Passed: 0
  Failed: 1
root@SC-1:~#



---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1994 IMMSv: Finalized CCB are counted under Max Ccb Limit

2016-09-20 Thread Neelakanta Reddy

- **status**: accepted --> fixed
- **Comment**:

changeset:   8104:554cfde112e2
branch:  opensaf-5.1.x
parent:  8102:1794ee4f2e48
user:Neelakanta Reddy
date:Tue Sep 20 14:42:00 2016 +0530
summary: imm: ccbs that are not timed out are counted for 
TerminatedCcbcount[#1994]

changeset:   8105:30138cd18adb
tag: tip
parent:  8103:aac8fd955b93
user:Neelakanta Reddy
date:Tue Sep 20 14:42:00 2016 +0530
summary: imm: ccbs that are not timed out are counted for 
TerminatedCcbcount[#1994]




---

** [tickets:#1994] IMMSv: Finalized CCB are counted under Max Ccb Limit**

**Status:** fixed
**Milestone:** 5.1.RC1
**Created:** Thu Sep 01, 2016 12:32 PM UTC by Chani Srivastava
**Last Updated:** Tue Sep 20, 2016 08:38 AM UTC
**Owner:** Neelakanta Reddy


setup:
Version - OpenSAF 5.1.FC : changeset - 7997
4-Node cluster
1PBE with 30K objects

- Default maxCcb is configured to 1 as in object 
opensafImm=opensafImm,safApp=safImmService
- Try creating more than 1 Ccb operations
~~~
for (( i = 1 ; i <=2; i++))
   immcfg -c TestClass testClass=$i 
~~~
Above operation fails with ERR_NO_RESOURCE after the Ccb count for cluster 
reached 1. Even when a max limit is reached; after few minutes more Ccbs 
are allowed. See the below syslog snippet



Sep  1 14:58:35 OSAF-SC1 osafimmnd[27298]: NO Ccb 45008 COMMITTED 
(chaniTestClass)
Sep  1 14:58:35 OSAF-SC1 osafimmnd[27298]: NO Ccb 45009 COMMITTED 
(chaniTestClass)
Sep  1 14:58:35 OSAF-SC1 osafimmnd[27298]: NO Ccb 45010 COMMITTED 
(chaniTestClass)
Sep  1 14:58:35 OSAF-SC1 osafimmnd[27298]: NO Ccb 45011 COMMITTED 
(chaniTestClass)
Sep  1 14:58:35 OSAF-SC1 osafimmnd[27298]: NO Ccb 45012 COMMITTED 
(chaniTestClass)
**Sep  1 *14:58:35* OSAF-SC1 osafimmnd[27298]: *NO ERR_NO_RESOURCES: maximum 
Ccbs limit 2 has been reached for the cluster***
Sep  1 15:00:34 OSAF-SC1 syslog-ng[1194]: Log statistics; 
dropped='pipe(/dev/xconsole)=0', dropped='pipe(/dev/tty10)=0', 
processed='center(queued)=92951', processed='center(received)=47084', 
processed='destination(messages)=47077', processed='destination(mailinfo)=7', 
processed='destination(mailwarn)=0', 
processed='destination(localmessages)=45786', 
processed='destination(newserr)=0', processed='destination(mailerr)=0', 
processed='destination(netmgm)=0', processed='destination(warn)=42', 
processed='destination(console)=16', processed='destination(null)=0', 
processed='destination(mail)=7', processed='destination(xconsole)=16', 
processed='destination(firewall)=0', processed='destination(acpid)=0', 
processed='destination(newscrit)=0', processed='destination(newsnotice)=0', 
processed='source(src)=47084'
**Sep  1 *15:10:14 *OSAF-SC1 osafimmnd[27298]: *NO Ccb 45014 COMMITTED 
(chaniTestClass)***
Sep  1 15:10:14 OSAF-SC1 osafimmnd[27298]: NO Ccb 45015 COMMITTED 
(chaniTestClass)
Sep  1 15:10:14 OSAF-SC1 osafimmnd[27298]: NO Ccb 45016 COMMITTED 
(chaniTestClass)
Sep  1 15:10:14 OSAF-SC1 osafimmnd[27298]: NO Ccb 45017 COMMITTED 
(chaniTestClass)



---

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] #2051 clm: clmd crashes due to different content in SaNameT value

- **status**: accepted --> review
- **Comment**:

https://sourceforge.net/p/opensaf/mailman/message/35379217/



---

** [tickets:#2051] clm: clmd crashes due to different content in SaNameT value**

**Status:** review
**Milestone:** 5.1.RC2
**Created:** Tue Sep 20, 2016 08:42 AM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 20, 2016 08:42 AM UTC
**Owner:** Zoran Milinkovic


When SaNameT string is decoded from network transport, only string of SaNameT 
lenght is copied. The rest of SaNameT value may have random characters.
When node name (type of SaNameT) is stored in patricia tree, it may happen that 
the node name cannot be found due to random characters in SaNameT value after 
SaNameT (length + 1) position.

Core dump generated due to node name mismatch in patricia tree:
~~~
#0  0x7f308d80c0a7 in raise () from /lib64/libc.so.6
#1  0x7f308d80d458 in abort () from /lib64/libc.so.6
#2  0x7f308f20b2ae in __osafassert_fail (__file=__file@entry=0x424ef0 
"../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_mbcsv.c", 
__line=__line@entry=467, 
__func=__func@entry=0x4259c0 <__FUNCTION__.11621> "ckpt_proc_node_rec", 
__assertion=__assertion@entry=0x424a85 "0") at 
../../../../../../opensaf/osaf/libs/core/leap/sysf_def.c:281
#3  0x00413526 in ckpt_proc_node_rec (cb=, 
data=0xf53320) at 
../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_mbcsv.c:467
#4  0x00417584 in ckpt_decode_async_update (cbk_arg=, 
cb=0x62d7a0 <_clms_cb>) at 
../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_mbcsv.c:2309
#5  ckpt_decode_cbk_handler (cbk_arg=0x7ffd702755d0) at 
../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_mbcsv.c:1996
#6  mbcsv_callback (arg=0x7ffd702755d0) at 
../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_mbcsv.c:718
#7  0x7f308f21b786 in ncs_mbscv_rcv_decode (peer=peer@entry=0xf525a0, 
evt=evt@entry=0x7f3088004fd0) at 
../../../../../../opensaf/osaf/libs/core/mbcsv/mbcsv_act.c:393
#8  0x7f308f21b956 in ncs_mbcsv_rcv_async_update (peer=0xf525a0, 
evt=0x7f3088004fd0) at 
../../../../../../opensaf/osaf/libs/core/mbcsv/mbcsv_act.c:440
#9  0x7f308f222540 in mbcsv_process_events (rcvd_evt=0x7f3088004fd0, 
mbcsv_hdl=mbcsv_hdl@entry=4293918753) at 
../../../../../../opensaf/osaf/libs/core/mbcsv/mbcsv_pr_evts.c:168
#10 0x7f308f2226ab in mbcsv_hdl_dispatch_all (mbcsv_hdl=4293918753, 
mbx=mbx@entry=4283432961) at 
../../../../../../opensaf/osaf/libs/core/mbcsv/mbcsv_pr_evts.c:272
#11 0x7f308f21ced2 in mbcsv_process_dispatch_request (arg=0x7ffd70275740) 
at ../../../../../../opensaf/osaf/libs/core/mbcsv/mbcsv_api.c:423
#12 0x00413cce in clms_mbcsv_dispatch (mbcsv_hdl=) at 
../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_mbcsv.c:686
#13 0x00405538 in main (argc=, argv=) at 
../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_main.c:536
~~~



---

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] #2051 clm: clmd crashes due to different content in SaNameT value