perfsonar development work

[Jason Zurawski <>]

Luchesar;


> > 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.
>
> Good point. However let's start with something easier, so how about a 
> generic test as a beginning?
>
> http://schemas.perfsonar.net/tools/admin/selftest/generic/full/1.0


See my comment to VV for an in depth reasoning.  I am not opposed to 
'all in one' as long as it is structured appropriately.


> > 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).
>
> You can tell if you have the info in the datum ("COMPONENT:"), and 
> you'll also have the number of tests as number of returned datums.


This may be true, but it is far from clean or ideal.  We use the 
structured messages for a reason: there is a natural mechanism to find 
what we are really interested in by walking the XML.  Doing a regex 
across several datums to verify the results of the test offers a quick 
and correct solution to this problem, but we do have the tools at our 
disposal to avoid shoving all possible results into a single text 
bloated element. 


> But I concur that separate metadata and data could be a benefit, 
> especially if we implement more specific tests in the future.
>
> > 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>
>
> Sure, that's very good idea. But I haven't proposed it for one single, 
> yet important reason so far. We don't have effective means to keep 
> this information widely available and current. When the Lookup 
> Services begin full operation, then perhaps the available self-tests 
> could be something registered there. Then you could, really, easily 
> send the type of requests you propose. So I'd suggest keeping this in 
> mind, but start with the simpler generic self-test. Simply we need 
> efficient enough self-testing for the upcoming 3.1, but can certainly 
> extend it later.


Ok, we can shelve the discussion of 'what ifs' and extensive 
personalized tests.  Even with the generic test you propose we need to:

 a) keep the format within the confines of the rest of the framework
 b) allow for this future extension.

The semantics of the multiple datum elements for this one test is really 
the issue that concerns me most.  If I am running this generic test I 
would want to know exactly what was being tested in this so called 
bundle for two reasons really:

 1) the logs need to reflect the details (e.g. the service running the 
test knows exactly what was going on, but the client doesn't get the 
complete picture)
 2) I may want to run the failed tests again on their own, outside of 
the bundle. 

Structuring things to avoid just using some number of datum elements 
does not complicate your idea for the generic test, and does not 
increase the amount of work needed to craft and send back an appropriate 
response from each service. 


> > 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.
>
> Okay, how about the response eventTypes:
>
> http://schemas.perfsonar.net/status/selftest/generic/full/1.0/
>                                                               success
>                                                               error
>
> Indeed, why has success and error been closer to the root (/) than 
> what generates them? To me the schema above is more logical, but I 
> might be missing something. I'll appreciate your opinion. Also, for 
> the generic selftest, it does make sense to return single metadata and 
> multiple datums. Once again, ID of the message origin is not a 
> problem, as it must be in the datum anyway. Each datum would 
> essentially contain what is written to syslog, and you'll want the 
> origin of the message there, anyway.


I don't think the proposed way to convey the information via the datums 
is completely wrong; I just think it shoving a little too much and too 
complex information into an element that wasn't really designed to 
handle it.  Hopefully I made my points clear in the examples from the 
previous message, if I haven't please let me know and I can formalize it 
more.


> Saying that, and going back to what you said about logging, the 
> EchoResponses will not be parsed to write the logs. Additionally to 
> the EchoResponse, the service will write all messages via syslog. In 
> fact, the web messages are additional to sysloging.

This is part of a larger discussion ( that should be scheduled for next 
week ) regarding 'completeness' in the initial request and the 
subsequent response.  There is information loss when a service decides 
to cover up intermediate steps, and being a bit more verbose does not 
hurt (regardless of if the information appears in syslog or some other 
form of report).

-jason