[tickets] [opensaf:tickets] #1251 In 2n model, saAmfSGNumPrefInserviceSUs doesn't instantiate SUs as per default value when unset.

2015-06-04 Thread Praveen 
- **status**: accepted -- review
- **Comment**:

Published updated AMF PR doc.



---

** [tickets:#1251] In 2n model, saAmfSGNumPrefInserviceSUs doesn't instantiate 
SUs as per default value when unset.**

**Status:** review
**Milestone:** 4.6.1
**Created:** Mon Feb 09, 2015 10:28 AM UTC by Syed Shareef Ali
**Last Updated:** Tue May 05, 2015 05:38 AM UTC
**Owner:** Praveen

In 2n model, saAmfSGNumPrefInserviceSUs doesn't instantiate SUs as per default 
value when unset.

Steps:-
1. Runtime bring up 2N redundancy model with following configuration.
a)  3SUs in lock-instantiation state  each SU having 3 PI components.Each SUs 
spawned on PL-4.
b)  3SIs in unlocked state  each SI  having 3 CSIs.
c) SG in unlock state, saAmfSGNumPrefInserviceSUs=3 

2. Perform unlock-instantiation and unlock of each SUs.
3. Runtime unset the saAmfSGNumPrefInserviceSUs from 3 to Empty 

It was observed that after step2, all 3SUs got instantiated.
However after step3 also, it was observed that 3 SUS was in instantiated state 
which was wrong because when saAmfSGNumPrefInserviceSUs gets unset, it should 
take default value of saAmfSGNumPrefInserviceSUs which is 2 for 2N model as per 
AMF B4.1 spec page 123.



---

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

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

[tickets] [opensaf:tickets] #1381 imm: no-dangling map is not built up in sync client

2015-06-04 Thread Anders Bjornerstedt 
- **status**: accepted -- review



---

