perfsonar-dev - Re: [pS-dev] Re: Self-test triggering/response messages pointer
Subject: perfsonar development work
List archive
- From: Verena Venus <>
- To:
- Cc: "Luchesar V. ILIEV" <>, Roman Lapacz <>, Szymon Trocha <>, Maciej Glowiak <>, Stijn Melis <>, Cándido Rodríguez Montes <>, Nicolas Simar <>, Domenico Vicinanza <>, perfSONAR developers <>,
- Subject: Re: [pS-dev] Re: Self-test triggering/response messages pointer
- Date: Thu, 19 Jun 2008 13:30:43 +0200
Hi Jason, all,
Am Mittwoch, 18. Juni 2008 12:59:35 schrieb 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.
>
That's true. However, I'd like to have some kind of generic way to request
for
selftests, at least in the beginning.
1. It's more flexible
2. It's easier to implement
3. There is no problem in extending this to have specific requests for
certain
tests later.
At the moment, service developers have to define what kind of tests they are
going to implement, which will maybe lead to a more or less complex set of
possbile tests. You might not want to run each test in the same interval, so
setting up reqeusts for such tests can be challenging, depending on the
strategy the service desk is going to use.
So, we definitely need a more distinct way of requesting tests. But if we
start to sort this out now, we will not get it done until Berlin.
So, I would suggest to start with the generic approach, Luchesar already
worked out, and then extend it later.
Let's go foward step by step. All we have to do now is ensuring that the
generic approach allows for easy extension for specific requests. Which, I
think, is absolutely no problem.
Let me know, if you see a problem there.
Regards,
Verena
> > 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#Invoc
> >>ation.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
--
Verena Venus, DFN-Labor
Friedrich-Alexander-Universität Erlangen-Nürnberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstraße 1, 91058 Erlangen, Germany
Tel. +49 9131 85-28738, -28800, Fax +49 9131 302941
www.win-labor.dfn.de
- Self-test triggering/response messages pointer, Luchesar V. ILIEV, 06/17/2008
- Re: Self-test triggering/response messages pointer, Luchesar V. ILIEV, 06/17/2008
- Re: Self-test triggering/response messages pointer, Luchesar V. ILIEV, 06/18/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Jason Zurawski, 06/18/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Jason Zurawski, 06/18/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Verena Venus, 06/19/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Jason Zurawski, 06/19/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Luchesar V. ILIEV, 06/19/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Stijn Melis, 06/20/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Verena Venus, 06/20/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Jason Zurawski, 06/20/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Luchesar V. ILIEV, 06/20/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Jeff W. Boote, 06/20/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Verena Venus, 06/20/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Jason Zurawski, 06/19/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Verena Venus, 06/19/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Stijn Melis, 06/19/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Luchesar V. ILIEV, 06/19/2008
- Re: [pS-dev] Re: Self-test triggering/response messages pointer, Jeff W. Boote, 06/19/2008
- Re: Self-test triggering/response messages pointer, Luchesar V. ILIEV, 06/18/2008
- Re: Self-test triggering/response messages pointer, Luchesar V. ILIEV, 06/17/2008
Archive powered by MHonArc 2.6.16.