perfsonar development work

[Nicolas Simar <>]

Hi,

I renamed this thread as it is not about schema version. I summarise the 
information seen on the mailing list.

1. What is the problem

The schema (protocol?) evolves over time. The deployment of services by 
the networks operators don't always follow this evolution. The 
visualisation tools are ending-up having to deal with hard-coding a tool 
deployed and the schema used.
(Temporary measure exist to give some information through the URL, but 
not for all the services).

2. Solutions

2.1. Protocol extension (as already proposed by Jeff) to support picking 
up of protocol version(s) supported.

2.2. Have the web-services URL containing the product or protocol 
version number.


3. Benefits

3.1 Protocol Extension
This would allow the visualisation client to deal with protocol 
versioning automatically.
- PerfsonarUI will be able to abandon MA.conf (combined with the 
deployment of the distributed LS).
- the web-services could adapt their answer with the client or the other 
web-service version (useful as the protocol evolves and the products 
might not deployed as frequently).

This is an assumption: do you validate it???

- Other benefits examples???


3.2. URL containing the (protocol/schema) version number.
It is a temporary hack to provide the information (actually, the hack is 
to provide the web-service version number).
Ideally, the URL should not change over time for a deployed instance (so 
that static configuration files don't have to be change by the users 
each time there is a service upgrade).
However
(a) the web-service name might change over time (for what reasons?),
(b) it is expected to use the LS to be communicated the URL when some 
data are needed (thus the URL could change over time).
But we should maybe not expect all the visualisation clients to rely on 
the LS (no case known to me so far though) and try not to have too 
"dynamic" service URLs (thus removing the product version number isn't a 
solution).

3.3. One could expect that within a year or two, all the deployed 
instances would have moved towards a newer web-service version (with 
protocol information included). Combined with the distributed LS, it 
would imply that the visualisation client wouldn't need static files 
anymore (which doesn't mean that all of them would abandon the static 
files).

5. Question

- Do we want to have a versioning for the schema or for the protocol 
(yet currently undefined, but in the process to)?

- Where shall this information be located?
In any messages exchanged? Only in the messages sent by the LS? In a new 
type of message sent by any web-service when requested?

- What impact will it have on the web-services?

- Jeff, can you re-sent your proposal for adding versioning? I don't 
remember in which thread it was sent.


Cheers,
Nicolas

Roman Łapacz wrote:
> Nina Jeliazkova napisał(a):
>
> > Hi all,
> >
> >   
>
> Hi
>
> > I fully support Loukik message, that ideally, the protocol should be
> > responsible to reveal versioning information.   
>
> In the comming release of rrd ma you will find new type of request 
> LookupInfoRequest/Response which help you in getting general service 
> information (including service version number; we could add protocol 
> version to this set as well). The implementation of this message type is 
> located in the base so each service can have it.
>
> Take a look at the documantation of it:
> https://svn.perfsonar.net/svn/perfsonar/tags/GEANT2-JAVA-RRD-MA-2.3-RC4/doc/Interface_Specification.doc 
>
>
> Of course I also support the idea of having protocol version inside 
> requests which could instruct services how to answer (what protocol 
> implemetation to use)
>
> Roman
>
>
> > Regarding perfsonarUI, the lack of such information so far led to 
> > introduction
> > of "supported schema" field in MA.conf. One of the factors delaying 
> > abandoning
> > MA.conf in favor of lookup service, is that after such transition, the 
> > version
> > information will be lost.
> > I see versioning in URL as a temporary workaround, to become 
> > irrelevant when
> > the protocol is updated to support versioning.
> >
> > Best regards,
> > Nina
> >
> >
> > Loukik Kudarimoti 
> > <>
> >  wrote:
> >
> >  
> >
> > > Nicolas,
> > >
> > > The lack of protocol versioning and a method to discover supported 
> > > protocols required us to make this choice.
> > >
> > > Without such versioning in the URL, its difficult to know which 
> > > version of software has been installed. If the protocol can be 
> > > extended (as already proposed by Jeff) to support picking up of 
> > > protocol version(s) supported, this can be safely removed. Ideally, 
> > > this protocol should also help in picking up the version of software 
> > > deployed.
> > >
> > > regards,
> > > Loukik.
> > >
> > > Nicolas Simar wrote:
> > >    
> > >
> > > > Hi Loukik, Michalis
> > > >
> > > > Can you tell about the rationale for having the release version name?
> > > >
> > > > Hi Nina and Andreas,
> > > >
> > > > Would you prefer to limit the URL changes of the web-services or do 
> > > > you prefer to have the product version in the URL?
> > > >
> > > > Cheers,
> > > > Nicolas
> > > >
> > > > Maciej Glowiak wrote:
> > > >      
> > > >
> > > > > Nicolas Simar wrote:
> > > > >
> > > > >        
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > looking at the web-services names
> > > > > >
> > > > > >           
> >
> > http://rrd-ma.perfsonar.xxx:8080/perfSONAR-RRD-MA-2.2/services/MeasurementArchiveService 
> >
> >  
> >
> > > > > > I see there is a part mentioning the service version(2.2). Is there a
> > > > > > particular benefit of seeing the service version?
> > > > > >
> > > > > > I am wondering about this, because when the service will be 
> > > > > > updated, the
> > > > > > version will be updated and the tools won't be able to access it 
> > > > > > until
> > > > > > they are updated.
> > > > > > It this statement correct?
> > > > > >           
> > > > >
> > > > >
> > > > > Nicolas,
> > > > >
> > > > > AFAIR it was a requirement from Release Mgmt. Team for perfSONAR 2.0.
> > > > > You should contact Loukik or Luis in order to get more information 
> > > > > about
> > > > > the reason for using version number.
> > > > >
> > > > > Anyway, Ilias and Roman are right - that's default name (contaning
> > > > > version number) and everybody can change it after the installation.
> > > > >
> > > > >         
> > > >
> > > >
> > > >
> > > >       
> >
> >
> >
> >
> >   

--
Nicolas
______________________________________________________________________

Nicolas Simar
Network Engineer

DANTE - www.dante.net

Tel - BE: +32 (0) 4 366 93 49
Tel - UK: +44 (0)1223 371 300
Mobile: +44 (0) 7740 176 883

City House, 126-130 Hills Road
Cambridge CB2 1PQ
UK
_____________________________________________________________________