[tickets] [opensaf:tickets] #1984 log: convert patricia trees to maps in the LOG service

2017-01-23 Thread A V Mahesh (AVM) 
- **status**: assigned --> accepted



---

** [tickets:#1984] log: convert patricia trees to maps in the LOG service**

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Tue Aug 30, 2016 03:51 AM UTC by A V Mahesh (AVM)
**Last Updated:** Tue Aug 30, 2016 03:51 AM UTC
**Owner:** A V Mahesh (AVM)


convert patricia trees to maps in the LOG service


---

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

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2217 mds: optimize use of gl_mds_library_mutex

2017-01-23 Thread A V Mahesh (AVM) 
- **status**: assigned --> accepted



---

** [tickets:#2217] mds: optimize use of gl_mds_library_mutex**

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Tue Dec 06, 2016 09:55 AM UTC by Mathi Naickan
**Last Updated:** Tue Dec 06, 2016 09:55 AM UTC
**Owner:** A V Mahesh (AVM)


A prototyping exercise was done long back to remove this lock but had resulted 
in problems such as out of order. MDS has evolved since then. 
We could revisit the way mds uses gl_mds_library_mutex.
The ticket aims to identify optimization of the way mds gl_mds_library_mutex is 
used.

Details TBD


---

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

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2210 AMFD: Loss of RT attribute update before headless

2017-01-23 Thread Praveen 
Hi,
I think such cases were already discussed in #1725 (on 24th and 25th Oct 2016) 
and has already been documented as one of the limitations. Since it is 
documented, it becomes an enhancement in this release?

Regarding the fix: I think we cannot deviate from normal cluster for any fix. 
In SC-presence/normal cluster, if AMF reverts shutdown admin operation on SI in 
this case, then after SC-absence state also, AMF should revert admin operation. 
This will be consistent with the approach taken in #1725 to see SC-absence as 
gap in time only and after SC-abscence state everything will continue as in 
normanl cluster. 
 
Thanks,
Praveen


---

** [tickets:#2210] AMFD: Loss of RT attribute update before headless**

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Mon Nov 28, 2016 10:18 PM UTC by Minh Hon Chau
**Last Updated:** Mon Jan 23, 2017 01:41 AM UTC
**Owner:** Minh Hon Chau


A loss of IMM RT saAmfSIAdminState update in AMFD has been seen just before 
cluster goes headless. It results in coredump after headless.

One scenario is:
- Issue amf-admin shutdown SI, delay csi quiescing callback
- Stop SCs, release csi quiescing callback
- Restart SCs
Observation: the saAmfSIAdminState is read as UNLOCKED while related SUSI was 
QUIESCED, and coredump as below

~~~
Thread 1 (Thread 0x7fec174a0780 (LWP 493)):
#0  0x004fbfd5 in SG_2N::node_fail_si_oper (this=0x24109d0, 
su=0x2413440) at sg_2n_fsm.cc:3102
s_susi = 0x8f5000b
susi_temp = 0x5fa169
o_su = 0x2417f98
__FUNCTION__ = "node_fail_si_oper"
cb = 0x919240 <_control_block>
#1  0x004fe69c in SG_2N::node_fail (this=0x24109d0, cb=0x919240 
<_control_block>, su=0x2413440) at sg_2n_fsm.cc:
3469
a_susi = 0x1
s_susi = 0x7fffedecd2d0
o_su = 0x5a50bd 
flag = 2
__FUNCTION__ = "node_fail"
su_ha_state = 0
#2  0x00513010 in AVD_SG::failover_absent_assignment (this=0x24109d0) 
at sg.cc:2273
su = @0x2411330: 0x2413440
__for_range = std::vector of length 2, capacity 2 = {0x2413440, 
0x24111e0}
__for_begin = 
__for_end = 
__FUNCTION__ = "failover_absent_assignment"
#3  0x0043be65 in avd_cluster_tmr_init_evh (cb=0x919240 
<_control_block>, evt=0x7fec04000df0) at cluster.cc:103
i_sg = 0x24109d0
it = {first = "safSg=1,safApp=osaftest", second = }
__FUNCTION__ = "avd_cluster_tmr_init_evh"
su = 0x0
node = 0x240f9b0
~~~



---

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

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2254 log: reuse of deleted resources leads to agent coredump

