Gridpp37 – 31/08/2016 George Ryall David Meredith GOCDB Status Update Gridpp37 – 31/08/2016 George Ryall David Meredith GOCDB is an EGI service provided by STFC, co-funded by EGI.eu and EGI-Engage.

Outline Introduction: Who are we What is GOCDB Information systems evolution Custom properties Write API Background Description Example Other recent developments Forced paging Contacts and links to further information

Who are we George Ryall (ME): 0.6 FTE Based at RAL Started working on GOCDB at the start of the FY (having previously spent 6 months as part of a graduate scheme placement). Dave Meredith: 0.4 FTE Based at DL Lead developer Where does our funding come from? Operations: egi.eu, match funded by GridPP New developments: EGI Engage

What is GOCDB? The Short answer: Grid Operations Centre DataBase: Goc.egi.eu – a grid topology database. The Long answer: a central registry to record information about the topology of an e-Infrastructure. Currently used by EGI and WLCG, with EUDAT running their own instance. Information includes entities such as operations centres, sites, services, service endpoints and their downtimes, users, and the relationships between the above. The service enforces a number of business rules and defines different grouping mechanisms and object-tagging for the purposes of fine-grained resource filtering. A role-based permissions model allows resource owners to manage their own resources user roles. Both a user facing web interface and a read programmatic interface are provided.

Information Systems evolution Will require more information to be stored in the GOCDB, some of which may need updating more frequently. The additional information can be stored using the recently developed custom properties feature. Andrew McNab will be presenting an update on this tomorrow morning. General aim is to move WLCG away from reliance on the BDII. More information at: https://twiki.cern.ch/twiki/bin/view/EGEE/StopBDII

Custom Properties The custom properties feature allows multiple key-value pairs to be associated with several types of GOCDB entity. These have been used to prototype WLCG requirements for new attributes. Multiple properties can be added through the web interface at once.

Write API Background GOCDB’s current API provides a variety of views of the information within it (e.g. https://goc.egi.eu/gocdbpi/public/?method=get_site). It is extensively documented here: https://wiki.egi.eu/wiki/GOCDB/PI/Technical_Documentation. Reducing the reliance on the BDII is likely to involve increasing the frequency of updates to the properties of some entities in GOCDB. It may be more appropriate to make these updates through a write API. A write API is under development. That development work is documented here: https://wiki.egi.eu/wiki/GOCDB/Write_API_Development Whilst the current development code for it can be found on GitHub: https://github.com/GRyall/gocdb/tree/write-api An alpha release for initial user testing is expected W/C September 19th.

Write API Initially only supporting changes to extension properties for sites, services, and service endpoints. Though it is written to be easily extended to allow changes to other properties if required. URL of the form …/v5/<entityType>/<entityID>/ExtensionProperties/, with the request contents and HTTP method determining the action (PUT, POST and DELETE supported, with GET a likely future development). Currently all requests must be authenticated using a x509 certificate It is envisaged that site admins will maintain an access control list of authorised client DNs through the web portal. Output and input is in JSON format, with appropriate HTTP response codes for different errors. A list of actions that are planned to be supported in the initial release can be found here: https://wiki.egi.eu/wiki/GOCDB/Write_API_Development#Initially_supported_urls.

Write API - example A typical request might be a POST request to “../v5/Service/5682/ExtensionProperties” with the contents of the request being: {"GLUE2EndpointID":"arc-ce04.gridpp.rl.ac.uk", "GLUE2EndpointImplementationName":"ARC-CE"} This would be made using a certificate with a DN in the list of authorised certificates for the sites that the service with 5682 belongs to. This would Add the extension properties in the request to the service with id 5682, and fail if there were already extension properties defined with either of the keys (PUT has a different behaviour). A PUT request would have overwritten the existing value if a pair with the requested key already existed.

Write API A list of actions that are planned to be supported in the initial release can be found here: https://wiki.egi.eu/wiki/GOCDB/Write_API_Development#Initially_supported_urls

Other Recent Developments Whilst the Write API is currently a major part of recent work, we have also recently completed a number of other developments: Forced of existing API queries – see the next slide. Dual stack IPv6 test instance (https://ip6tb-goc.gridpp.rl.ac.uk/portal/). Downtime calendar. Ability to declare downtimes in local timezone.

Forced Paging The next release of GOCDB will enforce paging of results on most existing API queries. This is cursor, not offset, paging. More details, including links to a test server with this code on, can be found here: https://wiki.egi.eu/wiki/GOCDB/notifications#v5.7

Questions? Information and contacts: Contact: gocdb-admins@mailman.egi.eu Discussion list (mainly tool developers using the PI): gocdb-discuss@mailmain.egi.eu Support: https://ggus.eu/ Source code: https://github.com/GOCDB/gocdb Requirements tracking: https://rt.egi.eu/rt/Dashboards/5541/GOCDB-Requirements Documentation: https://wiki.egi.eu/wiki/GOCDB/Documentation_Index