perfsonar development work

[Jason Zurawski <>]

Nina;

> Suppose the list of services for particular network element is 
> retrieved.  These can be very different services, which have to be 
> queried with different xml messages.
> How the client will know that one service is "hades" and have to be 
> queried for pair of IP adresses, and the other is TelnetSSH ?


The eventType values are indicative of what topology element/message 
structure would be needed.  For example if you received back 
characteristic/utilization and tools/iperf as eventTypes, interfaces and 
endPointPairs would be the topology subjects.  These are/will be defined 
by the various documentation efforts.


> The service version, introduced in newer LS versions help, and still 
> how do we interpret /servicetype="ma"/ and /service version="3.0"/ ? 
> Should it be uniquely recognized as RRD MA from perfsonar 3.0 
> distribution? What about flowSA MA ?  Is the expected meaning of 
> /serviceName  /defined?


These are excellent observations, and points out an obvious flaw in 
allowing deployments to define their own keyword structure.  I think it 
is much safer to rely on data structure (eventTypes, etc.) to dictate 
the structure of that data rather than a set of self configured strings.


> I guess event types might be the answer - but this needs to be 
> bootstrapped somehow. Can lookup service metadata query be used for 
> any type of service and return information in a more or less similar 
> way?  Currently, the result of a LS query is returned as *AnyElement*
>
> XQueryResults =
>         element psservice:datum { AnyElement* }
>         
> AnyElement =
>   element * {
>     (attribute * { text }
>      | text
>      | AnyElement)*
>   }  
> Provided, that the client should parse the XQuery results in order to 
> get the eventtypes, it should expect a well defined syntax. Do we have 
> such syntax that is valid for all type of services that (at least) 
> exist currently? For PIONIER RRD MA it contains nmwgt:interface 
> elements. Is it assumed this is the case for all services?


I am not sure what type of bootstrapping or well defined syntax you 
would be expecting here, the queries that the LS is able to accept are 
quiet arbitrary and the resulting data will be as well.  The purpose of 
the API was to normalize the behavior of certain calls so that *every* 
client/service won't have to:

a) create arbitrary XQuery syntax (perhaps redefining well known ways to 
get data)
b) deal with raw LS results that as you point out can be *anything*

Instead of communicating directly with the LS, calling one of the 
functions (e.g. getLSLocation or some other proposed call from the gLS 
document) and get back an answer that is much more defined than 
arbitrary XML.  I am still looking for feedback on this, if one of the 
proposed calls doesn't do something you want or need, we should talk 
about this very soon.


> <nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"; id="meta36">
>         <netutil:subject 
> xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/"; 
> id="subj36">
>             <nmwgt:interface 
> xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/";>
>                 
> <nmwgt:hostName>poznan-gw1.rtr.pionier.gov.pl</nmwgt:hostName>
>                 <nmwgt:ifName>xe-5/1/0.128</nmwgt:ifName>
>                 <nmwgt:ifDescription>Szczecin at poznan-gw1 
> 10GE</nmwgt:ifDescription>
>                 <nmwgt:ifAddress 
> type="ipv4">212.191.224.170</nmwgt:ifAddress>
>                 <nmwgt:direction>out</nmwgt:direction>
>                 <nmwgt:authRealm>PIONIER-Public</nmwgt:authRealm>
>                 <nmwgt:capacity>1000000000</nmwgt:capacity>
>             </nmwgt:interface>
>         </netutil:subject>
>         
> <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
>     </nmwg:metadata>
>
> This is definitely not the first time I am bringing the question how a 
> generic client (working with any type of services) could bootstrap 
> itself.
>
> Speaking about LS metadata queries, is there any particular reason 
> that metadata query for RRD MA returns only list of metadata elements, 
> but not metadata/data pairs? This is the current behaviour of PINIER 
> RRD MA service from perfsonar 3.0 distribution 
> http://ls.perfsonar.pionier.net.pl:8080/xml-ls/services/LookupService
>
> The schema seems to specify metadata/data pairs. 
> https://svn.internet2.edu/svn/perfsonar/trunk/geant2_java-xml-ls/doc/schema/rnc/LSQueryResponse.rnc


I am not sure what you mean by this, can you paste an example?

-jason


> > The query we were expecting was:
> >
> > What services (no matter the type) have data related to the following 
> > network topology elements?
> >
> > jeff
> >
> > On May 23, 2008, at 3:07 PM, Michael Bischoff wrote:
> >
> > > I'm not sure if its a valid use-case to figure out what kind of 
> > > services a LS contains unless
> > > the LS is also bound to a Location/area. (so something along the 
> > > lines of which (h)Ls-es are
> > > there along the path -> what tools(->read services) do I have avail 
> > > to test this route?
> > >
> > > But to be honest for the near future I expect users to look for 
> > > services by organisation
> > > (like what perfSONAR services are there available at Belnet) 
> > > (perhaps summarization in the
> > > gLS/dLS context should look at sending info on that too)
> > >
> > >
> > > > That 'can' be? Or that currently exist in any given LS?
> > > >
> > > >
> > > > Since new services can be created by anyone at any time, all possible
> > > > values can never be given.
> > > >
> > > > jeff
> > > >
> > > > On May 23, 2008, at 11:59 AM, Nina Jeliazkova wrote:
> > > >
> > > >
> > > > > All,
> > > > >
> > > > >
> > > > > Is it possible to list all possible serviceType values, that can be
> > > > > registered in a Lookup service? e.g. for RRD-MA, SQL-MA, Hades, 
> > > > > BWCTL, Telnet SSH, etc.?
> > > > >
> > > > >
> > > > > I am looking for a way to establish a correspondence between the
> > > > > information currently  stored in MA.conf and one retrieved from a 
> > > > > Lookup service.
> > > > >
> > > > > Best regards,
> > > > > Nina