[tickets] [opensaf:tickets] #1069 NTF: Incorrect or no validation of ntfsend option attributes

2014-09-16 Thread Praveen
- **status**: unassigned -- accepted
- **assigned_to**: Praveen



---

** [tickets:#1069] NTF: Incorrect or no validation of ntfsend option 
attributes**

**Status:** accepted
**Milestone:** 4.3.3
**Created:** Fri Sep 12, 2014 02:26 PM UTC by elunlen
**Last Updated:** Fri Sep 12, 2014 02:26 PM UTC
**Owner:** Praveen

No validation is done for attributes used with option for the ntfsend tool. 
E.g. a non numerical value is possible to give for option -E eventTime which 
result in 0 as event time.


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] Re: #1072 Sync stop after few payload nodes joining the cluster (TCP)

2014-09-16 Thread Anders Bjornerstedt
Instead of blindly changing other configuration parameters, please first try to 
find out what the PROBLEM is.
Go back to OpensAF defaults on all settings, except IMMSV_FEVS_MAX_PENDING 
which you had
increased to 255 (the maximum possible).

You said you had managed to overcome the perormance issue temporarily by this 
increase to 255.
What does that mean ?
Do you still get the problem after some time? or not? with only that change.

How much traffic are you generating ?
Not counting SYNC traffic here, I mean YOUR application traffic.
Do you have zero traffic ?
Obviously it is possible to generate too much traffic on ANY configuration and 
you will end up with
symptoms like the ones you see.

If the problem appears fixed by the 255 (maximum) setting, try *reducing* 
IMMSV_FEVS_MAX_PENDING
down again by 50% from 255  (current maximum possible) to 128.
Test this some time and see if you have a stable system.
If stable repeat, i.e. reduce again by 50%, test again etc, untill you get to a 
level where the problem re-appears.
Then double the value back up to the lowest level where it appeared to be 
stable.

This would solve the problem if the cause is that your setup has more VARIANCE 
in latency,
more bursty traffic, more chunky scheduling of execution for the 
containters/processors/processes/threads.
If that is the case then the problem is not traffic overload but that you 
indeed need some buffers to be larger
to avoid the extremes of the variance to cut you off.

/AndersBj



From: Adrian Szwej [mailto:adriansz...@users.sf.net]
Sent: den 16 september 2014 00:47
To: opensaf-tickets@lists.sourceforge.net
Subject: [tickets] [opensaf:tickets] #1072 Sync stop after few payload nodes 
joining the cluster (TCP)


I have also tried following flavours:
Larger MDS buffers

export MDS_SOCK_SND_RCV_BUF_SIZE=126976
DTM_SOCK_SND_RCV_BUF_SIZE=126976


Longer keep alive settings

OpenSAF build 4.5

MTU 9000
veth4e51 Link encap:Ethernet HWaddr aa:a6:f0:5f:0f:82
UP BROADCAST RUNNING MTU:9000 Metric:1
--
veth76a4 Link encap:Ethernet HWaddr 9a:ea:07:f4:be:55
UP BROADCAST RUNNING MTU:9000 Metric:1
--
vethb5f5 Link encap:Ethernet HWaddr 22:98:e3:39:32:34
UP BROADCAST RUNNING MTU:9000 Metric:1
--
vethb9e3 Link encap:Ethernet HWaddr d2:ec:18:c4:f9:2d
UP BROADCAST RUNNING MTU:9000 Metric:1
--
vethd703 Link encap:Ethernet HWaddr 3e:a0:49:c0:f0:73
UP BROADCAST RUNNING MTU:9000 Metric:1
--
vethf736 Link encap:Ethernet HWaddr 4e:c4:6e:74:fc:03
UP BROADCAST RUNNING MTU:9000 Metric:1

Ping during sync between containers show latency of 0.250-0.500 ms.

The result is the same.
I can provoke the problem by cycling start/stop of 6th opensaf instance in 
linux container.

while ( true ); do /etc/init.d/opensafd stop  /etc/init.d/opensafd start; done




