perfsonar development work

["Jeff W. Boote" <>]

Maciej Glowiak wrote:
> 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.

I agree. We should probably start collecting issues such as these on the wiki 
and still have at least a monthly call to discuss and agree to them. (With 
appropriate discussion via email of course.)

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

Each service will have it's own list of supportedEventTypes. And each of them 
will be providing different data. It makes sense that a client will need to know 
something about the specific type of data to actually make use of that data.

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

EventTypes should be named with a full URI name. That name includes the version. 
I don't think it is a good idea to add another place for version.

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

I agree with the supportedEventTypes. (In fact, I was thinking it was already 
there.) This will tell you better than anything else what a service is prepared 
to do for you.

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

I think it is important that clients be able to tell what a service is prepared 
to support. I don't actually have much of an opinion on the wsdl. I think quite 
often we will not need to update the wsdl based on new functionality being 
available due to the doc-lit nature of our services. Most new functionality will 
not require a change in syntax - just semantics. I realize that some of the 
semantics can be represented in the wsdl, but it seems much more tuned to syntax 
to me. So, something additional is needed to represent that additional 
functionality that is available. I think a list of supportedEventType's could be 
enough.

jeff