2017-01-23 Thread A V Mahesh (AVM) 
- **status**: review --> fixed
- **Comment**:

changeset:   8529:276b32344fd8
user:A V Mahesh 
date:Tue Jan 24 09:36:21 2017 +0530
summary: lga: assign valid client after invalid handle removal [#2254]
 
changeset:   8530:6ca9b46fcf4e
branch:  opensaf-5.1.x
tag: tip
parent:  8525:7336414d6a07
user:A V Mahesh 
date:Tue Jan 24 09:37:41 2017 +0530
summary: lga: assign valid client after invalid handle removal [#2254]

changeset:   8531:3cb09326f1ce
branch:  opensaf-5.0.x
tag: tip
parent:  8526:88555159b006
user:A V Mahesh 
date:Tue Jan 24 09:41:06 2017 +0530
summary: lga: assign valid client after invalid handle removal [#2254]



---

** [tickets:#2254] log: reuse of deleted resources leads to agent coredump**

**Status:** fixed
**Milestone:** 5.0.2
**Created:** Mon Jan 09, 2017 07:30 AM UTC by Tai Dinh
**Last Updated:** Wed Jan 18, 2017 06:54 AM UTC
**Owner:** A V Mahesh (AVM)


Below part of code looks not really safe:
~~~
rc = lga_recover_one_client(p_client);
TRACE("\t Client %d is recovered", p_client->lgs_client_id);
if (rc == -1) {
TRACE("%s recover_one_client Fail Deleting client (id 
%d)",
__FUNCTION__, p_client->lgs_client_id);
/* Fail to recover this client
 * Remove (handle invalidated)
 */
(void) lga_hdl_rec_del(_cb.client_list, p_client);
}

/* Next client */
p_client = p_client->next;
~~~
Note that after the lga_hdl_rec_del, the content of p_client had been freed 
already. So the next assignment statement will assign p_client to a non-valid 
memory.
The coredump was generated when we try to access the recovered_flag, but we can 
even crash at the assignment line also.

~~~
--
7f1a883f8cd5: /usr/lib64/libSaLog.so.1: file format elf64-x86-64


Disassembly of section .text:

7cd5 :
recovery2_thread():
/mnt/jenkins_virtual_disk/jenkins_work_folder/workspace/E2_Build_Cmw_x86_64/P1A01/opensaf/osaf/libs/agents/saf/lga/../../../../../../../opensaf/osaf/libs/agents/saf/lga/lga_state.c:362
 (discriminator 2)
7cd5:   80 7b 39 00 cmpb   $0x0,0x39(%rbx)

--
7f1f749190a4: /lib64/libpthread.so.0: file format elf64-x86-64


Disassembly of section .text:

80a4 :
start_thread():
80a4:   64 48 89 04 25 30 06mov%rax,%fs:0x630
80ab:   00 00

--
7f1f7464e02d: /lib64/libc.so.6: file format elf64-x86-64


Disassembly of section .text:

000e502d <__clone+0x6d>:
__clone():
   e502d:   48 89 c7mov%rax,%rdi

--

~~~
/Tai


---

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

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2023 AMF : Long DN RT objects creation failed with ERR_TOO_LONG (13)

2017-01-23 Thread Minh Hon Chau 
- **status**: accepted --> assigned
- **Milestone**: 5.2.FC --> future



---

** [tickets:#2023] AMF : Long DN RT objects creation failed with ERR_TOO_LONG 
(13)**

**Status:** assigned
**Milestone:** future
**Created:** Sat Sep 10, 2016 10:57 AM UTC by Srikanth R
**Last Updated:** Tue Sep 20, 2016 01:42 AM UTC
**Owner:** Minh Hon Chau
**Attachments:**

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


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


Summary :
--
 Long DN RT objects creation failed with ERR_TOO_LONG during unlock operation 
of SU.


Steps followed & Observed behaviour
--

-> Initially enabled the longDn feature.

-> Later imported the attached AMF configuration successfully.

-> Now performed unlock-in and unlock operation of SU, for which following 
error is observed in syslog.

Sep 10 16:11:43 CONTROLLER-2 osafamfnd[4279]: NO Assigned 
'safSi=AmfDemoabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz,safApp=AmfDemoabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz'
 ACTIVE to 'safSu=SU1,safSg=AmfDemoabcdefghijklmnopqrstuvwxyzabcdefghijklmnopq
 
rstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz,safApp=AmfDemoabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz'
Sep 10 16:11:43 CONTROLLER-2 osafamfd[4265]: ER exec: create FAILED 13
Sep 10 16:11:46 CONTROLLER-2 osafamfd[4265]:** ER exec: create FAILED 13**


Below is the corresponding trace in osafamfd :


Sep 10 16:11:46.647681 osafamfd [4265:imm.cc:0396] >> execute
Sep 10 16:11:46.647730 osafamfd [4265:imm.cc:0142] >> exec: Create 
safCsi=AmfDemoabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz_CSIA,safSi=AmfDemoabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz,safApp=AmfDemoabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxy
 zabcdefghijklmnopqrstuvT
Sep 10 16:11:46.647783 osafamfd [4265:imma_oi_api.c:2786] >> 
rt_object_create_common
Sep 10 16:11:46.647879 osafamfd [4265:imma_oi_api.c:2892] TR attr:safCSIComp
Sep 10 16:11:46.647908 osafamfd [4265:imma_oi_api.c:2892] TR 
attr:saAmfCSICompHAState
Sep 10 16:11:46.647927 osafamfd [4265:imma_oi_api.c:2892] TR 
attr:saAmfCSICompHAReadinessState
Sep 10 16:11:46.649108 osafamfd [4265:imma_oi_api.c:3063] << 
rt_object_create_common
Sep 10 16:11:46.649157 osafamfd [4265:imm.cc:0163] ER exec: create FAILED 13




---

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] #2262 base: Improve TRACE_ENTER, TRACE_LEAVE macros

2017-01-23 Thread Zoran Milinkovic 
changeset:   8528:4ad8ec96077f
tag: tip
user:Zoran Milinkovic 
date:Mon Jan 23 16:15:43 2017 +0100
summary: base: fix OpenSAF build [#2262]



---

** [tickets:#2262] base: Improve TRACE_ENTER, TRACE_LEAVE macros**

**Status:** fixed
**Milestone:** 5.2.FC
**Created:** Fri Jan 13, 2017 09:35 AM UTC by Hans Nordebäck
**Last Updated:** Mon Jan 23, 2017 12:02 PM UTC
**Owner:** Hans Nordebäck


Improve TRACE_ENTER, TRACE_LEAVE macros for C++ functions. A new class Trace is 
introduced to make TRACE_ENTER/TRACE_LEAVE consistent. The Trace destructor 
will handle all missing TRACE_LEAVE at runtime (RAII idiom). TRACE_LEAVEs 
without a matching TRACE_ENTER are handled at compile time. To identify all 
missing TRACE_LEAVE zeroes are written as line number:

Jan 13 10:03:48.925438 osafamfd [491:src/amf/amfd/sg_nored_fsm.cc:0325] >> 
susi_success: 1
  :
Jan 13 10:03:48.929056 osafamfd [491:src/amf/amfd/sg_nored_fsm.cc:] << 
susi_success

The trace2dot tool and e.g. dotty can be used to get a call graph.


---

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

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2265 clm: clmd coredump

2017-01-23 Thread Praveen 
- **status**: unassigned --> assigned
- **assigned_to**: Praveen
- **Milestone**: 5.2.FC --> 5.0.2
- **Comment**:

Hi Hung,

Thanks for the logs. I am going thorugh them.

Thanks,
Praveen



---

** [tickets:#2265] clm: clmd coredump**

**Status:** assigned
**Milestone:** 5.0.2
**Created:** Mon Jan 16, 2017 08:51 AM UTC by Hung Nguyen
**Last Updated:** Mon Jan 23, 2017 09:01 AM UTC
**Owner:** Praveen


Jan 11 10:36:23 SC-2 osafclmd[14467]: ER Node is NULL,problem with the database.
**Jan 11 10:36:23 SC-2 osafclmd[14467]: 
../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_mbcsv.c:467: 
ckpt_proc_node_rec: Assertion '0' failed.**
Jan 11 10:36:23 SC-2 osafamfnd[14497]: NO 
'safComp=CLM,safSu=SC-2,safSg=2N,safApp=OpenSAF' faulted due to 'avaDown' : 
Recovery is 'nodeFailfast'
Jan 11 10:36:23 SC-2 osafamfnd[14497]: ER 
safComp=CLM,safSu=SC-2,safSg=2N,safApp=OpenSAF Faulted due to:avaDown Recovery 
is:nodeFailfast
Jan 11 10:36:23 SC-2 osafamfnd[14497]: Rebooting OpenSAF NodeId = 131599 EE 
Name = , Reason: Component faulted: recovery is node failfast, OwnNodeId = 
131599, SupervisionTime = 60
Jan 11 10:36:23 SC-2 opensaf_reboot: Rebooting local node; timeout=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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2262 base: Improve TRACE_ENTER, TRACE_LEAVE macros

2017-01-23 Thread Hans Nordebäck 
- **status**: review --> fixed
- **Comment**:

changeset:   8527:7111d57a1590
tag: tip
parent:  8524:2605957a234b
user:Hans Nordeback 
date:Mon Jan 23 08:23:26 2017 +0100
files:   src/amf/amfd/ckpt_dec.cc src/amf/amfd/clm.cc src/amf/amfd/csi.cc 
src/amf/amfd/node.cc src/amf/amfd/nodegroup.cc src/amf/amfd/si_dep.cc 
src/amf/amfnd/pgdb.cc src/amf/amfnd/su.cc src/base/logtrace.c 
src/base/logtrace.h src/imm/agent/imma_init.cc src/imm/agent/imma_om_api.cc 
src/imm/immnd/ImmModel.cc src/imm/immpbed/immpbe_daemon.cc 
src/log/logd/lgs_imm_gcfg.cc src/log/logd/lgs_main.cc src/log/logd/lgs_mbcsv.cc 
src/ntf/ntfd/NtfClient.cc src/smf/smfd/SmfCampaignXmlParser.cc 
src/smf/smfd/SmfUpgradeStep.cc
description:
base: Improve TRACE_ENTER, TRACE_LEAVE macros [#2262]




---

** [tickets:#2262] base: Improve TRACE_ENTER, TRACE_LEAVE macros**

**Status:** fixed
**Milestone:** 5.2.FC
**Created:** Fri Jan 13, 2017 09:35 AM UTC by Hans Nordebäck
**Last Updated:** Fri Jan 13, 2017 09:51 AM UTC
**Owner:** Hans Nordebäck


Improve TRACE_ENTER, TRACE_LEAVE macros for C++ functions. A new class Trace is 
introduced to make TRACE_ENTER/TRACE_LEAVE consistent. The Trace destructor 
will handle all missing TRACE_LEAVE at runtime (RAII idiom). TRACE_LEAVEs 
without a matching TRACE_ENTER are handled at compile time. To identify all 
missing TRACE_LEAVE zeroes are written as line number:

Jan 13 10:03:48.925438 osafamfd [491:src/amf/amfd/sg_nored_fsm.cc:0325] >> 
susi_success: 1
  :
Jan 13 10:03:48.929056 osafamfd [491:src/amf/amfd/sg_nored_fsm.cc:] << 
susi_success

The trace2dot tool and e.g. dotty can be used to get a call graph.


---

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

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2133 AMF: Rollback admin shutdown/lock SI operation if node failover

2017-01-23 Thread Nagendra Kumar 
I will provied fix of 2N red model for 5.2 release. The fix would be to return 
TIMEOUT for failure of admin shutdown cases when shutdown admin op gets 
reverted and admin state is rolled back to Unlocked.


---

** [tickets:#2133] AMF: Rollback admin shutdown/lock SI operation if node 
failover**

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Thu Oct 20, 2016 06:49 PM UTC by Minh Hon Chau
**Last Updated:** Mon Jan 23, 2017 11:15 AM UTC
**Owner:** Nagendra Kumar


In scenario of shut down SI, delay QUIESCING csi callback, then reboot the node 
that hosting SU having pending this csi callback. The result of this operation 
looks differently between SGs
- For 2N: the SI Admin state is rollbacked to UNLOCK 
- For Nway: the SI Admin state moves to LOCKED
- In NpM: Haven't tested just browsing SG_NPM::node_fail_si_oper, looks SI 
Admin states rollbacks to UNLOCK

My question is whether the result of these scenario should be consistent? And 
what's the expected outcome?
Also, the handling of node_fail_si_oper for admin lock is not consistent. For 
2N, Admin state remains LOCKED, NpM rollbacks to UNLOCK


---

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

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2133 AMF: Rollback admin shutdown/lock SI operation if node failover

2017-01-23 Thread Nagendra Kumar 
>>Comparing to your findings, is there something we have to do with "single SI 
>>assignment, the admin state is locked." for su f/o and node f/o?
No, I think, if it is single SI assignment, we can return Success and mark 
admin state as Locked.
>>Another question, do you know use case's motivation or technical problem 
>>behind that we had this deviation/inconsistency?
It is for ease of flow. Like for single SI, we can easily mark locked and 
remove the assignments from Act SU. For SIs having two assignments, 2N red 
model is reusing SU switchover codes, it leaves Si in unlocked state.


---

** [tickets:#2133] AMF: Rollback admin shutdown/lock SI operation if node 
failover**

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Thu Oct 20, 2016 06:49 PM UTC by Minh Hon Chau
**Last Updated:** Mon Jan 23, 2017 08:29 AM UTC
**Owner:** Nagendra Kumar


In scenario of shut down SI, delay QUIESCING csi callback, then reboot the node 
that hosting SU having pending this csi callback. The result of this operation 
looks differently between SGs
- For 2N: the SI Admin state is rollbacked to UNLOCK 
- For Nway: the SI Admin state moves to LOCKED
- In NpM: Haven't tested just browsing SG_NPM::node_fail_si_oper, looks SI 
Admin states rollbacks to UNLOCK

My question is whether the result of these scenario should be consistent? And 
what's the expected outcome?
Also, the handling of node_fail_si_oper for admin lock is not consistent. For 
2N, Admin state remains LOCKED, NpM rollbacks to UNLOCK


---

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

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1209 IMM: OI callback timer should be restored after a ccb-augment is closed

2017-01-23 Thread Neelakanta Reddy 
- **Milestone**: 5.2.FC --> future



---

** [tickets:#1209] IMM: OI callback timer should be restored after a 
ccb-augment is closed**

**Status:** assigned
**Milestone:** future
**Created:** Tue Nov 11, 2014 12:49 PM UTC by Anders Bjornerstedt
**Last Updated:** Mon Aug 29, 2016 08:13 PM UTC
**Owner:** Neelakanta Reddy


This is related to ticket #1208.

http://sourceforge.net/p/opensaf/tickets/1208/

After an OI has closed a ccb-augmentation, the callback timer monitoring 
the liveness of the OI in that callback, should be restored. 

This requires the addition of a new message type to the IMMA->IMMND protocol.



---

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

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2274 ntf: replace log Error with Warning while sending clm status to NTFA clients.

2017-01-23 Thread Praveen 



---

** [tickets:#2274] ntf: replace log Error with Warning while sending clm status 
to NTFA clients. **

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Mon Jan 23, 2017 09:06 AM UTC by Praveen
**Last Updated:** Mon Jan 23, 2017 09:06 AM UTC
**Owner:** Praveen
**Attachments:**

- 
[messages](https://sourceforge.net/p/opensaf/tickets/2274/attachment/messages) 
(3.0 kB; application/octet-stream)
- 
[osafntfd](https://sourceforge.net/p/opensaf/tickets/2274/attachment/osafntfd) 
(99.8 kB; application/octet-stream)


Issue can be observed only when application registers with A.01.02 with NTF 
service.
When nodes loses CLM membership, CLM notifies this by sending track callback to 
registered clents.
In this issue a node loses the CLM membership. When NTFS was processing CLM 
callback to send the membership status of this node to the clients hosted on 
this node, client application also exited. Upon client exit, MDS clears its 
destination. Since NTFS is in the middle of processing CLM callback, it has 
still not processed MDS_DOWN of client. NTFS get failure from MDS while sending 
membership status to client as MDS has already cleared cleint info.
Steps to reproduce:
1)Being two controllers up.
2)On standby controller, run 5 to 6 process of ntfsubscribe.
3)Reboot standby controller by issuing reboot command.
4) NTF may get CLM track callback first. While sending CLM status to standby, 
it logs err:
   ER ntfs_mds_msg_send to ntfa failed rc: 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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2265 clm: clmd coredump

2017-01-23 Thread Hung Nguyen 
Hi,
Here's the syslog, trace was not enabled.



Attachments:

- 
[systemlogs.tgz](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/b86ccaf0/1f0e/attachment/systemlogs.tgz)
 (240.1 kB; application/x-compressed)


---

** [tickets:#2265] clm: clmd coredump**

**Status:** unassigned
**Milestone:** 5.2.FC
**Created:** Mon Jan 16, 2017 08:51 AM UTC by Hung Nguyen
**Last Updated:** Thu Jan 19, 2017 08:49 AM UTC
**Owner:** nobody


Jan 11 10:36:23 SC-2 osafclmd[14467]: ER Node is NULL,problem with the database.
**Jan 11 10:36:23 SC-2 osafclmd[14467]: 
../../../../../../../opensaf/osaf/services/saf/clmsv/clms/clms_mbcsv.c:467: 
ckpt_proc_node_rec: Assertion '0' failed.**
Jan 11 10:36:23 SC-2 osafamfnd[14497]: NO 
'safComp=CLM,safSu=SC-2,safSg=2N,safApp=OpenSAF' faulted due to 'avaDown' : 
Recovery is 'nodeFailfast'
Jan 11 10:36:23 SC-2 osafamfnd[14497]: ER 
safComp=CLM,safSu=SC-2,safSg=2N,safApp=OpenSAF Faulted due to:avaDown Recovery 
is:nodeFailfast
Jan 11 10:36:23 SC-2 osafamfnd[14497]: Rebooting OpenSAF NodeId = 131599 EE 
Name = , Reason: Component faulted: recovery is node failfast, OwnNodeId = 
131599, SupervisionTime = 60
Jan 11 10:36:23 SC-2 opensaf_reboot: Rebooting local node; timeout=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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2133 AMF: Rollback admin shutdown/lock SI operation if node failover

2017-01-23 Thread Nagendra Kumar 
- **status**: unassigned --> accepted
- **assigned_to**: Nagendra Kumar
- **Milestone**: future --> 5.2.FC



---

** [tickets:#2133] AMF: Rollback admin shutdown/lock SI operation if node 
failover**

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Thu Oct 20, 2016 06:49 PM UTC by Minh Hon Chau
**Last Updated:** Thu Jan 19, 2017 03:27 AM UTC
**Owner:** Nagendra Kumar


In scenario of shut down SI, delay QUIESCING csi callback, then reboot the node 
that hosting SU having pending this csi callback. The result of this operation 
looks differently between SGs
- For 2N: the SI Admin state is rollbacked to UNLOCK 
- For Nway: the SI Admin state moves to LOCKED
- In NpM: Haven't tested just browsing SG_NPM::node_fail_si_oper, looks SI 
Admin states rollbacks to UNLOCK

My question is whether the result of these scenario should be consistent? And 
what's the expected outcome?
Also, the handling of node_fail_si_oper for admin lock is not consistent. For 
2N, Admin state remains LOCKED, NpM rollbacks to UNLOCK


---

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

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2270 imm: Missing check for SaString attributes with ATTR_DN flag

2017-01-23 Thread Hung Nguyen 
- **status**: accepted --> review



---

** [tickets:#2270] imm: Missing check for SaString attributes with ATTR_DN 
flag**

**Status:** review
**Milestone:** 5.0.2
**Created:** Wed Jan 18, 2017 11:03 AM UTC by Hung Nguyen
**Last Updated:** Wed Jan 18, 2017 11:03 AM UTC
**Owner:** Hung Nguyen


A combination of SA_IMM_ATTR_SASTRINGT and SA_IMM_ATTR_DN should be treated as 
SA_IMM_ATTR_SANAMET.
Some places in IMM code miss the check for SaStringT

Example:
~~~
ImmModel::rtObjectCreate()
} else if (attrValues->n.attrValueType == SA_IMM_ATTR_SANAMET
&& !longDnsPermitted) {
...
if(attrValues->n.attrValue.val.x.size >= 
SA_MAX_UNEXTENDED_NAME_LENGTH) {
LOG_NO("ERR_NAME_TOO_LONG: Attribute '%s' has long DN. "
"Not allowed by IMM service or extended names are disabled",
attrName.c_str());
err = SA_AIS_ERR_NAME_TOO_LONG;
goto rtObjectCreateExit;
}
~~~



---

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

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets