#543 IMM: Incomplete PBE persistence for SaImmAttrImplementerName in config objects

[Anders Bjornerstedt]

Each IMM object has three system define attributes:

SaImmAttrClassName
SaImmAttrAdminOwnerName
SaImmAttrImplementerName

The IMM A.02.01 spec defines these attributes as being configuration attributes
in configuration objects and runtime attributes in runtime objects. In reality
they behave more like runtime attributes in both configuration and runtime
objects. But these system attributes differ from normal runtime attributes in
that they are not owned/maintained by the OI for the object, but by the IMM
service itself.When part of runtime objects, the spec says that they should
be persistent if the runtime object is persistent, otherwise not.

The current OpenSaf implementation deviates from the spec in some subtle ways
on the persistence properties of these attributes. This has to do with
the practical use of these attributes. [The A.03.01 spec also changes the set
of system attributes and alters the properties of of existing ones in a
way that is not backwards compatible, particularly so when they are persistent.]

First and simplest, the SaImmAttrClassName attribute is in practice a static
class attribute. It never changes value for any object. Whether or not it is
stored persistently per object is academic since its value can be
always be derived from what class an object belongs to and that never changes.
It is not a problem.

Second, the SaImmAttrAdminOwnerName attribute is "lazy persistent" towards the
file representation. That is, the value for this attribute will tag along with
any regular persistent update made to the object. Thus the value for admin-owner
visible to anyone observing the file state, will reflect the admin-owner-name
that was valid at the last persistified update of that object.
But the admin owner name is not persistified directly as a side effect of an
admin-owner set or release operation. The admin-owner name is also discarded at
cluster loading. It is then replaced by the special admin owner "IMMLOADER".
So this attribute is not full cycle persistent. The only reason it is lazy
persistified to the file system is for debugging purposes. It may be useful
to see which admin-owner was last involved in creating or updating a persistent
object. Because its value is discarded at loading, this attribute can not cause
any problems. The discarding of admin-owner at loading I see as a feature since
it removes any orphaned admin-owners and clears the way for a fresh start.
Ths IMMLOADER admin owner is special in that it can be overriden by any regular
admin-owner set. A configuration object implementer can use the admin-owner name
to detect if it is reading the initial configuration after a cluster start or
if an Om-user has altered the configuration after the last cluster start.

Finally, the SaImmAttrImplementerName is also lazy persistified. The value is
stored along with the object whenever the object is written for other reasons.
It is not written as a side effect of saImmOiClassImplementerSet/Release or
saImmOiObjectImplementeSet/Release. But this attribute is not discarded at
cluster loading. The full cycle persistency is necessary for persistent runtime
objects. The only OI allowed to access (or delete) a persistent runtime object
is an OI with the same implementer-name as the one that created it.
Thus any loss of the implementer-name for PRTOs after a cluster restart
would cause orphaned PRTOs. And cluster restart is the only use-case where
persistency of PRTOs comes into effect. As usual PRTOs are a pain in the X
and that is true here also. The original idea was also that recovering
implementer-name would also improve the efficiency of for the normal case
for config objects after a cluster restart, where the same implementer-name
is set again for the objects. Typically for all objects of a class.

In practice, this performance boost and idempotency supporting "feature" for
SaImmAttrImplementerName does not work well. To begin with it only works for
supporting the idempotency of saImmOiObjectImplementerSet, which is a rarely
used operation. It does not work for the normally used saImmOiClassImplementerSet
because the association between implementer-name and class is lost. Only the
association between implementer-name and object is persistent. To have the
implementer-name association with class be persistence would require a change
of representation of the export format for imm-classes.

But a potentially more serious problem exists for config objects if/when the
operations of saImmOiClassImplementerRelease or saImmOiObjectImplementerRelease
are used. The operations remove the implementer-name association from the
class (and all instances) or one instance (only allowed when it was set per
instance). Fortunately these operations are virtually never used since no
sensible application wants to change the implementer-name used. The only
legitimate use of these operations would be in conjunction with some upgrade
where the design of OIs has been altered in some way that forces a name change
for some OI.

Ironically, the typical use of these release operations is a benign application
mistake where the OI developer mistakenly thinks they must release the
implemener-name at say failover. But the only thing needed for failover (or swithc of implementorship for an implementer-name to another process) is
to do saImmOiImplementerClear which severs the mapping between oi-handle
and implementer-name instead of the mapping beween class/object and
implementer-name.

The potential problem with the lazy persistence of SaImmAttrImplementerName
arises for the extremely rare case of a legitimate change of implementer-name.
Thus the application would invoke saImmOiClassImplementerRelese to drop
the binding between some class and some implementer-name. Then immediately
after that invoke saImmOiClassImplementerSet, creating a binding from the class
(and all instances) to a new different name.
Efter this sequence has been executed. The persistent state for the
implementer-.name in the file system (PBE) will have diverged from the
state in imm ram. Should there now be a cluster restart, soon enough after
this so that the PBE file has not been regenerated. Then there is a risk that
the cluste rcomes up with the lates state, except that implementer-name
has been refverted to the older implementer-name.

This is a reare case (change of implementer-name) on top of a reare case
(cluster start soon after) but it can happen.

The proposed fix is to drop the implementer-name for config objects at
cluster loading. In fact implementer-name should only be full cycle
persistent for PRTOs. There it is both necessary (to avoid PRTO
orphans aka persistent garbage) and not a problem because PRTOs never
change implementer name.

[Neelakanta Reddy]

changeset: 5156:d895936fa842
tag: tip
parent: 5153:6cacbb91f268
user: Neelakanta Reddyreddy.neelakanta@oracle.com
date: Wed Apr 16 11:39:01 2014 +0530
summary: IMM:Removed Implementer name for config objects while loading [#543]

changeset: 5155:ae755a63097c
branch: opensaf-4.4.x
parent: 5146:cf14e876e1fe
user: Neelakanta Reddyreddy.neelakanta@oracle.com
date: Wed Apr 16 11:39:01 2014 +0530
summary: IMM:Removed Implementer name for config objects while loading [#543]

changeset: 5154:3e0116caaba9
branch: opensaf-4.3.x
parent: 5143:c00ffe89b23f
user: Neelakanta Reddyreddy.neelakanta@oracle.com
date: Wed Apr 16 11:39:01 2014 +0530
summary: IMM:Removed Implementer name for config objects while loading [#543]