perfsonar development work

[Jason Zurawski <>]

VV;

(Replying to you and Stijn in one swipe...)

> > > I'll be able to put the info on the Wiki only later today when I get
> > > back to work, so let me explain the most important things shortly in
> > > advance:
> > >
> > > 1) The self-test request is pretty much straightforward, so I guess no
> > > additional comments are necessary at the moment. Let me know if this
> > > is not the case, please.
> > >       
> > Will there be additional eventTypes besides the 'selftest' base uri or
> > did you envision there really only being one?  I think that subdividing
> > the uri by service type or individual services (e.g.
> > http://schemas.perfsonar.net/tools/admin/selftest/ma/snmp/database/1.0)
> > allows for more extension and clearly separates the tests from each other.
> >
> >     
>
> That's true. However, I'd like to have some kind of generic way to request for 
> selftests, at least in the beginning. 
> 1. It's more flexible
> 2. It's easier to implement
> 3. There is no problem in extending this to have specific requests for certain 
> tests later.
>
> At the moment, service developers have to define what kind of tests they are 
> going to implement, which will maybe lead to a more or less complex set of 
> possbile tests. You might not want to run each test in the same interval, so 
> setting up reqeusts for such tests can be challenging, depending on the 
> strategy the service desk is going to use.
>
> So, we definitely need a more distinct way of requesting tests. But if we 
> start to sort this out now, we will not get it done until Berlin.
>
> So, I would suggest to start with the generic approach, Luchesar already 
> worked out, and then extend it later. 
>
> Let's go foward step by step. All we have to do now is ensuring that the 
> generic approach allows for easy extension for specific requests. Which, I 
> think, is absolutely no problem.
>
> Let me know, if you see a problem there.
>   


I am not advocating an exhaustive listing of every possible test or a 
definition of numerous URIs immediately; this would be very imprudent.  
Having a generic 'service test' is fine by me, but it needs to be 
structured in such a way that it:

 a) remains consistent with the rest of the framework
 b) allows for extension

I think Luchesar is on the right track, but my primary concern remains 
that there is not a clear way to identify the results of this 
potentially multi-part test through datum elements alone.  Although it 
may be possible to parse the datum elements returned in the response 
looking for "COMPONENT: Description" patterns, this is not very clean 
and could be prone to errors.  Here is something else that accomplishes 
almost the same goal (although I am still interested in seeing 'single' 
tests instead of some sort of 'bundle'):

The Request:

<nmwg:message xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"; 
type="EchoRequest">
 <nmwg:metadata id="m1">
   
<nmwg:nmwg:eventType>http://schemas.perfsonar.net/tools/admin/selftest/1.0</nmwg:eventType>
 </nmwg:metadata>

 <nmwg:data id="d1" metadatIdRef="m1" />
</nmwg:message>

And the Response:

<nmwg:message xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"; 
type="EchoResponse">
 <nmwg:metadata id="r-m1" metadataIdRef="m1">
   
<nmwg:nmwg:eventType>http://schemas.perfsonar.net/tools/admin/selftest/1.0</nmwg:eventType>
 </nmwg:metadata>

 <nmwg:data id="r-d1" metadatIdRef="r-m1">

    <!-- the original eventType was really just a symbolic name of 2 
sub tests.  The service plans
           to report the status of each instead of using just a 
nmwgr:datum because of this
           reason -->

   <nmwg:metadata id="test1">
     <nmwg:nmwg:eventType>
       
http://schemas.perfsonar.net/tools/admin/selftest/SERVICE_TYPE/SERVICE_NAME/TEST_NAME/success/1.0
     </nmwg:eventType>
   </nmwg:metadata>
   <nmwg:data id="result1" metadatIdRef="test1">   
     <nmwgr:datum xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/";>
       Hopefully some useful message...
     </nmwgr:datum>
   <nmwg:data> 

   <nmwg:metadata id="test2">
     <nmwg:nmwg:eventType>
       
http://schemas.perfsonar.net/tools/admin/selftest/SERVICE_TYPE/SERVICE_NAME/TEST_NAME/failure/1.0
     </nmwg:eventType>
   </nmwg:metadata>
   <nmwg:data id="result2" metadatIdRef="test2">   
     <nmwgr:datum xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/";>
       Hopefully some useful message...
     </nmwgr:datum>
   <nmwg:data> 

 <nmwg:data> 
</nmwg:message>


This basically unbundles the potentially many tests that the service 
designers could potentially structure (in any order and amount they 
choose) in their version of the generic test.  It also ensures that the 
results are easily tracked and categorized on return instead of relying 
on something unstructured like the mux of datum elements.

And now for Stijn:

> > This becomes complex only because there is not a clear way to tell 
> > which test triggered which resulting event.  If the self test 
> > includes 5 tests (if somewhere it was defined that 5 things such as 
> > the configuration file, database, connectivity, logging, and file 
> > permissions should be tested as this one eventType) there is not a 
> > clear way to tell which datum belongs to which subtest.  It is also a 
> > mystery to the initiator of the test that there would be 5 subtests 
> > in the first place (unless they happened to have the documentation 
> > handy).
> >
> > If the separation was as so for a request:
> >
> > <metadata id="m1">
> >  <eventType>.../admin/selftest/ma/snmp/test1</eventType>
> > </metadata>
> >
> > <metadata id="m2">
> >  <eventType>.../admin/selftest/ma/snmp/test2</eventType>
> > </metadata>
> >
> > <data id="d1" metadataIdRef="m1" />
> >
> > <data id="d2" metadataIdRef="m2" />
>
> While this seems like a good idea, it isn't really helpful for the 
> SSHTELNET MP in my opinion. The tests done for the MP are the following:
>
> 1) check if eXist works (i.e. get metadata from it)
>
> 2) from this metadata, try to execute a command on every device
>
> The problem lies within step 2. In order for the service desk to 
> create a valid request following the proposal above, the service desk 
> would need to know the number of devices configured in the MP.
>
> Alternatively, you can group all devices in one metadata block, and 
> call the test "device test" or something, but then I think that's a 
> bit besides the point of having this separation of the tests in the 
> request.
>
> Any other thoughts on this?
>
> I do agree that it is more easy to interpret when all the datum 
> elements in the response belong to a specific part of the metadata, 
> instead of grouping everything together. 

I did not consider the ordering that would be required, and you are 
correct that it compounds the problem.  The above alternate method 
should give you and the other service designers the ability to structure 
the 'generic' test any way you want which does sound appealing.  
Alternatively, we do have the tools to order things via the chaining 
construct:


<metadata id="m1">
<eventType>.../admin/selftest/ma/snmp/test1</eventType>
</metadata>

<metadata id="m2">

 <!-- e.g. make sure the results of 1 go to 2 ... -->

 <subject metadataIdRef="m1" />
<eventType>.../admin/selftest/ma/snmp/test2</eventType>
</metadata>

<data id="d1" metadataIdRef="m1" />

<data id="d2" metadataIdRef="m2" />


Or:


<metadata id="m1">
<eventType>.../admin/selftest/ma/snmp/test1</eventType>
</metadata>

<metadata id="m2" metadataIdRef="m1">

 <!-- I don't need the data, but still run me after 1 -->

<eventType>.../admin/selftest/ma/snmp/test2</eventType>
</metadata>

<data id="d1" metadataIdRef="m1" />

<data id="d2" metadataIdRef="m2" />


Additional thoughts?  Perhaps this can make its way onto the Monday 
Agenda since there was a lack of content.

-jason