perfsonar development work

["Jeff W. Boote" <>]

I can see the desire for a simple generic test request. However, the  
resulting response should be equally simple. The current proposal does  
not fit that in my opinion.

For a simple generic case, I would expect a result to only have a  
simple result code and a human readable status message with more  
details. Something very simple like that I could see supporting in our  
services as well. However, the current proposal is a bit convoluted  
for me.

It seems clear that you all need to implement something fairly quickly  
for this. And that it may not be something that the full group of  
perfSONAR services want to support.

I would suggest you create your own namespace for this, so it is  
outside of the 'perfsonar' namespace. Things in the perfsonar  
namespace should probably be reviewed more thoroughly (and will be  
specified by the new OGF group). Several of you have already noted  
that this should be enhanced in the future - so it seems clear that we  
don't really know what should be here yet.

If you use your own namespace, you can get some operational and  
development experience for what works and use that to make  
recommendations for what should be in the perfsonar namespace in the  
future, ok?

Perhaps something like:

http://schemas.geant2.net/mdm/admin/selftest...

jeff

On Jun 19, 2008, at 7:55 AM, Luchesar V. ILIEV wrote:

> 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