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/Release4/Regionalisation/Data Scoping"

From EGIWiki
Jump to navigation Jump to search
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Back to [[GOCDB/Documentation_Index]] <br/>
{{Template:Op menubar}}
{{Template:GOCDB_menubar}}
{{TOC_right}}
[[Category:GOCDB]]
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> =


<span lang="EN-GB">To mark data within GOCDB as EGI data a new
<span lang="EN-GB">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
tagging system will be implemented. Such a tagging system will allow other
wishing to customise their own GOCDB instance.  
types of tags to be defined in future. These other tags can be used by NGIs
wishing to customise their GOCDB instance.  
<br/>
<br/>
* [[GOCDB/Release4/Regionalisation#1.29_Data_Tagging.2FScoping]] provides the tagging/scoping use-cases
* [[GOCDB/Release4/Regionalisation#1.29_Data_Tagging.2FScoping]] provides the tagging/scoping use-cases
Line 13: Line 14:
= <span lang="EN-GB">Underlying Implementation</span>  =
= <span lang="EN-GB">Underlying Implementation</span>  =


<span lang="EN-GB">A new PROM class called Tag will be
<span lang="EN-GB">A PROM class called Tag  
introduced that can be linked to sites, service endpoints, downtimes, users and
links to <u>sites, service endpoints, downtimes</u>. An example instance of this tag class includes 'EGI'.  
user roles. We will create an instance of this tag class called 'EGI.EU'.  
If a site, SE or downtime has a PROM link to the EGI tag then the object
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
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.  
isn’t tagged it won’t be exposed to the production infrastructure.  
Line 24: Line 24:
GOCDB Tag Entities:  
GOCDB Tag Entities:  
{| {{egi-table}}  
{| {{egi-table}}  
! Value !! Description !! Central/Regional gocdb usage|-
! Value !! Description !! Central/Regional gocdb usage
|EGI.EU || Centrally recognized tag. Data with this tag is globally available to the EGI and constitutes EGI data || Used in central and regional GOCDBs
|-
|-
|REGIONAL|| Centrally recognized tag used for declaring local/regional data in the central instance that are out of the EGI.EU scope (could also be used for publishing regional data to the central instance that should remain out of EGI.EU scope, provided there is a use case for this)|| Used in central and regional GOCDBs
|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 <u>central</u> instance that are out of the EGI scope, b) publishing <u>regional gocdb</u> 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|| Not Centrally recognized. Used only in a regional instance - Data with this tag is masked from EGI and is never 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
|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
|-  
|-  
|}
|}
Line 35: Line 36:




*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.
*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 'NGI_LOCAL' 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).  
*<u>Tags are not mutually exclusive.</u> 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.  
*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, <u>only those objects tagged with centrally supported tags will be propagated (since the central gocdb will query the regional using those tags)</u>. This would <u>require a regional instance to declare the same 'EGI.EU' tag (xsd:enum validation)</u>, 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.EU tag).   
*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, <u>only those objects tagged with centrally supported tags will be propagated (since the central gocdb will query each regional gocdb using those tags)</u>. This would <u>require a regional instance to declare the same 'EGI' tag (xsd:enum validation)</u>, 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 NGI_LOCAL and the centrally supported tags will be deployed as a regional configuration default.   
*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).  
*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.  
*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).  
*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).  
*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.
*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.

Latest revision as of 12: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

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.