perfsonar development work

["Nina Jeliazkova" <>]

Hi Maciej,

Maciej Glowiak 
<>
 wrote:

> Hi Nina,
> 
> I have been thinking on all of these issues for a long time :)

well, perhaps we could involve more thinkers and eventually come at some
solution :)

> 
> Nina Jeliazkova wrote:
> > Hello all,
> > 
> > Trying to use lookup service in PerfsonarUI, here is what is not clear to
> me:
> > 
> > 1) Is it mandatory for a service to register information other than pure
> > information about service (URL, name), e.g. interfaces?
> 
> No. It's undefined in fact. We defined a couple of attributes such as 
> name, URL, description and type. There are now some other fields 
> (organization, administrator, etc.). But data elements may contain 
> anything. Now, for MA services we publish all interfaces, but using 
> multi LS there may be aggregated data. That's quite a big problem for 
> client applications because it should know what may be found inside 
> service response. So, there is no good answer for your question. You may 
> make use of data elements inside Lookup Information, but it is still not 
> mandatory information.
> 


OK. It's not that bad, since list of interfaces, etc. can still be retrieved
by Metadata query directly from the service.


> > 2)Is there any way to discover schema supported by the service (for
> > PerfsonarUI to provide backward compatibility, like current MA.conf
> settings).
> >  I understood supported event type can be figured out from interfaces
> > registration, but what about services that don't register these?
> Additionally,
> > is it possible for interfaces within same service to support different
event
> > types?
> 
> No. I was thinking on adding attribute to metadata element, such as 
> schema-version or something like that (at least service version).
> 


I would greatly appreciate exposing some information about the supported
schema. Otherwise, PerfsonarUI will provide some defaults (e.g. latest
supported schema), but that may not be failsafe.

Theoretically, this info could come from WSDL, but having a look at 

http://selena.acad.bg:8080/axis/services/MeasurementArchiveService?wsdl 
and
http://stats.geant2.net/perfsonar/RRDMA-access/MeasurementArchiveService?wsdl

will not reveal any difference, although the first one is perfsonar 1.0 and
the second is perfsonar 2.0 service. Any comments?


> > 3)Is there a way to distinguish between different types of MA services
(e.g.
> > utilization MA service and Hades service). I saw a suggestion to have
> subType
> > parameter, but not sure it is implemented already or if it will be
> mandatory.
> 
> It's not implemented. There were two solutions: subtype vs. hierarchy of 
> types. For example:
> 
>     <type>MA</type>
>     <subtype>RRD</subtype>
> 
> vs.
> 
>     <type>ma.rrd</type>
> 
> Another concern is that RRD or SQL are actually not MA types. They're 
> implementation type, but the real type is "utilization" or "path 
> status". Maybe there should be supportedEventTypes? I am not sure what 
> is the status of the implementation / usage of them.
> 

I would indeed prefer subtypes to encode information directly reflecting what
kind of messages are accepted by the service (e.g. schema, and eventtypes are
part of the schema anyway). The client might not even want to distinguish
between RRD and SQL MA as long as both understand the same messages. 

At the same time HADES service is MA service, but provides information about
IP pairs, not individual interfaces and therefore messages are different. A
workaround (as discussed some time ago with Verena) is to rely on some naming
scheme, specific to Hades, which is feasible, but not a generic approach.


> > 4)For PerfsonarUI what will be the best approach - contact single
> > preconfigured LS, or have a list of LS to send queries? 
> 
> Hmm. I'd have the list of several LS-es (but not too many) and first 
> send a request to one LS, then if there is no requested data, I'd send 
> the request to others... But one LS is also fine.
> 
> > I am aware these points have already been discussed, but not sure there is
a
> > definite answer or it could be it is already explained in some
documentation
> > I've missed.
> 
> They were discussed several times, but still without strong conclusions.
> 
> We should finalize the discussion on all of these topics.
> 

Yes, definitely.

Regards,
Nina