perfsonar development work

[Szymon Trocha <>]

HI Jason,

Jason Zurawski pisze:
> Szymon Trocha wrote:
[...]
> > So that means that the summarization algorithm is wrong and needs 
> > serious improvements.
>
>
> I agree, will Maciej be available to work with the student on improving 
> the procedure?  The algorithm will be applicable to both the MDM and PS 
> services.

I think we should summarise problems with the help of Nina and Michael 
and then try to debug and work on solution. GN3 will not rush 
immediately with development so we should have some time for design as 
this will be one of the priorities to resolve.
I'd like to suggest a conf call to discuss this issue of LS usage.
As for today Maciej will continue his work on LS.

> > Can you explain to me how the answers from LS as shown by Nina can 
> > help the GUI to get data from PIONIER network as they don't provide 
> > *ANY* MA which contain correct data? My understanding is the results 
> > are currently useless for GUI. What would be the way to get correct 
> > MAs according to this algorithm?
>
>
> First, are there MAs and LSs that have this data and are they gLS 
> enabled?  From Nina's mail:

Let's focus on PIONIER's data.
Yes, there is a PIONIER hLS: 
http://ls.perfsonar.pionier.net.pl:8180/geant2-java-xml-ls/services/LookupService
It contains in its eXist database entries about 212.191.224.74 and 
150.254.185.146
The hLS is gLS enabled and is visible in gLS cloud.

> > 150.254.185.146  (PIONIER)
> > 192.5.40.187
> > 212.191.224.74
> > 194.141.0.10  (BREN) 
>
>
> Looking in the gLS, this is the summarization I see for PIONIER:
>
>         <nmtl3:network 
> xmlns:nmtl3="http://ogf.org/schema/network/topology/l3/20
> 070828/">
>           <nmtl3:subnet>
>             <nmtl3:address type="ipv4">150.254.162.229</nmtl3:address>
>             <nmtl3:netmask>32</nmtl3:netmask>
>           </nmtl3:subnet>
>         </nmtl3:network>
>         <nmtl3:network 
> xmlns:nmtl3="http://ogf.org/schema/network/topology/l3/20
> 070828/">

Correct. Such interface exists in PIONIER RRD MA

>           <nmtl3:subnet>
>             <nmtl3:address type="ipv4">62.40.124.182</nmtl3:address>
>             <nmtl3:netmask>32</nmtl3:netmask>
>           </nmtl3:subnet>
>         </nmtl3:network>
>         <nmtl3:network 
> xmlns:nmtl3="http://ogf.org/schema/network/topology/l3/20
> 070828/">

Correct. Such interface exists in PIONIER RRD MA

>           <nmtl3:subnet>
>             <nmtl3:address type="ipv4">212.191.224.0</nmtl3:address>
>             <nmtl3:netmask>24</nmtl3:netmask>
>           </nmtl3:subnet>
>         </nmtl3:network>

Correct. Such interfaces exist in PIONIER RRD MA

So the only missing one is 150.254.185.146 but it cannot be found for a 
simple reason - this one is not monitored and included in PIONIER RRD MA 
(this is our test server).

> Since this is a Java hLS, I would ask Maciej to please look at his 
> summarization code to ensure the proper ranges are being reported, 
> 150.254.162.229/32 is rather specific :)  As for the other ranges, if 
> you know which hLS is summarizing for them I can do the same analysis to 
> get us closer to debugging the problem.

So the above shows that after summarization the data is there (generally 
speaking).
So if there are sources of data which announce themselves correctly to 
LS infrastructure why does psUI get MAs which are completely different 
than PIONIER correct ones (which don't appear at all)? They shouldn't 
appear in the list as they do not contain PIONIER data. Is it wrong API 
request, wrong response from LS, wrong response interpretation?

> The bottom line is that if there is not data in the gLS cloud this will 
> not work.  The results for the Interet2/IU services would still show up, 
> but the 'correct' hLS would as well and proper answer can be discovered.

Let me know if you need more details.

Regards,
--
Szymon Trocha

Poznan Supercomputing & Netw. Center ::: NETWORK OPERATION CENTER
Tel. +48 618582022 ::: http://noc.man.poznan.pl