- 1 GGUS-TPM
- 1.1 Using GGUS System
- 1.2 Escalating GGUS Tickets
- 1.3 New Tickets
- 1.4 Middleware Tickets
- 1.5 How to see if a ticket is to be assigned to NGI
Using GGUS System
- Emails will be sent to TPM on duty when
- new tickets are created
- any change is made on TPM tickets
Communication with User
- The only reliable way to communicate with the user is to add a comment in the public diary field in each ticket
Other situation where users will receive updates
- when user sets notification option to every change. However, internal diary comments are hidden.
- when the ticket is set to solved. The solution field is sent at that time.
- when the supporter uses the replies to the ticket via email (GGUS mail interface)
Escalating GGUS Tickets
There are 3 escalation levels for GGUS tickets
- Escalate to the support unit. This is the first level of escalation. It will send an e-mail to the unit, prompting them for some action. Most often a reminder to the unit is enough to trigger action.
- Escalate to TPM and unit. This is the second level of escalation. It will involve the TPM who will closely monitor the progress of the ticket. The unit is also further prompted for action at the same time.
- Escalate to GGUS. This is the third and last level of escalation. It will involve GGUS itself who will investigate why there was no satisfactory progress on the ticket. The unit and the TPM are also notfied at the same time.
Assist ticket resolution
The TPM should do all that is possible to solve the ticket. If the TPM cannot solve the ticket, there are also things the TPM can do to help expedite the process.
To help solve the problem, the TPM can
- Verify if that the issue is not a usage mistake
- Check documentation, manuals, options
To clarify the issue before forwarding to SU, the TPM can
- ask for the verbose output of the command
- ask related log or configuration files if available
- also see service or software problem below.
Determine if this is service (site), software or experiment Issue
If the issue seems to be experiment specific, involving tools and/or services that are unique to one experiment, then the ticket should be assigned to the 'VO Support' ('VO Support' in case of an issue for ATLAS, ALICE, CMS and LHCb, or their own 'VO Support' for other VO).
To help determine if the problem is site specific or a general problem with the middleware, the following steps can be taken
- Try to reproduce the same error
- if using the same service(site node) fails, then
- Try at another site to make sure it is not a local problem
- If the test succeeds, then this may indicate a site specific problem, so assign to responsible NGI (or ROC) and notify the affected site if available
- If test fails, then it can possibly be a problem with a core service (LFC, VOMS, RB, BDII, ...)
- Try using another core service
- If this still fails, then this could be a Middleware problem. In this case assign the ticket to the DMSU.
If another ticket already exists that refers to the same problem then do the following:
- Notify the submitter that a duplicate ticket exists by adding a comment in the public diary
ticket #NNNN reports the same problem
- Mark one ticket as "Master" and the other one as "Slave"
After you determin that this ticket is a software bug, assign the ticket to DMSU.
How to see if a ticket is to be assigned to NGI
How to check the ticket is to be assigned to OSG or an NGI/ROC. Please follow the procedure to execute it.
- Please check the drop-down list of the field "Notify site" and select the site. This drop-down menu
- If you need to know the site a given host is located
- pleas click the question mark right of the "notify site" label. A new search window opens where you can query the GOCDB for the hostnames.