-----Original Message-----
From: Anders Björnerstedt
Sent: den 23 januari 2014 18:29
To: 'Neelakanta Reddy'; [email protected]
Subject: RE: [devel] Fwd: Review Request for IMMsv PR document update [# 718]
Hi Neel, here are my review comments.
-----------------------
Section 2.1
Needs to be refreshed to say that "Present OpenSAF4.4 supports A.02.13 API".
(The actual header for the A.02.13 API may be found in
osaf/libs/saf/include/saImmOm_A_2_13.h)
Hmm actually there is a documentation "bug" in both saImmOm_A_2_13.h and
saImmOm_A_2_12.h Where some comments say "Not yet supported" for things that
are precisely supported i.e.
Introduced in tht release. Strange that I missed that. It should say "Supported
in OpenSAF 4.3"
or "Supported in OpenSAF 4.4".
---------------------------------------------------------------------------------------------
Section 2.2.5 Compliance Report.
We could remove any table entry that says "YES", since the while table is in
The previous paragraph said to be a list of Exceptions to compliance ..!
-------------------------------------------------------------------------------------------
Section 2.2.6.1 needs to docuemtn bit 3 (OpensAF 4.3) and bit 4 (OpenSAF 4.4).
The third order bit, if set, allows allows immsv internal protocol
optimizations implemented in OpenSAF 4.3, to be used.
This bit is on by default so any 4.3 system that cluster (re) starts will get
this bit set. But a system being upgraded from 4.2 to 4.3 will not have this
bit set. This is as it should be during the upgrade. Once the upgrade to 4.3
has been completed successfully, the bit should be toggled on by the upgrade
campaign. This is achieved by invoking an admin operation on the opensaf
object:
immadm -o 1 -p opensafImmNostdFlags:SA_UINT32_T:3 \
opensafImm=opensafImm,safApp=safImmService
The fourth order bit, if set, turns on oneSafe2PBE. The effect is that a system
configured for 2PBE will allow persistent writes even if only one SC is
available. This should only be a temporary state, typically used if A 2PBE
system needs to repair one SC. See the 2PBE documentation for details.
--------------------------------------------
Section 2.2.6.4
In the list some elements could be expressed mpre clearly:
a) Support for search with configuration attributes.
Should say:
a) Support for search fetching only configuration attributes.
-----
c) Support for atribute definitions with no duplicates.
Should say:
c) Support for attribute definitions allowing no duplicates.
-----
h) IMMNDs subscribe as normal mode towards IMMD
Should say:
h) IMMNDs subscribe using MDS normal mode towards IMMD.
------------------------------------------------------------------------------
Section 2.2.6.5 OpenSAF 4.4 Features
The initial sentence should follow the same pattern as for 4.3 features and
mention the A.02.13 API version.
Also in the list:
b) Support for reference integrity checking.
Shoukld be:
b) Support for reference integrity checking, i.e. NO_DANGLING attributes.
----
c) Support search for objects having NO_DANGLING refrence.
Should be:
c) Support search for objects having NO_DANGLING attribute containing a
particular DN/reference.
--------------------------------------------------------------------
Section 2.2.7
Point 1): ....NO_DUPLICATES flag is added to remove the duplicates...
Should say: ...NO_DUPLICATES flag is added to disallow duplicates in a
multivalued attribute....
-------
Point 9): Every object which was created before saImmOmSearchInitialize_2 and
matches the search criteria,
will be returned exactly once by saImmOmSearchNext_2. If the object
is modified or deleted or
created after saImmOmSearchInitialize_2 will not be returned by
search iterator.
Should say: Every object which existed when saImmOmSearchInitialize_2 is
processed at the local IMMND and
matches the search criteria, will be returned exactly once by
saImmOmSearchNext_2. Any change
(modify, delete or create) arriving after saImmOmSearchInitialize_2
will not be reflected by
the earch iterator. Thus a saImmOmSearchInitialize takes a CCB
consistent snapshot of the
desired data as it is at the FEVS point when processed by the
IMMND. FEVS == Fake EVS.
--------------------------------------------------------------------
Section 3.1 Mentions only 4.2 extensions. Should say 4.2 and later .. Or
something to that effect.
-------------------------------------------------------
Section 3.2.1
Examples for immdump shoulkd add a blank between switch and argument for:
# immdump -pbe/tmp/imm.db
To be:
# immdump -pbe /tmp/imm.db
----------------------------------------------------------------------------
3.2.4
Says: ".... immcfg without arguments, immcfg starts in explicit commit mode
where is possible to perform more IMM operations
within one CCB. In explicit commit mode, immcfg accepts immcfg commands from
stdin, pipe or a file. Immcfg command has the
same syntax as immcfg in the command line.
Should say: "immcfg without arguments, immcfg starts in explicit commit mode
where it is possible to perform several IMM operations
within one CCB. In explicit commit mode, immcfg accepts commands from stdin,
pipe or a file. Immcfg in explicit commit
mode has the same syntax as immcfg arguments.
-------------------------------------------------------------------------------
Possibly extend the example for explicit commit mode a few object operations.
Question: Is it possible to apply a CCB without exiting immcfg, i.e. To just
continue To create the next CCB (could use the sasme ccb-handle internally).
-----------------------------------------------------
1.SAI-AIS-IMM-A.02.01 does not specify the return values for invoking multiple
Ccb operations on the same Object and the same CcbId. The OpenSAF
implementation returns:
---------------------------
3.4
Point 5 on the list (ccb-id is not visible to the om-user):
Says: SAI-AIS-IMM-A.02.01 does not specify the return values for invoking
multiple Ccb operations on the same Object and the same CcbId.
The OpenSAF implementation returns:
Should say: SAI-AIS-IMM-A.02.01 does not specify the return values for invoking
multiple operations on the same Object in the same CCB.
The OpenSAF implementation returns (assuming no other problem
dominated):......
Point 8 has unclear language and some redundant sentences:
Says: If the timeout is less than the Minimum SAF Accepted timeout(100ms) then
the default 10 seconds is timeout is considered for admin operations. If the
timeout is zero then the default IMMSV timeout (10 seconds)is considered .
During failover/switchover, there will transiently be no OI attached for
objects/classes. When an OI detaches the imm server will note the time. If a
request arrives in the server sufficiently close in time to the detachment, the
server shall reply with TRY_AGAIN instead of ERR_NOT_EXISTS. Sufficiently close
in time, the timeout is 6 seconds.
Should say: If the timeout is less than the minimum SAF Accepted timeout(100ms)
then the default 10 seconds is used for admin operations.
During failover/switchover, there MAY transiently be no OI attached for
objects/classes. When an OI detaches the imm server will note the time.
If a request arrives in the server within 6 seconds to the detachment, the
server will reply with TRY_AGAIN instead of ERR_NOT_EXISTS.
---------------------------------
Section 3.5.3.1 Multiple Appliers
I would like to add this paragraph concerning the completed callback for
appliers.
The completed callback really has no meaning for the applier interface.
For regular Ois, the completed callback has the purpose of allowing the OI to
validate The changes it received for the CCB. But appliers have no validation
rights. Any error code Returned by an applier from a completed callback is
discarded by the imm service. Note also That the immsv does not wait for such
replies, which means that the CCB is usually already applied in the imm ram
database by the time an applier gets the completed callback. But The CCB may
also not have been applied when the applier gets the completed callback.
Thus anm applier should not yse the completed callback as a trigger to read
from the immsv unless it is prepared to see the version of object before the
ccb was applier OR a version after the apply of the CCB.
---------------------------
Section 3.5.4 Support for search with configuration attributes.
Title should be: Support for search returning only config attributes.
-------------------------------------------
Section 3.5.5
Entire text seems to be underlined.
The text seems identical to that of the README (which is OK and good since it
simplifies The text maintenance) and so I have no read it carefully.
-----------------------
Section 3.7.2
The new 2PBE IMMD configuration variable seems to be missing a description here.
/AndersBj
-----Original Message-----
From: Neelakanta Reddy [mailto:[email protected]]
Sent: den 23 januari 2014 14:20
To: [email protected]
Subject: [devel] Fwd: Review Request for IMMsv PR document update [# 718]
Hi AndersBj/ zoran,
Attaching the IMMsv PR document for review.
/Neel
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
