Meeting held on April 29

Present:Antonio, Steve, John, Nick, Diana, Farida.

Conclusions/Actions

  • By default, unless someone volunteers, the ROC manager takes the responsibility of medium or long term tasks and make sure that they are carried out in time.
  • By default, unless someone volunteers, the ROC on duty (RoD) takes the responsibility of short term tasks that can be completed within the shift and make sure that they are carried out in time.
  • Farida to contact SAMAP if necessary for repairing the cron job submission.
  • The Worklog/Handover log will be used to communicate specific issues to be reported at the operations meetings to the RoD of the following week.

Points discussed

ROC WMS

  • This instance is used as a back up for SAMAP. It will not be used for the ROC certification anymore, SAMAP will be used directly for that.
  • It will be managed by Yvan, now FIO, as Lanxin who was the service manager has now left.
  • The cron job to launch the ROC certification jobs in SAMAP appears to be broken. Farida will verify and contact Rafal if necessary.

ROC on Duty role

  • The COD shift will be considered as separate shift. It will count as a full shift in the 'Hall of Fame'.
  • By default, unless someone volunteers, the ROC manager takes the responsibility of medium or long term tasks and make sure that they are carried out in time.
  • By default, unless someone volunteers, the ROC on duty takes the responsibility of short term tasks that can be completed within the shift and make sure that they are carried out in time.
  • The ROC reporting window in the CIC portal does not allow the RoD of the previous week to fill the report and problems sometimes arise when the new RoD is not aware of issue that went on the previous week. We will use the worklog (from now on aka Handover log) to report specific issues should there be any, so that they can be reported in the ROC report and raised at the operations meetings.

GGUS Survey

  • ROC CERN had a very poor response: only 2 out of ~20 sites answered, despite several reminders sent.
  • This has been identified as probably coming from two facts. The first that nobody in the ROC took the responsibility of following with the sites to make sure that they answered. And second, that ROC CERN is perceived as very distant by its sites. We should make an effort to improve out communication channels with the sites, and to attribute individual owneship to tasks (conclusion on this point already reported above).

SLAs

  • Shall we use GGUS to track progress? Probably a bit impersonal but it allows for keeping track on the progress made.
  • We need to come to an agreement on the numbers for the availability metrics with each site first and then sign a copy (on paper or electronically). Copies to be archived.

Communication with the sites

  • Should be improved. Partially already addressed under other points. The mailing list that we have is now obsolete, we should probably remove it and use the EGEE broadcast to communicate with sites.

Website

  • We should keep it up to date. It is a good way to keep track of long term tasks and a way to communicate with the sites.
  • We should also have a way for a more dynamic communications with the sites: shared point discussion groups? a blog?

-- DianaBosio - 13 May 2008

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r1 - 2008-05-13 - DianaBosio
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback