perfsonar development work

["Luchesar V. ILIEV" <>]

Verena, Stijn, Jason,

I'm afraid only now I have gotten to these mails (reading mails from 
newest to oldest does have its drawbacks, it seems.) :(

In a way connected to my recent mail to Jeff, Verena seems to have 
explained very well what I had not been able to. Thanks, Verena! ;)

As for what Stijn says, I'm afraid I'd better leave it for after some 
sleep. :|

And, finally, Jason (hmm, am I trying to excel you in replying in single 
swipe? ;D ), you made a very good point, indeed, about leaving space for 
further extension, and keeping the solution flexible, as I indicated in 
my previous mail, and accordingly updated my proposal.

Now, about the "COMPONENT: Description" thing, I'd rather leave that for 
after having some sleep too, but I'll still make one important note 
before that. Don't forget that in the core of the perfSONAR service 
monitoring will be the syslog messaging. In the end, there should be no 
difference if an error has been encountered in processing of regular 
user request, or during a self-test. Whatever goes wrong, it must be 
clearly indicated and well described in a message sent to syslog. So, 
getting to the point of it, there wouldn't be anything wrong in a 
"COMPONENT: Description" content of the datum's if that's what syslog 
collects too -- quite on the contrary, that is the goal.

Thanks a lot again, and I'll write again in the morning.

Kind regards,
Luchesar


Jason Zurawski wrote:
> VV;
>
> (Replying to you and Stijn in one swipe...)
>
> > > > 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.
> >   
>
>
> I am not advocating an exhaustive listing of every possible test or a 
> definition of numerous URIs immediately; this would be very imprudent.  
> Having a generic 'service test' is fine by me, but it needs to be 
> structured in such a way that it:
>
>  a) remains consistent with the rest of the framework
>  b) allows for extension
>
> I think Luchesar is on the right track, but my primary concern remains 
> that there is not a clear way to identify the results of this 
> potentially multi-part test through datum elements alone.  Although it 
> may be possible to parse the datum elements returned in the response 
> looking for "COMPONENT: Description" patterns, this is not very clean 
> and could be prone to errors.  Here is something else that accomplishes 
> almost the same goal (although I am still interested in seeing 'single' 
> tests instead of some sort of 'bundle'):
>
> The Request:
>
> <nmwg:message xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"; 
> type="EchoRequest">
>  <nmwg:metadata id="m1">
>    
> <nmwg:nmwg:eventType>http://schemas.perfsonar.net/tools/admin/selftest/1.0</nmwg:eventType> 
>
>  </nmwg:metadata>
>
>  <nmwg:data id="d1" metadatIdRef="m1" />
> </nmwg:message>
>
> And the Response:
>
> <nmwg:message xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"; 
> type="EchoResponse">
>  <nmwg:metadata id="r-m1" metadataIdRef="m1">
>    
> <nmwg:nmwg:eventType>http://schemas.perfsonar.net/tools/admin/selftest/1.0</nmwg:eventType> 
>
>  </nmwg:metadata>
>
>  <nmwg:data id="r-d1" metadatIdRef="r-m1">
>
>     <!-- the original eventType was really just a symbolic name of 2 sub 
> tests.  The service plans
>            to report the status of each instead of using just a 
> nmwgr:datum because of this
>            reason -->
>
>    <nmwg:metadata id="test1">
>      <nmwg:nmwg:eventType>
>        
> http://schemas.perfsonar.net/tools/admin/selftest/SERVICE_TYPE/SERVICE_NAME/TEST_NAME/success/1.0 
>
>      </nmwg:eventType>
>    </nmwg:metadata>
>    <nmwg:data id="result1" metadatIdRef="test1">        <nmwgr:datum 
> xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/";>
>        Hopefully some useful message...
>      </nmwgr:datum>
>    <nmwg:data>
>    <nmwg:metadata id="test2">
>      <nmwg:nmwg:eventType>
>        
> http://schemas.perfsonar.net/tools/admin/selftest/SERVICE_TYPE/SERVICE_NAME/TEST_NAME/failure/1.0 
>
>      </nmwg:eventType>
>    </nmwg:metadata>
>    <nmwg:data id="result2" metadatIdRef="test2">        <nmwgr:datum 
> xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/";>
>        Hopefully some useful message...
>      </nmwgr:datum>
>    <nmwg:data>
>  <nmwg:data> </nmwg:message>
>
>
> This basically unbundles the potentially many tests that the service 
> designers could potentially structure (in any order and amount they 
> choose) in their version of the generic test.  It also ensures that the 
> results are easily tracked and categorized on return instead of relying 
> on something unstructured like the mux of datum elements.
>
> And now for Stijn:
>
> > > 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" />
> >
> > While this seems like a good idea, it isn't really helpful for the 
> > SSHTELNET MP in my opinion. The tests done for the MP are the following:
> >
> > 1) check if eXist works (i.e. get metadata from it)
> >
> > 2) from this metadata, try to execute a command on every device
> >
> > The problem lies within step 2. In order for the service desk to 
> > create a valid request following the proposal above, the service desk 
> > would need to know the number of devices configured in the MP.
> >
> > Alternatively, you can group all devices in one metadata block, and 
> > call the test "device test" or something, but then I think that's a 
> > bit besides the point of having this separation of the tests in the 
> > request.
> >
> > Any other thoughts on this?
> >
> > I do agree that it is more easy to interpret when all the datum 
> > elements in the response belong to a specific part of the metadata, 
> > instead of grouping everything together. 
>
> I did not consider the ordering that would be required, and you are 
> correct that it compounds the problem.  The above alternate method 
> should give you and the other service designers the ability to structure 
> the 'generic' test any way you want which does sound appealing.  
> Alternatively, we do have the tools to order things via the chaining 
> construct:
>
>
> <metadata id="m1">
> <eventType>.../admin/selftest/ma/snmp/test1</eventType>
> </metadata>
>
> <metadata id="m2">
>
>  <!-- e.g. make sure the results of 1 go to 2 ... -->
>
>  <subject metadataIdRef="m1" />
> <eventType>.../admin/selftest/ma/snmp/test2</eventType>
> </metadata>
>
> <data id="d1" metadataIdRef="m1" />
>
> <data id="d2" metadataIdRef="m2" />
>
>
> Or:
>
>
> <metadata id="m1">
> <eventType>.../admin/selftest/ma/snmp/test1</eventType>
> </metadata>
>
> <metadata id="m2" metadataIdRef="m1">
>
>  <!-- I don't need the data, but still run me after 1 -->
>
> <eventType>.../admin/selftest/ma/snmp/test2</eventType>
> </metadata>
>
> <data id="d1" metadataIdRef="m1" />
>
> <data id="d2" metadataIdRef="m2" />
>
>
> Additional thoughts?  Perhaps this can make its way onto the Monday 
> Agenda since there was a lack of content.
>
> -jason

Attachment: signature.asc
Description: OpenPGP digital signature