Regionalized GOCDB use cases
|Main||EGI.eu operations services||Support||Documentation||Tools||Activities||Performance||Technology||Catch-all Services||Resource Allocation||Security|
Current status of regionalization
Currently there is a regionalized installation for GOCDB, but it is a stand-alone instance. It is not possible to automatically synchronize the data in the local installation with the central one. Please see: https://wiki.egi.eu/wiki/GOCDB_Regionalisation_Plans
- The main regionalization use cases for GOCDB are documented under the appropriate development plan at:
- Please add extra use-cases that are not covered by these plans below.
Use case #1
Hierarchical arquitecture for GOCDB
(Please see 'Regional-Synchronised GOCDB' at: https://wiki.egi.eu/wiki/GOCDB_Regionalisation_Plans#3.29_Regional-Synchronised_GOCDB )
Use case description
NGIs could benefit from a GOCDB hierarchical arquitecture with two layers: regional GOCDBs populating the bottom layer, and the EGI central GOCDB installation populating the top layer. Information would flow from the bottom layer to the top layer, with the possibility to filter data when sending to upper level.
This setup would allow the introduction of local sites in the regional infrastructure (regional nagios and the regional dashboard) without propagating that local site information to EGI and beyond the NGI scope.
(Note: Sorry, I didn't understood if the following scenario is completly absorbed in the GOCDB Regionalisation Plans. Therefore, I stated here once again)
- Yes - i think it does.
Dependencies with other regionalized tools
- The regional nagios and the regional dashboards would have to consolidate information based on what is available on the regional GOCDB. Since regional Nagios are now using ATP, probably an ATP regional view should be available also.
- ActiveMQ message chain would have to be done from regional nagios to regional dashboards.
For other use cases, please see: https://wiki.egi.eu/wiki/GOCDB_Regionalisation_Plans