VT GOCDBExt

From EGIWiki
Jump to: navigation, search

<< Back to Overview_of_Funded_Virtual_Team_projects
Will be completed soon.

General Information

  • Leader: David Meredith
  • Mailing List: gocdb-discuss[At]mailman.egi.eu
  • Meetings: link to Indico container
  • Status: Complete
  • Start Date: April 2013
  • Duration: 6mths to fund George Ryall
  • Customer: EGI/EUDAT/other projects eg. WLCG
  • End of project review doc: https://documents.egi.eu/document/1957

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.

Objectives

Non-Exclusive 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.

Management Interface

GOCDB does not provide a management interface for daily operational tasks. Amongst others, these tasks include moving sites to different NGIs, creating new NGIs, adding/deleting scope tags and updating user DNs in the database. Many administrative tasks are performed directly on the database using external scripts developed in the Oracle query language (PLSQL). A management interface will simplify and speedup execution of these tasks (especially for new portal administrators) and decrease the likelihood of introducing error.

Tasks

Scoping Extensions:

  • Design document detailing technical implementation:
    • DB support for multiple scopes
    • Front end portal modifications
    • New business rules (e.g. SE’s scopes must be reflected in parent site’s scopes)
    • Extend PI scope parameter to support list of scopes
    • PHPUnit Tests (add relevant DBUnit tests to assert non-exclusive scope support).
    • Deployment to production

Management interface:

  • Design document:
    • Add / Edit / Remove:
      • Service Types
      • NGIs
      • User DNs
    • Move sites between NGIs
    • Move service endpoints between sites