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
EGI Inspire Main page

Notes to contributors

Assessment: (Provide an assessment of the delivery of services over the past year from a managerial perspective; highlight positive areas and areas for improvement; do not include future plans; text should be roughly 1-2 paragraphs)

Score: (assign a numerical score from 1 to 5 with a succinct explanation of what needs to be improved to increase your score – remove numerical description references upon completion) 1 = An unacceptable level of service was delivered

2 = A level of service that was below expectations was delivered

3 = An acceptable service level has been delivered

4 = A level of service that exceeded expectations was delivered, but there is scope for even further improvement

5 = An excellent service has been delivered that should be considered as best practice

Table 4: EGI Global task assessment:Configuration repository
# Name Assessment Score How to Improve
# Configuration repository The GOCDB service ran smoothly and reliably throughout the first three quarters of 2010, and during the transition from EGEE to the start of EGI. Version 4 was released during the last quarter of 2010, and represented a major functional update. Operational support in this final quarter was challenging; with a high level of GGUS traffic, user support and emerging issues/requirements. This was to be expected considering the release of new software into production, and with the departure of the technical lead (notwithstanding the transition from EGEE to the new EGI environment and lead-time for the replacement). Since the v4 release, all bugs have been recorded and are being actively tracked/worked-upon, while new feature requests have been documented. The quality of user support and response-times were good during the first three quarters of 2010 (with the experienced team). Following an inevitable dip, support has improved in the last quarter as the new team have become more familiar with GOCDB. The service also experienced a number of hardware failures. These were dealt with quickly and the GOCDB Oracle database was migrated to new, more resilient hardware. In doing so, service reliability appears to have noticeably improved. The failover plan has recently been re-established and constitutes current work. The planned regionalization developments for GOCDB are challenging for the current staffing level (but should be achievable over the longer term), and will almost certainly require some refactoring of existing code to accommodate existing (and recently emerging) requirements. 4 (for first 3/4yr), 3 (for last 1/4yr) The GOCDB failover could be improved. This was not implemented with the transition from v3 to v4. This is actively being worked upon with a database backup procedure and an offsite web-portal. The release procedure could also be improved, as patches and refractored code has been continuously (and quietly) applied to the production service without formal release notification. This suggested improvement is timely, as adhering to a more formal release procedure during the last 3 months was not strictly necessary and would have consumed more time at the expense of operational support.