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 "VT GOCDBExt"

From EGIWiki
Jump to navigation Jump to search
Line 2: Line 2:
<br/>
<br/>
Comming soon.
Comming soon.
==Overview/Motivation==
The project would; A) Extend the current ‘EGI’ and ‘Local’ data scoping logic to introduce multiple, non-exclusive scope tags to encourage other projects to host their data within a single GOCDB instance, and B) Provide a supporting GOCDB management interface to simplify daily operational/admin tasks.
<p>
With these developments, the functionality of GOCDB would be extended beyond the current DoW so that topology data from multiple projects could be more effectively managed using a single GOCDB instance (e.g. EGI, EUDAT, PROJX). A management interface would help simplify and speedup daily operational tasks, especially for new service administrators and will help reduce on-going operational costs for EGI. Non-exclusive scope tags would allow sites/services to be scoped with both project-specific tags (e.g. ‘UK_NES’) and with the wider ‘EGI’ scope tag.
==Technical Outcomes==
===Scoping Extensions===
The current scoping implementation provides only ‘Local’ and ‘EGI’ scopes which are mutually exclusive; a site/service can only be tagged with a single scope. The enhancements will build upon the current data-scoping logic to introduce non-exclusive scope tags. This would allow a single object, such as a site, service, or virtual-site to be tagged by multiple projects. In doing this, a single data object could be defined once and associated with more than one project without duplication of information. This is essential in helping to maintain the integrity of topology information across different target infrastructures.
<p>
* The scoping extension would also introduce new business logic rules. For example, the scopes made available for a ‘Service.Scope' value would be limited to the values listed by the parent 'Site.Scope'. This way, a service scope would be limited to the scopes already defined by the site. A site scope would thus become a union of the child service scopes. This is logical since the owning site is the responsible administrative domain for its child services. For more information see: https://wiki.egi.eu/wiki/GOCDB/Release4/Development/conditionalCertificationStatusRules 
* When querying for data via the PI, the existing ‘scope’ parameter would be extended so that a comma separated list of target scopes could be specified. For example ‘get_sites?scope=EGI,EUDAT,PROJX’ and ‘get_service_endpoints?scope=EGI, PROJX’ . The PI results would then be restricted to show only those entities that define the requested scope.
* The GOCDB configuration file would be extended to add optional default scope declarations. These default scopes could be used to restrict the query results when no PI scope is explicitly requested. This is necessary to maintain the current (hard-wired) behaviour of the PI where the ‘EGI’ scoped entities are selected by default when the scope parameter is omitted in the query.

Revision as of 16:04, 22 April 2013

<< Back to Overview_of_Funded_Virtual_Team_projects
Comming soon.

Overview/Motivation

The project would; A) Extend the current ‘EGI’ and ‘Local’ data scoping logic to introduce multiple, non-exclusive scope tags to encourage other projects to host their data within a single GOCDB instance, and B) Provide a supporting GOCDB management interface to simplify daily operational/admin tasks.

With these developments, the functionality of GOCDB would be extended beyond the current DoW so that topology data from multiple projects could be more effectively managed using a single GOCDB instance (e.g. EGI, EUDAT, PROJX). A management interface would help simplify and speedup daily operational tasks, especially for new service administrators and will help reduce on-going operational costs for EGI. Non-exclusive scope tags would allow sites/services to be scoped with both project-specific tags (e.g. ‘UK_NES’) and with the wider ‘EGI’ scope tag.

Technical Outcomes

Scoping Extensions

The current scoping implementation provides only ‘Local’ and ‘EGI’ scopes which are mutually exclusive; a site/service can only be tagged with a single scope. The enhancements will build upon the current data-scoping logic to introduce non-exclusive scope tags. This would allow a single object, such as a site, service, or virtual-site to be tagged by multiple projects. In doing this, a single data object could be defined once and associated with more than one project without duplication of information. This is essential in helping to maintain the integrity of topology information across different target infrastructures.

  • The scoping extension would also introduce new business logic rules. For example, the scopes made available for a ‘Service.Scope' value would be limited to the values listed by the parent 'Site.Scope'. This way, a service scope would be limited to the scopes already defined by the site. A site scope would thus become a union of the child service scopes. This is logical since the owning site is the responsible administrative domain for its child services. For more information see: https://wiki.egi.eu/wiki/GOCDB/Release4/Development/conditionalCertificationStatusRules
  • When querying for data via the PI, the existing ‘scope’ parameter would be extended so that a comma separated list of target scopes could be specified. For example ‘get_sites?scope=EGI,EUDAT,PROJX’ and ‘get_service_endpoints?scope=EGI, PROJX’ . The PI results would then be restricted to show only those entities that define the requested scope.
  • The GOCDB configuration file would be extended to add optional default scope declarations. These default scopes could be used to restrict the query results when no PI scope is explicitly requested. This is necessary to maintain the current (hard-wired) behaviour of the PI where the ‘EGI’ scoped entities are selected by default when the scope parameter is omitted in the query.