[tickets:#1072]http://sourceforge.net/p/opensaf/tickets/1072 Sync stop after 
few payload nodes joining the cluster (TCP)

Status: invalid
Milestone: 4.3.3
Created: Fri Sep 12, 2014 09:20 PM UTC by Adrian Szwej
Last Updated: Mon Sep 15, 2014 09:48 PM UTC
Owner: Anders Bjornerstedt

Communication is MDS over TCP. Cluster 2+3; where scenario is
Start SCs; start 1 payload; wait for sync; start second payload; wait for sync; 
start 3rd payload. Third one fails; or sometimes it might be forth.

There is problem of getting more than 2/3 payloads synchronized due to a 
consistent way of triggering a bug.

The following is triggered in the loading immnd causing the joined node to 
timeout/fail to start up.

Sep 6 6:58:02.096550 osafimmnd [502:immsv_evt.c:5382] T8 Received: 
IMMND_EVT_A2ND_SEARCHNEXT (17) from 2020f
Sep 6 6:58:02.096575 osafimmnd [502:immnd_evt.c:1443]  
immnd_evt_proc_search_next
Sep 6 6:58:02.096613 osafimmnd [502:immnd_evt.c:1454] T2 SEARCH NEXT, Look for 
id:1664
Sep 6 6:58:02.096641 osafimmnd [502:ImmModel.cc:1366] T2 ERR_TRY_AGAIN: Too 
many pending incoming fevs messages ( 16) rejecting sync iteration next request
Sep 6 6:58:02.096725 osafimmnd [502:immnd_evt.c:1676]  
immnd_evt_proc_search_next
Sep 6 6:58:03.133230 osafimmnd [502:immnd_proc.c:1980] IN Sync Phase-3: step:540

I have managed to overcome this bug temporary by making following patch:

+++ b/osaf/libs/common/immsv/include/immsv_api.hSat Sep 06 08:38:16 
2014 +
@@ -70,7 +70,7 @@

 /*Max # of outstanding fevs messages towards director.*/
 /*Note max-max is 255. cb-fevs_replies_pending is an uint8_t*/
-#define IMMSV_DEFAULT_FEVS_MAX_PENDING 16
+#define IMMSV_DEFAULT_FEVS_MAX_PENDING 255

 #define IMMSV_MAX_OBJECTS 1
 #define IMMSV_MAX_ATTRIBUTES 128




Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to 
https://sourceforge.net/p/opensaf/tickets/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 

Re: [tickets] [opensaf:tickets] #1072 Sync stop after few payload nodes joining the cluster (TCP)

2014-09-16 Thread Anders Björnerstedt
Instead of blindly changing other configuration parameters, please first try to 
find out what the PROBLEM is.
Go back to OpensAF defaults on all settings, except IMMSV_FEVS_MAX_PENDING 
which you had
increased to 255 (the maximum possible).

You said you had managed to overcome the perormance issue temporarily by this 
increase to 255.
What does that mean ?
Do you still get the problem after some time? or not? with only that change.

How much traffic are you generating ?
Not counting SYNC traffic here, I mean YOUR application traffic.
Do you have zero traffic ?
Obviously it is possible to generate too much traffic on ANY configuration and 
you will end up with
symptoms like the ones you see.

If the problem appears fixed by the 255 (maximum) setting, try *reducing* 
IMMSV_FEVS_MAX_PENDING
down again by 50% from 255  (current maximum possible) to 128.
Test this some time and see if you have a stable system.
If stable repeat, i.e. reduce again by 50%, test again etc, untill you get to a 
level where the problem re-appears.
Then double the value back up to the lowest level where it appeared to be 
stable.

This would solve the problem if the cause is that your setup has more VARIANCE 
in latency,
more bursty traffic, more chunky scheduling of execution for the 
containters/processors/processes/threads.
If that is the case then the problem is not traffic overload but that you 
indeed need some buffers to be larger
to avoid the extremes of the variance to cut you off.

/AndersBj



From: Adrian Szwej [mailto:adriansz...@users.sf.net]
Sent: den 16 september 2014 00:47
To: opensaf-tickets@lists.sourceforge.net
Subject: [tickets] [opensaf:tickets] #1072 Sync stop after few payload nodes 
joining the cluster (TCP)


I have also tried following flavours:
Larger MDS buffers

export MDS_SOCK_SND_RCV_BUF_SIZE=126976
DTM_SOCK_SND_RCV_BUF_SIZE=126976


Longer keep alive settings

OpenSAF build 4.5

MTU 9000
veth4e51 Link encap:Ethernet HWaddr aa:a6:f0:5f:0f:82
UP BROADCAST RUNNING MTU:9000 Metric:1
--
veth76a4 Link encap:Ethernet HWaddr 9a:ea:07:f4:be:55
UP BROADCAST RUNNING MTU:9000 Metric:1
--
vethb5f5 Link encap:Ethernet HWaddr 22:98:e3:39:32:34
UP BROADCAST RUNNING MTU:9000 Metric:1
--
vethb9e3 Link encap:Ethernet HWaddr d2:ec:18:c4:f9:2d
UP BROADCAST RUNNING MTU:9000 Metric:1
--
vethd703 Link encap:Ethernet HWaddr 3e:a0:49:c0:f0:73
UP BROADCAST RUNNING MTU:9000 Metric:1
--
vethf736 Link encap:Ethernet HWaddr 4e:c4:6e:74:fc:03
UP BROADCAST RUNNING MTU:9000 Metric:1

Ping during sync between containers show latency of 0.250-0.500 ms.

The result is the same.
I can provoke the problem by cycling start/stop of 6th opensaf instance in 
linux container.

while ( true ); do /etc/init.d/opensafd stop  /etc/init.d/opensafd start; done




[tickets:#1072]http://sourceforge.net/p/opensaf/tickets/1072 Sync stop after 
few payload nodes joining the cluster (TCP)

Status: invalid
Milestone: 4.3.3
Created: Fri Sep 12, 2014 09:20 PM UTC by Adrian Szwej
Last Updated: Mon Sep 15, 2014 09:48 PM UTC
Owner: Anders Bjornerstedt

Communication is MDS over TCP. Cluster 2+3; where scenario is
Start SCs; start 1 payload; wait for sync; start second payload; wait for sync; 
start 3rd payload. Third one fails; or sometimes it might be forth.

There is problem of getting more than 2/3 payloads synchronized due to a 
consistent way of triggering a bug.

The following is triggered in the loading immnd causing the joined node to 
timeout/fail to start up.

Sep 6 6:58:02.096550 osafimmnd [502:immsv_evt.c:5382] T8 Received: 
IMMND_EVT_A2ND_SEARCHNEXT (17) from 2020f
Sep 6 6:58:02.096575 osafimmnd [502:immnd_evt.c:1443]  
immnd_evt_proc_search_next
Sep 6 6:58:02.096613 osafimmnd [502:immnd_evt.c:1454] T2 SEARCH NEXT, Look for 
id:1664
Sep 6 6:58:02.096641 osafimmnd [502:ImmModel.cc:1366] T2 ERR_TRY_AGAIN: Too 
many pending incoming fevs messages ( 16) rejecting sync iteration next request
Sep 6 6:58:02.096725 osafimmnd [502:immnd_evt.c:1676]  
immnd_evt_proc_search_next
Sep 6 6:58:03.133230 osafimmnd [502:immnd_proc.c:1980] IN Sync Phase-3: step:540

I have managed to overcome this bug temporary by making following patch:

+++ b/osaf/libs/common/immsv/include/immsv_api.hSat Sep 06 08:38:16 
2014 +
@@ -70,7 +70,7 @@

 /*Max # of outstanding fevs messages towards director.*/
 /*Note max-max is 255. cb-fevs_replies_pending is an uint8_t*/
-#define IMMSV_DEFAULT_FEVS_MAX_PENDING 16
+#define IMMSV_DEFAULT_FEVS_MAX_PENDING 255

 #define IMMSV_MAX_OBJECTS 1
 #define IMMSV_MAX_ATTRIBUTES 128




Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to 
https://sourceforge.net/p/opensaf/tickets/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 

[tickets] [opensaf:tickets] #1088 IMM: immnd may crash if client node is NULL in immnd_evt_proc_fevs_forward

2014-09-16 Thread Anders Bjornerstedt
- **status**: unassigned -- assigned
- **assigned_to**: Anders Bjornerstedt



---

** [tickets:#1088] IMM: immnd may crash if client node is NULL in 
immnd_evt_proc_fevs_forward**

**Status:** assigned
**Milestone:** 4.3.3
**Created:** Mon Sep 15, 2014 02:38 PM UTC by Zoran Milinkovic
**Last Updated:** Mon Sep 15, 2014 02:38 PM UTC
**Owner:** Anders Bjornerstedt

immnd may crash if client node is NULL in immnd_evt_proc_fevs_forward.

Next IF statement need a check before !(cl_node-mIsSync) that cl_node is not 
NULL

} else if((evt-info.fevsReq.sender_count == 0x1)  
!(cl_node-mIsSync) 
(immModel_immNotWritable(cb) ||  (cb-mSyncFinalizing 
 cb-fevs_out_count))) {


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1087 imm: assign instead of compare in immnd_evt_proc_rt_object_delete

2014-09-16 Thread Anders Bjornerstedt
- **status**: unassigned -- accepted
- **assigned_to**: Anders Bjornerstedt



---

** [tickets:#1087] imm: assign instead of compare in 
immnd_evt_proc_rt_object_delete**

**Status:** accepted
**Milestone:** 4.3.3
**Created:** Mon Sep 15, 2014 02:25 PM UTC by Zoran Milinkovic
**Last Updated:** Mon Sep 15, 2014 02:25 PM UTC
**Owner:** Anders Bjornerstedt

In IF statement in immnd_evt_proc_rt_object_delete, there is assigning of value 
instead of comparing. 
There should be (err == SA_AIS_OK)

if(spApplConn  (err = SA_AIS_OK)  !delayedReply) {




---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1092 2PBE: pbed exits with error 'cannot rollback - no transaction is active'

2014-09-16 Thread Sirisha Alla



---

** [tickets:#1092] 2PBE: pbed exits with error 'cannot rollback - no 
transaction is active'**

**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Tue Sep 16, 2014 07:12 AM UTC by Sirisha Alla
**Last Updated:** Tue Sep 16, 2014 07:12 AM UTC
**Owner:** nobody

The issue is seen on SLES X86 VMs running with opensaf changeset 5697+#946 
patches. IMM DB is loaded with 50k objects.

IMM Applications along with switchover is in progress.

Following is observed in the syslog of SC-1:

Sep 16 11:07:27 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE time-out in waiting 
on porepare for PRTA update ccb:101c4 
dn:safNode=PL-3,safCluster=myClmCluster
Sep 16 11:07:28 SLES-64BIT-SLOT1 osafimmpbed: ER SQL statement ('ROLLBACK') 
failed because:  cannot rollback - no transaction is active
Sep 16 11:07:28 SLES-64BIT-SLOT1 osafimmpbed: ER Exiting (line:2843)

An application class is created just before the PBE process started.

Sep 16 11:07:32 SLES-64BIT-SLOT1 osafimmnd[2384]: NO Create of class 
testMA_verifyObjCompCallbackNode_101_133 is PERSISTENT.

When the PBE process started verification of pbe state failed.

Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: NO Successfully opened 
pre-existing sqlite pbe file /home/sirisha/immsv/immpbe/imm.db.2010f
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: IN saImmRepositoryInit: 
SA_IMM_KEEP_REPOSITORY - attaching to repository
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: ER Expected 1 row got 0 rows 
(line: 1161)
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: WA Verify class 
testMA_verifyObjCompCallbackNode_101_133 failed!
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: NO Renamed 
/home/sirisha/immsv/immpbe/imm.db.2010f to 
/home/sirisha/immsv/immpbe/imm.db.2010f.failed_immdump because it has been 
detected to be corrupt.
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: NO Removed obsolete journal file: 
/home/sirisha/immsv/immpbe/imm.db.2010f-journal
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: WA verifyPbeState failed!
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: WA Pbe: Failed to re-attach to db 
file /home/sirisha/immsv/immpbe/imm.db.2010f - regenerating db file
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: IN Generating DB file from 
current IMM state. DB file: /home/sirisha/immsv/immpbe/imm.db.2010f

Syslog and IMMND traces on both the controllers is attached. there might be a 
few seconds time difference between the two slots.


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] Re: #1092 2PBE: pbed exits with error 'cannot rollback - no transaction is active'

2014-09-16 Thread Anders Bjornerstedt
I suggest we hold off testing 2PBE and creating more 2PBE tickets for a while 
now.

Many of the already existing tickets probably overlap in their cause.
So we will most likley save time for everyone by fixing these tickets and after 
that resume testing.

We are trying to focus on 4.5 also.

/AndersBj


From: Sirisha Alla [mailto:al...@users.sf.net]
Sent: den 16 september 2014 09:13
To: opensaf-tickets@lists.sourceforge.net
Subject: [tickets] [opensaf:tickets] #1092 2PBE: pbed exits with error 'cannot 
rollback - no transaction is active'



[tickets:#1092]http://sourceforge.net/p/opensaf/tickets/1092 2PBE: pbed exits 
with error 'cannot rollback - no transaction is active'

Status: unassigned
Milestone: 4.3.3
Created: Tue Sep 16, 2014 07:12 AM UTC by Sirisha Alla
Last Updated: Tue Sep 16, 2014 07:12 AM UTC
Owner: nobody

The issue is seen on SLES X86 VMs running with opensaf changeset 5697+#946 
patches. IMM DB is loaded with 50k objects.

IMM Applications along with switchover is in progress.

Following is observed in the syslog of SC-1:

Sep 16 11:07:27 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE time-out in waiting 
on porepare for PRTA update ccb:101c4 
dn:safNode=PL-3,safCluster=myClmCluster
Sep 16 11:07:28 SLES-64BIT-SLOT1 osafimmpbed: ER SQL statement ('ROLLBACK') 
failed because: cannot rollback - no transaction is active
Sep 16 11:07:28 SLES-64BIT-SLOT1 osafimmpbed: ER Exiting (line:2843)

An application class is created just before the PBE process started.

Sep 16 11:07:32 SLES-64BIT-SLOT1 osafimmnd[2384]: NO Create of class 
testMA_verifyObjCompCallbackNode_101_133 is PERSISTENT.

When the PBE process started verification of pbe state failed.

Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: NO Successfully opened 
pre-existing sqlite pbe file /home/sirisha/immsv/immpbe/imm.db.2010f
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: IN saImmRepositoryInit: 
SA_IMM_KEEP_REPOSITORY - attaching to repository
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: ER Expected 1 row got 0 rows 
(line: 1161)
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: WA Verify class 
testMA_verifyObjCompCallbackNode_101_133 failed!
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: NO Renamed 
/home/sirisha/immsv/immpbe/imm.db.2010f to 
/home/sirisha/immsv/immpbe/imm.db.2010f.failed_immdump because it has been 
detected to be corrupt.
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: NO Removed obsolete journal file: 
/home/sirisha/immsv/immpbe/imm.db.2010f-journal
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: WA verifyPbeState failed!
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: WA Pbe: Failed to re-attach to db 
file /home/sirisha/immsv/immpbe/imm.db.2010f - regenerating db file
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: IN Generating DB file from 
current IMM state. DB file: /home/sirisha/immsv/immpbe/imm.db.2010f

Syslog and IMMND traces on both the controllers is attached. there might be a 
few seconds time difference between the two slots.



Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to 
https://sourceforge.net/p/opensaf/tickets/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.



---

** [tickets:#1092] 2PBE: pbed exits with error 'cannot rollback - no 
transaction is active'**

**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Tue Sep 16, 2014 07:12 AM UTC by Sirisha Alla
**Last Updated:** Tue Sep 16, 2014 07:12 AM UTC
**Owner:** nobody

The issue is seen on SLES X86 VMs running with opensaf changeset 5697+#946 
patches. IMM DB is loaded with 50k objects.

IMM Applications along with switchover is in progress.

Following is observed in the syslog of SC-1:

Sep 16 11:07:27 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE time-out in waiting 
on porepare for PRTA update ccb:101c4 
dn:safNode=PL-3,safCluster=myClmCluster
Sep 16 11:07:28 SLES-64BIT-SLOT1 osafimmpbed: ER SQL statement ('ROLLBACK') 
failed because:  cannot rollback - no transaction is active
Sep 16 11:07:28 SLES-64BIT-SLOT1 osafimmpbed: ER Exiting (line:2843)

An application class is created just before the PBE process started.

Sep 16 11:07:32 SLES-64BIT-SLOT1 osafimmnd[2384]: NO Create of class 
testMA_verifyObjCompCallbackNode_101_133 is PERSISTENT.

When the PBE process started verification of pbe state failed.

Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: NO Successfully opened 
pre-existing sqlite pbe file /home/sirisha/immsv/immpbe/imm.db.2010f
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: IN saImmRepositoryInit: 
SA_IMM_KEEP_REPOSITORY - attaching to repository
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: ER Expected 1 row got 0 rows 
(line: 1161)
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: WA Verify class 

[tickets] [opensaf:tickets] #1087 imm: assign instead of compare in immnd_evt_proc_rt_object_delete

2014-09-16 Thread Anders Bjornerstedt
- **status**: accepted -- review



---

** [tickets:#1087] imm: assign instead of compare in 
immnd_evt_proc_rt_object_delete**

**Status:** review
**Milestone:** 4.3.3
**Created:** Mon Sep 15, 2014 02:25 PM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 16, 2014 07:00 AM UTC
**Owner:** Anders Bjornerstedt

In IF statement in immnd_evt_proc_rt_object_delete, there is assigning of value 
instead of comparing. 
There should be (err == SA_AIS_OK)

if(spApplConn  (err = SA_AIS_OK)  !delayedReply) {




---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1053 IMM; saImmOmAdminOwnerClear should only be allowed for root users

2014-09-16 Thread Anders Bjornerstedt
Will push this tomorrow if there are no objections.



---

** [tickets:#1053] IMM; saImmOmAdminOwnerClear should only be allowed for root 
users**

**Status:** review
**Milestone:** 4.5.0
**Created:** Tue Sep 09, 2014 09:00 AM UTC by Anders Bjornerstedt
**Last Updated:** Thu Sep 11, 2014 09:50 AM UTC
**Owner:** Anders Bjornerstedt

OpenSAF 4.5 introduced support for access control in the IMM (enhancement #938).

The om API downcall 'saImmOmAdminOwnerClear(...)' is very special in that 
it forces the removal of adminownership set up by any other user.

Because of the very special and powerful nature of this primitive, only
root users should be allowed to access it, when acces control is 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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1092 2PBE: pbed exits with error 'cannot rollback - no transaction is active'

2014-09-16 Thread Anders Bjornerstedt
- **status**: unassigned -- assigned
- **assigned_to**: Anders Bjornerstedt
- **Milestone**: 4.3.3 -- 4.4.1



---

** [tickets:#1092] 2PBE: pbed exits with error 'cannot rollback - no 
transaction is active'**

**Status:** assigned
**Milestone:** 4.4.1
**Created:** Tue Sep 16, 2014 07:12 AM UTC by Sirisha Alla
**Last Updated:** Tue Sep 16, 2014 07:12 AM UTC
**Owner:** Anders Bjornerstedt

The issue is seen on SLES X86 VMs running with opensaf changeset 5697+#946 
patches. IMM DB is loaded with 50k objects.

IMM Applications along with switchover is in progress.

Following is observed in the syslog of SC-1:

Sep 16 11:07:27 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE time-out in waiting 
on porepare for PRTA update ccb:101c4 
dn:safNode=PL-3,safCluster=myClmCluster
Sep 16 11:07:28 SLES-64BIT-SLOT1 osafimmpbed: ER SQL statement ('ROLLBACK') 
failed because:  cannot rollback - no transaction is active
Sep 16 11:07:28 SLES-64BIT-SLOT1 osafimmpbed: ER Exiting (line:2843)

An application class is created just before the PBE process started.

Sep 16 11:07:32 SLES-64BIT-SLOT1 osafimmnd[2384]: NO Create of class 
testMA_verifyObjCompCallbackNode_101_133 is PERSISTENT.

When the PBE process started verification of pbe state failed.

Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: NO Successfully opened 
pre-existing sqlite pbe file /home/sirisha/immsv/immpbe/imm.db.2010f
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: IN saImmRepositoryInit: 
SA_IMM_KEEP_REPOSITORY - attaching to repository
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: ER Expected 1 row got 0 rows 
(line: 1161)
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: WA Verify class 
testMA_verifyObjCompCallbackNode_101_133 failed!
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: NO Renamed 
/home/sirisha/immsv/immpbe/imm.db.2010f to 
/home/sirisha/immsv/immpbe/imm.db.2010f.failed_immdump because it has been 
detected to be corrupt.
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: NO Removed obsolete journal file: 
/home/sirisha/immsv/immpbe/imm.db.2010f-journal
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: WA verifyPbeState failed!
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: WA Pbe: Failed to re-attach to db 
file /home/sirisha/immsv/immpbe/imm.db.2010f - regenerating db file
Sep 16 11:07:33 SLES-64BIT-SLOT1 osafimmpbed: IN Generating DB file from 
current IMM state. DB file: /home/sirisha/immsv/immpbe/imm.db.2010f

Syslog and IMMND traces on both the controllers is attached. there might be a 
few seconds time difference between the two slots.


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1088 IMM: immnd may crash if client node is NULL in immnd_evt_proc_fevs_forward

2014-09-16 Thread Anders Bjornerstedt
- **status**: assigned -- accepted



---

** [tickets:#1088] IMM: immnd may crash if client node is NULL in 
immnd_evt_proc_fevs_forward**

**Status:** accepted
**Milestone:** 4.3.3
**Created:** Mon Sep 15, 2014 02:38 PM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 16, 2014 06:58 AM UTC
**Owner:** Anders Bjornerstedt

immnd may crash if client node is NULL in immnd_evt_proc_fevs_forward.

Next IF statement need a check before !(cl_node-mIsSync) that cl_node is not 
NULL

} else if((evt-info.fevsReq.sender_count == 0x1)  
!(cl_node-mIsSync) 
(immModel_immNotWritable(cb) ||  (cb-mSyncFinalizing 
 cb-fevs_out_count))) {


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1088 IMM: immnd may crash if client node is NULL in immnd_evt_proc_fevs_forward

2014-09-16 Thread Anders Bjornerstedt
- **status**: accepted -- review



---

** [tickets:#1088] IMM: immnd may crash if client node is NULL in 
immnd_evt_proc_fevs_forward**

**Status:** review
**Milestone:** 4.3.3
**Created:** Mon Sep 15, 2014 02:38 PM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 16, 2014 07:29 AM UTC
**Owner:** Anders Bjornerstedt

immnd may crash if client node is NULL in immnd_evt_proc_fevs_forward.

Next IF statement need a check before !(cl_node-mIsSync) that cl_node is not 
NULL

} else if((evt-info.fevsReq.sender_count == 0x1)  
!(cl_node-mIsSync) 
(immModel_immNotWritable(cb) ||  (cb-mSyncFinalizing 
 cb-fevs_out_count))) {


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1083 imm: ccbCreate - default values for PRTA's do not reach PBE or special applier

2014-09-16 Thread Anders Bjornerstedt
- **assigned_to**: Zoran Milinkovic -- Anders Bjornerstedt



---

** [tickets:#1083] imm: ccbCreate - default values for PRTA's do not reach PBE 
or special applier**

**Status:** assigned
**Milestone:** 4.3.3
**Created:** Mon Sep 15, 2014 01:29 PM UTC by Zoran Milinkovic
**Last Updated:** Mon Sep 15, 2014 03:28 PM UTC
**Owner:** Anders Bjornerstedt

Runtime attributes (persistent or not) that are

  - part of a config object.
  - have a default value.
  - have not been explicitly assigned a value

Will not get the default value written to PBE or included in special applier
callback.

The problem is in the calculation in IF statement, which is always true if 
attr-flags contains SA_IMM_ATTR_RUNTIME flag.

if((attr-mFlags  SA_IMM_ATTR_RUNTIME)  
  ~(attr-mFlags  SA_IMM_ATTR_PERSISTENT) 
  ~(attr-mFlags  SA_IMM_ATTR_NOTIFY)) {

Sign ~ should be replaced with !.


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1083 imm: ccbCreate - default values for PRTA's do not reach PBE or special applier

2014-09-16 Thread Anders Bjornerstedt
- **status**: assigned -- accepted



---

** [tickets:#1083] imm: ccbCreate - default values for PRTA's do not reach PBE 
or special applier**

**Status:** accepted
**Milestone:** 4.3.3
**Created:** Mon Sep 15, 2014 01:29 PM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 16, 2014 07:48 AM UTC
**Owner:** Anders Bjornerstedt

Runtime attributes (persistent or not) that are

  - part of a config object.
  - have a default value.
  - have not been explicitly assigned a value

Will not get the default value written to PBE or included in special applier
callback.

The problem is in the calculation in IF statement, which is always true if 
attr-flags contains SA_IMM_ATTR_RUNTIME flag.

if((attr-mFlags  SA_IMM_ATTR_RUNTIME)  
  ~(attr-mFlags  SA_IMM_ATTR_PERSISTENT) 
  ~(attr-mFlags  SA_IMM_ATTR_NOTIFY)) {

Sign ~ should be replaced with !.


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1082 imm: check the adminowner of same name exists before creating

2014-09-16 Thread Anders Bjornerstedt
- **status**: unassigned -- invalid
- **Comment**:

Closing this ticket since I dont understand what the problem is.

Separate clients that set admin-owner to the same admin-owner-name must have
their own admin-owner-struct in the IMMND because each admin-owner could have
release-on-finalize set ot true. On finalize or detach, the relase of
admin owner must only be done for objects where that client did set
admin-owner.




---

** [tickets:#1082] imm: check the adminowner of same name exists before 
creating**

**Status:** invalid
**Milestone:** 4.5.0
**Created:** Mon Sep 15, 2014 12:20 PM UTC by Neelakanta Reddy
**Last Updated:** Mon Sep 15, 2014 12:20 PM UTC
**Owner:** nobody

1. without enabling PBE the number of adminowners are:

immadm -O displayverbose -p resource:SA_STRING_T:adminowners 
opensafImm=opensafImm,safApp=safImmService
[using admin-owner: 'safImmService']
Object: opensafImm=opensafImm,safApp=safImmService
Name   Type Value(s)

safImmService  SA_INT64_T   131343 (0x2010f)

2. with enabling of PBE the no of adminowners are :
immcfg -m -a saImmRepositoryInit=1 safRdn=immManagement,safApp=safImmService

 immadm -O displayverbose -p resource:SA_STRING_T:adminowners 
opensafImm=opensafImm,safApp=safImmService
[using admin-owner: 'safImmService']
Object: opensafImm=opensafImm,safApp=safImmService
Name   Type Value(s)

safImmService  SA_INT64_T   131343 (0x2010f)
safImmService  SA_INT64_T   131343 (0x2010f)

while creating the new adminowner, check for existing adminowner if already 
present and assign it, instead of creating a new adminowner.



---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1093 Trailing slash can be ignored when checking for PBE directory name

2014-09-16 Thread Sirisha Alla



---

** [tickets:#1093] Trailing slash can be ignored when checking for PBE 
directory name**

**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Tue Sep 16, 2014 09:15 AM UTC by Sirisha Alla
**Last Updated:** Tue Sep 16, 2014 09:15 AM UTC
**Owner:** nobody

Sep 16 14:33:14 SLES-64BIT-SLOT2 osafimmd[6455]: NO Extended intro from node 
2010f
Sep 16 14:33:14 SLES-64BIT-SLOT2 osafimmd[6455]: WA Unacceptable difference in 
PBE directory name on shared fs between nodes: 
(/home/sirisha/immsv/immpbe/)!=(/home/sirisha/immsv/immpbe) - rejecting node 
2010f.
Sep 16 14:33:14 SLES-64BIT-SLOT2 osafimmd[6455]: WA Error returned from 
processing message err:2 msg-type:2
Sep 16 14:33:14 SLES-64BIT-SLOT2 osafimmnd[6465]: NO Global discard node 
received for nodeId:2010f pid:3585
Sep 16 14:33:29 SLES-64BIT-SLOT2 osafimmd[6455]: NO New IMMND process is on 
STANDBY Controller at 2010f
Sep 16 14:33:29 SLES-64BIT-SLOT2 osafimmd[6455]: NO Extended intro from node 
2010f
Sep 16 14:33:29 SLES-64BIT-SLOT2 osafimmd[6455]: WA Unacceptable difference in 
PBE directory name on shared fs between nodes: 
(/home/sirisha/immsv/immpbe/)!=(/home/sirisha/immsv/immpbe) - rejecting node 
2010f.
Sep 16 14:33:29 SLES-64BIT-SLOT2 osafimmd[6455]: WA Error returned from 
processing message err:2 msg-type:2
Sep 16 14:33:29 SLES-64BIT-SLOT2 osafimmnd[6465]: NO Global discard node 
received for nodeId:2010f pid:3608
Sep 16 14:33:44 SLES-64BIT-SLOT2 osafimmd[6455]: NO New IMMND process is on 
STANDBY Controller at 2010f
Sep 16 14:33:44 SLES-64BIT-SLOT2 osafimmd[6455]: NO Extended intro from node 
2010f
Sep 16 14:33:44 SLES-64BIT-SLOT2 osafimmd[6455]: WA Unacceptable difference in 
PBE directory name on shared fs between nodes: 
(/home/sirisha/immsv/immpbe/)!=(/home/sirisha/immsv/immpbe) - rejecting node 
2010f.

The node is not joining because of a trailing slash character which can be 
ignored.


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1082 imm: add more dipaly information to verbose output for ResourceDisplay

2014-09-16 Thread Neelakanta Reddy
- **summary**: imm: check the adminowner of same name exists before creating 
-- imm:  add more dipaly information to verbose output for ResourceDisplay 
- **status**: invalid -- assigned
- **assigned_to**: Neelakanta Reddy
- **Type**: defect -- enhancement
- **Milestone**: 4.5.0 -- 4.6.FC
- **Comment**:

From IMMND perspective IMMND has different admin-owner-struct, 

Additional display information must be added when displayverbose Operationname 
is used for ResourceDisplay.







---

** [tickets:#1082] imm:  add more dipaly information to verbose output for 
ResourceDisplay **

**Status:** assigned
**Milestone:** 4.6.FC
**Created:** Mon Sep 15, 2014 12:20 PM UTC by Neelakanta Reddy
**Last Updated:** Tue Sep 16, 2014 08:00 AM UTC
**Owner:** Neelakanta Reddy

1. without enabling PBE the number of adminowners are:

immadm -O displayverbose -p resource:SA_STRING_T:adminowners 
opensafImm=opensafImm,safApp=safImmService
[using admin-owner: 'safImmService']
Object: opensafImm=opensafImm,safApp=safImmService
Name   Type Value(s)

safImmService  SA_INT64_T   131343 (0x2010f)

2. with enabling of PBE the no of adminowners are :
immcfg -m -a saImmRepositoryInit=1 safRdn=immManagement,safApp=safImmService

 immadm -O displayverbose -p resource:SA_STRING_T:adminowners 
opensafImm=opensafImm,safApp=safImmService
[using admin-owner: 'safImmService']
Object: opensafImm=opensafImm,safApp=safImmService
Name   Type Value(s)

safImmService  SA_INT64_T   131343 (0x2010f)
safImmService  SA_INT64_T   131343 (0x2010f)

while creating the new adminowner, check for existing adminowner if already 
present and assign it, instead of creating a new adminowner.



---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #936 IMM: OiImplementer set api call for 2nd time should return ERR_EXIST

2014-09-16 Thread Neelakanta Reddy
- **status**: unassigned -- accepted
- **Part**: - -- doc
- **Milestone**: future -- 4.5.0
- **Comment**:

will update the IMMSV PR, accordingly



---

** [tickets:#936] IMM: OiImplementer set api call for 2nd time should return 
ERR_EXIST**

**Status:** accepted
**Milestone:** 4.5.0
**Created:** Thu Jun 05, 2014 11:57 AM UTC by surender khetavath
**Last Updated:** Tue Sep 16, 2014 06:52 AM UTC
**Owner:** Neelakanta Reddy

changeset : 5270.

The imm api call saImmOiImplementerSet() for 2nd time with same OI name is 
returning ERR_INVALID_PARAM. Instead it should return ERR_EXIST

spec definition:

SA_AIS_ERR_EXIST - An object implementer with the same name is already regis-
tered with the IMM Service or an object implementer name is already set for the 
han-
dle immOiHandle.

Also, there is no ERR_INVALID_PARAM return code defined in spec for this api.

Agent traces:
Jun  5 17:04:11.486724 imma [28790:imma_oi_api.c:0326]  saImmOiInitialize_2
Jun  5 17:04:11.495662 imma [28790:imma_oi_api.c:1174] NO ERR_INVALID_PARAM: 
Implementer OiImplementerSet_twice already set for this handle when trying to 
set OiImplementerSet_twice



---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #940 smfd: faulted due to csiSetcallbackTimeout

2014-09-16 Thread Ingvar Bergström
- **status**: review -- fixed
- **Comment**:

changeset:   5803:9142e2bc4962
branch:  opensaf-4.3.x
parent:  5795:b00af2767ed1
user:Ingvar Bergstrom ingvar.bergst...@ericsson.com
date:Tue Sep 16 12:27:14 2014 +0200
summary: smfd: better handling of admin op SI_SWAP return codes [#940]

changeset:   5804:72af05ed049d
branch:  opensaf-4.4.x
parent:  5796:b3eddcdcf961
user:Ingvar Bergstrom ingvar.bergst...@ericsson.com
date:Tue Sep 16 12:31:27 2014 +0200
summary: smfd: better handling of admin op SI_SWAP return codes [#940]

changeset:   5805:4a03c6f0c812
branch:  opensaf-4.5.x
parent:  5802:a6676bbc4d6f
user:Ingvar Bergstrom ingvar.bergst...@ericsson.com
date:Tue Sep 16 12:34:37 2014 +0200
summary: smfd: better handling of admin op SI_SWAP return codes [#940]

changeset:   5806:db0158925f33
tag: tip
parent:  5800:c697de1a1e8d
user:Ingvar Bergstrom ingvar.bergst...@ericsson.com
date:Tue Sep 16 12:34:37 2014 +0200
summary: smfd: better handling of admin op SI_SWAP return codes [#940]




---

** [tickets:#940] smfd: faulted due to csiSetcallbackTimeout **

**Status:** fixed
**Milestone:** 4.3.3
**Created:** Wed Jun 11, 2014 05:13 AM UTC by Ingvar Bergström
**Last Updated:** Tue Sep 09, 2014 05:16 AM UTC
**Owner:** Ingvar Bergström

smfd behaves faulty in QUIESCED state. May hang in saLogInitialize call. 


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #966 osaf: Global constant name 'kMaxDnLength' lacks prefix

2014-09-16 Thread Anders Widell
- **status**: accepted -- review



---

** [tickets:#966] osaf: Global constant name 'kMaxDnLength' lacks prefix**

**Status:** review
**Milestone:** 4.5.0
**Created:** Thu Jul 24, 2014 11:12 AM UTC by Anders Bjornerstedt
**Last Updated:** Mon Sep 15, 2014 01:16 PM UTC
**Owner:** Anders Widell

Ticket #191 added support for extended names (long DNs) to opensaf.
A new sanity limit is till defined by the global constant kMaxDnLength.
But that constant lacks any prefix and so does not make it clear where
it belongs (what component owns it) and could potentially cause naming 
conflicts in the future. 




---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1094 imm: missing NULL check in imma_xx_resurrect

2014-09-16 Thread Zoran Milinkovic



---

** [tickets:#1094] imm: missing NULL check in imma_xx_resurrect**

**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Tue Sep 16, 2014 01:02 PM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 16, 2014 01:02 PM UTC
**Owner:** nobody

In imma_om_resurrect and imma_oi_resurrect, imma_client_node_get may set 
cl_node to NULL, and later usage of cl_node may cause uncertain behavior.

imma_om_resurrect:

 imma_client_node_get(cb-client_tree, immHandle, cl_node);
 if (cl_node  cl_node-isOm)
 {
 cl_node-stale = true;
 cl_node-exposed = true;
 } else {
 TRACE_3(client_node_get failed);
 }
 timeout = cl_node-syncr_timeout;

imma_oi_resurrect:

 imma_client_node_get(cb-client_tree, immOiHandle, cl_node);
 if (cl_node  !cl_node-isOm) {
 cl_node-stale = true;
 cl_node-exposed = true;
 } else {
 TRACE_3(client_node_get failed);
 }
 
 timeout = cl_node-syncr_timeout;


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1095 imm: imm can crash in saImmOiAugmentCcbInitialize

2014-09-16 Thread Zoran Milinkovic



---

** [tickets:#1095] imm: imm can crash in saImmOiAugmentCcbInitialize**

**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Tue Sep 16, 2014 01:26 PM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 16, 2014 01:26 PM UTC
**Owner:** nobody

In saImmOiAugmentCcbInitialize, if immsv_om_handle_initialize returns non 
SA_AIS_OK, then rc value is converted in SA_AIS_ERR_TRY_AGAIN (cl_node == 
NULL)
In done: block, the call of imma_oi_ccb_record_augment may crash the library, 
accessing fields in cl_node struct, which is NULL


cl_node = NULL; /* avoid unsafe use */

if(immsv_om_handle_initialize) {/*This is always the first 
immsv_om_ call */
rc = immsv_om_handle_initialize(privateOmHandle, 
version);
} else {
TRACE(ERR_LIBRARY: Error in library linkage. 
libSaImmOm.so is not linked);
rc = SA_AIS_ERR_LIBRARY;
}

if(rc != SA_AIS_OK) {
TRACE(ERR_TRY_AGAIN: failed to obtain internal om 
handle rc:%u, rc);
rc = SA_AIS_ERR_TRY_AGAIN;
goto done;
}

.

done:

if (locked) {
m_NCS_UNLOCK(cb-cb_lock, NCS_LOCK_WRITE);
}

if(rc == SA_AIS_OK || rc == SA_AIS_ERR_TRY_AGAIN) {
/* mark oi_ccb_record with privateOmHandle to avoid repeated 
open/close
   of private-om-handle for each try again or each ccb op. The 
handle
   is closed when the ccb is terminated (apply-uc or abort-uc).
 */
imma_oi_ccb_record_augment(cl_node, ccbId, privateOmHandle, 
privateAoHandle);

.


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1097 imm: using invalid iterator in migrateObj

2014-09-16 Thread Zoran Milinkovic



---

** [tickets:#1097] imm: using invalid iterator in migrateObj**

**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Tue Sep 16, 2014 02:24 PM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 16, 2014 02:24 PM UTC
**Owner:** nobody

Schema change from single value to multi value attribute, iterator is 
incorrectly used.

/* Adjust existing attributes.*/
ImmAttrValueMap::iterator oavi; 
for(oavi = object-mAttrValueMap.begin(); 
   oavi != object-mAttrValueMap.end(); ++oavi) {
/*
   TRACE_5(CHECKING existing attribute %s:%s for object %s,
   className.c_str(), oavi-first.c_str(), objectDn.c_str());
*/

/* Change from single to multi-value requires change of value rep.*/
ai = changedAttrs.find(oavi-first);
if(ai != changedAttrs.end()) {
if((ai-second-mFlags  SA_IMM_ATTR_MULTI_VALUE) 
(!oavi-second-isMultiValued())) {
attrValue = new ImmAttrMultiValue(*(oavi-second));
TRACE_5(Schema change adjusted attribute %s in object:%s 
to be multivalued, oavi-first.c_str(), objectDn.c_str());
delete oavi-second;
object-mAttrValueMap.erase(oavi);
object-mAttrValueMap[ai-first] = attrValue;
}
}

/* Correct object-mAdminOwnerAttrVal. */
if(oavi-first == std::string(SA_IMM_ATTR_ADMIN_OWNER_NAME)) {
object-mAdminOwnerAttrVal = oavi-second;
TRACE_5(Schema change corrected attr %s in object:%s,
oavi-first.c_str(), objectDn.c_str());
}
}


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1053 IMM; saImmOmAdminOwnerClear should only be allowed for root users

2014-09-16 Thread Anders Bjornerstedt
- **status**: review -- fixed
- **Comment**:

changeset:   5808:ed440c34833e
tag: tip
parent:  5806:db0158925f33
user:Anders Bjornerstedt anders.bjornerst...@ericsson.com
date:Thu Sep 11 11:30:35 2014 +0200
summary: IMM: saImmOmAdminOwnerClear should only be allowed for root users 
[#1053]

changeset:   5807:c419c2e8dca4
branch:  opensaf-4.5.x
parent:  5805:4a03c6f0c812
user:Anders Bjornerstedt anders.bjornerst...@ericsson.com
date:Thu Sep 11 11:30:35 2014 +0200
summary: IMM: saImmOmAdminOwnerClear should only be allowed for root users 
[#1053]




---

** [tickets:#1053] IMM; saImmOmAdminOwnerClear should only be allowed for root 
users**

**Status:** fixed
**Milestone:** 4.5.0
**Created:** Tue Sep 09, 2014 09:00 AM UTC by Anders Bjornerstedt
**Last Updated:** Tue Sep 16, 2014 07:25 AM UTC
**Owner:** Anders Bjornerstedt

OpenSAF 4.5 introduced support for access control in the IMM (enhancement #938).

The om API downcall 'saImmOmAdminOwnerClear(...)' is very special in that 
it forces the removal of adminownership set up by any other user.

Because of the very special and powerful nature of this primitive, only
root users should be allowed to access it, when acces control is 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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1087 imm: assign instead of compare in immnd_evt_proc_rt_object_delete

2014-09-16 Thread Anders Bjornerstedt
- **status**: review -- fixed
- **Comment**:

changeset:   5812:c19301358ebc
tag: tip
parent:  5808:ed440c34833e
user:Anders Bjornerstedt anders.bjornerst...@ericsson.com
date:Tue Sep 16 09:10:30 2014 +0200
summary: imm: Compare err instead of assign in 
immnd_evt_proc_rt_object_delete [#1087]

changeset:   5811:735f05180fd0
branch:  opensaf-4.4.x
parent:  5804:72af05ed049d
user:Anders Bjornerstedt anders.bjornerst...@ericsson.com
date:Tue Sep 16 09:10:30 2014 +0200
summary: imm: Compare err instead of assign in 
immnd_evt_proc_rt_object_delete [#1087]

changeset:   5810:e43ec6b9e758
branch:  opensaf-4.3.x
parent:  5803:9142e2bc4962
user:Anders Bjornerstedt anders.bjornerst...@ericsson.com
date:Tue Sep 16 09:10:30 2014 +0200
summary: imm: Compare err instead of assign in 
immnd_evt_proc_rt_object_delete [#1087]

changeset:   5809:56393a02a852
branch:  opensaf-4.5.x
parent:  5807:c419c2e8dca4
user:Anders Bjornerstedt anders.bjornerst...@ericsson.com
date:Tue Sep 16 09:10:30 2014 +0200
summary: imm: Compare err instead of assign in 
immnd_evt_proc_rt_object_delete [#1087]




---

** [tickets:#1087] imm: assign instead of compare in 
immnd_evt_proc_rt_object_delete**

**Status:** fixed
**Milestone:** 4.3.3
**Created:** Mon Sep 15, 2014 02:25 PM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 16, 2014 07:23 AM UTC
**Owner:** Anders Bjornerstedt

In IF statement in immnd_evt_proc_rt_object_delete, there is assigning of value 
instead of comparing. 
There should be (err == SA_AIS_OK)

if(spApplConn  (err = SA_AIS_OK)  !delayedReply) {




---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1088 IMM: immnd may crash if client node is NULL in immnd_evt_proc_fevs_forward

2014-09-16 Thread Anders Bjornerstedt
- **status**: review -- fixed
- **Comment**:

changeset:   5816:2d9a9b89a37e
tag: tip
parent:  5812:c19301358ebc
user:Anders Bjornerstedt anders.bjornerst...@ericsson.com
date:Tue Sep 16 09:41:47 2014 +0200
summary: IMM: Add client node NULL-check in immnd_evt_proc_fevs_forward 
[#1088]

changeset:   5815:a26f26296454
branch:  opensaf-4.5.x
parent:  5809:56393a02a852
user:Anders Bjornerstedt anders.bjornerst...@ericsson.com
date:Tue Sep 16 09:41:47 2014 +0200
summary: IMM: Add client node NULL-check in immnd_evt_proc_fevs_forward 
[#1088]

changeset:   5814:904b98fa3101
branch:  opensaf-4.4.x
parent:  5811:735f05180fd0
user:Anders Bjornerstedt anders.bjornerst...@ericsson.com
date:Tue Sep 16 09:41:47 2014 +0200
summary: IMM: Add client node NULL-check in immnd_evt_proc_fevs_forward 
[#1088]

changeset:   5813:0a124b589f61
branch:  opensaf-4.3.x
parent:  5810:e43ec6b9e758
user:Anders Bjornerstedt anders.bjornerst...@ericsson.com
date:Tue Sep 16 09:41:47 2014 +0200
summary: IMM: Add client node NULL-check in immnd_evt_proc_fevs_forward 
[#1088]




---

** [tickets:#1088] IMM: immnd may crash if client node is NULL in 
immnd_evt_proc_fevs_forward**

**Status:** fixed
**Milestone:** 4.3.3
**Created:** Mon Sep 15, 2014 02:38 PM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 16, 2014 07:46 AM UTC
**Owner:** Anders Bjornerstedt

immnd may crash if client node is NULL in immnd_evt_proc_fevs_forward.

Next IF statement need a check before !(cl_node-mIsSync) that cl_node is not 
NULL

} else if((evt-info.fevsReq.sender_count == 0x1)  
!(cl_node-mIsSync) 
(immModel_immNotWritable(cb) ||  (cb-mSyncFinalizing 
 cb-fevs_out_count))) {


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1098 imm: immnd can crash when object is deleted

2014-09-16 Thread Zoran Milinkovic



---

** [tickets:#1098] imm: immnd can crash when object is deleted**

**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Tue Sep 16, 2014 03:08 PM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 16, 2014 03:08 PM UTC
**Owner:** nobody

objNameArr is uninitialized in both immnd_evt_proc_object_delete and 
immnd_evt_proc_rt_object_delete.

immModel_ccbObjectDelete in immnd_evt_proc_object_delete and 
immModel_rtObjectDelete in immnd_evt_proc_object_delete can set non 0 value to 
arrSize, and objNameArr remains uninitialized.

When memory is freed allocated by immModel_ccbObjectDelete and 
immModel_rtObjectDelete, it also frees uninitialized objNameArr that points to 
random address.


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1099 imm: memory leaks in immload when object and class are created

2014-09-16 Thread Zoran Milinkovic



---

** [tickets:#1099] imm: memory leaks in immload when object and class are 
created**

**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Tue Sep 16, 2014 03:18 PM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 16, 2014 03:18 PM UTC
**Owner:** nobody

In createImmObject, attrValues is not freed if saImmOmCcbObjectCreate_2 fails.

In createImmClass, attrDefinition is not freed if saImmOmClassCreate_2 fails.


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1100 imm: using invalid iterator in ccbAugmentInit

2014-09-16 Thread Zoran Milinkovic



---

** [tickets:#1100] imm: using invalid iterator in ccbAugmentInit**

**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Tue Sep 16, 2014 03:25 PM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 16, 2014 03:25 PM UTC
**Owner:** nobody

When CCB state is IMM_CCB_CREATE_OP, mutation iterator (omuti) can go to the 
end of the mutation tree, and invalidate the iterator.
Later, the iterator (omuti) is used to access member data.

This case is very rare. Check or assert is needed before the access of member 
data.

case IMM_CCB_CREATE_OP:
TRACE(Augment CCB in state CREATE_OP);
for(omuti=ccb-mMutations.begin();omuti != 
ccb-mMutations.end();++omuti) {
if(omuti-second-mContinuationId == rsp-inv) {break;}
} 
obj = omuti-second-mAfterImage;
break;



---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1083 imm: ccbCreate - default values for PRTA's do not reach PBE or special applier

2014-09-16 Thread Anders Bjornerstedt
- **status**: accepted -- review



---

** [tickets:#1083] imm: ccbCreate - default values for PRTA's do not reach PBE 
or special applier**

**Status:** review
**Milestone:** 4.3.3
**Created:** Mon Sep 15, 2014 01:29 PM UTC by Zoran Milinkovic
**Last Updated:** Tue Sep 16, 2014 07:48 AM UTC
**Owner:** Anders Bjornerstedt

Runtime attributes (persistent or not) that are

  - part of a config object.
  - have a default value.
  - have not been explicitly assigned a value

Will not get the default value written to PBE or included in special applier
callback.

The problem is in the calculation in IF statement, which is always true if 
attr-flags contains SA_IMM_ATTR_RUNTIME flag.

if((attr-mFlags  SA_IMM_ATTR_RUNTIME)  
  ~(attr-mFlags  SA_IMM_ATTR_PERSISTENT) 
  ~(attr-mFlags  SA_IMM_ATTR_NOTIFY)) {

Sign ~ should be replaced with !.


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1101 AMF: Dependent SIs are not removed if SU (assigned sponsored SIs) escalated to SuFailover

2014-09-16 Thread Minh Hon Chau
- Description has changed:

Diff:



--- old
+++ new
@@ -4,7 +4,7 @@
- NwayActive: 2SUs (SU4, SU5) with 1 components each, 1SIs (SI2)
 - SI2 depends on SI1A
 - saAmfSUFailover=1 for SU1, SU2, SU3
-- saAmfSGCompRestartMax=2, saAmfSGCompRestartProb=100, 
saAmfSGSuRestartMax=2, saAmfSGSuRestartProb=100 for NpM SG
+- saAmfSGAutoRepair=0, saAmfSGCompRestartMax=2, 
saAmfSGCompRestartProb=100, saAmfSGSuRestartMax=2, 
saAmfSGSuRestartProb=100 for NpM SG
 - saAmfNodeSuFailoverMax=3, saAmfNodeSuFailOverProb=100 for all 
safAmfNode
 
 Test:






---

** [tickets:#1101] AMF: Dependent SIs are not removed if SU (assigned sponsored 
SIs) escalated to SuFailover**

**Status:** assigned
**Milestone:** 4.5.0
**Created:** Wed Sep 17, 2014 01:26 AM UTC by Minh Hon Chau
**Last Updated:** Wed Sep 17, 2014 01:26 AM UTC
**Owner:** Minh Hon Chau

Configuration: 
- 1App, 2SG:
- NpM: 3SUs (SU1, SU2, SU3) with 1 components each, 2SIs (SI1A, SI1B)
- NwayActive: 2SUs (SU4, SU5) with 1 components each, 1SIs (SI2)
- SI2 depends on SI1A
- saAmfSUFailover=1 for SU1, SU2, SU3
- saAmfSGAutoRepair=0, saAmfSGCompRestartMax=2, 
saAmfSGCompRestartProb=100, saAmfSGSuRestartMax=2, 
saAmfSGSuRestartProb=100 for NpM SG
- saAmfNodeSuFailoverMax=3, saAmfNodeSuFailOverProb=100 for all 
safAmfNode

Test:
- unlock-in, unlock all SUs
- All SI assignments
safSISU=safSu=SU2\,safSg=AmfDemo1\,safApp=AmfDemo2,safSi=AmfDemo1A,safApp=AmfDemo2
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
safSISU=safSu=SU1\,safSg=AmfDemo1\,safApp=AmfDemo2,safSi=AmfDemo1B,safApp=AmfDemo2
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
--
safSISU=safSu=SU4\,safSg=AmfDemo2\,safApp=AmfDemo2,safSi=AmfDemo2,safApp=AmfDemo2
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
safSISU=safSu=SU3\,safSg=AmfDemo1\,safApp=AmfDemo2,safSi=AmfDemo1A,safApp=AmfDemo2
saAmfSISUHAState=STANDBY(2)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
safSISU=safSu=SU3\,safSg=AmfDemo1\,safApp=AmfDemo2,safSi=AmfDemo1B,safApp=AmfDemo2
saAmfSISUHAState=STANDBY(2)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
safSISU=safSu=SU5\,safSg=AmfDemo2\,safApp=AmfDemo2,safSi=AmfDemo2,safApp=AmfDemo2
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
- In SC-2, pkill amf_demo untill SuFailover, assignments:
safSISU=safSu=SU1\,safSg=AmfDemo1\,safApp=AmfDemo2,safSi=AmfDemo1B,safApp=AmfDemo2
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
--
safSISU=safSu=SU4\,safSg=AmfDemo2\,safApp=AmfDemo2,safSi=AmfDemo2,safApp=AmfDemo2
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
safSISU=safSu=SU3\,safSg=AmfDemo1\,safApp=AmfDemo2,safSi=AmfDemo1A,safApp=AmfDemo2
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
safSISU=safSu=SU5\,safSg=AmfDemo2\,safApp=AmfDemo2,safSi=AmfDemo2,safApp=AmfDemo2
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
- In PL-3, pkill amf_demo untill SuFailover, assignments:
safSISU=safSu=SU1\,safSg=AmfDemo1\,safApp=AmfDemo2,safSi=AmfDemo1B,safApp=AmfDemo2
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
--
safSISU=safSu=SU4\,safSg=AmfDemo2\,safApp=AmfDemo2,safSi=AmfDemo2,safApp=AmfDemo2
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
safSISU=safSu=SU5\,safSg=AmfDemo2\,safApp=AmfDemo2,safSi=AmfDemo2,safApp=AmfDemo2
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)

safSi=AmfDemo2 should be removed since safSi=AmfDemo1A has been removed
Instead of error escalation, locking SU2, SU3 can get the safSi=AmfDemo2 
removed as expected.


---

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.--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets