1. PRACE-EGI helpdesk integration
EGI Technical Forum, Prague September, 18th 2012
Marcello Morgotti, CINECA

2. Introduction
EGI and PRACE are pan-european research infrastructures with the aim to support scientific research
PRACE provides HPC services and resources
EGI provides Grid services and resources
Both have strong operational infrastructures for user support and helpdesk

3. Activity Aim
Since both are providing efficient operational infrastructures …
… for users in need to access to both infrastructure in a coordinated way is it possible to have a single point of contact

4. PRACE TTS - Objectives
Provide a simple and efficient helpdesk system to PRACE end user
Provide a strong tool to efficiently track and resolve issues and problems to the operation team

5. PRACE TTS – Overview In the beginning it was the DEISA TTS…
Old RT (3.6) instance, higly customized and highly modified
Stable but not easily maintainable because of too many undocumented code intervention
Then came the PRACE TTS…
Capitalize DEISA efforts for customization
Migrate to a more stable and maintanable system
Migrate to a more operation-oriented model
Use features of newer RT version (3.8 vs 3.6)

6. PRACE TTS – Technical details
Hardware
2 standard Debian 6.0 systems (1 production + 1 development)
Deployed on a Virtual infrastructure
Software
Best Practical Request Tracker (RT) 3.8.8
Debian packaged therefore easy to upgrade
DEISA configuration and customization imported

7. PRACE TTS – Structure and Workflow
Authentication and Authorization is based on X509 certificate
User informations are registered and gathered from the PRACE LDAP
Two different roles are outlined: standard users and staff users
Access is provided through
Web interface (primary): by filling the request field
Mail (secondary): by sending an to the ri.eu address

8. PRACE TTS – Structure and Workflow
Each site should provide a support address to deal with support requests
When a ticket is opened on a site queue the site support is notified with an
The structure of the PRACE TTS consists of:
A General queue where Generic requests are placed when tickets are opened by or when user is not fully sure where the problem is: in this case the Helpdesk on Duty or the Operator on Duty examines the request and move it to the proper queue
Different Site queues where ticket are actually taken in charge by the different Site support teams

9. GGUS Helpdesk and Support tool successfully used within EGI
Allows to host and integrate etherogeneous support infrastructures and provide a single contact interface
Basically does everything RT does so many common points in structure and workflow can be found

10. PRACE-EGI – Integration
BestPractical Request Tracker provides different interfaces:
HTTP post
Mail
SOAP
REST
CLI
GGUS provides SOAP interface with RT
Pro: it has already been successfully used for the integration of 3 NGI RT-based helpdesk

11. PRACE-EGI - Integration
Definition of a common workflow for ticket and support usage
What happens when a ticket is created on PRACE TTS?
What happens when a ticket is created on GGUS?
What happens when a ticket is moved from the General to a Site Queue in the PRACE TTS?
Definition of a table of mandatory fields needed in both tools to fully describe tickets and prevent loss of information
Can already working use-case be used as tutorial or at least as starting point?

12. GGUS – RT Integration Existing use cases
NGI CZ
NGI GRNET
Both are configured by means of scripts on both sides (RT and GGUS) which trigger syncronization on Creation, Update and Resolution of tickets
This is likely to be the path to be followed although quite a development effort is needed and not only a adaption of GGUS and RT configurations

13. PRACE-EGI – Integration
Which technical problems can arise?
Main problem can be user authentication and in particular authorization. Since both infrastructure should rely on same user profiles and same user database, an interoperability shold be therefore foreseen also in that area (i.e. Not every EGI authenticated user should be able to open PRACE tickets)
How to proceed?
Find a real use case (if not already existing) which can drive the activity and from which also gather additional requirements
Estimate the necessary effort both parts need to allocate
Test instances already in place for both tools.

14. Questions?