Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "GOCDB Regionalisation Plans"

From EGIWiki
Jump to navigation Jump to search
 
(20 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Template:Op menubar}}
{{Template:GOCDB_menubar}}
{{TOC_right}}
[[Category:GOCDB]]
= Regionalisation Plans =
= Regionalisation Plans =
== Introduction ==
== Introduction ==
Our future plans for regionalisation are described here. To see our cur current regionalisation status please visit [[GOCDB/Release4/Regionalisation | GOCDB4 Regionalisation Status]].
Our future plans for regionalisation are described here. To see our cur current regionalisation status please visit [[GOCDB/Release4/Regionalisation | GOCDB4 Regionalisation Status]].
In order to achieve a [[#3) Regional-Synchronised GOCDB]] stages 1) and 2) are both required first. 


== Separate EGI and Non-EGI Data (Data Grouping/Scoping) ==
 
== 1) Data Grouping/Scoping ==
'''(Separate EGI and Non-EGI Data)'''
* Confirmed Development
* 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).
A GOCDB instance (whether central or regional) 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).


'''Notes:'''
'''Notes:'''
* This will require GUI enhancements, allowing sites to opt-in or opt-out of the EGI group, and new request parameters for restricting the PI queries based on group memberships (e.g. “method=get_site_list_by_group&group=EGI” or “&group=local” or “&group=any”).
* This will require GUI enhancements, allowing sites to opt-in or opt-out of the EGI group, and new request parameters for restricting the PI queries based on group memberships (e.g. “method=get_site_list_by_group&group=EGI” or “&group=local” or “&group=any”).
* This development is a pre-requisite in order to subsequently publish the appropriate data for [[#Regional<-->Central Synchronisation]].  
* This development is a pre-requisite in order to publish the appropriate data for: [[#3) Regional-Synchronised GOCDB]].  


'''Use Cases:'''
'''Use Cases:'''
Line 16: Line 23:
* Regional GOCDB installation not required (e.g. for NGIs without effort to install/maintain a regional gocdb).
* Regional GOCDB installation not required (e.g. for NGIs without effort to install/maintain a regional gocdb).


== Regional GOCDB (Standalone) ==
 
 
== 2) Regional-Standalone GOCDB ==
* Confirmed Development
* Confirmed Development
We will continue to release a standalone instance of the GOCDB for regional NGI use. 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.
We will continue to release a standalone instance of the GOCDB for regional NGI use. 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:'''
* Customisable by NGIs
* NGIs can fully customise their own GOCDB as required (e.g. extend DDL/GUI/logic/SQL/whatever)
* Support available centrally
* Support available centrally


== Regional<-->Central Synchronisation ==
 
* Potential Development
== 3) Regional-Synchronised GOCDB ==
One potential long term goal for GOCDB is to synchronise regional data with the central instance.
* Long Term Development
A regional-standalone GOCDB instance will synchronise is EGI scoped regional data with the central instance.


This would allow NGIs to deploy their own GOCDB, customise it and publish EGI data (constrained by XML schema) to the central portal. Publishing of this data would have to be transactional, most probably via a schema constrained WS/REST interface (preferable over asynch messaging which would require response queues + ACKs). The central portal would be the definitive source for all EGI information.
This would allow NGIs to deploy their own GOCDB, customise it and publish EGI data (constrained by XML schema) to the central portal. Publishing of this data would have to be transactional, most probably via a schema constrained WS/REST interface (preferable over asynch messaging which would require response queues + ACKs). The central portal would be the definitive source for all EGI information.
Line 32: Line 42:
'''Notes:'''
'''Notes:'''
* It may be necessary to have two-way synchronisation, where the central instance would also update regional instances: https://rt.egi.eu/rt/Ticket/Display.html?id=1094.
* It may be necessary to have two-way synchronisation, where the central instance would also update regional instances: https://rt.egi.eu/rt/Ticket/Display.html?id=1094.
* NGI extensions and ''custom data would not be synchronized'' with the central GOCDB, therefore;
* NGI extensions and ''custom data would not be synchronised'' with the central GOCDB, therefore;
* [[#Separate EGI and Non-EGI Data (Data Grouping/Scoping)]] is necessary in order to publish the appropriate data.  
* [[#1) Data Grouping/Scoping]] is necessary in order to publish the appropriate data.  


'''Use Cases:'''
'''Use Cases:'''
* NGIs customise their own GOCDB
* NGIs can '''extend''' their own GOCDB as required (e.g. extend DDL/GUI/logic/SQL)
** (note, these customizations should extend gocdb, leaving the core tables/queries/schema in tact in order to synchronize the core EGI data, e.g. custom data should be defined in a different table space). 
* Single access point to input both EGI and non-EGI data, and query data.  
* Single access point to input both EGI and non-EGI data, and query data.  
* Central operators would need to override data published by regional GOCDBs (for https://rt.egi.eu/rt/Ticket/Display.html?id=1094)
* Central operators would need to override data published by regional GOCDBs (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
* Customisations sharing
* User visits one portal to input both EGI and non-EGI data
* NGIs don't need to provide GOCDB effort

Latest revision as of 12:23, 18 December 2012

Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security


GOC DB menu: Home Documentation Index


Regionalisation Plans

Introduction

Our future plans for regionalisation are described here. To see our cur current regionalisation status please visit GOCDB4 Regionalisation Status. In order to achieve a #3) Regional-Synchronised GOCDB stages 1) and 2) are both required first.


1) Data Grouping/Scoping

(Separate EGI and Non-EGI Data)

  • Confirmed Development

A GOCDB instance (whether central or regional) 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).

Notes:

  • This will require GUI enhancements, allowing sites to opt-in or opt-out of the EGI group, and new request parameters for restricting the PI queries based on group memberships (e.g. “method=get_site_list_by_group&group=EGI” or “&group=local” or “&group=any”).
  • This development is a pre-requisite in order to publish the appropriate data for: #3) Regional-Synchronised GOCDB.

Use Cases:

  • Users can centrally include/exclude sites/SEs from the from the whole EGI infrastructure as required (provides extensible data visibility/scoping according to groupings).
  • Single point to input/query data for EGI and local/regional data.
  • Regional GOCDB installation not required (e.g. for NGIs without effort to install/maintain a regional gocdb).


2) Regional-Standalone GOCDB

  • Confirmed Development

We will continue to release a standalone instance of the GOCDB for regional NGI use. 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:

  • NGIs can fully customise their own GOCDB as required (e.g. extend DDL/GUI/logic/SQL/whatever)
  • Support available centrally


3) Regional-Synchronised GOCDB

  • Long Term Development

A regional-standalone GOCDB instance will synchronise is EGI scoped regional data with the central instance.

This would allow NGIs to deploy their own GOCDB, customise it and publish EGI data (constrained by XML schema) to the central portal. Publishing of this data would have to be transactional, most probably via a schema constrained WS/REST interface (preferable over asynch messaging which would require response queues + ACKs). The central portal would be the definitive source for all EGI information.

Notes:

Use Cases:

  • NGIs can extend their own GOCDB as required (e.g. extend DDL/GUI/logic/SQL)
    • (note, these customizations should extend gocdb, leaving the core tables/queries/schema in tact in order to synchronize the core EGI data, e.g. custom data should be defined in a different table space).
  • Single access point to input both EGI and non-EGI data, and query data.
  • Central operators would need to override data published by regional GOCDBs (for https://rt.egi.eu/rt/Ticket/Display.html?id=1094)