perfsonar development work

[Jason Zurawski <>]

All;


> > > > It is not clear if this is a discovery issue, or an advertising
> > > > problem at this point.
> > > >
> > > > One aspect of this is that the pS-PS hLS summarization algorithm is
> > > > advertising too-wide of ranges, and we are working on fixing that.
> > > > But, we also need to understand better the summarization algorithm of
> > > > the MDM hLS. It looks suspect that it is advertising /32's.
> > > I think /32 can reflect correctly what is in PIONIER RRD MA. It has
> > > only single interface in each of these networks in metadata config
> > > file. So MDM hLS advertises /32s for these two IPs. Or you would
> > > expect something different here?
> > >
> > > > As mentioned before - we need to see the actual messages that the
> > > > Java gLS-API is sending to debug this. Obviously the discovery query
> > > > that is being sent from pS-UI is not finding those /32's - and we
> > > > won't be able to figure out why until we can see the specific query
> > > > messages it is sending.
> > > Could you Nina help us here?
> > Perfsonar log attached for the same scenario
> > (TracerouteTest#testNewLookup() )
> >
> >         "150.254.185.146",//  (PIONIER)
> >          "192.5.40.187",
> >          "212.191.224.74",
> >          "194.141.0.10"//  (BREN)
> >
> > You might notice the response from PIONIER LS contains an error code.
>
>
> Thank you Nina, I will look through it as soon as I am able. 
> Incidentally, the error is at the gLS (Syzmon, could you check your 
> service?) - but the API should know enough to contact the next available 
> gLS.  I am more interested in seeing if there are any hLS errors.


The good news is that I know the problem, it is 2 bugs, and everyone 
(except Nina and Michael) are to blame :)  Both bugs are related to 
eventTypes actually, and not the IP addresses at all:

First bug (in the gLS):

Maciej told me some time ago that multiple eventTypes are not supported, 
so to fix this we allow eventType parameters:

<summary:parameters 
xmlns:summary="http://ggf.org/ns/nmwg/tools/org/perfsonar/service/lookup/summarization/2.0/"; 
id="summmary.md.1">
<nmwg:parameter name="eventType" 
value="http://ggf.org/ns/nmwg/characteristic/errors/2.0"/>
<nmwg:parameter name="keyword" value="project:geant2"/>
<nmwg:parameter name="eventType" 
value="http://ggf.org/ns/nmwg/characteristic/utilization/2.0"/>
<nmwg:parameter name="eventType" 
value="http://ggf.org/ns/nmwg/characteristic/discards/2.0"/>
</summary:parameters>

The gLS discovery code does search for these, but was failing due to a 
poorly constructed internal XPath.  I have fixed this and will send 
e-mail to the gLS deployers immediately when I have a new package 
available.

The second bug is in the Java hLS:

Because the eventType parameters are used (and only one eventType could 
ever be present) I am seeing this being registered into the gLS from the 
Java hLSs:

<nmwg:data>
  <nmwg:metadata>
    <summary:subject>

      <nmtb:domain />

      <nmtl3:network />

    </summary:subject>
    <summary:parameters>
      <nmwg:parameter name="eventType" />
    </summary:parameters>

<nmwg:eventType>http://ggf.org/ns/nmwg/tools/org/perfsonar/service/lookup/summarization/2.0</nmwg:eventType>
  </nmwg:metadata>
</nmwg:data>

The summarization eventType here is unexpected - there should only be 
'data' eventTypes in this space (e.g. utilization, errors) and this was 
causing the Discovery code to ignore them.

Maciej: Just removing the eventType from this message will work for me - 
when you are able to support multiple eventTypes it can return.

Once these fixes are entered (and the summerization algorithms are 
enhanced) we can try Nina's use case again.

Thanks;

-jason