perfsonar development work

[Jason Zurawski <>]

VV, Stijn & All;


> > > 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_NA
> > > ME/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_NA
> > > ME/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.
> >
> >     
>
> I like this one also. I think it fulfills the requirements (a and b from 
> Jason, and 1. 2. 3. from myself ;) )
>   


Excellent.  Luchesar/Jeff/Other developers: could you perhaps weigh in 
on this?


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


Stijn: We can ignore this chaining proposal.  Just as an explanation, my 
intention was to show that the service desk won't need to know how many 
metadata there are: the results of the eXist test can be passed directly 
to the second test but perhaps this is not low level enough to be useful.


> > > Additional thoughts?  Perhaps this can make its way onto the Monday
> > > Agenda since there was a lack of content.
> > >       
>
> I'd like to have an agreement for this fast, so I suggest Luchesar to rework 
> his proposal (if he has not already done so) to reflect the format suggested 
> by Jason for the generic case. Then we can agree with the group on monday  on 
> this proposal, and go forward discussing the specific requests. I think this 
> will not be so easy, as Stijn already pointed out problems with this approach 
> for SSH/Telnet MP.
>
> I want to point out here, that this feature should be optional, so I see no 
> need for services not beeing part of the MDM to implement the generic 
> approach immedeatly, or at all. It will not brake the protocol if a service 
> responds with a proper error message, indicating that no (generic) selftest 
> functionality is implemented. Which more or less boils down to: "EventType 
> not known".

If someone points me to the URL of the wiki I would be happy to add it 
(I have only found one page thus far, and it seems to contain RNC schema 
only, not examples).  I agree with your sentiment about MDM and perhaps 
as a parallel effort we could still specify the 'single test case' that 
everyone would be interested in using.

-jason