perfsonar development work

["Luchesar V. ILIEV" <>]

Hi Jason,

Thanks a lot for the helpful comments. :)

Jason Zurawski wrote:
> 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

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

Great.

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

Agree.

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

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.

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

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.

Thanks a lot again for your very helpful comments and suggestions.

Cheers,
Luchesar

Attachment: signature.asc
Description: OpenPGP digital signature