** [tickets:#1381] imm: no-dangling map is not built up in sync client**

**Status:** review
**Milestone:** 4.5.2
**Created:** Wed Jun 03, 2015 08:06 AM UTC by Hung Nguyen
**Last Updated:** Wed Jun 03, 2015 09:34 AM UTC
**Owner:** Anders Bjornerstedt

Turn on SC-1 only and create a simple no-dangling reference
# immcfg -c TestClass testClass=1
# immcfg -c TestClass -a dep=testClass=1 testClass=2

Now turn on SC-2. sReverseRefsNoDanglingMMap of IMMND on SC-2 was empty.

Just turn off SC-1 and testClass=1 can be deleted.


---

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

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

[tickets] [opensaf:tickets] #1382 IMM: Correct syslog severity in ImmModel.cc

2015-06-04 Thread Anders Bjornerstedt 



---

** [tickets:#1382] IMM: Correct syslog severity in ImmModel.cc**

**Status:** accepted
**Milestone:** 4.5.2
**Created:** Thu Jun 04, 2015 04:13 PM UTC by Anders Bjornerstedt
**Last Updated:** Thu Jun 04, 2015 04:13 PM UTC
**Owner:** Anders Bjornerstedt

There are many places in the source file ImmModel.cc where LOG_ERror is used
for user errors such as an attempt to delete an object with a NO_DANGLING 
reference
to it. The general rule is that severity LOG_ER is to be used only for process
errors that are so serious that they are fatal to the process.




---

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

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

[tickets] [opensaf:tickets] #1382 IMM: Correct syslog severity in ImmModel.cc

2015-06-04 Thread Anders Bjornerstedt 
- **status**: accepted -- review



---

** [tickets:#1382] IMM: Correct syslog severity in ImmModel.cc**

**Status:** review
**Milestone:** 4.5.2
**Created:** Thu Jun 04, 2015 04:13 PM UTC by Anders Bjornerstedt
**Last Updated:** Thu Jun 04, 2015 04:13 PM UTC
**Owner:** Anders Bjornerstedt

There are many places in the source file ImmModel.cc where LOG_ERror is used
for user errors such as an attempt to delete an object with a NO_DANGLING 
reference
to it. The general rule is that severity LOG_ER is to be used only for process
errors that are so serious that they are fatal to the process.




---

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

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

[tickets] [opensaf:tickets] #1372 cpsv : adopt leap ncs_os_posix_shm( #1271 ) enhancements to cpsv service

2015-06-04 Thread A V Mahesh (AVM) 
- **status**: review -- fixed
- **Milestone**: 4.6.1 -- 4.5.2
- **Comment**:

hangeset:   6600:bfd18491461b
branch:  opensaf-4.5.x
user:A V Mahesh mahesh.va...@oracle.com
date:Thu Jun 04 14:22:43 2015 +0530
summary: cpsv: enhance cpnd to shm read/write size to SaOffsetT [#1372]

 
changeset:   6602:5920f40601b8
branch:  opensaf-4.6.x
user:A V Mahesh mahesh.va...@oracle.com
date:Thu Jun 04 14:23:41 2015 +0530
summary: cpsv: enhance cpnd to shm read/write size to SaOffsetT [#1372]


changeset:   6604:45b2840aafff
tag: tip
user:A V Mahesh mahesh.va...@oracle.com
date:Thu Jun 04 14:24:22 2015 +0530
summary: cpsv: enhance cpnd to shm read/write size to SaOffsetT [#1372]



 AND =



changeset:   6599:512659e50b5c
branch:  opensaf-4.5.x
parent:  6593:49e69afbd0df
user:A V Mahesh mahesh.va...@oracle.com
date:Thu Jun 04 14:18:37 2015 +0530
summary: leap: enhance posix_shm() to accommodate SaOffsetT [#1271]
 

 
changeset:   6601:d7368041f931
branch:  opensaf-4.6.x
parent:  6594:447615c80905
user:A V Mahesh mahesh.va...@oracle.com
date:Thu Jun 04 14:23:22 2015 +0530
summary: leap: enhance posix_shm() to accommodate SaOffsetT [#1271]


 
changeset:   6603:5133a0a441a6
parent:  6598:ca169b780407
user:A V Mahesh mahesh.va...@oracle.com
date:Thu Jun 04 14:24:05 2015 +0530
summary: leap: enhance posix_shm() to accommodate SaOffsetT [#1271]




---

** [tickets:#1372] cpsv : adopt leap ncs_os_posix_shm( #1271 ) enhancements to 
cpsv service **

**Status:** fixed
**Milestone:** 4.5.2
**Created:** Thu May 14, 2015 04:02 AM UTC by A V Mahesh (AVM)
**Last Updated:** Mon May 18, 2015 03:43 AM UTC
**Owner:** A V Mahesh (AVM)

Currently because of  limitation in Leap ncs_os_posix_shm() function
the maxSectionSize defined in CKPT is of SaUint32T type and the offset 
which
is been derived from +maxSectionSize ,

Now the Ticket #1271 will enhancing leap functionality to accommodate  
SaUint64T  ,
cpsv  should also align to uint64_t type. 


---

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

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

[tickets] [opensaf:tickets] #952 immsv: sync data Mbcsv Check pointing can be optimized

2015-06-04 Thread Neelakanta Reddy 
- **status**: unassigned -- assigned
- **assigned_to**: Neelakanta Reddy
- **Part**: - -- d



---

** [tickets:#952] immsv: sync data Mbcsv Check pointing can be optimized**

**Status:** assigned
**Milestone:** future
**Created:** Tue Jul 08, 2014 03:31 AM UTC by A V Mahesh (AVM)
**Last Updated:** Thu Oct 02, 2014 01:46 PM UTC
**Owner:** Neelakanta Reddy

On 7/7/2014 9:58 AM, A V Mahesh wrote:
While IMMD broadcasting datasync message (IMMND_EVT_D2ND_GLOB_FEVS_REQ_2)
to IMMNDs additionally the same message (including large sync data) getting 
Check pointed to standby director , this means for eachdata`sync FEVS message 
(IMMND_EVT_D2ND_GLOB_FEVS_REQ_2) IMMD is sending two messages one to IMMND's as 
BCAST and one to peer IMMD as R-BCAST (MBCSV).

Currently in my observation if fault happens when sync is in-progress that sync 
gets aborted ,
and the new active is starting a fresh sync. If my understanding is right ,
why we need to Check point IMMND_EVT_D2ND_GLOB_FEVS_REQ_2 message to peer IMMD 
including large sync data?



---

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

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

[tickets] [opensaf:tickets] #1377 imm: IMM deletes object with NO_DANGLING reference

2015-06-04 Thread Anders Bjornerstedt 
- Description has changed:

Diff:



--- old
+++ new
@@ -1,4 +1,4 @@
-In a certain case with bidirectional references between objects, IMM is able 
to delete object with NO_DANGLING reference from another object.
+In a certain case with NO_DANGLING references between objects, IMM is able to 
delete object with NO_DANGLING reference from another object.
 
 - Case 1: IMM worked as expected and rejected the deletion
 






---

** [tickets:#1377] imm: IMM deletes object with NO_DANGLING reference**

**Status:** accepted
**Milestone:** 4.5.2
**Created:** Fri May 29, 2015 08:45 AM UTC by Zoran Milinkovic
**Last Updated:** Wed Jun 03, 2015 12:34 PM UTC
**Owner:** Hung Nguyen

In a certain case with NO_DANGLING references between objects, IMM is able to 
delete object with NO_DANGLING reference from another object.

- Case 1: IMM worked as expected and rejected the deletion

pre
SC-1:~ # immcfg -c TestClass testClassId=1
SC-1:~ # immcfg
 immcfg -c TestClass -a reference=testClassId=1 testClassId=2
 immcfg -a reference=testClassId=2 testClassId=1
(Ctrl+D)
{Note that the above object-create and object-modify have to occur in the same 
CCB. 
 This is to simulate the actions when creating objects with bidirectional 
associations}
SC-1:~ # immcfg -d testClassId=2
error - saImmOmCcbApply FAILED: SA_AIS_ERR_FAILED_OPERATION (21)
SC-1:~ # immcfg -d testClassId=1
error - saImmOmCcbApply FAILED: SA_AIS_ERR_FAILED_OPERATION (21)
SC-1:~ #
/pre

*syslog messages*
..
May 27 04:01:48 SC-1 osafimmnd[4671]: ER ERR_FAILED_OPERATION: Delete of object 
testClassId=2 would violate NO_DANGLING reference from object testClassId=1, 
not scheduled for delete by this Ccb:58
May 27 04:01:48 SC-1 osafimmnd[4671]: NO Ccb 58 ABORTED (immcfg_SC-1_13712)
May 27 04:01:51 SC-1 osafimmnd[4671]: ER ERR_FAILED_OPERATION: Delete of object 
testClassId=1 would violate NO_DANGLING reference from object testClassId=2, 
not scheduled for delete by this Ccb:59
May 27 04:01:51 SC-1 osafimmnd[4671]: NO Ccb 59 ABORTED (immcfg_SC-1_13715)
..

- Case 2: IMM worked unexpectedly and approved the deletion

pre
SC-1:~ # immcfg -c TestClass testClassId=2
SC-1:~ # immcfg
 immcfg -c TestClass -a reference=testClassId=2 testClassId=1
 immcfg -a reference=testClassId=1 testClassId=2
 (Ctrl+D) 
{Note that the above object-create and object-modify have to occur in the same 
CCB. 
 This is to simulate the actions when creating objects with bidirectional 
associations} 
SC-1:~ # immcfg -d testClassId=1
SC-1:~ # immfind | grep testClass
testClassId=2
SC-1:~ #
/pre

*syslog messages*
..
May 27 04:20:58 SC-1 osafimmnd[4671]: NO Ccb 73 COMMITTED (immcfg_SC-1_14511)
..



---

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

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

[tickets] [opensaf:tickets] #19 IMM: PBE should periodically audit the imm.db file

2015-06-04 Thread Zoran Milinkovic 
- **status**: accepted -- review
- **Comment**:

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



---

** [tickets:#19] IMM: PBE should periodically audit the imm.db file**

**Status:** review
**Milestone:** 4.7-Tentative
**Created:** Tue May 07, 2013 08:43 AM UTC by Anders Bjornerstedt
**Last Updated:** Wed Jun 03, 2015 11:58 AM UTC
**Owner:** Zoran Milinkovic

The Imm Persistent Back-End writes transactions/CCBs incrementally
to an slqlite file imm.db. This file resides on a replicated file
system. The replicated file system guards against hardware problems
such as failure of the disk or the host where the disk resides.

But there is always a risk of the imm.db file being corrupted
accidentally. This could be due to bugs in the PBE; or due to
network partitioning of the cluster causing two PBEs to
concurrently write to the same file; or accidents with the
backup and restore framework; or problems with the very complex
communication stack which the shared filesystem is (drbd,
journaling, nfs, sqlite recovery).

The problem is that the imm.db file is a logically a single
point of failure at cluster start.

If the imm.db is corrupted due to whatever reason, then
this may not be discovered until the critical time when it
is needed for a cluster restart.

This enhancement proposes that the PBE shall have some form
of periodic audit of of the existing imm.db file.

One possibility is for the PBE to periodically copy the imm.db
file to a local tmp directory. During the copy the PBE will
buffer  delay the regular user requests (Ccbs  PRTA updates).
As soon as the copy has been made, a pseudo loading will
be invoked using the copy of imm.db. In essence the immloder
is invoked such that it reads the imm.db in exactly the way
it does during loading, but does not try to actually load
anything towards the immsv.

Note that this level of audit will only catch consistency problems
in the PBE/sqlite representation of the imm data.
Loading may fail on higher levels, by failing checks inside
the immsv or applications (failing validation by OIs).

THe point of this is to discover an inconsistency earlier,
when the problem has hopefully not impacted the executing
cluster. IF a problem is detected, then the PBE will restart
and generate a new version of the imm.db file.

Migrated from:
http://devel.opensaf.org/ticket/2451
--


The audit could actually verify snapshot value equality between the sqlite 
representation
in PBE and the in-memory representation in immsv. By initializing an iterator
towards the immsv during the short stop period for mutations enforced during the
file copy, the iterator will take a snapshot of the in-memory representation.

That snapshot should reflect all committed CCbs and PRTA updates. The same 
values
should be commited to the PBE representation.
-
 http://list.opensaf.org/pipermail/devel/2012-February/021139.html
-
The fix for this enhancement should be based on an improvement of 
verifyPbeState(..)
in imm_pbe_dump.cc
That function is executed each time the PBE re-attaches to the imm.db file.
Currently it is very weak. It should ideally verify the state of all persistent
objects both ways. All objects that exist in the imm.db must exist in the imm 
and
have the same state; and all persistent objects that exist in the imm must 
exist in
the imm.db file and have the same state.

This same function could be periodically invoked by the immnd-coord using an 
admin-op
towards the pbe. This should only be done during periods when there is a lull in
persistence traffic. The frequency can be quite low, but could also be increased
in relation to write traffic.

Finally, there is a point in closing and re-opening the imm.db file before 
performing
the verification. This to protect agains accidental removal of the file (inode).
-



---

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

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