perfsonar development work

[Fausto Vetter <>]

Hi,

Additional service will go beyond to retrieve information. The main idea 
is being able to configure multiple services based on templates. In a 
domain, it is possible to exist multiple MPs that share similar politics 
and rights upon it.

For example: bwctl. Probably Administrator will say: well I want only to 
permit bwctl UDP tests for no more than 30 seconds among exclusively the 
MPs in my domain. Well, if another BWCTL MP is installed in the domain, 
what are the administrator steps to apply its politics to this new MP? 
Well, he/she would need to go all other MPs and add this new MP to the 
rules file. And also configure the politics to this new MP.

What would it happen in this new service? Well, MP would register itself 
in a bwctl IS, it would receive politics from IS and IS would update 
automatically all others MPs rules in domain of interest.

Well, and about security? well, it might be done based on manager of a 
domain that is permitted to add this kind of service on a domain or 
other rules. We should think better about it.

The whole point is: you would have a central point where you could 
control services on your domain and any change could be done on there. 
Also, static Resource Protection could be done on there. Once info is 
there, you could then retrieve this info for other purposes when needed.

The reason to have this kind of service is that sometimes it is 
difficult to keep rules updated everytime a new service goes up or down, 
once most of the times services will be sharing similar rules. It can be 
compared as a DHCP server for a domain, from where host receive  network 
basic configuration.  But in our case, configuration would be about the 
domain of interest.

does anyone checked the purpose? any comments?

does it make sense?

Bye,
Fausto

Nina Jeliazkova wrote:

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