perfsonar development work

["Michael Bischoff" <>]

Hello Luchesar,

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

Afaik the use of non-URI eventTypes is considered deprecated and services
should move to URI's asap.

the old echo req/response should probably also be changed to URI.

regards,

Michael


> 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.
>
> 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.
>
> 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.:
>
> <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.
>
> 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_we
>> b_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
>>
>>
>
>