Ok.
Will add information about A.2.13 being needed for use of NO_DANGLING.
And push this.
Zoran is just about ready to send out the patch for #50 (search API for
NO_DANGLING) for review.
http://sourceforge.net/p/opensaf/tickets/50/
In will send out an update for README.NO_DANGLING to be part of that review.
/AndersBj
Neelakanta Reddy wrote:
> Hi AndersBj,
>
> Reviewed the patch.
> Ack with minor commnet.
>
> comment:
>
> supporting imm version must be included in the readme for No_DANGLING.
>
> /Neel.
> On Monday 02 December 2013 09:11 PM, Anders Bjornerstedt wrote:
>> osaf/services/saf/immsv/README | 14 +++-
>> osaf/services/saf/immsv/README.2PBE | 20 +++--
>> osaf/services/saf/immsv/README.NO_DANGLING | 113
>> +++++++++++++++++++++++++++++
>> 3 files changed, 137 insertions(+), 10 deletions(-)
>>
>>
>> Also updated README.2PBE with a pointer to always at least provide
>> the imm.xml
>> file at both SCs, when initial start is to be be performed for a 2PBE
>> cluster.
>>
>> diff --git a/osaf/services/saf/immsv/README
>> b/osaf/services/saf/immsv/README
>> --- a/osaf/services/saf/immsv/README
>> +++ b/osaf/services/saf/immsv/README
>> @@ -1606,12 +1606,22 @@ Bit 4 controls 2PBE oneSAfe2PBE (see 2PB
>> 2PBE Allow IMM PBE to be configured without shared file system (4.4)
>> ===================================================================
>> -https://sourceforge.net/p/opensaf/tickets/21/
>> +http://sourceforge.net/p/opensaf/tickets/21/
>> The 2PBE enhancement allows the IMM to have PBE configred so that it
>> does not rely on a shared filesystem, such as DRBD.
>> -See: osaf/services/saf/immsv/README.2PBE.
>> +See: osaf/services/saf/immsv/README.2PBE for details.
>> +
>> +
>> +Support for reference integrity checking - SA_IMM_ATTR_NO_DANGLING
>> (4.4)
>> +========================================================================
>>
>> +http://sourceforge.net/p/opensaf/tickets/49/
>> +
>> +A new attribute definition flag has been defined:
>> +#define SA_IMM_ATTR_NO_DANGLING 0x0000000004000000
>> +
>> +See: osaf/services/saf/immsv/README.NO_DANGLING for details.
>> ----------------------------------------
>> DEPENDENCIES
>> diff --git a/osaf/services/saf/immsv/README.2PBE
>> b/osaf/services/saf/immsv/README.2PBE
>> --- a/osaf/services/saf/immsv/README.2PBE
>> +++ b/osaf/services/saf/immsv/README.2PBE
>> @@ -66,7 +66,16 @@ Cluster-start & IMM loading from PBE-fil
>> The active IMMD will order each SC resident IMMND to execute a
>> "preload", probing
>> the SC local filesystem for the file state that *would* be loaded
>> to the cluster
>> if that SC IMMND was chosen as coord. The two SC IMMNDs send the
>> preload stats to
>> -the active IMMD.
>> +the active IMMD. On each SC, the file probe starts by attempting to
>> open the
>> +database file with the 2PBE suffix (e.g. imm.db.2010f at SC1 and
>> imm.db.2020f at
>> +SC2). If the file with suffix does not exist (can not be opened),
>> then a new probe
>> +is tried using the database file without suffix (e.g imm.db at both
>> SC1 and SC2).
>> +If that probe also fails, then the last alternative is to try to
>> open the
>> +IMMSV_LOAD_FILE (e.g. imm.xml).
>> +
>> +When initial starting a 2PBE system, take care so that at least the
>> imm.xml file
>> +exists at both SCs. Otherwise there is a risk that the preloading
>> will hang for
>> +quite some time, when the IMMND restarts at an SC.
>> The active IMMD will wait for the IMMNDs at *both* SCs to
>> complete the preload
>> task and then determine which SC has the apparently latest file
>> state. The IMMND
>> @@ -135,20 +144,15 @@ has synced (regenerated its file) and re
>> The 1safe2PBE state is entered by the administrative opeation:
>> - immadm -o 1 -a safImmService -p
>> opensafImmNostdFlags:SA_UINT32_T:8 \
>> + immadm -o 1 -p opensafImmNostdFlags:SA_UINT32_T:8 \
>> opensafImm=opensafImm,safApp=safImmService
>> It is exited either automatically by a rejoined SC or by an
>> explicit administrative
>> opertion:
>> - immadm -o 2 -a safImmService -p
>> opensafImmNostdFlags:SA_UINT32_T:8 \
>> + immadm -o 2 -p opensafImmNostdFlags:SA_UINT32_T:8 \
>> opensafImm=opensafImm,safApp=safImmService
>> -Note the explicit setting of admin-owner-name using "-a
>> safImmService". This has to
>> -be used for these admin-operations because the imm service needs
>> admin-ownership
>> -over the object "opensafImm=opensafImm,safApp=safImmService" in
>> order for 2PBE to
>> -work properly.
>> -
>> Hence the fourth bit in the opensafImmNostdFlags bitvector of the
>> OpenSAF service
>> object, is used to toggle on/off oneSafe2PBE. Toggling this bit, on
>> older systems,
>> or systems that do not have 2PBE configured, will have no effect.
>> Toggling this bit
>> diff --git a/osaf/services/saf/immsv/README.NO_DANGLING
>> b/osaf/services/saf/immsv/README.NO_DANGLING
>> new file mode 100644
>> --- /dev/null
>> +++ b/osaf/services/saf/immsv/README.NO_DANGLING
>> @@ -0,0 +1,113 @@
>> +Support for reference integrity checking - SA_IMM_ATTR_NO_DANGLING
>> (4.4)
>> +========================================================================
>>
>> +http://sourceforge.net/p/opensaf/tickets/49/
>> +
>> +A new attribute definition flag has been defined:
>> +#define SA_IMM_ATTR_NO_DANGLING 0x0000000004000000
>> +
>> +This flag can only be set for attribute definitions where the
>> attribute data
>> +type is SaNameT and the attribute is a CONFIG attribute.
>> +
>> +The SaNameT type signifies that the value is a reference to an IMM
>> object,
>> +i.e. the value is a DN. The IMM spec does not define any general
>> consistency
>> +constraints for such references. In particular, the value may be a
>> DN for a
>> +non existing object.
>> +
>> +The new attribute definition flag SA_IMM_ATTR_NO_DANGLING added with
>> this
>> +enhacement, makes it possible for the imm service to monitor and
>> maintain
>> +referential integrity. That is, the imm service can releive the OI
>> from the
>> +burden of having to validate the existence of the object that the
>> reference
>> +points to.
>> +
>> +The IMM service will thus guarantee that the value(s) of an
>> attribute with the
>> +SA_IMM_ATTR_NO_DANGLING flag, when set, contains the distinguished
>> name(s) of
>> +an existing IMM object(s). IMM will reject attempts to set it to
>> anything that
>> +is not the distinguished name of an existing object, and it will reject
>> +attempts to delete objects that are referenced by such an attribute.
>> This
>> +validation is performed when the CCB is applied, which means that it
>> will take
>> +into account all changes performed within the CCB.
>> +
>> +The NO_DANGLING flag is not allowed to be set for RUNTIME attributes,
>> +(persistent or not). The reason is that runtime attribues and
>> runtime objects
>> +are not changed using CCBs/transactions and so it is impossible for
>> the IMM
>> +service to maintain inter-object consistency constraints for references
>> +emanating from runtime data.
>> +
>> +However, a NO_DANGLING flagged config attribute may refer *to* a
>> PERSISTENT
>> +runtime object (PRTO). This will prevent such a PRTO from being
>> deleted untill
>> +all such NO_DANGLING config attribute references to that object have
>> been
>> +removed. PRTOs are deleted either by the saImmOiRtObjectDelete
>> operation or
>> +indirectly by a cascading saImmOmCcbObjectDelete as part of a CCB.
>> +
>> +The validation of NO_DANGLING constraints is done as part of the
>> apply of
>> +a CCB. The IMM service does such validation before any completed
>> callbacks are
>> +sent to any OIs involved in the CCB. If the validation fails, no
>> completed and
>> +of course no apply callback will be generated towards OIs. Instead
>> an abort
>> +callback is generated to all OIs.
>> +
>> +Association objects (object that have a DN composed of the parent DN
>> and an RDN
>> +value that is the DN of an associated object) can mark the
>> RDN_ATTRIBUTE as also
>> +being NO_DANGLING. This means that the IMM will maintain the
>> referential
>> +integrity towards the associated object. Note that implicit referential
>> +integrity from child to parent in the IMM naming tree has always
>> been maintained
>> +by the IMM.
>> +
>> +The IMM will also perform interference checking in the operational
>> phase of
>> +a CCB. A failed interference check will typically only reject that
>> latest
>> +operation, without aborting the CCB. Interference checks are mainly for
>> +regulationg concurrency conflicts between CCBs, but also catch
>> blatant errors
>> +that are local to the operation. The rejection of such a bad
>> operation is done
>> +before any OIs receive the operation callback. If an interference
>> check fails
>> +then no OI will get that operation callback. This is important
>> because there is
>> +no "undo" callback for indiviudal operations. To undo any operation
>> towards an
>> +OI can only be done by aborting the entire CCB.
>> +
>> +Here is a summary of the interference/operation checks performed in
>> relaion
>> +to NO_DANGLING. Again note these are performed before the validation
>> done as
>> +part of ccbApply.
>> +
>> +- CCB Object Create:
>> +
>> +o If the created object has a NO_DANGLING reference to a
>> non-persistent
>> + runtime object, return BAD_OPERATION.
>> +
>> +o If the created object has a NO_DANGLING reference to an object
>> deleted
>> + within the same CCB, return BAD_OPERATION.
>> +
>> +o If the created object has a NO_DANGLING reference to an object
>> that is
>> + flagged for delete by another CCB, return BUSY.
>> +
>> +o If the created object has a NO_DANGLING reference to an object
>> that is
>> + flagged for creation by another CCB, return BUSY.
>> +
>> +- CCB Object Modify (Add or Replace attribute value):
>> +
>> +o If an updated attribute value has a NO_DANGLING reference to a
>> + non-persistent runtime object, return BAD_OPERATION.
>> +
>> +o If an updated attribute value has a NO_DANGLING reference to an
>> object that
>> + is deleted within the same CCB, return BAD_OPERATION.
>> +
>> +o If an updated attribute value has a NO_DANGLING reference to an
>> object that
>> + is flagged for deletion by another CCB, return BUSY.
>> +
>> +o If an updated attribute value has a NO_DANGLING reference to an
>> object that
>> + is flagged for creation by another CCB, return BUSY.
>> +
>> +- CCB Object Delete:
>> +
>> +o If an object is flagged for deletion or creation by another CCB
>> with a
>> + NO_DANGLING reference to the object that will be deleted, then
>> return BUSY.
>> +
>> +o If an object is flagged for creation by the same CCB, and has a
>> NO_DANGLING
>> + reference to the object proposed for delete, then return
>> BAD_OPERATION.
>> +
>> +- Deleting persistent runtime object:
>> +
>> +o Check if there is a NO_DANGLING reference to the PRTO, if there
>> is the
>> + delete operation returns BAD_OPERATION.
>> +
>> +
>> +
>> +
>> +
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
