Difference between revisions of "GOCDB Regionalisation Plans"
Line 10: | Line 10: | ||
* Confirmed Development | * Confirmed Development | ||
We will continue to release a regional instance of the GOCDB. This regional instance will be supported regardless of other developments. | We will continue to release a regional instance of the GOCDB. This regional instance will be supported regardless of other developments. | ||
We will ensure that future developments don't conflict with requirements from NGIs by capturing the NGIs requirements. | |||
Use Cases | Use Cases | ||
Line 19: | Line 21: | ||
One potential long term goal for GOCDB is to synchronise regional GOCDB data to the central instance. | One potential long term goal for GOCDB is to synchronise regional GOCDB data to the central instance. | ||
This would allow NGIs to deploy their own GOCDB, customise it | This would allow NGIs to deploy their own GOCDB, customise it and publish data to the central portal. The central portal would be the definitive source for all GOCDB information. | ||
It may be necessary to have two way synchronisation (where the central instance updates the regional instances) in order to solve this ticket: https://rt.egi.eu/rt/Ticket/Display.html?id=1094. | |||
Use Cases | Use Cases | ||
Line 25: | Line 29: | ||
* EGI data published to the central GOCDB | * EGI data published to the central GOCDB | ||
* User visits one portal to input both EGI and non-EGI data | * User visits one portal to input both EGI and non-EGI data | ||
* Central operators can override regional GOCDBs data (for https://rt.egi.eu/rt/Ticket/Display.html?id=1094) | |||
== Central Customisations == | == Central Customisations == | ||
* Potential Development | * Potential Development | ||
One potential development is implementing | One potential development is implementing regional customisations centrally. The customisations would be visible only to specified NGIs through the grouping tools developed in "Separate EGI and Non-EGI Data". | ||
This plan is preferable if the effort to implement NGI customisation requests is less than the effort to develop and support a synchronisation mechanism and support the NGIs in implementing the customisations themselves. | This plan is preferable if the effort to implement NGI customisation requests is less than the effort to develop and support a synchronisation mechanism and support the NGIs in implementing the customisations themselves. |
Revision as of 17:36, 4 March 2011
Regionalisation Plans
Introduction
Our future plans for regionalisation are described here. To see our cur current regionalisation status please visit GOCDB4 Regionalisation Status.
Separate EGI and Non-EGI Data
- Confirmed Development
A GOCDB instance needs to differentiate between EGI and non-EGI data. A new group named EGI will be created along with tools to insert / remove data to and from a specified group. With this functionality in place NGIs will be able to store and retrieve both local and EGI level sites in the central GOCDB. (This plan is from "Design A" in https://rt.egi.eu/rt/Ticket/Display.html?id=943#txn-52051).
Regional GOCDB
- Confirmed Development
We will continue to release a regional instance of the GOCDB. This regional instance will be supported regardless of other developments.
We will ensure that future developments don't conflict with requirements from NGIs by capturing the NGIs requirements.
Use Cases
- Customisable by NGIs
- Support available centrally
Regional/Central Synchronisation
- Potential Development
One potential long term goal for GOCDB is to synchronise regional GOCDB data to the central instance.
This would allow NGIs to deploy their own GOCDB, customise it and publish data to the central portal. The central portal would be the definitive source for all GOCDB information.
It may be necessary to have two way synchronisation (where the central instance updates the regional instances) in order to solve this ticket: https://rt.egi.eu/rt/Ticket/Display.html?id=1094.
Use Cases
- NGIs customise their own GOCDB
- EGI data published to the central GOCDB
- User visits one portal to input both EGI and non-EGI data
- Central operators can override regional GOCDBs data (for https://rt.egi.eu/rt/Ticket/Display.html?id=1094)
Central Customisations
- Potential Development
One potential development is implementing regional customisations centrally. The customisations would be visible only to specified NGIs through the grouping tools developed in "Separate EGI and Non-EGI Data".
This plan is preferable if the effort to implement NGI customisation requests is less than the effort to develop and support a synchronisation mechanism and support the NGIs in implementing the customisations themselves.
A regional non-synchronising GOCDB would still be available for NGIs with esoteric requirements.
Use Cases
- NGIs can specify custom functionality
- Custom functionality can be shared
- User visits one portal to input both EGI and non-EGI data
- NGIs don't need to provide GOCDB effort