perfsonar development work

[Jason Zurawski <>]

Guilherme;


> > > > > If a service does not make available to the LS:
> > > > >
> > > > > a) Address information (ipv4 or perhaps ipv6)
> > > > > d) Domain information (fully qual hostname will do)
> > > > > c) any and all possible eventTypes
> > > > >
> > > > > Discovery will be meaningless.  If service authors have questions or
> > > > > concerns about this, lets start talking about it very soon, and if 
> > > > > you
> > > > > haven't done so *please* read the LS API document, this should 
> > > > > explain
> > > > > everything:
> > > > >
> > > > > http://anonsvn.internet2.edu/svn/nmwg/trunk/nmwg/doc/dLS/gLS/phase_1_color. 
> > > > >
> > > > > html
> > > > >
> > > > >     
> > > > Good to know this one also. It is not obvious to me (and 
> > > > considering that quite a lot of other services have not implemented 
> > > > this, it seems to be not obvious to others, too) that the API for 
> > > > dLS is relevant for implementing the API to LS! Sorry, but how do 
> > > > you expect me and others to find exactly this document if noone 
> > > > points out that it is the one you need to implement when properly 
> > > > registering to LS?
> > > >
> > > > By the way, I had a look into it. Unfortunately it does not point 
> > > > to a schema definition for the elements to be registered with a 
> > > > normal LS. So, still, I do not know, how I should do this exactly.
> > > >
> > > > It's not that I need a discussion what elements should be 
> > > > registered. I just need to know which elements you need, and in 
> > > > what format I should register them, that's all.   
> > >
> > >
> > > 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>
> >
> > 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).
> Sorry, just realized I was talking specifically about the CL-MP. CL-MP 
> uses eventTypes also as functionalities, but this isn't the case for 
> any of the other services I know. The other services use the message 
> types. In which case we can separate what I said in two parts, the one 
> above this, which related to registering which eventTypes the service 
> actually deals with and can be done as proposed, and the one below 
> which is more about registering that kind of information to the LS or 
> not.
>
> Maybe the information about functionalities hasn't been deemed 
> necessary, I know that for AA the client is supposed to make the 
> request and then see if it needs authentication or not. For CL-MP, 
> there are other things to be considered, i.e. scheduling restrictions, 
> but they might also just be done in a per request basis instead of 
> registering it to the LS. So if this is the case, we can forget about 
> the paragraph below.


I still think we may be talking past each other on the issue of LS 
registration vs LS to gLS summarization.  If you would like to include 
more information into your initial CL-MP registration to the LS you can 
of course do it, but this extra information won't propagate worldwide.  
There are a couple of caveats:

1) the structure needs to be normalized so that the summarization is 
effective, e.g. a registered metadata element that should contain a 
subject, eventType(s) and parameters is the basic unit that will be 
summarized.
2) Summarization will only care about certain topological elements in 
the subject, if they are not sent they will not be summarized.
3) The same applies to eventTypes.
4) Parameters will not be considered in the summarization step, but they 
still can reside in the LS.

The gLS instances will consume this summary (as described in the 
document) as these were decided to be the most tangible units that allow 
discovery in the framework.  At a minimum to find a service of interest 
comes down to needing to know:

1) what the service offers in the way of data (i.e. I want ping data, i 
dont care where it is)
2) What domains the service may have data for (i.e. I only want data 
from utk.edu)
3) What ip ranges the service may have data for (i.e. I only want data 
from 128.4.175.0/24)
4) Combinations of the previous 3 (i.e. ping data for 128.4.175.0/24)

While knowing the AA status or items like count are useful locally, 
consuming various parameters at the upper level doesn't really buy much: 
discovery should tell you where to look only not offer a verbatim list 
of what is available below (this defeats the purpose of calling it a 
'summary' instead of just replicating all info).

I hope this helps.

-jason


> > 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).
> >
> > 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.