Internal SA1 issues being addressed by the ROC Managers

This is the list of issues gathered by the ROCs, which need to be addressed internally within SA1.

# DESCRIPTION ADDED BY DATE ADDED
1 Monitoring tools improvements. Currently if there's a problem with some central service (e.g. top-level BDII) the site is being assigned a ticket because it appears to fail a critical SAM test. This needs to be changed: the monitoring tools should distinguish between site related and core service related problems and not "accuse" the site unnecessarily. It always takes the site admin's time to investigate the problem. Nick 19/03/07
2 The GGUS interface should be substantially improved to allow users submitting problems to indicate the type of the problem more clearly, or even to assign it to a support unit. This will reduce workload on TPM and help users. Also, introducing expected resolution time of a ticket would be nice improvement (set initially by user, adjusted by TPM and supporter if needed). Nick 19/03/07
3 Failover of core operations services (SAM, GOCDB, CIC portal (esp. Broadcast tool), GGUS must be reliable. This means each service must be able to fail-over quickly and completely to another site. Nick 19/03/07
4 Upgrading of core operations services should be done outside of working hours.
Upgrading of core operations services (e.g. CIC portal, GOCDB, etc.) should be transparent.
Nick 19/03/07
5 GOCDB and eNOC database need to be linked so that all the information which a site is required to provide can be entered through just one interface. Nick 19/03/07
6 LFC Perl API on 64 bit OS - In the March GDB meeting (March 7th) SL4 migration issues have been discussed. In particular the presentation by Markus Schultz, see page (11). There are three possible scenarios mentioned how one could get to interpreted languages running on 64Bit SL4. It seems, that solution B ("Forget Perl ...") would mean that the PERL API for LFC would be dropped. E.g. as VOs HONE and ZEUS use this API heavyly in production, it's strongly requested to provide these APIs in future. Sven 02/04/07
7 All Operations Tools (GOC DB, CIC poratl, etc.) must have an adequate Change Request (CR) process in place.
The essential elements of a change request process were agreed by the ROC managers on 22 May 2007 and can be found here
Nick 5/06/07
8 Release notes often do not mention major changes that will affect services in production.
– Example: introduction of new pools of accounts for prd and sgm users was mentioned only at the bottom of YAIM-3.0.1 guide, not at all in release notes of the update that introduced new YAIM release (see GGUS 20942).
ANSWER: Agreed; some selected sites in PPS will be requested to do a final check on the release notes before they are ready (usually 1-2 days before the release).
Nick 9 Oct 07

Votes

  • 3 for the No1 priority
  • 2 for the No2 priority
  • and 1 for the No3 priority of your roc

(this explanation wasn't visble before)

ISSUES / ROC AP CESorted ascending CERN DECH FR IT NE RU SEE SWE UKI SUM
1         3             3
2         1             1
3         2             2
4                       0
5                       0
6                       0
7                       0

-- Main.thackray - 25 Oct 2006

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r8 - 2007-10-09 - NicholasThackray
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EGEE All webs login

This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback