perfsonar development work

["Nina Jeliazkova" <>]

Hi,

What will be the added value of an additional service to retrieve additional
(e.g. interface) information, rather than querying the measurement acrhive or
measurement point with specific type of messages?  

Regards,
Nina

Fausto Vetter 
<>
 wrote:

> Hi,
> 
> My opinion, as a propose to handle non-mandatory data on LS, is that it 
> could be solved using information service proposed by myself on the 
> list. LS should just care about a static list of variables that are 
> common to find services. For all other, e.g. interface information, 
> could be handled by specialized IS (information service) managers, so LS 
> is concise to its purpose, that is to find services.
> 
> For example: One domain would have at least a LS and a IS for each 
> metric it is measuring. So LS would store the list of all Services. And, 
> for:
> - interface information: ISInterface
> - owamp data: ISOwamp
> - bwctl: ISBwctl
> - so on...
> 
> In this way, you exactly know what kind of data client should expect be 
> talking to each IS specific service.
> 
> If client want to know interfaces that a domain has, it would:
> - client request IS of the type to LS
> - LS should respond to the corresponding IS
> - client talk with corresponding IS
> 
> OR
> 
> - client request interface info to LS
> - LS find in its list which is the corresponding IS it has this information
> - LS contacts IS Interfaces
> - IS responds info to LS
> - LS responds to client
> 
> What are your opinions about it?
> 
> Thanks,
> Fausto
> 
> Jeff W. Boote wrote:
> 
> > 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
> 
>