perfsonar development work

[Roman Lapacz <>]

Jason Zurawski wrote:
> > 2) 
> > http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/errors/store.xml 
> >
> >
> > supportedEventType parameter is not needed in the key. Data element 
> > with a key refers to metadata where supportedEventType is present.
>
>
> We will need to have this in the key (or perhaps just eventType) for 
> situations when a metadata element describes multiple eventTypes, and 
> may be used by several data blocks w/ keys.  Consider a metadata 
> description  that is used for utilization, errors, and discards.  The 
> corresponding RRD description may use two files (one for utilization, 
> another for errors/discards):
Using parameters element with supportedEventType parameters fits here 
perfectly. metadataIdRef of data element points to ceratin metadata 
element with relevant supportedEventType parameter.

<metadata id="1">
 <parameters>
   <parameter name="supportedEventType">1</parameter>
   <parameter name="supportedEventType">2</parameter>
   <parameter name="supportedEventType">3</parameter>
 </parameters>
</metadata>

<data id="d1" metadataIdRef="1">
 <key>
   file1
   ds0
 </key>
</data>

<data id="d2" metadataIdRef="1">
 <key>
   file1
   ds1
 </key>
</data>

<data id="d3" metadataIdRef="1">
 <key>
   file2
   ds0
 </key>
</data>
> <metadata id="1">
>  <eventType>1</eventType>
>  <eventType>2</eventType>
>  <eventType>3</eventType>
> </metadata>
>
> <data id="d1" idRef="1">
>  <key>
>    <eventType>1</eventType>
>  </key>
> </data>
>
> <data id="d2" idRef="1">
>  <key>
>    <eventType>2</eventType>
>    <eventType>3</eventType>
>  </key>
> </data>
>
>
> > 3) 
> > http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/errors/store.xml 
> >
> >
> > This file is store file so metadata should contain this:
> >
> >        <nmwg:parameters>
> >            <nmwg:parameter 
> > name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:parameter> 
> >
> >        </nmwg:parameters>
> >
> > instead of this:
> >
> >        
> > <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType> 
>
>
> We should move away from 'supportedEventType' and start using actual 
> eventTypes so we can get rid of the layer of indirection that 
> parameters gives us.

I don't see the problem in using parameters here

> > 6) 
> > http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/errors/MDKRequest2.xml 
> >
> >
> > Parameters in the key in metadata m3 represent more than one 
> > namespace so it should look like this:
> >
> >    <nmwg:key id="1">
> >      <nmwg:parameters id="1">
> >        <nmwg:parameter 
> > name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:parameter> 
> >
> >        <nmwg:parameter name="type">rrd</nmwg:parameter>
> >        <nmwg:parameter name="valueUnits">Eps</nmwg:parameter>   
> >        <nmwg:parameter 
> > name="file">/home/jason/perfSONAR-PS/MP/SNMP/mead.rrd</nmwg:parameter>
> >        <nmwg:parameter 
> > name="dataSource">eth0-ifInErrors</nmwg:parameter>
> >      <nmwg:parameters id="2">
> >      <select:parameters id="2">
> >        <nmwg:parameter name="startTime" value="N-50" />
> >        <nmwg:parameter name="endTime" value="N" />
> >        <nmwg:parameter name="resolution" value="1" />
> >        <nmwg:parameter name="consolidationFunction" value="AVERAGE" 
> > />           </select:parameters>
> >    </nmwg:key>
> >
> > This approach should be used in requests and responses.
>
> This is too cumbersome and allowing multiple parameters blocks doesn't 
> look correct in this case.  We really should use a chain to describe 
> what is going on, or because the contents of the key is opaque it 
> should not matter what namespace is used to describe the internals.

I think it's quite clear and straightforward. Right, what's inside does 
not matter for a client but for a service might be interesting and 
needed not to lose context of parameters. Having all parameters in one 
namespace nmwg, which in fact might be wrong for some of them, is losing 
some information.


Roman

> -jason