perfsonar development work

[Chris Welti <>]

Hi all,

I completely agree with Joe on this.
A single LS would make things a lot easier for end-users.

Regards,
Chris

Joe Metzger wrote:
> Nicolas,
> This approach is unexpected.
> 
> I want all the deployed services to register with a single global LS.
> This will provide a single point for GUI and analysis tools to discover
> all perfSONAR services now.
> 
> The idea is to build the root of the tree first so the user community
> can start using it now, and then build the leaves in a later version
> when the multi-LS functionality is developed, and the size of the global
> perfSONAR deployment scales beyond the capabilities of a single server.
> 
> One reason for deploying a LS at this point is to support the end user
> community by eliminating the requirements for static configuration files
> that will always be incomplete or out of date. Replacing a static list
> of a dozen MA's with a list of a half dozen Lookup services doesn't
> solve the problem.
> 
> Another reason is to try and tie all of the deployments together. We
> don't want to encourage every network to deploy another island. Instead
> we want them to link their deployments together so that everybody
> benefits from each additional deployment.
> 
> 
> I guess there will be more to talk about at the meeting tomorrow than
> I expected.
> 
> --Joe
> 
> 
> 
> 
> Nicolas Simar wrote:
>> Hi all,
>>
>> We had a little brainstorm with Maciej and Vedrin on the Lookup server
>> as input for Thursday discussion.
>>
>> Those are the main points which came out of it:
>>
>> 1) Because of the multi-LS is distributed, we would be better off
>> starting with several LSes rather than a single one. The transition
>> later on would be easier.
>> 2) Because we don't know yet the capabilities of a LS in term of
>> handeling information, it would be best to have several LSes with a
>> different amount of information store on them (variation of number of
>> interfaces and number of services registered at it, this would give us
>> some clues about their capabilities). Vedrin mention that with the
>> current tests he has been doing, he don't expects the LS to be able to
>> support more than few hundreds of interfaces.
>> 3) In ordre to get more feedback on deployed instance of the LS (find
>> bugs, etc) , it would be best to have several NRENs deploying the LS.
>> Three more that currently would be ideal.
>>
>> The suggestion would be to have 5 LS deployed with all the services
>> registering at them. Maciej wrote a quite sensible proposal on how
>> ideally they could group together, allowing us to observe the behavior
>> (see below). Basically, the suggestion would be that all the NRENs
>> within a groups would register their service to a single LS (one of
>> them volunteering to deploy it).
>>
>> My proposal is to install several LSes for:
>>   (institutions, number of interfaces, country/area)
>>
>> (I) North America (2 MAs, 498 interfaces)
>>  - ESNET         415   US
>>  - Internet2      83   US [*]
>>
>> (II) South America (1MA, 63 interfaces)
>>  - RNP            63   Brazil [*]
>>
>> (III) Central Europe (3MA, 24 interfaces)
>>  - PIONIER-RRD    23   Poland [*]
>>  - PIONIER-SQL     1   Poland
>>  - CESNET          -   Czech Rep.
>>
>> (IV) Western Europe (2MAs, 317 interfaces)
>>  - GEANT          45   UK
>>  - SWITCH        272   Switzerland [*]
>>
>> (V)  South-East Europe (6MAs, 201 interfaces)
>>  - GRNET          24   Greece
>>  - CARNET          8   Croatia
>>  - ISTF-J         80   Bulgaria [*]
>>  - ISTF-P         80   Bulgaria
>>  - MREN            2   Serbia and Montenegro
>>  - SEEREN          7   South-East Europe
>>
>> (VI) Nothern Europe (Scandinavia) (1MA, 969 interfaces)
>>  - UNINETT       969   Norway [*]
>>
>> ======
>> Notes:
>> ======
>>
>> 1. [*] are potential places where LSes should/could be deployed
>>
>> 2. Maybe (II)-RNP could be combined with (I)-I2/ESNET? But RNP has
>> already had its own LS. So, it depends on them.
>>
>> 3. PSNC has really small amount of data, and it could be combined with
>> other group, but I it's already been installed and I'd like to have
>> other deployment as well. Moreover, the PSNC LS might be the newest one
>> (I assume it's already been the newest one supporting Result Codes)
>>
>> 4. In the future we can move some interfaces to PSNC from other Lookup
>> Services it the number of interfaces will be growing up in other areas.
>>
>>
>>
>> Maciej and Vedrin mentioned that it would be of value if at least two
>> NRENs could deploy the latest LS as it contains error code. It has
>> also the advantage that developpers of visualisation services can test
>> that feature).
>>
>> It is proposed to:
>>  (I), (II) and probably (VI) be perfSONAR 1.0 LS
>>  (III), (V) and maybe (IV) be perfsonar 1.0a (snapshot on wiki)
>>
>> So an NREN would have the choice between deploying
>> 1. the released LS:
>> - pros: it has been tested and work with the released MA, it is easy
>> to install (installation scripts)
>> - cons: the troubleshooting is more difficult as no errors codes
>> or
>> 2. the latest version of the LS (Maciej to indicate which version so
>> that a single one is used and not four different latest versions)
>> - pros: it contains erros codes which helps the troubleshooting in
>> case of problem.
>>
>> Cheers,
>> Nicolas
>>
>> Eric L. Boyd wrote:
>>> Greetings,
>>>
>>> I'd like to propose a meeting for next week to discover operational
>>> support for perfSONAR discovery requests.
>>>
>>> In effect, we should discuss deploying the centralized lookup server
>>> (v1.0) supported operationally by the project in the short term until
>>> we have working, deployed instances of the Multi-LS.
>>>
>>> I'd like to propose Thursday, July 27, at 10 AM ET.
>>>
>>> I'd like to ensure sufficient critical mass to have this discussion,
>>> so please let me know if you can make it. Otherwise
>>>
>>> --Eric
>>>
>>
> 
> 
> 
>