perfsonar development work

[Roman Lapacz <>]

Jason Zurawski wrote:
> Roman;
>
>
> > > I still am confused as to why you feel 'supportedEventType' 
> > > parameters are a much better fit than eventType in this case, they 
> > > are describing the same exact thing except that eventType is more 
> > > direct than a parameters block.  The old style may have filled a 
> > > need during the early development, but if we are going to progress 
> > > to supporting multiple metrics using the same descriptions we should 
> > > try more concrete solutions instead of workarounds.
> > I would prefer to keep parameters to group supported event types 
> > (first we had eventType element but after a while we decided to 
> > switch to parameters as grouping solution) but I'm not against to 
> > come back to eventType.
>
>
> If it makes the short term work easier than its ok, but we should 
> consider moving to something more formal.

OK, so I will keep supportedEventType parameter for the next release 
because we don't have too much time to implement two new metrics and 
eventual update of already implemented ones (Nicoals, correct me if I'm 
wrong) but after the release I can implement the use of eventType as a 
solution we prefer in future.

> > > > > > 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.
> > > There is no information loss because the key has been 'cooked' in 
> > > one of its previous visits and the server has organized the 
> > > information in a format it likes, including extra parameters blocks 
> > > in various namespaces really only aids humans as they examine the 
> > > key (which they shouldn't do anyway as it is opaque).
> > > Ideally we shouldn't be passing back a clear key where it is obvious 
> > > to see what we have done (the key structure if I recall correctly 
> > > should be used to save state on the server end), we should start 
> > > moving to an obfuscated key that means nothing by sight.
> > I agree with you that the key has no meaning for a client but a 
> > request with key for service side is a different case. Why not to 
> > keep namespaces as originally? It might be useful for RRD MA (at 
> > least for Java implementation). It will not be the rule for all 
> > services of course. Other services might use totally different keys 
> > (even without parameters :) In fact, client app should not generate 
> > keys, it should get it from a service.
>
> I would still *much* rather we go back to including the entire chain 
> in these communications, that way we are guaranteed to not lose 
> anything.  If we are going to treat the entire

Hmm, but a key can represent a chain of metadata. This is my 
understanding of a key (something which is just an id; it does not 
matter how it looks like; I could imaging that a service could have a 
map structure with pairs key - metadata chain ).

> key as opaque, then it really shouldn't matter what is on the inside, 
> although I am still against the idea of including two sets of parameters

the number of parameters sets depends on the namespace number (I can 
imagine that there could be more parameters namespaces used in one request)

> because it is not very natural in my opinion ('cooking' is 'cooking' 
> no matter what end result looks like).  Does the RRDMA use the above 
> example now?

Yes. After the last release I implemented this (before that there was a 
discussion about it on the list). I think it's not a big problem now 
because the key should be generated be a service and client should use 
them as a black box (it does not know what's inside). The problem  might 
be on the client side which generates keys (in this case the client must 
know inside structure).


Roman



> (your interface docs seem to show everything being in one 
> nmwg:parameters block, if you are changing things please let me know 
> for interop purposes).
> -jason