DMSU report for TCB meeting 28/2-2011

(this is an unfiltered, not quite-politically-correct version :-))

First an overview of tickets per support group:

      1 APEL-EMI
      1 ETICS
      1 gLite_Hydra
      1 gLite_Identity
      1 gLite_Java
      1 gLite_Release
      1 gLite_SGE
      1 Gridsite
      1 Proxyrenewal
      1 SAM/Nagios
      1 TPM
      1 UNICORE-Client
      1 UNICORE-Server
      2 AMGA
      2 ARGUS
      2 dCache
      2 DGAS
      3 ARC
      3 EMI
      3 MPI
      3 VOMS
      6 FTS
      6 gLite_L&B
      6 Information_System/GIP/BDII
      7 VOMS-Admin
      9 gLite_Security
      9 lcg_util
      9 LFC
     10 StoRM
     12 gLite_Yaim
     14 CREAM-BLAH
     14 DPM
     17 Information_System
     21 DMSU
     21 gLite_WMS
     41 APEL

Most of the APEL tickets concerns configuration of the client. Considering the
size or complexity that an accounting client should have, the number of tickets
is rather high. Most of the APEL tickets are concerned with configuration, but
there is also a number of tickets reporting the APEL service is being down. The
latter problem is often transient.

WMS is a central component in gLite, but still scores a bit on the high side.
DMSU tickets are tickets which could be solved immediately by DMSU assigners
without assigning them to a specific support unit. Information system is
typically BDII (also has another entry further down), and many of those tickets
appears to be configuration releated.

From DPM and down, I haven't seen enough tickets to make any generalizations
about their nature.

What is also interesting the low number of tickets for ARC, dCache, and
Unicore. The ARC and dCache projects (and probably also Unicore) already has
working support and ticket systems, and it is likely that their users use those
directly. Assuming users get proper support I do not consider this a huge
problem. It makes it difficult to get metrics, but we should not punish
technology providers from having well-working existing infrastructure. Several
TPs also have other customers than EGI and need such systems regardless of EGI.
If we want metrics, EGI must become better at integrating with existing
systems, and stop assuming that GGUS is the center of the world.

The majority of tickets reported to DMSU are concerned with configuration
issues, or other problems that can be solved without changing the middleware.
There of course also tickets, which are bugs, but they are a minority. GGUS
does currently not support marking the nature of the ticket, i.e.,
configuration, bug, etc. Furthermore there is not support for collecting ETAs,
which should only exist for software bugs. Collecting ETAs, is currently only
done sparsely, and is typically only denoted in the ticket as text. Some of the
reported software issues are already reported and has a ticket in the issue
tracking systems of the TP. Currently tickets for bugs have a link to the TP
ticket system and is put on hold, until the bug is fixed. This is very far from
optimal. Being to able to integrate with such upstream ticket system in some or
another would be very nice.