perfsonar development work

[Nicolas Simar <>]

Nina Jeliazkova wrote:
> Nicolas:
> see comments inline.
>
> Jeff :
>
> I will indeed will prefer to follow some API specification and a 
> transparent one for global LS/dLS is a very good solution.
>
> Michael:
>
> I completely agree - perhaps it make sense to wait couple of weeks to 
> get the API specification ready and then refactor your code to fit the API.
>
>
> Best regards,
> Nina
>
> Michael Bischoff написа:
>
> > hi all,
> >
> > Using the code I submitted a couple of weeks ago to Nina it should be 
> > trivial to implement
> > with that api, since it returns generic services which can be LS's 
> > themselves, and the lookup
> > method also takes a generic service. you can simply traverse down the 
> > tree by calling lookup
> > again as soon as you encounter a LS.
> >
> > regards,
> >
> > Michael Bischoff
> >
> >  
> >
> > > Nina,
> > >
> > >
> > > It is important to point out that while it will of course be possible 
> > > for pS-UI
> > > to make both queries - the intent was to create a resolver style 
> > > library that abstracts this
> > > into an API. That way the move to dLS would be transparent to 
> > > clients. (If you have read the
> > > dLS document at all - this is discovery phase, then query phase. Most 
> > > common uses of the LS
> > > should not need to explicitly do both.)
> > >
> > > We intend to have a straw-man specification of the API sent out to 
> > > the list for
> > > comment in the next week or two. (We had our member meeting last 
> > > week, so this week is the
> > > first chance we have had to work on it.) It will be as language 
> > > independent as we can make it
> > > - but we will likely be creating a specific perl
> > > version and working with Maciej for the Java implementation.
> > >
> > > jeff
> > >
> > > Nicolas Simar wrote:
> > >
> > >    
> > >
> > > > Hi Nina,
> > > >
> > > >
> > > > at the end of the Zagreb meeting, the idea was launched to have a 
> > > > global LS (awaiting for
> > > > the dLS). Several groups of users have been complaining that there 
> > > > isn't any discovery of
> > > > MAs and they'd like to skip the pSUI
> > > > selection step.
> > > >       
>
> As a side note: the user can have all MA selected , psUI will find the 
> correct ones anyway.

It is quite time consuming. People have been put off from pSUI because 
of that feature inter-acting with either too slow MAs or no MA. It was 
taking 4 minutes in some case.

> > > > The idea shown on the slide would be that the current LS would be
> > > > transformed to register to a global LS their URL and the list of 
> > > > domains they are
> > > > responsible for.
> > > >
> > > > The general idea would be that a client would go first to the global 
> > > > LS.
> > > > The request would contain the domain name (or AS or list of domain name
> > > > or AS) for which the information is seeked. The gLS would then send 
> > > > back the URL of the LS
> > > > which has registered that information.
> > > >
> > > > The client can then contact the LSes to get the URL of the web-service
> > > > for which they wish to have the data.
> > > >
> > > > We would wish for the June Berlin workshop to have the global LS 
> > > > working
> > > > along with perfSONAR-UI.
> > > >
> > > >
> > > > In order to investigate for its feasibility, I'd like
> > > > - to have your comments on the idea
> > > >       
>
> The idea seems fine as a workaround.
>
> > > > - to have your thoughts on how perfsonarUI would use the gLS to go from
> > > > a traceroute IP address and find out the web-services that contains 
> > > > the data
> > > >
> > > >       
>
> The steps are more or less clear:
> - get domain name of the IP

That's my main point of interrogation. How can it be done?
Whois to get the domain or AS name?
In that case, it is important that the deployer of the LS register the 
same name as the one used in the reference methodology to map IP 
addresses to domain name/AS name.

Cheers,
Nicolas

> - send it to gLS
> - receive URL of LS
> -query LS for the IP
> -get MA URL
> -query MA as usual
>
> > > > Potential Drawback: in the case of the Hades MA, which data spans 
> > > > across
> > > > multiple domain, it wouldn't work (IMHO?) as the search would be 
> > > > done based on domain names.
> > > > But that's not an issue as we got only one Hades MA.
> > > >       
>
> Yes
>
> Best regards,
> Nina
>
> > > > Thanks a lot,
> > > > Nicolas
> > > >
> > > >
> > > > -------- Original Message --------
> > > > Subject: Global LS deployment until we have dLS
> > > > Date: Fri, 11 Apr 2008 12:50:14 +0200 (CEST)
> > > > From: Maciej Glowiak 
> > > > <>
> > > > To: 
> > > > ,
> > > >  
> > > > ,
> > > > ,         CC: 
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > >
> > > > According to discussion on Thursday and our talk with Martin I am
> > > > sending the slide depicting the idea of global LS deployment until 
> > > > the time when we have dLS
> > > > implemented and deployed.
> > > >
> > > > The idea is to have one common global-LS that would keep summarized
> > > > information from other Lookup Services.
> > > >
> > > > The summary will be send as LSRegistration Request and will contain:
> > > > 1) domain name of services stored in local LS
> > > > or (next step?) 2) first level of summary (all IPs, geografical info 
> > > > and evnetTypes)
> > > > (to be discussed)
> > > >
> > > >
> > > > For instance on the picture there is PSNC MA that register to LS1. 
> > > > LS1 will
> > > > register its summarized information to global LS (well known address).
> > > >
> > > > Client application that wants to get information about PSNC services
> > > > will ask for LS address for (query 1) 1) specific domain
> > > > or 2) IP, geografical location, eventType (if used 1st level summary)
> > > >
> > > >
> > > > Then the client will be responded with LS1 URL and will perform just
> > > > xquery to obtain (query 2) further data.
> > > >
> > > > There might be also replication from gLS to another gLS (backup) - just
> > > > full database copy.
> > > >
> > > > Best regards
> > > > Maciej
> > > >
> > > >
> > > >       
> > >
> > >     

--
Nicolas
______________________________________________________________________

Nicolas Simar
Network Engineer

DANTE - www.dante.net

Tel - BE: +32 (0) 4 366 93 49
Tel - UK: +44 (0)1223 371 300
Mobile: +44 (0) 7740 176 883

City House, 126-130 Hills Road
Cambridge CB2 1PQ
UK
_____________________________________________________________________