Ticket #543 (closed enhancement: fixed)
IMMSv: Persistent repository
| Reported by: | anders | Owned by: | anders |
|---|---|---|---|
| Priority: | major | Milestone: | 4.0.B5 |
| Component: | IMMSv | Version: | |
| Keywords: | Cc: | ||
| patch waiting for maintainer: | no |
Description
The IMM standard specifies that configuration attributes and persistent runtime attributes shall be *persistent* relative to cluster rstarts.
Such persistence shall hold for every committed CCB. This implies that the saImmOmCcbApply call will block and return SA_AIS_OK only when/if persistence for that CCB is secured, by the IMMSv.
The persistence guarantee also applies implicitly for every update of a persistent runtime attribute. This implies that invocations of calls saImmOiRtObjectCreate/Delete/Update will block and return SA_AIS_OK only when/if persistence is secured for that operation, by the IMMSv.
The IMMSv as provided in OpenSAF3.0 does not comply with the persistence requirement. Persistence is only supported in the weaker sense of allowing dumps to the imm.xml format, which may then be used to replace the imm.xml file used at cluster re-start.
The OpenSAF IMM implementation only provides the immdump binary,
which dumps the persistent part of the current IMM contents.
Such dumps must be generated by the user of OpenSAF, when that user
wants to secure persistence in the face of cluster restarts.
Care must also be taken to wrap the use of immdump in such a way that the dump atomically replaces the file used for loading.
Specifically, the user must avoid direct overwrite of the current
imm.xml with the new dump, since a failed dump would result in *no* valid imm.xml fail being available at cluster restart.
It has not yet been decided how far the OpenSAF implementation of IMMSv shall go to provide the support for CCB level persistence.
OpenSAF is used by several users with differing requirements on persistence and differing preferences of what technology to use for the persistence back-end.
Any solution provided as part of OpenSAF should be light-weight (little or no configuration) and low on resource demands.
The solution should probably also be open for "plug in" towards
different persistence back ends as decided by the OpenSAF user.
