In a certain case with NO_DANGLING references between objects, IMM is able to delete object with NO_DANGLING reference from another object.
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:~ #
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)
..........
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:~ #
syslog messages
..........
May 27 04:20:58 SC-1 osafimmnd[4671]: NO Ccb 73 COMMITTED (immcfg_SC-1_14511)
..........
Tickets: #1377
Tickets: #1474
Wiki: ChangeLog-4.5.2
Wiki: ChangeLog-4.6.1
Hung's analysis:
When committing a ccb, immnd loops through mutation list of that ccb and commit them one by one.
If the creation is committed before the modification, IMM_CREATE_LOCK flag will be cleared and no dangling reference is failed to be added to sReverseRefsNoDanglingMMap in addNewNoDanglingRefs().
Notice that items in mMutations are always sorted by object DN so the order of mutations to be committed depends on the object DNs.
That's why the problem only occurs in Case 2.
Raised to critical because this ticket means there could be systems out there
that have a corrupt imm database due to this problem.
Besides fixing the bug that this ticket reports we also needs some form
of audit that users could use to check for infection by the problem and
some means to correct it.
An audit is preferable to implement in immdump/pbe for several reasons.
It can be run off-line and it catches problems caused by either imm-ram
or imm-pbe. There exists an enhancement ticket for this #19.
Enhancement of course means it will be available as such in the next release.
But again by encapsulating it in the immdump/pbe tool such a tool could be
applied on files generated from older releases.
Diff:
opensaf-4.5.x:
changeset: 6611:06291c4d1256
branch: opensaf-4.5.x
parent: 6608:ad98ab30bcbc
user: Hung Nguyen hung.d.nguyen@dektech.com.au
date: Fri Jun 05 11:14:41 2015 +0700
summary: imm: Check no-dangling map before adding new references when committing modify-op [#1377]
opensaf-4.6.x:
changeset: 6612:e2272fa55f67
branch: opensaf-4.6.x
parent: 6609:ca5bd5669669
user: Hung Nguyen hung.d.nguyen@dektech.com.au
date: Fri Jun 05 11:14:41 2015 +0700
summary: imm: Check no-dangling map before adding new references when committing modify-op [#1377]
default(4.7):
changeset: 6613:7950e6a79c6f
tag: tip
parent: 6610:adcc7260c7ae
user: Hung Nguyen hung.d.nguyen@dektech.com.au
date: Fri Jun 05 11:14:41 2015 +0700
summary: imm: Check no-dangling map before adding new references when committing modify-op [#1377]
Related
Tickets:
#1377