Participants:
-
Malgorzata Krakowian (EGI.eu)
-
Mathilde Romberg (EMI)
-
Ales Krenek (NGI_CZ)
-
Tiziana Ferrari (EGI.eu)
-
Steve Crouch (IGE)
-
Guenter Grein (GGUS)
-
Helmut Dres (GGUS)
-
Peter Solagna (EGI.eu)
-
Cyril Lorphelin (NGI_FRANCE, Operations Portal)
-
Helene Cordier (NGI_FRANCE)
Summary of GGUS survey on post EMI/IGE support
GGUS
* savannah interface will be dropped after the decommissioning of savannah
* jira will not be implemented because CMS will move to GGUS abandoning savannah/jira
MR: The software suppor unit may mask the fact that some supporters have a different bug tracker system, GGUS would be the reference end-point
. unicore: sourceforge
. ARC: bugzilla
. RT used by IGE, could be extended by 1 additional year but it is still to be decided EGCF
ACTION (Steve): check plans for continuity to use RT for GLOBUS issue tracking
ACTION (Malgorzata): create a spread sheet with missing products including
. JRA1 software (operational tools)
. saga
. qcg
. any other support unit that is about software
http://go.egi.eu/ProductTeamslist
Supporting three levels is not a problem in GGUS from a technical point of view.
For unresponsive SUs we will start with Level 1, and we will see the type of support provided
GGUS release: Wed 5th of June (tentative schedule)
ACTION (GGUS team): document the two workflows for broader discussion with UCB and communication to the VO managers
The prototype for the dashboard for the middleware PTs
Work plan for transition from the current technology helpdesk to the new framework for software support
1800 tickets: total number of tickets handled through the technology helpdesk // seems very low as a number
Option 2 seems to be the most popular --> the GGUS AB agrees with Option 2
Alarms against operations tool in case of critical incidents
Cyril: GGUS cannot be notified in case of its failure. In case of problems with network you cannot contact if the phone infrastructure is based on network.
Questions:
For which central services should an alarm be possible? Only for GOCDB, MSG, SAM and OPSPORTAL or for all GRIDOPS* sites in GOC DB?
yes all
What about MSG? There are 3 instances covered by one support unit/GRIDOPS site.
ACTION (Tiziana): discus with Paschalis how to contact in case of issue with one of the MSG broker
Will the GRIDOPS* sites all provide an emergency email in GOC DB or shall this be kept in the local GGUS DB?
ACTION (Guenter): check what is most sufficient
For many of the central services we already have a support unit in GGUS. Shall the alarms be mapped to these central service SUs?
yes
How about the visibility within GGUS. Shall tickets be searchable (by whom? ) via the search engine?
yes, by everyone
Should these tickets be accounted for the report generator?
yes
One person per NGI to open tickets.
AOB
- What does it mean "solved"? Does it mean solved by PT or solved and accessible in UMD?
Solutions:
1. close and put information that next step is UMD and when will be released
2. reassigned to UMD
MR: EMI closed as soon as it is released in EMI
Ales: an extra step for ticket processing -> it requires version of component and UMD as mandatory ("fix available in version")
Guenter : not possible for every component to have version of UMD
ACTION (Ales): check Peter Solagna opinion to have UMD SU (used to assign tickets which needs information about UMD releases when issue was solved by PT), and contact with Guenter to change the flow
- report generator issues?
MR: Reports are provided only for calendar years not the project years (median)
TF: a special request needs to be send to GGUS each time. It will not be implemented
since projects have different starting months.
There are minutes attached to this event.
Show them.
