- 1 FAQ GGUS-Alarm-Ticket-Process
- 2 Introduction
- 3 Basic requirements for ALARM tickets
- 4 Technical description
- 5 Periodic ALARM ticket testing rules
- 6 What if I have questions which are not dealt with by this FAQ?
The purpose of alarm tickets is to notify tier-1 administrators about serious problems of the site at any time, independent from usual office hours.
Therefore the submission of alarm tickets is restricted to a dedicated group of people. Alarm tickets should only be submitted in case of severe problems occurring.
The alarm ticket process is exclusively implemented for tier-1 sites.
Figure 1: LCG tier-1 sites.
Basic requirements for ALARM tickets
Alarm tickets can only be submitted by experts (the so called “alarmers”) who have the appropriate permissions in the GGUS user database. These people belong to one of the four LHC VOs
- Cms or
and are nominated by the particular VO management. They are about 3 to 4 people per VO. Alarmers are registered in the CERN VOMS server. The GGUS user database synchronizes with the CERN VOMS server once per night. Alarmers are authenticated by their certificate registered in VOMS. Details on how to submit an alarm ticket are described in chapter "Alarm ticket submission".
This chapter describes the workflows of alarm tickets from a technical point of view. The basic conditions like permissions for alarm tickets are already described in the chapter on "Basic requirements for alarm tickets".
ALARM ticket submission
Alarm tickets can be submitted using the GGUS web portal.
On top of the ticket submit form in GGUS web portal there is a link to the submit form for alarm tickets [Figure 2].
Figure 2: Link to the alarm ticket submit form in GGUS portal.
As alarm ticket submitters are experts who will hopefully provide all necessary information, the number of fields on the alarm ticket submit form is reduced to a minimum compared to the number of fields on the user ticket submit form [Figure 3]. Three fields on this form are mandatory:
- MoU Area,
- Notified Site.
ALARM ticket processing
The processing of a team ticket consists of two main parts, the notification of the notified site and the routing of the ticket to the NGI/ROC the site belongs to.
Tier-1 site notification
In parallel to the creation of an alarm ticket the GGUS system sends an alarm email directly to the tier 1 site specified in field “Notify SITE”. This email is sent to a specific site alarm mail address and signed with the GGUS certificate. The tier-0 alarm mail address is based on the VO name. It is <<voname>>-operator-alarm[atnospam]cern.ch. Tier-1 site alarm mail addresses are taken from the "Emergency Email" field in GOC DB. For tier-1 sites registered in the OSG OIM DB the alarm email address is taken from field "SMSAddress" of the "Administrative Contact" in OIM DB.
The DN of the GGUS certificate is /C=DE/O=GermanGrid/OU=KIT/CN=ggusmail/ggus.eu.
The alarm mail looks like shown in Figure 4.
Figure 4: Alarm mail example
Alarm tickets are bypassing the TPMs and routed to the appropriate NGI/ROC automatically. The decision to which NGI/ROC a ticket has to be routed is done automatically, based on the value of the “Notify SITE” field. The “Notify SITE” drop-down menu shows both, the tier 1 site names from GOC DB and the tier 1 site names used by WLCG.
Figure 5: „Notify SITE“ drop-down menu
Once the tier 1 site received the alarm email the receipt should be confirmed. Sending a reply mail containing the typical GGUS identifier and the ticket ID “GGUS-Ticket-ID: #00000000” in the subject is sufficient. Such a reply will be added to the alarm ticket.
Working on ALARM tickets
For working on alarm tickets and resolving them please use the GGUS portal. A reference link to the alarm ticket is given in the alarm mail [Figure 4].
Periodic ALARM ticket testing rules
Alarm ticket testing is documented in WLCG twiki.
What if I have questions which are not dealt with by this FAQ?
Please submit a GGUS ticket.