1. GOCDB New Requirements

2. non‐EMI service types and notifications
Improved support for non‐EMI service registration
We centrally control the service types in GOCDB to mitigate duplication and proliferation of unsuitable types (domain compute Jobs for example).
A distinction between centrally controlled SE types and custom types could be useful. This requires discussion/acceptance at JRA1/OTAG/OMB.
No notification for pending role requests
can be added in rt with low priority - the same as RT1102

3. User-friendliness
GOCDB front‐end was more user friendly in previous version (GOCDB3)
GOCDB v4.0 used a single module for drawing all GUI components. This module was far too rigid - it was impossible to deal with GUI requirements on a per-page basis. To address this, the entire MVC logic has been redeveloped and front end usability is now steadily improving.
Front end developments have to be balanced against other higher-priority (back-end) developments/tasks.

4. Input and visulisation
Separation of "input" and "visualisation" is a little confusing. It would be useful to be able to add a downtime from the info page for a given site
Is this really a priority?

5. Functionality can be improved by adding change tracking
All site certification changes are recorded and can be queried for audit purposes using the PI. See:
If further change/history tracking functionality is required, then use-cases should be devised and submitted via RT for prioritisation.

6. GUI https://gocdb4.esc.rl.ac.uk/portal has not a trusted certificate
GUI certificate
GUI has not a trusted certificate
GOCDB has a UK e-Science certificate that is fully trusted by the IGTF. We could consider using a certificate issued by a different CA, such as one provided by Terena which is globally trusted (

7. GOCDB experiences a lot of downtimes
Availability
GOCDB experiences a lot of downtimes
We recently experienced site DNS issues that may have led to this viewpoint.
According to the external ops-monitor check, GOCDB achieved:
99.75% total up time from April 07th 2011 to Jan 01st 2012 (11h 53mins total downtime)
99.927% total up time since 01st Jan 2012 to date (49mins total downtime)

8. Slowness
The web interface has become rather slow that its always a hassle to use
Is still true?
Maybe the users are referring to the recent DNS issues

9. Write APIs
We are waiting for “write” API to integrate regional configuration management database with the central GOCDB and we see no plans for that. We tried to adapt GOCDB to our region but the code is complicated so regional extensions were difficult
We understand the requirement for a writable API, but this has to be balanced against other higher priority developments documented at:
A writable API would be part of the Regional-Publishing GOCDB (to submit data from regional to central instance).
Given the addition of data scoping in the central instance, we suggest a re-prioritization exercise for the Regional-Publishing model.

10. Slowness of development
From our perspective it seems that development slowed down and no much progress was achieved since long time. Even small changes takes quite long
In 2011 a large amount of time has focused upon addressing a number of fundamental v4.0 design issues that had to be prioritized ahead of responding to new feature requests.
The entire MVC architecture has been replaced (see previous comment).
The backend of the application has been redeveloped significantly (
This work is not always immediately apparent to the front end user. However, there have been marked improvements in reliability, code quality and abstraction. As a result, there has been a noticeable decrease in the number of GGUS tickets (since the DB logic is now atomic, so the number of tickets relating to data-inconsistencies has completely dropped).
New functionalities have also been released in parallel throughout 2011 (listed at above link) and new core features are soon to be released.
Only have one FTE of effort for admin, support and development of GOCDB.