Deployment team

→ Europe/Zurich
VRVS - Subway virtual room

VRVS - Subway virtual room

Jeremy Coles
Minutes
    • 11:00 → 11:20
      Experiment problems/issues 20m
      Review of weekly issues by experiment/VO - LHCb - CMS - ATLAS - Other
    • 11:20 → 11:25
      Review of ops meeting news 5m
      Agenda link: http://indico.cern.ch/conferenceDisplay.py?confId=18673 - Main items -- YAIM on PPS = New version of YAIM will be delivered today from certification to PPS with PPS Update35 . The new update will contain only the "service oriented" version of YAIM. Although this version of YAIM supports both gLite3.0 and gLite3.1, the rpm will presumably be shipped with the number 3.1.1 , this number will be upgraded to 4.0.0 before the release to production in order not to create confusion with versions 3.0 and 3.1 of gLite. -- More YAIM Once YAIM 3.1.1 is released (expected mid July), the previous versions of YAIM will not be further developed or maintained. This means that YAIM bug fixing will only be done in versions equal or higher than 3.1.1. The new yaim can use old site-info.def. The way site-info.def is handled hasn't changed. In general, the new yaim doesn't introduce big changes for the site admins since the yaim command is already present from yaim 3.0.1. -- And you guessed it: glite-yaim=3.0.1-22 (gLite 3.0.2 Update 27) allows "sgm" and/or "prd" users to be mapped to the traditional static accounts or to their own sets of pool accounts. Pool accounts are better w.r.t. the audit trail on the CE and WN. The use of pool accounts can be decided per VO and per account type: YAIM will discover which sort of accounts has been put into users.conf for sgm and/or prd users and map those users accordingly. The LHC experiments have been asked to adapt their software installation procedures to cope with the possible use of sgm pool accounts at sites. LHCb were the only ones to respond so far: in principle their procedure is ready, but they request sites not to switch to sgm accounts during the summer holidays, when the available expertise to debug problems is much reduced. -- Glue Schema updates and upgrading BDIIs: gLite 3.0.2 Update 27 includes fixes to the Glue schema: The new version of glue-schema updates to Glue version 1.3. The top-level BDIIs should be updated first, followed by the sites BDIIs and then the GRISs. Only when all the nodes have been updated, new information can be published. As discussed at this week's operations meeting, we propose a coordinated staged deployment of this fix to the production BDIIs: * Step 1: upgrade ONLY all top level BDIIs in the next week, deadline: the end of next Monday 9th of July * Step 2: upgrade site BDIIs, starting from Tuesday 10th of July (a reminder will be given at next Monday's operations meeting and broadcasted after). PLEASE, ALL PRODUCTION SITES: don't upgrade your site BDII yet, wait till Tuesday 10th of July (In case your site has been already upgraded, we are presently testing what would be the effects of this (site BDII upgraded and top level BDII not upgraded) so we can inform the VOs and find a workaround).
    • 11:25 → 11:35
      Summary from GSSD (pre-GDB) 10m
      Slides
    • 11:35 → 11:40
      Quarterly reports status 5m
      - Including KSI2K values and benchmarking - Any storage accounting problems? Please cross check site derived values with those in the portal: http://goc02.grid-support.ac.uk/accountingDisplay/view.php?queryType=storage
    • 11:40 → 11:50
      Status of SL4 testing 10m
      - What has been done so far - Findings (links to the rpm information) - Coordinating the rollout across UK sites What's in the VO cards? (https://cic.gridops.org/index.php?section=rc&page=supportedvos) ALICE: No requirements mentioned. ATLAS: Software installation requirements: - an experimental software area (shared filesystem) with at least 20 GB free; - the full compiler suite should be installed in the WNs; - the f2c library is also required to run the software; - high priority in the batch system for the atlassgm user. - ATLAS also have this page: https://twiki.cern.ch/twiki/bin/view/Atlas/RPMcompatSLC4 CMS: No other requirements LHCb:For SL3/SLC3 sites: LHCb software requires PYTHON2.2 installed plus OS compatibility with RH7.3. In more details they need the following RPM : compat-libstdc++-7.3-2.96.128 containing libstdc++-libc6.2-2.so.3 libraries. For SL4/SLC4 sites: it is sufficient the node has 32-bit compatibility, Our slc3 binaries would run on slc4 nodes regardless of whether they are installed in 32-bit or 64-bit mode. This is certainly true of the most recent releases. The only complication is that you need to make sure you have access to the gcc323 runtime libraries, and to the correct, gcc323 compatible build of libshift.so.2.1 Irrespectively the OS and capabilities of the site it is strongly required that the site does advertise correctly the platform accordingly the convention available at: http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_my_machine_architecture http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_the_OS_name It is also strongly required that sites keep separated clusters running different OSes (using different CEs). Others: Do we know of others this may impact? LAL's results: "I just want to emphasize once again that we need to validate but there is not much reason to worry about potential problems, for at least 2 reasons : - LHC experiments tend to provide anything they need in their SW area and don't rely on installed RPM for anything, except very standard thing, installed everywhere, from the OS. - GRIF has been successfully running SL4 WNs (even 64-bit) without any change to experiment SW for more than a year. ... To provide SL3 compatibility for applications, it is necessary to install RPM part of standard SL distribitution : compat-libstdc++-33-3.2.3-47.3.i386.rpm If you want to run on a 64-bit WNs, there a couple of other i386 rpm required (Python, ElectricFence...). I can give the full list if somebody is interested."
    • 11:50 → 11:55
      Actions review 5m
      Those that are most urgent: Andrew: Collate plans from CMS and what is know regarding the ATLAS transfers to derive a more detailed schedule for joint and dteam testing – for site bandwidth and site SE-WAN capabilities David: Send URL to agendas for CMS software weeks to the list
    • 11:55 → 12:00
      AOB 5m
      - Update from ROC manager's meeting - EGEE 2007 (last day for early registration)
      text