GOCDB/Release4/Development

Back to GOCDB/Documentation_Index

Recent Completed Developments

• GOCDB-4.2 Released into production - November 2011 https://www.sysadmin.hep.ac.uk/svn/grid-monitoring/tags/gocdb/GOCDB-4.2/gocdb/changeLog.txt
  • Scoping of sites and service endpoints https://rt.egi.eu/rt/Ticket/Display.html?id=2789
• GOCDB-4.1 Release - November 2011 https://www.sysadmin.hep.ac.uk/svn/grid-monitoring/tags/gocdb/GOCDB-4.1/gocdb/changeLog.txt
  • Refactored PROM db API. The underlying database code has been refactored considerably for greater flexibility and stability. All changes to the database are now atomic facilitating transaction demarcation in higher level business routines. Database interactions are now performed through a database agnostic API interface.
    • (Before v4.1, the GOCDB PROM API did not allow transaction demarcation in high level business operations, such as inserting a site and adding new SE because explicit commits and rollbacks were declared in low-level PLSQL functions including fnNewLink(), fnUpdateObject(), fnDeleteObject(), fnDeleteLink(). Consequently, any business operation that invoked these functions multiple times in a single processing unit was not atomic, and gocdb 4.0 could leave the db in an inconsistent state if an error occurred since full rollback was not possible (e.g. on site creation Savannah 74860). This almost certainly accounted for a number of previously reported data inconsistencies. Refactoring the database logic was therefore high priority and is a regionalisation pre-requisite; either all or none of the data should be committed to the central gocdb when publishing from regional to central).
  • Refactored much of the code base initially (inc. MVC) to support scoping but also to provide more flexibility long term (using a flexible controller per page architecture with view templates). This will make future change requests easier to fulfill and gives us more flexibility to make user interface improvements.
    • (Before v4.1, GOCDB used a generic module for drawing all forms and GUI components such as tables. This module defined a single code path which was too rigid, making it difficult to deal with form/table requirements on a per-page basis).
  • New View Site page (to support scoping and to address user issues with the current View Site page) https://rt.egi.eu/guest/Ticket/Display.html?id=974
  • New View Service Endpoint page
  • Added current UTC time to New Downtime page https://rt.egi.eu/guest/Ticket/Display.html?id=1210
  • Added context sensitive page titles https://rt.egi.eu/rt/Ticket/Display.html?id=1109
  • Added "All" button to table view https://rt.egi.eu/guest/Ticket/Display.html?id=974
• Refactored database code to be atomic (required to implement scoping) - Oct 2011 (release into production end Oct/start-Nov) https://rt.egi.eu/rt/Ticket/Display.html?id=943 (details below)
• New Downtime interface much improved, moved to single page + can now select all endpoints under one site - September 2011
• Moved Site, User and Endpoint manipulation to new MVC architecture ready to support scoping - July 2011 https://rt.egi.eu/rt/Ticket/Display.html?id=943
• Fixed a few long term bugs with adding and editing sites and users - July 2011
• Increased front end responsiveness - July 2011
• Cleaned old roles - June 2011 https://rt.egi.eu/rt/Ticket/Display.html?id=931
• Added a URL field to service endpoint objects to support UNICORE services - May 2011 https://rt.egi.eu/rt/Ticket/Display.html?id=975 (note, even though a single URL field is displayed per Endpoint, a new Gocdb_Endpoint_Location entity was created in order to link multiple service endpoint locations per SE if this becomes a future requirement - see Media:GocdbGlue2UnicoreV2.pdf).
• Add a "my site" link in the main menu - May 2011 https://rt.egi.eu/rt/Ticket/Display.html?id=1091 (note, this uses the new controller-per page with templates design as summarized below).
• Record Certification Status History - May 2011 https://rt.egi.eu/rt/Ticket/Display.html?id=939
• Allow authorised operators to suspend sites at central level - March 2011 https://rt.egi.eu/rt/Ticket/Display.html?id=1094
• Show when a site entered the current production status - March 2011 https://wiki.egi.eu/wiki/GOCDB/PI/get_cert_status_date
• Consolidated Wiki and all documentation.

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.

The GOCDB role/permissions model are to be updated

in order to cater for a finer grained permission proposal currently emerging as a new EGI requirement. More information available here: GOCDB/Release4/Development/NewRoles Media:FinerGrainedGOCDB_rolesVeraProposal2.xls

Establish a central GOCDB readonly failover

A central GOCDB webportal failover will be installed at Fraunhofer ITWM. A DNS switch for the 'goc.egi.eu' domain between the production server and the failover server is in place. Once installed, the failover will be readonly in order to prevent data-synchronization problems.

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: https://rt.egi.eu/rt/Ticket/Display.html?id=987 and https://wiki.egi.eu/wiki/Logical-site

• 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 (https://wiki.egi.eu/wiki/GOCDB/PI/get_service_endpoint_method and https://wiki.egi.eu/wiki/GOCDB/PI/get_site_method ). The following XML example is related: https://twiki.cern.ch/twiki/pub/Main/ATPVOFeeds/atp_vo_feed_example.xml
  • 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.

Redevelop the xml_output module to implement nested XML collections [not confirmed]

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 and URLs within a single ServiceEndpoint element, see: Media:GocdbGlue2UnicoreV2.pdf). It is likely that this is a requirement for regionalisation to implement the proposed XML 'synch' docs described at: https://wiki.egi.eu/wiki/GOCDB/Release4/Regionalisation/Data_Transfer_Format

Development Roadmap

• v4.1 Released 01 Nov 2011 https://www.sysadmin.hep.ac.uk/svn/grid-monitoring/tags/gocdb/GOCDB-4.1/gocdb/changeLog.txt
• v4.2 Released into production mid Nov 2011 (includes Scoping - tagged download available soon)
• Central GOCDB failover in place, end Dec 2011.
• v4.3 Finer grained roles/permissions, Jan 2012
• v4.4 Virtual Sites (VSites), ~March 2012
• [Not confirmed] Replace current XML output module to cater for nested XML collections
• A re-prioritization exercise will then determine the next major developments.