USAG 05 June 2008 notes by Diana Attendance ----------- AP - Min Tsai CERN - Maria Dimou, Diana Bosio FR - GGUS - Helmut Dres, Torsten Antoni, Guenter Grein IT - Federico Nebiolo NE - Jeff Templon, Ron Trompert UK/I - Claire Devereux SW - Kai Neuffer JRA1 - Francesco Giacomini Apologies: Cal Loomis 3. Discussion on EGEE III Milestone MSA1.6 on GGUS assessment To assist Kai in the writing of the document MSA1.6 on the GGUS assessment. Maria proposed that the USAG makes a table of content for it. In this way we can make explicit the criteria for the assessment. USAG can have a say on what criteria should be included in the document, in a similar way of what was done in EGEEII. This is a huge document, that may be reduced. It is linked from the agenda of the USAG meeting of April 10. At the proposal to use the previous assessment as a blueprint, Torsten made the remark that it does not make sense to distribute it. The assessment in EGEEII was closely coupled with the plan, as in the plan one could find the criteria for its assessment. maria asked if we wish to do the same for the assessment in EGEEIII. The EDMS reference is document 726136. Jeff asked if we were discussing the assessment document or a document to guide the assessment. Diana replied that it was the former and Jeff then commented that in this case it seems weird that the plan contains the assessment. Those should be independent documents. It was clarified that the plan did not contain the assessment, but very precise points on which progress could be measured. In this sense, the assessment was made much easier and "contained" in the plan. Torsten: we should make the assessment based on the GGUS plan for EGEEIII. But there is a problem, the plan is due end of June, but I have no number whatsoever for the effort of the various the subtasks. Without those it is very hard to plan. Maria: pity that the VOs are not here today. Does anyone would like to propose a criteria that is important for them to assess User Support? Those criteria should be made available before next meeting as the milestone document is due during the Autumn so we only have few meetings left to discuss them. Jeff and Ron asked for a measure of efficiency. In particular Jeff asked if one could have statistics on the various status transitions, 1. new -> assigned to TPM 2. TPM -> assigned to ROC 3. assigned -> in progress in ROC 4. assigned to ROC -> assigned to site 5. in progress -> closure {ndr. transition 4 happens quite often outside of GGUS, as such GGUS cannot have statistics on that) ideally divided by kind of tickets: 1. bug in software (corresponding to all the software SUs) 2. failed SAM test (corresponding to tickets issued by CODs) 3. experiment problem (corresponding to VO related tickets 4. VO tickets (under VoSupport SU) Torsten: it would be nice to have also statistics over time. Those metrics are already collected, it is not a big effort to provide statistics on them Maria: Can Kai use this data and draw conclusions? Kai: Yes. One could also ask big and small VOs about their input. Maria: We could also use the site survey results (Kai agreed) and I will also ask the VOS for their input on criteria to be used, but it would be easier if one had some concrete questions to be answered. Kai will compile a questionnaire for the VOs based on the site survey results Conclusion Torsten will provide the statistics on GGUS tickets Kai will analyse the statistics and also compile a questionnaire based on the site survey results maria will address NA4 Vo managers and the LHC Vos before the end of the summer to have time to discuss the input for the document. We shall keep this item on the agenda for future meetings. Kai disconnects. 4.4 DISCUSSION ALARMS ROUTING TO SITES PROPOSAL There is new input on the corresponding SL item in savannah from Maria, GGUS, Jeff and John Gordon. https://savannah.cern.ch/support/?103942 After some discussion it was agreed that: - the e-mail will be signed by GGUS using its own certificate - the body of the e-mail will contain the DN of the original submitter - the alarm e-mail will follow a formatted template Diana noted that concerning the template we should involve the actual people that will submit this kind of e-mails. Maria noted that they were invited to join the meeting, and Jeff commented that ATLAS is in hot water at the moment and this is probably the reason why they did not join. Guenter proposed to implement what we have no, i.e. the signed e-mail with the current template as the template can always be changed later. Jeff asked clarification on on field of the template the "update field" which basically is the field used to indicate if the ticket is a team ticket or not. Jeff started a discussion on how to guide ticket submission, but decided to move the discussion in a savannah item to propose additional fields like service endpoint. Maria: additional fields typically interfere with local ticketing systems, so please describe them very accurately. to wrap up, Maria told that Guenter is going to meet the following day with the security team of KIT (fka FZK) to discuss how GGUS can send signed e-mails. This opened the discussion on where to store the alarm e-mail address of sites. For the moment it will be maintained in GGUS, but will eventually move to the GOCDB. Maria: from where can GGUS take the list? Jeff: LCG Twiki. Will send the link. But Guenter know as he used the LCG names and not the EGEE ones. DB: We have a problem. Which names shall we use? A discussion followed, as the mapping is not one-to-one between LCG and EGEE names, some T1s are distributed, like NL-T1 which is two sites, and also some UK T2 is 4 sites. Maria: GGUS has to use EGEE names, we stated this explicitly many times in many meetings. Diana: maybe we can rescue the situation. If mapping is always one-to-many it is enough to have many sites in the GOCDB with the same alarm e-mail. GGUS will only need to maintain the list that maps the LCG naming scheme with the EGEE one, which should be stable and fixed, in case some operators use the LCG name. Maria wraps up the discussion saying that GGUS will have to maintain: - the alarms e-mail list until GOCDB takes over - a list of mapping between the T1 and the EGEE sites. 4.1 DISCUSSION ON ESCALATION BODY FOR TICKETS Maria: Some users would like to have an escalation authority to complain about tickets. Maybe a button "escalate" that reassign ticket to OCC Diana: But then the ticket disappear from the SU's radar maria: Right, maybe then the button will just cause an "involve others" for the OCC. Diana: yes, but OCC is not the right body to escalate software tickets. Francesco: In EGEEII developers gave support, but now this is not possible anymore. Developers cannot answer GGUS tickets, only savannah bugs. Diana: but the unit after all is a mailing list. Maybe we can find a way to solve this, without giving the burden of opening savannah bugs and follow them to see if they were accepted or rejected to the TPMs. Discussion will be taken offline. Progress to be reported at the next meeting. Points 4.2, 4.3, 5, 6.1 will be reported to next meeting as time is really short 6.2 TPM training NE ROC asked Min to be trained in order to join the TPM effort, but nor Min nor Maria coordinate the training. Torsten: yes, we use to offer regular training in EGEEII but the demand was really low. We now plan to offer training on request. There is no point in setting up an organizational effort given that the demand is so low. Maria: fine. Would you send an e-mail to the ROC managers list to see which ROC is interested in being trained for TPM duties? Torsten: will do Min: I was not directly involved in training, but we had very good training at CERN two years ago, the involvement of experienced TPMs is crucial. Torsten will write to the ROC managers list to see what is the demand. 6.1 USAG@EGEE08 Consensus was that it is a good idea. Maria will see if she can obtain a slot at the beginning or at the end of the week so that she can come only for few days. 4.3 DISCUSSION (BRIEF) ON THE REMINDER E_MAIL FOR "AGENTS" Guenter would like to avoid having many kind of different reports and reach a consensus on a good definition before implementing it. Diana suggested Claire to contact Matt (the originator of the request) to get further requirements on what he would like, and the urgency of it as if not that urgent maybe the item can be moved to the July release. ACTION LIST 20080506-1: (Was: #164.14) Provide information on the CIC VO XML dump Gilles. Now passed to the CIC developers (give us a name please as Gilles left. Carry forward This action dates since the ESC meeting of 24 May 2007. Please remind us who still needs this action done and why. David Bouvet will ask Gilles. ???? 20080506-3: Ask the GOCDB developers about Site alarms' mailing lists inclusion. Claire Pending. 20080506-4: Comment on EGEE II DSA1.7 (FZK) http://edms.cern.ch/document/726263, page 41. Torsten ???? 200806-1: Provide statistics on elapsed time between status transitions in GGUS Torsten Pending 200806-2: Write a questionnaire for the VOs based on the site survey results to solicit criteria of assessment for user support Kai Pending 200806-3: Write to NA4 and LHC VO managers to ask criteria for user support assessment. Maria Depends on 200806-2. 200806-4: Keep point about MS1.6 in agenda Maria 200806-5: send the link of the LCG twiki where the alarm e-mails for the sites can be found Jeff Done 200806-6: Report progress on the definition of escalation authority for software tickets. Diana and Maria 200806-7: Poll the ROC managers list to see who needs to attend the training, so GGUS can send material, pointers to documentation and organize a training session if needed. Torsten Pending 200806-8: Ask Matt if the item can go to the July release and to add further input to the savannah item https://savannah.cern.ch/support/?104039 200806-9: agenda points 4.1, 4.2, 4.3, and 5 to next meeting Maria Pending