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.

GOCDB/Release4/Regionalisation/Data Scoping

From EGIWiki
Jump to navigation Jump to search

Back to GOCDB/Documentation_Index
Back to GOCDB/Release4/Regionalisation

Data Scoping

To mark data within GOCDB as EGI data a new tagging system will be implemented. Such a tagging system will allow other types of tags to be defined in future. These other tags can be used by NGIs wishing to customise their GOCDB instance.

Underlying Implementation

A new PROM class called Tag will be introduced that can be linked to sites, service endpoints, downtimes, users and user roles. We will create an instance of this tag class called 'EGI.EU'. If a site, SE, downtime, user or user role has a PROM link to the EGI.EU tag then the object will be exposed to the EGI infrastructure through the PI. If such an object isn’t tagged it won’t be exposed to the production infrastructure.

GOCDB Tag Entities:

Value Description Notes
EGI.EU Data with this tag is globally available to the EGI and constitutes EGI data Used in central and regional GOCDBs
REGIONAL.PUBLISHED Tag denotes: a) Regional data in the central instance that are out of the EGI.EU scope b) Data residing in a regional gocdb that should be published to the central but should remain out of EGI.EU scope Used in central and regional GOCDBs
REGIONAL.PRIVATE Regional only tag - Data with this tag is masked from EGI Used in regional GOCDB only


  • This will require GUI enhancements, allowing users to associate tags with gocdb objects, and new request parameters for restricting the PI queries based on tag associations.
  • Tagging is a prerequisite for a regional gocdb so that only the appropriate data can be published to a central instance.
  • Tags are not mutually exclusive. For example, if an object is tagged with both the 'EGI.EU' and 'REGIONAL.PRIVATE' tags in a regional gocdb, that object will still be selected by queries that request the EGI.EU scoped data (the object would need to be explicitly un-linked from the EGI.EU tag).
  • Only the admins of the particular GOCDB instance will be able to create/delete tags.
  • Central gocdb admins will declare centrally supported tags such as ‘EGI.EU’(potentially others also for special grouping purposes). When publishing data from a regional to the central gocdb, only those objects tagged with centrally supported tags will be propagated (xsd:enum validation). This would require a regional instance to declare the same 'EGI.EU' tag, but from an underlying implementation perspective, there is no special meaning given to different tags (of course, GUI can/will emphasize particular tags as required).
  • Centrally supported tags will be deployed as a regional configuration default.
  • A regional PI would be the same as the central PI (just potentially with different supported tag values).
  • Tags can only be added / removed by gocdb admins and users can choose to (un)link their data with the available tag.
  • By default, tags that are linked to a parent object will also be linked to that object's children when creating the object (i.e. cascading the same tags to child objects). For example, when adding a new SE to a site, the site's tags are also linked to the SE object. However, the user can always make subsequent modifications if required (e.g. un-link the SE's 'EGI.EU tag' to exclude the SE from the EGI scoped data).
  • There is a Many-to-Many relationship between 'tag' object and data objects (producing few tag instances, but many links to tags). A single data object can be linked to multiple (parent) tags while an individual tag can link to many (child) objects (site, SE, downtime, user).
  • In the relationship between Tags and gocdb data entities, Tag is always the parent of the data objects for permissions reasons, e.g. we want users to be able to (un)link to existing tags, but not be able to edit tags.

Scoping Rules

An EGI child must have an EGI parent (e.g. an EGI SE must have a parent EGI site, an EGI role must have a parent EGI user etc).

User Interface

DataScopingUI.PNG

  • Add a tick box to each affected data type (sites, service endpoints, downtimes, users and user roles) on the add and edit forms.
  • The question mark button will lead to a page explaining that marking data as EGI will send that data to the central GOCDB portal
  • The user interface should enforce the scoping rules set out above (EGI child must have EGI parent)
  • The UI should also automatically de/select the EGI tick box for new objects depending on whether their parents are EGI objects.
    • For example, when adding a new service endpoint to an EGI site the EGI box in the Add New Service Endpoint form should be ticked by default.
    • Similarly if a downtime is to be added to a set of non-EGI service endpoints the EGI box shouldn’t be ticked by default.
  • Change Browse Sites in the left hand menu to Browse EGI sites
  • Add a new link to Browse Local Sites. This will also need a help button by it explaining the difference.
  • When viewing an object (site, SE, downtime, user, role) it should be clear that the object is local-only.
  • Site/SE etc. page titles will change to Local Site / Local SE etc
  • Consider changing the colour of the headings on the page.
    • This could be accompanied with a "Why is this page blue?" link.
  • For each table (e.g. list of service endpoints in a site) add a EGI or Local column with a colourful icon
  • Search results will include a separate section for local objects.