Difference between revisions of "GOCDB/Release4/Regionalisation/Data Scoping"

From EGIWiki
Jump to: navigation, search
Line 1: Line 1:
{{Template:Op menubar}}
Back to [[GOCDB/Documentation_Index]] <br/>
Back to [[GOCDB/Release4/Regionalisation]] <br/>
Back to [[GOCDB/Release4/Regionalisation]] <br/>
= <span lang="EN-GB">Data Scoping</span> =
= <span lang="EN-GB">Data Scoping</span> =

Latest revision as of 13:32, 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

Back to GOCDB/Release4/Regionalisation

Data Scoping

GOCDB uses a tagging system to mark data within a particular scope. This tagging system allows other types of tags to be defined in future. These other tags can be used by NGIs wishing to customise their own GOCDB instance.

Underlying Implementation

A PROM class called Tag links to sites, service endpoints, downtimes. An example instance of this tag class includes 'EGI'. If a site, SE or downtime has a PROM link to the EGI 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 Central/Regional gocdb usage
EGI Centrally recognized tag. Data with this tag is globally available to the EGI and constitutes EGI data Used in central and regional GOCDBs
Local Centrally recognized tag used for a) declaring local/regional data directly in the central instance that are out of the EGI scope, b) publishing regional gocdb data to the central instance that should remain out of EGI scope (if there is a use case for this) Used in central and regional GOCDBs
NGI_LOCAL (or any proprietary tag name) Not Centrally recognized. Used only in a regional instance - Data with proprietary tags are masked from EGI since they would never be queried by the central services and is not published to the central gocdb. The tag name and the tagged data can be freely customised by the NGI Used in regional GOCDB only

  • 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' and 'NGI_LOCAL' tags in a regional gocdb, that object will still be selected by queries that request the EGI scoped data (the object would need to be explicitly un-linked from the EGI tag).
  • Only the admins of the particular GOCDB instance will be able to create/delete tags.
  • Central gocdb admins declare centrally supported tags such as ‘EGI’(potentially others also for special grouping purposes in required). When publishing data from a regional to the central gocdb, only those objects tagged with centrally supported tags will be propagated (since the central gocdb will query each regional gocdb using those tags). This would require a regional instance to declare the same 'EGI' tag (xsd:enum validation), 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 such as adding a tick box to (de)assign the EGI tag).
  • The 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' 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


  • 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.