Please see the release notes for further information.
The EGI Helpdesk is reachable via a welcome page. Another way for accessing the ticket management interface is using the direct link provided in the notification emails sent after ticket updates. However either a valid X509 personal certificate or a Check-in account are required for accessing the system.
GGUS home provides a quick overview over tickets submitted by the current user, the latest tickets of other users and a collection of news and links to useful information. The navigation bar is located on the left side of GGUS pages. It provides links to:
After each release, a major change or new feature is explained in some sentences here.
In the documentation section there is a collection of links providing useful information around GGUS system.
All information about registration can be found on the registration page. For registering as support staff, click the link “Apply” and fill in the registration form. After registering successfully you will receive a confirmation mail from GGUS team.
If you want to update your account data, you can do this using the link “Check your GGUS account” on the registration page. If you can’t access GGUS web interface due to changed DN string of your personal certificate, you can log into the system using your Check-in account. Then go to the registration page and click on Check/update your GGUS account. The system shows you all your user data. It detects the new DN string of your browser automatically. Just save the changes by clicking on button Update now. Additional information on GGUS accounts is available here.
Access to the support staff page is restricted to users having support privileges. Depending on further privileges people may have there are links to e.g. news administration and other features. All support staffs can use the GGUS report generator and the GGUS ticket timeline tool as well as links to other information useful for support staffs.
The link to the GGUS ticket timeline tool is located on support staff page. The ticket timeline tool provides a graphical overview of tickets concerning a selected site and time range. It shows all tickets that have been updated during the selected time range. When moving the mouse over one of the colored bars some additional information is displayed. Clicking on the ticket ID opens a new window showing the ticket details and the modify section of the ticket.
The link to the GGUS Report Generator is located on support staff page and on GGUS home page in section “GGUS tools/reports”. The GGUS Report Generator could be used for generating statistics and reports for all support units in GGUS. Further information on the report generator is available on the report generator.
Depending on the user’s privileges GGUS offers different ticket submit forms:
GGUS offers two fields which help to classify various tickets into categories and types.
The ticket category is for differentiating between incidents and service requests. This distinction is helpful for supporters as well as for the GGUS reporting, e.g. for excluding test tickets. Other categories were added over the time. Currently the following values are available for selection:
When submitting a ticket the ticket category field is not visible. It defaults to “Incident” and is only editable for supporters, not for users. So it is up to the supporter to check and, if necessary, classify the ticket correctly. Please see details in section Changing ticket category.
The ticket type field is for differentiating between standard user tickets and tickets for achieving the special requirements of various groups like the LHC VOs or EGI operations. It can’t be set manually, but is set automatically by the system based on several rules. The ticket type field could not be changed during ticket lifetime. Possible ticket types in GGUS are:
The ticket type USER is the default ticket type. User tickets are the usual tickets which can be submitted by everyone. They are visible to everybody. They can be updated either by the submitter himself or by any supporter.
The purpose of TEAM tickets is to allow a group of people to submit and modify ticketseditable by the whole group. TEAM tickets can only be submitted by people who have the appropriate permissions in the GGUS user database. These people belong to either one of the four LHC VOs (ALICE, ATLAS, CMS, LHCB) or to the BIOMED or BELLE VO and are nominated by the particular VO management. TEAM tickets are editable by all members of the VO team (which are the so called VO shifters) regardless own the ticket. TEAM tickets are visible to everyone. They can be submitted for all tier-1 sites in EGI and are routed to the appropriate NGI/ROC automatically, bypassing the TPM. Additionally the site is notified by mail about the ticket. By default TEAM tickets are routed to the appropriate NGI/ROC directly, bypassing TPM. But the submitter could also choose to route it to the TPM instead. Further information on TEAM tickets is available in the TEAM tickets page.
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. They can only be submitted by experts who have the appropriate permissions in the GGUS user database. These people belong to one of the four LHC VOs (ALICE, ATLAS, CMS, LHCB) and are nominated by the particular VO management. They are about 3 to 4 people per VO. ALARM tickets are editable by all members of the VO team (which are the so called VO shifters) regardless they own the ticket. They are visible to everyone. ALARM tickets can be submitted for all tier-1 sites in EGI and are routed to the appropriate NGI/ROC automatically, bypassing the TPM. Additionally the tier-1 site is notified by an ALARM email. It is up to the tier-1 site how to deal with this ALARM email. Further information on ALARM tickets is available in the ALARM tickets page.
This ticket type is used for operations tickets submitted via the operations portal.
This dashboard can be used for getting quick access to any ticket of interest. Each ticket has to be added manually.
The search engine provides a large number of fields for creating dedicated query strings. Many of them have additional information hidden behind a question mark icon. The results of a query are shown in a results list. The default search displays all open tickets of last week. They were ordered by date of creation in descending manor. For further details on using the search engine see chapter Searching for tickets. The result list is showing a color schema reflecting the priority of tickets. The algorithm used for setting the priority colours is explained in chapter Reminder emails.
Various possibilities of searching tickets in GGUS are described in this FAQ. Please avoid searching for “all” tickets or “solved” tickets without any time-frame if not necessary for some reasons as these searches cause heavy load on the machine.
Searching via ticket ID is the easiest and fastest way to look at a ticket. When searching via Ticket ID all other search parameters are ignored. Besides searching for all open tickets this is the recommended kind of search, because it avoids needless workload on the system. When searching via ticket ID the ticket details are shown in the same window. For getting back to the main page use the “Back” button of your browser. For Firefox users there is a nice add-on for adding a customized search for any web page to the browser’s search bar available here.
The search parameters can be combined in any way wanted. Description fields “Keyword”, “Involved supporter” and “Assigned to person” trigger a LIKE search to the database. Concatenating keywords with “AND” or “OR” is currently not possible. The result of a search by parameters is shown in the result list. For viewing ticket details just click on the ID. A new window opens showing ticket details. For getting back to the search result just close the window with the ticket details.
You can customize the result list in various ways. One way to customize the result list is by checking or un-checking the appropriate boxes in the blue bar. The related columns will then be added or removed. Another way for customizing the result list is by selecting another ticket order in field Order tickets by. After changing the result list layout you have to refresh the search result by clicking the Go! button.
Search results can be exported in csv or xml format for further processing. After clicking on the appropriate link a new window opens showing the results in the specified format. Out of this window you can save a local copy of this file.
By clicking on the ticket ID of a ticket in the results list of the search engine you can access the ticket data. The ticket data is divided into 3 main sections:
The system shows the information section after clicking on a ticket ID.It provides an overview of all relevant ticket parameters and could be divided into 5 areas:
Additional features of the ticket information section are:
Figure 5: Ticket duplication Supporters have the opportunity to duplicate an existing ticket up to 15 times. The duplicate feature is located right below ticket information. It is useful if a ticket concerns not only one support unit but has to be handled by several support units. The fields that are copied into the duplicated tickets are:
Attachments are not duplicated physically but linked to all duplicated tickets. The Responsible Unit is set to “TPM” by default.
Figure 3: Convert team to alarm ticket Support staffs with ALARM privileges are able to convert TEAM tickets to ALARM tickets clicking on a button in the ticket information section. This feature is only available for the WLCG VOs.
The ticket history is located below ticket information. It shows all relevant changes of the ticket in chronological manner. Changes of these fields lead to a new entry in ticket history:
For making the history more readable solution entries and entries in the public diary are marked with green colour, entries of the internal diary with orange colour.
The ticket modification area offers several fields for modifying a ticket. The fields are described in detail below.
GGUS system offers various possibilities for participating in tickets. They are
An overview on these fields is given in the table below. Ticket participation can be done by adding a valid mail address to one of these fields. Please avoid adding closed mailing lists as such produce a lot of mail errors! Several mail addresses have to be separated by semicolon.
User submit | User modify | Supporter modify | |
---|---|---|---|
CC | Yes | No | Yes |
Involve others | No | No | Yes |
Subscribe | No | Yes | Yes |
The CC field can be set by the user in the ticket submit form. Updates are only possible for supporters for correcting or removing invalid mail addresses. Every ticket update triggers a notification email to the mail address specified in the “CC” field.
The “Involve others” field is only for supporters use. Every ticket update triggers a notification email to the mail address specified in the “Involve others” field.
This field can be used by any user for participating in tickets at any time. The user has just to add his mail address. He will receive notifications for updates of the public diary or the solution for following the whole ticket life cycle. “Internal Diary” entries never go to the people who subscribed to a ticket.
Several tickets describing the same issue can be put into a master-slave relation. One of them can be marked as master, the other ones as slave. Only the master ticket has to be dealt with. The slave tickets are set to “on hold”. They can’t be updated directly as long as they are in a master-slave relation. The user gets an automated notification if a ticket is marked as slave. All updates of the master were pushed to the slaves. When solving the master the slaves are solved to. The master-slave relation is kept after the master is solved. Nevertheless each ticket can be reopened separately. Updates on reopened slave tickets are possible. A master-slave relation can be reset manually either by removing the master ID of a slave ticket or by un-checking the master checkbox of the master. If a master is unmarked as master all slaves were reset to “standard” tickets automatically.
Marking a ticket as slave is only possible if there is already a master ticket. If a ticket is marked as slave a popup window opens showing available master tickets. For selecting a master just click on the ID. The master ID is set automatically. Once you have chosen a wrong master ID click Reset Master-Slave relation and select another one.
To show all related slave tickets click on link “show slaves for this ticket”. A popup window opens showing the IDs of all slave tickets.
If you want to search for master or slave tickets you can do this using field “Special attributes” of the search engine. The status value for searching is set to an appropriate value accordingly.
Parent-child relationships work in reverse to master-slave relationships. The parent ticket cannot be resolved until all of its child tickets are resolved. The parent ticket is set to the status “on hold” while the child tickets are waiting for their solution. For each solved child ticket a note is added to the parent ticket history including the solution of the child ticket. After the last open child ticket has been solved the status of the parent ticket changes to “in progress” automatically. In addition, the system sends a notification mail to the responsible support unit that all child tickets have been solved now. So the parent ticket can be “solved” too.
A ticket can be selected as child ticket by checking the box “Mark this ticket as child of ticket” and adding the ticket ID of the parent ticket. A comment is added to the ticket history automatically stating “This ticket is a child ticket of GGUS ticket # 18492”. Multiple child tickets can be related to one parent ticket by repeating this procedure. The parent ticket is flagged as “parent” automatically. A comment is added to the ticket history automatically stating “This ticket is a parent ticket. It has to wait the solving of all its child tickets. GGUS ticket #18493 is a child to this ticket.".
For resetting child tickets just remove the tick from the checkbox “Mark this ticket as child of ticket”.
Selecting a parent ticket explicitly is not possible. The parent tickets are flagged automatically by the system while the parent ID is specified for a child ticket.
The search for parent or child tickets is similar to the search for master or slave tickets. It can be done using field “Special attributes” of the search engine.
This section is a description of how the GGUS ticketing system behaves. There are other documents which describe the system in more detail and include more of the implementation details. One of the most important fields of the system is the status field. Many workflows are triggered by status value changes. Please read the Short Guide for getting information on status values. Tickets are normally assigned to a support unit. This means that the ticket notification is sent to a mailing list composed of many supporters. One of these supporters assigns the ticket to himself and takes responsibility for it; the supporter changes the status to “in progress”. This person is then in charge of the ticket. He either solves it or reassigns the ticket to somebody else. The status of the ticket stays set to “in progress” if the ticket is under the responsibility of one supporter and until the ticket has been solved.
A graphical view of the ticket flow in GGUS is shown here:
The GGUS Support is organized with two main lines of support:
The first line support is provided by an organisation called TPM – Ticket Processing Manager. The TPM team has members who have very good general grid knowledge. It is an organisation populated by people provided from the Czech NGI. This organisation is responsible for the routing and processing of all active tickets.
The second line support is formed by many support units. Each support unit is formed from members who are specialists in various areas of grid middleware, or NGI/ROC supporters for operations problems, or VO specific supporters. The membership of the support units is maintained on mailing lists. If the user responds to any email received from GGUS, then the reply is added to the ticket history. The subject of the email includes metadata to ensure the association of the response with the ticket.
The workflows for tickets waiting for user input is described in this FAQ.
The following advice is intended for people working on TPM.
When submitting a ticket the ticket category field could not be set but default to “Incident”. It is up to the supporters to decide whether a ticket describes an “Incident” or a service ticket. Service tickets are tickets that request something be done like:
They do not report issues. This differentiation is compliant to ITIL. Differentiating between incident tickets and service tickets can help supporters to order tickets they are responsible for by urgency. The GGUS reporting also relies on the correct setting of the ticket category field as it does ignore tickets of category “Test”.
Tickets assigned to a support unit by error or tickets that need actions from other support units should be either assigned back to the TPM or assigned to the relevant support unit directly. In both cases an explanation in the public diary will avoid confusion.
In this section the usage of the different status values and input fields is described.
The system offers two groups of meta states, open states and terminal states.
Single steps of the solution process can be documented in field “Public Diary”. Information and comments which should not be visible to the user can be put into the “Internal diary”. When a solution is found, the modifier types the solution into the solution field and changes status to “solved”. The “Solution” field provides 4000 characters. If 4000 characters are not sufficient, please add an attachment. After changing status to “solved” and saving all changes, the solution is sent to the submitter via mail automatically. Tasks for solving a ticket:
Reminder mails are based on the priority colours. The algorithm of setting priority colours is described in the following chapters. Reminder mails are sent with the reply-to address ignored - atnospam - ggus.eu. All mails sent to this mail box are deleted regularly without reading them.
Priority colours are:
Priority colours depend on the expected response time and the expected solution time of a ticket.
The expected response times for support units that did not agree on a dedicated quality of service are listed in the relevant FAQ. This means, the status of a ticket should be set to another value than “assigned” for indicating that the support unit has acknowledged the ticket.
The expected solution times are driven by the priority values of the tickets. All values are working days. The higher the priority the shorter is the duration within which the ticket is expected to be solved. For further details please see the Ticket Priority page.
Ticket follow-up Ticket follow-up is done by a team at KIT (Germany) for all tickets besides operations tickets. More information on the ticket follow-up processes are available at the pages about DMSU ticket follow-up and Ticket monitoring.