perfsonar development work

["Jeff W. Boote" <>]

Hi All,

First, Luchesar, I would like to apologize for my choice of  
vocabulary. I did not mean to imply that the ideas were convoluted,  
only that the syntax was. I understand your desire for simplicity and  
your desire to match the design to logging infrastructures.

My main concern here was only that the syntax did not match the  
overall architecture for how relationships between information have  
normally been described in the schema. And, I would like to keep that  
as consistent as possible, so it can stay as simple as possible.  
(Given that it is already not so simple.)

My suggestion of using the different namespace was motivated from the  
desire to keep the perfsonar/admin namespace for 'required' protocol  
eventTypes (to make it easier for service developers to see the  
complete set of required eventTypes they must support to be compliant  
with the perfSONAR protocol when it is standardized) but perhaps it is  
already too late for that. And as VV says, a service can of course  
return a non-supported error. But, I don't see how using this  
different namespace hurts the MDM services... It just makes it more  
clear that this data format is specifically developed for this purpose.

My goal here is that as much as possible, I would like this to use the  
same mechanisms we have already been employing to maintain the  
relationship information between test metadata/test results for  
individual tests.

I definitely prefer the latest syntax that you have all been  
discussing to the previous.

jeff

On Jun 20, 2008, at 3:10 AM, Verena Venus wrote:

> 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