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 @


From EGIWiki
Jump to navigation Jump to search

Back to GOCDB/Documentation_Index

Recent Completed Developments

  • GOCDB-4.1 Release - November 2011
 * Underlying database code refactored for greater flexibility and stability. All changes to the database are now atomic. Database interactions are now performed through a formalised interface API.
 * Refactored much of the code base initially to support scoping but also to provide more flexibility long term. This will make future change requests easier to fulfill and gives us more flexibility to make user interface improvements.
 * New View Site page (to support scoping and to address user issues with the current View Site page)

Current Developments

Regionalisation related developments are given in their own page: GOCDB/Release4/Regionalisation
Feedback received on the new system is given at: GOCDB/Release4/Feedback

The list of [GOCDB development items is available in the EGI RT ticket tracker]

These are the developments we are currently working on. They come from the agreed development list, as defined by the Operational Tools Advisory Group (OTAG) who filters and prioritizes user requests.

Redevelopment of the PROM database API to be Atomic

(e.g. on site creation Savannah 74860). The GOCDB PROM API did not allow transaction demarcation within high level business operations (e.g. inserting a site and adding new SEs). Explicit commits and rollbacks were declared in low-level PLSQL functions including fnNewLink(), fnUpdateObject(), fnDeleteObject(), fnDeleteLink(). Consequently, any composite business operation that invokes multiple low level functions could not declare tx boundaries around the whole process. These operations are therefore not atomic and can leave the db in an inconsistent state if an error occurs (since rollback over all the low level operations is not possible). This almost certainly accounts for a number of inconsistencies seen in the db. The PROM PLSQL layer and the higher level DAOs are being refactored so that transaction demarcation can be moved up into the business operations (e.g. as in a regular stateless service facade). This is a pre-requisite for a regional-publishing gocdb (either all or none of the data should be published to the central gocdb in a particular synching operation).

New MVC Logic

The GOCDB4 uses a generic module for drawing a forms and GUI components such as tables. This proprietary module uses a single code path for all form and table based operations. In doing this, the code has become too rigid making it difficult to deal with form/table requirements on a per-page basis. This module will be replaced with a more flexible controller per page architecture with view templates. This is necessary to address a number of the RT requirement requests (approximately half suggest GUI improvements).

Data Scoping in the Central GOCDB

The following tasks need to be completed to introduce scoping to the central GOCDB instance. "DONE" means completed in our current development version of GOCDB and not necessarily put into production.

  • Enable database level tagging to allow scoping of data - DONE
  • Modify PI queries to be scope aware (e.g. get_downtime?scope=Regional) - DONE
  • Atomic database access - IN PROGRESS
  • Add scoping capability to the web portal - IN PROGRESS
    • This is being achieved through MVC implementation of inserting / editing objects
      • Add / Edit Service Endpoint - DONE
      • Add / Edit Site - DONE
      • Add / Edit Downtime - DONE
      • Add / Edit User - DONE
      • Add / Edit Role - IN PROGRESS
  • Remove old Non-MVC code - IN PROGRESS
  • Remove old XML Input code
  • Indicate what scope data has in the web portal
    • When viewing an individual object
    • When viewing a table of objects
  • Add scope specific web portal views
    • View Local Sites
    • View EGI Sites
    • Scope Specific Search

Explicitly indicate if all SEs of a site are in downtime through the PI

Redevelop the xml_output module to implement nested XML collections

probably using the Query2XML package. This is necessary because the existing XML Output module will only generate flat XML documents (e.g. that often map to individual DB entities). Currently SQL joins/associations between Sites, SEs and URLs cannot be represented as hierarchical/nested XML documents (for example, consider nesting multiple EndpointLocation objects/URLs in the ServiceEndpoint XML, see: Media:GocdbGlue2UnicoreV2.pdf).

Support for Virtual Site Entities (VSite)

There is a requirement to group existing Service Endpoints (currently grouped under their corresponding 'owning' physical Site) under a new 'Virtual Site' entity. See: and

  • At present, the proposed features of a VSite will include (see Media:VirtualSitesDesign.pdf‎):
    • A VSite will be a separate GOCDB entity, and will have users and other attributes much like an existing physical site but with different rules (described below). Importantly, we believe this grouping has to be a new gocdb object in order to clearly define the intended semantics of the grouping (e.g. both a 'VSite' and an imaginary 'VService' could both group many SEs, but a VSite has very different semantics to a VService !).
    • A VSite will be used to group existing Service Endpoints only (i.e. SEs that have already been created under their owning physical Site).
    • A VSite cannot group new SEs that have no owning physical site.
    • A single SE may only have a single parent physical Site (i.e. GOCDB cardinality of 1 between Site and SE)
    • A single SE can have many parent VSites (requires GOCDB cardinality of 'many-to-many' between Virtual Site and SE).
    • New PI queries are proposed to support querying of VSites and querying of SEs that are grouped under a VSite (much like the existing get_site and get_service_endpoint methods ( and ). The following XML example is related:
    • The permissions model requirements for a VSite are not yet well defined. It is currently proposed that users with a role over the owning physical site should maintain their cascading permissions over their SEs (i.e. no modification to the current site/permissions model). Conversely, users with a VSite role will not gain any cascading permissions over the SEs; this has the following important implications;
      • A VSite could not be used to declare a downtime for all its member SEs.
      • Similarly, users with a role over the VS will not be able to update/modify a member SE.
      • If VSite permissions are required (e.g. for declaring SE downtimes and modifying SEs), then a user may have to request a physical site role. These requirements are currently undefined.

The GOCDB role/permissions model may need to be updated

in order to cater for a finer grained permission proposal currently emerging as a new EGI requirement. Media:FinerGrainedGOCDB_rolesVeraProposal2.xls

development item Estimated release Estimated date
Provide a production quality package for GOCDB regional module 4.0d7 Oct 2010
Improvement of GOCDB failover system and backend replication 4.0.1 May 2011
New service endpoint URL associations for new service types (see above) ? April/June 2011
Re-develop GUI Logic (see above) ? Sept 2011 (EGI-Y2)
Update/refactor role model for finer grained permissions (see above) ? EGI-Y2
Data scoping by tagging GOCDB entities (see above) ? EGI-Y2
Regionalisation GOCDB/Release4/Regionalisation ? EGI-Y2/3
Work on GOCDB and Operations Portal common front end ? EGI-Y2
GOCDB interface to the dynamic information system (BDII/GluE) ? EGI-Y3