perfsonar development work

[Stijn Melis <>]

Hi Jason,

thanks for your answer. You can find my comments inline.

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 seems like a very good solution to me. This also fixes my problem, 
because in the request there is only one entry stating a very generic 
"http://schemas.perfsonar.net/tools/admin/selftest/1.0";, while in the 
response, this generic eventType is more detailed in its subtests. I am 
in agreement with this syntax.

> 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:
>
> <snip>
>
> 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" />

Are you talking about the request here? Because if you are, this would 
still contain the same problem as before. Because the service desk 
doesn't know how many devices there are configured in the MP, it 
wouldn't know how many metadata blocks there should be (chained or not, 
it doesn't really matter in this case, in my opinion).
The format you suggested to Verena, however, does solve the problem, 
because no matter how many devices there are configured, you still only 
have one metadata block in the request.

Regards,

Stijn

> Additional thoughts?  Perhaps this can make its way onto the Monday 
> Agenda since there was a lack of content.
>
> -jason