perfsonar development work

[Jason Zurawski <>]

Guilherme;

> > I think you are confusing two issues here: what is necessary for 
> > services to register to LS instances and what LS instances need to do 
> > to distribute this information via the gLS mechanism.  The gLS 
> > document I pasted above does not deal with the former and I do 
> > believe descriptions exist for this task exist already and Maciej 
> > should be able to point people to the exact locations.
> >
> > The requirements for services registering to the LS have not changed 
> > since the original LS was released some time ago.  We have always 
> > asked that each service provide a service information description as 
> > well as metadata that they manage.  In the provided metadata it is 
> > assumed that eventType(s) as well as the necessary domain and address 
> > information is provided (each time I helped design new metadata 
> > descriptions for the various services we ensured that this 
> > information was available).
> This is very clear in the case of MAs, because they handle specific 
> metadata. I don't see it as clear in the case of MPs which, for 
> instance, permit on-demand measurements to anywhere (and, in some 
> cases, from anywhere). What I think that Verena is trying to say is 
> that we don't have a specific metadata definition of what the service 
> does, like you have in your store.xml.
>
> We have eventTypes which are accepted by the service and the schema 
> that defines what is permitted and needed in the requests that use 
> them. We wouldn't register something as complete as you have in the 
> request for perfSONAR-BUOY, because we don't have specific  
> information, i.e. parameters or endpoints. Using your example, we 
> could adapt it to be generic, which would actually be registering the 
> RNC for the requests accepted, and I know this is not what is 
> expected, or we could make it as simples as, i.e. for CL-MP:
>
> <nmwg:data id="data-1" metadataIdRef="serviceLookupInfo">
>    <nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"; 
> id="metadata-1">
>      
> <nmwg:eventType>http://ggf.org/ns/nmwg/tools/ping/2.0</nmwg:eventType>
>      
> <nmwg:eventType>http://ggf.org/ns/nmwg/tools/traceroute/2.0</nmwg:eventType> 
>
>      
> <nmwg:eventType>http://ggf.org/ns/nmwg/tools/bwctl/2.0</nmwg:eventType>
>      
> <nmwg:eventType>http://ggf.org/ns/nmwg/tools/owamp/2.0</nmwg:eventType>
>      
> <nmwg:eventType>http://ggf.org/ns/nmwg/tools/cron/2.0</nmwg:eventType>
>    </nmwg:metadata>
>  </nmwg:data>


I don't think the situation is any different than an MA actually, if you 
do not have the topology elements (in your case they do not exist) you 
can't register them.  You do have access to what eventType(s) are 
available though, and the service itself may have ACLs that allow it to 
make measurements in certain domains or IP ranges (or it could be wide 
open) so these items may be substituted for a particular 'interface' or 
'endPoint'.  Your example above looks acceptable.


> This would be just registering all eventTypes accepted by the service, 
> and I believe it might satisfy the requirements of the dLS. But we get 
> to another point, as I was mentioned before, it might also be 
> interesting to have not only the functionalities (eventTypes) 
> available, but also extra information about them (which actually means 
> metadata information, and could just be defined using parameters).
>
> But these are not related directly to the eventType as action, but to 
> the eventType as functionality. In the sense that you have parameters 
> for defining a ping measurement (i.e. count, size), which is defined 
> by the ping namespace. Now we would also need parameters for defining 
> information about actually using the funcionatility (doing a ping), 
> i.e. if it needs authentication or not. We could define a new 
> namespace for this kind of information, and I believe this is what 
> Verena was actually asking for (not exactly for this purpose).


This extra information you speak of will be available in the CL-MP 
though.  Once a service/user tracks down 'what' they are looking for via 
the eventTypes, they can of course query the CL-MP directly for 
additional information such as parameters. 

The CL-MP is free to define whatever parameters it would like to 
register to its local LS instance, but that local instance *will not* 
turn around and summarize these parameters for inclusion in the gLS at a 
higher level.  From a discovery point of view I agree that they may be 
useful, but there needs to be a boundary line drawn on what is useful 
for a wide area query (e.g. someone a continent away be looking for ping 
data with a count of 1 but breaking that query into two parts seems more 
reasonable than making sure all parameters are available at the upper 
level).


> I don't think there has been any definition of this before, I think it 
> has always been just "anyText". But maybe I'm wrong, it would be good 
> if Maciej jumped into the discussion.


From Maciej's point of view 'anyText' is really all he needs to care 
about.  There is some well formed blob that comes from a service that 
the LS can manage.  It is up to the individual service designer to 
elaborate this as much as possible.

-jason