perfsonar development work

["Jeff W. Boote" <>]

Roman Lapacz wrote:
> > The measurements results are stored in a SQL MA. The user should be 
> > able to choose to which MA he wants the data sent.
> >
> > In the examples I used different namespaces for each action, these 
> > could be put inside the same namespace 'cron' and identified by a 
> > 'action' parameter. I've initially put the MA IP address as an 
> > attribute of the <nmwg:messsage> element, I think this was suggested 
> > by Jeff before, but this isn't actually currently supported by the 
> > nmwg schema. So maybe it should go also as a parameter in the cron 
> > metadata.
>
> I think the attribute in the message element is not a good place for 
> MA's address. What if your request would have 2 sub-requests (2 data 
> triggers) and results of them would have to be stored in separate MAs. I 
> prefer to have it in some metadata element directly related with a 
> measurement.

I agree with Roman here. I would expect it to be in one of the parameters of the 
metadata.

> > <nmwg:message type="MeasurementRequest" id="msg1"
> >     ma="150.162.248.15:8080" 
> > xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
> >     xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/";
> >     xmlns:owamp="http://ggf.org/ns/nmwg/tools/owamp/2.0/";
> >     xmlns:cron="http://ggf.org/ns/nmwg/tools/cron/modify/2.0/";>
> >
> >     <nmwg:metadata id="owamp">
> >         <owamp:subject id="sub2">
> >             <nmwgt:endPointPair>
> >                 <nmwgt:src type="ipv4" value="1.1.1.1" />
> >                 <nmwgt:dst type="ipv4" value="2.2.2.2" />
> >             </nmwgt:endPointPair>
> >         </owamp:subject>
> >         
> > <nmwg:eventType>http://ggf.org/ns/nmwg/tools/owamp/2.0</nmwg:eventType>
> >         <owamp:parameters id="param2">
> >             <nmwg:parameter name="direction">to</nmwg:parameter>
> >             <nmwg:parameter name="count">5</nmwg:parameter>
> >             <nmwg:parameter name="portRange">2500-2999</nmwg:parameter>
> >         </owamp:parameters>
> >     </nmwg:metadata>
> >
> >     <nmwg:metadata id="cron" metadataIdRef="owamp">
> >   
>
> My understanding of nmwg chaining is that the metadataIdRef attribute in 
> metadata element is used for base chaining. So only when we want to 
> divide metadata block in order to reuse their parts. In this case if I 
> decide that the metadata block with id="cron" will not be used elsewhere 
> I could create one metadata element with contents of metadata id=owamp" 
> and metadata id="cron". This of course would be wrong. That is why other 
> chaining approach should be used:
>
>
>    <nmwg:metadata id="cron">
>        <cron:subject id="iusub2" metadataIdRef="owamp"/>
>        <cron:parameters id="param1">
>            <nmwg:parameter name="minutes">20-30</nmwg:parameter>
>            <nmwg:parameter name="hours">*</nmwg:parameter>
>            <nmwg:parameter name="dom">*</nmwg:parameter>
>            <nmwg:parameter name="months">*</nmwg:parameter>
>            <nmwg:parameter name="dow">*</nmwg:parameter>
>        </cron:parameters>
>        <nmwg:eventType>
>            http://ggf.org/ns/nmwg/tools/cron/modify/2.0
>        </nmwg:eventType>
>    </nmwg:metadata>
>
>
> Jason, Jeff, what's your view on this?

Yes - the metadataIdRef of the 'subject' element should be used here. We have 
called this 'filter-chaining' in the past, but I guess it is really more of a 
'function' step. 'function-chaining'?

Now, this might sound silly - but the part I always struggle with is what 
'order' things should be chained:

data -> cron -> owamp
        or
data -> owamp -> cron

It probably doesn't matter that much. But, it would be good to have a clear 
reason that can give guidance across multiple service/message definitions. For 
example, I am hitting a similar issue with bwctl:

data -> bwctl-scheduling -> iperf
        or
data -> iperf -> bwctl-scheduling

(This is for a new version of the bwctl schema. The current one basically has a 
single metadata that includes iperf and bwctl options. But the next version of 
bwctl will support other throughput tools such as nuttcp and thrulay so I was 
trying to factor out the bwctl specific things.)

jeff