perfsonar development work

[Maciej Glowiak <>]

Nina Jeliazkova wrote:
> 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 :)

Yes, definitely. He have discussed most of these topics (as you said 
before) several times, but we didn't decide how to solve these problems.

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

Yes, but not all services support such functionality.


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

OK, I think it's good idea to add schema-version (or schemaVersion) tag 
inside metadata/subject/service)


> 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?

AFAIR we didn't change anything in wsdl files between pS 1 and pS 2. 
They're exactly the same files.

> > > 3)Is there a way to distinguish between different types of MA services
> (e.g.
> > (...)
> > 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.

For me both approaches are ok. But, as I mentioned before, we probably 
should add supportedEventTypes - for instance SQL MA supports two 
metrics: path status and utilization, bo there should be two 
supportedEventTypes. That's the same as "subtype", and I think we 
shouldn't add fields describing the same information.

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

So, what others think on that?

Maciej