perfsonar development work

[Verena Venus <>]

Hi all,

Am Freitag, 20. Juni 2008 10:47:58 schrieb Stijn Melis:
shortening for better readability:
[...]
> > 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, we all agree with this statement.

> > 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 ;) )

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

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

Regards,
Verena 
-- 
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