perfsonar development work

[Jason Zurawski <>]

Luchesar;

> 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.


> 2) The response is a bit more complex, but still very much like the 
> "echo" one you already know:
>
>     a) the two recognized metadata eventTypes are:
>
>             success.selftest
>         error.selftest
>
>         or, using URI syntax instead:
>
>             http://schemas.perfsonar.net/status/
>                                                 success/echo/1.0
>                                                 error/echo/1.0
>
>         If you have strong preference over one or the other, please 
> let me know. Otherwise, I suggest both to be recognized for reasons of 
> compatibility and consistency with the "echo" eventType messages.


All eventTypes should take the uri format, we should be eliminating 
'success.whatever'.


>     b) the data element should contain at least one datum, which (or 
> its value attribute) should hold:
>
>         - on successful self-test: "Self-test passed successfully."
>
>         - in case of errors one datum should be used per error message.
>
> In the last case, I'd suggest a general format "COMPONENT: 
> Description", e.g. "EXIST-DB: Database "null" does not exist." (erm, 
> honestly, no pun intended ;). The emphasis is on clearly stating which 
> check generated the error -- in the example above, it has been the 
> eXist database. For consistency, the success message could be instead 
> "*: Self-test passed successfully."
>
> There's also an alternative, and please let me know if it feels better 
> to you: both on success and on failure, one datum is returned in the 
> data element for _each_test_ performed. The datum indicates the 
> component tested and the result. E.g.:


This relates to my first question (perhaps its because I am vague on the 
definition of self test) but there could be possibly many components to 
a single test?  I would much rather see a test be singular and separated 
through the metadata and data similar to the format that measurements 
currently use.


> <nmwg:data id="..." metadataIdRef="...">
>     <nmwgr:datum type="errorDescription">
>         EXIST-DB: Database "null" does not exist.
>     </nmwgr:datum>
>     <nmwgr:datum type="successDescription">
>         DEVICE: Router "rt1.lon.uk.geant2.net" contacted successfully.
>     </nmwgr:datum>
>     <nmwgr:datum type="successDescription">
>         DEVICE: Router "rt2.lon.uk.geant2.net" contacted successfully.
>     </nmwgr:datum>
>     <nmwgr:datum type="errorDescription">
>         DEVICE: Connection attempt to "rt3.lon.uk.geant2.net" timed out.
>     </nmwgr:datum>
> </nmwg:data>
>
> You might have also noticed the possibility to use the type attribute, 
> which is allowed there, to facilitate the differentiation between 
> datums indicating errors and datums indicating successfully passed 
> checks.
>
> I guess this variant is more complex to implement, but perhaps would 
> be preferred by the Service Desk. Once again, please let me know what 
> you think.


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" />


The response would be easier to interpret:


<metadata id="r-m1" metadataIdRef="m1">
 <eventType>.../success/...</eventType>
</metadata>

<metadata id="r-m2" metadataIdRef="m1">
 <eventType>.../error/...</eventType>
</metadata>

<data id="d1" metadataIdRef="r-m1">
 <datum>some results here</datum>
</data>

<data id="d2" metadataIdRef="r-m2">
 <datum>some other results here</datum>
</data>

This would lend itself to easier logging (especially in the syslog case: 
the name of the test, the result code, and the result message are all 
easily correlated) and extension to whatever types of tests are required.

-jason


> I'll save the rest for last. Or was it "the best" for last? Hmm, never 
> mind, indeed. If you have objections, or anything else to comment... 
> Well, you know already what to do. ;)
>
> Cheers,
> Luchesar
>
> P.S. There will be examples on the Wiki.
>
> P.P.S. I've unintentionally omitted Jason from the previous mail 
> recipients. Sorry about that.
>
>
> Luchesar V. ILIEV wrote:
> > Hi folks,
> >
> > I've been terribly late with my tasks, and I do owe you _at_least_ a 
> > round of beer. Now, before the number of the necessary "compensatory" 
> > rounds grows to an extent endangering my bank account, let me really 
> > begin doing something about it:
> >
> > http://wiki.perfsonar.net/jra1-wiki/index.php/Main_Page
> > --> Resources
> > --> Service Monitoring
> > --> Service Self-testing
> > --> Invocation/response web messages
> >
> > Direct link:
> > http://wiki.perfsonar.net/jra1-wiki/index.php/Service_Self-testing#Invocation.2Fresponse_web_messages 
> >
> >
> > This is pointer to the specification of the extended EchoRequest / 
> > EchoResponse messages used for invocation of the perfSONAR services 
> > self-tests and reporting the results. At the moment there's only the 
> > RELAX NG schema there, but I will (must) quickly add more information 
> > (this means in the next hours.)
> >
> > I'll keep you updated on the progress. Meanwhile, if you find 
> > anything wrong so far, or have any questions, please do write me.
> >
> > As a side note, you might also notice the attempt to organize the 
> > Wiki information on the service monitoring and have it structured 
> > better (I should have done this long time ago, actually... erm, well, 
> > that's another beer, I guess, for one very patient person, really.) 
> > If you have comments, suggestions, or simply don't like it, please 
> > let me know.
> >
> > Thanks a lot,
> > Luchesar