[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openais
Subject:    [Openais] RE: [Saftest-devel] SAFtest 0.2 run against openais
From:       Steven Dake <sdake () mvista ! com>
Date:       2004-12-14 20:29:06
Message-ID: 1103056146.26439.54.camel () persist ! az ! mvista ! com
[Download RAW message or body]

Jun

Two comments below:

On Mon, 2004-12-13 at 20:08, Mi, Jun wrote:
> Hi, Steven
> 	Sorry for later reply. I am so busy these days.
> 	Thank you for your effort. I am so glad to know you are using
> saftest project cases.
> Comments below:
> 
> Thanks,
> -Jun
> 
> -----Original Message-----
> From: saftest-devel-admin@lists.sourceforge.net
> [mailto:saftest-devel-admin@lists.sourceforge.net] On Behalf Of Steven
> Dake
> Sent: Tuesday, November 30, 2004 7:23 AM
> To: saftest-devel@lists.sourceforge.net;
> saftest-ais-devel@lists.sourceforge.net; openais@lists.osdl.org
> Subject: [Saftest-devel] SAFtest 0.2 run against openais
> 
> Folks,
> 
> I have run the saf test suite 0.2 against openais.  I have found several
> defects in the test suites, including some that were reported with
> saftest 0.1.  I have to run the test suites manually now because of the
> blocking bugs in Dispatch.  I have attached a few patches to fix up bugs
> in the test cases.  The rest require a little more thought that I leave
> to the designers of the test cases.
> 
> [Mi, Jun]
> 
> saClmDispatch:1
> No mechanism for dispatch routine to execute any callbacks, hence
> it will block forever.  This test case needs some mechanism to cause a
> callback to execute, until which it is invalid.
> 
> [Mi, Jun] Now I add one mechanism to cause a callback.
> 	But for this case, I think if there is no any mechanism,
> dispatch will do nothing. It should not be blocked there. As my
> understanding to this spec, when we set the dispatch flag to
> SA_DISPATCH_ONE, if there is blocking thing, dispatch will execute one.
> But if there is no any blocking thing, dispatch will do nothing. What do
> you think about it?
> 

The specification says:
"Invoke a single pending callback in the context of the calling thread
and then return from the dispatch".

This means (to me) if there are no callbacks waiting, wait to dispatch a
callback.  If there is a callback waiting for dispatch, dispatch one and
only one callback.

But then I went to look at the B.01.01 specification which states:
"Invoke a single pending callback, if there is a pending callback, in
the context of the calling thread and then return from the dispatch"

So I think from the spirit of the spec authors the saftest view of the
specification is correct.

openais does not comply with the specs.

> saClmDispatch:3
> No thread ever executes saClmFinalize, so dispatch blocking doesn't
> exit.  A seperate thread, timer, or signal must be created which calls
> saAmfFinalize which will trigger the dispatch routine to unblock.  Until
> This occurs, the test is invalid.
> 
> [Mi, Jun]
> 	You are right. Now the test case fits to this case. Could you
> test it again?
> 
> saClmSelectionObjectGet:3
> The if statement is invalid, a patch is attached.
> 
> [Mi, Jun]
> 	You are so careful. It is my fault. Thank you.
> 
> saClmClusterNodeGet:2
> saClmClusterNodeGet:3
> These tests are invalid.  It is perfectly valid to return the cluster
> node name even if a saClmInitialize has never occured.  It is invalid to
> expect that saClmInitialize must have to be called before
> saClmClusterNodeGet can operate.  If an implementation behaves in this
> way, it is broken.  Notice there is no handle passed into these apis,
> for that very reason.
> 
> [Mi, Jun] 
> 	There is no handle passed into this api. But the spec says that 
> "SA_ERR_INIT - The function saClmInitialize() has not been called yet or
> the function saClmFinalize() has been called already." in page 148. So
> it is necessary for us to give these two test cases. 
> 

This was an errata in the AIS A.01.01 specifications and fixed in
B.01.01.  It was caused by overzealous cut and paste.  When there is
clearly an error, the saftest project should defer towards what makes
the most sense given future events (like this problem being fixed in a
later spec).

I'd suggest removing this test from the tests.

> saClmClusterNodeGetAsync:4
> I'm not sure what the invalid parameter is in this test case.  Async
> calls should almost always return SA_OK.  The only thing I could think
> it is is the node id (where 100 is not a valid node id).  But in this
> case, clusternodegetasync would have to block, which means this can't be
> the invalid parameter that is being tested for.  Could more detail be
> described?
> 
> [Mi, Jun]
> 	Yes. The nodeid is valid. But the spec doesn't make it clear. So
> I think I can remove this test case.
> 
> saClmClusterNodeGetCallbackT:1
> The test will block forever given the AIS A specifications.  The correct
> thing to do is to exit the select loop once the async dispatch has
> occured.  A patch is attached to do 
> 
> [Mi, Jun]
> 	Thank you for your patch. I have checked it into CVS.
> 
> saClmClusterTrackCallbackT:1,2,3
> These test cases need to be rethought a little bit.  First, no error is
> printed when the callback is not called..  but I'd expect some sort of
> error.  Sleeping for 1 second may not be sufficient to generate a
> configuration change to cause the membership to change with
> TRACK_CHANGES_ONLY.  TRACK_CHANGES and TRACK_CURRENT are not set at the
> same time in a test case which is valid.
> 
> [Mi, Jun]
> 	saClmClusterTrackCallbackT:1
> 		The test case now can let user to change the membership.
> 
> 	saClmClusterTrackCallbackT:2
> 	saClmClusterTrackCallbackT:3
> 		Rewrite the test cases. You can run it again.
> 
> TrackStart:7
> openais is not compliant with the specifications.
> 
> TrackStart:8
> openais is not compliant with the specifications.
> 
> Trackstart:9
> The specification clearly states it is possible to use SA_TRACK_CURRENT
> | SA_TRACK_CHANGES_ONLY in the same invocation.  So the test is
> invalid.  Perhaps what is meant is SA_TRACK_CHANGES |
> SA_TRACK_CHANGES_ONLY which is invalid.  Also in this test case,
> numberOfItems is not set to a valid value and will be uninitialized.
> 
> [Mi, Jun]
> 	You are right. It is fixed now.
> 
> Trackstart:10
> openais is not compliant with the specifications.
> 
> TrackStop:4
> openais is not compliant with the specifications.
> 
> TrackStop:5
> openais is not compliant with the specifications.
> 
> Regards
> -steve



_______________________________________________
Openais mailing list
Openais@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/openais


[prev in list] [next in list] [prev in thread] [next in thread]